围绕效率提升，测试可以做什么？

Posted 2020-10-21

大部分的研发经理心中，进度是第一位的，其次是成本，最后是质量，当然人员队伍最好稳定。天下武功，唯快不破：进度 > 成本 > 质量 > 人。

围绕效率提升，测试可以做什么？你脑海里跳出来的，应该是“自动化”或者“敏捷”吧，没错，自动化和敏捷都可以帮助提升研发效率，但是并不是只要做了都有这个作用。

下面来看看测试支持效率提升的不同段位。

一段：提升测试效率。

提升测试的效率，最有效的手段是制定测试策略。对，你没有看错，是测试策略而不是自动化！

测试策略提升测试效率的逻辑是：减少不必要的测试，重要的问题早发现早解决。

测试策略的基础是风险评估，首先从失效概率、失效影响这两个维度，区分高、中、低风险的特性，失效概率是发生错误的可能性，评分一般是依据：同类特性的历史表现，设计中需要考虑的要素多寡，需求变更的频繁程度，是否采用新方法等。失效影响是错误发生造成的影响，评分的一般是参考：错误失效对主要业务流程的影响范围，给研发团队以及客户带来的直接经济损失，修复成本，信誉影响等。这两个风险维度的评分虽然有一些参考维度，但主要是依赖经验。

风险评估完成后，根据每个测试内容的风险评分，确定测试的时间和强度（测试强度通常是用千行代码用例数来衡量）。原则上高风险的内容要尽可能早测试，低风险的内容在计划安排上灵活性可以大一些。高风险的内容要多测试，比如考虑多种测试设计方法同时使用，安排探索式测试等。测试的过程中，需要持续的分析缺陷数据、指标数据，以确定风险是降低还是升高了，如果发现风险升高，甚至已经成为会阻碍产品发布的问题，则必须进行例外报告，调整开发和测试策略。

提升测试的效率，基于需求的测试也是有效手段之一，基于需求进行测试设计的目的，是减少不必要的参数组合和虚构的应用场景的测试用例。当然，只基于需求进行测试，往往不那么让人放心，因为总会有意外的情况发生，一般还需要再基于经验、基于错误猜测，或者基于在线应用采集的应用场景进行一些补充。对于特别重要的测试内容，可能还需要基于设计进行更高强度的测试。

那么，为什么不是自动化？大多数时候，我们是将原本手工执行的功能和DFX测试自动化执行，这种情况下自动化测试更多的是服务于质量，其目的是发现新特性对老特性产生的，不为人知的影响。如果新特性每次发布，都导致老特性发生意外的变化，进而导致测试不得不在每个版本都全面测试老特性，那么这种自动化就是提升测试效率的。不过，这种情况比较少见，而且，如果真的发生这种情况，一定是产品架构设计出了问题，优化架构比实现自动化测试的优先级要高。

二段：提升开发效率，测试不再局限于测试活动本身。

测试帮助提升研发效率，最有效的手段是自动化和工具化，这两个手段是实现TDD和缺陷快速定位的关键措施。

TDD的作用，是用测试用例的形式表述需求或设计目标，从而确保codeing过程中，始终在做正确的事，在向主干中加入各种分支处理逻辑、或者进行各种修改时，不会破坏已经正确的功能，让开发可以放心的修改缺陷或者重构代码。在TDD实施中，测试的主要价值是提供趁手的工具，这个工具不仅要能够驱动测试用例执行，还要让开发很方便的构建测试用例及其执行所需的条件。我们有些团队在TDD实施的早期，把TDD用例编写和调试的工作也交给测试完成，这种方式无法让开发及时验证自己的每一次改动，做不到及时的质量反馈，也起不到TDD宣称的那些作用，不建议采用。

缺陷快速定位为什么要拿出来讲呢？因为，我们曾经统计过开发的工作量，在实现阶段，大概有1/3~1/2的开发工作量是耗费在缺陷的确认、重现、定位、修改、验证，如果能加快这个过程，则开发效率会有大幅提升。

通过缺陷辅助定位工具，可以提高这部分工作的效率。在一个用例执行不通过的时候，工具自动采集缺陷定位所需的信息，如：系统产生的日志和其他过程与结果记录，产生变化的数据库记录，此用例执行覆盖到的代码。通过这些信息，可以在无需重现、无需跟踪执行的情况下定位大部分的问题。当然，要实现这个目的，仅仅有工具是不够的，还需要产品做一些日志上的增强，例如在函数的入口和出口记录函数的输入、输出参数。缺陷修改完成后，再用自动化用例进行验证，就能够对开发的缺陷定位产生积极影响。

很多团队中，开发会把测试提交的缺陷集中在某个时间去修改，也是为了压缩处理缺陷的时间，但是这样会导致质量风险在开发后期集中爆发，是不值得借鉴的方式。

提升代码质量，除了TDD和缺陷定位，还可以在环境准备、测试结果采集上，使用工具和自动化提升效率。

三段：提升版本发布效率，测试服务于研发整体而不是某个环节的效率提升。

测试帮助提升版本发布的效率，主要方法是自动化和CI（持续集成）、持续交付。

自动化是CI的基础，而自动化及CI是持续交付的基础。

CI对自动化的要求，除了用测试用例进行自动化的产品验证，还包括自动化的编译、打包、部署、环境检查等。

持续交付在一般CI的基础上，通常还需要做到应用场景的自动化验证（通常是基于UI的自动化测试，用于冒烟测试）、常规性能的自动化验证，不同环境的统一部署，以及按不同的策略发布。一般的组织中，持续交付主要还是用于向专门的测试团队交付产品版本。某些互联网公司能够做到将持续交付用于生产环境，这种场景下，除了上述能力，还需要在产品上线初期进行自动化的异常侦测，看护系统和业务的正常运行，此外，还应该有比较可靠的系统和数据回滚机制。在生产环境中，要使这个过程安全的走下来，验证用例最好能比较完整的覆盖基本功能和新增需求，也需要根据历史问题不断完善看护、侦测规则。

发布时对基本功能的覆盖，除了传统的人工编写自动化用例的方式，利用在线运行抓取实际场景是更能让测试适配产品更新节奏的方式。

理想情况下，CI可以做到每天（也可能是每周或者其他的周期）都能够有一个质量过关的版本为上线做好了准备。这是比较理想的情况，我没有见到过真正这样实施的团队，在我们团队中，CI更多的还是在开发过程中，检查程序员的代码质量，起到的是质量门槛的作用。

持续发布是研发整体的工程能力提升，需要的不仅是研发团队的工具开发能力，还需要在过程管理、配置管理，甚至产品架构、质量文化等方面进行匹配。持续发布的实施，有专门的书籍做了详细介绍。

四段：提升特×××付效率，测试不是依赖工具和自动化，而是依赖分析设计服务于效率提升。

测试帮助提升特×××付的效率，需要做到基于需求的测试，此外，敏捷也可以提升特性的交付效率。

基于需求的测试中，测试帮助研发团队在需求实现方面少一次试错。很多团队认为自己是基于需求进行测试的，但实际上是基于“需求规格说明书”进行测试，后者依赖一份质量优良的文档（标准是，内容完整且正确，研发各个环节都可以完全依据这份文档开展工作，并最终得到正确的特性），但通常这个依赖条件不存在。

基于需求测试需要做到：

■改善需求质量。利用需求内容模型（5W1H）促进需求内容完整性的提升，利用测试对产品、业务的理解，通过静态测试发现需求中的遗漏、矛盾、错误，从而改善需求，即测试设计输入的质量。

■基于需求测试。根据需求进行单个操作、业务场景和端到端应用场景的测试。并在测试执行时，通过研发测试、邀请客户和需求工程师参与体验和演示等方式，在产品特性半成品上，利用形象的操作过程对抽象的分析进行验证和纠错。

基于需求的测试除了要会使用上述方法，也比较依赖测试工程师的经验，因为实际应用过程中，我们通常都是参照已经成熟的特性，曾经犯过的错误来进行查缺补漏。

敏捷提升交付效率的基本逻辑是实现按特性开发和交付。首先，应对这种小步快跑的方式，测试需要及时实现对少量的新增和修改内容进行测试，在最短的时间内进行质量反馈，这要求测试设计、测试执行（自动化测试），甚至发布、部署都要能够在迭代周期的时间窗内完成。其次，按特性发布可以让客户尽可能快的看到和使用特性，以便更快的进行产品应用层面的质量反馈，因此，如果团队按特性开发了，但是并不能按特×××付，那么对于交付效率的提升还是只完成了一半。

敏捷是建立在研发的质量文化、产品的架构优化、测试的自动化水平之上的研发模式的演进，如果没有这些基础，仅仅依靠模式的改变是无法既提升效率，又维持质量稳定的。

围绕效率提升，测试可以开展的工作远不止上面提到的这些，也一定还有做到更高段位的团队实践（提升产品交付效率的DevOps），期待……