在探讨测试能力分层架构下的效率提升时，我们的视角往往自然聚焦于测试开发团队，这诚然重要，但转换思路，或许能开启新的视野，收获更为丰富的成效。
效率提升的双重考量在追求效率提升的过程中，两大核心问题不容忽视，它们是相互依存、缺一不可的基石：
适不适合做：这关乎项目的价值与必要性。自动化测试的实施，应当以解决具体问题为导向，而非盲目追求自动化形式。它要求我们在项目初期就明确自动化测试能为项目带来哪些实质性的改进，而非仅仅是为了技术展示或跟风。能不能够做：这则是对实施能力的考量。它涉及自动化测试的设计、开发、维护与应用等多个环节，要求团队具备相应的技术实力与资源支持，以最低的成本实现高效的自动化测试流程。结合以往经验，在只解决上述问题中的其一或者二者不解决的情况下，可能会出现以下情况：
只解决“适不适合做”的问题，可能会导致：
没有掌握完整的自动化测试技术栈，开发成本高。没有选择合适的框架或解决方案，无法从整体上降低用例的编写、维护成本，在持续投入下，投入产出比大概率为负。只解决“能不能够做”的问题，可能会导致：
传统瀑布开发模式下，迭代周期长，次数少。几个版本下来，等同测试覆盖下，自动化测试投入可能大于手动测试投入。频繁的需求变更，自动化用例维护成本高，自动化测试逐渐废弃。“适不适合做”、“能不能够做”的问题都不解决，可能会导致：
如果是这样，那这只能是 “闹着玩”，也许昙花一现、也许半途而废。因此，在我们的自动化开展过程中，引入了自动化需求澄清环节，主要研判的就是上述两个问题。这个过程，业务方作为需求提出方主要研判“适不适合做“的问题，测开方作为需求承接方主要研判“能不能够做的问题”，根据以往经验，前者问题难度更高更复杂。
因此，我们不难发现，要做到有效的提升、这两个问题是绕不过去。在解决这两个问题的前提下，我们才能够正确地明确其目标，才有了目标才能正确制定其具体实施方案。
为何而做—— 目标度量的精准定位
接下来，聊一聊目标，自动化测试度量指标，我们近几年尝试过很多种维度去度量，例如，从自动化用例数量、到覆盖率、再到ROI、效率提升率，我们发现这些度量维度不难计算，通过自动或手动统计的方式都可以统计计算出结果，但度量数据反映的情况与实际情况存在较大的差异性（效率、质量），例如 度量数据呈现出的效率提升率在变高，但实际业务测试周期似乎没有变化，等等。
那么这个问题出在哪里？—— 当我们与真相一步步靠近时，这其中每一步都是有意义的。
问题也许出在 “目标” 本身，目标即导向。那么效率提升的本质是不是“用例数量多“、”覆盖率多”、”ROI高”？
好像也并不是，差一点意思。我认为本质应该是简单的、直接的 ：
在定时测试任务的背景下，快 → 时间缩短在定量测试任务的背景下，快 → 人数减少结合上面说的，接下来在具体指标设定时，除了“定性”、不可避免的还要“定量”，“定量”一方面是为了度量其绝对值，另一方面是与其“定性”相互佐证。
定量指标-时间缩短
平均项目测试周期缩短：设定具体目标，如“在未来一个季度内，将平均项目测试周期缩短20%”。这要求记录每个项目的测试开始与结束时间，并计算平均值进行比较。关键任务响应时间：除了整体周期，还可以设定针对特定关键任务的响应时间缩短目标，如“紧急缺陷修复的平均响应时间缩短至24小时内”。定量指标-成本节约（人力投入）
累计节省额外人力投入：明确“额外人力”的定义（如加班、外包等），并设定具体目标，如“通过流程优化和自动化，本年度累计节省额外人力投入50人月”。定性指标-模式创新
自动化测试技术引入：具体描述引入的自动化测试类型（如UI自动化、API自动化）、覆盖的测试范围（如功能测试、性能测试）以及预期带来的改变，如“成功引入基于Selenium的UI自动化测试框架，覆盖80%的核心业务场景，显著提升回归测试效率”。流程改进：除了技术引入，还可以关注流程上的创新，如“实施敏捷测试流程，将测试与开发更紧密集成，实现快速反馈与迭代”。定性指标-质量提升
缺陷逃逸率降低：作为效率与质量并重的考量，设定“缺陷逃逸率降低至X%以下”的目标，反映测试有效性的提升。客户满意度提升：虽然不是直接由测试团队控制，但可以通过减少软件缺陷、提高交付速度等间接提升客户满意度，作为长期目标之一。如何去做——实践路径的精细规划这是万事俱备，只欠东风的一步，当然这也是最重要的一步。有一些项目可能会有疑问，上述的问题，我们都一定程度解决掉了，但自动化测试仍然没有达到预期的效果。
大概可能是以下原因导致：
优化测试用例执行设计：缺乏整体测试用例执行设计，用例覆盖目的性弱，具有随机性、随意性，低覆盖，无法真正的缩短执行效率，容易造成指标值与实际情况不相符的问题。强化自动验证能力：只做到了自动执行，但没有做到自动验证，无法真正的在保证质量的前提下，提高执行效率，也就是说效率提升一定是建立在测试有效性的基础之上的。打破“自动化孤岛”：“自动化孤岛”，缺乏持续性、未引入到流程当中。“缺乏整体测试用例执行设计”的问题 解决思路
我们在手动执行测试用例时，为了缩短执行时间，避免某些操作的重复执行，通常，我们会先设计执行场景，一个场景下，尽可能根据执行顺序，覆盖更多的测试用例。
比如，结合上述业务流程示例，我们需要自动化测试覆盖所有功能服务接口，我们的会怎样设计测试用例？是从单接口的角度还是场景的角度进行覆盖？
对于这种包含业务流程或是用户使用场景的功能测试分析，建议从场景的角度去覆盖：
首先，通过对场景流程进行逐步分解、拆分。然后，对拆分后的流程环节进行测试分析，提取测试点。最后，根据流程串联各个环节的测试点，最大程度地复用流程，降低测试覆盖过程的重复性操作，以覆盖一个场景为最小有效单位。例如，1-2-4-5-7, 1-3-6-7 。再举一个反例：
假如，我们在自动化覆盖的时候，不按照场景的方式，单个接口逐一覆盖，此时若“关注商品”暂时没有进行自动化覆盖，还是需要采用手动执行的方式验证该功能，那么从上图路径上可以看出，在实际手动执行时，会发现在有意或无意地在操作自动化测试已经覆盖的“查询商品”等功能（通常，自动化测试的覆盖策略是优先覆盖正向设计），导致出现了自动化测试与手工测试的交叉覆盖，那么从提效的角度来看，手动执行自动化已经覆盖的测试点，相当于自动化的提效作用被抵消。
因此，无论我们在冒烟测试、回归测试的自动化用例设计中，尽可能保障自动化测试覆盖功能点在操作上是一个闭环链路，避免与手工测试的执行链路交叉覆盖，以覆盖一个场景为最小有效单位，这个场景的定义就是连续性操作的闭环链路，这个链路可能包含N个功能、也可能是一个功能。
强化自动验证能力
翻阅平台的自动化用例，不乏只有验证响应状态的用例出现，也许是在手动测试的时候，只是关注了下状态，剩余的一扫而过。
一条严谨有效的测试用例，需要对响应内容全面覆盖，考虑到响应内容可能存在一些非幂等性的属性，比如当前时间，目前提供的关键字中，也灵活的支持过滤掉哪些属性不校验的功能。
避免在提升效率的过程中，忽略了质量的基本要求。这也是自动化平台需要延展的功能—— 测试用例设计风险预警。
“自动化孤岛”，缺乏持续性、未引入到流程当中。
这个大家应该都明白，那就是引入到持续集成中，是最直接、有效的解决方法。
同时，在流程中的提测环节、在系统集成前，做好自动化测试通过率、代码覆盖率的卡点。
最后自动化测试，起初的适应场景是适应于执行操作具备重复性，且测试对象具备稳定性的回归测试场景中，这是有一定局限性的。
这其中的主要问题是“成本问题”，试想自动化实施、维护成本足够低时，此问题也会被最大化的弱化，进而自动化的适应场景的局限性就会被打破，不仅仅可以应用在回归测试场景中，也可以用于新增功能的首轮测试、甚至是在与研发功能设计有良好的契约下，在提测前也可以完成。
因此，在自动化测试平台的整体设计上，要充分考虑测试人员在用例编写、维护方面的成本问题，及早的引入接口录制、智能设计等便利性功能。
除此之外，还可以去尝试结合代码覆盖率，不断提高自动化覆盖率；亦或者结合代码改动范围，精准运行对应测试用例，从机器逐渐演变成智能...
#自动化测试##长文创作激励计划#
