Chapter12软件测试策略.ppt

Chapter 12软件测试策略Software Testing Strategies Myers的软件测试的定义 测试是为了发现程序中的错误而执行程序的过程； 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； 成功的测试是发现了迄今为止尚未发现的错误的测试 。 测试的意义和几点说明 软件质量保证的最重要手段 是否达到需求说明的功能和预期的指标 测试耗时费力，应用最小的测试代价获得最大的测试效果。 测试是为了发现错误，不是为了证明程序无错误。 测试不能证明程序中没有错误。 测试的可信度（dependability)问题。 “ Optimism is the occupational hazard of programming; testing is the treatment.” — Kent Beck “ Testing is the unavoidable part of any responsible effort to develop a software system.” — William Howden “Errors are more common, more pervasive, and more troublesome in software than other technologies.” — David Parnas “ The first mistake that people make is thinking that the testing team is responsible for assuring quality.” — Brian Marick “Every program does something right; it just may not be the thing we want it to do.” 软件测试的对象 软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。 需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。 12.1 软件测试的策略性方法 测试准则 验收与确认 软件测试的组织 传统的软件体系结构的测试策略(集成测试) OO软件体系结构的测试策略 测试完成的标准 软件测试准则 所有的测试都应追溯到用户需求，从用户角度看，最严重的错误是不能满足需求。 制定测试计划，并严格执行，排除随意性。测试计划在需求分析阶段就开始了，详细的测试用例在设计阶段确定。 Pareto原则：所发现错误的80%很可能源于程序模块的20%中。 测试应当从‘小规模’开始，逐步转向‘大规模’。 穷举测试是不可能的（Exhaustive testing）。 由独立的第三方或专门的测试小组进行独立测试。 Cont. 测试用例由输入数据和相应的预期输出组成。 测试用例不仅选用合理的输入数据，还要选择不合理的。 不仅检查程序是否做了应该做的事，还应该检查是否不应该做的。 长期保留测试用例，以便进行回归测试和维护。 不同的测试技术适用于不同的时间点。 测试和调试是不同的活动，但任何测试策略中都必须包括调试。 验收与确认 Verification and Validation,VV 确认(我们在构造正确的产品吗？)是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。 需求规格说明的确认 程序的确认 (静态确认、动态确认) 验证(我们在正确地构造产品吗？)，试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。 验证和确认包含了广泛SQA活动。 软件测试的组织 开发人员总是要负责单元测试； 多数情况下，开发人员也进行集成测试； 在软件体系结构完成后（集成测试结束），独立测试小组（ITG）才开始介入。 开发人员并不是将程序交给ITG而一走了之。 从分析与设计开始到计划、制定测试规程，ITG参与整个项目过程。 Testing Strategy 完成测试的标准（Criteria) 规定测试的方法和应该达到的条件，如白盒测试的语句覆盖达到90%等。可以开发有关的工具。 根据可靠性模型，规定至少要查出的错误数。 测试的可信度（Dependability）问题。 12.2 策略问题 早在测试之前，就要以量化的方式规定产品需求。 用可测量的术语陈述测试目标。 了解用户并为每个用户建立用户轮廓。 建立强调“快速周期测试”的测试计划。 建立能够测试自身的“健壮”软件。 测试之前，利用有效的正式技术评审作为过滤器。 实施正式技术评审以评估测试策略和测试用例本