軟件工程概論：第八章 程序的測試

1、Testing the Programs 程序的測試程序的測試SOFTWARE ENGINEERING 8.1 Software fault and failures 軟件故障和失效軟件失效機(jī)理通常將軟件失效機(jī)理描述為軟件錯誤、軟件缺陷、軟件故障和軟件失效。4個概念軟件錯誤：是指在軟件生命周期內(nèi)不希望出現(xiàn)和不可接受的人為錯誤，其結(jié)果導(dǎo)致軟件缺陷的產(chǎn)生。軟件錯誤的產(chǎn)生是一種人為過程，相對軟件本身，它是一種外部行為。 錯誤在整個軟件開發(fā)周期中很可能被擴(kuò)展，在需求階段發(fā)生的錯誤，在設(shè)計期間有可能被放大，在編寫代碼時還會進(jìn)一步擴(kuò)大。軟件缺陷：是存在于軟件（文檔、數(shù)據(jù)、程序）之中的那些不希望出現(xiàn)或不可接

2、受的偏差，例如多一條語句等。缺陷導(dǎo)致的結(jié)果是軟件運(yùn)行某一特定條件時出現(xiàn)軟件故障，稱軟件缺陷被激活。軟件故障：是軟件運(yùn)行過程中出現(xiàn)的一種不可接受或不希望出現(xiàn)的內(nèi)部狀態(tài)。例如，程序出現(xiàn)死循環(huán)，就是出現(xiàn)了軟件故障，如果無有效措施及時處理，則產(chǎn)生軟件失效。軟件故障是一種動態(tài)行為。軟件失效：是指軟件運(yùn)行時產(chǎn)生的一種不希望出現(xiàn)和不可接受的外部行為結(jié)果。四個概念之間的關(guān)系：軟件錯誤是一種人為的失誤。一個軟件錯誤必定產(chǎn)生一個或多個軟件缺陷。當(dāng)一個軟件缺陷被激活時，便產(chǎn)生了軟件故障。同一個軟件缺陷在不同的條件下被激活，可能產(chǎn)生不同的軟件故障。對于軟件故障，如果沒有容錯措施或及時處理，便不可避免地導(dǎo)致軟件失效。同

3、一軟件故障在不同條件下可能產(chǎn)生不同的軟件失效。How does software fail 哪些因素使得系統(tǒng)失效?The specification may be wrong or have a missing requirement. 需求說明是錯誤的，或者遺漏了某個需求。需求說明是錯誤的，或者遺漏了某個需求。The specification may contain a requirement that is impossible to implement, given the prescribed hardware and software. 由于規(guī)定的硬件和軟件的原因，說明中包含不可能

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

5、情況的訪問控制算法。制算法。The program code may be wrong. It may implement the algorithm improperly or incompletely. 程序代碼有錯誤。代碼對算法的實現(xiàn)可能不正確或不完整。程序代碼有錯誤。代碼對算法的實現(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 pro

6、cedures.我們的目標(biāo)是發(fā)現(xiàn)錯誤。因為只有發(fā)現(xiàn)了錯誤、或者由于測試過程而使程序發(fā)生失效，測試才稱得上成功。Fault identification is the process of determining what fault or faults caused the failure. 錯誤確定是判定什么錯誤引發(fā)了失效的過程。Fault correction or fault removal is the process of making changes to the system so the faults are removed. 錯誤糾正或去除是改動系統(tǒng)以去除錯誤的過程。Type

7、s of faults 錯誤類型Algorithmic fault 算法錯誤Syntax fault 語法錯誤Computation and precision fault 計算和精度錯誤Documentation fault 文檔錯誤Stress or overload fault 強(qiáng)度或過載錯誤Capacity or boundary fault 能力或邊界錯誤Timing or coordination fault 計時或協(xié)調(diào)錯誤Throughput or performance fault 吞吐量或性能錯誤Recovery fault 恢復(fù)錯誤Hardware and system s

8、oftware fault 硬件和系統(tǒng)軟件錯誤Standards and procedures fault 標(biāo)準(zhǔn)和規(guī)程錯誤Explanation of types of faults 錯誤類型說明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)由于處理步驟中的某些錯誤，使得一個組件的算法或邏輯對一個給定

9、的輸入不能產(chǎn)生正確的輸出時，出現(xiàn)的是算法錯誤。Compilers catch many of our Syntax faults for us.編譯器查找的是語法錯誤。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)一個公式的實現(xiàn)是錯誤的，或者計算結(jié)果沒有達(dá)到要求的精度時出現(xiàn)計算錯誤和精度錯誤。Explanation of types of faults

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

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

12、或協(xié)調(diào)錯誤。Throughput or performance faults occur when the system does not perform at the speed prescribed by the requirement.當(dāng)系統(tǒng)不能以需求規(guī)定的速度執(zhí)行任務(wù)時出現(xiàn)吞吐量錯誤或性能錯誤。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)遇到一次失效，而

13、系統(tǒng)不能像設(shè)計時希望的或顧客要求的那樣運(yùn)轉(zhuǎn)時，出現(xiàn)的是恢復(fù)錯誤。Explanation of types of faults 錯誤類型說明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)軟件實際上并沒有按照文檔記錄的操作條件和步驟運(yùn)行時，發(fā)生的是硬件和系統(tǒng)軟件錯誤。Stan

14、dards and procedure faults may not always affect the running 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ī)程錯誤并不總影響程序的運(yùn)行，但他們可能會產(chǎn)生系統(tǒng)測試和改動時產(chǎn)生錯誤的環(huán)境。orthogonal defect classification 正交故障分類正交故障分類It is useful to categorize track the ty

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

16、ct classification. One of the key features of orthogonal defect classification is its orthogonal.IBM開發(fā)了一種進(jìn)行錯誤跟蹤的方法，稱為正交故障分類。正交故障分類的一個關(guān)鍵特征是它的正交性。IBM orthogonal defect classification Function Fault功能錯誤： Fault that affects capability, end-user interfaces, product interfaces, interface with hardware arc

17、hitecture, or global data structure.影響能力、最終用戶接口、與硬件體系結(jié)構(gòu)的接口或全局?jǐn)?shù)據(jù)結(jié)構(gòu)的錯誤。 Interface Fault 接口錯誤：Fault in interacting with other components or drivers via calls, macros, control blocks or parameter lists.通過調(diào)用、宏、控制塊或參數(shù)表與其他組件交互時出現(xiàn)的錯誤。 Checking Fault檢查錯誤：Fault in program logic that fails to validate data and

18、 values properly before they are used.在數(shù)據(jù)和值使用之前不能正確地對其確認(rèn)的程序邏輯錯誤。 Assignment Fault賦值錯誤：Fault in data structure or code block initialization.數(shù)據(jù)結(jié)構(gòu)或代碼塊初始化的錯誤。Timing/serialization Fault計時/串行錯誤：Fault that involves timing of shared and real-time resources.涉及共享資源或?qū)崟r資源計時的錯誤。Build/package/merge Fault構(gòu)建/打包/合并錯

19、誤：Fault that occurs because of problems in repositories, management changes, or version control.由于倉庫、管理變動或版本控制的問題等而出現(xiàn)的錯誤。Documentation Fault文檔錯誤： Fault that affects publications and maintenance notes.影響發(fā)布和維護(hù)注釋的錯誤。Algorithm Fault算法錯誤： Fault involving efficiency or correctness of algorithm or data str

20、ucture but not design.涉及算法或數(shù)據(jù)結(jié)構(gòu)的效率或正確性但與設(shè)計無關(guān)的錯誤。HP Fault Classification錯誤起源錯誤類型錯誤模式Faults for One HPs Division3218545191168.2 Testing Issues 測試的有關(guān)事項測試定義：測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；成功的測試是發(fā)現(xiàn)了迄今為止尚未發(fā)現(xiàn)的錯誤的測試 。測試的意義和幾點說明至今為止，測試仍然是軟件質(zhì)量保證的最重要手段。測試是證實軟件需求說明的功能是否實現(xiàn)，是否達(dá)到預(yù)期的指標(biāo)的最有效手段。軟件測

21、試耗時費力，追求用最小的測試代價獲得最大的測試效果。測試是為了發(fā)現(xiàn)錯誤，不是為了證明程序無錯誤。測試不能證明程序中沒有錯誤。測試的可信度（dependability)問題Testing Principles 測試指導(dǎo)原則所有的測試都應(yīng)追溯到用戶需求，從用戶角度看，最嚴(yán)重的錯誤是不能滿足用戶需求。制定測試計劃，并嚴(yán)格執(zhí)行，排除隨意性。測試計劃在需求分析階段就開始了，詳細(xì)的測試用例在設(shè)計階段確定。Pareto原則：所發(fā)現(xiàn)錯誤的80%很可能源于程序模塊的20%中。測試應(yīng)當(dāng)從“小規(guī)?！遍_始，逐步轉(zhuǎn)向“大規(guī)?！?。窮舉測試是不可能的（Exhaustive testing）。由獨立的第三方或?qū)ｉT的測試小組進(jìn)

22、行獨立測試。Testing Principles 測試指導(dǎo)原則測試用例由輸入數(shù)據(jù)和相應(yīng)的預(yù)期輸出組成。測試用例不僅選用合理的輸入數(shù)據(jù)，還要選擇不合理的。不僅檢查程序是否做了應(yīng)該做的事，還應(yīng)該檢查是否不應(yīng)該做的。長期保留測試用例，以便進(jìn)行回歸測試和維護(hù)。測試技術(shù)的分類靜態(tài)測試l辦公桌檢查 desk checkingl走查 walk-throughl代碼會審 code inspection動態(tài)測試l黑盒測試（closed box or black box）l白盒測試（open box、clear box or white box）l窮舉和選擇測試。靜態(tài)測試定義定義l人工方式進(jìn)行的代碼復(fù)審。人工方式

23、進(jìn)行的代碼復(fù)審。目的目的l檢查程序靜態(tài)結(jié)構(gòu)，找出編譯不能發(fā)現(xiàn)的錯誤和人的主觀認(rèn)識檢查程序靜態(tài)結(jié)構(gòu)，找出編譯不能發(fā)現(xiàn)的錯誤和人的主觀認(rèn)識上偏差。上偏差。范圍范圍l需求定義、設(shè)計文檔、源代碼（著重分析）需求定義、設(shè)計文檔、源代碼（著重分析）特點特點l研究表明，對于某些類型的錯誤，靜態(tài)測試更有效研究表明，對于某些類型的錯誤，靜態(tài)測試更有效 。l經(jīng)驗表明，組織良好的代碼復(fù)審可以發(fā)現(xiàn)程序中經(jīng)驗表明，組織良好的代碼復(fù)審可以發(fā)現(xiàn)程序中30%到到70%的的編碼和邏輯設(shè)計錯誤。編碼和邏輯設(shè)計錯誤。l不存在錯誤定位問題。不存在錯誤定位問題。動態(tài)測試定義l在設(shè)定的測試數(shù)據(jù)上執(zhí)行被測試程序的過程。目的l通過執(zhí)行程序代

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

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

26、測試用例發(fā)現(xiàn)最多的程序錯誤。Testing Issues 測試的有關(guān)事項Test organization 測試的組成Attitudes toward testing 測試態(tài)度Who performs the tests 由誰進(jìn)行測試Views of the test objects 對測試對象的看法Test organization 測試的組成Several Test Stages for large system 大型系統(tǒng)測試的幾個階段Module test, component test, unit test 模塊測試、組件測試、單元測試Integration test 集成測試Func

27、tion test 功能測試Performance test 性能測試Acceptance test 驗收測試Installation test 安裝測試Testing stepsUnittestIntegrationtestUnittestUnittestInstallationtestPerformancetestFunctiontestAcceptancetestDesignspecificationSystemfunctionalrequirementsOther software requirementCustomer requirement specificationUser en

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

29、o 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)是盡可能多地消除錯誤，無論這些錯誤出現(xiàn)在系統(tǒng)的何處，也無論是誰創(chuàng)造它們。當(dāng)發(fā)現(xiàn)一個錯誤或出現(xiàn)一次失效時，我們關(guān)注的是糾正錯誤，而不是譴責(zé)某個開發(fā)人員。Who performs the tests？由誰進(jìn)行測試？We often use an independent t

30、est 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.通常由一個獨立的測試小組來測試系統(tǒng)。用這種方式避免了個人對錯誤負(fù)有的責(zé)任和發(fā)現(xiàn)盡可能多錯誤的需要之間的沖突。Views of the test objects 對測試對象的看法As you test a component, group of component, subsystem, or

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

32、 代碼預(yù)排lCode Inspections 代碼審查 典型的審查準(zhǔn)備時間和會議時間典型的審查準(zhǔn)備時間和會議時間Table 8.2. Typical inspection preparation and meeting times.Development artifact開發(fā)工作開發(fā)工作Preparation time準(zhǔn)備時間準(zhǔn)備時間Meeting time會議時間會議時間Requirements document25 pages per hour12 pages per hourFunctional specification45 pages per hour15 pages per hou

33、rLogic 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)活動中找到的錯誤發(fā)現(xiàn)活動中找到的錯誤Table 8.3. Faults found during discovery activities.Discovery activity發(fā)現(xiàn)活動發(fā)現(xiàn)活動Faults found per thousand lines of co

34、de每千行代碼發(fā)現(xiàn)的錯誤每千行代碼發(fā)現(xiàn)的錯誤Requirements review2.5Design review5.0Code inspection10.0Integration test3.0Acceptance test2.0Proving code correct 證明代碼正確性Formal proof techniques 形式證明技術(shù)Symbolic execution 符號執(zhí)行Automated theorem-proving 自動定理證明Testing program components 測試程序組件Testing versus proving 測試與證明 A proof t

35、ells us how a program 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.一個證明告訴我們在設(shè)計和需求描述的假設(shè)環(huán)境下，程序?qū)⒃鯓舆\(yùn)行，測試提供了在實際的操作環(huán)境中程序怎樣運(yùn)行的有關(guān)消息。Choosing test cases 選擇測試實例 We begin by determini

36、ng our test objectives. 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 i

37、n order to choose our test cases.首先決定測試目標(biāo)。然后選擇測試實例、定義旨在滿足特定目標(biāo)的測試。有的目標(biāo)是證明所有的語句都正確執(zhí)行。有的目標(biāo)是證明代碼執(zhí)行的每個功能都是正確完成的。目標(biāo)決定了怎樣對輸入分類從而選擇測試實例。Test thoroughness 測試的徹底性To perform a test, we decide how to demonstrate in a convincing way that the test data exhibit all possible behaviors. 為了進(jìn)行一個測試，應(yīng)當(dāng)以一種有說服力的方式來證明該測試數(shù)據(jù)

38、展示了所有可能的行為。To test code thoroughly, we can choose test cases using at least one of several approaches based on the data manipulated by the code:為了徹底地測試代碼，根據(jù)代碼處理的數(shù)據(jù)，至少可以用下面幾種方法之一來選擇測試實例： Statement testing （語句測試） Branch testing （分支測試） Path testing （路徑測試） Definition-use path testing （定義使用測試） All-uses t

39、esting （所有使用的路徑測試） All-predicate-uses/some-computational-uses testing （所有判定使用/某些計算使用的測試） All-computational-uses/some-predicate-uses testing （所有計算使用/某些判定使用的測試）Statement testing（語句測試）：every statement in the component is executed at least once in some test. 組件中的每個語句在某些測試中至少執(zhí)行一次。Branch testing（分支測試）：for

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

41、試）：every path from every definition of every every path from every definition of every variable to every use of that definition is variable to every use of that definition is exercised in some test.exercised in some test. 從每個變量的定義到該定義的使用的每一條路徑，從每個變量的定義到該定義的使用的每一條路徑，都在某些測試中執(zhí)行。都在某些測試中執(zhí)行。All-uses testi

42、ngAll-uses testing（所有使用的路徑測試）（所有使用的路徑測試）: : the test set includes at least one path from the test set includes at least one path from every definition to every use that can be every definition to every use that can be reached by that definition.reached by that definition. 測試集至少包含這樣一條路徑，它從每一個定義測試集至少包

43、含這樣一條路徑，它從每一個定義到該定義能到達(dá)的所有使用。到該定義能到達(dá)的所有使用。All-predicate-uses/some-computational-uses testing（所有判定使用/某些計算使用的測試）：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 descripti

44、on, then include computational uses so that every definitions is covered. 對每個變量和該變量的定義，測試至少包含了這樣的一條路徑，它從該定義到每個判斷的使用；如果有定義沒有被這個描述覆蓋，那么加入計算的使用以便覆蓋每個定義。All-computational-uses/some-predicate-uses All-computational-uses/some-predicate-uses testingtesting（所有計算使用（所有計算使用/ /某些判定使用的測試）：某些判定使用的測試）： for every v

45、ariable and every definition of for every variable and every definition of that variable, a test includes at least one that variable, a test includes at least one path from the definition to every path from the definition to every computational use; if there are definitions computational use; if the

46、re are definitions not covered by that description, then include not covered by that description, then include predicate uses so that every definitions is predicate uses so that every definitions is covered.covered. 對每個變量和該變量的定義，測試至少包含了這對每個變量和該變量的定義，測試至少包含了這樣的一條路徑，它從該定義到每個計算的使用；如果樣的一條路徑，它從該定義到每個計算的使

47、用；如果有定義沒有被這個描述覆蓋，那么加入判定的使用以有定義沒有被這個描述覆蓋，那么加入判定的使用以便覆蓋每個定義。便覆蓋每個定義。 所有路徑 所有定義 使用路徑 所有使用 所有計算/ 某些判定使用 所有判定/ 某些計算使用 所有計算使用 所有定義 所有判定使用 分支 語句 Relative strengths of test strategies 測試策略的相對強(qiáng)度Ntafos shows lrandom testing (not test strategies) found 79.5% faultslbranch testing found 85.5%, andlall-uses test

48、ing found 90%Stronger strategy means more test cases策略越強(qiáng)、涉及的測試實例越多。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,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 由錯誤起源發(fā)現(xiàn)錯誤的百分比發(fā)現(xiàn)技術(shù)起源需求設(shè)

49、計編碼文檔原型化40353515需求評審401505設(shè)計評審1555015代碼審查20406525單元測試15200Effectiveness of fault-discovery techniques錯誤發(fā)現(xiàn)技術(shù)的效果需 求錯 誤設(shè) 計錯 誤編 碼錯 誤文 檔錯 誤評審一般極好極好好原型化好一般一般不適用測試壞壞好一般正確性證明壞壞一般一般8.4 Integration testing 集成測試When we are satisfied that individual components are working correctly and meet our objectives, we c

50、ombine 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.集成測試也稱為組裝測試。當(dāng)對單個組件的正確運(yùn)行情況滿意、認(rèn)為它們達(dá)到了目標(biāo)之后，將它們組合成一個工作系統(tǒng)。通過策劃和調(diào)整這種集成方式，當(dāng)出現(xiàn)錯誤后能大致了解是什么導(dǎo)致了這個錯誤。集成測試的方法Bottom-up 自底向上Top-down 自頂向下Big-bang 一次性Sandwich testing 三明

51、治測試Modified top-down 改進(jìn)自頂向下Modified sandwich 改進(jìn)三明治 Bottom-up測試步驟自底向上由一個葉模塊開始，自底向上逐步添加新模塊，組成程序的一個子系統(tǒng)或具有某一功能的模塊族（群Cluster)設(shè)計驅(qū)動程序，協(xié)調(diào)測試數(shù)據(jù)的輸入和輸出測試去掉驅(qū)動模塊，沿軟件結(jié)構(gòu)自下而上移動，把有關(guān)的子系統(tǒng)結(jié)合，形成更大的子系統(tǒng)。 Bottom-up測試示例ABDCEFGTestETestFTestGTestD,GTestCTestB,E,FTestA,B,C,D,E,F,GTop-down 測試步驟測試主控模塊，由樁模塊代替所有直屬模塊根據(jù)所確定的組合策略增加一個模

52、塊，設(shè)計新的樁模塊。測試，如果在新的條件下發(fā)現(xiàn)新的錯誤，執(zhí)行下一步；否則執(zhí)行上一步?；貧w測試（全部或部分地重復(fù)已做過的測試并返回）Top-down測試示例ABDCEFGTestATestA,B,C,DTestA,B,C,D,E,F,G Big-bang 測試示例ABDCEFGTest ETest FTest GTest DTest CTest ATestA,B,C,D,E,F,GTest BSandwich testing 測試步驟 對上層模塊采用自頂向下，較早顯示程序的總體輪廓。目標(biāo)層（中間層）的選擇問題對某些關(guān)鍵模塊（如具有I/O功能的模塊、功能重要或含有特殊算法的模塊）或子系統(tǒng)采用自底向

53、上組裝和測試，以便容易地產(chǎn)生測試用例或減少重復(fù)測試次數(shù)。 Sandwich 集成策略示例ABDCEFGTestETestFTestGTestATestD,GTestB,E,FTestA,B,C,D,E,F,G Modified Top-down測試示例TestBTestCTestDTestGTestFTestETestA,B,C,D,E,F,GTestA,B,C,DTestAModified top-down測試兩種結(jié)合策略l深度優(yōu)先 先組裝在軟件結(jié)構(gòu)的一條主控通路上的所有模塊。l寬度優(yōu)先 沿軟件結(jié)構(gòu)水平地移動，把處于同一個控制層次上的所有模塊組裝起來。 Modified Sandwich集成

54、策略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)作程序的時間晚早早晚早早需要組件驅(qū)動程序是否是是是是需要存根程序否是是是是是開始工作的并行性中等低中等高中等高測試特殊路徑的能力容易難容易容易中等容易計劃和控制順序的能力容易難難容易難難Builds At Microsoft 微軟的集

55、成方法Market-driven integration strategyMarket-driven integration strategy市場驅(qū)動集成策略市場驅(qū)動集成策略The process iterates among designing, building, The process iterates among designing, building, testing components while involving customers in testing components while involving customers in the testing process t

56、he testing process 該過程在測試過程中包含顧客該過程在測試過程中包含顧客的同時，在設(shè)計、構(gòu)建、測試組件之間迭代。的同時，在設(shè)計、構(gòu)建、測試組件之間迭代。Work in teamsWork in teamslTeam size 3 to 8 developers 3Team size 3 to 8 developers 3到到8 8人一組人一組lDifferent teams are responsible for different Different teams are responsible for different features features 不同的小組負(fù)責(zé)不

57、同的特征不同的小組負(fù)責(zé)不同的特征lEach team is allowed to change the Each team is allowed to change the specification of features specification of features 每個小組都可以改每個小組都可以改動說明的特征動說明的特征Microsoft Synch-and-stabilize approach 微軟同步且穩(wěn)定的測試方法里程碑1：最重要的特征和共享的組件 設(shè)計、代碼、原型、可用性測試 日常構(gòu)造 特征集成、消除嚴(yán)重錯誤里程碑2：想要的特征 設(shè)計、代碼、原型、可用性測試 日常構(gòu)造 特征

58、集成里程碑3：最不重要的特征 設(shè)計、代碼、原型、可用性測試 日常構(gòu)造 特征集成和完成 發(fā)布、進(jìn)行批量制造8.5 testing object-oriented system 測試面向?qū)ο笙到y(tǒng)Testing the code 代碼測試Begin testing object-oriented system by asking several questions(通過提出幾個問題開始測試面向?qū)ο笙到y(tǒng))：When your code expects a unique value, is there a path that generates a unique result?期望代碼什么時候有一個唯一

59、值，有一條路徑產(chǎn)生一個唯一的結(jié)果嗎？When there are many possible values, is there a way to select a unique result? 什么時候有許多可能值，有一種方法選擇一個唯一的結(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, unne

60、cessary classes, missing or unnecessary associations, or incorrect placement of associations or attributes.接著，確信檢查了對象和類本身的過度和不足：遺漏的類、遺漏或不必要的關(guān)系、不正確的關(guān)系或?qū)傩园才?。Objects might be missing 對象可能會遺漏lYou find asymmetric associations or generalization 發(fā)現(xiàn)有不對稱的關(guān)系或類lYou find disparate attributes and operations on a