软件测试案例教程教学课件作者周元哲第二章节软件测试基本课件幻灯片.ppt

测试用例的设计步骤 1．制定测试用例的策略和思想，在测试计划中描述出来。 2. 设计测试用例的框架，也就是测试用例的结构 3. 细化结构，逐步设计出具体的测试用例 4.通过测试用例的评审，不断优化测试用例 测试用例维护 （1）产品特性没变，只是根据漏掉的缺陷来完善测试用例。这时候，增加和修改测试用例均可，因为当前被修改的测试用例对相应的版本都有效，不会影响某个特定版本所拥有的测试用例。 （2）原有产品特性发生变化，不是新功能特性，而是功能增强，这时候原有的测试用例只对先前版本有效，对当前新的版本无效。此时，绝不能修改测试用例，只能增加新的测试用例，不能影响原有的测试用例。 （3）原有功能取消了，这时只要将与该功能对应的测试用例在新版本上置为空标志或“无效”状态，但不能删除这些测试用例，因为它们对先前某个版本还是有效的。 （4）完全新增加的特性，需要增加新的测试用例。 测试充分性准则用来评价一个测试数据集（测试输入数据的集合）按照规范说明书，测试被测软件是否充分，是在测试之前，由相关各方根据质量、成本和进度等因素规定的，表现为对测试的要求，与软件需求和软件实现有关，具有以下的一些基本性质： ● 空测试对于任何软件都是不充分的。 ● 对任何软件都存在有限的充分测试数据集，这一性质称为有限性。 ● 如果一个测试数据集对一个软件系统的测试是充分的，那么再增加一些测试用例也是充分的，这一性质称为单调性。 ● 软件越复杂，需要的测试用例就越多，这一性质称为复杂性。 ● 测试得越多，进一步测试所能得到的充分性增长就越少，这一性质称为回报递减律。 测试的充分性问题 Weyuker将公理系统应用到软件测试的研究中， 给出了几条基于程序的测试数据集充分性公理。 公理2.1 (非外延性公理)：如果有两个功能相同而 实现不同的程序，对其中一个是充分的测试数据集 对另一个不一定是充分的。 公理2.2 (多重修改公理)：如果两个程序具有相同 的语法结构，对一个是充分的测试数据集对另一个 不一定是充分的。 公理2.3 (不可分解公理)：对一个程序进行了充分 的测试，并不表示对其中的成分都进行了充分的测 试。 公理2.4 (非复合性公理)：对程序各单元是充分的 测试数据集并不一定对整个程序（集成后）是充分 的。 停止测试的标准 因为无法判定当前发现的故障是否是最后一个故障，所以决定什么时候停止测试是一件非常困难的事。受经济条件的限制，测试最终一定要停止。 五类常用的停止测试标准 测试超过了预定的时间则停止测试。 执行了所有测试用例但没有发现故障，则停止测试。 使用特定的测试用例设计方法作为判断测试停止的基础。 正面指出测试停止的要求，比如发现并修改70个故障。 根据单位时间内查出故障的数量决定是否停止测试。 第三类标准把使用特定的测试用例设计方法作为判断测试停止的基础。 这类标准比前面两个标准优越，但它存在以下三方面的问题： 1. 在没有特定方法的测试阶段中无效，如系统测试阶段。 2. 这仍是一个主观的衡量标准，因为无法保证测试人员准确、严格地使用了某种方法，如边界值分析。 3. 这类标准只给定了一个测试用例设计的方法，并不是一个确定的目标。只有测试人员确实能够成功地运用测试用例设计的方法时，才能应用这类标准，并且这种标准只对某些测试阶段适用， 第四类标准正面指出了停止测试的要求。 这类标准虽然加强了测试的定义。但仍存在两个问题： 一个问题是如何知道将要查出的故障数，为了得到这个数字，要求： 1）．估计程序中故障的总数。 2）．估计这些故障中通过测试的比例，有多少故障可以很容易地被找出来。 3）．估计哪些故障产生于某些特定的设计过程，估计这些故障将在测试的哪个阶段被查出。 另一个明显的问题是过高地估计故障的总数。如果在测试开始时故障就少于估计的个数，若按这一标准则测试永远不会停止。 第五类标准看上去很容易，但在实际使用中要用到很多判断和直觉。  最好的测试停止标准或许是将上面讨论的几类标准结合起来。因为大部分设计项目在单元测试阶段并没有正式地跟踪查错过程，所以这一阶段最好的停止测试标准可能是第一类。对于集成测试和系统测试阶段，停止测试的标准可以是查出了预定数量的故障和达到了一定的测试期限，但还要分析故障—时间图，只有当该图指明这一阶段的测试效率很低时，才能停止测试。 输入／输出错误 输入／输出错误包括文件读取、接受键盘或鼠标输入出错，以及向打印机或屏幕等输出错误。检查输入/输出错误应考虑以下几个方面： ● 如果文件被显式地声明，它们的属性是否正确； ● 是否处理了文件、外设不存在或未准备好等错误的情况； ● 所有文件在使用之前是否都被打开了； ● 软件是否以预期方式