1、Testing the Programs 程序的測試,SOFTWARE ENGINEERING,8.1 Software fault and failures 軟件故障和失效,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 prescribe

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

3、am code may be wrong. It may implement the algorithm improperly or incompletely. 程序代碼有錯誤。代碼對算法的實現(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. 我們的目標是發(fā)現(xiàn)錯誤。因為只有發(fā)現(xiàn)了錯誤、或者由于測試過程而使程序發(fā)生失效，測

4、試才稱得上成功。 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)以去除錯誤的過程。,Types of faults 錯誤類型,Algorithmic fault 算法錯誤 Synt

5、ax fault 語法錯誤 Computation and precision fault 計算和精度錯誤 Documentation fault 文檔錯誤 Stress or overload fault 強度或過載錯誤 Capacity or boundary fault 能力或邊界錯誤 Timing or coordination fault 計時或協(xié)調(diào)錯誤 Throughput or performance fault 吞吐量或性能錯誤 Recovery fault 恢復錯誤 Hardware and system software fault 硬件和系統(tǒng)軟件錯誤 Standards

6、and procedures fault 標準和規(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.當由于處理步驟中的某些錯誤，使得一個組件的算法或邏輯對一個給定的輸入不能產(chǎn)生正確的輸出時，出現(xiàn)的是算法錯誤。 Compile

7、rs 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 當一個公式的實現(xiàn)是錯誤的，或者計算結果沒有達到要求的精度時出現(xiàn)計算錯誤和精度錯誤。,Explanation of types of faults 錯誤類型說明,When the documentati

8、on does not match hat the program actually does, we say that the program has documentation faults.當文檔與程序實際做的事情不相符時，我們稱該程序有文檔錯誤。 Stress or overload faults occur when these data structures are filled past their specified capacity.當數(shù)據(jù)結構被填充得超過了它們規(guī)定的能力時，發(fā)生的是強度錯誤或過載錯誤。 Capacity or boundary faults occur wh

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

10、rformance faults occur when the system does not perform at the speed prescribed by the requirement.當系統(tǒng)不能以需求規(guī)定的速度執(zhí)行任務時出現(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.當遇到一次失效，而系統(tǒng)不能像設計時希望的或顧客要求的那樣運轉

11、時，出現(xiàn)的是恢復錯誤。,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.當提供的硬件和系統(tǒng)軟件實際上并沒有按照文檔記錄的操作條件和步驟運行時，發(fā)生的是硬件和系統(tǒng)軟件錯誤。 Standards and procedur

12、e 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.標準和規(guī)程錯誤并不總影響程序的運行，但他們可能會產(chǎn)生系統(tǒng)測試和改動時產(chǎn)生錯誤的環(huán)境。,orthogonal defect classification 正交故障分類,It is useful to categorize track the types of faults. Many or

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

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

15、al data structure.影響能力、最終用戶接口 、與硬件體系結構的接口或全局數(shù)據(jù)結構的錯誤。 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 values properly

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

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

18、not design.涉及算法或數(shù)據(jù)結構的效率或正確性但與設計無關的錯誤。,HP Fault Classification,Faults for One HPs Division,32,18,5,4,5,19,11,6,8.2 Testing Issues 測試的有關事項,測試定義：測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程； 好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案； 成功的測試是發(fā)現(xiàn)了迄今為止尚未發(fā)現(xiàn)的錯誤的測試 。,測試的意義和幾點說明,至今為止，測試仍然是軟件質量保證的最重要手段。 測試是證實軟件需求說明的功能是否實現(xiàn)，是否達到預期的指標的最有效手段。 軟件測試耗時費力

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

20、測試小組進行獨立測試。,Testing Principles 測試指導原則,測試用例由輸入數(shù)據(jù)和相應的預期輸出組成。 測試用例不僅選用合理的輸入數(shù)據(jù)，還要選擇不合理的。 不僅檢查程序是否做了應該做的事，還應該檢查是否不應該做的。 長期保留測試用例，以便進行回歸測試和維護。,測試技術的分類,靜態(tài)測試 辦公桌檢查 desk checking 走查 walk-through 代碼會審 code inspection 動態(tài)測試 黑盒測試 白盒測試 窮舉和選擇測試。,靜態(tài)測試,定義 人工方式進行的代碼復審。 目的 檢查程序靜態(tài)結構，找出編譯不能發(fā)現(xiàn)的錯誤和人的主觀認識上偏差。 范圍 需求定義、設計文檔、

21、源代碼（著重分析） 特點 研究表明，對于某些類型的錯誤，靜態(tài)測試更有效 。 經(jīng)驗表明，組織良好的代碼復審可以發(fā)現(xiàn)程序中30%到70%的編碼和邏輯設計錯誤。 不存在錯誤定位問題。,動態(tài)測試,定義 在設定的測試數(shù)據(jù)上執(zhí)行被測試程序的過程。 目的 通過執(zhí)行程序代碼動態(tài)地驗證結果的正確性。 三個過程： 設計測試用例（test case) 執(zhí)行被測試程序 分析執(zhí)行結果并發(fā)現(xiàn)錯誤 三個要素：程序、測試數(shù)據(jù)、需求定義 兩個方面： 在測試數(shù)據(jù)上程序是對的 測試數(shù)據(jù)是正確的,黑盒測試（功能測試）,定義：已知產(chǎn)品應該具有的功能，通過測試檢驗其每個功能是否都能夠正常使用。又稱功能測試。 用途：把程序看成一個黑盒子，

22、僅僅考慮輸入和輸出的對應關系和程序接口，完全不考慮它的內(nèi)部結構和處理過程。一般用于綜合測試、系統(tǒng)測試等。,白盒測試（結構測試 ）,定義 已知產(chǎn)品內(nèi)部的工作過程，通過測試檢驗產(chǎn)品內(nèi)部動作是否都能按照需求定義的規(guī)定正常使用。 用途 必須完全了解程序的內(nèi)部結構和處理過程，才能按照程序內(nèi)部的邏輯測試，以檢驗程序中每條路徑是否正確，因此 一般用于規(guī)模較小的程序和單元測試。,窮舉測試 (Exhaustive testing),定義 包含所有可能情況的測試。 對于黑盒測試，必須對所有輸入數(shù)據(jù)的各種可能值的排列組合都進行測試； 對于白盒測試，程序中每條可能的路徑在每種可能的輸入數(shù)據(jù)下至少執(zhí)行一次。 窮舉測試是

23、不可能的。 例一：要對C編譯系統(tǒng)進行黑盒窮舉測試，一方面要編出所有能夠想象出來的合法程序讓它編譯；另一方面又要編出一切不合法的程序，考察它能否指出程序的非法性質。顯然，這兩類（合法和不合法）程序的數(shù)量是無限的。,選擇測試,僅選擇一些具有代表的、典型的測試用例，進行有限的測試。 以最少的測試用例發(fā)現(xiàn)最多的程序錯誤。,Testing Issues 測試的有關事項,Test organization Attitudes toward testing Who performs the tests Views of the test objects,Test organization 測試的組成,Sev

24、eral Test Stages for large system 大型系統(tǒng)測試的幾個階段 Module test, component test, unit test 模塊測試、組件測試、單元測試 Integration test 集成測試 Function test 功能測試 Performance test 性能測試 Acceptance test 驗收測試 Installation test 安裝測試,Testing steps,Attitudes toward testing 測試態(tài)度,The goal as a developer should be to eliminate as

25、 many faults as possible, no matter where in the system they occur 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ā)人員的目標是盡可能多地消除錯誤，無論這些錯誤出現(xiàn)在系統(tǒng)的何處，也無論是誰創(chuàng)造它們。當發(fā)現(xiàn)一個錯誤或出現(xiàn)一次失效

26、時，我們關注的是糾正錯誤，而不是譴責某個開發(fā)人員。,Who performs the tests？由誰進行測試？,We often use 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. 通常由一個獨立的測試小組來測試系統(tǒng)。用這種方式避免了個人對錯誤負有的責任和發(fā)現(xiàn)盡可能多錯誤的需要之間的沖突。,Views

27、 of the test objects 對測試對象的看法,As you test a component, group of component, subsystem, or system, your view of the test object can affect the way in which testing proceeds. 當測試一個組件、組件群、子系統(tǒng)、或系統(tǒng)時，你對測試對象的看法可能影響測試進行的方式。,8.3 Unit Testing 單元測試,單元測試主要評價模塊的五個特性 模塊接口 局部數(shù)據(jù)類型 重要的執(zhí)行通路 出錯處理通路 影響以上特性的邊界條件 單元測試過程 檢

28、查代碼 證明代碼正確性 測試程序組件,Examining the Code 檢查代碼,Two types of code review Code Walkthroughs Code Inspections Success of Code Reviews,Proving code correct 證明代碼正確性,Formal proof techniques Symbolic execution Automated theorem-proving,Testing program components 測試程序組件,Testing versus proving 測試與證明 A proof tell

29、s 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.一個證明告訴我們在 設計和需求描述的假設環(huán)境下，程序將怎樣運行， 測試提供了在實際的操作環(huán)境中程序怎樣運行的有 關消息。,Choosing test cases 選擇測試實例 We begin by determin

30、ing 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

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

32、y, we can choose test cases using at least one of several approaches based on the data manipulated by the code: 為了進行一個測試，應當以一種有說服力的方式來證明該測試數(shù)據(jù)展示了所有可能的行為。為了徹底地測試代碼，根據(jù)代碼處理的數(shù)據(jù)，至少可以用下面幾種方法之一來選擇測試實例：,Statement testing（語句測試）：every statement in the component is executed at least once in some test.組件中的每個語句在某

33、些測試中至少執(zhí)行一次。 Branch testing（分支測試）：for 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 testing（定義使用測

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

35、，它從每一個定義到該定義能到達的所有使用。,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 description, then include co

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

37、 definition to every computational use; if there are definitions not covered by that description, then include predicate uses so that every definitions is covered.對每個變量和該變量的定義，測試至少包含了這樣的一條路徑，它從該定義到每個計算的使用；如果有定義沒有被這個描述覆蓋，那么加入判定的使用以便覆蓋每個定義。,Relative strengths of test strategies 測試策略的相對強度,Ntafos shows

38、random testing (not test strategies) found 79.5% faults branch testing found 85.5%, and all-uses testing found 90% Stronger strategy means more test cases策略越強、涉及的測試實例越多。,Logic Flow 邏輯流,Statement testing 1,2,3,4,5,6,7 branch testing 1,2,3,4,5,6,7 1,2,4,5,6,1 path testing 1,2,3,4,5,6,7 1,2,3,4,5,6,1 1

39、,2,4,5,6,7 1,2,4,5,6,1,Comparing techniques 技術比較,Fault discovery percentages by fault origin 由錯誤起源發(fā)現(xiàn)錯誤的百分比,Effectiveness of fault-discovery techniques錯誤發(fā)現(xiàn)技術的效果,8.4 Integration testing 集成測試,When we are satisfied that individual components are working correctly and meet our objectives, we combine them

40、 into a working system. This integration is planned and coordinated so that when a failure occurs, we have some idea of what caused it. 集成測試也稱為組裝測試。當對單個組件的正確運行情況滿意、認為它們達到了目標之后，將它們組合成一個工作系統(tǒng)。通過策劃和調(diào)整這種集成方式，當出現(xiàn)錯誤后能大致了解是什么導致了這個錯誤。,集成測試的方法,Bottom-up Top-down Big-bang Sandwich testing Modified top-down Mod

41、ified sandwich,Bottom-up測試步驟,自底向上由一個葉模塊開始，自底向上逐步添加新模塊，組成程序的一個子系統(tǒng)或具有某一功能的模塊族（群Cluster) 設計驅動程序，協(xié)調(diào)測試數(shù)據(jù)的輸入和輸出 測試 去掉驅動模塊，沿軟件結構自下而上移動，把有關的子系統(tǒng)結合，形成更大的子系統(tǒng)。,Bottom-up測試示例,A,B,D,C,E,F,G,Test E,Test F,Test G,Test D,G,Test C,Test B,E,F,Test A,B,C,D,E,F,G,Top-down 測試步驟,測試主控模塊，由樁模塊代替所有直屬模塊 根據(jù)所確定的組合策略增加一個模塊，設計新的樁模

42、塊。 測試，如果在新的條件下發(fā)現(xiàn)新的錯誤，執(zhí)行下一步；否則執(zhí)行上一步。 回歸測試（全部或部分地重復已做過的測試并返回）,Top-down測試示例,A,B,D,C,E,F,G,Test A,Test A,B,C,D,Test A,B,C,D,E,F,G,Big-bang 測試示例,A,B,D,C,E,F,G,Test E,Test F,Test G,Test D,Test C,Test A,Test A,B,C,D,E,F,G,Test B,Sandwich testing 測試步驟,對上層模塊采用自頂向下，較早顯示程序的總體輪廓。 目標層（中間層）的選擇問題 對某些關鍵模塊（如具有I/O功能的

43、模塊、功能重要或含有特殊算法的模塊）或子系統(tǒng)采用自底向上組裝和測試，以便容易地產(chǎn)生測試用例或減少重復測試次數(shù)。,Sandwich 集成策略示例,A,B,D,C,E,F,G,Test E,Test F,Test G,Test A,Test D,G,Test B,E,F,Test A,B,C,D,E,F,G,Modified Top-down測試示例,Test B,Test C,Test D,Test G,Test F,Test E,Test A,B,C,D,E,F,G,Test A,B,C,D,Test A,Modified top-down測試,兩種結合策略 深度優(yōu)先 先組裝在軟件結構的一條主

44、控通路上的所有模塊。 寬度優(yōu)先 沿軟件結構水平地移動，把處于同一個控制層次上的所有模塊組裝起來。,Modified Sandwich集成策略,Test E,Test F,Test G,Test A,Test D,G,Test B,E,F,Test A,B,C,D,E,F,G,Test C,Test B,Test D,Table 8.7. Comparison of integration strategies集成策略的比較,Builds At Microsoft 微軟的集成方法,Market-driven integration strategy Work in teams Team size

45、 3 to 8 developers Different teams are responsible for different features Each team is allowed to change the specification of features The process iterates among designing, building, testing components while involving customers in the testing process,Microsoft Synch-and-stabilize approach 微軟同步且穩(wěn)定的測試

46、方法,8.5 testing object-oriented system 測試面向對象系統(tǒng),Testing the code 代碼測試 Begin testing object-oriented system by asking several questions(通過提出幾個問題開始測試面向對象系統(tǒng))： When your code expects a unique value, is there a path that generates a unique result?期望代碼什么時候有一個唯一值，有一條路徑產(chǎn)生一個唯一的結果嗎？ When there are many possibl

47、e values, is there a way to select a unique result? 什么時候有許多可能值，有一種方法選擇一個唯一的結果嗎？ 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 ass

48、ociations, or incorrect placement of associations or attributes. 接著，確信檢查了對象和類本身的過度和不足：遺漏的類、遺漏或不必要的關系、不正確的關系或屬性安排。,Objects might be missing if You find asymmetric associations or generalization You find disparate attributes and operations on a class One class is playing two or more roles An operation has no good target class You find two associations with the same name and purpose,Differences between object-oriented and traditional testing面向對象測試和傳統(tǒng)測試之間的差別,OO測試中更容