测试级别是一组共同组织和管理的测试活动。每个测试级别都是测试过程的实例，由1.4节所述的活动组成，在特定软件开发级别上开展，从单个单元或组件到完整的系统，或在特定情况下的综合系统。测试级别与软件开发生命周期内的其他活动有关。本大纲涉及的测试级别有：
• 组件测试
• 集成测试
• 系统测试
• 验收测试
测试级别的特征包括以下属性：
• 具体的目标
• 测试依据，作为参考以提取测试用例
• 测试对象（即被测试的对象）
• 典型缺陷和失效
• 特定方法和职责
2.2.1 组件测试
组件测试目标
组件测试（也称为单元或模块测试）关注在独立可测的组件。组件测试的目标包括：
• 减少风险
• 验证组件的功能和非功能行为是否符合设计和规定
• 建立对组件质量的信心
• 发现组件的缺陷
• 防止缺陷遗漏到更高的测试级别
有时候，特别是在正在代码变更的增量和迭代开发模型（如敏捷）中，组件的自动化回归测试在建立对变更没有破坏现有组件的信心方面发挥了关键作用。
组件测试通常是独立于系统其他部分进行的，这取决于软件开发生命周期模型和系统，这可能需要模拟对象、服务虚拟化、工具、桩和驱动。组件测试可以覆盖功能（例如计算的正确性）、非功能属性（例如搜索内存泄漏）和结构化的特性（例如决策测试）。
测试依据
组件测试的测试依据包括：
• 详细设计
• 代码
• 数据模型
• 组件规格说明
测试对象
组件测试的典型测试对象包括：
• 组件、单元或模块
• 代码和数据结构
• 类
• 数据模块
典型缺陷和失效
组件测试发现的典型缺陷和失效包括：
• 不正确的功能（例如：与设计规格说明中的描述不同）
• 数据流问题
• 不正确的代码和逻辑
通常情况下，发现的缺陷可以立即得到修复，不需要正式的缺陷管理。但是在报告缺陷时，开发人员可以为根本原因分析和过程改进提供重要的信息。
具体方法和职责
组件测试通常由编写代码的开发人员执行，但测试至少需要深入到被测代码中。开发人员可以将组件开发与发现和修复缺陷交替进行。开发人员通常会在编写了组件代码之后编写和执行测试。然而，特别是在敏捷开发中，编写自动化组件测试用例可能先于编写应用程序代码。
例如：考虑测试驱动开发（TDD）。测试驱动开发是高度迭代的，基于开发自动化测试用例，构建和集成小段代码，然后执行组件测试，再纠正任何问题并重构代码的循环。该过程一直持续到组件完全构建完成并且所有组件测试都通过为止。测试驱动开发是一个测试优先方法的例子。虽然测试驱动开发起源于极限编程（XP），但它已经推广到了其他形式的敏捷以及顺序生命周期（见ISTQB -AT基础级敏捷测试扩展教学大纲）。
2.2.2 集成测试
集成测试目标
集成测试关注于组件或系统之间的交互。集成测试的目标包括：
• 减少风险
• 验证接口功能和非功能行为是否符合设计和规定
• 建立对接口质量的信心
• 发现缺陷（可能存在于接口本身，也可能存在于组件或系统内部）
• 防止缺陷遗漏到更高的测试级别
类似于组件测试，有时候自动化集成回归测试可以提供信心，即变更并没有破坏已有的接口、组件或系统。
本大纲中描述的集成测试有两个不同的层次，可以在不同规模的测试对象上进行，具体如下：
• 组件集成测试侧重于组件之间的交互和接口。组件集成测试是在组件测试之后进行的，通常是自动化的。在迭代和增量开发中，组件集成测试通常是持续集成过程的一部分。
• 系统集成测试侧重于系统、软件包和微服务之间的交互和接口。系统集成测试还可以涵盖与外部组织提供的接口（例如网络服务）之间的交互。在这种情况下，开发组织无法控制外部接口，从而给测试带来各种挑战（例如：确保外部组织代码中的会导致测试被阻塞的缺陷得到解决，安排测试环境等）。系统集成测试可以在系统测试之后进行，也可以与正在进行的系统测试活动并行进行（不管是顺序开发还是迭代和增量开发）。
测试依据
集成测试的测试依据包括：
• 软件和系统设计
• 序列图
• 接口和通讯协议规格说明
• 用例
• 组件或系统级别的架构
• 工作流
• 外部接口定义
测试对象
集成测试的典型测试对象包括：
• 子系统
• 数据库
• 基础设施
• API
• 微服务
典型缺陷和失效
组件集成测试的典型缺陷和失效包括：
• 数据不正确、数据缺失或数据编码不正确
• 接口调用的顺序或时间安排不正确
• 接口不匹配
• 各组件之间通信失效
• 组件之间的未处理或处理不当的通信失效
• 组件之间传递的数据存在含义、单位或边界的错误假设
系统集成测试的典型缺陷和失效包括：
• 系统之间信息结构不一致
• 数据不正确、数据缺失或数据编码不正确
• 接口不匹配
• 系统之间通信失效
• 系统之间的未处理或处理不当的通信失效
• 系统之间传递的数据存在含义、单位或边界的错误假设
• 没有遵守强制性安全条例
具体方法和职责
组件集成测试和系统集成测试应该集中在集成本身。例如：集成模块A与模块B，测试应侧重于模块之间的通信，而不是单个模块的功能，因为它们应该在组件测试过程中已经覆盖。如果集成系统X与系统Y，测试应侧重于系统之间的通信，而不是单个系统的功能，因为它们应该在系统测试中已经覆盖。功能测试、非功能测试和结构测试都适用。
组件集成测试通常是开发人员的责任。系统集成测试一般由测试人员负责。理想的情况是，执行系统集成测试的测试人员应该了解系统架构，并且可以对集成规划施加影响。
如果在组件或系统构建之前就计划了集成测试和集成策略，那么组件或系统就可以按照最有效测试所需的顺序构建。系统集成策略可以基于系统架构（例如：自上而下和自下而上）、功能任务、事务处理顺序、系统或组件的其他方面。为了简化缺陷隔离和尽早检测缺陷，集成通常应该是增量式的（即一次增加少量的组件或系统），而不是“大爆炸”式的（即将所有组件或系统一次性集成）。对最复杂的接口进行风险分析有助于更有针对性的集成测试。
集成范围越大，就越难以将缺陷隔离到特定的组件或系统中，从而导致风险和失效排除时间的增加。这是软件按每个组件逐步进行集成(即功能集成)成为普遍做法的一个原因。这种持续集成通常包括自动化回归测试，理想情况是在多个测试级别进行。
2.2.3 系统测试
系统测试目标
系统测试的重点是整个系统或产品的行为和能力，经常需要考虑系统可以执行的端到端任务，以及执行这些任务时所具备的非功能行为。系统测试的目标包括：
• 减少风险
• 验证系统的功能和非功能行为是否符合设计和规定
• 验证系统是否完整并按预期工作
• 建立对整个系统质量的信心
• 发现缺陷
• 防止缺陷遗漏到更高的测试级别或生产环境
对于特定系统，验证数据质量可能作为一个目标。类似于组件测试和集成测试，有时候自动化系统回归测试可以提供信心，即变更没有破坏现有的特性或端到端的能力。系统测试产生的信息通常有助于利益相关者作出发布决定。系统测试也可能是为了符合法律或法规的要求或标准。
理想的测试环境应与最终目标或生产环境相对应。
测试依据
系统测试的测试依据包括：
• 系统和软件需求规格说明（功能和非功能）
• 风险分析报告
• 用例
• 用户故事
• 系统行为模型
• 状态图
• 系统和用户手册
测试对象
系统测试的典型测试对象包括
• 应用
• 硬件/软件系统
• 操作系统
• 被测系统
• 系统配置和配置数据
典型缺陷和失效
系统测试发现的典型缺陷和失败包括：
• 计算错误
• 不正确或非预期的系统功能或非功能行为
• 系统内不正确的控制和/或数据流
• 未能正确和全面地执行端到端的功能任务
• 系统未能在生产环境中正常工作
• 系统无法按照系统和用户手册中描述那样工作
具体方法和职责
系统测试应侧重于系统作为一个整体的端到端行为，包括功能和非功能。系统测试应使用最合适的技术（见第4章）进行系统测试。例如：可以创建一个决策表来验证功能行为是否如业务规则中描述的那样。
系统测试通常由独立测试人员开展。规格说明中的缺陷（例如；缺少用户故事、错误的业务需求等）可能导致对预期的系统行为缺乏了解或产生分歧。此时会造成假阳性和假阴性结果，浪费时间和降低缺陷检测有效性。测试人员及早参与用户故事的完善或静态测试活动（例如：评审），有助于减少此类问题的发生。
2.2.4 验收测试
验收测试目标
类似系统测试，验收测试通常侧重于整个系统或产品的行为和能力。验收测试的目标包括：
• 建立对整个系统质量的信心
• 确认系统是否完整并将按预期工作
• 验证系统的功能和非功能行为符合规定
验收测试可提供信息，以评估系统是否可以部署和交给用户（最终用户）使用。验收测试中可以发现缺陷，但发现缺陷往往不是其目标的，在验收测试中发现大量缺陷在某些情况下会被认为是一个重大的项目风险。验收测试也可能是为了符合法律或法规的要求或标准。
常见的验收测试包括：
• 用户验收测试
• 操作验收测试
• 合同和法规验收测试
• Alpha测试和Beta测试
以下将分别介绍。
用户验收测试（UAT）
用户对系统的验收测试，通常侧重于验证系统是否适合目标用户在真实或模拟的运行环境中使用。其主要目的是建立信心，使用户能够以最低的难度、成本和风险使用该系统来满足他们的需要、满足需求和执行业务流程。
操作验收测试（OAT）
操作人员或系统管理人员对系统的验收测试通常在（模拟）生产环境中进行。测试的重点是操作方面，可包括：
• 备份和恢复测试
• 安装、卸载和升级
• 灾后恢复
• 用户管理
• 维护任务
• 数据负荷和迁移任务
• 检查安全漏洞
• 性能测试
操作验收测试的主要目的是建立信心，使操作人员或系统管理员能够在操作环境中，即使在特殊或困难的条件下，也能为用户保持系统正常工作。
合同和法规验收测试
合同验收测试是根据合同验收准则对生成的定制软件进行的。当双方对合同协商一致时定义验收准则。合同验收测试通常由用户或独立测试人员进行。
法规验收测试是根据必须遵守的法规，例如政府条例、法律条例或安全条例而开展的。法规验收测试通常由用户或独立测试人员进行，有时候测试结果需要监管机构证明或审计。
合同和法规验收测试的主要目标是构建信心，说明合同或法规要求已得到满足。
Alpha测试和Beta测试
Alpha和Beta测试通常被商业现货软件（COTS）的开发者所使用，他们希望在软件产品投放市场之前得到潜在或现有用户、客户和/或操作者的反馈。Alpha测试是在开发组织所在地点进行的，由潜在的或现有的客户，和/或操作人员或独立的测试团队进行，而非开发团队。Beta测试由潜在的或现有的客户，和/或操作人员在他们自己所在地点进行。Beta测试可以在Alpha测试之后进行，也可以在没有先前Alpha测试情况下进行。
Alpha测试和Beta测试的一个目标是在潜在的或现有客户和/或操作人员之间建立信心，相信他们能够在正常的日常条件下，在操作环境中以最低的难度、成本和风险使用该系统来实现其目标。另一个目标是发现与使用该系统的条件和环境有关的缺陷，特别是在开发团队难以复制这些条件和环境的情况下。
测试依据
验收测试的测试依据包括：
• 业务流程
• 用户或业务要求
• 法规、法律合同和标准
• 用例
• 系统要求
• 系统或用户文件
• 安装程序
• 风险分析报告
此外，作为获取操作验收测试的测试用例的测试依据，可参考以下一种或多种工作产品：
• 备份和恢复规程
• 灾后恢复规程
• 非功能需求
• 操作文件
• 部署和安装说明
• 业绩目标
• 数据库包
• 安全标准或法规
典型测试对象
验收测试的典型测试对象包括：
• 被测系统
• 系统配置和配置数据
• 全面集成系统的业务流程
• 恢复系统和热门站点(用于业务连续性和灾难恢复测试)
• 操作和维护过程
• 表格
• 报告
• 现有和已转换的生产数据
典型缺陷和失效
验收测试发现的典型缺陷包括：
• 系统工作流不符合业务或用户要求
• 商业规则没有得到正确实现
• 系统不符合合同或法规要求
• 非功能性失效，如安全漏洞、高负载下的性能效率不足，或在受支持的平台上不恰当的操作
具体方法和职责
验收测试通常是客户、业务用户、产品所有者或系统操作者负责，其他利益相关者也会参与其中。
验收测试常被认为是顺序开发生命周期中的最后一个测试级别，实际上也可以在其他时间开展，例如：
• COTS软件产品安装或集成时进行验收测试
• 系统测试之前对新的功能增强进行验收测试
在迭代开发中，项目团队可以在每次迭代期间和迭代结束时使用各种类型的验收测试，例如：侧重于对照其验收标准验证新特性的测试，以及那些侧重于确认新特性满足用户要求的测试。此外，可以在每次迭代的最后、每次迭代完成后或在一系列迭代后进行Alpha测试和Beta测试。用户验收测试、操作验收测试、法规验收测试和合同验收测试也可在每次迭代的最后、每次迭代完成或一系列迭代之后开展。