测试及早介入原则

根据统计表明，在软件开发生命周期早期引入的错误占软件过程中出现所有错误(包括最终的缺陷)数量的50%～60%。 此外，IBM的份研究结果表明， 缺陷存在放大趋势，如需求阶段的一个错误可能会导致N个设计错误。越是测试后期，为修复缺陷所付出的价就会越大，因此，软件测试人员要尽早地且不断地进行软件测试，以提高软件质量，降低软件开发成本。

测试左移概念

简单的讲就是更早于传统的测试介入阶段（提测后）之前介入测试工作，不局限于软件提测后再介入测试，使得测试与开发活动结合的更加紧密，测试左移的思想可以从两个角度去考虑：

1.功能测试左移，比如测试人员在需求评审、分析阶段介入，可以理解为测试流程的左移，也可理解为测试重心的左移（在需求分析、测试设计阶段加大投入）。

2.（接口）自动化测试左移，即不再局限于功能趋于稳定再介入自动化测试，而取决于自动化测试技术应用结果的易用性、可扩展性、可维护性的发展程度。

测试左移下的开发测试流程

如图所示，我们将软件生命周期简单划分为概念阶段、设计阶段、开发阶段、验证阶段、发布阶段以及明确开发与测试在各阶段的工作内容，图中标注了测试左移、自动化左移、测试右移对应的测试阶段及测试活动。

功能测试左移

功能测试左移的主要思想，就是在研发人员进行需求评审、分析阶段，测试人员同步参与整个评审、分析过程，了解需求背景、场景的同时对需求的完善性、锲合度等方面进行评审；研发人员在功能设计、实现阶段，测试人员同步进行测试分析、用例设计、评审工作。同时加大了对测试需求分析的投入力度。其核心是对需求的深度理解：

部分测试人员对需求的初始认知已经建立在需求正确的基础之上的，因此缺少对需求的正确性判断，对需求的的背景、场景等都不了解，如果是这样那只能对已有功能进行正确性校验，无法或者不能考虑其必要性，是否真正的满足用户诉求等等。所以我们首先要了解需求，然后才能对其进行评审，才能结合功能需求产出对应的测试需求，才能结合用户数据对需求的价值进行客观的评估。一般需求分为业务需求、用户需求、功能需求。

·业务需求：业务需求描述了组织为什么要开发一个系统， 即组织希望达到的目标。业务需求通常来自项目投资人，购买产品的客户实际用户的管理者、市场营销部门或产品集划部门。使用前置和范围文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求文档。

·用户需求：用户需求描述的是用户的目标或用户要求系统必须能完成的任务。比如软件的界面是否好看、功能使用是否便捷等都属于用户需求。用户需求可以认为是对业务需求的一个具体目标。比如业务需求提出了这个系统具有语音功能，那么用户需求可能就包含了语音具备的功能，比如，可以喊刘德华的电影去搜电影等。

·功能需求：功能需求规定开发人员必须在产品中实现的软件功能，用户利用这个功能来完成任务，满足业务需求。功能需求有时也被称作行为需求功能需求是去解决业务需求、用户需求的具体的解决方案，也就是我们通常说的需求说明书。对用户需求做具体的分析、提出实施方法(需求说明书通常是由软件开发方编写比如产品经理。使得用户和软件开发方都对软件的初始规定有个共同的理解，是整个开发的基础)。同时，开发方需要对需求说明书进行评估，比如这个需求能不能做，耗费的成本是不是小于带来的收益，还有风险评估等。

自动化测试左移

自动化测试左移是在类敏捷、DevOps开发模式催化下的一种测试思想，随着持续的频繁迭代，对测试效应效率提出了更高的要求，传统的自动化测试准入原则（功能相对稳定）已经不再适应。

我们尝试在用例设计阶段产出手工用例的同时，依据功能设计（接口设计文档）产出自动化测试用例，在研发提测后进手工执行为进行自动化测试覆盖的用例，提高测试活动的敏捷性和持续性。

目前我们通过基于测试库架构、数据驱动架构、关键字架构利用Python语言构建了接口自动化测试平台，通过将接口测试要素提取为各关键字并完成设计、开发，以满足各场景下的接口测试需求，为手工测试人员进行自动化用例覆盖提供了更为高效、易用的测试策略。

当接口自动化测试变得足够简单，维护成本足够低的时候，功能需求改动引入的自动化维护成本也将变得可以接受，因此自动化测试左移得以实现，不再局限于功能相对稳定的约束条件之下。

总之无论是测试左移和测试右移其核心目的都是围绕着产品质量提供测试服务。