系統(tǒng)測試的課件

1、.1第6章 系統(tǒng)測試.2主要內(nèi)容：性能測試壓力測試容量測試健壯性測試安全性測試可靠性測試可用性測試驗(yàn)收測試的內(nèi)容、策略和方法系統(tǒng)測試工具及其應(yīng)用.36.1 性能測試.46.1.1 性能測試的基本概念性能測試主要檢驗(yàn)軟件是否達(dá)到需求規(guī)格說明書中規(guī)定的各類性能指標(biāo)，并滿足一些性能相關(guān)的約束和限制條件。.5性能測試包括以下幾個(gè)方面 ：評估系統(tǒng)的能力。測試中得到的負(fù)荷和響應(yīng)時(shí)間等數(shù)據(jù)可以被用于驗(yàn)證所計(jì)劃的模型的能力，并幫助做出決策。 識別系統(tǒng)中的弱點(diǎn)。受控的負(fù)荷可以被增加到一個(gè)極端的水平并突破它，從而修復(fù)系統(tǒng)的瓶頸或薄弱的地方。系統(tǒng)調(diào)優(yōu)。重復(fù)運(yùn)行測試，驗(yàn)證調(diào)整系統(tǒng)的活動(dòng)得到了預(yù)期的結(jié)果，從而改進(jìn)性能，

2、檢測軟件中的問題。.66.1.2 性能測試方法基準(zhǔn)法性能測試的基準(zhǔn)大體有以下幾方面：響應(yīng)時(shí)間 從應(yīng)用系統(tǒng)發(fā)出請求開始，到客戶端接收到最后一個(gè)字節(jié)數(shù)據(jù)為止所消耗的時(shí)間。合理的響應(yīng)時(shí)間取決于實(shí)際的用戶需求。并發(fā)用戶數(shù)常見的錯(cuò)誤理解：使用系統(tǒng)的全部用戶數(shù)量使用系統(tǒng)的全部在線用戶數(shù)量正確理解：與服務(wù)器進(jìn)行交互的在線用戶數(shù)量吞吐量單位時(shí)間在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量這個(gè)是衡量網(wǎng)絡(luò)性能的主要指標(biāo)注：由S-C性能計(jì)數(shù)器 描述服務(wù)器或操作系統(tǒng)性能的一些數(shù)據(jù)指標(biāo)，比如Windows系統(tǒng)資源管理器。.76.1.2 性能測試方法性能測試的其他常見用語：TPS每秒鐘系統(tǒng)能夠處理事務(wù)的數(shù)量 點(diǎn)擊率每秒發(fā)送的HTTP請求的數(shù)量點(diǎn)

3、擊率越大對SERVER的壓力也就越大請求響應(yīng)時(shí)間從Client端發(fā)出請求到得到響應(yīng)的整個(gè)時(shí)間。一般包括網(wǎng)絡(luò)響應(yīng)時(shí)間+server的響應(yīng)時(shí)間事務(wù)響應(yīng)時(shí)間完成這個(gè)事務(wù)所用的時(shí)間這個(gè)是性能測試中重點(diǎn)關(guān)注的指標(biāo).86.1.2 性能測試執(zhí)行分為三個(gè)階段：1計(jì)劃階段2測試階段3分析階段.96.2 壓力測試（負(fù)載測試、并發(fā)測試）.106.2.1 壓力測試的基本概念壓力測試（Stress Testing）是指模擬巨大的工作負(fù)荷，以查看系統(tǒng)在峰值使用情況下是否可以正常運(yùn)行。壓力測試是通過逐步增加系統(tǒng)負(fù)載來測試系統(tǒng)性能的變化，并最終確定在什么負(fù)載條件下系統(tǒng)性能處于失效狀態(tài)，以此來獲得系統(tǒng)性能提供的最大服務(wù)級別的測

4、試。.11在一種需要反常（如長時(shí)間的峰值）數(shù)量、頻率或資源的方式下，執(zhí)行可重復(fù)的負(fù)載測試，以檢查程序?qū)Ξ惓Ｇ闆r的抵抗能力，找出性能瓶頸。從本質(zhì)上來說，測試者是想要破壞程序。.12壓力測試方法具有如下特點(diǎn)：（1）壓力測試是檢查系統(tǒng)處于壓力情況下的能力表現(xiàn)。比如，通過增加并發(fā)用戶的數(shù)量，檢測系統(tǒng)的服務(wù)能力和水平；通過增加文件記錄數(shù)來檢測數(shù)據(jù)處理的能力和水平等等。.13（2）壓力測試一般通過模擬方法進(jìn)行。通常在系統(tǒng)對內(nèi)存和CPU利用率上進(jìn)行模擬，以獲得測量結(jié)果。如將壓力的基準(zhǔn)設(shè)定為：內(nèi)存使用率達(dá)到75%以上、CPU使用率達(dá)到75%以上，并在此觀測系統(tǒng)響應(yīng)時(shí)間、系統(tǒng)有無錯(cuò)誤產(chǎn)生。除了對內(nèi)存和CPU的使

5、用率進(jìn)行設(shè)定外，數(shù)據(jù)庫的連接數(shù)量、數(shù)據(jù)庫服務(wù)器的CPU利用率等等也都可以作為壓力測試的依據(jù)。.14（3）壓力測試一般用于測試系統(tǒng)的穩(wěn)定性。如果一個(gè)系統(tǒng)能夠在壓力環(huán)境下穩(wěn)定運(yùn)行一段時(shí)間，那么該系統(tǒng)在普遍的運(yùn)行環(huán)境下就應(yīng)該可以達(dá)到令人滿意的穩(wěn)定程度。在壓力測試中，通常會(huì)考察系統(tǒng)在壓力下是否會(huì)出現(xiàn)錯(cuò)誤等方面的問題。.15壓力測試與性能測試的聯(lián)系與區(qū)別：壓力測試是用來保證產(chǎn)品發(fā)布后系統(tǒng)能否滿足用戶需求，關(guān)注的重點(diǎn)是系統(tǒng)整體；性能測試可以發(fā)生在各個(gè)測試階段，即使是在單元層，一個(gè)單獨(dú)模塊的性能也可以進(jìn)行評估。.16壓力測試是通過確定一個(gè)系統(tǒng)的瓶頸，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。性能測試是檢測系統(tǒng)在

6、一定負(fù)荷下的表現(xiàn)，是正常能力的表現(xiàn)；而壓力測試是極端情況下的系統(tǒng)能力的表現(xiàn)。.17例如對一個(gè)網(wǎng)站進(jìn)行測試，模擬10到50個(gè)用戶同時(shí)在線并觀測系統(tǒng)表現(xiàn)，就是在進(jìn)行常規(guī)性能測試；當(dāng)用戶增加到系統(tǒng)出項(xiàng)瓶頸時(shí)，如1000乃至上萬個(gè)用戶時(shí)，就變成了壓力測試。.18壓力測試和負(fù)載測試（Load Test）：負(fù)載測試是通過逐步增加系統(tǒng)工作量，測試系統(tǒng)能力的變化，并最終確定在滿足功能指標(biāo)的情況下，系統(tǒng)所能承受的最大工作量的測試。壓力測試實(shí)質(zhì)上就是一種特定類型的負(fù)載測試。.19壓力測試和并發(fā)性測試：并發(fā)性測試是一種測試手段，在壓力測試中可以利用并發(fā)測試來進(jìn)行壓力測試。.206.2.2 壓力測試方法壓力測試應(yīng)該盡

7、可能逼真的模擬系統(tǒng)環(huán)境。對于實(shí)時(shí)系統(tǒng)，測試者應(yīng)該以正常和超常的速度輸入要處理的事務(wù)從而進(jìn)行壓力測試。批處理的壓力測試可以利用大批量的批事務(wù)進(jìn)行，被測事務(wù)中應(yīng)該包括錯(cuò)誤條件。.21壓力測試中使用事務(wù)獲得途徑測試數(shù)據(jù)生成器；由測試小組創(chuàng)建的測試事務(wù)；原來在系統(tǒng)環(huán)境中處理過的事務(wù)。.22壓力測試中應(yīng)該模擬真實(shí)的運(yùn)行環(huán)境。測試者應(yīng)該使用標(biāo)準(zhǔn)文檔，輸入事務(wù)的人員或者系統(tǒng)使用人員應(yīng)該和系統(tǒng)產(chǎn)品化之后的參與人員一樣。實(shí)時(shí)系統(tǒng)應(yīng)該測試其擴(kuò)展的時(shí)間段，批處理系統(tǒng)應(yīng)該使用多于一個(gè)事務(wù)的批量進(jìn)行測試。.23有效的壓力測試將可采用以下測試手段：（1）重復(fù)（Repetition）測試：重復(fù)測試就是一遍又一遍地執(zhí)行某個(gè)操

8、作或功能，比如重復(fù)調(diào)用一個(gè)Web服務(wù)。確定在極端情況下一個(gè)操作能否正常執(zhí)行，并且能否持續(xù)不斷地在每次執(zhí)行時(shí)都正常。.24（2）并發(fā)（Concurrency）測試：并發(fā)是同時(shí)執(zhí)行多個(gè)操作的行為，即在同一時(shí)間執(zhí)行多個(gè)測試線程。例如，在同一個(gè)服務(wù)器上同時(shí)調(diào)用許多Web服務(wù)。并發(fā)測試原則上不一定適用于所有產(chǎn)品（比如無狀態(tài)服務(wù)），但多數(shù)軟件都具有某個(gè)并發(fā)行為或多線程行為元素，這一點(diǎn)只能通過執(zhí)行多個(gè)代碼測試用例才能得到測試結(jié)果。.25（3）量級（Magnitude）增加：壓力測試可以重復(fù)執(zhí)行一個(gè)操作，但是操作自身也要盡量給產(chǎn)品增加負(fù)擔(dān)。量級的確定總是與應(yīng)用系統(tǒng)有關(guān)，可以通過查找產(chǎn)品的可配置參數(shù)來確定量級。

9、.26（4）隨機(jī)變化： 該手段是指對上述測試手段進(jìn)行隨機(jī)組合，以便獲得最佳的測試效果。.276.2.3 壓力測試執(zhí)行可以設(shè)計(jì)壓力測試用例來測試應(yīng)用系統(tǒng)的整體或部分能力。壓力測試用例選取可以從以下幾個(gè)方面考慮：輸入待處理事務(wù)來檢查是否有足夠的磁盤空間；創(chuàng)造極端的網(wǎng)絡(luò)負(fù)載；制造系統(tǒng)溢出條件；.28當(dāng)應(yīng)用系統(tǒng)所能正常處理的工作量并不確定時(shí)需要使用壓力測試。壓力測試意圖通過對系統(tǒng)施加超負(fù)載事務(wù)量來達(dá)到破壞系統(tǒng)的目的。壓力測試的弱點(diǎn)在于準(zhǔn)備測試的時(shí)間與在測試的實(shí)際執(zhí)行過程中所消耗的資源數(shù)量都非常龐大。通常在應(yīng)用程序投入使用之前這種消耗的衡量是無法進(jìn)行的。.29【例6.4】某個(gè)電話通信系統(tǒng)的測試測試采用壓

10、力測試方法。在正常情況下，每天的電話數(shù)目大約2000個(gè)，一天24小時(shí)服從正態(tài)分布。在系統(tǒng)第1年使用時(shí)，系統(tǒng)的平均無故障時(shí)間大約1個(gè)月左右。分析表明，系統(tǒng)的出錯(cuò)原因主要來源于單位時(shí)間內(nèi)電話數(shù)量比較大的情況下，為此，對系統(tǒng)采用壓力測試，測試時(shí)將每天電話的數(shù)目增加10倍，即20000個(gè)左右，分布采用均勻和正態(tài)兩種分布，測試大約進(jìn)行了4個(gè)月，共發(fā)現(xiàn)了314個(gè)錯(cuò)誤，修復(fù)這些錯(cuò)誤大約花費(fèi)了6個(gè)月的時(shí)間，修復(fù)后的系統(tǒng)運(yùn)行了近2年，尚未出現(xiàn)問題。.306.3 容量測試.316.3.1 容量測試基本概念所謂的容量測試（Volume Testing）是指，采用特定的手段測試系統(tǒng)能夠承載處理任務(wù)的極限值所從事的測試

11、工作。這里的特定手段是指，測試人員根據(jù)實(shí)際運(yùn)行中可能出現(xiàn)極限，制造相對應(yīng)的任務(wù)組合，來激發(fā)系統(tǒng)出現(xiàn)極限的情況。.32容量測試的目的容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理，通過測試，預(yù)先分析出反映軟件系統(tǒng)應(yīng)用特征的某項(xiàng)指標(biāo)的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），確定系統(tǒng)在其極限值狀態(tài)下是否還能保持主要功能正常運(yùn)行。容量測試還將確定測試對象在給定時(shí)間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。.33對軟件容量的測試，能讓軟件開發(fā)商或用戶了解該軟件系統(tǒng)的承載能力或提供服務(wù)的能力，如電子商務(wù)網(wǎng)站所能承受的、同時(shí)進(jìn)行交易或結(jié)算的在線用戶數(shù)。知道了系統(tǒng)的實(shí)際容量，如果不能滿足設(shè)計(jì)要求

12、，就應(yīng)該尋求新的技術(shù)解決方案，以提高系統(tǒng)的容量。有了對軟件負(fù)載的準(zhǔn)確預(yù)測，不僅能對軟件系統(tǒng)在實(shí)際使用中的性能狀況充滿信心，同時(shí)也可以幫助用戶經(jīng)濟(jì)地規(guī)劃應(yīng)用系統(tǒng)，優(yōu)化系統(tǒng)的部署。.34容量測試與壓力測試的區(qū)別與容量測試十分相近的概念是壓力測試。二者都是檢測系統(tǒng)在特定情況下，能夠承擔(dān)的極限值。然而兩者的側(cè)重點(diǎn)有所不同，壓力測試主要是使系統(tǒng)承受速度方面的超額負(fù)載，例如一個(gè)短時(shí)間之內(nèi)的吞吐量。容量測試關(guān)注的是數(shù)據(jù)方面的承受能力，并且它的目的是顯示系統(tǒng)可以處理的數(shù)據(jù)容量。.35容量測試往往應(yīng)用于數(shù)據(jù)庫方面的測試數(shù)據(jù)庫容量測試使測試對象處理大量的數(shù)據(jù)，以確定是否達(dá)到了將使軟件發(fā)生故障的極限。容量測試還將確

13、定測試對象在給定時(shí)間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。.36壓力測試、容量測試和性能測試的區(qū)別更確切的說，壓力測試可以看作是容量測試、性能測試和可靠性測試的一種手段，不是直接的測試目標(biāo)。壓力測試的重點(diǎn)在于發(fā)現(xiàn)功能性測試所不易發(fā)現(xiàn)的系統(tǒng)方面的缺陷，而容量測試和性能測試是系統(tǒng)測試的主要目標(biāo)內(nèi)容，也就是確定軟件產(chǎn)品或系統(tǒng)的非功能性方面的質(zhì)量特征，包括具體的特征值。容量測試和性能測試更著力于提供性能與容量方面的數(shù)據(jù)，為軟件系統(tǒng)部署、維護(hù)、質(zhì)量改進(jìn)服務(wù)，并可以幫助市場定位、銷售人員對客戶的解釋、廣告宣傳等服務(wù)。.37壓力測試、容量測試和性能測試的測試方法相通，在實(shí)際測試工作中，往往結(jié)合起來進(jìn)行以提高測試

14、效率。一般會(huì)設(shè)置專門的性能測試實(shí)驗(yàn)室完成這些工作，即使用虛擬的手段模擬實(shí)際操作，所需要的客戶端有時(shí)還是很大，所以性能測試實(shí)驗(yàn)室的投資較大。對于許多中小型軟件公司，可以委托第三方完成性能測試，可以在很大程度上降低成本。.386.4 健壯性測試.396.4.1 健壯性測試基本概念健壯性測試（Robustness Testing）主要用于測試系統(tǒng)抵御錯(cuò)誤的能力。這里的錯(cuò)誤通常指的是由于設(shè)計(jì)缺陷而帶來的系統(tǒng)錯(cuò)誤。測試的重點(diǎn)為當(dāng)出現(xiàn)故障時(shí)，是否能夠自動(dòng)恢復(fù)或忽略故障繼續(xù)運(yùn)行。.40健壯性的兩層含義：一是高可靠性，二是從錯(cuò)誤中恢復(fù)的能力。前者體現(xiàn)了軟件系統(tǒng)的質(zhì)量；后者體現(xiàn)了軟件系統(tǒng)的適應(yīng)性。二者也給測試工

15、作提出了不同的測試要求，前者需要根據(jù)符合規(guī)格說明的數(shù)據(jù)選擇測試用例，用于檢測在正常情況下系統(tǒng)輸出的正確性；后者需要在異常數(shù)據(jù)中選擇測試用例，檢測非正常情況下的系統(tǒng)行為。.416.4.2 健壯性測試方法健壯性測試可以根據(jù)以下方面評價(jià)系統(tǒng)的健壯性：通過：系統(tǒng)調(diào)用運(yùn)行輸入的參數(shù)產(chǎn)生預(yù)期的正常結(jié)果。災(zāi)難性失效：這是系統(tǒng)健壯性測試中最嚴(yán)重的失效，這種失效只有通過系統(tǒng)重新引導(dǎo)才能得到解決。重啟失效：一個(gè)系統(tǒng)函數(shù)的調(diào)用沒有返回，使得調(diào)用它的程序掛起或停止。夭折失效：程序執(zhí)行時(shí)由于異常輸入，系統(tǒng)發(fā)出錯(cuò)誤提示使程序中止。沉寂失效：異常輸入時(shí)，系統(tǒng)應(yīng)當(dāng)發(fā)出錯(cuò)誤提示，但是測試結(jié)果卻沒有發(fā)生異常。干擾失效：指系統(tǒng)異常

16、時(shí)返回了錯(cuò)誤的提示，但是該錯(cuò)誤提示不是期望中的錯(cuò)誤。.42自動(dòng)化實(shí)現(xiàn)上述測試內(nèi)容是需要把握以下原則：可移植性：健壯性測試基準(zhǔn)程序是用來比較不同系統(tǒng)的健壯性，因此移植性是測試基準(zhǔn)程序的基本要求。覆蓋率：理想的基準(zhǔn)程序能夠覆蓋所有的系統(tǒng)模塊，然而這種開銷是巨大的。因此一般選取使用頻度最高的模塊進(jìn)行測試?？蓴U(kuò)展性：可擴(kuò)展性體現(xiàn)在當(dāng)需要擴(kuò)展測試集時(shí)能夠前后一致。這種可擴(kuò)展性不僅指為已有模塊增加測試集，還包括為新增加的模塊增加測試集。測試結(jié)果的記錄：健壯性測試的目的是找出系統(tǒng)的不健壯性因素，因此應(yīng)詳細(xì)的記錄測試結(jié)果。.43設(shè)計(jì)健壯性測試的策略基于錯(cuò)誤的策略：確認(rèn)所有可能的錯(cuò)誤源，為每一類錯(cuò)誤開發(fā)錯(cuò)誤注入

17、技術(shù)；基于覆蓋率的策略：接口覆蓋的數(shù)量，故障位置覆蓋的數(shù)量，例外覆蓋的數(shù)量；基于失效的策略：用例設(shè)計(jì)故障是否被處理了，例外是否被處理了，一個(gè)組件中的失效是否影響另一個(gè)組件；.44健壯性測試用例設(shè)計(jì)方法在進(jìn)行健壯性測試時(shí)，常用的用例設(shè)計(jì)方法主要有三種：故障插入測試，變異測試和錯(cuò)誤猜測法。健壯性測試方法通常需要構(gòu)造一些不合理的輸入來引誘軟件出錯(cuò)，如輸入錯(cuò)誤的數(shù)據(jù)類型，輸入定義域之外的數(shù)值等。.456.4.3 一個(gè)健壯性測試案例分析【例66】為了更清楚的讓讀者了解什么是健壯性測試，在這里舉個(gè)簡單的例子。假如定義了兩個(gè)變量X1和X2，兩個(gè)變量都有自己的取值范圍，則寫成如下這種形式：aX1b；cX2d；

18、用坐標(biāo)的形式表示，如圖6.7所示。.46圖6.7 兩變量函數(shù)的健壯性測試用例在圖中，灰色區(qū)域外的4個(gè)點(diǎn)就是健壯性測試要重點(diǎn)考慮的情況。一般情況下，邊界值分析的大部分討論都直接適用于健壯性測試。健壯性測試最需要關(guān)注的部分不是輸入，而是預(yù)期的輸出。當(dāng)物理量超過其最大值時(shí)，會(huì)出現(xiàn)什么情況。如果是飛機(jī)機(jī)翼的迎角，則飛機(jī)可能失速，健壯性測試的主要價(jià)值是觀察例外處理情況。.476.5安全性測試.486.5.1安全性測試基本概念安全性測試是檢查系統(tǒng)對非法侵入的防范能力，其目的是為了發(fā)現(xiàn)軟件系統(tǒng)中是否存在安全漏洞。軟件安全性是指在非正常條件下不發(fā)生安全事故的能力。安全性一般分為兩個(gè)層次，即應(yīng)用程序級的安全性和

19、系統(tǒng)級別的安全性 .496.5.2安全性測試方法（1）功能驗(yàn)證功能驗(yàn)證是采用軟件測試當(dāng)中的黑盒測試方法，對涉及安全的軟件功能，如用戶管理模塊、權(quán)限管理模塊、加密系統(tǒng)、認(rèn)證系統(tǒng)等進(jìn)行測試，主要是驗(yàn)證上述功能是否有效。 .50（2）漏洞掃描 安全漏洞掃描通常都是借助于特定的漏洞掃描器完成。漏洞掃描器是一種能自動(dòng)檢測遠(yuǎn)程或本地主機(jī)安全性弱點(diǎn)的程序，通過使用漏洞掃描器，系統(tǒng)管理員能夠發(fā)現(xiàn)所維護(hù)信息系統(tǒng)存在的安全漏洞，從而在信息系統(tǒng)網(wǎng)絡(luò)安全防護(hù)過程中做到有的放矢，及時(shí)修補(bǔ)漏洞。.51模擬攻擊試驗(yàn) 對于安全測試來說，模擬攻擊試驗(yàn)是一組特殊的黑盒測試案例，通常以模擬攻擊來驗(yàn)證軟件或信息系統(tǒng)的安全防護(hù)能力。.

20、526.6 可靠性測試.536.6.1 可靠性測試的基本概念1軟件可靠性測試過程.54.552描述軟件可靠性的基本參數(shù)假設(shè)系統(tǒng)S投入測試或運(yùn)行后，工作一段時(shí)間t1后，軟件出現(xiàn)錯(cuò)誤，系統(tǒng)被停止并進(jìn)行修復(fù)，經(jīng)過T1時(shí)間后，故障被排除，又投入測試或運(yùn)行。假設(shè)t1，t2，tn是系統(tǒng)正常的工作時(shí)間，T1，T2，Tn是維護(hù)時(shí)間，如圖6.11所示。.56（1）故障率（風(fēng)險(xiǎn)函數(shù)）： 的單位是FIT，1FIT=10-9/小時(shí)。.57(2) 維修率：(3) 平均無故障時(shí)間： .58(4) 平均維護(hù)時(shí)間：(5) 有效度 .59 (6) 可靠性：美國國家標(biāo)準(zhǔn)ANSI/AIAA R-013-1992要求最合理的故障率大

21、約在10-4/小時(shí)左右，對于安全用計(jì)算機(jī)，推薦的MTBF大約為100010000小時(shí)。.60【例6.8】 某個(gè)系統(tǒng)的使用情況如圖6.12所示。根據(jù)題義，n=6,t=186天=1488小時(shí)（每天8小時(shí)），T=15小時(shí)，則：MTBF=248小時(shí)=0.004/小時(shí)MTTR=2.5小時(shí)=0.4A=0.99.613測試剖面和使用剖面之間的關(guān)系(1) 計(jì)算準(zhǔn)確的軟件運(yùn)行剖面，只有得到真實(shí)的軟件運(yùn)行剖面，軟件可靠性計(jì)算的結(jié)果才是真實(shí)的，否則，就會(huì)存在誤差。假設(shè)Test(D)是測試時(shí)的運(yùn)行剖面，User(D)是用戶使用時(shí)的運(yùn)行剖面。(2) 計(jì)算測試強(qiáng)度C，也稱為壓縮因子。C被定義為： .62定理6.1：設(shè)x1

22、，x2，xn是測試期間的n個(gè)無故障時(shí)間間隔，測試剖面等于使用剖面，即Test (D)= User (D)，則：.63定理6.2：假設(shè)軟件有n功能或模塊，實(shí)際使用時(shí)每個(gè)模塊被執(zhí)行的概率分別為p1，p2，pn，均勻分布測試M小時(shí)，相當(dāng)于按使用剖面測試了小時(shí)。.64定理6.3：假設(shè)軟件有n功能，實(shí)際使用時(shí)每個(gè)功能被執(zhí)行的概率分別為p1，p2，pn，測試期間假設(shè)的每個(gè)功能被執(zhí)行的概率分別為：p1，p2，pn，令： 則x越大，測試時(shí)估計(jì)的可靠性就越不準(zhǔn)確。反之，亦然。.656.6.2 軟件的運(yùn)行剖面1運(yùn)行剖面的概念及意義定義6.1：軟件的運(yùn)行剖面：設(shè)D是軟件S的定義域，D=d1，d2，dn，P(di)是

23、di的發(fā)生的概率，則運(yùn)行剖面被定義為： (d1 ,P(d1), (d2 ,P(d2), (dn ,P(dn)。.66軟件測試與軟件可靠性的評估離不開軟件的運(yùn)行剖面。軟件S的運(yùn)行剖面是指軟件輸入空間D以及D中的點(diǎn)取值的分布，也就是說，D中每個(gè)點(diǎn)取值的概率（一般，將D及D的分布稱為運(yùn)行剖面）。顯然，如果dD，若S（d ）是正確的，則S的正確運(yùn)行的概率為1，即P（S）=1。假設(shè)D=D1D2，D1是S正確運(yùn)行的概率，D2是S產(chǎn)生錯(cuò)誤的概率。在均勻分布假設(shè)下，S正確運(yùn)行的概率為： .676.7 可用性測試.686.7.1 可用性測試的概念可用性測試 (Usability Testing) 是對于用戶友好

24、性的測試，是指在設(shè)計(jì)過程中被用來改善易用性的一系列方法。測試人員為用戶提供一系列操作場景和任務(wù)讓他們?nèi)ネ瓿?，這些場景和任務(wù)與產(chǎn)品或服務(wù)密切相關(guān)，通過觀察來發(fā)現(xiàn)完成過程中出現(xiàn)了什么問題、用戶喜歡或不喜歡哪些功能和操作方式，原因是什么，針對問題所在提出改進(jìn)的建議。.69可用性與實(shí)用性的區(qū)別可用性是指產(chǎn)品在特定使用環(huán)境下為特定用戶用于特定用途時(shí)所具有的有效性、效率和用戶主觀滿意度。有效性是用戶完成特定任務(wù)時(shí)所具有的正確和完整程度；效率是用戶完成任務(wù)的正確完整程度與所用資源（如時(shí)間）之間的比率；滿意度是用戶在使用產(chǎn)品過程中具有的主觀滿意和接受程度?？捎眯泽w現(xiàn)的是用戶在使用過程中所實(shí)際感受到的產(chǎn)品質(zhì)量，

25、即使用質(zhì)量；而實(shí)用性體現(xiàn)的是產(chǎn)品功能，即產(chǎn)品本身所具有的功能模塊。與實(shí)用性相比，可用性重視了人的因素，重視了產(chǎn)品是被要最終用戶使用的。.70典型可用性測試包含以下維度:任務(wù)操作的成功率；任務(wù)操作效率；任務(wù)操作前的用戶期待；任務(wù)操作后的用戶評價(jià)；用戶滿意度；各任務(wù)出錯(cuò)率；二次操作成功率；二次識別率用戶操作過程中各認(rèn)知緯度（視產(chǎn)品情況而定）。.71可用性測試的文檔日程安排文檔用戶背景資料文檔用戶協(xié)議測試腳本 測試前問卷 測試后問卷任務(wù)卡片 測試過程檢查文檔 過程記錄文檔 測試報(bào)告 影音資料.726.7.2 可用性測試方法（1）一對一用戶測試：一個(gè)可用性測試部分包括測試人員（主持人/助理）和一個(gè)目標(biāo)

26、用戶，這個(gè)目標(biāo)用戶會(huì)在測試人員的陪同下完成一系列的典型任務(wù)。征得參與者的同意后測試過程將被攝像，測試人員將持續(xù)觀察、了解用戶的操作過程、思維過程以及相關(guān)各項(xiàng)指標(biāo)（包括用戶出錯(cuò)次數(shù)、完成任務(wù)的時(shí)間等），記錄用戶遇到的可用性問題并分析。.73（2）啟發(fā)式評估：邀請58名用戶作為評估人員來評價(jià)產(chǎn)品使用中的人機(jī)交互狀況，發(fā)現(xiàn)問題，并根據(jù)可用性設(shè)計(jì)原則提出改進(jìn)方案。啟發(fā)式評估法是一種用來發(fā)現(xiàn)用戶界面設(shè)計(jì)中的可用性問題從而使這些問題作為再設(shè)計(jì)過程中的一部分被重視的內(nèi)容可用性檢查方法。啟發(fā)式評估法旨在利用已確立的可用性原則來解釋每個(gè)發(fā)現(xiàn)的可用性問題，所以要根據(jù)由已經(jīng)被違背的、好的交互系統(tǒng)需具備的原則所規(guī)定的

27、設(shè)計(jì)準(zhǔn)則來制定一個(gè)修正的設(shè)計(jì)方案是相當(dāng)容易的。據(jù)研究發(fā)現(xiàn)，一般情況下，5個(gè)評估人員能夠發(fā)現(xiàn)75的可用性問題，從可用性問題產(chǎn)出的市場價(jià)值與評估費(fèi)用的比率來看，是較為理想的數(shù)字。.74 （3）焦點(diǎn)小組：是在可用性工程中使用的比較多的一種方法，通常用于產(chǎn)品功能的界定、工作流程的模擬、用戶需求的發(fā)現(xiàn)、用戶界面的結(jié)構(gòu)設(shè)計(jì)和交互設(shè)計(jì)、產(chǎn)品的原型的接受度測試、用戶模型的建立等。.75可用性問題包括以下方面:過分復(fù)雜的功能或者指令；困難的安裝過程；錯(cuò)誤信息過于簡單，例如“系統(tǒng)錯(cuò)誤”；語法難于理解和使用；非標(biāo)準(zhǔn)的GUI接口；用戶被迫去記住太多的信息；.76難以登錄；幫助文本上下文不敏感或者不夠詳細(xì)；和其他系統(tǒng)之

28、間的連接太弱；默認(rèn)不夠清晰；接口太簡單或者太復(fù)雜；語法、格式和定義不一致；沒有給用戶提供所有輸入的清晰的認(rèn)識。.776.8 驗(yàn)收測試.786.8.1 驗(yàn)收測試的概念驗(yàn)收測試是部署軟件之前的最后一個(gè)測試操作。驗(yàn)收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。實(shí)施驗(yàn)收測試的常用策略主要有三種，分別是正式驗(yàn)收測試、非正式驗(yàn)收測試和Beta測試。策略的選擇通常建立在合同需求、公司標(biāo)準(zhǔn)以及應(yīng)用領(lǐng)域的基礎(chǔ)上 .791正式驗(yàn)收測試 正式驗(yàn)收測試是一項(xiàng)管理嚴(yán)格的過程，它通常是系統(tǒng)測試的延續(xù)。計(jì)劃和設(shè)計(jì)這些測試的周密和詳細(xì)程度不亞于系統(tǒng)測試。選擇的測試用例應(yīng)當(dāng)是系統(tǒng)測試中所執(zhí)

29、行測試用例的子集，并且不應(yīng)當(dāng)偏離所選擇的測試用例方向。在很多項(xiàng)目中，正式驗(yàn)收測試是通過自動(dòng)化測試工具執(zhí)行的。 .80優(yōu)點(diǎn)包括：要測試的功能和特性都是已知的測試的細(xì)節(jié)是已知的并且可以對其進(jìn)行評測這種測試可以自動(dòng)執(zhí)行，支持回歸測試可以對測試過程進(jìn)行評測和監(jiān)測可接受性標(biāo)準(zhǔn)是已知的 .81缺點(diǎn)包括：要求大量的資源和計(jì)劃這些測試可能是系統(tǒng)測試的再次實(shí)施可能無法發(fā)現(xiàn)軟件中由于主觀原因造成的缺陷.822非正式驗(yàn)收測試在非正式驗(yàn)收測試中，執(zhí)行測試過程的限定不像正式驗(yàn)收測試中那樣嚴(yán)格，那樣組織有序，而且更為主觀。非正式驗(yàn)收測試確定并記錄要研究的功能和業(yè)務(wù)任務(wù)，但沒有可以遵循的特定測試用例，測試內(nèi)容由各測試人員決

30、定。多數(shù)情況下，非正式驗(yàn)收測試是由內(nèi)部測試人員組織執(zhí)行的。.83優(yōu)點(diǎn)包括：要測試的功能和特性都是已知的可以對測試過程進(jìn)行評測和監(jiān)測可接受性標(biāo)準(zhǔn)是已知的與正式驗(yàn)收測試相比，可以發(fā)現(xiàn)更多由于主觀原因造成的缺陷.84缺點(diǎn)包括：要求資源和計(jì)劃無法控制所使用的測試用例最終用戶可能沿用系統(tǒng)工作的方式，并且可能無法發(fā)現(xiàn)缺陷最終用戶可能專注于比較新系統(tǒng)與遺留系統(tǒng)，而不是專注于查找缺陷用于驗(yàn)收測試的資源不受項(xiàng)目的控制，并且可能受到壓縮.853Beta測試在以上三種驗(yàn)收測試策略中，Beta測試需要的控制是最少的。在Beta測試中，采用的數(shù)據(jù)和方法完全由各測試人員決定。各測試人員負(fù)責(zé)創(chuàng)建自己的環(huán)境，選擇數(shù)據(jù)，并決定

31、要研究的功能、特性和任務(wù)。各測試人員負(fù)責(zé)確定自己對于系統(tǒng)當(dāng)前狀態(tài)的接受標(biāo)準(zhǔn)。Beta測試由最終用戶實(shí)施，通常開發(fā)組織對最終用戶的管理很少或不進(jìn)行管理。Beta測試是所有驗(yàn)收測試策略中最主觀的。 .86優(yōu)點(diǎn)包括：測試由最終用戶實(shí)施大量的潛在測試資源提高客戶對參與人員的滿意程度與正式或非正式驗(yàn)收測試相比，可以發(fā)現(xiàn)更多由于主觀原因造成的缺陷.87缺點(diǎn)包括：未對所有功能或特性進(jìn)行測試測試流程難以評測最終用戶可能沿用系統(tǒng)工作的方式，并可能沒有發(fā)現(xiàn)或沒有報(bào)告缺陷最終用戶可能專注于比較新系統(tǒng)與遺留系統(tǒng)，而不是專注于查找缺陷用于驗(yàn)收測試的資源不受項(xiàng)目的控制，并且可能受到壓縮可接受性標(biāo)準(zhǔn)是未知的需要更多輔助性資

32、源來管理Beta測試人員.886.8.2 驗(yàn)收測試方法1驗(yàn)收測試的過程2驗(yàn)收測試用例的設(shè)計(jì)要點(diǎn).89驗(yàn)收測試的過程 (1) 軟件需求分析：了解軟件功能和性能要求、軟硬件環(huán)境要求等，并特別要了解軟件的質(zhì)量要求和驗(yàn)收要求。(2) 編制驗(yàn)收測試計(jì)劃和項(xiàng)目驗(yàn)收準(zhǔn)則：根據(jù)軟件需求和驗(yàn)收要求編制測試計(jì)劃，制定所需測試的測試項(xiàng)，制定測試策略及驗(yàn)收通過準(zhǔn)則，并由客戶參與計(jì)劃評審。(3) 測試設(shè)計(jì)和測試用例設(shè)計(jì)：根據(jù)驗(yàn)收測試計(jì)劃和項(xiàng)目驗(yàn)收準(zhǔn)則編寫測試用例，并經(jīng)過評審。.90(4) 測試環(huán)境搭建：建立測試的硬件環(huán)境、軟件環(huán)境等。(5) 測試實(shí)施：測試并記錄測試結(jié)果。(6) 測試結(jié)果分析：根據(jù)驗(yàn)收通過準(zhǔn)則分析測試結(jié)果，給出驗(yàn)收是否通過和測試評價(jià)。(7) 測試報(bào)告：根據(jù)測試結(jié)果編制缺陷報(bào)告和驗(yàn)收測試報(bào)告，并提交給客戶。.91驗(yàn)收測試用例的設(shè)計(jì)要點(diǎn) (1) 驗(yàn)收測試的目的主要是驗(yàn)證軟件功能的正確性和需求的符合性。軟件研發(fā)階段的單元測試、集成測試、系統(tǒng)測試的目的是發(fā)現(xiàn)軟件錯(cuò)誤，將軟件缺陷排除在交付給客戶之前，而驗(yàn)收測試是與客戶共同參與的，旨在確認(rèn)軟件符合需求規(guī)格的驗(yàn)證活動(dòng)。這是組織和編寫驗(yàn)收測試用例的出發(fā)點(diǎn)。(2) 驗(yàn)收測試用例所覆蓋的范圍應(yīng)該只是軟件功能的子集，而不是軟件的所有功能。在V字模型中驗(yàn)收測試與需求分析階段是相對應(yīng)的，因此，驗(yàn)收測試用例與軟件需求規(guī)格說明書之間具有可追溯性。