軟件工程理論與實(shí)踐課件：第8章 程序的測(cè)試

1、Testing the Programs 程序的測(cè)試SOFTWARE ENGINEERING 8.1 Software fault and failures 軟件故障和失效How does software fail 哪些因素使得系統(tǒng)失效?The specification may be wrong or have a missing requirement.需求說明是錯(cuò)誤的，或者遺漏了某個(gè)需求。The specification may contain a requirement that is impossible to implement, given the prescribed ha

2、rdware and software. 由于規(guī)定的硬件和軟件的原因，說明中包含不可能實(shí)現(xiàn)的需求 。The system design may contain a fault. 系統(tǒng)設(shè)計(jì)中包含錯(cuò)誤。The program design may contain a fault. The component descriptions may contain an access control algorithm that does not handle this case correctly. 程序設(shè)計(jì)中包含錯(cuò)誤。組件描述可能包含不能正確處理這種情況的訪問控制算法。The program code

3、 may be wrong. It may implement the algorithm improperly or incompletely. 程序代碼有錯(cuò)誤。代碼對(duì)算法的實(shí)現(xiàn)可能不正確或不完整。Our goal is to discover faults, we consider a test successful only when a fault is discovered or a failure occurs as a result of our testing procedures.我們的目標(biāo)是發(fā)現(xiàn)錯(cuò)誤。因?yàn)橹挥邪l(fā)現(xiàn)了錯(cuò)誤、或者由于測(cè)試過程而使程序發(fā)生失效，測(cè)試才稱得上成功。F

4、ault identification is the process of determining what fault or faults caused the failure. 錯(cuò)誤確定是判定什么錯(cuò)誤引發(fā)了失效的過程。Fault correction or fault removal is the process of making changes to the system so the faults are removed. 錯(cuò)誤糾正或去除是改動(dòng)系統(tǒng)以去除錯(cuò)誤的過程。Types of faults 錯(cuò)誤類型Algorithmic fault 算法錯(cuò)誤Syntax fault 語(yǔ)法錯(cuò)誤C

5、omputation and precision fault 計(jì)算和精度錯(cuò)誤Documentation fault 文檔錯(cuò)誤Stress or overload fault 強(qiáng)度或過載錯(cuò)誤Capacity or boundary fault 能力或邊界錯(cuò)誤Timing or coordination fault 計(jì)時(shí)或協(xié)調(diào)錯(cuò)誤Throughput or performance fault 吞吐量或性能錯(cuò)誤Recovery fault 恢復(fù)錯(cuò)誤Hardware and system software fault 硬件和系統(tǒng)軟件錯(cuò)誤Standards and procedures fault 標(biāo)準(zhǔn)

6、和規(guī)程錯(cuò)誤Explanation of types of faults 錯(cuò)誤類型說明An algorithmic fault occurs when a components algorithm or logic does not produce the proper output for a given input because something is wrong with the processing steps.當(dāng)由于處理步驟中的某些錯(cuò)誤，使得一個(gè)組件的算法或邏輯對(duì)一個(gè)給定的輸入不能產(chǎn)生正確的輸出時(shí)，出現(xiàn)的是算法錯(cuò)誤。Compilers catch many of our Synta

7、x faults for us.編譯器查找的是語(yǔ)法錯(cuò)誤。Computation and precision faults occur when a formulas implementation is wrong or does not compute the result to the required degree of accuracy 當(dāng)一個(gè)公式的實(shí)現(xiàn)是錯(cuò)誤的，或者計(jì)算結(jié)果沒有達(dá)到要求的精度時(shí)出現(xiàn)計(jì)算錯(cuò)誤和精度錯(cuò)誤。Explanation of types of faults 錯(cuò)誤類型說明When the documentation does not match hat the pro

8、gram actually does, we say that the program has documentation faults.當(dāng)文檔與程序?qū)嶋H做的事情不相符時(shí)，我們稱該程序有文檔錯(cuò)誤。Stress or overload faults occur when these data structures are filled past their specified capacity.當(dāng)數(shù)據(jù)結(jié)構(gòu)被填充得超過了它們規(guī)定的能力時(shí)，發(fā)生的是強(qiáng)度錯(cuò)誤或過載錯(cuò)誤。Capacity or boundary faults occur when the systems performance beco

9、mes unacceptable as system activity reaches its specified limit.當(dāng)系統(tǒng)活動(dòng)達(dá)到規(guī)定的極限時(shí)系統(tǒng)性能變得不可接受，稱為能力錯(cuò)誤或邊界錯(cuò)誤。Explanation of types of faults 錯(cuò)誤類型說明Timing or coordination faults occur when the code coordinating events is inadequate.當(dāng)系統(tǒng)不能按需求滿足順序的協(xié)調(diào)性時(shí)出現(xiàn)計(jì)時(shí)錯(cuò)誤或協(xié)調(diào)錯(cuò)誤。Throughput or performance faults occur when the sy

10、stem does not perform at the speed prescribed by the requirement.當(dāng)系統(tǒng)不能以需求規(guī)定的速度執(zhí)行任務(wù)時(shí)出現(xiàn)吞吐量錯(cuò)誤或性能錯(cuò)誤。Recovery faults can occur when a failure is encountered and the system does not behave as the designers desire or as the customer requires.當(dāng)遇到一次失效，而系統(tǒng)不能像設(shè)計(jì)時(shí)希望的或顧客要求的那樣運(yùn)轉(zhuǎn)時(shí)，出現(xiàn)的是恢復(fù)錯(cuò)誤。Explanation of types of

11、faults 錯(cuò)誤類型說明Hardware and system software faults can arise when the supplied hardware and system software do not actually work according to the documented operating conditions and procedures.當(dāng)提供的硬件和系統(tǒng)軟件實(shí)際上并沒有按照文檔記錄的操作條件和步驟運(yùn)行時(shí)，發(fā)生的是硬件和系統(tǒng)軟件錯(cuò)誤。Standards and procedure faults may not always affect the run

12、ning of the program, but they may foster an environment where faults are created as the system is tested and modified.標(biāo)準(zhǔn)和規(guī)程錯(cuò)誤并不總影響程序的運(yùn)行，但他們可能會(huì)產(chǎn)生系統(tǒng)測(cè)試和改動(dòng)時(shí)產(chǎn)生錯(cuò)誤的環(huán)境。orthogonal defect classification 正交故障分類It is useful to categorize track the types of faults. Many organizations perform statistical fault mo

13、deling and causal analysis, both of which depend on understanding the number and distribution of types of faults.對(duì)錯(cuò)誤類型進(jìn)行分類和跟蹤是很有用的。許多機(jī)構(gòu)進(jìn)行統(tǒng)計(jì)錯(cuò)誤建模和原因分析都依賴于對(duì)錯(cuò)誤的數(shù)目和類型分布的理解。IBM have developed an approach to fault tracking called orthogonal defect classification. One of the key features of orthogonal defec

14、t classification is its orthogonal.IBM開發(fā)了一種進(jìn)行錯(cuò)誤跟蹤的方法，稱為正交故障分類。正交故障分類的一個(gè)關(guān)鍵特征是它的正交性。IBM orthogonal defect classification Function Fault功能錯(cuò)誤： Fault that affects capability, end-user interfaces, product interfaces, interface with hardware architecture, or global data structure.影響能力、最終用戶接口、與硬件體系結(jié)構(gòu)的接口或全局?jǐn)?shù)

15、據(jù)結(jié)構(gòu)的錯(cuò)誤。 Interface Fault 接口錯(cuò)誤：Fault in interacting with other components or drivers via calls, macros, control blocks or parameter lists.通過調(diào)用、宏、控制塊或參數(shù)表與其他組件交互時(shí)出現(xiàn)的錯(cuò)誤。 Checking Fault檢查錯(cuò)誤：Fault in program logic that fails to validate data and values properly before they are used.在數(shù)據(jù)和值使用之前不能正確地對(duì)其確認(rèn)的程序邏輯錯(cuò)

16、誤。 Assignment Fault賦值錯(cuò)誤：Fault in data structure or code block initialization.數(shù)據(jù)結(jié)構(gòu)或代碼塊初始化的錯(cuò)誤。Timing/serialization Fault計(jì)時(shí)/串行錯(cuò)誤：Fault that involves timing of shared and real-time resources.涉及共享資源或?qū)崟r(shí)資源計(jì)時(shí)的錯(cuò)誤。Build/package/merge Fault構(gòu)建/打包/合并錯(cuò)誤：Fault that occurs because of problems in repositories, manag

17、ement changes, or version control.由于倉(cāng)庫(kù)、管理變動(dòng)或版本控制的問題等而出現(xiàn)的錯(cuò)誤。Documentation Fault文檔錯(cuò)誤： Fault that affects publications and maintenance notes.影響發(fā)布和維護(hù)注釋的錯(cuò)誤。Algorithm Fault算法錯(cuò)誤： Fault involving efficiency or correctness of algorithm or data structure but not design.涉及算法或數(shù)據(jù)結(jié)構(gòu)的效率或正確性但與設(shè)計(jì)無(wú)關(guān)的錯(cuò)誤。HP Fault Class

18、ification錯(cuò)誤起源錯(cuò)誤類型錯(cuò)誤模式Faults for One HPs Division3218545191168.2 Testing Issues 測(cè)試的有關(guān)事項(xiàng)測(cè)試定義：測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程；好的測(cè)試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試方案；成功的測(cè)試是發(fā)現(xiàn)了迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試 。測(cè)試的意義和幾點(diǎn)說明至今為止，測(cè)試仍然是軟件質(zhì)量保證的最重要手段。測(cè)試是證實(shí)軟件需求說明的功能是否實(shí)現(xiàn)，是否達(dá)到預(yù)期的指標(biāo)的最有效手段。軟件測(cè)試耗時(shí)費(fèi)力，追求用最小的測(cè)試代價(jià)獲得最大的測(cè)試效果。測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤，不是為了證明程序無(wú)錯(cuò)誤。測(cè)試不能證明程序中沒有錯(cuò)誤。

19、測(cè)試的可信度（dependability)問題Testing Principles 測(cè)試指導(dǎo)原則所有的測(cè)試都應(yīng)追溯到用戶需求，從用戶角度看，最嚴(yán)重的錯(cuò)誤是不能滿足用戶需求。制定測(cè)試計(jì)劃，并嚴(yán)格執(zhí)行，排除隨意性。測(cè)試計(jì)劃在需求分析階段就開始了，詳細(xì)的測(cè)試用例在設(shè)計(jì)階段確定。Pareto原則：所發(fā)現(xiàn)錯(cuò)誤的80%很可能源于程序模塊的20%中。測(cè)試應(yīng)當(dāng)從“小規(guī)?！遍_始，逐步轉(zhuǎn)向“大規(guī)?！?。窮舉測(cè)試是不可能的（Exhaustive testing）。由獨(dú)立的第三方或?qū)ｉT的測(cè)試小組進(jìn)行獨(dú)立測(cè)試。Testing Principles 測(cè)試指導(dǎo)原則測(cè)試用例由輸入數(shù)據(jù)和相應(yīng)的預(yù)期輸出組成。測(cè)試用例不僅選用合理的

20、輸入數(shù)據(jù)，還要選擇不合理的。不僅檢查程序是否做了應(yīng)該做的事，還應(yīng)該檢查是否不應(yīng)該做的。長(zhǎng)期保留測(cè)試用例，以便進(jìn)行回歸測(cè)試和維護(hù)。測(cè)試技術(shù)的分類靜態(tài)測(cè)試辦公桌檢查 desk checking走查 walk-through代碼會(huì)審 code inspection動(dòng)態(tài)測(cè)試黑盒測(cè)試白盒測(cè)試窮舉和選擇測(cè)試。靜態(tài)測(cè)試定義人工方式進(jìn)行的代碼復(fù)審。目的檢查程序靜態(tài)結(jié)構(gòu)，找出編譯不能發(fā)現(xiàn)的錯(cuò)誤和人的主觀認(rèn)識(shí)上偏差。范圍需求定義、設(shè)計(jì)文檔、源代碼（著重分析）特點(diǎn)研究表明，對(duì)于某些類型的錯(cuò)誤，靜態(tài)測(cè)試更有效 。經(jīng)驗(yàn)表明，組織良好的代碼復(fù)審可以發(fā)現(xiàn)程序中30%到70%的編碼和邏輯設(shè)計(jì)錯(cuò)誤。不存在錯(cuò)誤定位問題。動(dòng)態(tài)測(cè)試

21、定義在設(shè)定的測(cè)試數(shù)據(jù)上執(zhí)行被測(cè)試程序的過程。目的通過執(zhí)行程序代碼動(dòng)態(tài)地驗(yàn)證結(jié)果的正確性。三個(gè)過程：設(shè)計(jì)測(cè)試用例（test case)執(zhí)行被測(cè)試程序分析執(zhí)行結(jié)果并發(fā)現(xiàn)錯(cuò)誤三個(gè)要素：程序、測(cè)試數(shù)據(jù)、需求定義兩個(gè)方面：在測(cè)試數(shù)據(jù)上程序是對(duì)的測(cè)試數(shù)據(jù)是正確的黑盒測(cè)試（功能測(cè)試）定義：已知產(chǎn)品應(yīng)該具有的功能，通過測(cè)試檢驗(yàn)其每個(gè)功能是否都能夠正常使用。又稱功能測(cè)試。用途：把程序看成一個(gè)黑盒子，僅僅考慮輸入和輸出的對(duì)應(yīng)關(guān)系和程序接口，完全不考慮它的內(nèi)部結(jié)構(gòu)和處理過程。一般用于綜合測(cè)試、系統(tǒng)測(cè)試等。白盒測(cè)試（結(jié)構(gòu)測(cè)試 ）定義已知產(chǎn)品內(nèi)部的工作過程，通過測(cè)試檢驗(yàn)產(chǎn)品內(nèi)部動(dòng)作是否都能按照需求定義的規(guī)定正常使用。用

22、途必須完全了解程序的內(nèi)部結(jié)構(gòu)和處理過程，才能按照程序內(nèi)部的邏輯測(cè)試，以檢驗(yàn)程序中每條路徑是否正確，因此 一般用于規(guī)模較小的程序和單元測(cè)試。窮舉測(cè)試 (Exhaustive testing)定義包含所有可能情況的測(cè)試。對(duì)于黑盒測(cè)試，必須對(duì)所有輸入數(shù)據(jù)的各種可能值的排列組合都進(jìn)行測(cè)試；對(duì)于白盒測(cè)試，程序中每條可能的路徑在每種可能的輸入數(shù)據(jù)下至少執(zhí)行一次。窮舉測(cè)試是不可能的。例一：要對(duì)C編譯系統(tǒng)進(jìn)行黑盒窮舉測(cè)試，一方面要編出所有能夠想象出來的合法程序讓它編譯；另一方面又要編出一切不合法的程序，考察它能否指出程序的非法性質(zhì)。顯然，這兩類（合法和不合法）程序的數(shù)量是無(wú)限的。選擇測(cè)試僅選擇一些具有代表的、

23、典型的測(cè)試用例，進(jìn)行有限的測(cè)試。以最少的測(cè)試用例發(fā)現(xiàn)最多的程序錯(cuò)誤。Testing Issues 測(cè)試的有關(guān)事項(xiàng)Test organizationAttitudes toward testingWho performs the testsViews of the test objects測(cè)試的組成測(cè)試態(tài)度由誰(shuí)進(jìn)行測(cè)試對(duì)測(cè)試對(duì)象的看法Test organization 測(cè)試的組成Several Test Stages for large system 大型系統(tǒng)測(cè)試的幾個(gè)階段Module test, component test, unit test 模塊測(cè)試、組件測(cè)試、單元測(cè)試Integrati

24、on test 集成測(cè)試Function test 功能測(cè)試Performance test 性能測(cè)試Acceptance test 驗(yàn)收測(cè)試Installation test 安裝測(cè)試Testing stepsUnittestIntegrationtestUnittestUnittestInstallationtestPerformancetestFunctiontestAcceptancetestDesignspecificationSystemfunctionalrequirementsOther software requirementCustomer requirement spec

25、ificationUser environmentIntegrated modulesFunctioning systemVerified, validated software Accepted system System in use!Component codeTested component.系統(tǒng)測(cè)試Attitudes toward testing 測(cè)試態(tài)度The goal as a developer should be to eliminate as many faults as possible, no matter where in the system they occur

26、and no matter who created them. When a fault is discovered or a failure occurs, we are concerned with correcting the fault, not with placing blame on a particular developer.作為開發(fā)人員的目標(biāo)是盡可能多地消除錯(cuò)誤，無(wú)論這些錯(cuò)誤出現(xiàn)在系統(tǒng)的何處，也無(wú)論是誰(shuí)創(chuàng)造它們。當(dāng)發(fā)現(xiàn)一個(gè)錯(cuò)誤或出現(xiàn)一次失效時(shí)，我們關(guān)注的是糾正錯(cuò)誤，而不是譴責(zé)某個(gè)開發(fā)人員。Who performs the tests？由誰(shuí)進(jìn)行測(cè)試？We often use

27、an independent test team to test a system. In this way, we avoid conflict between personal responsibility for faults and the need to discover as many faults as possible.通常由一個(gè)獨(dú)立的測(cè)試小組來測(cè)試系統(tǒng)。用這種方式避免了個(gè)人對(duì)錯(cuò)誤負(fù)有的責(zé)任和發(fā)現(xiàn)盡可能多錯(cuò)誤的需要之間的沖突。Views of the test objects 對(duì)測(cè)試對(duì)象的看法As you test a component, group of component

28、, subsystem, or system, your view of the test object can affect the way in which testing proceeds. 當(dāng)測(cè)試一個(gè)組件、組件群、子系統(tǒng)、或系統(tǒng)時(shí)，你對(duì)測(cè)試對(duì)象的看法可能影響測(cè)試進(jìn)行的方式。8.3 Unit Testing 單元測(cè)試單元測(cè)試主要評(píng)價(jià)模塊的五個(gè)特性模塊接口局部數(shù)據(jù)類型重要的執(zhí)行通路出錯(cuò)處理通路影響以上特性的邊界條件單元測(cè)試過程檢查代碼證明代碼正確性測(cè)試程序組件Examining the Code 檢查代碼Two types of code reviewCode WalkthroughsCo

29、de InspectionsSuccess of Code Reviews兩種代碼評(píng)審方法代碼預(yù)排代碼審查代碼評(píng)審的成功 典型的審查準(zhǔn)備時(shí)間和會(huì)議時(shí)間Table 8.2. Typical inspection preparation and meeting times.Development artifact開發(fā)工作Preparation time準(zhǔn)備時(shí)間Meeting time會(huì)議時(shí)間Requirements document25 pages per hour12 pages per hourFunctional specification45 pages per hour15 pages

30、per hourLogic specification50 pages per hour20 pages per hourSource code150 lines of code per hour75 lines of code per hourUser documents35 pages per hour20 pages per hour 發(fā)現(xiàn)活動(dòng)中找到的錯(cuò)誤Table 8.3. Faults found during discovery activities.Discovery activity發(fā)現(xiàn)活動(dòng)Faults found per thousand lines of code每千行代碼

31、發(fā)現(xiàn)的錯(cuò)誤Requirements review2.5Design review5.0Code inspection10.0Integration test3.0Acceptance test2.0Proving code correct 證明代碼正確性Formal proof techniquesSymbolic executionAutomated theorem-proving形式證明技術(shù)符號(hào)執(zhí)行自動(dòng)定理證明Testing program components 測(cè)試程序組件Testing versus proving 測(cè)試與證明 A proof tells us how a progra

32、m will work in a hypothetical environment described by the design and requirements, testing gives us information about how a program works in its actual operating environment.一個(gè)證明告訴我們?cè)谠O(shè)計(jì)和需求描述的假設(shè)環(huán)境下，程序?qū)⒃鯓舆\(yùn)行，測(cè)試提供了在實(shí)際的操作環(huán)境中程序怎樣運(yùn)行的有關(guān)消息。Choosing test cases 選擇測(cè)試實(shí)例 We begin by determining our test objectiv

33、es. Then, we select test cases designed to meet a specific objective. One objective may be to demonstrate that all statements execute properly. Another may be to show that every function performed by the code is done correctly. The objectives determine how we classify the input in order to choose ou

34、r test cases.首先決定測(cè)試目標(biāo)。然后選擇測(cè)試實(shí)例、定義旨在滿足特定目標(biāo)的測(cè)試。有的目標(biāo)是證明所有的語(yǔ)句都正確執(zhí)行。有的目標(biāo)是證明代碼執(zhí)行的每個(gè)功能都是正確完成的。目標(biāo)決定了怎樣對(duì)輸入分類從而選擇測(cè)試實(shí)例。Test thoroughness 測(cè)試的徹底性To perform a test, we decide how to demonstrate in a convincing way that the test data exhibit all possible behaviors. To test code thoroughly, we can choose test cases

35、 using at least one of several approaches based on the data manipulated by the code:為了進(jìn)行一個(gè)測(cè)試，應(yīng)當(dāng)以一種有說服力的方式來證明該測(cè)試數(shù)據(jù)展示了所有可能的行為。為了徹底地測(cè)試代碼，根據(jù)代碼處理的數(shù)據(jù)，至少可以用下面幾種方法之一來選擇測(cè)試實(shí)例：Statement testing（語(yǔ)句測(cè)試）：every statement in the component is executed at least once in some test.組件中的每個(gè)語(yǔ)句在某些測(cè)試中至少執(zhí)行一次。Branch testing（分支測(cè)

36、試）：for every decision point in the code, each branch is chosen at least once in some test.對(duì)代碼中的每個(gè)判定點(diǎn)，每個(gè)分支在某些測(cè)試中至少選擇一次。Path testing（路徑測(cè)試）：every distinct path through the code is executed at least once in some test.貫穿代碼的每條路徑在某次測(cè)試中至少執(zhí)行一次。Definition-use path testing（定義使用測(cè)試）：every path from every definit

37、ion of every variable to every use of that definition is exercised in some test.從每個(gè)變量的定義到該定義的使用的每一條路徑，都在某些測(cè)試中執(zhí)行。（All-uses testing）所有使用的路徑測(cè)試:the test set includes at least one path from every definition to every use that can be reached by that definition.測(cè)試集至少包含這樣一條路徑，它從每一個(gè)定義到該定義能到達(dá)的所有使用。All-predicat

38、e-uses/some-computational-uses testing（所有判定使用/某些計(jì)算使用的測(cè)試）：for every variable and every definition of that variable, a test includes at least one path from the definition to every predicate use; if there are definitions not covered by that description, then include computational uses so that every def

39、initions is covered.對(duì)每個(gè)變量和該變量的定義，測(cè)試至少包含了這樣的一條路徑，它從該定義到每個(gè)判斷的使用；如果有定義沒有被這個(gè)描述覆蓋，那么加入計(jì)算的使用以便覆蓋每個(gè)定義。All-computational-uses/some-predicate-uses testing（所有計(jì)算使用/某些判定使用的測(cè)試）： for every variable and every definition of that variable, a test includes at least one path from the definition to every computational

40、use; if there are definitions not covered by that description, then include predicate uses so that every definitions is covered.對(duì)每個(gè)變量和該變量的定義，測(cè)試至少包含了這樣的一條路徑，它從該定義到每個(gè)計(jì)算的使用；如果有定義沒有被這個(gè)描述覆蓋，那么加入判定的使用以便覆蓋每個(gè)定義。 所有路徑 所有定義 使用路徑 所有使用 所有計(jì)算/ 某些判定使用 所有判定/ 某些計(jì)算使用 所有計(jì)算使用 所有定義 所有判定使用 分支 語(yǔ)句 Relative strengths of tes

41、t strategies 測(cè)試策略的相對(duì)強(qiáng)度Ntafos shows random testing (not test strategies) found 79.5% faultsbranch testing found 85.5%, andall-uses testing found 90%Stronger strategy means more test cases策略越強(qiáng)、涉及的測(cè)試實(shí)例越多。Logic Flow 邏輯流Statement testing1,2,3,4,5,6,7branch testing1,2,3,4,5,6,71,2,4,5,6,1path testing1,2,3

42、,4,5,6,71,2,3,4,5,6,11,2,4,5,6,71,2,4,5,6,1Comparing techniques 技術(shù)比較Fault discovery percentages by fault origin 由錯(cuò)誤起源發(fā)現(xiàn)錯(cuò)誤的百分比發(fā)現(xiàn)技術(shù)起源需求設(shè)計(jì)編碼文檔原型化40353515需求評(píng)審401505設(shè)計(jì)評(píng)審1555015代碼審查20406525單元測(cè)試15200Effectiveness of fault-discovery techniques錯(cuò)誤發(fā)現(xiàn)技術(shù)的效果需 求錯(cuò) 誤設(shè) 計(jì)錯(cuò) 誤編 碼錯(cuò) 誤文 檔錯(cuò) 誤評(píng)審一般極好極好好原型化好一般一般不適用測(cè)試壞壞好一般正確性證明

43、壞壞一般一般8.4 Integration testing 集成測(cè)試When we are satisfied that individual components are working correctly and meet our objectives, we combine them into a working system. This integration is planned and coordinated so that when a failure occurs, we have some idea of what caused it.集成測(cè)試也稱為組裝測(cè)試。當(dāng)對(duì)單個(gè)組件的正

44、確運(yùn)行情況滿意、認(rèn)為它們達(dá)到了目標(biāo)之后，將它們組合成一個(gè)工作系統(tǒng)。通過策劃和調(diào)整這種集成方式，當(dāng)出現(xiàn)錯(cuò)誤后能大致了解是什么導(dǎo)致了這個(gè)錯(cuò)誤。集成測(cè)試的方法Bottom-upTop-downBig-bangSandwich testingModified top-downModified sandwich自底向上自頂向下一次性三明治測(cè)試改進(jìn)自頂向下改進(jìn)三明治 Bottom-up測(cè)試步驟自底向上由一個(gè)葉模塊開始，自底向上逐步添加新模塊，組成程序的一個(gè)子系統(tǒng)或具有某一功能的模塊族（群Cluster)設(shè)計(jì)驅(qū)動(dòng)程序，協(xié)調(diào)測(cè)試數(shù)據(jù)的輸入和輸出測(cè)試去掉驅(qū)動(dòng)模塊，沿軟件結(jié)構(gòu)自下而上移動(dòng)，把有關(guān)的子系統(tǒng)結(jié)合，形成

45、更大的子系統(tǒng)。 Bottom-up測(cè)試示例ABDCEFGTestETestFTestGTestD,GTestCTestB,E,FTestA,B,C,D,E,F,GTop-down 測(cè)試步驟測(cè)試主控模塊，由樁模塊代替所有直屬模塊根據(jù)所確定的組合策略增加一個(gè)模塊，設(shè)計(jì)新的樁模塊。測(cè)試，如果在新的條件下發(fā)現(xiàn)新的錯(cuò)誤，執(zhí)行下一步；否則執(zhí)行上一步?；貧w測(cè)試（全部或部分地重復(fù)已做過的測(cè)試并返回）Top-down測(cè)試示例ABDCEFGTestATestA,B,C,DTestA,B,C,D,E,F,G Big-bang 測(cè)試示例ABDCEFGTest ETest FTest GTest DTest CTest

46、 ATestA,B,C,D,E,F,GTest BSandwich testing 測(cè)試步驟 對(duì)上層模塊采用自頂向下，較早顯示程序的總體輪廓。目標(biāo)層（中間層）的選擇問題對(duì)某些關(guān)鍵模塊（如具有I/O功能的模塊、功能重要或含有特殊算法的模塊）或子系統(tǒng)采用自底向上組裝和測(cè)試，以便容易地產(chǎn)生測(cè)試用例或減少重復(fù)測(cè)試次數(shù)。 Sandwich 集成策略示例ABDCEFGTestETestFTestGTestATestD,GTestB,E,FTestA,B,C,D,E,F,G Modified Top-down測(cè)試示例TestBTestCTestDTestGTestFTestETestA,B,C,D,E,F,

47、GTestA,B,C,DTestAModified top-down測(cè)試兩種結(jié)合策略深度優(yōu)先先組裝在軟件結(jié)構(gòu)的一條主控通路上的所有模塊。寬度優(yōu)先沿軟件結(jié)構(gòu)水平地移動(dòng)，把處于同一個(gè)控制層次上的所有模塊組裝起來。 Modified Sandwich集成策略ABDCEFGTestETestFTestGTestATestD,GTestB,E,FTestA,B,C,D,E,F,GTestCTest BTest DTable 8.7. Comparison of integration strategies集成策略的比較自底向上自頂向下改進(jìn)的自頂向下一次性集成三明治改進(jìn)的三明治集成早早早晚早早能產(chǎn)生基本運(yùn)

48、作程序的時(shí)間晚早早晚早早需要組件驅(qū)動(dòng)程序是否是是是是需要存根程序否是是是是是開始工作的并行性中等低中等高中等高測(cè)試特殊路徑的能力容易難容易容易中等容易計(jì)劃和控制順序的能力容易難難容易難難Builds At Microsoft 微軟的集成方法Market-driven integration strategyWork in teamsTeam size 3 to 8 developers Different teams are responsible for different featuresEach team is allowed to change the specification of

49、 featuresThe process iterates among designing, building, testing components while involving customers in the testing process市場(chǎng)驅(qū)動(dòng)集成策略3到8人一組不同的小組負(fù)責(zé)不同的特征每個(gè)小組都可以改動(dòng)說明的特征該過程在測(cè)試過程中包含顧客的同時(shí)，在設(shè)計(jì)、構(gòu)建、測(cè)試組件之間迭代Microsoft Synch-and-stabilize approach 微軟同步且穩(wěn)定的測(cè)試方法8.5 testing object-oriented system 測(cè)試面向?qū)ο笙到y(tǒng)Testing th

50、e code 代碼測(cè)試Begin testing object-oriented system by asking several questions(通過提出幾個(gè)問題開始測(cè)試面向?qū)ο笙到y(tǒng))：When your code expects a unique value, is there a path that generates a unique result?期望代碼什么時(shí)候有一個(gè)唯一值，有一條路徑產(chǎn)生一個(gè)唯一的結(jié)果嗎？When there are many possible values, is there a way to select a unique result? 什么時(shí)候有許多可

51、能值，有一種方法選擇一個(gè)唯一的結(jié)果嗎？Are there useful cases that are not handled? 還有未經(jīng)處理的有用情況嗎？Next, make sure that you check the objects and classes themselves for excesses and deficiencies: missing objects, unnecessary classes, missing or unnecessary associations, or incorrect placement of associations or attribute

52、s.接著，確信檢查了對(duì)象和類本身的過度和不足：遺漏的類、遺漏或不必要的關(guān)系、不正確的關(guān)系或?qū)傩园才?。Objects might be missing if You find asymmetric associations or generalizationYou find disparate attributes and operations on a classOne class is playing two or more rolesAn operation has no good target classYou find two associations with the same name and purpose對(duì)象可能會(huì)遺漏，如果發(fā)現(xiàn)有不對(duì)稱的關(guān)系或類發(fā)現(xiàn)一個(gè)類中有完全無(wú)關(guān)的屬性和操作一個(gè)類承擔(dān)兩個(gè)或更多的職責(zé)一個(gè)操作沒有好的目標(biāo)類