1. 软件测试基础- 1.2为什么需要测试？

关键词

覆盖（coverage）、调试（debugging）、缺陷（defect）、错误（error）、失效（failure）、质量 （quality）、质量保证（qualityassurance）、根本原因（root cause）、测试分析（test analysis）、测试依据（test basis）、测试用例（test case）、测试结束（test completion）、测 试条件（test condition）、测试控制（test control）、测试数据（test data）、测试设计（test

design）、测试执行（test execution）、测试执行进度表（test execution schedule）、测试实施 （test implementation）、测试监督（test monitoring）、测试对象（test object）、测试目标 （test objective）、测试结果参照物（test oracle）、测试计划（test planning）、测试规程 （test procedure）、测试套件（test suite）、测试（testing）、测试件（testware）、可追traceability）、确认（validation）、验证（verification）

---

软件测试基础的学习目标

1.1 什么是测试？

FL-1.1.1 (K1) 识别典型的测试目标

FL-1.1.2 (K2) 区分测试与调试的不同

1.2 为什么需要测试？

FL-1.2.1 (K2) 给出为什么需要测试的例子

FL-1.2.2 (K2) 描述测试与质量保证之间的关系，举例说明测试是如何提高软件质量的

FL-1.2.3 (K2) 辨别错误、缺陷和失效

FL-1.2.4 (K2) 辨别引起缺陷的根本原因及其影响

1.3 七项测试的基本原则

FL-1.3.1 (K2) 解释测试的七项基本原则

1.4 测试过程

FL-1.4.1 (K2) 解释测试过程中的环境影响

FL-1.4.2 (K2) 描述测试过程中的测试活动和各自的任务

FL-1.4.3 (K2) 区分用于支持测试过程的工作产品

FL-1.4.4 (K2) 解释在测试依据和测试工作产品之间保持可追溯性的价值

1.5 测试的心理学

FL-1.5.1 (K1) 识别影响测试成功与否的心理因素

FL-1.5.2 (K2) 解释测试活动所需的思维方式和开发活动所需的思维方式之间的差异

---

1.2.为什么需要测试？

对组件和系统及其相关文档进行严格的测试，有助于降低软件运行过程中出现失效的风险。当发现缺陷并随后加以修复时，这有助于提高组件或系统的质量。此外，还可能需要进行软件测试，以满足合同或法律法规或行业具体标准的要求。

1.2.1.测试对成功的贡献

纵观计算机的历史，软件和系统的交付使用是很常见的，但是由于缺陷的存在，随后就会导致软件和系统失效，或者由于没有满足干系人的需求。然而，使用适当的测试技术可以减少这种有问题交付的频率，只要这些技术是在适当的测试机能水平、适当的测试级别和软件开发生命周期的适当点上得到应用。例如：

• 让测试员参与需求评审或用户故事细化，可以发现这些工作产品中的缺陷。识别和修复需求缺陷可以减少被开发功能的不正确或不可测试的风险。
• 在系统设计过程中，让测试员与系统设计人员密切合作，可以提高各方对设计和如何测试的理解。理解的增加可以降低基本设计缺陷的风险，并使测试能够尽早介入。
• 在开发代码过程中，让测试员与开发人员密切合作，可以提高各方对代码以及如何测试的理解。理解的增加可以降低代码和测试中出现缺陷的风险。
• 让测试员在发布之前对软件进行验证和确认，可以发现之前遗漏的、失效的缺陷，并帮助修复导致失效的缺陷（即调试）。这样就增加了软件满足干系人需求的可能性。

除了这些·例子之外，达到已定义测试目标有助于整个软件开发和维护的成功。

1.2.2.质量保证和测试

人们经常使用“质量保证”（或QA）来代指测试，虽然它们是有关联的，但是质量保证和测试是不一样的。可以用更大的概念把它们联系在一起，质量管理。质量管理包括所有指导和控制组织质量的活动。

除其他活动外，质量管理还包括质量保证和质量控制。质量保证的关注点在于遵循正确的过程，为产品能够达到合适的质量级别提供信心。当过程正确开展时，这些过程所创造的工作产品通常具有更高的质量，这也有助于缺陷的预防。另外，使用根本原因分析方法来发现缺陷并消除引起缺陷的原因，以及适当应用回顾性会议的结论来改进过程，这对于有效的质量保证也很重要。

质量控制涉及各种支持达到适当质量级别的活动，包括测试活动。测试活动是整个软件开发或维护过程的一部分。因为质量保证涉及到整个过程的正确执行，质量保证会支持正确的测试活动。如前所述，测试在以各种方式帮助实现质量的提高。

1.2.3.错误、缺陷和失效

所有人都会犯错（mistake），这样就会导致在软件代码或者其他相关工作产品中引入缺陷（fault或bug）。在一个工作产品中引入的缺陷就可能会导致其他相关产品都引入缺陷。例如，需求引发的错误就可能导致需求缺陷，需求缺陷就会导致编程错误，这样代码中就存在缺陷。

如果执行了存在缺陷的代码，就可能导致失效，但不一定在所有情况下都是这样。例如，有些缺陷需求要非常特殊的输入或先决条件才能触发失效，这种失效可能很少发生，也可能永远不会发生。

发生错误的原因有很多种，例如：

• 时间压力
• 人本身容易犯错
• 缺乏经验或技能不足的项目参与者
• 项目参与者之间沟通有误，包括需求和设计之间的沟通误解
• 代码、设计、架构的复杂度，待解决的潜在问题，和/或使用的技术。
• 对系统内和系统间接口的误解，特别是当系统内和系统间的交互数量比较多的时候
• 新的不熟悉的技术

除了代码中的缺陷导致的失效之外，环境条件也可能导致失效。例如：辐射、电磁场和污染等都有可能引起固件中的失效，或者由于硬件环境的改变而影响软件的执行。

但并非所有意外的测试结果都属于失效。由于测试执行方式的错误，或者由于测试数据、测试环境或其他测试固件中的缺陷，又或者由于其他的原因，可能会出现假阳性结果（误报）。相反的情况也有可能发生，即相似的错误或缺陷会导致假阴性结果（缺陷的漏报）。假阴性结果指的是没有发现测试应该要发现的缺陷；假阳性结果记录为缺陷，但实际上并不是缺陷。

1.2.4.缺陷、根本原因和影响

缺陷的根本原因是导致缺陷产生的最早的行为或条件。可以分析缺陷并找出其根本原因，以减少类似的缺陷以后再发生。通过将关注点放在最重要的根本原因，根本原因的分析可以促进过程的改进，从而防止将来引入大量的缺陷。

例如，假设由于一行不正确的代码，支付了错误的利息，导致了客户投诉。由于产品所有者对如何计算利息有误解，所以为模糊的用户故事编写了有缺陷的代码。如果在利息计算中存在很大比例的缺陷，并且引发这些缺陷的根本原因来源于类似的误解，那么需要为产品所有者进行利息计算相关主题的培训，以便在未来减少这类缺陷。

在这个例子中，客户投诉的是影响。支付错误的利息属于失效。代码中错误计算属于缺陷，它是由模糊的用户故事中的原始缺陷造成的。原始缺陷产生的根本原因是产品所有者知识的缺乏，导致产品所有者在编写用户故事时犯了错误。