第9软件测试精要.ppt

9.1 基本概念 9.1.1 软件测试的必要性 9.1.2 软件测试目的 9.1.3 软件缺陷定义 9.1.4 测试用例 9.1.5 软件测试的原则 9.1.1 软件测试的必要性 1. 问题引入 根据统计表明，软件测试的工作量往往占软件开发总工作量的40%以上，可能我们会思考这样一个问题，花费那么多资源在测试上，花费在一个对整个软件工程“没有任何建设成果”的活动上，值得吗？ 9.1.1 软件测试的必要性 2. 解答问题 答案是肯定的。 软件缺陷和故障问题在某些情况下会造成相当严重的损失和灾难，花费大量的资源在测试上，目的是为了提高软件质量，尽可能地减少软件缺陷造成的损失。 9.1.1 软件测试的必要性 3. 分析问题 让我们先来了解几个“著名”的计算机工程事故吧，借此说明软件缺陷和故障问题有时会造成相当严重的损失和灾难。 详见书P181~182。 9.1.2 软件测试目的 这只是表面现象，暴露问题、“破坏”程序并不是软件测试的最终目的，软件测试的目的是尽早发现软件缺陷，并确保其得以修复。换而言之，软件测试的最终目的是提高软件质量。所以，软件测试表面看起来是“破坏”，其实质却是为了“建设”质量更高的软件产品。用一句不太恰当的话总结就是，破而后立。 9.1.3 软件缺陷定义 (2) 我们习惯上把所有的软件问题都统称为缺陷（bug）。要定义软件缺陷，我们必须先了解另一个概念——产品需求规格说明书（又称需求说明书）：是软件开发小组的协定，它对开发的产品进行定义，包括产品有何细节、如何操作、功能如何、有何限制等。 9.1.3 软件缺陷定义 (3) 软件缺陷的正式定义如下，只要符合下列5个规则中的任何一条都是软件缺陷： 软件未达到产品说明书表明的功能； 软件出现了产品说明书指明不会出现的错误； 软件功能超出了产品说明书指明的范围； 软件未达到产品说明书虽未指出但应达到的目标； 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 9.1.3 软件缺陷定义 (1) 按要求输入了两个数字1和2，并且按下了“+”键，要求进行加法数学运算，但是，最终计算器并没有在显示屏上显示结果，又或者是计算器在显示屏上显示的是错误的结果，比如显示结果是4，而不是正确结果3。那么，根据第1条规则，这就是一个软件缺陷。 (2) 对计算器的键盘随意敲击，发现计算器“死机”了，对任何操作都无响应，那么，根据第2条规则，这就是一个软件缺陷。 9.1.3 软件缺陷定义 (3) 计算机除了能够进行加、减、乘、除的数学运算，还能够进行sin、cos等科学运算，虽然，运算处理的结果是正确的，但是，根据第3条规则，这就是一个软件缺陷。因为，很可能这个计算器就是为小学的学生开发的，而加入这样的科学运算会造成小学生学习混乱。 (4) 计算器在电池电力不足的情况下，会丢失运算处理后显示的结果，那么，根据第4条规则，这就是一个软件缺陷。 (5) 计算器的按键太小了、按键间距太密了、按键上的数字和运算符号显示不清晰，那么，根据第5条规则，这些都算是一个软件缺陷。 9.1.4 测试用例 3. 分析问题 测试用例对整个软件测试过程非常重要，原因有以下几方面： 测试用例构成了设计和制定测试过程的基础； 测试的“深度”与测试用例的数量成比例； 判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和执行的测试用例的数量为依据的，类似下面这样的说明：“95%的关键测试用例已得以执行和验证”，远比“我们已完成95%的测试”更有意义； 测试工作量与测试用例的数量成比例，根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。 9.1.5 软件测试的原则 1. 问题引入 为了达到软件测试的目标，在软件测试过程中针对测试计划、测试用例设计以及测试管理必须遵循哪些基本原则？ 9.1.5 软件测试的原则 在实际测试中，完全测试是不可行的，即使最简单的程序也不行，主要有以下4个原因： 输入量太大； 输出结果太多； 路径组合太多； 软件需求规格说明书很可能也没有客观的标准，从不同的角度看，软件缺陷的标准不同。 9.1.5 软件测试的原则 (2) 软件测试是有风险的行为 如果放弃了完全测试，选择了不测试所有的情况，那么，我们就选择了风险。比如在计算器的例子中，测试员已经对加法运算进行了有限的测试，但是，测试员在这有限的测试里，并没有测试输入1024+1024的情况，那么，用户在用到这组数据进行相加时，就是存在风险的，软件可能会出错。 图9-1说明了测试量与遗漏的软件缺陷 9.1.5 软件测试的原则 9.1.5 软件测试的原则 (3) 测试无法显示潜在的软件缺陷 软件测试员的工作就像防疫员一样，如果在对马匹进行检疫时发现了寄生虫，那么，检疫员