Ch6-集成測試與系統(tǒng)測試-STMT

1、Zhu.K朱少民朱少民Kerry Zhu軟件測試方法和技術(shù)軟件測試方法和技術(shù)第第2版版第第6章章 集成測試和系統(tǒng)測試集成測試和系統(tǒng)測試第5章 回顧Zhu.K 單元測試的定義與進(jìn)行單元測試的重要性單元測試的定義與進(jìn)行單元測試的重要性 單元測試的目標(biāo)與任務(wù)單元測試的目標(biāo)與任務(wù) 靜態(tài)測試技術(shù)的運(yùn)用靜態(tài)測試技術(shù)的運(yùn)用 動態(tài)測試技術(shù)的運(yùn)用動態(tài)測試技術(shù)的運(yùn)用 調(diào)試與評估調(diào)試與評估 單元測試的過程與文檔管理單元測試的過程與文檔管理 單元測試的常用工具簡介單元測試的常用工具簡介第第6章章 集成測試和系統(tǒng)測試集成測試和系統(tǒng)測試Zhu.K6.1 系統(tǒng)集成的模式與方法系統(tǒng)集成的模式與方法6.2 功能測試功能測試6.

2、3 回歸測試回歸測試6.4 非功能性測試非功能性測試6.1 系統(tǒng)集成的模式與方法系統(tǒng)集成的模式與方法Zhu.K6.1.1 集成測試前的準(zhǔn)備6.1.2 集成測試的模式6.1.3 自頂向下和自底向上集成方法6.1.4 大棒與三明治集成方法6.1.5 持續(xù)集成6.1.1 6.1.1 集成測試前的準(zhǔn)備集成測試前的準(zhǔn)備人員安排人員安排測試計劃測試計劃測試內(nèi)容測試內(nèi)容集成模式集成模式測試方法測試方法Zhu.K為什么總是集成不起來？為什么總是集成不起來？Zhu.K6.1.2 集成測試的模式集成測試的模式漸增式測試模式與非漸增式測試模式漸增式測試模式與非漸增式測試模式非漸增式測試模式非漸增式測試模式：先分別測

3、試每個模塊，再把所有模塊按設(shè)計要求放在一起結(jié)合成所要的程序，如大棒模式。漸增式測試模式漸增式測試模式：把下一個要測試的模塊同已經(jīng)測試好的模塊結(jié)合起來進(jìn)行測試，測試完以后再把下一個應(yīng)該測試的模塊結(jié)合進(jìn)來測試。各自的優(yōu)缺點(diǎn)（各自的優(yōu)缺點(diǎn)（P126）Zhu.K6.1.3 自頂向下和自底向上集成方法自頂向下和自底向上集成方法 Zhu.K驅(qū)動程序驅(qū)動程序/驅(qū)動模塊驅(qū)動模塊（driver），用以模擬被測模塊的上級模塊。驅(qū)動模塊在集成測試中接受測試數(shù)據(jù)，把相關(guān)的數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并打印出相應(yīng)的結(jié)果。樁程序樁程序/樁模塊樁模塊（stub），），也有人稱為存根程序，用以模擬被測模塊工作過程中所調(diào)

4、用的模塊。樁模塊由被測模塊調(diào)用，它們一般只進(jìn)行很少的數(shù)據(jù)處理，例如打印入口和返回，以便于檢驗被測模塊與其下級模塊的接口自頂向下法自頂向下法(Top-down Integration) Zhu.K自頂向下法的主要優(yōu)缺點(diǎn)自頂向下法的主要優(yōu)缺點(diǎn)Zhu.K自頂向下法自頂向下法(Top-down Integration) 自底向上法自底向上法(Bottom-up Integration) Zhu.K自底向上法的主要優(yōu)缺點(diǎn)自底向上法的主要優(yōu)缺點(diǎn)自底向上法自底向上法(Bottom-up Integration) Zhu.K混合策略混合策略(Modified Top-down Integration) Zhu

5、.K混合法：對軟件結(jié)構(gòu)中較上層，使用的是混合法：對軟件結(jié)構(gòu)中較上層，使用的是“自頂向下自頂向下”法；對軟件結(jié)構(gòu)中法；對軟件結(jié)構(gòu)中較下層，使用的是較下層，使用的是“自底向上自底向上”法，兩者相結(jié)合法，兩者相結(jié)合 6.1.4 大棒集成方法大棒集成方法(Big-bang Integration)Zhu.K采用大棒集成方法采用大棒集成方法,先是對每一個子模塊進(jìn)行測試（單元測試階段），先是對每一個子模塊進(jìn)行測試（單元測試階段），然后將所有模塊一次性的全部集成起來進(jìn)行集成測試然后將所有模塊一次性的全部集成起來進(jìn)行集成測試 。因為所有的模塊一次集成的，所以很難確定出錯的真正位置、所在的模塊、錯誤的原因。這種

6、方法并不推薦在任何系統(tǒng)中使用，適合在規(guī)模較小的應(yīng)用系統(tǒng)中使用。 三明治集成方法三明治集成方法(Sandwich Integration) Zhu.K采用三明治方法的優(yōu)點(diǎn)是：它將自頂向下和自底向上的集成方法有機(jī)地結(jié)合起來，不需要寫樁程序因為在測試初自底向上集成已經(jīng)驗證了底層模塊的正確性。采用這種方法的主要缺點(diǎn)是：在真正集成之前每一個獨(dú)立的模塊沒有完全測試過。改善的三明治集成方法改善的三明治集成方法Zhu.K改進(jìn)的三明治集成方法，不僅自兩頭向中間集成，而且保證每個模改進(jìn)的三明治集成方法，不僅自兩頭向中間集成，而且保證每個模塊得到單獨(dú)的測試，使測試進(jìn)行得比較徹底塊得到單獨(dú)的測試，使測試進(jìn)行得比較徹底

7、 。幾種集成方法性能的比較幾種集成方法性能的比較 Zhu.K自底向上自底向上 自頂向下自頂向下 混合策略混合策略大棒大棒三明治三明治改進(jìn)三明治改進(jìn)三明治集成集成早早早早早早晚晚早早早早基本程序能工作時間基本程序能工作時間晚晚早早早早晚晚早早早早需要驅(qū)動程序需要驅(qū)動程序是是否否是是是是是是是是需要樁程序需要樁程序否否是是是是是是是是是是工作并行性工作并行性中中低低中中高高中中高高特殊路徑測試特殊路徑測試容易容易難難容易容易容易容易中等中等容易容易計劃與控制計劃與控制容易容易難難難難容易容易難難難難6.1.5 持續(xù)集成持續(xù)集成Zhu.Kp 通常系統(tǒng)集成都會采用持續(xù)集成的策略，軟件開發(fā)中各個模塊不是

8、同時完成，根據(jù)進(jìn)度將完成的模塊盡可能早的進(jìn)行集成，有助于盡早發(fā)現(xiàn)Bug，避免集成中大量Bug涌現(xiàn)。p 而且容易定位Bug、修正Bug，最終提高軟件開發(fā)的質(zhì)量與效率。6.2功能測試功能測試 Zhu.K目的和內(nèi)容目的和內(nèi)容 p 程序安裝、啟動正常，有相應(yīng)的提示框、錯誤提示等p 每項功能符合實際要求p 系統(tǒng)的界面清晰、美觀p 菜單、按鈕操作正常、靈活，能處理一些異常操作p 能接受正確的數(shù)據(jù)輸入，對異常數(shù)據(jù)的輸入有提示、容錯處理等p 數(shù)據(jù)的輸出結(jié)果準(zhǔn)確，格式清晰，可以保存和讀取p 功能邏輯清楚，符合使用者習(xí)慣p 系統(tǒng)的各種狀態(tài)按照業(yè)務(wù)流程而變化，并保持穩(wěn)定p 支持各種應(yīng)用的環(huán)境p 能配合多種硬件周邊設(shè)

9、備p 軟件升級后，能繼續(xù)支持舊版本的數(shù)據(jù)p 與外部應(yīng)用系統(tǒng)的接口有效 功能測試的方法功能測試的方法 n等價類劃分法等價類劃分法n邊界值分析法邊界值分析法n錯誤推測法錯誤推測法n因果圖法因果圖法n場景法場景法n正交試驗法正交試驗法Zhu.K我要測試所我要測試所有的功能有的功能回歸測試的目的回歸測試的目的 p 所做的修改達(dá)到了預(yù)定的目的，如錯誤得到了改正，新功能得到了實現(xiàn)，能夠適應(yīng)新的運(yùn)行環(huán)境等；p 不影響軟件原有功能的正確性。 回歸測試的方法回歸測試的方法p 再測試全部用例 p 基于風(fēng)險選擇測試 p 基于操作剖面選擇測試 p 再測試修改的部分 6.3 回歸測試回歸測試 2000Zhu.K回歸測試

10、的組織和實施回歸測試的組織和實施6.4 非功能性非功能性測試測試p6.4.1 性能測試性能測試p6.4.2 壓力測試壓力測試p6.4.3 容量測試容量測試p6.4.4 安全性測試安全性測試p6.4.5 可靠性測試可靠性測試p6.4.6 容錯性測試容錯性測試Zhu.K6.4.1 性能測試性能測試 Zhu.K 性能測試(Performance test)通過測試以確定系統(tǒng)運(yùn)行時的性能表現(xiàn)，如得到運(yùn)行速度、響應(yīng)時間、占有系統(tǒng)資源等方面的系統(tǒng)數(shù)據(jù)。 0510152025301X51X1001X5001X7001X90010X5HTTPTCPHTTP&TCP軟件的性能軟件的性能軟件的性能是軟件的

11、一種非功能特性，它關(guān)注的不是軟件是否能夠完成特定的功能，而是在完成該功能時展示出來的及時性。由于感受軟件性能的主體是人，不同的人對于同樣的軟件能有不同的主觀感受，而且不同的人對于軟件性能關(guān)心的視角也不同。軟件的功能與性能舉例軟件的功能與性能舉例例如：電子郵件系統(tǒng)功能：郵件系統(tǒng)能夠支持收發(fā)以30種語言為標(biāo)題和正文的郵件，并支持粘貼10MB的附件。性能：郵件系統(tǒng)能夠在2GB RAM/1GHz CPU的服務(wù)器上，支持10000注冊用戶，日均處理10000封郵件，響應(yīng)時間不超過5秒/封。軟件的功能與性能舉例軟件的功能與性能舉例功能需求中名詞和動詞多，描述軟件主體和動作行為，如“標(biāo)題”、“正文”、“收發(fā)

12、”、“粘貼”等。性能需求中涉及容量和時間詞匯多，如“2GB RAM/1GHz CPU的服務(wù)器”、“10000注冊用戶”、“5秒/封”等。軟件性能與功能的區(qū)別軟件性能與功能的區(qū)別軟件性能和功能的區(qū)別的實質(zhì)是：軟件功能焦點(diǎn)在于軟件“做什么”，關(guān)注軟件“主體”發(fā)生的“事件”；而軟件性能則關(guān)注于軟件“做的如何”，這是綜合“空間”和“時間”考慮的方案(資源和速度)，表現(xiàn)為軟件對“空間”和“時間”的敏感度。性能測試的目的和需求性能測試的目的和需求目的：目的： 為了驗證系統(tǒng)是否達(dá)到用戶提出的性能指標(biāo)，同時發(fā)現(xiàn)系統(tǒng)中存在的性能瓶頸，起到優(yōu)化系統(tǒng)的目的。性能測試需求：性能測試需求：用戶對各項指標(biāo)提出的明確需求；

13、如果用戶沒有提出性能指標(biāo)則根據(jù)用戶需求、測試設(shè)計人員的經(jīng)驗來設(shè)計各項測試指標(biāo)。（需求+經(jīng)驗）主要的性能指標(biāo)：主要的性能指標(biāo)：服務(wù)器的各項指標(biāo)（CPU、內(nèi)存占用率等）、后臺數(shù)據(jù)庫的各項指標(biāo)、網(wǎng)絡(luò)流量、響應(yīng)時間軟件性能軟件性能用戶視角用戶視角對用戶而言，性能就是響應(yīng)時間。用戶甚至不關(guān)心響應(yīng)時間中哪些是軟件造成的，哪些是硬件造成的。響應(yīng)時間(Response Time):指用戶感受軟件系統(tǒng)為其服務(wù)所耗費(fèi)的時間。服務(wù)器端響應(yīng)時間網(wǎng)絡(luò)響應(yīng)時間客戶端響應(yīng)時間軟件性能軟件性能軟件人員視角軟件人員視角常用軟件性能指標(biāo)：吞吐量(Throughput)：指軟件系統(tǒng)在每單位時間內(nèi)處理多少個事務(wù)/請求/單位數(shù)據(jù)等。如

14、數(shù)據(jù)庫吞吐量指單位時間內(nèi)SQL語句的執(zhí)行數(shù)量。資源使用率(Resource utilization)：CPU占用率、內(nèi)存使用率、磁盤I/O等。并發(fā)用戶數(shù)(Concurrent users)：度量服務(wù)器并發(fā)容量和同步協(xié)調(diào)的能力。性能測試方法性能測試方法設(shè)計性能場景設(shè)計性能場景負(fù)載模擬負(fù)載模擬 并發(fā)用戶 + 思考時間 + 每次請求的數(shù)據(jù)量 + 負(fù)載模式系統(tǒng)負(fù)載系統(tǒng)負(fù)載在線用戶并發(fā)用戶思考時間負(fù)載模式兩種負(fù)載類型兩種負(fù)載類型“FlatFlat”測試測試: : 對于一次給定的測試，應(yīng)該取響應(yīng)時間和吞吐量的平均值。精確地獲得這些值的唯一方法是一次一次加載所有的用戶加載所有的用戶，然后在預(yù)定的時間段內(nèi)持續(xù)

15、時間段內(nèi)持續(xù)運(yùn)行。虛擬用戶的數(shù)量虛擬用戶的數(shù)量兩種負(fù)載類型兩種負(fù)載類型 Ramp-upRamp-up測試測試: : 用戶是交錯上升的（每幾秒增加一些新用戶）。ramp-up測試不能產(chǎn)生精確和可重現(xiàn)的平均值，這是因為由于用戶的增加是每次一部分，系統(tǒng)的負(fù)載在不斷地變化。其優(yōu)點(diǎn)是，可以看出隨著系統(tǒng)負(fù)載的改變，測量值是如何改變的據(jù)此選擇要運(yùn)行的flat測試的范圍。性能測試的基本步驟性能測試的基本步驟n確定性能測試需求確定性能測試需求；n根據(jù)測試需求，選擇測試工具和開發(fā)相應(yīng)的測試腳本；n建立性能測試負(fù)載模型建立性能測試負(fù)載模型，就是確定并發(fā)虛擬用戶的數(shù)量、每次請求的數(shù)據(jù)量、思考時間、加載方式和持續(xù)加載的

16、時間等；n執(zhí)行性能測試；n結(jié)果分析結(jié)果分析，并提交性能測試報告。性能測試要點(diǎn)性能測試要點(diǎn)p測試環(huán)境應(yīng)盡量與產(chǎn)品運(yùn)行環(huán)境保持一致，應(yīng)單獨(dú)運(yùn)行盡量避免與其他軟件同時使用。p性能測試一般使用測試工具和測試人員編制測試腳本來完成。p性能測試的重點(diǎn)在于前期數(shù)據(jù)的設(shè)計與后期數(shù)據(jù)的分析。p性能測試的用例主要涉及到整個系統(tǒng)架構(gòu)的問題，所以測試用例一旦生成，改動一般不大，所以做性能測試的重復(fù)使用率一般比較高。性能測試需避免的誤區(qū)性能測試需避免的誤區(qū)n性能測試不是功能測試n對基本的常用的功能做性能測試n對響應(yīng)時間要求苛刻的功能做性能測試n性能測試屬于系統(tǒng)級測試n注重從用戶的角度出發(fā)n系統(tǒng)處于比較穩(wěn)定的狀態(tài)性能調(diào)優(yōu)

17、的手段性能調(diào)優(yōu)的手段n滿足用戶性能需求的解決方案：n消除軟件對空間和時間不必要的浪費(fèi)n以空間換時間n以時間換空間n消除軟件對空間和時間不必要的浪費(fèi)內(nèi)存泄漏n以空間換時間n如cache緩存以時間換空間以時間換空間案例案例優(yōu)化后：void swapTwo(int *a, int* b) *a = *a + *b; *b = *a - *b; *a = *a - *b;優(yōu)化前：void swapOne(int *a, int* b) int temp; temp = *a; *a = *b; *b = temp;系統(tǒng)瓶頸分析舉例系統(tǒng)瓶頸分析舉例-1交易的響應(yīng)時間交易的響應(yīng)時間如果很長，遠(yuǎn)遠(yuǎn)超過系統(tǒng)性

18、能需求，表示耗費(fèi)CPU的數(shù)據(jù)庫操作，例如排序，執(zhí)行aggregate functions（例如sum、min、max、count）等較多，可考慮是否有索引以及索引建立的是否合理；盡量使用簡單的表聯(lián)接；水平分割大表格等方法來降低該值。Zhu.K系統(tǒng)瓶頸分析舉例系統(tǒng)瓶頸分析舉例-2分段排除錯誤。測試工具可以模擬不同的虛擬用戶來單獨(dú)訪問Web服務(wù)器、應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器，這樣，就可以在Web端測出的響應(yīng)時間減去以上各個分段測出的時間就可以知道瓶頸在哪并著手調(diào)優(yōu)。 Zhu.K系統(tǒng)瓶頸分析舉例系統(tǒng)瓶頸分析舉例-3UNIX資源監(jiān)控（NT操作系統(tǒng)同理）中指標(biāo)內(nèi)存內(nèi)存頁交換速率頁交換速率（Paging r

19、ate），如果該值偶爾走高，表明當(dāng)時有線程競爭內(nèi)存。如果持續(xù)很高，則內(nèi)存可能是瓶頸。也可能是內(nèi)存訪問命中率低?！癝wap in rate”和“Swap out rate”也有類似的解釋。 Zhu.K系統(tǒng)瓶頸分析舉例系統(tǒng)瓶頸分析舉例-4UNIX資源監(jiān)控（NT操作系統(tǒng)同理）中指標(biāo)CPU占用率占用率（CPU utilization），如果該值持續(xù)超過95%，表明瓶頸是CPU?？梢钥紤]增加一個處理器或換一個更快的處理器 。合理使用的范圍在60%至70%。Zhu.K系統(tǒng)瓶頸分析舉例系統(tǒng)瓶頸分析舉例-5UNIX資源監(jiān)控（NT操作系統(tǒng)同理）中指標(biāo)磁盤磁盤交換率交換率（Disk rate），如果該參數(shù)值一直很

20、高，表明I/O有問題?？煽紤]更換更快的硬盤系統(tǒng)、重新部署業(yè)務(wù)邏輯等，另外設(shè)置Tempdb in RAM，減低max async IO，max lazy writer IO等措施都會降低該值。 Zhu.K6.4.2 壓力測試壓力測試Zhu.K壓力測試壓力測試(Stress test)，也稱為強(qiáng)度測試、負(fù)載測試。壓力測試是模擬實際應(yīng)用的軟硬件環(huán)境及用戶使用過程的系統(tǒng)負(fù)荷，長時間或超大負(fù)荷地運(yùn)行測試軟件，來測試被測系統(tǒng)的性能、可靠性、穩(wěn)定性等。壓力測試類型壓力測試類型n 并發(fā)性能測試（重點(diǎn)）并發(fā)性能測試（重點(diǎn)）n 疲勞強(qiáng)度測試疲勞強(qiáng)度測試n 大數(shù)據(jù)量測試大數(shù)據(jù)量測試 在一種需要反常（如長時間的峰值）

21、數(shù)量、頻率或資源的方式下，執(zhí)行可重復(fù)的負(fù)載測試，以檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力，找出性能瓶頸找出性能瓶頸。從本質(zhì)上來說，測試者是想要破壞程序。并發(fā)性能測試并發(fā)性能測試考察客戶端應(yīng)用的性能，測試的入口是客戶端并發(fā)性能測試的過程，是一個負(fù)載測試和壓力測試的過程。即逐漸增加并發(fā)虛擬用戶數(shù)負(fù)載，直到系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，通過綜合分析交易執(zhí)行指標(biāo)、資源監(jiān)控指標(biāo)等來確定系統(tǒng)并發(fā)性能的過程。并發(fā)性能測試是負(fù)載壓力測試中的重要內(nèi)容。ramp-up測試測試 疲勞強(qiáng)度測試疲勞強(qiáng)度測試 通常是采用系統(tǒng)穩(wěn)定運(yùn)行情況下能夠支持的最大并發(fā)用戶數(shù)或者日常運(yùn)行用戶數(shù)，持續(xù)執(zhí)行一段時間業(yè)務(wù)，通過綜合分析交易執(zhí)行指標(biāo)和

22、資源監(jiān)控指標(biāo)來確定系統(tǒng)處理最大工作量強(qiáng)度性能的過程。 疲勞強(qiáng)度測試案例制定的原則是保證系統(tǒng)長期不間斷運(yùn)行的業(yè)務(wù)量，并且應(yīng)該盡量去滿足該條件。 Flat測試測試大數(shù)據(jù)量測試大數(shù)據(jù)量測試n獨(dú)立的數(shù)據(jù)量測試獨(dú)立的數(shù)據(jù)量測試 針對某些系統(tǒng)存儲、傳輸、統(tǒng)計、查詢等業(yè)務(wù)進(jìn)行大 數(shù)據(jù)量測試 。n綜合數(shù)據(jù)量測試綜合數(shù)據(jù)量測試 和壓力性能測試、負(fù)載性能測試、并發(fā)性能測試、疲勞性能測試相結(jié)合的綜合測試方案。6.4.3 容量測試容量測試 Zhu.K 容量測試目的是通過測試預(yù)先分析出反映軟件系統(tǒng)應(yīng)用特征的某項指標(biāo)的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），系統(tǒng)在其極限值狀態(tài)下還能保持主要功能正常運(yùn)行。容量測試還將確

23、定測試對象在給定時間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。 度量系統(tǒng)容量舉例度量系統(tǒng)容量舉例查看現(xiàn)有系統(tǒng)中性能與負(fù)載間的關(guān)系，并確定出現(xiàn)響應(yīng)時間顯著延長的位置 “拐點(diǎn)”。可以確定是否需要增加資源以支持額外的用戶。Zhu.K6.4.4 安全性測試安全性測試Zhu.K根據(jù)根據(jù)ISO 8402的定義，安全性是的定義，安全性是“使傷害或損害的風(fēng)使傷害或損害的風(fēng)險限制在可接受的水平內(nèi)險限制在可接受的水平內(nèi)”。 安全性測試安全性測試 Zhu.K安全性測試是檢查系統(tǒng)對非法侵入的防范能力。安全測試期間，測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如：p 想方設(shè)法截取或破譯口令；p 專門開發(fā)軟件來破壞系統(tǒng)的

24、保護(hù)機(jī)制；p 故意導(dǎo)致系統(tǒng)失敗，企圖趁恢復(fù)之機(jī)非法進(jìn)入；p 試圖通過瀏覽非保密數(shù)據(jù)，推導(dǎo)所需信息等等。理論上講，只要有足夠的時間和資源，沒有不可進(jìn)入的系統(tǒng)。因此系統(tǒng)安全設(shè)計的準(zhǔn)則是，使非法侵入的代價超過被保護(hù)信息的價值，此時非法侵入者已無利可圖。6.4.5 可靠性測試可靠性測試 Zhu.K可靠性（Reliability）是產(chǎn)品在規(guī)定的條件下和規(guī)定的時間內(nèi)完成規(guī)定功能的能力，它的概率度量稱為可靠度。軟件可靠性是軟件系統(tǒng)的固有特性之一，它表明了一個軟件系統(tǒng)按照用戶的要求和設(shè)計的目標(biāo)，執(zhí)行其功能的可靠程度。軟件可靠性與軟件缺陷有關(guān)，也與系統(tǒng)輸入和系統(tǒng)使用有關(guān)。理論上說，可靠的軟件系統(tǒng)應(yīng)該是正確、完整

25、、一致和健壯的。 l 規(guī)定的時間規(guī)定的時間 l 規(guī)定的環(huán)境條件規(guī)定的環(huán)境條件l 規(guī)定的功能規(guī)定的功能Zhu.K可靠性測試結(jié)果的評估可靠性測試結(jié)果的評估成熟性度量可以通過錯誤發(fā)現(xiàn)率DDP（Defect Detection Percentage）來表現(xiàn)。在測試中查找出來的錯誤越多，實際應(yīng)用中出錯的機(jī)會就越小，軟件也就越成熟。DDP=測試發(fā)現(xiàn)的錯誤數(shù)量測試發(fā)現(xiàn)的錯誤數(shù)量/已知的全部錯誤數(shù)量已知的全部錯誤數(shù)量已知的全部錯誤數(shù)量是測試已發(fā)現(xiàn)的錯誤數(shù)量加上可能會發(fā)現(xiàn)的錯誤數(shù)量之和?？煽啃詼y試結(jié)果的評估可靠性測試結(jié)果的評估nMTTF(Mean Time To Failure)，平均無故障時間，表示一段時間內(nèi)

26、兩次故障發(fā)生的平均間隔時間。nt2至t3之間MTTF的計算方法：n（1）找出t2之前發(fā)生的最后一次故障時間t1與t3之后發(fā)生的第一次故障時間t4；n（2）計算t1至t4之間的天數(shù)(t1、t4只算其中一天)；n（3）統(tǒng)計t1至t4之間發(fā)生的故障次數(shù)n；n（4）MTTF = （t4-t1）/（n-1）示例示例月月日日三月7日，26日四月3日，18日五月4日六月4日，27日七月18日某軟件運(yùn)行過程中，故障記錄如下表所示，試分別計算五月份與第二季度（第四、五、六月）的MTTF值。示例示例n五月份的 MTTF 計算如下：n 第一個故障，t1 = 4 月 18 日n 最后一次故障，t4 = 6 月 4 日n 所以，t4-t1 = 47 天n n = 3n 所以，五月份的 MTTF 是 47/2 = 23.5 天。n第二季度（4 月到