1、SOFTWARE ENGINEERING,福州大学软件学院王灿辉 ,Software Testing(软件测试),SOFTWARE ENGINEERING,Code Generation,The Development Phase,Software Testing,Software Design,SOFTWARE ENGINEERING,Software Quality Assurance,软件质量保证（SQA）应该从产品的计划和设计开始，直到投入使用和售后服务的软件生存周期的每一个阶段中的每一个步骤，每一个有关的人，包括软件开发人员、测试人员、项目经理、销售人员和用户都必须严把质量关，只有这
2、样才能保证软件的高质量，这就是现代软件质量保证的基本策略。,SOFTWARE ENGINEERING,Software Testing,测试是软件生命周期中的一个重要阶段。它直接影响着软件的质量和软件的可靠性。因此，人们往往花费了大量的时间和人力用于软件测试。在软件开发的全过程中，尽管对每个阶段均有严格的技术审查，但是，要发现所有的错误是不可能的。因此，软件在投入生产性运行之前要尽可能多地发现软件中的差错，以提高软件的质量。,SOFTWARE ENGINEERING,Software Testing,一旦编码开始，正式测试必须随即开始。 测试要求开发者首先抛弃“刚开发的软件是正确的”这一先入为
3、主的观念，然后努力去构造测试用例来“破坏”软件。 神话：若我们确实擅长编程，就应当不会有错误。,SOFTWARE ENGINEERING,Software Testing,测试不应该被看作是安全网 只有在软件体系结构完成后,独立的测试组（ITG）才介入 任何测试策略都必须包含测试计划测试用例设计、测试执行及测试结果数据的收集与评估 测试是可以事先计划并可以系统地进行的一系列活动,SOFTWARE ENGINEERING,Software Testing,The importance of software testing and its implications with respect to
4、 software quality cannot be overemphasized. Software testing is a critical element of software quality assurance and represents the ultimate review of specification,design,and coding.,SOFTWARE ENGINEERING,Software Testing,开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。这样才能少犯错误。 错误的分类是技术性的。如：手册错误可能导致机毁人亡。假设某个财务软件有两
5、个错误：错误A使该系统死机，错误B导致工资计算错误。按分类，错误A比错误B严重。但事实上B要比A严重。,SOFTWARE ENGINEERING,Software Testing,In fact,testing is the one step in the software engineering process that could be viewed (psychologically,at least) as destructive rather than constructive. Software developer are by their nature constructive p
6、eople. 错觉：“程序编完后，研制工作就接近尾声了”。 实际：“测试占开发费用的40%至50%，对有关生命危险的软件甚至占80%”,SOFTWARE ENGINEERING,Software Testing,测试,可靠性 模型,纠错,评价,软件配置,测试配置,测试结果,错误,改正,预期的结果,错误率数据,预测的可靠性,测试必须按照软件需求和设计阶段所制订的测试计划进行，其结果以“测试分析报告”的形式提交。,回归测试,测试计划文档的一部分,SOFTWARE ENGINEERING,测试工作量,到目前为止，证明软件百分之百正确是不可能的，而且进行穷举测试也是不可能的。你永远也不能完成测试。因此
7、我们的测试策略是在一定的开发周期和某种经济条件下，通过有限的测试以尽可能多地发现错误。 按软件工程中的402040规则（编程工作占开发工作的20%，编程前-计划、需求分析、概要设计和详细设计，和编程后-测试的工作量各占开发工作的40%）。测试在整个软件的开发中必须占40%左右的工作量。 各类测试在测试总工作量所占的比例根据具体项目及开发人员的配置情况而定。,SOFTWARE ENGINEERING,测试结束标志,依照测试工作量及下述标准可判定是否可以结束测试过程： 如果测试没有发现错误，说明测试失败，则必须更换测试人员作进一步测试。 如果有规律地出现一些严重的，需要修改设计的错误，则说明软件的
8、质量和可靠性存在问题，必须重写相应模块，甚至整个软件。 如果软件功能正常，发现的错误容易纠正，则说明软件的质量和可靠性可接受（不排除测试不充分的可能）。,SOFTWARE ENGINEERING,Testing Objectives,Testing is a process of executing a program with the intent of finding an error. A good test case is one that has a high proba-bility of finding an as-yet undiscovered error. A succes
9、sful test is one that uncovers an as-yet undiscovered error. Testing cannot show the absence of defects,it can only show that software errors are present.,SOFTWARE ENGINEERING,Testing Objectives,理解测试的目的是个很重要的意识问题。如果说测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。这样的测试是虚假的。目前的科技成果鉴定会普遍存在类似的虚
10、假现象。 尽管已经明白了测试的目的是为了发现尽可能多的缺陷，但当测试人员真的发现了一堆缺陷时，却不可乐颠颠地跑去恭喜那个倒霉的开发者，否则会打架的。,SOFTWARE ENGINEERING,测试与质量,测试有助于提高软件的质量，但是提高软件的质量不能依赖于测试。测试与质量的关系很象在考试中“检查”与“成绩”的关系。 学习好的学生，在考试时通过认真检查能减少因疏忽而造成的答题错误，从而“提高”了考试成绩（取得他本来就该得的好成绩）。 而学习差的学生，他原本就不会做题目，无论检查多么细心，也不能提高成绩。 软件的高质量是设计出来的，而不是靠测试修补出来的。,SOFTWARE ENGINEERIN
11、G,Testing Principles(1),All tests should be traceable to customer requirements. Tests should be planed long before testing begins. The Pareto principle applies to software testing. Stated simply,the Pareto principle implies that 80 percent of all errors uncovered during testing will likely be tracea
12、ble to 20 percent of all program modules.,SOFTWARE ENGINEERING,Testing Principles(2),Testing should begin “in the small” and progress toward testing “in the large.” Exhaustive testing is not possible. To be most effective,testing should be conducted by an independent third party.,SOFTWARE ENGINEERIN
13、G,Testing Principles(3),程序员或程序设计机构不应测试自己设计的程序； 测试用例设计不仅要有确定的输入数据，而且要有确定的、详尽的预期输出数据； 测试用例设计不仅要有合理的输入数据，还要有不合理的输入数据； 除了检查程序是否做完了它应做的事之外，还要检查它是否做了不应做的事； 保留全部测试用例，并作为软件配置的组成部分之一； 程序中存在错误的概率与该段程序中已经发现的错误数成正比。,SOFTWARE ENGINEERING,Testability(可测试性),Operability: “The better it work,the more efficiently it
14、can be tested.” Observability: “What you see is what you test.” Controllability: “The better we can control the software,the more the testing can be automated and optimized.”,SOFTWARE ENGINEERING,Testability(可测试性),Decomposability: “By controlling the scope of testing,we can more quickly isolate prob
15、lems and perform smarter retesting.” Simplicity: “The less there is to test,the more quickly we can test it.” Stability: “The fewer the changes,the fewer the disruptions to testing.” Understandability: “The more information we have,the smarter we will test.”,SOFTWARE ENGINEERING,Attributes of a “goo
16、d” test,A good test has a high probability of finding an error. A good test is not redundant. A good test should be “best of breed.” The test that has the highest likelihood of uncovering a whole class of errors should be used. A good test should be neither too simple nor too complex.,SOFTWARE ENGIN
17、EERING,软件测试分类,测试分为如下的几类： 模块测试（单元测试、分调、单调） 组装测试（整体测试、集成测试、联调） 有效性测试 （确认测试） 系统（组装、集成）测试 并行测试（平行测试、双轨制运行）测试、测试 验收测试（接收测试）：由用户完成 此外部分测试可能需要进行回归测试。,SOFTWARE ENGINEERING,软件测试步骤,模块测试,确认测试,组装测试,模块,模块测试,模块测试,模块,模块,系统测试,设计信息,经装配好 的软件,测试过的模块,软件需求,确认过的软件,其他系统元素,可运行的系统,软件试运行、验收,SOFTWARE ENGINEERING,测试过程和研制过程的对应关
18、系,系统定义,需求分析,详细设计,组装测试,模块测试,确认测试,系统测试,验收测试,软件计划,概要设计,编码,研制是一个自顶向下逐步细化的过程，而测试则是按相反顺序的集成过程。,SOFTWARE ENGINEERING,测试方法和测试技术,测试方法和测试技术,静态技术,动态技术,桌前检查,代码会审,黑盒测试,步行检查,白盒测试,路径测试,条件测试,数据测试,循环测试,等价类划分,边界值分析,比较测试,SOFTWARE ENGINEERING,测试用的程序实例,三角形问题：接受3个1100之间的整数，判别由这3条边构成的三角形的类型：等边、等腰、不等边或非三角形。 NextDate函数：接受3个
19、整数，输出非法日期或输入日期的下一个日期。 佣金问题：销售商根据不同的销售额可以获得不同的奖励。,SOFTWARE ENGINEERING,测试方法和测试技术 程序的静态分析,检查逻辑设计和编码错误。不涉及程序的实际执行，用人工进行分析。 桌前检查(Desk Check)：程序员自己检查程序效果不太理想。解决办法：互相交换程序检查。 代码会审(Code Inspections)：由一组人通过阅读、讨论和争议，对程序进行静态分析的过程。 步行检查(Walkthroughs)：预先准备测试数据，让与会者充当“计算机”一检查程序的状态。有时比真正运行程序可能发现更多的错误。,SOFTWARE ENG
20、INEERING,测试方法和测试技术 程序的动态测试,在程序的测试中，十全十美的测试情况是不存在的，即任何程序的测试都是不彻底的，测试不能发现程序中的所有错误。 在测试方法中，最简单的，也是最差的一种测试方法是随机输入的测试。这种将随机选择的输入值作为输入数据的测试往往检测不出较多的错误。通常，在程序的测试中采用二类方法：黑盒法和白盒法。,SOFTWARE ENGINEERING,测试方法和测试技术 程序的动态测试,无论是白盒法还是黑盒法，关键都是如何选择高效的测试用例(高效的测试用例是指一个用例能够覆盖尽可能多的测试情况，从而提高测试效率)。 Black-box testing allude
21、s to test that are conducted at the software interface. White-box testing of software is predicated on close examination of procedural detail.,SOFTWARE ENGINEERING,测试方法和测试技术 程序的动态测试,由于无法进行穷举测试，所以测试用例(test case)的设计在软件测试中起很重要的作用。测试用例设计的基本目的是确定一组最有可能发现某个错误或某类错误的测试数据。 测试用例的设计技术有许多种。如：路径测试，各种逻辑覆盖（语句、条件、循
22、环等），等价类划分，边界值分析，因果图和程序图等图形技术。,SOFTWARE ENGINEERING,测试方法和测试技术 White-box Testing,White-box testing,sometimes called glass-box testing,is a test case design method that uses the control structure of the procedural design to derive test cases. 白盒法检查程序的内部结构，即检测程序的逻辑。,SOFTWARE ENGINEERING,测试方法和测试技术 White-
23、box Testing,Using white-box testing methods,the software engineer can derive test cases that (1)guarantee that all independent paths within a module have been exercised at least once;(2)exercise all logical decision on their true and false sides;(3)execute all loops at their boundaries and within th
24、eir operational bounds;and (4)exercise internal data structures to assure their validity.,SOFTWARE ENGINEERING,White-box Testing Basic Path Testing,The basic path method enables the test designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defini
25、ng a basic set of execution paths.Test cases derived to exercise the basic set are guaranteed to execute every statement in the program at least one time during testing.,SOFTWARE ENGINEERING,White-box Testing Basic Path Testing Flow Graph Notation,Sequence,If-then-else,Case,While,Until,Flow graph No
26、tation,SOFTWARE ENGINEERING,Translating Flow chart and PDL to a flow graph.,2,3,9,8,7,6,1,4,5,10,11,R1,R4,R3,R2,Node,Edge,Region,White-box Testing Basic Path Testing Flow Graph Notation,SOFTWARE ENGINEERING,McCabe认为程序的复杂性很大程度上取决于程序控制流的复杂性。 Cyclomatic(环路) Complexity is a software metric that provides
27、 a quantitative measure of the logical complexity of a program. Cyclomatic complexity has a foundation in graph theory and provides us with an extremely useful software metric.,White-box Testing Basic Path Testing Cyclomatic complexity,SOFTWARE ENGINEERING,Complexity is computed in one of three ways
28、: The number of regions of flow graph correspond to the cyclomatic complexity. Cyclomatic complexity,V(G),for a flow graph G is define as V(G)=Edge-Node+2. cyclomatic complexity,V(G),for a flow graph G is also define as V(G)=P+1,where P is the number of predicate nodes contained in the flow graph G.
29、,White-box Testing Basic Path Testing Cyclomatic complexity,SOFTWARE ENGINEERING,Cyclomatic complexity for example can be computed: The flow graph has 4 regions. V(G)=11edges-9nodes+2=4 V(G)=3 predicate nodes+1=4 测试工作量和潜在错误的个数与V(G)成正比 McCabe认为在一个模块内 V(G)一般应控制在10以内，当V(G)在3至9之间时被认为是良好的结构和恰当的复杂性(度)。,Wh
30、ite-box Testing Basic Path Testing Cyclomatic complexity,SOFTWARE ENGINEERING,The value computed for cyclomatic complexity defines the number of independent paths I the basic set of a program and provide us with an upper bound for the number of the tests that must be conducted to ensure that all sta
31、tements have been executed at least once.,White-box Testing Basic Path Testing Independent Paths,SOFTWARE ENGINEERING,An independent path is any path through the program that introduces at least one new set of processing statements or a new condition.When stated in terms of a flow graph,an independe
32、nt path must move along at least edge that has not been traversed before the path is defined.,White-box Testing Basic Path Testing Independent Paths,SOFTWARE ENGINEERING,A set of independent paths for example: Path 1:1-11 Path 2:1-2-3-4-5-10-1-11 Path 3:1-2-3-6-8-9-10-1-11 Path 4:1-2-3-6-7-9-10-1-11
33、 The path 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 is not considered to be an independent path.,White-box Testing Basic Path Testing Independent Paths,SOFTWARE ENGINEERING,The basic path testing method can be applied to a procedural design or to source code. Using the design or code as a foundation, draw a
34、corresponding flow graph. Determine the cyclomatic complexity of the resultant flow graph. Determine a basic set of linearly independent paths. Prepare test cases that will force execution of each path in the basic set.,White-box Testing Basic Path Testing Deriving Test Cases,SOFTWARE ENGINEERING,白盒
35、法又称为逻辑覆盖法，因为要以程序（模块）内部的逻辑结构为基础来设计测试用例，主要用于单元测试。,White-box Testing Condition Testing,SOFTWARE ENGINEERING,Condition testing is a test case design method that exercises the logical conditions contained in a program module. The condition testing method focuses on testing each condition in the program.
36、条件测试包括四类覆盖：判定覆盖、条件覆盖 、判定/条件覆盖 、条件的组合覆盖,White-box Testing Condition Testing,SOFTWARE ENGINEERING,White-box Testing Condition Testing,开始,X=X/A,A1 AND B=0,结束,X=X+1,A=2 OR X1,Y,Y,被测试的程序的流程图,a,e,d,c,b,N,N,SOFTWARE ENGINEERING,判定覆盖又称作分支覆盖，它是使程序中的每个判定至少出现一次“真值”和一次“假值”，即程序中的每个分支至少经过一次。 对此，我们可以设计如下测试数据对判定逻辑进
37、行覆盖：A=3，B=0，X=1(通过路径acd)A=2，B=1，X=3(通过路径abe),White-box TestingCondition Testing 判定覆盖,SOFTWARE ENGINEERING,条件覆盖是判定中的每个条件的所有可能的结果至少出现一次，并且使每条语句(不是每个分支)至少执行一次(语句覆盖)。 对此，条件覆盖的测试可由下面两组数据进行：A=2，B=0，X=4 (通过路径ace)A=1，B=1，X=1 (通过路径abd) 条件覆盖一般情况下比判定覆盖要强。,White-box TestingCondition Testing 条件覆盖,SOFTWARE ENGINE
38、ERING,但是，也有例外的情况（如果，测试数据设计得不好的话），例如下例所示： IF A1 AND B=0 中，若设计一组条件覆盖的测试数据如下： A=2，B=1A=1，B=0 则这组数据满足条件覆盖，但不会执行IF语句中的THEN的子句。,White-box TestingCondition Testing 条件覆盖,SOFTWARE ENGINEERING,设计下面两组数据：A=1，B=0，X=3A=2，B=1，X=1 满足条件覆盖（四个条件：A1, B=0, A=2, X1均取过“真”值和“假”值）但它们都通过路径abe，所以不满足判定覆盖。,White-box TestingCond
39、ition Testing 条件覆盖,SOFTWARE ENGINEERING,判定/条件覆盖方式是使判定中每个条件的所有可能结果至少出现一次。而每个判定本身所有的可能结果也至少出现一次。 下面两组数据满足判定/条件覆盖：A=2，B=0，X=4 (通过路径ace)A=1，B=1，X=1 (通过路径abd),White-box TestingCondition Testing 判定/条件覆盖,SOFTWARE ENGINEERING,条件的组合覆盖所设计的测试数据使每个判定中的条件的各种组合至少出现一次，并且每条语句至少执行一次。 例子中条件的所有可能组合有8种： A1,b0 A2,X1 A1,
40、b0 A2,X1 A1,b0 A2,X1 A1,b0 A2,X1,White-box TestingCondition Testing 条件的组合覆盖,SOFTWARE ENGINEERING,要测试上述8种组合（满足条件组合覆盖），可设计下述4组数据： A=2,B=0,X=4 覆盖 A=2,B=1,X=1 覆盖 A=1,B=0,X=2 覆盖 A=1,B=1,X=1 覆盖 但上述的4组测试数据并没有覆盖所有的每一条路径（路径acd未通过）。,White-box TestingCondition Testing 条件的组合覆盖,SOFTWARE ENGINEERING,The data flow
41、 testing method selects test paths of a program according to the location of definition and uses of variables in the program. One simple data flow testing strategy is to require that every DU chain be covered at least once.We refer to this strategy as the DU testing strategy. It has been shown that
42、DU testing does not guaranteed to be coverage of all branches of a program.,White-box Testing Data Flow Testing,SOFTWARE ENGINEERING,Loop testing is a white-box testing technique that focuses exclusively on the validity of loop constructs. Four different classes of loops can be defined: simple loops
43、,concatenated loops,nested loops, and unstructured loops.,White-box Testing Loop Testing,SOFTWARE ENGINEERING,The following set of tests should be applied to simple loops. Skip the loop entirely. Only one pass through the loop. Two passes through the loop. M passes through the loop where mn. n-1,n,n
44、+1 passes through the loop. Where n is the maximum number of allowable passes through the loop.,White-box Testing Loop Testing Simple Loops,SOFTWARE ENGINEERING,Beizer suggests an approach that will help to reduce the number of tests: Start at the innermost loop.Set all other loops to minimum values
45、. Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter(e.g.,loop counter)values.Add other tests for out-of range or excluded values.,White-box Testing Loop Testing Nested Loops(1),SOFTWARE ENGINEERING,Work outward,conducting tests for th
46、e next loop,but keeping all other outer loops at minimum values and other nested loops to “typical” values. Continue until all loops have been tested.,White-box Testing Loop Testing Nested Loops(2),SOFTWARE ENGINEERING,Concatenated loops can be tested using the approach defined above for simple loop
47、s if each of the loops is independent of the other. When the loops are not independent,the approach applied to nested loops is recommended.,White-box Testing Loop Testing Concatenated Loops,SOFTWARE ENGINEERING,Whenever possible,this class of loops should be redesigned to reflect the use of the stru
48、ctured programming constructs.,White-box Testing Loop Testing Unstructured Loops,SOFTWARE ENGINEERING,测试方法和测试技术 Black-box Testing,黑盒法是把测试对象看作一个黑盒，测试时完全不考虑程序的内部的逻辑结构与内部特性，只需根据需求规格说明书，测试程序的功能或程序的外部特性。因此黑盒法又称为功能测试或数据驱动测试。常用的测试方法有：,软件,输入,输出,SOFTWARE ENGINEERING,测试方法和测试技术 Black-box Testing,Black-box test
49、ing focuses on the functional requirements of the software.That is,black-box testing enables the software engineer to derive sets of input conditionals that will fully exercise all functional requirements for a program. Black-box testing is not an alternative to white-box techniques.Rather,it is a complementary approach that is likely to uncover a different class of errors than white-box methods.,
