概念:测试级别
本指南将测试活动分为开发人员测试、独立测试、单元测试、集成测试、系统测试和验收测试。
关系
主要描述

测试在不同阶段或级别的工作中被应用于不同类型的目标。通常由那些在设计和执行测试方面最有技能的角色,在技术最适合每个级别的测试的位置上,来区分这些级别。确保在这些不同的工作间保持重点的平衡是很重要的。

开发人员测试

开发人员测试表示最适合开发人员团队承担的测试设计和实施的某些方面。这与“独立测试”是对立的。在大多数情况下,最初在设计和实施测试的开发人员测试团队中发生测试执行,但是让开发人员按这样的方法创建他们的测试,使它们可供独立测试团队执行,这是一种很好的实践。

传统上认为开发人员测试主要与单元测试相关。虽然某些开发人员也执行可变级别的集成测试,但是这在很大程度上取决于文化和其他环境问题。我们建议:开发人员测试应该比单独测试独立单元有更大的覆盖面。

独立测试

独立测试表示最适合独立于开发人员团队之外的某个人员执行的测试设计和实施。您可考虑这个特点是一个超集,它包含“独立验证和确认”。在大多数情况下,最初在设计和实施测试的独立测试团队中发生测试执行,但是独立的开发人员应创建他们的测试,使它们可供开发人员测试团队执行。关于独立测试在开发人员测试中的不同目标,Boris Beizer 给出了以下说明:

“独立测试的目的在于提供一个不同观点,进而提供不同的测试;而且在与开发人员可能遇到的环境相比更为丰富 [...] 的环境中执行这些测试。”[BEI95]

独立项目干系人测试

对独立测试的另一看法是:它代表了基于不同项目干系人的需求和关注的测试。因此,它被称为“项目干系人测试”。这是一个重要的特点 - 它有助于涵盖比传统上考虑的范围更为广泛的项目干系人关注,除了客户和用户之外,还将技术支持人员、技术培训人员和销售人员等项目干系人纳入到略为普通的“客户”范围中。

总而言之,在 RUP 中,XP客户测试概念与独立测试的分类相关。

单元测试

单元测试着重于验证软件最小的可测试元素。通常,单元测试被应用于在实施模型中代表的组件,以验证控制流和数据流是否被覆盖并且它们在正常运行。实施者在开发单元时执行单元测试。在实施规程中描述单元测试的详细信息。

集成测试

执行集成测试来确保:当实施模型中的组件结合以执行用例时,这些组件处于正常运作状态。测试目标是实施模型中的一个包或一组包。通常,被结合的包来自不同的开发组织。集成测试将揭示包接口规范中的不完整或错误。

在某些情况下,开发人员做出的假定是:其他团队(例如独立测试人员)将执行集成测试。这种情况将为软件项目带来风险,最终为软件质量带来风险,这是因为:

  • 集成区域是软件故障的共同点。
  • 独立测试人员通常使用黑匣技术执行集成测试,且集成测试一般涉及较大的软件组件。

更好的方法是:让开发人员和独立测试人员共同进行集成测试,但要使每个团队的测试工作策略不至于有太大的重叠。重叠的确切本性根据单个项目的需求而定。我们建议您发展一种环境,在该环境下,开发人员和独立系统测试人员可共享单一的质量理念。关于其他信息,请参阅概念:开发人员测试

系统测试

传统情况下,在软件作为整体运行时执行系统测试。迭代的生命周期允许更早地执行系统测试(一旦实施了组成合理的用例行为子集,就执行系统测试)。通常,测试目标是系统的端到端的功能元素。

验收测试

用户验收测试是部署软件前的最后一个测试行动。验收测试的目的在于,验证软件是否准备就绪,以及是否可以让用户将其用于执行软件的既定功能和任务。关于其他信息,请参阅 概念:验收测试

验收测试存在其他观念,这些观念的一般特点是从一个组或团队到另一个组或团队的传递。例如,执行工作版本验收测试以接受某个新的软件工作版本从开发到独立测试的移交。

关于测试级别顺序和时间安排的注释

传统情况下,认为单元测试是在作为测试第一阶段的迭代的早期实施的:在执行后续阶段之前所有的单元都需要通过测试。但是,在迭代的开发流程中,该方法作为一般规则是不合适的。更好的方法是:确定最有可能找到错误的单元测试、集成测试和系统测试,然后基于最大风险和支持环境的组合,实施和执行这些测试。