在大部分研发项目经理心中，进度往往会放在第一位，其次是成本，最后是质量，当然人员队伍最好也要稳定。天下武功，唯快不破：进度 > 成本 > 质量 > 人。
这个说法并不是绝对，今天我们并不是讨论他们之间的优先顺序。而是围绕效率提升，测试可以做什么？
相信大部分测试人员脑海里首先会跳出来：“自动化测试”或者“敏捷测试”，没错，自动化和敏捷都可以帮助提升研发效率，但是并不是只要做了就都有这个提升作用。
测试效率提升有以下几个不同段位：
1、提升测试效率
提升测试的效率，最有效的手段是制定测试策略。对，你没有看错，是测试策略而不是自动化！
测试策略提升测试效率的逻辑是：减少不必要的测试，重要的问题早发现早解决。
测试策略的基础是风险评估，首先从失效概率、失效影响这两个维度，区分高、中、低风险的特性。失效概率是发生错误的可能性，评分一般是依据：同类特性的历史表现，设计中需要考虑的要素多寡，需求变更的频繁程度，是否采用新方法等。失效影响是错误发生造成的影响，评分的一般是参考：错误失效对主要业务流程的影响范围，给研发团队以及客户带来的直接经济损失，修复成本，信誉影响等。这两个风险维度的评分虽然有一些参考维度，但主要是依赖经验。
风险评估完成后，根据每个测试内容的风险评分，确定测试的时间和强度（测试强度通常是用千行代码用例数来衡量）。原则上高风险的内容要尽可能早测试，低风险的内容在计划安排上灵活性可以大一些。高风险的内容要多测试，比如考虑多种测试设计方法同时使用，安排探索式测试等。测试的过程中，需要持续的分析缺陷数据、指标数据，以确定风险是降低还是升高了，如果发现风险升高，甚至已经成为会阻碍产品发布的问题，则必须进行例外报告，调整开发和测试策略。
提升测试的效率，基于需求的测试也是有效手段之一，基于需求进行测试设计的目的，是减少不必要的参数组合和虚构的应用场景的测试用例。当然，只基于需求进行测试，往往不那么让人放心，因为总会有意外的情况发生，一般还需要再基于经验、基于错误猜测，或者基于在线应用采集的应用场景进行一些补充。对于特别重要的测试内容，可能还需要基于设计进行更高强度的测试。
那么，为什么不是自动化？大多数时候，我们是将原本手工执行的功能用自动化的方式来执行，这种情况下自动化测试更多的是服务于质量，其目的是发现新特性对老特性产生的，不为人知的影响。如果新特性每次发布，都导致老特性发生意外的变化，进而导致测试不得不在每个版本都全面测试老特性，那么这种自动化就是提升测试效率的。不过，这种情况比较少见，而且，如果真的发生这种情况，一定是产品架构设计出了问题，优化架构比实现自动化测试的优先级要高。
2、提升开发效率
测试活动不再局限于测试活本身，测试帮助提升研发效率，最有效的手段是自动化和工具化，这两个手段是实现TDD和缺陷快速定位的关键措施。
TDD的作用，是用测试用例的形式表述需求或设计目标，从而确保codeing过程中，始终在做正确的事，在向主干中加入各种分支处理逻辑、或者进行各种修改时，不会破坏已经正确的功能，让开发可以放心的修改缺陷或者重构代码。在TDD实施中，测试的主要价值是提供趁手的工具，这个工具不仅要能够驱动测试用例执行，还要让开发很方便的构建测试用例及其执行所需的条件。我们有些团队在TDD实施的早期，把TDD用例编写和调试的工作也交给测试完成，这种方式无法让开发及时验证自己的每一次改动，做不到及时的质量反馈，也起不到TDD宣称的那些作用，不建议采用。
缺陷快速定位为什么要拿出来讲呢？因为，我们曾经统计过开发的工作量，在实现阶段，大概有1/3~1/2的开发工作量是耗费在缺陷的确认、重现、定位、修改、验证，如果能加快这个过程，则开发效率会有大幅提升。
通过缺陷辅助定位工具，可以提高这部分工作的效率。在一个用例执行不通过的时候，工具自动采集缺陷定位所需的信息，如：系统产生的日志和其他过程与结果记录，产生变化的数据库记录，此用例执行覆盖到的代码。通过这些信息，可以在无需重现、无需跟踪执行的情况下定位大部分的问题。当然，要实现这个目的，仅仅有工具是不够的，还需要产品做一些日志上的增强，例如在函数的入口和出口记录函数的输入、输出参数。缺陷修改完成后，再用自动化用例进行验证，就能够对开发的缺陷定位产生积极影响。
很多团队中，开发会把测试提交的缺陷集中在某个时间去修改，也是为了压缩处理缺陷的时间，但是这样会导致质量风险在开发后期集中爆发，是不值得借鉴的方式。
提升代码质量，除了TDD和缺陷定位，还可以在环境准备、测试结果采集上，使用工具和自动化提升效率。
3、提升版本发布效率
测试服务于研发整体而不是某个环节的效率提升。
测试帮助提升版本发布的效率，主要方法是自动化和CI（持续集成）、持续交付。
自动化是CI的基础，而自动化及CI是持续交付的基础。
CI对自动化的要求，除了用测试用例进行自动化的产品验证，还包括自动化的编译、打包、部署、环境检查等。
持续交付在一般CI的基础上，通常还需要做到应用场景的自动化验证（通常是基于UI的自动化测试，用于冒烟测试）、常规性能的自动化验证，不同环境的统一部署，以及按不同的策略发布。一般的组织中，持续交付主要还是用于向专门的测试团队交付产品版本。某些互联网公司能够做到将持续交付用于生产环境，这种场景下，除了上述能力，还需要在产品上线初期进行自动化的异常侦测，看护系统和业务的正常运行，此外，还应该有比较可靠的系统和数据回滚机制。在生产环境中，要使这个过程安全的走下来，验证用例最好能比较完整的覆盖基本功能和新增需求，也需要根据历史问题不断完善看护、侦测规则。
发布时对基本功能的覆盖，除了传统的人工编写自动化用例的方式，利用在线运行抓取实际场景是更能让测试适配产品更新节奏的方式。
理想情况下，CI可以做到每天（也可能是每周或者其他的周期）都能够有一个质量过关的版本为上线做好了准备。这是比较理想的情况，我没有见到过真正这样实施的团队，在我们团队中，CI更多的还是在开发过程中，检查程序员的代码质量，起到的是质量门槛的作用。
持续发布是研发整体的工程能力提升，需要的不仅是研发团队的工具开发能力，还需要在过程管理、配置管理，甚至产品架构、质量文化等方面进行匹配。持续发布的实施，有专门的书籍做了详细介绍。