第2章 軟件測試策略

第2章

軟件測試策略本章主要內(nèi)容測試的設(shè)計測試過程設(shè)計測試類型設(shè)計測試數(shù)據(jù)設(shè)計測試的管理流程管理數(shù)據(jù)管理軟件測試與軟件工程模型V模型介紹測試編碼測試運行測試測試測試測試需求功能設(shè)計編碼驗收測試系統(tǒng)測試集成測試單元測試2.1測試的生命周期

軟件測試是軟件開發(fā)的一個階段，然而測試階段本身又可以劃分成不同的階段，這就構(gòu)成了軟件測試的生命周期。

根據(jù)實踐經(jīng)驗的總結(jié)，我們仿照軟件開發(fā)的生命周期模型，給出軟件測試的生命周期模型，如圖2.1所示。圖2.1軟件測試的生命周期 1．計劃階段

在此階段，通過對系統(tǒng)的整體分析，提出針對性的策略和規(guī)范，同時對系統(tǒng)輸入空間進(jìn)行合理的劃分，據(jù)此來寫出足夠的、具體的測試用例。

計劃階段的主要任務(wù)包括安排進(jìn)度、分配資源、人員及確定測試的起始點和結(jié)束點等。

圖2.2給出了最佳的測試結(jié)束點，在該點的左側(cè)，雖然測試成本很低，但還有很多錯誤沒有被發(fā)現(xiàn)，不能結(jié)束測試；而在最佳測試結(jié)束點的右側(cè)，雖然還會發(fā)現(xiàn)更多的軟件錯誤，但是測試成本會大大提高，測試的代價太高，除非系統(tǒng)有著特殊的要求，否則就可以結(jié)束測試了。

所以，我們需要對測試進(jìn)行合理的計劃安排，把測試作為一個項目來進(jìn)行，要做到在有限的時間內(nèi)，完成所設(shè)計的測試工作，并且達(dá)到要求的程序結(jié)構(gòu)覆蓋或需求覆蓋。圖2.2測試時間與測試費用 2．設(shè)計階段

測試的設(shè)計包括測試過程的設(shè)計和測試用例的設(shè)計。

測試過程設(shè)計是指對給定的系統(tǒng)如何展開測試、展開哪些測試。

測試過程的設(shè)計主要考慮測試內(nèi)容和測試順序。

（1）測試內(nèi)容：針對系統(tǒng)的要求，給出將如何展開測試。

（2）測試順序：軟件測試的一般順序為，首先進(jìn)行功能性測試，然后進(jìn)行性能測試（包括壓力測試、負(fù)載測試等），符合要求后進(jìn)行可靠性測試，最后進(jìn)行安全性測試等。

軟件測試的任務(wù)有兩個方面：一方面是盡可能多地發(fā)現(xiàn)系統(tǒng)中的Bug；另一方面是評估系統(tǒng)的性能，我們設(shè)計的測試輸入數(shù)據(jù)這兩方面都要滿足。

測試用例在軟件測試中是使用最多的名詞術(shù)語，也就是說，測試用例設(shè)計包含兩個部分，首先要給出針對系統(tǒng)要進(jìn)行怎樣的輸入；另外還要給出針對這樣的輸入，系統(tǒng)會產(chǎn)生怎樣的反應(yīng)，也就是預(yù)期結(jié)果。

由于被測軟件系統(tǒng)的輸入要求不同，所以測試用例又可以分為以下幾種。（1）純數(shù)據(jù)型測試用例。（2）文件型測試用例。（3）操作序列型測試用例。（4）程序型測試用例。 3．開發(fā)階段

由于系統(tǒng)的規(guī)模龐大，測試用例的多樣化，在執(zhí)行時要考慮效率問題，所以需要開發(fā)必要的工具，以便在測試用例的選擇、修訂、完善和執(zhí)行上盡可能采用自動化的手段。

開發(fā)階段主要包括準(zhǔn)備測試腳本、測試數(shù)據(jù)自動生成、測試流程自動化等工作。 4．執(zhí)行階段

這一階段的任務(wù)就是執(zhí)行測試用例，有手動執(zhí)行和自動執(zhí)行。 5．評估階段

這是測試的最后一個階段，也是最重要的階段，沒有評估階段就不能對被測系統(tǒng)給出正確的評價，測試也是不完整的。

這一階段的任務(wù)是對測試結(jié)果進(jìn)行評估和對發(fā)現(xiàn)的錯誤數(shù)進(jìn)行統(tǒng)計。

測試結(jié)果評估主要依靠信息比較，也就是將測試結(jié)果與期望輸出進(jìn)行比較，通過各種量化方法，對測試的有效性及結(jié)果的可信性提供量化的依據(jù)。

對于發(fā)現(xiàn)的錯誤數(shù)，可以進(jìn)行多方位的統(tǒng)計，包括：錯誤數(shù)與時間的函數(shù)關(guān)系圖（見圖2.3）；錯誤數(shù)與功能點的函數(shù)關(guān)系（見圖2.4）；錯誤數(shù)與開發(fā)人員的關(guān)系等。圖2.3測試各個階段發(fā)現(xiàn)的錯誤數(shù)圖2.4各個功能點的錯誤數(shù)統(tǒng)計2.2測試步驟圖2.5軟件測試策略

軟件測試工作也可從這一螺旋線上體現(xiàn)出來。

在螺旋線的核心點針對每個單元的源代碼進(jìn)行單元測試。

在各單元測試完成以后，沿螺旋線向外前進(jìn)，開始針對軟件整體構(gòu)造和設(shè)計的集成測試。

然后是檢驗軟件需求能否得到滿足的確認(rèn)測試，最后，來到螺旋線的最外層，把軟件和系統(tǒng)的其他部分協(xié)調(diào)起來，當(dāng)作一個整體，完成系統(tǒng)測試。這樣，沿著螺旋線，從內(nèi)向外，逐步擴(kuò)展了測試的范圍。

以上用螺旋線表明的測試過程按4個步驟進(jìn)行，即單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試。圖2.6所示為測試的4個步驟。圖2.6軟件測試步驟 2.2.1單元測試

單元（unit）是程序的最小組成單位，它具有以下的特征。

（1）通常可分配給某個程序人員開發(fā)，在單元之間或與外界除去有技術(shù)接口（如相互調(diào)用）、引用數(shù)據(jù)庫以外，總會有操作的界面需要協(xié)調(diào)。

（2）單元接受數(shù)據(jù)輸入后，經(jīng)過加工，得到一些結(jié)果，這時可能給出輸出數(shù)據(jù)，也可能僅僅發(fā)生一些狀態(tài)的改變。但如果輸入、加工和輸出三者缺少任何一個，這個程序單元都不是完整的。

（3）原則上說，每個程序單元都應(yīng)有正規(guī)的規(guī)格說明，使之對其輸入、加工和輸出的關(guān)系做出明確的描述。

模塊應(yīng)該具有以下的基本屬性：名字；明確規(guī)定了的功能；內(nèi)部使用的數(shù)據(jù)，或稱局部數(shù)據(jù)；與其他模塊或與外界存在的數(shù)據(jù)聯(lián)系；實現(xiàn)其特定功能的算法；可被其上層模塊調(diào)用，在其工作過程中也可調(diào)用其下屬模塊協(xié)同工作。

單元測試是要檢驗程序最小單位有無錯誤，它是在編碼完成后，首先要施行的測試工作。

通常由編碼人員自己來完成，因而有人把編碼與單元測試考慮成一個開發(fā)階段。

單元測試大多從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例，即多采用白盒測試方法。

多個程序單元可以并行地獨立開展測試工作。 1．單元測試要解決的問題

單元測試是要針對每個模塊的程序，解決以下5個方面的問題（參見圖2.7）。模塊接口—對被測的模塊，信息能否正常無誤地流入和流出。圖2.7單元測試局部數(shù)據(jù)結(jié)構(gòu)—在模塊工作過程中，其內(nèi)部的數(shù)據(jù)能否保持其完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關(guān)系不發(fā)生錯誤。邊界條件—在為限制數(shù)據(jù)加工而設(shè)置的邊界處，模塊是否能夠正常工作。覆蓋條件—模塊的運行能否做到滿足特定的邏輯覆蓋。出錯處理—模塊工作中發(fā)生了錯誤，其中的出錯處理設(shè)施是否有效。 2．單元測試的步驟

單元測試常常被當(dāng)作代碼編寫的附屬步驟，它是在完成了程序編寫，經(jīng)過了復(fù)查，確認(rèn)沒有語法錯誤以后，針對每個程序模塊單獨進(jìn)行的測試工作。

圖2.8所示為一個被測模塊進(jìn)行單元測試時的環(huán)境狀況，其中，設(shè)置了一個驅(qū)動模塊和3個樁模塊。

驅(qū)動模塊在單元測試中接受測試數(shù)據(jù)，把相關(guān)的數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并打印出相應(yīng)的結(jié)果。圖2.8單元測試環(huán)境 2.2.2集成測試

在每個模塊完成單元測試以后，需要按照設(shè)計時作出的結(jié)構(gòu)圖把它們連接起來，進(jìn)行集成測試（integratedtesting）。

實踐表明，一些模塊能夠單獨地工作，并不能保證連接起來也能正常工作。

程序在某些局部上反映不出的問題，在全局上很可能暴露出來，影響功能的發(fā)揮。\

怎樣合理地組織集成測試？這里提供兩種不同的方法，即非增式測試和增式測試。

增式測試的做法與非增式測試有所不同。

它的集成是逐步實現(xiàn)的，集成測試也是逐步完成的。也可以說它把單元測試與集成測試結(jié)合起來進(jìn)行。增式集成測試可按不同的次序?qū)嵤?，因而可以有兩種：（1）自頂向下增式測試。（2）自底向上增式測試。圖2.9非增式測試示例圖2.10自頂向下增式測試?yán)龍D2.11自底向上增式測試?yán)?2.2.3確認(rèn)測試

集成測試完成以后，分散開發(fā)的模塊被連接起來，構(gòu)成完整的程序。其中各模塊之間接口存在的種種問題都已消除。

于是測試工作進(jìn)入最后階段—確認(rèn)測試（validationtesting）。（1）確認(rèn)測試準(zhǔn)則。（2）配置評審。圖2.12配置評審與確認(rèn)測試的關(guān)系 1．恢復(fù)測試

恢復(fù)測試（recoverytest）是要采取各種人工干預(yù)方式使軟件出錯，而不能正常工作，進(jìn)而檢驗系統(tǒng)的恢復(fù)能力。 2．安全測試

安全測試（securitytest）的目的在于驗證安裝在系統(tǒng)內(nèi)的保護(hù)機(jī)構(gòu)確實能夠?qū)ο到y(tǒng)進(jìn)行保護(hù)，使之不受各種非常的干擾。 3．強(qiáng)度測試

檢驗系統(tǒng)的能力最高實際限度。進(jìn)行強(qiáng)度測試（stresstest）時，讓系統(tǒng)的運行處于資源的異常數(shù)量、異常頻率和異常批量的條件下。 4．容量測試

容量測試（capacitytest）是要檢驗系統(tǒng)的處理能力最高能達(dá)到什么程度，在使系統(tǒng)的全部資源達(dá)到“滿負(fù)荷”的情形下，測試系統(tǒng)的承受能力。 5．性能測試

性能測試（performancetest）檢驗安裝在系統(tǒng)內(nèi)的軟件運行性能。這種測試常常與強(qiáng)度測試、容量測試結(jié)合起來進(jìn)行。 6．α測試和β測試

α測試是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進(jìn)行的測試。α測試的目的主要是評價軟件產(chǎn)品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持），尤其注重產(chǎn)品的界面和特色。

β測試是由軟件的多個用戶在實際使用環(huán)境下進(jìn)行的測試。 7．安裝測試

安裝測試（installationtest）的目的不是找軟件錯誤，而是找安裝錯誤。在安裝軟件系統(tǒng)時，會有多種選擇。 8．可使用性測試

可使用性測試（usabilitytest）主要從使用的規(guī)范性、合理性和方便性等角度對軟件系統(tǒng)進(jìn)行檢查，以發(fā)現(xiàn)人為因素或使用上的問題。2.3靜態(tài)方法與動態(tài)方法

靜態(tài)方法的主要特征是不利用計算機(jī)運行被測試的程序，而是采用其他手段達(dá)到檢測的目的。

靜態(tài)分析是對被測程序進(jìn)行特性分析的一些方法的總稱。這些方法本身各有自己的目標(biāo)和步驟。2.4黑盒測試與白盒測試

黑盒測試與白盒測試是很廣泛使用的兩類測試方法。

黑盒測試（Black-boxTesting）又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試（Specification-basedTesting）。

用這種方法進(jìn)行測試時，被測程序被當(dāng)作打不開的黑盒，因而無法了解其內(nèi)部構(gòu)造。

在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者只知道該程序輸入和輸出之間的關(guān)系，或是程序的功能（見圖2.13），他必須依靠能夠反映這一關(guān)系和程序功能的需求規(guī)格說明書考慮確定測試用例和推斷測試結(jié)果的正確性。即所依據(jù)的只能是程序的外部特性。因此，黑盒測試是從用戶觀點出發(fā)的測試。圖2.13黑盒測試

白盒測試（White-boxTesting）又稱結(jié)構(gòu)測試、邏輯驅(qū)動測試或基于程序的測試（Program-basedTesting）。采用這一測試方法，測試者可以看到被測的源程序，他可用以分析程序的內(nèi)部構(gòu)造，并且根據(jù)其內(nèi)部構(gòu)造設(shè)計測試用例。這時測試者可以完全不顧程序的功能。 2.4.1黑盒測試 2.4.2白盒測試 2.4.3黑盒測試與白盒測試的比較

表2.1所示為黑盒測試與白盒測試兩類方法的對比。

圖2.14所示為它們各自的能力范圍、它們的互補(bǔ)關(guān)系以及各自的不足。黑盒測試白盒測試測試依據(jù)根據(jù)用戶能看到的規(guī)格說明，即針對命令、信息、報表等用戶界面及體現(xiàn)它們的輸入數(shù)據(jù)與輸出數(shù)據(jù)之間的對應(yīng)關(guān)系，特別是針對功能進(jìn)行測試根據(jù)程序的內(nèi)部結(jié)構(gòu)，比如語句的控制結(jié)構(gòu)、模塊間的控制結(jié)構(gòu)以及內(nèi)部數(shù)據(jù)結(jié)構(gòu)等進(jìn)行測試特點優(yōu)點能站在用戶立場上進(jìn)行測試能夠?qū)Τ绦騼?nèi)部的特定部位進(jìn)行覆蓋測試缺點不能測試程序內(nèi)部特定部位如果規(guī)格說明有誤，則無法發(fā)現(xiàn)無法檢驗程序的外部特性無法對未實現(xiàn)規(guī)格說明的程序內(nèi)部缺陷部分進(jìn)行測試方法舉例等價類劃分邊值分析因果圖語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋路徑覆蓋模塊接口測試表2.1 黑盒測試與白盒測試的對比

A 只能用黑盒測試發(fā)現(xiàn)的錯誤

C 只能用白盒測試發(fā)現(xiàn)的錯誤

B 用黑盒測試或白盒測試都能發(fā)現(xiàn)的錯誤

D 黑盒測試與白盒測試均無法發(fā)現(xiàn)的錯誤

A+B 能用黑盒測試發(fā)現(xiàn)的錯誤

B+C 能用白盒測試發(fā)現(xiàn)的錯誤

A+B+C 用兩種測試能發(fā)現(xiàn)的錯誤

A+B+C+D 軟件中的全部錯誤圖2.14黑盒測試與白盒測試能夠發(fā)現(xiàn)的錯誤2.5回歸測試方法

回歸測試可以應(yīng)用于軟件測試的各個階段，用來驗證錯誤修改情況，這稱為改錯性回歸測試；同時在軟件的增量式開發(fā)構(gòu)件復(fù)用過程中，通過重新測試已有的測試用例和設(shè)計新的測試用例，來測試改動（增加或刪除）的程序，這稱為增量性回歸測試。實踐表明，回歸測試在發(fā)現(xiàn)錯誤中起著非常重要的作用。 Rothermel和Harrold在1996年提出了對安全縮減測試用例庫的評價標(biāo)準(zhǔn)。

（1）包含性（Inclusiveness）：縮減的測試用例庫所揭示的回歸錯誤數(shù)與可能顯示的回歸錯誤數(shù)的百分比。

（2）精度（Precision）：縮減的測試用例庫所忽略的不能揭示的回歸錯誤數(shù)與系統(tǒng)存在的不能揭示的回歸錯誤數(shù)的百分比。

（3）效率（Efficiency）：識別一個縮減的測試用例庫的成本。

（4）普遍性（Generality）：選擇的策略的應(yīng)用范圍。2.6人工測試與自動測試 2.6.1人工測試技術(shù)概述

人工走查與審查會的差別主要在于側(cè)重點和目標(biāo)有所不同。

人工走查通常被當(dāng)作開發(fā)人員在開發(fā)過程中使用的技術(shù)（盡管實際上不只是開發(fā)者本人參加），其目的在于提高編碼的質(zhì)量。

審查會則常被當(dāng)作一種管理機(jī)制，經(jīng)過審查不僅可以提高各階段軟件產(chǎn)品（不僅是編碼）的質(zhì)量，而且還可以收集到一些有關(guān)該軟件產(chǎn)品質(zhì)量的數(shù)據(jù)。

項目管理人員可借以合理和定量地做出決策。因此，軟件開發(fā)過程中每個階段的審查都必須十分正規(guī)地、嚴(yán)格地加以定義，并且根據(jù)規(guī)格說明實施。 2.6.2軟件審查

軟件審查工作大致要經(jīng)歷以下幾個步驟：制定計劃；預(yù)審；準(zhǔn)備；審查會；返工；終審。 2.6.3軟件審查的作用 1．軟件審查所得數(shù)據(jù)的使用

任何一個軟件審查都將取得一些數(shù)據(jù)，這些數(shù)據(jù)如圖2.15所示，它真實地反映了開發(fā)過程中出現(xiàn)的各種問題。

充分利用這些數(shù)據(jù)指導(dǎo)和改進(jìn)開發(fā)工作，將是十分有益的。

圖2.16所示為處在兩個開發(fā)階段之間的審查，其所獲數(shù)據(jù)有3方面用途，即反饋、前饋和饋入。圖2.15軟件審查取得的數(shù)據(jù)圖2.16審查數(shù)據(jù)的用途 2．作為軟件開發(fā)進(jìn)程控制的審查

為了使軟件審查成為軟件開發(fā)進(jìn)程的控制手段，就要在開發(fā)過程的若干控制點實施前面介紹過的階段審查。

圖2.17所示為安排有階段審查的軟件開發(fā)過程。圖2.17軟件開發(fā)過程中的審查

圖中涉及的開發(fā)階段包括需求分析、概要設(shè)計、詳細(xì)設(shè)計、編碼、制定測試計劃以及設(shè)計測試用例。

其中的每個階段審查都應(yīng)規(guī)定它的進(jìn)入條件、出口條件、推薦的參審人員、查出問題分類以及查找問題策略。

正如圖2.15中所給出的數(shù)據(jù)，階段審查所發(fā)現(xiàn)的問題主要有3種表現(xiàn)形式，即遺漏—在規(guī)格說明或標(biāo)準(zhǔn)中指明應(yīng)該有的內(nèi)容，送審資料中丟掉了。多余—超出規(guī)格說明和標(biāo)準(zhǔn)，多給出的信息。錯誤—應(yīng)該有，也的確有，但內(nèi)容有誤的信息。

圖2.15中對審查中發(fā)現(xiàn)的問題歸納成13類，即接口、數(shù)據(jù)、邏輯、輸入和輸出、功能、性能、人為因素、標(biāo)準(zhǔn)、文檔、語法、測試環(huán)境、測試覆蓋和其他。下面結(jié)合某一項目概要設(shè)計的審查，舉例說明其分類方法。

圖2.18所示為這一分類的實例，而其項目概要設(shè)計說明則在圖2.19中給出。性能● 有一個似乎合理的變元使該程序不能滿足需求中描述的性能目標(biāo)數(shù)據(jù)● 在INPUTS,OUTPUTS或UPDATES節(jié)中遺漏或多出信息項● 在INPUTS,OUTPUTS或UPDATES節(jié)中遺漏或有不正確的數(shù)據(jù)類型接口● 在PROCESSING節(jié)中遺漏或多出子程序調(diào)用● INVOCATION中的信息有誤功能● 在PROCESSING中遺漏、多余或有錯誤操作● 在PROCESSING中的邏輯條件有遺漏、多余或有誤文檔● 在DESCRIPTION節(jié)中的內(nèi)容不完整或使人誤解● 對數(shù)據(jù)項的描述有多義性● 處理步驟描述不夠清晰標(biāo)準(zhǔn)● 違背了采用的設(shè)計標(biāo)準(zhǔn)：ProjectStandardsManual語法● 語法、標(biāo)點或拼寫方面有誤其他● 不屬于以上所述的其他問題圖2.18概要設(shè)計審查發(fā)現(xiàn)問題分類實例SUBPROGRAM:prclTITLE：按列打印DESCRIPTION：本子程序?qū)⑤斎胛募儞Q格式成按列輸出文件INPUTS：-1任選的長度命令-k任選的列數(shù)-w任選的頁寬命令filename輸入文件UPDATES：N/AOUTPUTS：

格式化輸出

排入標(biāo)準(zhǔn)輸出文件

錯誤信息

至標(biāo)準(zhǔn)錯誤文件

狀態(tài)

處理狀態(tài)碼PROCESSING：1．將輸入文件格式化按標(biāo)準(zhǔn)輸出每頁k列2．若發(fā)現(xiàn)錯誤，則將錯