測試概述
無論怎樣強調軟件測試的重要性和它對軟件可靠性的影響都不過分。在開發大型軟件系統的漫長過程中，面對著極其錯綜復雜的問題，人的主觀認識不可能完全符合客觀現實，與工程密切相關的各類人員之間的通信和配合也不可能完美無缺，因此，在軟件生命周期的每個階段都不可避免地會產生差錯。我們力求在每個階段結束之前通過嚴格的技術審查，盡可能早地發現并糾正差錯；
經驗表明審查并不能發現所有差錯，此外在編碼過程中還不可避免地會引入新的錯誤。如果在軟件投入生產性運行之前，沒有發現并糾正軟件中的大部分差錯，則這些差錯遲早會在生產過程中暴露出來，那時不僅改正這些錯誤的代價更高，而且往往會造成很惡劣的后果。測試的目的就是在軟件投入生產性運行之前，盡可能多地發現軟件中的錯誤。
目前軟件測試仍然是保證軟件質量的關鍵步驟，它是對軟件規格說明、設計和編碼的最后復審。軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對它做必要的測試(稱為單元測試)，模塊的編寫者和測試者是同一個人，編碼和單元測試屬于軟件生命周期的同一個階段。在這個階段結束之后，對軟件系統還應該進行各種綜合測試，這是軟件生命周期中的另一個獨立的階段，通常由專門的測試人員承擔這項工作。
大量統計資料表明，軟件測試的工作量往往占軟件開發總工作量的40％以上，在極端情況，測試那種關系人的生命安全的軟件所花費的成本，可能相當于軟件工程其他開發步驟總成本的三倍到五倍。因此，必須高度重視軟件測試工作，絕不要以為寫出程序之后軟件開發工作就接近完成了，實際上，大約還有同樣多的開發工作量需要完成。僅就測試而言，它的目標是發現軟件中的錯誤，但是，發現錯誤并不是我們的最終日的。軟件工程的根本目標是開發出高質量的完全符合用戶需要的軟件。
1.測試目標
測試的目標或定義：
1）測試是為了發現程序中的錯誤而執行程序的過程；
2）好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案；
3）成功的測試是發現了至今為止尚未發現的錯誤的測試。
從上述規則可以看出，測試的正確定義是“為了發現程序中的錯誤而執行程序的過程”。這和某些人通常想象的“測試是為了表明程序是正確的”，“成功的測試是沒有發現錯誤的測試”等等是完全相反的。正確認識測試的目標是十分重要的，測試目標決定了測試方案的設計。如果為了表明程序是正確的而進行測試，就會設計一些不易暴露錯誤的測試方案；相反，如果測試是為了發現程序中的錯誤，就會力求設計出最能暴露錯誤的測試方案。
由于測試的目標是暴露程序中的錯誤，從心理學角度看，由程序的編寫者自己進行測試是不恰當的。因此，在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外，應該認識到測試決不能證明程序是正確的。即使經過了最嚴格的測試之后，仍然可能還有沒被發現的錯誤潛藏在程序中。測試只能查找出程序中的錯誤，不能證明程序中沒有錯誤。
2.測試策略
測試策略用于說明某項工作的測試方法與目標。系統測試策略主要針對系統測試需求確定測試類型及實施的測試方法與技術。測試策略一般包括下列內容：
要實施的測試類型與目標
確定系統測試策略首先要清楚地所實施系統測試的類型和測試目標。系統測試類型一般包括：
1）功能測試
2）性能測試
3）負載測試
4）強度測試
5）安全性測試
6）配置測試
7）故障恢復測試
8）文檔測試
9）用戶界面測試
其中，功能測試，配置測試，安裝測試在一般情況下是必需的，其它類型的測試可根據需求進行裁剪。
3測試計劃
根據測試的種類，測試計劃分為功能測試和性能測試計劃。測試計劃旨在說明各測試階段任務、人員分配、時間安排、測試要點、工作規范等。測試計劃在策略和方法方面說明如何計劃、組織和管理測試項目。測試計劃包含足夠的信息使測試人員明白項目需要做什么是如何運作的。測試計劃不包括測試用例的細節和系統功能的詳細信息。測試計劃應附有測試功能點矩陣、測試性能點矩陣。
測試計劃應在項目組內進行評審。參與測試計劃評審的人員包括：項目經理、測試組長、開發組長、測試組員。
4.測試用例
測試用例是為實施測試而向被測試系統提供的輸入數據、操作或各種環境設置以及期望結果的一個特定的集合。解決要測什么、怎么測和如何衡量的問題。
從測試結構上面劃分分為黑盒測試、和百盒測試2種，他們各自有不同的測試方式，目前本公司只考慮黑盒測試，以下設計方法以黑盒方法為例
第一條 測試用例設計方法
黑盒測試用例設計方法有等價類測試、邊界值分析、基于因果圖的測試、基于猜錯的測試、基于場景的測試、基于隨機的測試。其中常用的設計方法有等價類測試、邊界值分析、因果圖三種方法，以下分別介紹這幾種方法：
等價類劃分
等價類劃分是一種典型的黑盒測試方法。等價類是指某個輸入域的集合。它表示對揭露程序中的錯誤來說，集合中的每個輸入條件是等效的。因此我們只要在一個集合中選取一個測試數據即可。等價類劃分的辦法是把程序的輸入域劃分成若干等價類，然后從每個部分中選取少數代表性數據當作測試用例。這樣就可使用少數測試用例檢驗程序在一大類情況下的反映。
在考慮等價類時，應該注意區別以下兩種不同的情況：
有效等價類：有效等價類指的是對程序的規范是有意義的、合理的輸入數據所構成的集合。在具體問題中，有效等價類可以是一個，也可以是多個。
無效等價類：無效等價類指對程序的規范是不合理的或無意義的輸入數據所構成的集合。對于具體的問題，無效等價類至少應有一個，也可能有多個。
確定等價類有以下幾條原則：
如果輸入條件規定了取值范圍或值的個數，則可確定一個有效等價類和兩個無效等價類。例如，程序的規范中提到的輸入條包括“……項數可以從1到999……”，則可取有效等價類為“l考項數＜999”，無效等價類為“項數＜l，，及“項數＞999”。
輸入條件規定了輸入值的集合，或是規定了“必須如何”的條件，則可確定一個有效等價類和一個無效等價類。如某程序涉及標識符，其輸入條件規定“標識符應以字母開頭……”則“以字母開頭者”作為有效等價類，“以非字母開頭”作為無效等價類。
如果我們確知，已劃分的等價類中各元素在程序中的處理方式是不同的，則應將此等價類進一步劃分成更小等價類。
根據已列出的等價類表，按以下步驟確定測試用例：
為每個等價類規定一個唯一的編號；
設計一個測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復這一步，最后使得所有有效等價類均被測試用例所覆蓋；
設計一個新的測試用例，使其只覆蓋一個無效等價類。重復這一步，使所有無效等價類均被覆蓋。這里強調每次只覆蓋一個無效等價類。這是因為一個測試用例中如果含有多個缺陷，有可能在測試中只發現其中的一個，另一些被忽視。等價類劃分法能夠全面、系統地考慮黑盒測試的測試用例設計問題，但是沒有注意選用一些“高效的”、“有針對性的”測試用例。后面介紹的邊值分析法可以彌補這一缺點。
邊值分析法
邊值分析法是列出單元功能、輸入、狀態及控制的合法邊界值和非法邊界值，設計測試用例，包含全部邊界值的方法。典型地包括IF語句中的判別值，定義域、值域邊界，空或畸形輸入，末受控狀態等。邊值分析法不是一類找一個例子的方法，而是以邊界情況的處理作為主要目標專門設計測試用例的方法。另外，邊值分析不僅考查輸入的邊值，也要考慮輸出的邊值。這是從人們的經驗得出的一種有效方法。人們發現許多軟件錯誤只是在下標、數據結構和標量值的邊界值及其上、下出現，運行這個區域的測試用例發現錯誤的概率很高。
用邊值分析法設計測試用例時，有以下幾條原則：
如果輸入條件規定了取值范圍，或是規定了值的個數，則應以該范圍的邊界內及剛剛超出范圍的邊界外的值，或是分別對最大、最小及稍小于最小、稍大于最大個數作為測試用例。如有規范“某文件可包含l至255”個記錄……“，則測試用例可選1和255及0和256等。
針對規范的每個輸出條件使用原則
如果程序規范中提到的輸入或輸出域是個有序的集合(如順序文件、表格等)就應注意選取有序集的第一個和最后一個元素作為測試用例。
分析規范，盡可能找出可能的邊界條件。一個典型的邊值分析例子是三角形分類程序。選取a，b，c構成三角形三邊，“任意兩邊之和大于第三邊”為邊界條件。邊值分析相等價類劃分側重不同，對等價類劃分是一個補充。如上述三角形問題，選取a＝3，b＝4，c＝5，a＝2，b＝4，c＝7則覆蓋有效和無效等價類。如果能在等價類劃分中注入邊值分析的思想。在每個等價類中不只選取一個覆蓋用例，而是進而選取該等價類的邊界值等價類劃分法將更有效，最后可以用邊值分析法再補充一些測試用例。
因果圖
等價類劃分法并沒有考慮到輸入情況的各種組合。這樣雖然各個輸入條件單獨可能出錯的情況已經看到了，但多個輸入情況組合起來可能出錯的情況卻被忽略。采用因果圖方法能幫助我們按一定步驟選擇一組高效的測試用例，同時，還能為我們指出程序規范的描述中存在什么問題。
利用因果圖導出測試用例需要經過以下幾個步驟：
分析程序規范的描述中哪些是原因，哪些是結果。原因常常是輸入條件或是輸入條件的等價類。結果是輸出條件。
分析程序規范的描述中語義的內容，并將其表示成連接各個原因與各個結果的“因果圖”。
由于語法或環境的限制，有些原因和結果的組合情況是不可能出現的。為表明這些特定的情況，在因果圖上使用持殊的符號標明約束條件。把因果圖轉換成判定表。把判定表的每一列寫成一個測試用例。
猜錯法
猜錯法在很大程度上是憑經驗進行的，是憑人們對過去所作的測試工作結果的分析，對所揭示的缺陷的規律性作直覺的推測來發現缺陷的。
一個采用兩分法的檢索程序，典型地可以列出下面幾種測試情況：
被檢索的表只有一項或為空表；
表的項數恰好是2的冪次；
表的項數比2的冪次多1等。
猜錯法充分發揮人的經驗，在一個測試小組中集思廣益，方便實用，特別在軟件測試基礎較差的情況下，很好地組織測試小組 (也可以有外來人員)進行錯誤猜測，是有效的測試方法。
隨機數法
即測試用例的參數是隨機數。它可以自動生成，因此自動化程度高。使用大量隨機測試用例測試通過的程序會提高用戶對程序的信心。但其關鍵在于隨機數的規律是否符合使用實際。
