第十二讲测试A.ppt

第 十 二 讲 测试（Testing) 本讲（第七章）的主要内容 一、软件测试及其目标 二、软件测试准则 三、测试阶段的信息流 四、测试方法 五、测试阶段 一、Myers的软件测试的定义 测试是为了发现程序中的错误而执行程序的过程； 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； 成功的测试是发现了迄今为止尚未发现的错误的测试 。 测试的意义和几点说明 软件质量保证的最重要手段 是否达到需求说明的功能和预期的指标 测试耗时费力，应用最小的测试代价获得最大的测试效果。 测试是为了发现错误，不是为了证明程序无错误。 测试不能证明程序中没有错误。 测试的可信度（dependability)问题。 “ Testing is the unavoidable part of any responsible effort to develop a software system.” — William Howden “ 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.” — we unknown 二、软件测试准则 所有的测试都应追溯到用户需求，从用户角度看，最严重的错误是不能满足需求。 制定测试计划，并严格执行，排除随意性。测试计划在需求分析阶段就开始了，详细的测试用例在设计阶段确定。 Pareto原则：所发现错误的80%很可能源于程序模块的20%中。 测试应当从‘小规模’开始，逐步转向‘大规模’。 穷举测试是不可能的（Exhaustive testing）。 由独立的第三方或专门的测试小组进行独立测试。 Cont. 测试用例由输入数据和相应的预期输出组成。 测试用例不仅选用合理的输入数据，还要选择不合理的。 不仅检查程序是否做了应该做的事，还应该检查是否不应该做的。 长期保留测试用例，以便进行回归测试和维护。 软件测试的对象 软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。 需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。 为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。 确认(Validation是否满足用户的需求？)是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。 需求规格说明的确认 程序的确认 (静态确认、动态确认) 验证(Verification是否实现了所设计的要求？)，试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。 三、测试信息流 软件配置：软件需求规格说明、软件设计规格说明、源代码等； 测试配置：测试计划、测试用例、测试程序等； 测试工具：测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。 测试结果分析：比较实测结果与预期结果，评价错误是否发生。 排错(调试)：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。 修正后的文档再测试：直到通过测试为止。 通过收集和分析测试结果数据，对软件建立可靠性模型 利用可靠性分析，评价软件质量： 软件的质量和可靠性达到可以接受的程度； 所做的测试不足以发现严重的错误； 如果测试发现不了错误，可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。 测试与软件开发各阶段的关系 软件开发过程是一个自顶向下，逐步细化的过程 软件计划阶段定义软件作用域 软件需求分析建立软件信息域、功能和性能需求、约束等 软件设计 把设计用某种程序设计语言转换成程序代码 测试过程是依相反顺序安排的自底向上，逐步集成的过程。 四、测试技术的分类 静态测试 代码会审 code inspection 走查 walk-through 办公桌检查 desk checking 例如：Yourdon结构化走通、IBM的Fagan检查 动态测试 黑盒测试 白盒测试 穷举和选择测试。 静态测试 人工测试，代码复审,即人工方式进行的代码复审。 目的：检查程序的静态结构，找出编译不能发现的错误和人的主观认识上的偏差。 范围：需求定义、设计文档、源代码（着重分析） 特点： Myers的研究表明，对于某些类型的错误，静态测试更有效 。