2.1 軟件測試發展歷程
軟件測試伴隨着軟件的產生而產生。早期軟件開發過程中，軟件規模小，複雜程度低，軟件開發過程相當混亂無序，軟件測試含義也比較窄，等同於“調試”。此時軟件測試的目的是糾正軟件的故障，常常由軟件開發人員自己進行。對測試的投入極少，測試介入也晚，常常是等到形成代碼、產品已經基本完成時才進行測試。
1957年，軟件測試首次作爲發現軟件缺陷的活動，與調試區分開來。1972年，北卡羅來納大學舉行首屆軟件測試會議，John Good Enough和Susan Gerhart在IEEE上發表的《測試數據選擇的原理》確定了軟件測試是軟件的一種研究方向。1979年，Glenford Myers在《軟件測試藝術》一書中提出“測試是爲發現錯誤而執行的一個程序或者系統的過程”。
20世紀80年代早期，軟件和IT行業進入了大發展，軟件向大型化、高複雜度的方向發展，軟件的質量越來越重要。一些軟件測試的基礎理論和實用技術開始形成，軟件開發的方式也逐漸由混亂無序的開發過程過渡到結構化的開發過程。以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試爲特徵，軟件測試性質和內容也隨之發生變化，不再是一個單純的發現錯誤的過程，而是具有軟件質量評價的內容。1983年，Bill Hetzel在《軟件測試完全指南》中指出，測試是以評價一個程序或者系統屬性爲目標的一種活動，是對軟件質量的度量。IEEE給軟件測試定義爲“使用人工或自動手段來運行或測定某個軟件系統的過程，其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別”。這個定義明確地指出，軟件測試的目的是爲了檢驗軟件系統是否滿足需求，軟件測試不再是一個一次性的活動，也不只是開發後期的活動，而是與整個開發流程融爲一體的。
20世紀90年代，軟件測試工具開始運用。1996年，測試支持度TSM、測試成熟度TMM等一系軟件測試相關理論被提出。到了2002年，Rick和Stefan在《系統的軟件測試》一書中對軟件測試做了進一步描述：測試是爲了度量和提高軟件的質量，對軟件進行工程設計、實施和維護的整個生命週期過程。
近20年來，隨着計算機和軟件技術的飛速發展，軟件測試技術的研究也取得了很大的突破。許多測試模型(如V模型等)產生，單元測試、自動化測試等方面涌現了大量的軟件測試工具。在軟件測試工具方面，商業化的軟件測試工具，如捕獲/回放工具、Web測試工具、性能測試工具、測試管理工具、代碼測試工具等大量涌現，一些開放源碼社區中也出現了許多軟件測試工具，這些工具得到了廣泛應用且相當成熟和完善。
2.2 軟件測試目的
軟件測試是指使用人工或者自動手段來運行或測試某個系統的過程，其目的在於檢驗被測試系統是否滿足規定的要求或弄清預期結果與實際結果之間的差別。
軟件測試是幫助識別開發完成(中間或最終的版本)計算機軟件(整體或部分)的正確度、完全度和質量的軟件過程，是軟件質量保證的重要子域。
Grenford J.Myers曾對軟件測試的目的提出過以下觀點:
(1) 測試是爲了證明程序有錯，而不是證明程序無錯誤；
(2) 一個好的測試用例在於它能發現至今未發現的錯誤；
(3) 一個成功的測試是指發現了至今未發現的錯誤的測試。
這種觀點指出測試是以查找錯誤爲中心，而不是爲了演示軟件的正確功能。但是隻從字面意思理解可能會產生誤導，認爲發現錯誤是軟件測試的唯一目的，查找不出錯誤的測試就是沒有價值的測試。
軟件測試的目的往往包含如下內容：
(1) 測試並不僅僅是爲了找出錯誤，而且要通過分析錯誤產生的原因和錯誤的發生趨勢，幫助項目管理者發現當前軟件開發過程中的缺陷，以便及時改進。
(2) 測試分析幫助測試人員設計出有針對性的測試方法，以改善測試的效率和有效性。
(3) 沒有發現錯誤的測試也是有價值的，完整的測試是評定軟件質量的一種方法。
2.3 軟件測試原則
軟件測試應遵循以下基本原則：
(1) 應當把“儘早地和不斷地進行軟件測試”作爲軟件開發者的座右銘。由於軟件的複雜性和抽象性，軟件開發各個階段工作的多樣性，以及參加開發各種層次人員之間工作的配合關係等因素，使得開發的每個環節都可能產生錯誤。因此不應把軟件測試僅僅看做是軟件開發的一個獨立階段，而應當把它貫穿到軟件開發的各個階段中。堅持在軟件開發的各個階段進行技術評審，儘早發現和預防錯誤，把出現的錯誤克服在早期，杜絕某些隱患，提高軟件質量。
(2) 測試用例應由測試輸入數據和與之對應的預期輸出結果兩部分組成。測試用例主要用來檢驗程序員編制的程序，不但需要測試輸入數據，而且需要針對這些輸入數據的預期輸出結果。如果對測試輸入數據沒有得到預期的程序輸出結果，那麼就缺少了檢驗實測結果的基準，就有可能把一個似是而非的錯誤結果當成正確結果。
(3) 程序員應避免檢查自己的程序。測試工作需要嚴謹的作風、客觀的態度和冷靜的情緒。心理學告訴我們，人們具有一種不願否定自己工作的心理，而這一心理狀態就成爲測試自己程序的障礙。另外，程序員對軟件規格說明理解錯誤而引入的錯誤則更難發現。因此由別人來測試程序員編寫的程序，可能會更客觀、更有效，並更容易取得成功。
(4) 在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證程序正確的輸入條件；而不合理的輸入條件是指異常的、臨界的、可能引起問題異變的輸入條件。用不合理的輸入條件測試程序時，往往比用合理的輸入條件進行測試能發現更多的錯誤。
(5) 充分注意測試中的羣集現象。經驗表明，測試後程序中殘存的錯誤數目與該程序中已發現的錯誤數目或檢錯率成正比。根據這個規律，應當對錯誤羣集的程序段進行重點測試，以提高測試投資的效益。 在所測程序段中，若發現錯誤數目多，則殘存錯誤數目也比較多。這種錯誤羣集現象已爲許多程序的測試實踐所證實。例如IBM公司的OS/370操作系統中，大量的錯誤僅與該系統的4%的程序模塊有關。因此，如果發現某一程序模塊似乎比其它程序模塊有更多的錯誤傾向時，則應當花費較多的時間和代價測試這個程序模塊。
(6) 嚴格執行測試計劃，排除測試的隨意性。測試計劃應包括：所測軟件的功能，輸入和輸出，測試內容，各項測試的進度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方式和過程，系統組裝方式，跟蹤規程，調試規程，迴歸測試的規定以及評價標準等。
(7) 應當對每一個測試結果做全面檢查。有些錯誤的徵兆在輸出實測結果時已經明顯地出現了，但是如果不仔細、全面地檢查測試結果，就會使這些錯誤被遺漏掉。所以必須對預期的輸出結果明確定義，對實測的結果仔細分析檢查，抓住徵候，暴露錯誤。
(8) 妥善保存測試計劃、測試用例、出錯統計和最終分析報告，爲軟件維護提供方便。
2.4 軟件測試分類
2.4.1 按照開發階段劃分
軟件測試貫穿整個軟件開發的始末，按照軟件開發階段劃分，軟件測試分爲單元測試、集成測試、確認測試、系統測試、驗收測試等。
2.4.2 按照執行主體劃分
按照測試實施組織劃分，軟件測試分爲開發方測試、用戶測試和第三方測試。
1．開發方測試
開發方測試通常也叫“驗收測試”或“α測試”。在軟件開發環境中，開發者檢測與證實軟件的實現是否滿足軟件設計說明或軟件需求說明的要求。用戶測試是指在用戶的應用環境下，用戶檢測與覈實軟件實現是否符合自己預期的要求。
2． 用戶測試
通常用戶測試被稱爲β測試，指把軟件有計劃地、免費地分發到目標市場，讓用戶大量使用、評價和檢查軟件。通常情況下，用戶測試不是指用戶的“驗收測試”，而是指用戶的使用性測試，由用戶在應用過程中發現軟件的缺陷與問題，並對使用質量進行評價。
3．第三方測試
第三方測試是指由第三方測試機構來進行的測試，也稱獨立測試。第三方測試由在技術、管理和財務上與開發方和用戶方都相對獨立的組織進行，一般在模擬用戶真實應用的環境下，進行軟件的確認測試。
2.4.3 按照執行狀態劃分
1．靜態測試
靜態測試是指計算機不真正運行被測試的程序，而是人工對程序和文檔進行分析與檢查，包括走查、符號執行、需求確認等。靜態測試一方面利用計算機作爲對被測程序進行特性分析的工具，與人工測試有着根本的區別；另一方面並不真正運行被測程序，與動態方法也不相同。因此，靜態測試常稱爲“分析”，是對被測程序進行特性分析方法的總稱。靜態分析過程如圖2.1所示。其中，針對代碼的靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等。
1) 代碼檢查 代碼檢查主要檢查代碼和設計的一致性，代碼對文檔標準的遵循及代碼的可讀性，代碼的邏輯表達正確性，代碼結構的合理性等方面。代碼檢查比動態測試更有效率，能快速找到30%～70%的邏輯設計錯誤和代碼缺陷。
代碼檢查一般在編譯和動態測試之前進行，其實施方法很多，如走查(Walk through)、審查(Inspection)、評審(Review)等，如表2.1所示。
(1) 走查。 (2) 審查。 (3) 評審。
2) 靜態結構分析 靜態結構分析以圖形的方式表現程序的內部結構，例如，函數調用關係圖、函數內部控制流圖等。其中，函數調用關係圖描述程序中函數調用與被調用的關係，控制流圖顯示函數的邏輯結構。
2．動態測試
動態測試指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率和健壯性等性能的測試方法。這種方法由三部分組成：構造測試實例、執行程序和分析程序的輸出結果。
2.4.4 按照測試技術劃分
1．黑盒測試
黑盒測試也稱功能測試或數據驅動測試。它是在已知產品所應具有的功能的前提下，通過測試來檢測每個功能是否都能正常使用。在測試時，把程序看做一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息，並且保持外部信息(如數據庫或文件)的完整性。黑盒測試試圖發現以下類型的錯誤：功能錯誤或遺漏、界面錯誤、數據結構或外部數據庫訪問錯誤、性能錯誤、初始化和終止錯誤等。
2．白盒測試
白盒測試又稱結構測試或邏輯驅動測試。與黑盒測試正好相反，它是知道產品內部工作過程，檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都能按預定要求正確工作。白盒測試的主要方法有邏輯驅動、路徑測試等，主要用於軟件驗證。
白盒測試是基於源代碼的測試，需要了解程序的構架、具體需求以及一些編寫程序的技巧，能夠檢查一些程序規範、指針、變量、數組越界等問題。 白盒測試容易發現以下類型的錯誤：變量沒有聲明、無效引用、數組越界、死循環、函數本身沒有析構、參數類型不匹配、調用系統的函數沒有考慮到系統的兼容性等。
3．灰盒測試
灰盒測試介於黑盒測試和白盒測試之間，主要用於測試各個組件之間的邏輯關係是否正確，相對白盒測試來說要求相對較低，對測試用例要求也相對較低，用於代碼的邏輯測試、驗證程序接收和處理參數。灰盒測試的重點在於測試程序的處理能力和健壯性，相對黑盒測試和白盒測試而言，投入的時間相對少，維護量也較小。 軟件測試方法與軟件開發過程相關聯。單元測試一般應用白盒測試方法，集成測試應用灰盒測試方法，系統測試和確認測試應用黑盒測試方法。 黑盒測試和白盒測試比較如表2.2所示。
2.4.5 按照軟件發佈範圍劃分
1. 國際化測試
國際化測試的目的是測試軟件的國際化支持能力，發現軟件的國際化的潛在問題，保證軟件在世界不同區域都能正常運行。以Windows應用軟件爲例，針對世界軟件市場的語言優先級，需要首先應用德語和日語的操作系統。這兩種語言代表最重要的區域市場，同時日語又作爲東亞雙字節字符的典型語言，在英文Windows操作系統上安裝具體的語言支持文件進行區域設置。將日語作爲系統默認區域設置進行測試，可驗證ANSI(非Unicode)組件中的雙字節字符集(DBCS)處理。將德語作爲系統默認區域設置進行測試，可確保需要進行文本轉換時能夠正確處理ANSI和OEM代碼頁。
國際化測試使用每種可能的國際輸入類型，針對任何區域性或區域設置檢查產品的功能是否正常。軟件國際化測試的重點在於執行國際字符串的輸入/輸出功能。國際化測試數據必須包含東亞語言、德語、複雜腳本字符和英語(可選)的混合字符，其中複雜腳本字符指阿拉伯語、希伯來語、泰語。國際化測試中發現的比較嚴重的軟件錯誤包括軟件在不同區域設置環境下的功能丟失或數據破壞。這些錯誤經常出現在字符編碼轉換和雙字節字符的輸入/輸出過程中。
2. 本地化能力測試
本地化能力是指不需要重新設計或修改代碼，將程序的用戶界面翻譯成任何目標語言的能力。本地化能力高的軟件可以容易地實施本地化處理。本地化能力測試的目的是測試軟件的本地化支持能力，儘早發現軟件本地化時將會出現的潛在錯誤。本地化能力測試通過以後，表示產品已可用於本地化，才能進行軟件的本地化過程和本地化測試。爲了降低本地化能力測試的成本，提高測試效率，本地化能力測試通常在軟件的僞本地化版本上進行。軟件的僞本地化是指將軟件中需要本地化的英文文本，使用其它本地化的文本替換，模擬本地化版本的過程。
3. 本地化測試
本地化測試的目的是測試特定目標區域設置的軟件本地化質量。本地化測試的對象是軟件的本地化版本。本地化測試的環境是在本地化的操作系統上安裝本地化的軟件。從測試方法上分爲基本功能測試、安裝/卸載測試、當地區域的軟硬件兼容性測試。測試的內容主要包括軟件本地化後的界面佈局和軟件翻譯的語言質量，包含軟件、文檔和聯機幫助等部分。
本地化測試的錯誤主要包括軟件用戶界面錯誤，如佈局錯誤(版式、大小和位置)，本地化有關的功能錯誤，翻譯錯誤和雙字節支持錯誤。軟件的翻譯質量包括翻譯的準確性、完整性、一致性以及特定區域市場的文化、傳統、習俗和政治的敏感內容。爲了保證軟件本地化測試的質量和成本，通常外包給當地語言爲母語的本地化服務公司。
2.5 軟件測試模型
2.5.1 V模型
V模型作爲最典型的測試模型，由Paul Rook在20世紀80年代後期提出，如圖2.2所示。V模型反映了測試活動與分析和設計的關係，明確標明瞭測試過程中存在的不同級別，並清楚描述測試的各個階段和開發過程的各個階段之間的對應關係。V模型左側是開發階段，右側是測試階段。開發階段先從定義軟件需求開始，然後把需求轉換爲概要設計和詳細設計，最後形成程序代碼。測試階段是在代碼編寫完成以後，先從單元測試開始，然後是集成測試、系統測試和驗收測試。
單元測試對應詳細設計，也就是說，單元測試用例和詳細設計文檔一起實現；而集成測試對應於概要設計，其測試用例是根據概要設計中模塊功能及接口等實現方法編寫。依次類推，測試計劃在軟件需求完成後就開始進行，完成系統測試用例的設計等。 V模型存在如下一些侷限性：它僅把測試過程作爲在需求分析、概要設計、詳細設計及編碼之後的一個階段，主要針對程序進行尋找錯誤的活動，而忽視了測試活動對需求分析、系統設計等活動的驗證和確認的功能。
2.5.2 W模型
相對於V模型而言，W模型增加了軟件各開發階段中應同步進行的驗證和確認(V&V)活動。如圖2.3所示，W模型由兩個V字型模型組成，分別代表測試與開發過程，明確表示出了測試與開發的並行關係。
W模型強調，測試伴隨着整個軟件開發週期，測試的對象不僅僅是程序，需求、設計等同樣要測試，也就是說，測試與開發同步進行。W模型有利於儘早地發現問題，只要相應的開發活動完成，就可以開始測試。例如，需求分析完成後，測試就應該參與到對需求的驗證和確認活動中，以儘早地找出缺陷所在。同時，對需求的測試也有利於及時瞭解項目難度和測試風險，及早制定應對措施，從而減少總體測試時間，加快項目進度。 W模型也存在侷限性。在W模型中，需求、設計、編碼等活動被視爲串行，測試和開發活動保持着一種線性的前後關係，上一階段結束，纔開始下一個階段工作，因此，W模型無法支持迭代開發模型。
2.5.3 H模型
V模型和W模型都認爲軟件開發是需求、設計、編碼等一系列串行的活動，而事實上，這些活動在大部分時間內可以交叉。因此，相應的測試也不存在嚴格的次序關係，單元測試、集成測試、系統測試之間具有反覆迭代。正因爲V模型和W模型存在這樣的問題，H模型將測試活動完全獨立出來，使得測試準備活動和測試執行活動清晰地體現出來。 圖2.4僅僅顯示了整個測試生命週期中某個層次的“微循環”。H模型揭示了軟件測試作爲一個獨立的流程貫穿於軟件整個生命週期，與其它流程併發地進行，並指出軟件測試要儘早準備，儘早執行。不同的測試活動可以按照某個次序先後進行，也可能是反覆的，只要某個測試達到準備就緒點，測試執行活動就可以開展。
2.5.4 X模型
由於V模型沒能體現出測試設計、測試回溯的過程，因此出現了X測試模型。 如圖2.5所示，X模型的左邊描述的是針對單獨程序片段所進行的編碼和測試，此後將進行頻繁的交接，通過集成最終合成爲可執行的程序。X模型右上方定位了已通過集成測試的成品進行封版並提交給用戶，也可以作爲更大規模和範圍內集成的一部分。多根並行的曲線表示變更可以在各個部分發生。X模型右下方定位了探索性測試。這是不進行事先計劃的特殊類型的測試，往往幫助有經驗的測試人員在測試計劃之外發現軟件錯誤。
2.5.5 前置模型
前置模型將測試和開發緊密結合，具有如下的優點。
(1) 開發和測試相結合。前置測試模型將開發和測試的生命週期整合在一起，標識了項目生命週期從開始到結束之間的關鍵行爲，表示這些行爲在項目週期中的價值。 前置測試在開發階段以“編碼→測試→編碼→測試”的方式進行。也就是說，程序片段編寫完成後會進行測試。
(2) 對每一個交付內容進行測試。每一個交付的開發結果都必須通過一定的方式進行測試。源程序代碼並不是唯一需要測試的內容。可行性報告、業務需求說明以及系統設計文檔等也是被測試的對象。這同V模型中開發和測試的對應關係相一致，並且在其基礎上有所擴展。
(3) 讓驗收測試和技術測試保持相互獨立。驗收測試應該獨立於技術測試，這樣可以提供雙重的保險，以保證設計及程序編碼能夠符合最終用戶的需求。驗收測試既可以在實施階段的第一步來執行，也可以在開發階段的最後一步執行。
(4) 反覆交替的開發和測試。項目開發中存在很多變更，例如需要重新訪問前一階段的內容，或者跟蹤並糾正以前提交的內容，修復錯誤，增加新發現的功能等。開發和測試需要一起反覆交替地執行。
(5) 引入新的測試理念。前置測試對軟件測試進行優先級劃分，用較低的成本及早發現錯誤，並且充分強調了測試對確保系統高質量的重要意義。
2.6 測試用例
2.6.1 測試用例的基本概念
測試用例作爲測試工作的指導，是軟件測試必須遵守的準則，是軟件測試質量穩定的根本保障。測試用例(Test Case)目前沒有經典的定義。簡單地說，測試用例就是設計一個情況，軟件程序在這種情況下，必須能夠正常運行並且達到程序所設計的執行結果。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略，內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並形成文檔。
測試用例是將軟件測試的行爲活動做了一個科學化的組織歸納，目的是將軟件測試的行爲轉化成可管理的模式，同時測試用例也是將測試具體量化的方法之一。
測試用例的重要性體現在以下幾方面。
(1) 測試用例構成了設計和制定測試過程的基礎。
(2) 測試的“深度”與測試用例的數量成比例，這是由於每個測試用例反映不同的場景、條件或經由產品的事件流。
(3) 測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。
(4) 測試設計和開發的類型以及所需的資源主要受控於測試用例。
(5) 測試用例通常根據它們所關聯的測試類型或測試需求來分類，而且將隨類型和需求進行相應的改變。
測試用例主要有如下幾種分類。
(1) 功能測試用例：包含功能測試、健壯性測試和可靠性測試。
(2) 性能測試用例：包含性能測試、壓力測試和強度測試。
(3) 集成測試用例：包含接口測試、健壯性測試和可靠性測試。
(4) 安全測試用例。
(5) 用戶界面測試用例及少量功能測試用例。
(6) 安裝/反安裝測試用例。
測試種類、階段和用例的關係如表2.3所示。
2.6.2 測試用例的編寫
編寫測試用例文檔應有文檔模板，須符合內部的規範要求。測試用例文檔將受制於測試用例管理軟件的約束。 測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試範圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體測試用例都將包括下列詳細信息：用例編號、用例名稱、測試等級、入口準則、驗證步驟、期望結果(含判斷標準)、出口準則、註釋等。以上內容涵蓋了測試用例的基本元素：測試索引、測試環境、測試輸入、測試操作、預期結果、評價標準。表2.4所示是一個典型的測試用例文檔。
測試用例可根據基本事件、備選事件和異常事件設計相關的用例。設計基本事件的用例，應該參照用例規約(或設計規格說明書)，根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例。基本事件的測試用例應包含所有需要實現的需求功能，覆蓋率達100%。
設計備選事件和異常事件的用例，則要複雜許多。
2.6.3 測試用例的作用
1．指導測試的實施
測試用例主要適用於集成測試、系統測試和迴歸測試。在實施測試時測試用例作爲測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試，並將測試情況記錄在測試用例管理軟件中，以便自動生成測試結果文檔。
根據測試用例的測試等級，集成測試應測試哪些用例，系統測試和迴歸測試又該測試哪些用例，在設計測試用例時都已作明確規定，實施測試時測試人員不能隨意作變動。
2．規劃測試數據的準備
按照測試用例配套準備一組或若干組測試原始數據，以及標準測試結果。尤其像測試報表之類數據集的正確性，按照測試用例規劃準備測試數據是十分必要的。 除正常數據之外，還必須根據測試用例設計大量邊緣數據和錯誤數據。
3．編寫測試腳本的“設計規格說明書”
爲提高測試效率，軟件測試已大力發展自動測試。自動測試的中心任務是編寫測試腳本。如果說軟件工程中軟件編程必須有設計規格說明書，那麼測試腳本的設計規格說明書就是測試用例。
4．評估測試結果的度量基準
完成測試實施後需要對測試結果進行評估，並且編制測試報告。判斷軟件測試是否完成、衡量測試質量需要一些量化的結果。例如：測試覆蓋率是多少，測試合格率是多少，重要測試合格率是多少，等等。
5．分析缺陷的標準
通過收集缺陷，對比測試用例和缺陷數據庫，分析確認是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟件質量的目的。而已有相應測試用例，則反映實施測試或變更處理存在問題。
2.6.4 相關問題
1．測試用例的評審
測試用例是軟件測試的準則，但它並不是一經編制完成就成爲準則。測試用例在設計編制過程中要組織同級互查。完成編制後應組織專家評審，需獲得通過纔可以使用。評審委員會可由項目負責人、測試、編程、分析設計等有關人員組成，也可邀請客戶代表參加。
2．測試用例的修改更新
測試用例在形成文檔後還需要不斷完善。主要來自三方面的緣故：第一，在測試過程中發現設計測試用例時考慮不周，需要完善；第二，在軟件交付使用後反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成的；第三，軟件自身新增功能以及軟件版本的更新，測試用例也必須配套修改更新。 一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。如果軟件的版本升級更新，則測試用例一般也應隨之編制升級更新版本。
3．測試用例的管理軟件
運用測試用例還需配備測試用例管理軟件。它的主要功能有三個：第一，能將測試用例文檔的關鍵內容，如編號、名稱等自動導入管理數據庫，形成與測試用例文檔完全對應的記錄；第二，可供測試實施時及時輸入測試情況；第三，最終實現自動生成測試結果文檔，包含各測試度量值、測試覆蓋表及測試通過或不通過的測試用例清單列表。
2.7 思考與習題
一、選擇題
1. 軟件測試按照測試技術劃分爲( C )。
A. 性能測試、負載測試、壓力測試
B. 恢復測試、安全測試、兼容測試
C. A與B都是
D. 單元測試、集成測試、驗收測試
2. 軟件測試的目的是( C )。
A. 避免軟件開發中出現錯誤
B. 發現軟件開發中出現的錯誤
C. 儘可能發現並排除軟件中潛藏的錯誤，提高軟件的可靠性
D. 修改軟件中出現的錯誤
3. 各個地方對軟件測試定義不同，請你根據軟件測試方面、理論方面、代碼的角度測試填空。
代碼方面分爲：( A )、集成測試、系統測試、驗收測試。
理論方面分爲：( C )、動態測試、靜態測試
測試方面分爲：( B )、壓力測試、迴歸測試、負載測試、恢復測試、安全性測試、兼容性測試、內存泄露測試、比較測試等。
A. 單元測試 B. 黑盒測試 C. 白盒測試 D. 負載測試
二、判斷題
(1) Beta測試是驗收測試的一種。( √ )
(2) 儘量用公共過程或子程序去代替重複的代碼段。( √ )
(3) 測試是爲了驗證該軟件是否已正確地實現了用戶的要求。( × )
(4) 對於連鎖型分支結構，若有n個判定語句，則有2n條路徑。( × )
(5) 儘量採用複合的條件測試，以避免嵌套的分支結構。( √ )
(6) GOTO語句概念簡單，使用方便，在某些情況下，保留GOTO語句反能使寫出的程序更加簡潔。( √ )
(7) 發現錯誤多的程序模塊，殘留在模塊中的錯誤也多。( √ )
(8)黑盒測試方法中最有效的是因果圖法。( × )
(9)在做程序的單元測試時，樁(存根)模塊比驅動模塊容易編寫。( × )
(10)程序效率的提高主要應通過選擇高效的算法來實現。( √ )
三、簡答題
1. 軟件測試的目的是什麼？
答:軟件測試的目的有:
①軟件測試是爲了發現錯誤而執行程序的過程。
②一個好的測試用例能夠發現至今尚未發現的錯誤。
③一個成功的測試是發現了至今尚未發現的錯誤。
2. 軟件測試中應注意哪些事項？
答:軟件測試應注意以下事項:
1.應當把“儘早和不斷地測試”作爲開發者的座右銘。
2.程序員應該避免檢查自己的程序，測試工作應該由獨立的專業的軟件測試機構來完成。
3.設計測試用例時， 應該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下要製造極端狀態和意外狀態，比 如網絡異常中斷、電源斷電等情況。
4.一定要注意測試中的錯誤集中發生現象，這和程序員的編程水平和習慣有很大的關係。
5.對測試錯誤結果一定要有一個確認的過程。- - 般有A 測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。
6.制定 嚴格的測試計劃，並把測試時間安排得儘量寬鬆，不要希望在極短的時間內完成一一個高水平的測試。
7.迴歸測試的關聯性一 定要引起充分的注意，修改-一個錯誤而引起更多錯誤出現的現象並不少見。
8.妥善保存- -切測試過程文檔，意義是不言而喻的，測試的重現性往往要靠測試文檔。
3. 按執行主體劃分，軟件測試分哪幾類？
答:哪找測試實施組織劃分，軟件測試分爲a 測試，β 測試和第三方測試。
4. V模型和W模型各自的優缺點是什麼？
答: V模型:
優點是:如此簡單的模型適合工程量小、人力投入 也少的情況。而且項目的改動不大，風險不高的情況。
缺點:在實際中能用上V 模型的項目很少。錯誤也發現得遲。採用V模型的而產生的風險費用很高
W模型:
優點:能在前期發現需求錯誤，在測試過程中也有利於及時瞭解項目難度。適合做中型軟件。
缺點: W模型繼承V模型而來，仍要求項目需求不能有大變動，否則前期準備很容易白費。也不適合 於大型的項目，大型項 目不能一-開始就有完整的需求，而且風險大而造成需求變動大。人力上也要求有專門測試的人員。
5. 測試用例是什麼？
答:測試用例是指對一-項特定的軟件產品進行測試任務的描述，體現在測試方案，方法，技術，策略等。測試用例的內容包括測試目標，測試環境，輸入數據，測試步驟，預期結果，測試腳本等，並形成文檔。
測試用例的屬性:
1.測試用例具有優先性。
2.測試用例具有目標性。
3.測試用例具有範圍性。
4.測試用例具有關聯性。
5.測試用例具有階段性。
6.測試用例具有狀態性。
7.測試用例具有代表性。
8.測試用例具有時效性。