《软件工程概论：第八章 程序的测试》由会员分享，可在线阅读，更多相关《软件工程概论：第八章 程序的测试（89页珍藏版）》请在金锄头文库上搜索。
1、Testing the Programs 程序的测试程序的测试SOFTWARE ENGINEERING 8.1 Software fault and failures 软件故障和失效软件失效机理通常将软件失效机理描述为软件错误、软件缺陷、软件故障和软件失效。4个概念软件错误：是指在软件生命周期内不希望出现和不可接受的人为错误，其结果导致软件缺陷的产生。软件错误的产生是一种人为过程，相对软件本身，它是一种外部行为。 错误在整个软件开发周期中很可能被扩展，在需求阶段发生的错误，在设计期间有可能被放大，在编写代码时还会进一步扩大。软件缺陷：是存在于软件（文档、数据、程序）之中的那些不希望出现或不可接
2、受的偏差，例如多一条语句等。缺陷导致的结果是软件运行某一特定条件时出现软件故障，称软件缺陷被激活。软件故障：是软件运行过程中出现的一种不可接受或不希望出现的内部状态。例如，程序出现死循环，就是出现了软件故障，如果无有效措施及时处理，则产生软件失效。软件故障是一种动态行为。软件失效：是指软件运行时产生的一种不希望出现和不可接受的外部行为结果。四个概念之间的关系：软件错误是一种人为的失误。一个软件错误必定产生一个或多个软件缺陷。当一个软件缺陷被激活时，便产生了软件故障。同一个软件缺陷在不同的条件下被激活，可能产生不同的软件故障。对于软件故障，如果没有容错措施或及时处理，便不可避免地导致软件失效。同
3、一软件故障在不同条件下可能产生不同的软件失效。How does software fail 哪些因素使得系统失效?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. 由于规定的硬件和软件的原因，说明中包含不可能
4、实现的需求由于规定的硬件和软件的原因，说明中包含不可能实现的需求 。The system design may contain a fault. 系统设计中包含错误。系统设计中包含错误。The program design may contain a fault. The component descriptions may contain an access control algorithm that does not handle this case correctly. 程序设计中包含错误。组件描述可能包含不能正确处理这种情况的访问控程序设计中包含错误。组件描述可能包含不能正确处理这种
5、情况的访问控制算法。制算法。The program code may be wrong. It may implement the algorithm improperly or incompletely. 程序代码有错误。代码对算法的实现可能不正确或不完整。程序代码有错误。代码对算法的实现可能不正确或不完整。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.我们的目标是发现错误。因为只有发现了错误、或者由于测试过程而使程序发生失效，测试才称得上成功。Fault identification is the process of determining what fault or faults caused the failure. 错误确定是判定什么错误引发了失效的过程。Fault correction or fault removal is the process of making changes to the system so the faults are removed. 错误纠正或去除是改动系统以去除错误的过程。Type
7、s of faults 错误类型Algorithmic fault 算法错误Syntax fault 语法错误Computation and precision fault 计算和精度错误Documentation fault 文档错误Stress or overload fault 强度或过载错误Capacity or boundary fault 能力或边界错误Timing or coordination fault 计时或协调错误Throughput or performance fault 吞吐量或性能错误Recovery fault 恢复错误Hardware and system s
8、oftware fault 硬件和系统软件错误Standards and procedures fault 标准和规程错误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.当由于处理步骤中的某些错误，使得一个组件的算法或逻辑对一个给定
9、的输入不能产生正确的输出时，出现的是算法错误。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 当一个公式的实现是错误的，或者计算结果没有达到要求的精度时出现计算错误和精度错误。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.当文档与程序实际做的事情不相符时，我们称该程序有文档错误。Stress or overload faults occur when these data structures are filled past their specified capacity.当数据结构被填充得超过了它们规定的能力时，发生的是强度错误或过载错误。Capacity or
11、 boundary faults occur when the systems performance becomes unacceptable as system activity reaches its specified limit.当系统活动达到规定的极限时系统性能变得不可接受，称为能力错误或边界错误。Explanation of types of faults 错误类型说明Timing or coordination faults occur when the code coordinating events is inadequate.当系统不能按需求满足顺序的协调性时出现计时错误
12、或协调错误。Throughput or performance faults occur when the system does not perform at the speed prescribed by the requirement.当系统不能以需求规定的速度执行任务时出现吞吐量错误或性能错误。Recovery faults can occur when a failure is encountered and the system does not behave as the designers desire or as the customer requires.当遇到一次失效，而
13、系统不能像设计时希望的或顾客要求的那样运转时，出现的是恢复错误。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.当提供的硬件和系统软件实际上并没有按照文档记录的操作条件和步骤运行时，发生的是硬件和系统软件错误。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.标准和规程错误并不总影响程序的运行，但他们可能会产生系统测试和改动时产生错误的环境。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.对错误类型进行分类和跟踪是很有用的。许多机构进行统计错误建模和原因分析都依赖于对错误的数目和类型分布的理解。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开发了一种进行错误跟踪的方法，称为正交故障分类。正交故障分类的一个关键特征是它的正交性。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.影响能力、最终用户接口、与硬件体系结构的接口或全局数据结构的错误。 Interface Fault 接口错误：Fault in interacting with other components or drivers via calls, macros, control blocks or parameter lists.通过调用、宏、控制块或参数表与其他组件交互时出现的错误。 Checking Fault检查错误：Fault in program logic that fails to validate data and
18、 values properly before they are used.在数据和值使用之前不能正确地对其确认的程序逻辑错误。 Assignment Fault赋值错误：Fault in data structure or code block initialization.数据结构或代码块初始化的错误。Timing/serialization Fault计时/串行错误：Fault that involves timing of shared and real-time resources.涉及共享资源或实时资源计时的错误。Build/package/merge Fault构建/打包/合并错
19、误：Fault that occurs because of problems in repositories, management changes, or version control.由于仓库、管理变动或版本控制的问题等而出现的错误。Documentation Fault文档错误： Fault that affects publications and maintenance notes.影响发布和维护注释的错误。Algorithm Fault算法错误： Fault involving efficiency or correctness of algorithm or data str
20、ucture but not design.涉及算法或数据结构的效率或正确性但与设计无关的错误。HP Fault Classification错误起源错误类型错误模式Faults for One HPs Division3218545191168.2 Testing Issues 测试的有关事项测试定义：测试是为了发现程序中的错误而执行程序的过程；好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；成功的测试是发现了迄今为止尚未发现的错误的测试 。测试的意义和几点说明至今为止，测试仍然是软件质量保证的最重要手段。测试是证实软件需求说明的功能是否实现，是否达到预期的指标的最有效手段。软件测
21、试耗时费力，追求用最小的测试代价获得最大的测试效果。测试是为了发现错误，不是为了证明程序无错误。测试不能证明程序中没有错误。测试的可信度（dependability)问题Testing Principles 测试指导原则所有的测试都应追溯到用户需求，从用户角度看，最严重的错误是不能满足用户需求。制定测试计划，并严格执行，排除随意性。测试计划在需求分析阶段就开始了，详细的测试用例在设计阶段确定。Pareto原则：所发现错误的80%很可能源于程序模块的20%中。测试应当从“小规模”开始，逐步转向“大规模”。穷举测试是不可能的（Exhaustive testing）。由独立的第三方或专门的测试小组进
22、行独立测试。Testing Principles 测试指导原则测试用例由输入数据和相应的预期输出组成。测试用例不仅选用合理的输入数据，还要选择不合理的。不仅检查程序是否做了应该做的事，还应该检查是否不应该做的。长期保留测试用例，以便进行回归测试和维护。测试技术的分类静态测试l办公桌检查 desk checkingl走查 walk-throughl代码会审 code inspection动态测试l黑盒测试（closed box or black box）l白盒测试（open box、clear box or white box）l穷举和选择测试。静态测试定义定义l人工方式进行的代码复审。人工方式
23、进行的代码复审。目的目的l检查程序静态结构，找出编译不能发现的错误和人的主观认识上检查程序静态结构，找出编译不能发现的错误和人的主观认识上偏差。偏差。范围范围l需求定义、设计文档、源代码（着重分析）需求定义、设计文档、源代码（着重分析）特点特点l研究表明，对于某些类型的错误，静态测试更有效研究表明，对于某些类型的错误，静态测试更有效 。l经验表明，组织良好的代码复审可以发现程序中经验表明，组织良好的代码复审可以发现程序中30%到到70%的编的编码和逻辑设计错误。码和逻辑设计错误。l不存在错误定位问题。不存在错误定位问题。动态测试定义l在设定的测试数据上执行被测试程序的过程。目的l通过执行程序代
24、码动态地验证结果的正确性。三个过程：l设计测试用例（test case)l执行被测试程序l分析执行结果并发现错误三个要素：程序、测试数据、需求定义两个方面：l在测试数据上程序是对的l测试数据是正确的黑盒测试（功能测试）定义：已知产品应该具有的功能，通过测试检验其每个功能是否都能够正常使用。又称功能测试。用途：把程序看成一个黑盒子，仅仅考虑输入和输出的对应关系和程序接口，完全不考虑它的内部结构和处理过程。一般用于综合测试、系统测试等。白盒测试（结构测试 ）定义l已知产品内部的工作过程，通过测试检验产品内部动作是否都能按照需求定义的规定正常使用。用途l必须完全了解程序的内部结构和处理过程，才能按照
25、程序内部的逻辑测试，以检验程序中每条路径是否正确，因此 一般用于规模较小的程序和单元测试。穷举测试 (Exhaustive testing)定义l包含所有可能情况的测试。l对于黑盒测试，必须对所有输入数据的各种可能值的排列组合都进行测试；l对于白盒测试，程序中每条可能的路径在每种可能的输入数据下至少执行一次。穷举测试是不可能的。l例一：要对C编译系统进行黑盒穷举测试，一方面要编出所有能够想象出来的合法程序让它编译；另一方面又要编出一切不合法的程序，考察它能否指出程序的非法性质。显然，这两类（合法和不合法）程序的数量是无限的。选择测试仅选择一些具有代表的、典型的测试用例，进行有限的测试。以最少的
26、测试用例发现最多的程序错误。Testing Issues 测试的有关事项Test organization 测试的组成Attitudes toward testing 测试态度Who performs the tests 由谁进行测试Views of the test objects 对测试对象的看法Test organization 测试的组成Several Test Stages for large system 大型系统测试的几个阶段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.系统测试Attitudes toward testing 测试态度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.作为开发人员的目标是尽可能多地消除错误，无论这些错误出现在系统的何处，也无论是谁创造它们。当发现一个错误或出现一次失效时，我们关注的是纠正错误，而不是谴责某个开发人员。Who performs the tests？由谁进行测试？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.通常由一个独立的测试小组来测试系统。用这种方式避免了个人对错误负有的责任和发现尽可能多错误的需要之间的冲突。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. 当测试一个组件、组件群、子系统、或系统时，你对测试对象的看法可能影响测试进行的方式。8.3 Unit Testing 单元测试单元测试主要评价模块的五个特性l模块接口l局部数据类型l重要的执行通路l出错处理通路l影响以上特性的边界条件单元测试过程l检查代码l证明代码正确性l测试程序组件Examining the Code 检查代码Two types of code review 两种代码评审方法lCode Walkthroughs
32、 代码预排lCode Inspections 代码审查 典型的审查准备时间和会议时间典型的审查准备时间和会议时间Table 8.2. Typical inspection preparation and meeting times.Development artifact开发工作开发工作Preparation time准备时间准备时间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 发现活动中找到的错误发现活动中找到的错误Table 8.3. Faults found during discovery activities.Discovery activity发现活动发现活动Faults found per thousand lines of co
34、de每千行代码发现的错误每千行代码发现的错误Requirements review2.5Design review5.0Code inspection10.0Integration test3.0Acceptance test2.0Proving code correct 证明代码正确性Formal proof techniques 形式证明技术Symbolic execution 符号执行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.一个证明告诉我们在设计和需求描述的假设环境下，程序将怎样运行，测试提供了在实际的操作环境中程序怎样运行的有关消息。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.首先决定测试目标。然后选择测试实例、定义旨在满足特定目标的测试。有的目标是证明所有的语句都正确执行。有的目标是证明代码执行的每个功能都是正确完成的。目标决定了怎样对输入分类从而选择测试实例。Test thoroughness 测试的彻底性To perform a test, we decide how to demonstrate in a convincing way that the test data exhibit all possible behaviors. 为了进行一个测试，应当以一种有说服力的方式来证明该测试数据
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:为了彻底地测试代码，根据代码处理的数据，至少可以用下面几种方法之一来选择测试实例： 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. 组件中的每个语句在某些测试中至少执行一次。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. 贯穿代码的每条路径在某次测试中至少执行一次。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. 从每个变量的定义到该定义的使用的每一条路径，从每个变量的定义到该定义的使用的每一条路径，都在某些测试中执行。都在某些测试中执行。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、含这样一条路径，它从每一个定义到该定义能到达的所有使用。到该定义能到达的所有使用。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 that for every variable and every definition of that variable, a test includes at least one path variable, a test includes at least one path from the definition to every computational use; from the definition to every computational use; if there are definitions not co
46、vered by that if there are definitions not covered by that description, then include predicate uses so description, then include predicate uses so that every definitions is covered.that every definitions is covered. 对每个变量和该变量的定义，测试至少包含了这对每个变量和该变量的定义，测试至少包含了这样的一条路径，它从该定义到每个计算的使用；如果样的一条路径，它从该定义到每个计算的使
47、用；如果有定义没有被这个描述覆盖，那么加入判定的使用以有定义没有被这个描述覆盖，那么加入判定的使用以便覆盖每个定义。便覆盖每个定义。 所有路径 所有定义 使用路径 所有使用 所有计算/ 某些判定使用 所有判定/ 某些计算使用 所有计算使用 所有定义 所有判定使用 分支 语句 Relative strengths of test strategies 测试策略的相对强度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策略越强、涉及的测试实例越多。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 技术比较Fault discovery percentages by fault origin 由错误起源发现错误的百分比发现技术起源需求设
49、计编码文档原型化40353515需求评审401505设计评审1555015代码审查20406525单元测试15200Effectiveness of fault-discovery techniques错误发现技术的效果需 求错 误设 计错 误编 码错 误文 档错 误评审一般极好极好好原型化好一般一般不适用测试坏坏好一般正确性证明坏坏一般一般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.集成测试也称为组装测试。当对单个组件的正确运行情况满意、认为它们达到了目标之后，将它们组合成一个工作系统。通过策划和调整这种集成方式，当出现错误后能大致了解是什么导致了这个错误。集成测试的方法Bottom-up 自底向上Top-down 自顶向下Big-bang 一次性Sandwich testing 三明
51、治测试Modified top-down 改进自顶向下Modified sandwich 改进三明治 Bottom-up测试步骤自底向上由一个叶模块开始，自底向上逐步添加新模块，组成程序的一个子系统或具有某一功能的模块族（群Cluster)设计驱动程序，协调测试数据的输入和输出测试去掉驱动模块，沿软件结构自下而上移动，把有关的子系统结合，形成更大的子系统。 Bottom-up测试示例ABDCEFGTestETestFTestGTestD,GTestCTestB,E,FTestA,B,C,D,E,F,GTop-down 测试步骤测试主控模块，由桩模块代替所有直属模块根据所确定的组合策略增加一个模
52、块，设计新的桩模块。测试，如果在新的条件下发现新的错误，执行下一步；否则执行上一步。回归测试（全部或部分地重复已做过的测试并返回）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 测试步骤 对上层模块采用自顶向下，较早显示程序的总体轮廓。目标层（中间层）的选择问题对某些关键模块（如具有I/O功能的模块、功能重要或含有特殊算法的模块）或子系统采用自底向
53、上组装和测试，以便容易地产生测试用例或减少重复测试次数。 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测试两种结合策略l深度优先先组装在软件结构的一条主控通路上的所有模块。l宽度优先沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。 Modified Sandwich集成策略
54、ABDCEFGTestETestFTestGTestATestD,GTestB,E,FTestA,B,C,D,E,F,GTestCTest BTest DTable 8.7. Comparison of integration strategies集成策略的比较集成策略的比较自底向上自顶向下改进的自顶向下一次性集成三明治改进的三明治集成早早早晚早早能产生基本运作程序的时间晚早早晚早早需要组件驱动程序是否是是是是需要存根程序否是是是是是开始工作的并行性中等低中等高中等高测试特殊路径的能力容易难容易容易中等容易计划和控制顺序的能力容易难难容易难难Builds At Microsoft 微软的集成方
55、法Market-driven integration strategyMarket-driven integration strategy市场驱动集成策略市场驱动集成策略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 the
56、 testing process 该过程在测试过程中包含顾客该过程在测试过程中包含顾客的同时，在设计、构建、测试组件之间迭代。的同时，在设计、构建、测试组件之间迭代。Work in teamsWork in teamslTeam size Team size 3 to 8 developers 3 3 to 8 developers 3到到8 8人一组人一组lDifferent teams are responsible for different Different teams are responsible for different features features 不同的小组负责不同
57、的特征不同的小组负责不同的特征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 微软同步且稳定的测试方法里程碑1：最重要的特征和共享的组件 设计、代码、原型、可用性测试 日常构造 特征集成、消除严重错误里程碑2：想要的特征 设计、代码、原型、可用性测试 日常构造 特征集
58、成里程碑3：最不重要的特征 设计、代码、原型、可用性测试 日常构造 特征集成和完成 发布、进行批量制造8.5 testing object-oriented system 测试面向对象系统Testing the code 代码测试Begin testing object-oriented system by asking several questions(通过提出几个问题开始测试面向对象系统)：When your code expects a unique value, is there a path that generates a unique result?期望代码什么时候有一个唯一值
59、，有一条路径产生一个唯一的结果吗？When there are many possible values, is there a way to select a unique result? 什么时候有许多可能值，有一种方法选择一个唯一的结果吗？Are there useful cases that are not handled? 还有未经处理的有用情况吗？Next, make sure that you check the objects and classes themselves for excesses and deficiencies: missing objects, unnec
60、essary classes, missing or unnecessary associations, or incorrect placement of associations or attributes.接着，确信检查了对象和类本身的过度和不足：遗漏的类、遗漏或不必要的关系、不正确的关系或属性安排。Objects might be missing 对象可能会遗漏lYou find asymmetric associations or generalization 发现有不对称的关系或类lYou find disparate attributes and operations on a
61、class 发现一个类中有完全无关的属性和操作lOne class is playing two or more roles 一个类承担两个或更多的职责lAn operation has no good target class 一个操作没有好的目标类lYou find two associations with the same name and purpose 发现两个关系有同样的名字和目的Differences between object-oriented and traditional testing面向对象测试和传统测试之间的差别OO测试中更容易和更困难的部分测试中更容易和更困难的
62、部分更容易：模块化、更快的开发、规模小的方法、复用、提前确定接口。更困难：继承、多态性、动态捆绑、复杂的接口、更多的集成Differences between object- oriented and traditional testing 2OO测试不同于传统测试的主要方面测试不同于传统测试的主要方面相同：计划和管理、模拟和载入测试、测试执行、测试开发不同：需求分析和验证、测试实例的产生、源代码分析、覆盖分析结论Requirements are likely to be expressed in the requirements document, but there are few too
63、ls to support validation of requirements expressed as objects and methods. 需求可能在需求文档中表述，但几乎没有什么工具来支持表述为对象和方法的需求进行验证。Most tools that assist in test case generation are not prepared to handle a model expressed in objects and methods.协助产生测试实例的大多数工具并不准备处理用对象和方法表述的模型。Most source code measurements are def
64、ined for procedural code, not for objects and methods. Traditional metrics such as cyclomatic numbers are of little use when assessing the size and complexity of object-oriented systems.大多数代码度量是针对过程代码设计的，而不是针对对象和方法。环路复杂度等传统的度量标准在评估面向对象系统的规模和复杂性时几乎没有什么用处。Because it is the interaction of objects that
65、is the source of complexity, code coverage measurements and tools are of less value in object-oriented testing than in traditional testing.由于对象的交互是复杂性的根源，代码覆盖度量和工具在面向对象测试中的价值要比在传统测试中小。8.6 Test planning 测试计划Establish test objectives 制定测试目标Design test cases 设计测试实例Write test cases 编写测试实例Testing test ca
66、ses 测试测试实例Execute tests 执行测试Evaluate test results 评价测试结果Parts of a test plan测试计划的组成目的文档引用系统概要主要测试进度表所需材料8.7 Automated testing tools 自动测试工具Code analysis tools 代码分析工具lStatic analysis 静态分析code analyzer 代码分析器structure checker 结构检查器data analyzer 数据分析器sequence checker 序列检查器lDynamic analysis 动态分析program mo
67、nitor 程序监视器Test execution tools 测试执行工具 lCapture and replay 获取和重放lStubs and drivers 存根和驱动lAutomated testing environments 自动测试环境Test case generators 测试实例生成器8.8 When to stop testing 何时停止测试1、Coverage criteria 覆盖标准 （覆盖85%的路径等）例如：ESTCA(error sensitive test cases analysis，错误敏感测试用例分析)覆盖准则 LCSAJ(linear code
68、sequence and jump coverage,线性代码序列与跳转覆盖)覆盖率准则2、错误数估计、错误数估计 错误播种法：基于两条假设错误播种法：基于两条假设 a.测试小组成员有意在程序中插入已知数目的错测试小组成员有意在程序中插入已知数目的错误；误； b.假设播种的错误与程序中实际错误有同样的种假设播种的错误与程序中实际错误有同样的种类和复杂度。类和复杂度。令令S：播种在一个程序中的错误数：播种在一个程序中的错误数 s：测试中检测到的播种错误数目：测试中检测到的播种错误数目 N：固有的错误数（非播种）：固有的错误数（非播种） n：测试中检测到的非播种错误的实际数目：测试中检测到的非播种
69、错误的实际数目在在a,b的条件下，有的条件下，有N的估计值为：的估计值为： N=n*S/s 因为因为b的假设并非总是成立，所以可对之进行改进。通的假设并非总是成立，所以可对之进行改进。通过独立测试来完成，即用两个小组来测试同一程序。过独立测试来完成，即用两个小组来测试同一程序。 设：程序中固有错误数估计值为设：程序中固有错误数估计值为n 1小组检测到错误数小组检测到错误数x 2小组检测到错误数小组检测到错误数y 两个小组检测到共有错误数两个小组检测到共有错误数q, 则两个小组各自的检测有效性为则两个小组各自的检测有效性为: E1=x/n=q/y E2=y/n=q/x 由由、可得可得 n=x*y
70、/q=q/(E1*E2) 例：若例：若x=25，y=30，q=15 则估计则估计 n=15/（0.6*0.5）=50 还剩错误数为还剩错误数为50-（30+25-15）=103、软件中的置信度 基于错误播种的假设检验。 Confidence in the software（置信度）定义为软件中没有错误的可能性。 假设认为程序中有N个错误，播种错误数S，测试程序发现所有S个错误，n是测试中发现实际非播种错误数。例如：取例如：取N=0，S=10,n=0 c=10/11=91%若需要若需要c=98%，则对，则对N=0，n=0 有有S/(S-0+1)=98% 得：得：S=49该方法的问题是：该方法的问题是： 只对只对N=0有效有效 在检测到所有播种错误之前不可能预测置信度在检测到所有播种错误之前不可能预测置信度改进：将置信度用检测到的播种错误数来估计。Identifying Fault-Prone Code确定容易出错的代码
