软件测试过程

测试概念、策略、技术和措施需要集成到一个定义和控制的过程中。测试过程支持测试活动，并为测试人员和测试团队提供指导，从测试计划到测试输出评估，以这样一种方式提供保证，即测试目标将以经济有效的方式得到满足。

5.1实际考虑

5.1.1态度/无自我的编程

成功测试的一个重要因素是对测试和质量保证活动的协作态度。在软件开发和维护过程中，管理人员在培养对故障发现和纠正的普遍好感方面起着关键作用;例如，通过克服程序员之间个人代码所有权的心态，以及通过促进协作环境，让团队对代码中的异常负责。

5.1.2测试指南

测试阶段可以由各种目标来指导——例如，基于风险的测试使用产品风险来确定优先级并测试策略，基于场景的测试基于指定的软件场景定义测试用例。

5.1.3测试过程管理

在不同层面(参见主题2，测试层面)进行的测试活动必须与人员、工具、策略和度量一起组织成一个定义良好的过程，它是生命周期的一个完整部分。

5.1.4测试文档和工作产品

文档是测试过程形式化的一个组成部分。测试文档可能包括测试计划、测试设计规范、测试过程规范、测试用例规范、测试日志和测试事件报告。被测试的软件被记录为测试项目。测试文档应该生成并不断更新到与软件工程中其他类型文档相同的质量水平。测试文档也应该在软件配置管理的控制之下(参见软件配置管理知识领域)。此外，测试文档包括可以为用户手册和用户培训提供材料的工作产品。

5.1.5测试驱动开发

测试驱动开发(TDD)起源于XP(极限编程)的核心实践之一，包括在编写要测试的代码之前编写单元测试(参见软件工程模型和方法知识领域中的敏捷方法)。通过这种方式，TDD将开发测试用例作为软件需求规格说明文档的替代，而不是作为软件是否正确实现了需求的独立检查。TDD不是一种测试策略，而是一种需要软件开发人员定义和维护单元测试的实践;因此，它还可以对制定用户需求和软件需求规格说明产生积极的影响。

5.1.6内部测试团队与独立测试团队

将测试过程形式化还可能涉及到将测试团队的组织形式化。测试团队可以由内部成员(也就是说，在项目团队中，参与或不参与软件构建)、外部成员(希望带来一个公正的、独立的视角)，或者由内部和外部成员组成。对成本、进度、相关组织的成熟度级别和应用程序的临界性的考虑可以指导决策。

5.1.7成本/工作量评估和测试过程度量

管理人员使用一些与花费在测试上的资源以及各个测试阶段的相对发现缺陷的有效性相关的措施来控制和改进测试过程。这些测试度量可能包括指定的测试用例的数量、执行的测试用例的数量、通过的测试用例的数量、失效的测试用例的数量等等。

测试阶段报告的评估可以与根源分析相结合，以评估测试过程在尽早发现故障方面的有效性。这种评价可以与风险分析相联系。此外，值得花费在测试上的资源应该与应用程序的使用/临界程度相称:不同的技术有不同的成本，并产生对产品可靠性不同程度的信心。

5.1.8测试的终止

必须决定多少测试是足够的，以及什么时候可以终止测试阶段。彻彻性度量，例如已实现的代码覆盖率或功能覆盖率，以及对故障密度或操作可靠性的估计，提供了有用的支持，但它们本身是不够的。该决定还涉及到对可能的剩余失效所引起的成本和风险的考虑，而不是继续测试所引起的成本(参见1.2节，关键问题中的测试选择标准/测试充分性标准)。

5.1.9测试复用和测试模式

要以有组织且经济有效的方式进行测试或维护，用于测试软件各部分的方法应系统地重复使用。测试材料的存储库应该处于软件配置管理的控制之下，以便对软件需求或设计的变更可以反映在对所执行的测试的变更中。

在特定的环境下测试某些应用程序类型所采用的测试解决方案，以及所做决定背后的动机，形成了一个测试模式，它本身可以被记录下来，以便稍后在类似的项目中复用。