如果团队结合使用系统化方法和基础架构增强功能，可以实现更高的工作效率。这样可以及时提供有关代码行为的反馈。良好的测试策略具有以下特点：
本页将帮助您确定要实现哪些类型的测试、在哪里运行这些测试以及运行频率。
*保真度是指测试运行时环境与生产环境的相似程度。
大多数应用都应包含许多小型测试，而大型测试相对较少。每类测试的分配应该形成一个金字塔，数量较多的测试构成底部，数量较少的测试构成顶部。
良好的测试策略可以最大限度地提高开发者的工作效率，同时最大限度地减少发现错误的成本。
下面是一个可能效率不高的策略示例。在这里，按大小划分的测试次数没有整理到一个金字塔中。大型端到端测试过多，而组件界面测试过少：
这意味着，在合并之前运行的测试太少。如果存在bug，测试可能不会在运行每夜或每周端到端测试之前发现。
请务必考虑这对发现和修复bug的成本的影响，以及为何应将测试工作重点放在更小且更频繁的测试上：
传统上，测试金字塔分为3类：
不过，这些概念没有确切的定义，因此团队可能希望以不同的方式定义其类别，例如使用5层：
范围
网络访问
执行
build类型
生命周期
单位
依赖项最少的单个方法或类。
否
本地
可调试
合并前
组件
模块级或组件级
合并多个类
功能
功能级别
与其他团队拥有的组件集成
模拟
申请
应用级别
与其他团队拥有的功能和/或服务集成
模拟的预演版服务器正式版服务器
模拟器设备
合并前合并后
候选版本
生产服务器
缩减后的发布build
合并后发布前
一般来讲，您应该考虑能够为团队提供适当反馈的金字塔最低层级。
被测对象
测试内容说明
测试类别
测试类型示例
表单验证器逻辑
一个类，用于根据正则表达式验证电子邮件地址，并检查是否已输入密码字段。它没有任何依赖项。
单元测试
带有仅在表单通过验证后启用的按钮的表单
组件测试
遵循用户体验规范的表单
与身份验证管理器集成
向身份验证管理器发送凭据并接收可能包含不同错误的响应的界面。
功能测试
应用测试
候选版
请注意，测试类别并不决定测试类型，并且并非所有功能都必须在每个类别中进行测试。
手动测试也可以成为测试策略的一部分。通常，QA团队会执行候选版本测试，但他们也可以在其他阶段参与。例如，在不使用脚本的情况下，对功能进行探索性测试以查找bug。
测试策略必须由基础架构和工具支持，以帮助开发者持续运行测试并强制执行规则，确保所有测试都能通过。
您可以按范围对测试进行分类，以定义何时何地运行哪些测试。例如，以下5层模型：