1 / 156

福州大学 · 软件学院 · 王灿辉 wangch8131@sina

Software Testing ( 软件测试 ). 福州大学 · 软件学院 · 王灿辉 wangch8131@sina.com. The Development Phase. Software Design. Code Generation. Software Testing. Software Quality Assurance.

octavius-julius
Télécharger la présentation

福州大学 · 软件学院 · 王灿辉 wangch8131@sina

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Testing(软件测试) 福州大学·软件学院·王灿辉 wangch8131@sina.com SOFTWARE ENGINEERING

  2. The Development Phase Software Design Code Generation Software Testing SOFTWARE ENGINEERING

  3. Software Quality Assurance • 软件质量保证（SQA）应该从产品的计划和设计开始，直到投入使用和售后服务的软件生存周期的每一个阶段中的每一个步骤，每一个有关的人，包括软件开发人员、测试人员、项目经理、销售人员和用户都必须严把质量关，只有这样才能保证软件的高质量，这就是现代软件质量保证的基本策略。 SOFTWARE ENGINEERING

  4. Software Testing • 测试是软件生命周期中的一个重要阶段。它直接影响着软件的质量和软件的可靠性。因此，人们往往花费了大量的时间和人力用于软件测试。在软件开发的全过程中，尽管对每个阶段均有严格的技术审查，但是，要发现所有的错误是不可能的。因此，软件在投入生产性运行之前要尽可能多地发现软件中的差错，以提高软件的质量。 SOFTWARE ENGINEERING

  5. Software Testing • 一旦编码开始，正式测试必须随即开始。 • 测试要求开发者首先抛弃“刚开发的软件是正确的”这一先入为主的观念，然后努力去构造测试用例来“破坏”软件。 • 神话：若我们确实擅长编程，就应当不会有错误。 SOFTWARE ENGINEERING

  6. Software Testing • 测试不应该被看作是安全网 • 只有在软件体系结构完成后,独立的测试组（ITG）才介入 • 任何测试策略都必须包含测试计划测试用例设计、测试执行及测试结果数据的收集与评估 • 测试是可以事先计划并可以系统地进行的一系列活动 SOFTWARE ENGINEERING

  7. Software Testing • The importance of software testing and its implications with respect to 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

  8. Software Testing • 开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。这样才能少犯错误。 • 错误的分类是技术性的。如：手册错误可能导致机毁人亡。假设某个财务软件有两个错误：错误A使该系统死机，错误B导致工资计算错误。按分类，错误A比错误B严重。但事实上B要比A严重。 SOFTWARE ENGINEERING

  9. 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 people. • 错觉：“程序编完后，研制工作就接近尾声了”。 • 实际：“测试占开发费用的40%至50%，对有关生命危险的软件甚至占80%” SOFTWARE ENGINEERING

  10. Software Testing • 测试必须按照软件需求和设计阶段所制订的测试计划进行，其结果以“测试分析报告”的形式提交。 回归测试 软件配置 错误 评价 改正 纠错 测试结果 测试 预期的结果 错误率数据` 测试配置 测试计划文档的一部分 预测的可靠性 可靠性 模型 SOFTWARE ENGINEERING

  11. 测试工作量 • 到目前为止，证明软件百分之百正确是不可能的，而且进行穷举测试也是不可能的。你永远也不能完成测试。因此我们的测试策略是在一定的开发周期和某种经济条件下，通过有限的测试以尽可能多地发现错误。 • 按软件工程中的40—20—40规则（编程工作占开发工作的20%，编程前---计划、需求分析、概要设计和详细设计，和编程后---测试的工作量各占开发工作的40%）。测试在整个软件的开发中必须占40%左右的工作量。 • 各类测试在测试总工作量所占的比例根据具体项目及开发人员的配置情况而定。 SOFTWARE ENGINEERING

  12. 测试结束标志 • 依照测试工作量及下述标准可判定是否可以结束测试过程： • 如果测试没有发现错误，说明测试失败，则必须更换测试人员作进一步测试。 • 如果有规律地出现一些严重的，需要修改设计的错误，则说明软件的质量和可靠性存在问题，必须重写相应模块，甚至整个软件。 • 如果软件功能正常，发现的错误容易纠正，则说明软件的质量和可靠性可接受（不排除测试不充分的可能）。 SOFTWARE ENGINEERING

  13. 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 successful 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

  14. Testing Objectives • 理解测试的目的是个很重要的意识问题。如果说测试的目的是为了说明程序中没有缺陷，那么测试人员就会向这个目标靠拢，因而下意识地选用一些不易暴露错误的测试示例。这样的测试是虚假的。目前的科技成果鉴定会普遍存在类似的虚假现象。 • 尽管已经明白了测试的目的是为了发现尽可能多的缺陷，但当测试人员真的发现了一堆缺陷时，却不可乐颠颠地跑去恭喜那个倒霉的开发者，否则会打架的。 SOFTWARE ENGINEERING

  15. 测试与质量 • 测试有助于提高软件的质量，但是提高软件的质量不能依赖于测试。测试与质量的关系很象在考试中“检查”与“成绩”的关系。 • 学习好的学生，在考试时通过认真检查能减少因疏忽而造成的答题错误，从而“提高”了考试成绩（取得他本来就该得的好成绩）。 而学习差的学生，他原本就不会做题目，无论检查多么细心，也不能提高成绩。 • 软件的高质量是设计出来的，而不是靠测试修补出来的。 SOFTWARE ENGINEERING

  16. 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 traceable to 20 percent of all program modules. SOFTWARE ENGINEERING

  17. 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 ENGINEERING

  18. Testing Principles(3) • 程序员或程序设计机构不应测试自己设计的程序； • 测试用例设计不仅要有确定的输入数据，而且要有确定的、详尽的预期输出数据； • 测试用例设计不仅要有合理的输入数据，还要有不合理的输入数据； • 除了检查程序是否做完了它应做的事之外，还要检查它是否做了不应做的事； • 保留全部测试用例，并作为软件配置的组成部分之一； • 程序中存在错误的概率与该段程序中已经发现的错误数成正比。 SOFTWARE ENGINEERING

  19. Testability(可测试性) • Operability: “The better it work,the more efficiently it 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

  20. Testability(可测试性) • Decomposability: “By controlling the scope of testing,we can more quickly isolate problems 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

  21. Attributes of a “good” 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 ENGINEERING

  22. 软件测试分类 • 测试分为如下的几类： • 模块测试（单元测试、分调、单调） • 组装测试（整体测试、集成测试、联调） • 有效性测试 （确认测试） • 系统（组装、集成）测试 • 并行测试（平行测试、双轨制运行） • α测试、β测试 • 验收测试（接收测试）：由用户完成 • 此外部分测试可能需要进行回归测试。 SOFTWARE ENGINEERING

  23. 软件测试步骤 模块 测试过的模块 模块测试 软件需求 经装配好 的软件 模块 确认测试 模块测试 确认过的软件 组装测试 …… 系统测试 模块测试 设计信息 模块 其他系统元素 可运行的系统 软件试运行、验收 SOFTWARE ENGINEERING

  24. 测试过程和研制过程的对应关系 系统定义 软件计划 需求分析 概要设计 详细设计 编码 模块测试 组装测试 确认测试 系统测试 研制是一个自顶向下逐步细化的过程，而测试则是按相反顺序的集成过程。 验收测试 SOFTWARE ENGINEERING

  25. 测试方法和测试技术 桌前检查 代码会审 静态技术 步行检查 路径测试 测试方法和测试技术 条件测试 白盒测试 数据测试 循环测试 动态技术 等价类划分 边界值分析 黑盒测试 比较测试 SOFTWARE ENGINEERING

  26. 测试用的程序实例 • 三角形问题：接受3个1—100之间的整数，判别由这3条边构成的三角形的类型：等边、等腰、不等边或非三角形。 • NextDate函数：接受3个整数，输出非法日期或输入日期的下一个日期。 • 佣金问题：销售商根据不同的销售额可以获得不同的奖励。 SOFTWARE ENGINEERING

  27. 测试方法和测试技术 —程序的静态分析 • 检查逻辑设计和编码错误。不涉及程序的实际执行，用人工进行分析。 • 桌前检查(Desk Check)：程序员自己检查程序效果不太理想。解决办法：互相交换程序检查。 • 代码会审(Code Inspections)：由一组人通过阅读、讨论和争议，对程序进行静态分析的过程。 • 步行检查(Walkthroughs)：预先准备测试数据，让与会者充当“计算机”一检查程序的状态。有时比真正运行程序可能发现更多的错误。 SOFTWARE ENGINEERING

  28. 测试方法和测试技术 —程序的动态测试 • 在程序的测试中，十全十美的测试情况是不存在的，即任何程序的测试都是不彻底的，测试不能发现程序中的所有错误。 • 在测试方法中，最简单的，也是最差的一种测试方法是随机输入的测试。这种将随机选择的输入值作为输入数据的测试往往检测不出较多的错误。通常，在程序的测试中采用二类方法：黑盒法和白盒法。 SOFTWARE ENGINEERING

  29. 测试方法和测试技术 —程序的动态测试 • 无论是白盒法还是黑盒法，关键都是如何选择高效的测试用例(高效的测试用例是指一个用例能够覆盖尽可能多的测试情况，从而提高测试效率)。 • Black-box testing alludes to test that are conducted at the software interface. • White-box testing of software is predicated on close examination of procedural detail. SOFTWARE ENGINEERING

  30. 测试方法和测试技术 —程序的动态测试 • 由于无法进行穷举测试，所以测试用例(test case)的设计在软件测试中起很重要的作用。测试用例设计的基本目的是确定一组最有可能发现某个错误或某类错误的测试数据。 • 测试用例的设计技术有许多种。如：路径测试，各种逻辑覆盖（语句、条件、循环等），等价类划分，边界值分析，因果图和程序图等图形技术。 SOFTWARE ENGINEERING

  31. 测试方法和测试技术 —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

  32. 测试方法和测试技术 —White-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 their operational bounds;and (4)exercise internal data structures to assure their validity. SOFTWARE ENGINEERING

  33. 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 defining 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

  34. White-box Testing —Basic Path Testing —Flow Graph Notation Sequence If-then-else Case While Until Flow graph Notation SOFTWARE ENGINEERING

  35. White-box Testing —Basic Path Testing —Flow Graph Notation • Translating Flow chart and PDL to a flow graph. 1 Edge 2,3 6 4,5 Region 7 8 R3 R2 R1 9 R4 10 Node 11 SOFTWARE ENGINEERING

  36. White-box Testing —Basic Path Testing —Cyclomatic complexity • McCabe认为程序的复杂性很大程度上取决于程序控制流的复杂性。 • Cyclomatic(环路) Complexity is a software metric that provides 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. SOFTWARE ENGINEERING

  37. White-box Testing —Basic Path Testing —Cyclomatic complexity • Complexity is computed in one of three ways: • 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. SOFTWARE ENGINEERING

  38. White-box Testing —Basic Path Testing —Cyclomatic complexity • 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之间时被认为是良好的结构和恰当的复杂性(度)。 SOFTWARE ENGINEERING

  39. White-box Testing —Basic Path Testing —Independent Paths • 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 statements have been executed at least once. SOFTWARE ENGINEERING

  40. White-box Testing —Basic Path Testing —Independent Paths • 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 independent path must move along at least edge that has not been traversed before the path is defined. SOFTWARE ENGINEERING

  41. White-box Testing —Basic Path Testing —Independent Paths • 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 • The path 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11is not considered to be an independent path. SOFTWARE ENGINEERING

  42. White-box Testing —Basic Path Testing —Deriving Test Cases • 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 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. SOFTWARE ENGINEERING

  43. 弱 强 语 句 覆 盖 判 定 覆 盖 条 件 覆 盖 判 定 条 件 覆 盖 条 件 组 合 覆 盖 White-box Testing —Condition Testing • 白盒法又称为逻辑覆盖法，因为要以程序（模块）内部的逻辑结构为基础来设计测试用例，主要用于单元测试。 SOFTWARE ENGINEERING

  44. White-box Testing —Condition Testing • 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. • 条件测试包括四类覆盖：判定覆盖、条件覆盖 、判定/条件覆盖 、条件的组合覆盖 SOFTWARE ENGINEERING

  45. White-box Testing —Condition Testing 开始 a A>1 AND B=0 Y c X=X/A 被测试的程序的流程图 N b A=2 OR X>1 Y e X=X+1 N d 结束 SOFTWARE ENGINEERING

  46. White-box Testing—Condition Testing —判定覆盖 • 判定覆盖又称作分支覆盖，它是使程序中的每个判定至少出现一次“真值”和一次“假值”，即程序中的每个分支至少经过一次。 • 对此，我们可以设计如下测试数据对判定逻辑进行覆盖： • A=3，B=0，X=1(通过路径acd) • A=2，B=1，X=3(通过路径abe) SOFTWARE ENGINEERING

  47. White-box Testing—Condition Testing —条件覆盖 • 条件覆盖是判定中的每个条件的所有可能的结果至少出现一次，并且使每条语句(不是每个分支)至少执行一次(语句覆盖)。 • 对此，条件覆盖的测试可由下面两组数据进行： • A=2，B=0，X=4 (通过路径ace) • A=1，B=1，X=1 (通过路径abd) • 条件覆盖一般情况下比判定覆盖要强。 SOFTWARE ENGINEERING

  48. White-box Testing—Condition Testing —条件覆盖 • 但是，也有例外的情况（如果，测试数据设计得不好的话），例如下例所示： • IF A>1 AND B=0 中，若设计一组条件覆盖的测试数据如下： • A=2，B=1 • A=1，B=0 • 则这组数据满足条件覆盖，但不会执行IF语句中的THEN的子句。 SOFTWARE ENGINEERING

  49. White-box Testing—Condition Testing —条件覆盖 • 设计下面两组数据： • A=1，B=0，X=3 • A=2，B=1，X=1 • 满足条件覆盖（四个条件：A>1, B=0, A=2, X>1均取过“真”值和“假”值）但它们都通过路径abe，所以不满足判定覆盖。 SOFTWARE ENGINEERING

  50. White-box Testing—Condition Testing —判定/条件覆盖 • 判定/条件覆盖方式是使判定中每个条件的所有可能结果至少出现一次。而每个判定本身所有的可能结果也至少出现一次。 • 下面两组数据满足判定/条件覆盖： • A=2，B=0，X=4 (通过路径ace) • A=1，B=1，X=1 (通过路径abd) SOFTWARE ENGINEERING

More Related