《《軟件測試技術》知識點整理》由會員分享，可在線閱讀，更多相關《《軟件測試技術》知識點整理（14頁珍藏版）》請在裝配圖網上搜索。

一、軟件測試的定義 軟件測試是一個過程或一系列過程，用來確認計算機代碼完成了其應該完成的功能，不執(zhí)行其不該有的操作。 1．軟件測試與調試的區(qū)別？ （1）測試是為了發(fā)現(xiàn)軟件中存在的錯誤；調試是為證明軟件開發(fā)的正確性。 （2）測試以已知條件開始，使用預先定義的程序，且有預知的結果，不可預見的僅是程序是否通過測試；調試一般是以不可知的內部條件開始，除統(tǒng)計性調試外，結果是不可預見的。 （3）測試是有計劃的，需要進行測試設計；調試是不受時間約束的。 （4）測試經歷發(fā)現(xiàn)錯誤、改正錯誤、重新測試的過程；調試是一個推理過程。 （5） 測試的執(zhí)行是有規(guī)程的；調試的執(zhí)行往往要求開發(fā)人員進行必要推理以至知覺的"飛躍"。 （6） 測試經常是由獨立的測試組在不了解軟件設計的條件下完成的；調試必須由了解詳細設計的開發(fā)人員完成。 （7） 大多數(shù)測試的執(zhí)行和設計可以由工具支持；調式時，開發(fā)人員能利用的工具主要是調試器。 2．對軟件測試的理解？ 軟件測試就是說要去根據(jù)客戶的要求完善它.即要把這個軟件還沒有符合的或者是和客戶要求不一樣的，或者是客戶要求還沒有完全達到要求的部分找出來。 （1）首先要鍛煉自己軟件測試能力，包括需求的分析能力，提取能力，邏輯化思想能力，即就是給你一個系統(tǒng)的時候，能夠把整個業(yè)務流程很清晰的理出。 （2）學習測試理論知識并與你鍛煉的能力相結合。 （3）想和做。想就是說你看到任何的系統(tǒng)都要有習慣性的思考；做就是把實際去做練習，然后提取經驗。 總結測試用例，測試計劃固然重要，但能力和思想一旦到位了，才能成為一名合格的軟件測試工程師。 二、軟件測試的分類 1．按照測試技術劃分 （1）白盒測試：通過對程序內部結構的分析、檢測來尋找問題。檢查是否所有的結構及邏輯都是正確的，檢查軟件內部動作是否按照設計說明的規(guī)定正常進行。--結構測試 （2）黑盒測試：通過軟件的外部表現(xiàn)來發(fā)現(xiàn)錯誤，是在程序界面處進行測試，只是檢查是否按照需求規(guī)格說明書的規(guī)定正常實現(xiàn)。--性能測試 （3）灰盒測試：介于白盒測試與黑盒測試之間的測試。 2．按照是否讓備測軟件運行劃分 （1）靜態(tài)測試 （2）動態(tài)測試 3．按照開發(fā)階段劃分 （1）單元測試：模塊測試，檢查每個程序單元嫩否正確實現(xiàn)詳細設計說明中的模塊功能等。 （2）集成測試：組裝測試，將所有的程序模塊進行有序、遞增的測試，檢驗程序單元或部件的接口關系 （3）系統(tǒng)測試：檢查完整的程序系統(tǒng)能否和系統(tǒng)（包括硬件、外設和網絡、系統(tǒng)軟件、支持平臺等）正確配置、連接，并滿足用戶需求。 （4）確認測試：證實軟件是否滿足特定于其用途的需求，是否滿足軟件需求說明書的規(guī)定。 （5）驗收測試：按項目任務或合同，供需雙方簽訂的驗收依據(jù)文檔進行的對整個系統(tǒng)的測試與評審，決定是否接受或拒收系統(tǒng)。 4．按照測試實施組織劃分 （1）開發(fā)方測試 （2）用戶測試 （3）第三方測試 三、軟件測試的原則 1．測試用例中一個必需部分是對預期輸出或結果的定義； 2．程序員應當避免測試自己編寫的程序； 3．編寫軟件的組織不應當測試自己編寫的程序； 4．應該徹底檢查每個測試的執(zhí)行結果； 5．測試用例的編寫不僅應當根據(jù)有效和預期的輸入情況，也應當根據(jù)無效和未預料到的輸入情況； 6．檢查程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了不應該做的”； 7．應避免測試用例用后既棄，除非軟件本身就是一個一次性的軟件； 8．計劃測試工作時不應默許假定不會發(fā)現(xiàn)錯誤； 9．程序某部分存在更多錯誤的可能性，與該部分已發(fā)現(xiàn)錯誤的數(shù)量成正比； 10．軟件測試是一項極富創(chuàng)造性、極具智力挑戰(zhàn)性的工作。 四、測試用例的設計 1．測試用例的定義 （1）測試用例是為特定的目的而設計的一組測試輸入、執(zhí)行條件和預期的結果。 （2）測試用例是執(zhí)行的最小實體。 2．特征： （1）最有可能抓住錯誤的； （2）不是重復的、多余的； （3）一組相似測試用例中最有效的； （4）既不是太簡單，也不是太復雜。 3．設計測試用例的基本準則 測試用例的代表性、測試結果的可判定性、測試結果的可再現(xiàn)性。 五、黑盒測試 1．等價類劃分法 ①等價類劃分法的設計方法：是把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分（子集），然后從每一個子集中選取少量具有代表性的數(shù)據(jù)作為測試用例。 等價類是指某個輸入域的子集合。在該子集合中各個輸入數(shù)據(jù)對于揭露程序中錯誤都是等效的。并合理地假定：測試某等價類的代表值就等于對這一類其他值的測試。 有效等價類：對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構成的集合 無效等價類：對軟件規(guī)格說明而言，是無意義的、不合理的輸入數(shù)據(jù)所構成的集合 等價類對于測試有兩個重要的意義：完備性 無冗余性 ②等價類劃分法的原則 （a）按照區(qū)間劃分： 一個有效等價類和兩個無效等價類。 （b）按照數(shù)值劃分： n 個有效等價類和一個無效等價類 （c）按照數(shù)值集合劃分 一個有效等價類和一個無效等價類 （d）按照限制條件或規(guī)則劃分：可確定一個有效等價類和若干個無效等價類 （e）細分等價類 ③等價類劃分法的步驟 （a）確定等價類 （b）建立等價類表，列出所有劃分出的等價類 （c）從劃分出的等價類中按以下的3個原則設計測試用例： 為每一個等價類規(guī)定一個唯一的編號 設計一個新的測試用例，使其盡可能多的覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止； 設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。 ④確定等價類的方法 （a）先考慮輸入數(shù)據(jù)的類型（合法型和非法型）； （b）再考慮數(shù)據(jù)范圍（合法型中的合法區(qū)間和非法區(qū)間）； （c）最后考慮輸出結果，逆向設定輸入。 2．邊界值分析法 ①邊界值分析法就是對輸入或輸出的邊界值進行測試 ②特點：具有很強的發(fā)現(xiàn)程序錯誤的能力；測試用例來自等價類的邊界； ③基本原理：故障往往發(fā)生在輸入定義域和輸出值域的邊界上，而不是在其內部。 ④方法：（a）首先應確定邊界情況. （b）選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù) ⑤標準邊界值： min、min+、nom、max-、max 健壯邊界值： min、min+、nom、max-、max min- max+ ⑥例： ⑦對于一個含有n個變量的程序，只讓其中一個變量取極值，讓其余的變量取正常值，被保留的變量依次取min、min+、nom、max-、max值，對每個變量都重復進行。n個變量的程序，邊界值分析測試程序會產生4n+1個測試用例。 3．決策表法 ①概述：決策表法是黑盒測試方法中最為嚴格、最具有邏輯性的測試方法。 ②什么時候使用？ 程序輸入輸出比較多，輸入之間、輸出之間相互制約的條件比較多時，可以清楚地表達它們之間的各種復雜關系。 條件樁 條件項 動作樁 動作項 ③決策表通常由四部分組成： 規(guī)則 條件樁： 列出問題的所有條件 條件項：針對條件樁給出的條件列出所有可能的取值 動作樁：給出問題規(guī)定的可能采取的操作 動作項：與條件項緊密相關，指出在條件項的各組取值情況下應采取的動作 規(guī)則：項中的每一列是一條規(guī)則，每一條規(guī)則是一組測試用例。 ④決策表的化簡 （a）合并：如果一個條件項(表中某列中的條件值)和另外一個條件項所產生的動作是相同的,且兩個條件項對應的每一行的值只有一個是不同的,則可以將其合并.合并的項除了不同值變成”不關心”條目外,其余不變 （b）包含：如果兩個條件項的動作是相同的，對任意條件1的值和條件2中對應的值，如果滿足： – 如果條件1的值是T(F),則條件2中的值也是T(F). – 如果條件1的值是-(不關心),則條件2中的值是T,F,-,稱條件1包含條件2,條件2可以撤去. – 重復A,B就可以得到精簡的決策表. N Y N N Y Y √ √ － N Y √ N N N － Y Y √ √ N － Y √ 合并 包含 ⑤構造決策表的步驟： （a）確定規(guī)則的個數(shù)； （b）列出所有的條件樁和動作樁； （c）填入輸入項； （d）填入動作項,得到初始的決策表； （e）對初始的決策表化簡。 ⑥決策表測試法的適用范圍 （a）if-then-else邏輯突出； （b）輸入變量之間存在邏輯關系； （c）涉及輸入變量子集的計算； （d）輸入和輸出之間存在因果關系。 4．因果圖方法 ①概述：如果輸入之間有關系，測試時必須考慮輸入條件的各種組合，考慮適合于描述對于多種條件的組合，相應產生多個動作的形式來設計測試用例，這就需要利用因果圖。 因果圖方法最終生成的就是判定表。適合于檢查程序輸入條件的各種組合情況。 ②因果圖法的基本思想： 首先從程序規(guī)格說明書的描述中,找出因(輸入條件)和果(輸出結果或者程序狀態(tài)的改變),然后通過因果圖轉換為判定表,最后為判定表中的每一列設計一個測試用例. ③基本符號 原因 結果 通常在因果圖中用Ci表示原因，用Ei表示結果，各結點表示狀態(tài)，可取值“0”或“1”?！?”表示某狀態(tài)不出現(xiàn)，“1”表示某狀態(tài)出現(xiàn)。 C2 c1 恒等： c1為1,則e1也為1,否則e1為0. 非： 若c1是1,則e1為0,否則e1是1. 或： 若c1或c2或c3是1,則e1是1,若三者都不為1,則e1為0. 與： 若c1和c2都是1,則e1為1,否則若有其中一個不為1,則e1為0. ④約束：實際問題中,輸入狀態(tài)之間可能存在某些依賴關系. E約束(異)： a,b最多有一個可能為1,不能同時為1. I約束(或)： a,b,c中至少有一個必須為1,不能同時為0. O約束(惟一)： a和b必須有一個且僅有一個為1 R約束(要求)：a是1時,b必須是1,即a為1時,b不能為0 M約束：對輸出條件的約束,若結果a為1,則結果b必須為0. ⑤因果圖生成測試用例的基本步驟 （a）找出原因和結果。（b）畫出因果圖。 （c）增加約束。 （d）把因果圖轉化為判定表，并化簡。 （e）把判定表的每一列拿出來作為依據(jù)，設計測試用例。 ⑥例題 （a）原因： C1：第一個字符是A； C2：第一個字符是B；C3：第二個字符是一個數(shù)字字找。 結果： E1：給出信息L； E2：修改文件； E3：給出信息M。 （b）因果圖。 （c）決策表。 1 2 3 4 5 6 7 8 C1 C2 C3 10 1 1 1 1 1 0 1 0 1 1 1 0 0 1 0 1 1 1 0 1 0 1 0 0 1 0 0 0 0 0 E1 E2 E3 不可能 √ √ √ √ √ √ √ √ √ 測試用例 A3 A5 AM A& B3 B5 BM B* C2 X6 CM D* （d）設計測試用例 測試用例1： 輸入數(shù)據(jù)：A3 預期輸出：修改文件 測試用例2： 輸入數(shù)據(jù)：AM 預期輸出：給出信息M 測試用例3： 輸入數(shù)據(jù)：B3 預期輸出：修改文件 測試用例4： 輸入數(shù)據(jù)：B* 預期輸出：給出信息M 測試用例5： 輸入數(shù)據(jù)：C2 預期輸出：給出信息L 測試用例6： 輸入數(shù)據(jù)：CM 預期輸出：給出信息LM ⑦因果圖法的優(yōu)點： （a）考慮了多個輸入之間的相互組合、相互制約關系； （b）能夠幫助我們按一定步驟，高效率地選擇測試用例，同時還能為我們指出，程序規(guī)格說明描述中存在著什么問題。 六、白盒測試 1．白盒測試概述：白盒測試也稱結構測試或邏輯驅動測試。 2．方法：程序結構分析；邏輯覆蓋測試；基本路徑測試。 3．原則： （1）保證一個模塊中所有獨立路徑至少被測試一次； （2）所有邏輯值均需測試真（True）和假（False）兩種情況； （3）檢查程序的內部數(shù)據(jù)結構，保證其結構的有效性； （4）在取值上、下邊界，即可操作范圍內運行所有循環(huán). 4．邏輯覆蓋測試:主要是測試覆蓋率，以程序內在邏輯結構為基礎的測試。 6種：語句覆蓋 判斷覆蓋 條件覆蓋 判定-條件覆蓋 條件組合覆蓋 路徑測試. ①語句覆蓋：在測試時，首先設計若干個測試用例，然后運行被測程序，使程序中的每個可執(zhí)行語句至少執(zhí)行一次 。 判定：整體 控制。 包括：a、單一條件判定； b、符合條件覆蓋 語句覆蓋率：已執(zhí)行的可執(zhí)行語句占程序中可執(zhí)行語句總數(shù)的百分比 ②判定覆蓋：設計足夠多的測試用例，使程序中的每個判定至少都獲得一次“真值”或“假值”。 ③條件覆蓋:構造一組測試用例，使得每一判定語句中每個邏輯條件的可能值至少滿足一次。 滿足條件覆蓋的不一定滿足判定覆蓋，反之亦然。兩者無直接關系。 ④判定/條件覆蓋：設計足夠的測試用例，使得判定中每個條件的所有可能(真/假)至少出現(xiàn)一次，并且每個判定本身的判定結果(真/假)也至少出現(xiàn)一次 ⑤組合條件覆蓋（MCC）：設計足夠的測試用例，使得每個判定中條件的各種可能組合都至少出現(xiàn)一次。 滿足組合條件覆蓋的測試用例是一定滿足判定覆蓋、條件覆蓋和判定/條件覆蓋。 ⑥修正條件判定覆蓋(MCDC)：需要足夠的測試用例來確定各個條件能夠影響到包含的判定的結果，即要求滿足兩個條件。 七、靜態(tài)測試 1．靜態(tài)測試不實際運行軟件，主要對軟件的編程格式、結構等方面進行評估?？梢杂腥斯みM行，也可借助軟件工具自動進行。 2．靜態(tài)測試的方法 （1）代碼檢查：代碼審查 代碼走查 桌面檢查 同行評分（略） （2）代碼審查：通常由4人組成，其中一人是協(xié)調人，一人是程序的編寫者，其他人員通常是程序的設計人員以及測試專家。 優(yōu)點和作用：錯誤列表、高效、會后修正、增加修改錯誤清單、較早發(fā)現(xiàn)錯誤。 （3）代碼走查：為測試員的人會帶著一些書面的測試用例參加會議 （4）桌面檢查：（a）完全沒有約束（b）開發(fā)人員測試自己的程序（c）沒有展示自己能力，缺乏良好的效應。（效果遠遠遜于代碼審查和代碼走查） 3．靜態(tài)結構分析：主要是以圖形的方式表現(xiàn)程序的內部結構。 4．代碼質量度量：功能性 可靠性 可用性 |有效性 可維護性 輕便性 八、單元測試 1．單元測試的定義 單元測試又稱模塊測試，是最小單位的測試，其依據(jù)是詳細設描述，對模塊內所有重要的控制路徑設計測試用例，以便發(fā)現(xiàn)模塊內部的錯誤。 單元測試多采用白盒測試技術 2．單元測試的對象 結構化程序，單元測試的單元是指單個子程序、函數(shù)或過程 面向對象程序，單元測試的單元是指類或方法（通常為類）。 3．單元測試的目的 將模塊的功能與定義模塊的功能規(guī)格說明或接口規(guī)格說明進行比較，揭示出模塊與其規(guī)格說明之間存在的矛盾。 4．單元測試的人員:開發(fā)人員 5．單元測試的針對的問題 （1）模塊接口: 檢查進出程序單元的數(shù)據(jù)流是否正確。 （2）局部數(shù)據(jù)結構: 必須測試模塊內部的數(shù)據(jù)能否保持完整性。 （3）邊界條件測試：主要檢查臨界數(shù)據(jù)是否正確處理。 （4）獨立路徑測試：發(fā)現(xiàn)由于不正確的判定或不正常的控制流而產生的錯誤。 （5）出錯處理：要求能預見出錯的條件，并設置適當?shù)奶幚韺ο?，保證其路徑的正確性。 6．單元測試的流程 計劃單元測試設計單元測試執(zhí)行單元測試評估單元測試 7. 計劃單元測試 （1）驅動模塊(Drive)：用來模擬被測試模塊的上一級模塊，相當于被測模塊的主程序。它接收數(shù)據(jù)，將相關數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并打印出相應的結果。 （2）樁模塊(Stub)：用來模擬被測模塊工作過程中所調用的模塊。它們一般只進行很少的數(shù)據(jù)處理。 8．設計單元測試 （1）需要的信息 模塊的規(guī)格說明：模塊的輸入和輸出以及模塊的功能。 模塊的源代碼。 （2）測試用例的設計方法 模塊測試總體上是面向白盒測試的（靜態(tài)、動態(tài)） 后續(xù)測試針對較大的元素不易進行白盒測試。 后續(xù)測試著眼于發(fā)現(xiàn)其他類型的錯誤，不一定與程序邏輯結構有關。 使用一種或多種白盒測試方法分析模塊的邏輯結構，然后使用黑盒測試方法對照模塊的規(guī)格說明補充測試用例。 9.執(zhí)行單元測試 （1）設置測試環(huán)境 （2）將測試環(huán)境初始化 （3）執(zhí)行測試過程。 10.評估單元測試 （1）測試完備性評估 （2) 代碼覆蓋率評估 九、集成測試 1．集成測試的定義 集成測試又稱組裝測試，集成測試是在單元測試的基礎上，將所有模塊按照設計要求組裝成子系統(tǒng)或系統(tǒng)進行的測試活動。 2．集成測試的目的 確保各單元組合在一起后能夠按既定意圖協(xié)作運行，并確保增量的行為正確，所測試的內容包括單元間的接口以及集成后的功能。 3．集成測試的層次 （1）模塊內集成測試 （2）子系統(tǒng)內集成測試 （3）子系統(tǒng)間集成測試 4．集成測試的流程 5．集成測試的方法 （1）靜態(tài)測試：只要指對概要設計的測試。 （2）動態(tài)測試：以黑盒測試為主，需要了解內部細節(jié)時結合白盒測試 6．集成測試策略 （1）非增量式集成：對所有模塊進行個別的單元測試后，按照程序結構圖將各模塊連接起來，把連接后的程序當作一個整體進行測試。 關鍵模塊的特征： ①滿足某些軟件需求； ②在程序的模塊結構中位于較高的層次（高層控制模塊）； ③較復雜、較易發(fā)生錯誤； ④有明確定義的性能要求。 （2）增量式集成：逐次將未曾集成測試的模塊和已經集成測試的模塊（或子系統(tǒng)）結合成程序包，再將這些模塊集成為較大系統(tǒng)，在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產生的問題。 方法： ① 自頂向下增量式測試：深度優(yōu)先、廣度優(yōu)先。 ② 自底向上增量式測試 ③混合增量式測試 7．不同集成測試方法的比較 十、系統(tǒng)測試 1． 系統(tǒng)測試的目的 將系統(tǒng)或程序與其初始目標進行比較，這意味著系統(tǒng)測試并不局限于系統(tǒng)，系統(tǒng)測試是一個試圖說明程序作為一個整體是如何不滿足其目標的過程。如果產品沒有一組書面的、可度量的目標，系統(tǒng)測試也無法進行。 2． 系統(tǒng)測試的類型 能力測試，容量測試，強度測試，易用性測試，安全性測試，性能測試，存儲測試，配置測試，兼容性/配置/轉換測試，安裝測試，可靠性測試，可恢復性測試，適用性測試，文檔測試，過程測試 （1）能力測試 判斷目標文檔提及的每一項能力（以區(qū)別功能測試中的‘功能’）是否都確實已經實現(xiàn)。 通常是通過人工檢查目標文檔中定義了“要做什么” 。 （2）容量測試 是程序經受大容量數(shù)據(jù)的檢驗，目的是證明程序不能處理目標文檔中規(guī)定的數(shù)據(jù)容量。 容量測試需要大量的資源，不可進行過多。 如何使操作系統(tǒng)的作業(yè)隊列達到飽和容量。 （3）強度測試 使程序承受高負載或強度的檢驗。所謂高強度是指在很短的時間間隔內達到的數(shù)據(jù)或操作的數(shù)量峰值。（要與容量測試相區(qū)分） 強度測試涉及時間因素，適用于在可變負載下運行的程序以及交互式程序、實時程序和過程控制程序。基于Web的應用程序也是最常接受強度測試的軟件之一。 如，1.在很短的時間內是操作系統(tǒng)的作業(yè)隊列達到峰值; 2.web應用程序要處理一定容量的并發(fā)用戶。 注：強度測試是對強度的界定很重要。 （4）易用性測試 每個用戶界面是否都根據(jù)用戶的智力、教育程度和環(huán)境要求進行了調整？ 程序的輸出是否有意義、不模糊且無計算機雜亂信息？ 錯誤診斷信息是否直接，非計算機專業(yè)用戶是否能夠理解（這要求對錯誤進行精確的預測和詳細的分類）？ 整體的用戶界面是否在語法、慣例、語義、格式、風格和縮寫等方面展現(xiàn)出了相當程度的完整性、一致性和同一性？ 系統(tǒng)是否包含過多或不太可能用到的選項？ 對于所有輸入，系統(tǒng)是否返回了即時確認信息？ 程序是否易于使用？如區(qū)分大小寫的要求用戶是否清楚，不同層次菜單之間的瀏覽是否容易等。 （5）安全性測試 設計測試用例來突破程序安全檢查。例如，可以設計測試用例來規(guī)避操作系統(tǒng)的內存保護機制、破壞數(shù)據(jù)庫管理系統(tǒng)的數(shù)據(jù)安全機制等。 常用的測試用例設計方法是研究類似系統(tǒng)中已知的安全問題，然后生成測試用例，暴露被測系統(tǒng)中的類似問題 基于Web的應用程序常常比絕大多數(shù)程序所需的安全測試級別更高，對于電子商務網站尤其如此。 （6）性能測試 很多軟件都有特定的性能或效率目標，這些特性描述為在特定負載和配置環(huán)境下程序的響應時間和吞吐率。應設計測試用例來說明程序不能滿足其性能目標。 （7）存儲測試 軟件偶爾會有存儲目標，例如描述程序使用的內存和輔存的容量以及臨時文件或移出文件的大小。應設計測試用例來證明這些存儲目標沒有得到滿足。 （8）配置測試 很多軟件都支持多種硬件配置，可以運行在多種操作系統(tǒng)下，使用多種web瀏覽器。通?？赡艿呐渲脭?shù)量非常之大，以至于無法全面測試，但應該盡可能測試各種配置。 （9）兼容性/配置/轉換測試 很多軟件不是全新的，而是為了替換某些已有的系統(tǒng)。這樣的軟件往往涉及與已有系統(tǒng)的兼容以及從已有系統(tǒng)的轉換過程，如升級數(shù)據(jù)庫管理系統(tǒng)。 （10）安裝測試 有些軟件的安裝過程非常復雜，測試安裝過程是系統(tǒng)測試的一個重要部分。 （11）可靠性測試 所有測試都是為了提高軟件的可靠性，但如果軟件的目標中包含了對可靠性的特別描述，就必須設計專門的可靠性測試用例。 （12）適用性測試 對于軟件的適用性和可維護性目標也必須測試。 （13）可恢復性測試 諸如OS、DBMS等軟件通常都有可恢復性目標，說明系統(tǒng)如何從硬件失敗和數(shù)據(jù)錯誤中恢復過來。系統(tǒng)測試的一個目標是證明這些恢復機制不能正確發(fā)揮作用。 可以故意將程序錯誤植入個系統(tǒng)中，判斷系統(tǒng)是否可以從中恢復。 這些系統(tǒng)的設計目標之一是平均恢復時間（MTTR）最小，測試目標之一就是證明系統(tǒng)不能滿足MTTR的要求。 （13）文檔測試 系統(tǒng)測試也需要檢查用戶文檔的正確性和清晰性。 （14）過程測試 很多軟件系統(tǒng)不是完全自動化的，其中包括了很多人員操作過程。在系統(tǒng)測試中，必須對所有已規(guī)定的人工過程，如系統(tǒng)操作員、最終用戶、數(shù)據(jù)庫管理員的操作過程進行測試。 十一、驗收測試 是將程序與其最初的需求及最終用戶當前的需要進行比較的過程 通常是由程序的客戶或最終用戶來進行，一般不認為是軟件開發(fā)機構的職責 最好的方法是設計測試用例，盡力證明程序沒有滿足合同要求；假如這些測試用例都通過了，就可以接受該程序。