軟工概論第14章軟件測試策略

1

第14章軟件測試策略什么是軟件質(zhì)量？軟件質(zhì)量的定義不明確，就談不上軟件測試。高質(zhì)量的軟件是一個重要目標，在一般意義上，軟件質(zhì)量可以這樣定義：在一定程度上，應用有效的軟件過程，創(chuàng)造有用的產(chǎn)品，為生產(chǎn)者和使用者提供明顯的價值。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.2軟件質(zhì)量保證延伸前述的質(zhì)量定義，軟件質(zhì)量保證就是為了保證軟件高質(zhì)量而必需的“有計劃、系統(tǒng)化的行動模式”。軟件質(zhì)量保證（質(zhì)量管理）是適用于整個軟件過程的一種普適性活動，而不僅僅是在編碼完成之后才開始進行。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.3軟件質(zhì)量保證軟件質(zhì)量保證是由兩個不同人群相聯(lián)系的多種任務組成——分別是做技術工作的軟件工程師和負有質(zhì)量策劃、監(jiān)督、記錄、分析和報告責任的軟件質(zhì)量保證組。其中，軟件工程師通過采用可靠的技術方法和措施，進行技術評審，并進行周密計劃的軟件測試來獲得質(zhì)量?？梢?，軟件測試是軟件質(zhì)量保證活動中的一部分。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.45軟件測試測試是在交付產(chǎn)品給最終用戶之前，帶著特定的目的在運行程序的過程中發(fā)現(xiàn)錯誤。測試的目的是為了發(fā)現(xiàn)測試對象的問題，而不是證明測試對象沒有問題。測試可以提高軟件的質(zhì)量嗎？軟件公司一般都有自己的測試中心或測試部門，他們的職責和作用是什么呢？讀者可能會不加思索地回答：“測試可以提高軟件產(chǎn)品的質(zhì)量！”我們說：“回答錯了”，為什么？因為測試只能發(fā)現(xiàn)軟件產(chǎn)品的“不符合項”或錯誤(Bug)，不能改正軟件產(chǎn)品的錯誤，所以不能直接提高軟件產(chǎn)品的質(zhì)量。這個問題就是軟件測試的作用。優(yōu)秀的測試團隊可在早期發(fā)現(xiàn)錯誤，使軟件維護的費用降到最低點。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.67測試顯示了什么錯誤需求符合性性能質(zhì)量跡象errorsrequirementsconformanceperformanceanindicationofquality8策略性方法測試策略為軟件開發(fā)人員提供了測試模板，且具備下述一般特征：為完成有效的測試，應該進行有效的技術評審。通過評審，許多錯誤可以在測試開始之前排除。測試開始于構(gòu)件層，然后向外“延伸”到整個基于計算機系統(tǒng)的集成。不同的測試技術適用于不同的軟件工程的方法和不同的時間點。測試由軟件開發(fā)人員和（對大型項目而言）獨立的測試組執(zhí)行。測試和調(diào)試是不同的活動，但任何測試策略都必須包括調(diào)試。9V&V（驗證與確認——VerificationandValidation）軟件測試是通常所講的更為廣泛的主題——驗證與確認的一部分。驗證是指確保軟件正確地實現(xiàn)某一特定功能的一系列活動。

確認指的是確保開發(fā)的軟件可追溯到客戶需求的另外一系列活動。Boehm[Boe81]用另一種方式說明了這兩者的區(qū)別：驗證：我們在正確地構(gòu)造產(chǎn)品嗎？確認：我們在構(gòu)造正確的產(chǎn)品嗎？10誰測試軟件？開發(fā)者獨立測試者理解系統(tǒng)，但是測試很“溫和”，由“交付”驅(qū)動。開發(fā)者的軟件分析與設計連同編碼是建設性的任務。其精心地設計和執(zhí)行測試，試圖證明其程序的正確性，而不是發(fā)現(xiàn)錯誤。必須了解系統(tǒng)，但試圖打破它，由質(zhì)量驅(qū)動。以開發(fā)者的觀點，可以認為測試是破壞性的。由一種微妙但確實存在的企圖，試圖摧毀軟件工程師所建造的大廈。developerindependenttester11測試策略系統(tǒng)工程需求分析模型設計模型代碼生成單元測試集成測試確認測試系統(tǒng)測試SystemengineeringAnalysismodelingDesignmodelingCodegenerationUnittestIntegrationtestValidationtestSystemtest12測試策略我們首先以‘小的測試’開始，隨后轉(zhuǎn)向‘大的測試’對于傳統(tǒng)的軟件我們最初關注模塊（構(gòu)件）隨后關注集成模塊對于面向?qū)ο筌浖覀兊年P注點從單獨模塊“小的測試”（傳統(tǒng)的觀點）變化到一個包含屬性和操作以及暗含溝通和協(xié)作的面向?qū)ο箢悺?3策略問題早在測試之前，就要以量化的方式規(guī)定產(chǎn)品需求。明確地陳述測試目標。了解軟件的用戶并為每類用戶建立用戶描述。指定強調(diào)“快速周期測試”的測試計劃。建立能夠測試自身的“健壯”軟件。測試之前，利用有效的正式技術評審作為過濾器。實施正式技術評審以評估測試策略和測試用例本身。為測試過程建立一種持續(xù)的改進方法。單元測試單元測試是對軟件的基本組成單元進行測試。單元可以是：函數(shù)、子過程類或類的方法獨立的過程和函數(shù)一個菜單或顯示界面TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.1415單元測試被測試的模塊測試用例結(jié)果軟件工程師moduletobetestedtestcasesresultssoftwareengineer16單元測試接口局部數(shù)據(jù)結(jié)構(gòu)邊界條件獨立路徑錯誤處理路徑測試用例被測試的模塊interfacelocaldatastructuresboundaryconditionsindependentpathserrorhandlingpathsmoduletobetestedtestcases單元測試的主要任務TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.17模塊模塊接口局部數(shù)據(jù)結(jié)構(gòu)獨立路徑測試出錯處理邊界條件

模塊接口這是對模塊接口進行的測試，檢查進出程序單元的數(shù)據(jù)流是否正確。模塊接口測試必須在任何其它測試之前進行。若數(shù)據(jù)不能正確的輸入輸出，那么其他測試都是沒有意義的。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.18

局部數(shù)據(jù)結(jié)構(gòu)在模塊工作過程中，必須測試模塊內(nèi)部的數(shù)據(jù)能否保持完整性，包括內(nèi)部數(shù)據(jù)的內(nèi)容、形式及相互關系不發(fā)生錯誤。對于局部數(shù)據(jù)結(jié)構(gòu)，應該在單元測試中注意發(fā)現(xiàn)以下幾類錯誤：（1）不正確的或不一致的類型說明。（2）錯誤的初始化或默認值。（3）錯誤的變量名，如拼寫錯誤或書寫錯誤。（4）下溢、上溢或者地址錯誤。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.19獨立路徑測試在單元測試中，最主要的測試是針對路徑的測試。測試用例必須能夠發(fā)現(xiàn)由于計算錯誤、不正確的判定或不正常的控制流而產(chǎn)生的錯誤。執(zhí)行控制結(jié)構(gòu)中的所有獨立路徑以確保模塊中的所有語句至少能執(zhí)行一次。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.20出錯處理測試出錯處理的重點是模塊在工作中發(fā)生了錯誤，其中的出錯處理設施是否有效。好的設計要求能夠預置出錯條件并設置異常處理路徑，以便當錯誤確實出現(xiàn)時重新確定路徑或徹底中斷處理。檢驗程序中的出錯處理可能面對的情況有：（1）對運行發(fā)生的錯誤描述難以理解。（2）所報告的錯誤與實際遇到的錯誤不一致。（3）出錯后，在錯誤處理之前就引起系統(tǒng)的干預。（4）例外條件的處理不正確。（5）提供的錯誤信息不足，以至于無法找到錯誤的原因。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.21邊界條件邊界測試是單元測試的最后一步，必須采用邊界值分析方法來設計測試用例，測試邊界條件，確保在達到邊界值的極限或受限處理的情形下，看模塊是否能夠正常工作。邊界測試是最重要的單元測試任務之一。軟件通常在邊界出錯。也就是說，錯誤行為往往出現(xiàn)在處理n維數(shù)組的第n個元素，或者第i次循環(huán)的第i次調(diào)用，或者遇到允許出現(xiàn)的最大、最小數(shù)值時。使用剛好小于、等于或者大于最大值或最小值的數(shù)據(jù)結(jié)構(gòu)、控制流和數(shù)值作為測試用例就很有可能發(fā)現(xiàn)錯誤。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.22何時進行單元測試單元測試常常是和代碼編寫工作同時進行的，在完成了程序編寫、復查和語法正確性驗證后，就應進行單元測試用例設計。在單元測試時，如果模塊不是獨立的程序，需要設置一些輔助測試模塊。輔助測試模塊有兩種：（1）驅(qū)動模塊(Drive)

用來模擬被測試模塊的上一級模塊，相當于被測模塊的主程序。它接收數(shù)據(jù)，將相關數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并打印出相應的結(jié)果。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.23何時進行單元測試（2）樁模塊(Stub)

用來模擬被測模塊工作過程中所調(diào)用的模塊。它們一般只進行很少的數(shù)據(jù)處理。驅(qū)動模塊和樁模塊都是額外的開銷，雖然在單元測試中必須編寫，但并不需要作為最終的產(chǎn)品提供給用戶。

TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.2425單元測試環(huán)境被測模塊樁模塊樁模塊驅(qū)動模塊結(jié)果接口局部數(shù)據(jù)結(jié)構(gòu)邊界條件獨立路徑錯誤處理路徑測試用例ModulestubstubdriverRESULTSinterfacelocaldatastructuresboundaryconditionsindependentpathserrorhandlingpathstestcases26集成測試策略集成測試是構(gòu)造軟件體系結(jié)構(gòu)的系統(tǒng)化技術，同時也是進行一些已在發(fā)現(xiàn)與接口相關的錯誤的測試。選擇：? “大爆炸”方法，非增量式的? 增量構(gòu)建策略非增量式測試非增量式測試是采用一步到位的方法來構(gòu)造測試：

——對所有模塊進行個別的單元測試后，按照程序結(jié)構(gòu)圖將各模塊連接起來，把連接后的程序當作一個整體進行測試。非增量式測試的缺點：

——當一次集成的模塊較多時，非增量式測試容易出現(xiàn)混亂，因為測試時可能發(fā)現(xiàn)了許多故障，為每一個故障定位和糾正非常困難，并且在修正一個故障的同時，可能又引入了新的故障，新舊故障混雜，很難判定出錯的具體原因和位置。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.27增量式測試增量式測試的集成是逐步實現(xiàn)的：——逐次將未曾集成測試的模塊和已經(jīng)集成測試的模塊（或子系統(tǒng)）結(jié)合成程序包，再將這些模塊集成為較大系統(tǒng)，在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。按照不同的實施次序，增量式集成測試又可以分為三種不同的方法：（1）自頂向下增量式測試（2）自底向上增量式測試（3）三明治測試——混合增量測試TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.28自頂向下增量式測試自頂向下增量式測試表示逐步集成和逐步測試是按照結(jié)構(gòu)圖自上而下進行的，即模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結(jié)構(gòu)向下進行集成。從屬于主控模塊的按深度優(yōu)先方式（縱向）或者廣度優(yōu)先方式（橫向）集成到結(jié)構(gòu)中去。深度優(yōu)先方式的集成：——首先集成在結(jié)構(gòu)中的一個主控路徑下的所有模塊，主控路徑的選擇是任意的。廣度優(yōu)先方式的集成：——首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.2930自頂向下集成帶樁的頂層模塊測試一次替換一個樁模塊，“深度優(yōu)先”當集成新的模塊時，重新運行某些測試子集ABCDEFGtopmoduleistestedwithstubsstubsarereplacedoneatatime,"depthfirst"asnewmodulesareintegrated,somesubsetoftestsisre-run自底向上增量式測試自底向上增量式測試表示逐步集成和逐步測試的工作是按結(jié)構(gòu)圖自下而上進行的，即從程序模塊結(jié)構(gòu)的最底層模塊開始集成和測試。由于是從最底層開始集成，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)集成并測試完成，所以不再需要使用樁模塊進行輔助測試。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.3132自底向上集成一次替換一個驅(qū)動模塊，“深度優(yōu)先”集成工作模塊并將其分組為簇ABCDEFG簇driversarereplacedoneatatime,"depthfirst"workermodulesaregroupedintobuildsandintegratedcluster33三明治測試帶樁測試頂層模塊ABCDEFG簇集成工作模塊并將其分組為簇TopmodulesaretestedwithstubsWorkermodulesaregroupedintobuildsandintegratedcluster混合增量式測試是把自頂向下測試和自底向上測試這兩種方式結(jié)合起來進行集成和測試。這樣可以兼具兩者的優(yōu)點，而摒棄其缺點。34回歸測試回歸測試重新執(zhí)行已測試過的某些子集，以確保變更沒有傳播不期望的副作用。無論什么時候修正軟件，軟件配置的某些方面（程序、文檔或支持數(shù)據(jù)）也發(fā)生變更?；貧w測試有助于保證變更（由于測試或其他原因）不引入無意識行為或額外的錯誤?；貧w測試可以手工進行，方法是重新執(zhí)行所有測試用例的子集，或者利用捕捉/回放工具自動進行。35冒煙測試為生產(chǎn)軟件創(chuàng)建“每日構(gòu)建”的一種常見方法冒煙測試步驟：將已經(jīng)轉(zhuǎn)換為代碼的軟件構(gòu)件集成到“構(gòu)建”中去。

一個構(gòu)建包括所有的數(shù)據(jù)文件、庫、可復用的模塊以及實現(xiàn)一個或多個產(chǎn)品功能所需的工程化構(gòu)件。設計一系列測試以暴露影響構(gòu)建正確地完成其功能的錯誤。其目的是為了發(fā)現(xiàn)極有可能造成項目延遲的“業(yè)務阻塞”錯誤。每天將該構(gòu)建與其他構(gòu)建及整個軟件產(chǎn)品（以其當前的形式）集成起來進行冒煙測試。這種集成方法可以是自頂向下，也可以自底向上。36面向?qū)ο鬁y試通過評估分析和設計模型的正確性和一致性開始測試策略改變由于封裝，‘單元’的概念擴展。封裝的類通常是單元測試的重點，類中包含的操作是最小的可測試單元。面向?qū)ο筌浖念悳y試等同于傳統(tǒng)軟件的單元測試。集成側(cè)重于類和它們跨線程的執(zhí)行或使用場景的環(huán)境確認使用傳統(tǒng)的黑盒方法測試用例的設計借鑒了傳統(tǒng)方法，但是也包含了特殊的特征。37擴展“測試”的視野可以肯定，面向?qū)ο蠓治龊驮O計模型的評審非常有用，因為相同的語義結(jié)構(gòu)（例如，類、屬性、操作、消息）出現(xiàn)在分析、設計和代碼層。因此，在分析期間所發(fā)現(xiàn)的類屬性的定義問題會防止副作用的發(fā)生，如果問題直到設計或編碼階段（或者是分析的下一輪迭代）還沒有發(fā)現(xiàn)，副作用就會發(fā)生。38測試CRC模型檢查CRC模型和對象-關系模型。檢查每一張CRC索引片的描述以確定委托責任是定義協(xié)作者的一部分。反轉(zhuǎn)連接，確保每個提供服務的協(xié)作者都從合理的地方收到請求。使用步驟3中反轉(zhuǎn)后的結(jié)果，確定是否真正需要其他類，或者責任在類之間的組織是否合適。確定是否可以將廣泛請求的多個責任組合為一個責任。將步驟1到步驟5反復應用到每個類及分析模型的每一次評估中。39OO測試策略類測試相當于單元測試測試類中的操作檢查類中的狀態(tài)行為集成測試應用三種不同的策略基于線程的測試——對響應系統(tǒng)的一個輸入或事件所需的一組類進行集成基于使用的測試——對響應系統(tǒng)的一個使用用例所需的一組類進行集成簇測試——對演示一個協(xié)作所需的一組類進行集成40WebApp測試-I對WebApp的內(nèi)容模型進行評審，以發(fā)現(xiàn)錯誤。對接口模型進行評審，保證適合所有的用例。對WebApp的設計模型進行評審，以發(fā)現(xiàn)導航錯誤。測試用戶界面，發(fā)現(xiàn)表現(xiàn)機制和（或）導航機制中的錯誤。對每個功能構(gòu)件進行單元測試。41WebApp測試-II對貫穿體系結(jié)構(gòu)的導航進行測試。在各種不同的環(huán)境配置下，實現(xiàn)WebApp，并測試WebApp對于每一種配置的兼容性。進行安全性測試，試圖攻擊WebApp或其所處環(huán)境弱點。進行性能測試。通過可監(jiān)控的最終用戶群對WebApp進行測試。對他們與系統(tǒng)的交互結(jié)果進行評估，包括內(nèi)容和導航錯誤、適用性、兼容性、WebApp的可靠性及性能。42高階測試確認測試關注點是軟件需求確認測試也稱為合格性測試，是檢驗所開發(fā)的軟件是否能按用戶提出的要求進行。軟件確認要通過一系列證明軟件功能和要求一致的黑盒測試來完成，傳統(tǒng)軟件、面向?qū)ο筌浖癢ebApp之間的差別已經(jīng)消失。系統(tǒng)測試關注點是系統(tǒng)集成由于軟件只是計算機系統(tǒng)中的一個組成部分，軟件開發(fā)完成之后，最終還要和系統(tǒng)中的硬件系統(tǒng)、某些支持軟件、數(shù)據(jù)信息等其他部分配套運行。這些測試已經(jīng)超出軟件過程范圍，而且不僅僅由軟件工程師執(zhí)行。α/β測試關注點是客戶使用α測試是由有代表性的最終用戶在開發(fā)者的現(xiàn)場進行的，開發(fā)者在后面觀看，并記錄錯誤和使用問題。β測試是在一個或者多個最終用戶場所進行。開發(fā)者通常不在場。高階測試恢復測試通過各種方式強制地使軟件發(fā)生故障，并驗證其能適當恢復。安全測試驗證建立在系統(tǒng)內(nèi)的保護機制是否能夠?qū)嶋H保護系統(tǒng)不受非法入侵。壓力測試

以非正常的數(shù)量、頻率或容量的方式執(zhí)行系統(tǒng)。測試是想要破壞程序。舉例：—如果正常的中斷頻率為每秒5次，強度測試設計為每秒50次中斷?！演斎霐?shù)據(jù)的量提高一個數(shù)量級來測試輸入功能會如何響應?！裟诚到y(tǒng)正常運行可支持200個終端并行工作，強度測試則檢驗1000個終端并行工作的情況。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.43高階測試性能測試用來測試軟件在集成環(huán)境中的運行性能，特別是針對實時系統(tǒng)和嵌入式系統(tǒng)，僅提供符合功能需求但不符合性能需求的軟件是不能被接受的。性能測試可以在測試過程的任意階段進行，但只有當整個系統(tǒng)的所有成分都集成在一起后，才能檢查一個系統(tǒng)的真正性能。性能測試常常和強度（壓力）測試結(jié)合起來進行，而且常常需要硬件和軟件測試設備，這就是說，常常有必要在一種苛刻的環(huán)境中衡量資源的使用（比如，處理器周期）。TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitioner’sApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.4445調(diào)試：一個診斷過程調(diào)試出現(xiàn)在成功的測試之后。也就是說，當測試用例發(fā)現(xiàn)錯誤時，調(diào)試是使錯誤消除的過程。調(diào)試就是查找問題癥狀與其產(chǎn)生原因之間的聯(lián)系尚未得到很好理解的智力過程46調(diào)試過程回歸測試測試用例附加測試修正識別的原因調(diào)試推測的原因結(jié)果47調(diào)試結(jié)果診斷癥狀并確定原因所需的時間修正錯誤并執(zhí)行回歸測試所需的時間timerequiredtodiagnosethesymptomanddeterminethecausetimerequiredtocor