【温馨提示】由于公众号更改了推送规则，不再按照时间顺序排列，如果不想错过测试开发技术精心准备的的干货文章还有精彩的课程，请将测试开发技术设为“星标☆”，看完文章在文尾处点亮“在看”！
![]()
本文来源于阿里云-小瑕同学分享，以团队内约定俗成的测试策略概念为主题，总结了一些个人经验和思考结论，可能对其他业务/团队而言，存在术语定义不一致，希望对大家有参考意义，深度好文，欢迎探讨，感谢理解。
基本含义：指为达到某种目的而制定的行动方案或计划。详细解释：策略是指在特定情况下为达到某种目的而采取的有系统性的行动方案或计划。它通常包括分析、决策和执行三个阶段。策略的制定需要综合考虑各种因素，包括目标、资源、环境和竞争等。策略的好坏直接关系到目标的实现效果。策略是为目的/目标服务的，且策略是自带背景/特定情况的，一定要识别到背景形势的发展和变化，然后才能制定针对性的谋略、计策。测试策略有两层背景叠加：业务大背景和项目小背景。下文提到的测试策略有时指代业务级测试策略，有时指代项目级测试策略，如果无特指强调，则是在探讨两类测试策略的共同特点。当你有多种测试方案时。如果你只有一个测试方案一条路，那就没什么选择余地；只有当多种测试方案都满足基本要求，但又各有优劣时，才会涉及到如何选择、取舍。每一次的选择取舍，抽象出的方法论，就是策略。就像棋类大师在每一步棋的选择上各有理由，但背后都有着同一套分析和决策思路，那套思路就是策略。当你的测试方案差异比较大的时候。测试方案有三个方向的指标：质量、效率、成本，这三者同时也是一个不可能三角：质量，先结合业务发展和研发模式综合制定质量标准，再以多维度指标衡量质量结果。（敲黑板：质量是被定义出来的。）效率通常以项目为衡量单位，即人工效率和机器执行效率双重影响下的项目交付/发布效率。除此之外，效率也包括了自动化研发效率、自动化运行效率、协同效率等局部效率。成本则包括了项目内成本和项目外成本，效率驱动下，质量同学大多会追求自动化率，自动化率就体现了项目内成本从人工转化到机器的程度。从人成本看，项目外的成本主要是平台工具的开发运维投入，这部分成本会大幅高于单次项目使用时的人力成本，从机器成本看，则涉及多次多方使用的平摊，追求环境利用率也就是尽可能摊薄单次使用成本。另外，成本还有时间因素，初期建设成本要在后面多次使用中逐步摊平。大家吐槽的重复造轮子，问题不是轮子不好用，而是反复付出的建设成本和使用者的学习成本太多。![]()
1)提升质量=>提高测试覆盖率=>增加测试点，其他条件相同情况下，会导致效率降低，增加成本2)提升效率=>提升执行效率=>提升自动化程度，其他条件相同情况下，会导致项目外的自动化建设成本增加。3)降低成本=>降低人成本或降低机器成本，两种方式通常都会对质量产生负向影响，效率有可能提升也可能下降。以上例子可以看到，三角的任一角正向提升时，都对另外一角或两角产生了负向影响，工作中，我们需要让三角关系处于平衡状态，每一角的表现都保持在可接受范围。综上，当你具备多种测试方案/路径，且他们的质量、效率、成本三角指标表现差异明显时，你需要分析并决策测试策略，使三角保持在适当的平衡态。前文提到，测试策略是用来选择测试方案的，那么是现有测试方案，再抽象出选择原则作为测试策略？还是先有测试策略，再生成测试方案？我们先把测试策略和测试方案拆分到业务级和项目级两个语境之下，探讨业务级测试策略、业务级测试方案（业务级测试方案这个概念不常用，可以等同于日常工作中讲的业务质量体系）、项目级测试策略、项目级测试方案四者的关系。以我的个人经验来看，在新业务（新产品或新技术栈）初始期、发展期、成熟期：这四者的关系分别对应下面三张图：![]()
![]()
如果是成熟质量团队承接新业务，就可以直接进入下图四象限循环、螺旋式上升状态。这也是大公司在新开业务时，都会主动调拨一些经验丰富同学的原因，这时候，个体经验需要从项目抽象到业务，从测试方案抽象到测试策略，才能更快的做迁移复用。![]()
小结：测试策略是测试方案的抽象，测试策略又指导了测试方案的具象化。两者就是鸡生蛋，蛋生鸡的关系。 测试策略包括的维度很广，核心要素是测什么：即测试范围、测试目标；向内细分怎么测，即测试工作的时空分布，什么时候，以什么测试方法测；向外要求测试基础设施支撑：环境、工具、数据；测什么、怎么测、测试基础设施支撑、这三个要素都和质量、效率、成本三目标有相关性，但侧重点有所区分：测什么和质量强相关，怎么测，目标是为了质量，同时也影响了效率成本的表现。测试基础设施则同时关联三个维度，能不能测（质量），测的快不快（效率），测的费不费劲（成本）。先从质量维度，定义测什么（测试范围、测试目标），同时也就定义了不测什么（极端异常测不测？用户体验是不是目标？）质量维度要求越高，测试范围越大，测试目标越高。放在业务背景下：如金融业务和搜索业务相比，质量要求高，测试覆盖率要求高，测试精准度要求也更高。从质量目标和当下能力确定怎么测（从多种方案中选择）之后，再从效率成本角度，进行平衡评估。同样考虑到背景信息：如果当下业务对效率要求更高，那么可以增大成本提高并发执行效率，如果成本有上限，那么为了效率可以对质量目标打一点小折扣，或者为了质量可以接受一定程度的低效率，把三者调整成符合业务需求的平衡状态。测试基础设施呢？测试基础设施为了同时支撑质量效率成本三目标，以技术的方式，综合提升三目标的整体表现，即用技术做到：质量更好，效率更高，同时成本持平甚至更低。这也是为什么对测试团队考核时，测试工程能力的权重会日益增加。就是因为靠人只能做到三目标的相对平衡，靠工程（测试基础设施）才能做到三目标绝对总分的提升。细心的同学可能会看出，三角指标中，我总是会把质量放在最前面。因为质量是测试的首要职责，是测试工作存在的基础前提。也更因为质量是业务存活以及发展的前提。大家日常可能会吐槽说某某团队不重视质量，仔细回想下，这个团队能接受质量极差，天天故障的状态吗？不可能的。换句话说，有什么业务会嫌弃质量太好吗？。。。如果你感知到你的主管或业务方对质量的要求不高，和你标准不一致，可以细细分析下，是不是高质量标准带来的效率、成本，有点拖后腿了？如果我们能解决效率成本问题，高质量绝对是我们的一贯追求。所以在三角指标中，我会把质量放在引领地位。最后，测试策略还有一个非常重要的要素：组织协同：什么角色测，其他角色如何协作。可能有读者看到“什么角色测”，会觉得多此一问：不就是因为测试人员负责测试，我们才来探讨测试策略么？这个问题的答案太显而易见了吧。注意，如果有这种想法，可以把此处作为一个提醒，要先练习跳出测试角色看测试工作。业务级测试策略是为业务服务的，项目级测试策略是为项目服务的。既然测试策略是服务于业务、项目的，那么所有业务、项目的干系人，都有责任和义务支持最优的测试策略落地应用，那么“什么角色测”，取决于各角色知识、技能、工作流程的最优匹配，而不应被已有分工所限定。比如单元测试，为什么通常是开发在测？不是因为测试做不了单元测试，而是测试负责单元测试的信息成本太高（开发写代码自然知道代码的设计细节，而测试需要额外付出了解成本）。再比如为什么要有pd/业务验收环节？是因为验收过程不仅能验证产品实现是否符合prd设计，还能兼顾prd没有覆盖的用户体验部分，pd/业务在这方面也比技术角色更擅长。最后还有开发自测项目这个经典场景。我个人始终如一的支持部分项目由开发自测，原因是，对于改动小，风险小的项目，开发、测试完全能够达成一致的质量结果，且如果测试方法明确，测试工具易用，开发也能够做到和测试持平的效率表现，两角表现相等情况下，开发还能够节省一份沟通协作成本（类似单元测试，节省自我沟通成本），那么这部分协作成本就是开发自测在不可能三角的正向收益。那么什么样的项目不适合开发自测？从上文可以看出，适合的项目前提是两个角色在质量、效率表现相同，如果这个前提被打破（由于岗位职责、专业能力差异，测试比开发表现更优），这类项目就需要做取舍：成本的正向收益 Vs 质量效率的负向收益。这也就是为什么：复杂、大体量业务中只有部分项目能够开发自测，高风险项目一定需要专职测试团队承接。（有些外部公司据说是没有专职测试团队的，那么需要确认业务风险类型，以及是否有专职保障此类风险的团队。）小结：测试策略的四大要素：测什么，怎么测，测试基础设施支撑，组织协同，共同服务业务、项目的三角指标（质量、效率、成本）既然测试策略是服务于三角指标，那么三角指标的整体表现就是测试策略的评价标准。好的测试策略能做到三角表现平衡，特别是业务级测试策略，它能持续作用于业务发展各阶段，跨越周期更长。在这个过程中，外部压力或内部发展变化都会扰动三角的平衡态。我们要做的是先感知到失衡，并且判断具体失衡位置和程度，再通过测试策略进行调整，回归平衡。质量维度：如果线上出现重大质量问题，即质量表现严重偏离预期时，需要以质量为牵引，先要让质量回归到稳定态，这时候通常组织会投入更多成本（包括不限于人、组织、机器资源），不论是手工测试还是自动化测试，都以增加质量覆盖率为目的，同时容忍效率的降低。效率维度：当研发效率或业务发布效率被频繁提及时，说明效率维度偏离了组织预期，可能是预期提高了，也可能是效率表现降低了，在重新明确效率预期后，不可能三角要围绕效率做再平衡。这时候先通过增加成本，即增加人或机器的并发工作来提高执行效率，如果还不能达到要求，则需慎重考虑质量预期是否可调，以减少执行时间，提高效率。注意，如果要下调质量预期，一定要得在所有角色层面达成一致。成本维度：如果质量效率都表现ok，成本就是默认的内在驱动力。由于成本可以细分为人、机器两个视角，组织期望降低人成本或降低机器成本时，都需要调整测试策略，进行再平衡。总结来说，当组织内部的声音开始在三角的某一角上逐步聚集时，特别是有一些badcase出现时，就说明三角开始失衡，需要我们主动去做再平衡。而再平衡的策略也很简单：质量优先，效率其次，最后由成本作为持续驱动。还有一个反向小技巧：如果在某一个角上频繁获奖或获得高度评价，说明此处表现已经显著超出预期，需要适当多考虑一下其他两个角。三角指标真的不可能一起提升吗？其实从前面分析已经提供了线索：技术。只有通过技术创新，才有可能整体性提升质量、效率、成本表现。技术的成本收益的规律如图所示：![]()
新技术在初期付出研发成本，在后期应用时收回收益，质量领域的技术不论是质量收益（不可测变可测），还是效率收益（同等交付下效率更快），都遵循上述投入、回本、持续收益三大阶段的规律，如果我们能到持续收益期，那么不可能三角就可以全局性提升。如何在长周期变化情况下，选择正确的技术方案，在未来的某日能够通过质量效率收益收回技术投入成本，进入持续收益期，这就是测试负责人的终极考验。反之，如果技术无用或技术本身投入或维护成本过大，要么平白增加投入成本，要么回收期就会很长，而且很可能碰到业务变化，等不到回本的那一天。从上图可以看出：成本相比质量效率，需要更长的周期才能全面衡量，同时成本有项目内和项目外两种成本（类似表内和表外），最典型的测试工具平台开发、技术架构改造，这类工作有时会包含在某一个业务项目内完成，有时独立为技术项目自运作，更多时候，这类成本会散落在项目间隙中，比如工具维护，排查，答疑等等。对于测试负责人，除了关注项目内成本，更要关注整体性成本。一是长周期下收益的变化，一些技术效果会逐步腐化削弱，是否还能提供足够的收益冲抵成本，需要持续关注，二是成本积累效应，散落成本会随时间逐步积累到一定规模，要考虑历史积累到现在的维护成本，组织是否还能支撑。
2.3 有没有成本减少后，质量效率降低的情况？
这种情况可接受吗？
举两个质量表现降低的例子：一种情况是某种原因导致测试投入被动减少（比如出现测试人员离职转岗），线上问题有增加，但没有出严重故障。另一种情况是业务发生变化，如业务量下降，线上问题的严重程度下降，组织主动减少了测试投入，线上问题有增加。这两种情况都出现了投入成本的降低和质量表现的下降，唯一区别是因果顺序，主动被动之分），两种情况的共同点是，质量表现仍在业务允许范围内。请注意：质量指标是多维度指标，问题数量、问题影响面（时长、用户量）、问题对客表现等质量子指标都是独立变动的。如果有某个质量子指标下降时，就需要考虑这个子指标对全局质量影响的权重，以及具体下降程度，来判断质量整体表现是否可接受。毕竟我们的质量表现不是每天都在生死存亡线上勉强维持，所以总有一部分空间是可以接受波动的。这个话题更适合总结为“业务质量标准制定”, 本文不做过多展开。成本降低时，如果原本资源就很紧张，那效率一定会体现出降低，而且更容易体现在主观体感上：不论是投诉测试太慢的声音变多，或是测试排期开始变得困难，或是大家感觉测试周期比预期长了，这些都是短期效率下降的信号。注意：主观体感和客观指标的差异在于，主观体感对个别异常case会感受强烈，放大短期表现，而客观指标观察的是一段时间周期内的均值表现，通常不会剧烈变化，如发布周期、测试周期、回归周期、测试开发周期比等指标，也就更适合做中长期评价。那么短期效率表现降低时，是否一定要解决呢？是否一定要补充资源（增加投入成本）来解决呢？我个人的思路是，先观察分析当下成本结构（人、机器）和效率要求的冲突点在哪里，未来发展趋势是什么，是短期波动还是长期影响，客观效率指标变化趋势如何，整体效率表现（主观+客观）是否仍在大组织可接受范围内，再决策是否解决以及如何解决。对解决方法的探讨更适合总结为“测试模式与测试梯队能力建设”，本文也不做过多展开。从以上的探讨可以看出，对质量、效率来说，都没有绝对客观的衡量标准，即使各个维度都有客观指标，最终也需要有一个主观定义的目标值。而目标值的设定和业务发展、组织要求息息相关，有时还要参考同行表现，以保持团队竞争力。
1.打开冰箱门=瞄准目标：确定三角指标的具体衡量指标和目标值。这一步是在制定质量标准、团队kpi/OKR时就应该已经完成的。重点是冰箱（业务）本身。2.评估测试策略在三角指标的表现。这个步骤就是“把大象放进去”，即问题的本质步骤。上文讲了很多测试策略和三角指标的联动关系、观测信号、调优方式等，但每个测试策略的实际表现必须放在具体的业务、技术、团队中衡量，即对应到具体的大象、冰箱实例场景中。3.选择匹配度最高的测试策略。像关冰箱门一样简单直接。如果这一步没法对比匹配度，请回到上一步。
1. 大体量业务上新启动了一个战略项目，如何制定项目级测试策略？
业务体量大=业务质量要求高，并且一定已经有了一些基础测试体系，新启动，代表有新功能新特性甚至新产品新业务模式出现。战略项目说明重要程度，也代表了对质量、效率（交付进度）的高标准要求。接下来就是先明确项目质量目标和发布时间目标，再参考目前团队人员，初步判断是否能以现行业务级测试策略支撑。如果新功能部分所需要的人员技能是目前人员技能无法支撑的，那么招聘、借调、培训都需要尽快做起来，如果以现有人员配置能够支撑质量工作，但效率目标和质量目标有冲突，那么一定要确认成本、效率、质量三角权重关系。对战略项目而言，优选增加成本投入，保障质量效率目标，其次选择微调质量或效率目标。微调质量效率目标都需要以质量为key：按照功能或按照质量风险的表现型，区分出重大风险和小风险，优先保障重大风险，小风险则可以进行风险报备、风险缓释（灰度观察）、延后保障（发布后补测）等。实际上，战略项目的重要程度，通常值得团队做一些前置工作，比如在开发阶段同步做自动化测试用例开发，或提前开发测试工具，都可以提升测试阶段的执行效率。本质是把一部分测试阶段的工作量折叠到开发阶段同步进行，减小测试阶段质量效率目标的冲突程度。2. 新启动的业务，如何制定初始期业务级测试策略？
新启动业务，如果完全没有可继承的三角目标、标准、质量体系积累，甚至团队都还在组建过程，那么先恭喜你，这是一个没有技术负债的场景。没有历史包袱，就大胆的追求完美吧！首先基于业务形态，分析业务质量表现维度，定义指标和目标值，可以参考同类业务的现行指标和目标值，然后和业务、研发团队探讨业务研发模式，确定效率目标，如项目制、班车制、独立发布or全局发布。最后参考技术栈和业务经验两类能力要求搭建测试梯队。定好了目标，就在实践中进行迭代优化。每一个项目的测试方案都是我们迭代的基础，每一个bug都是我们优化的线索。项目测试方案不仅是为了保障单个项目，还要在项目后复盘总结测试方案的优劣，从质量、效率、成本三个角度综合评价。漏测指标是质量的抓手，重复性的工作量是效率的抓手，测试方案优化后也不仅是用于当下的项目测试，还可以用过往的项目做回溯分析，时刻记住，除了当下的项目，更重要是面向未来交付业务级测试策略。参考业务复杂度和人员经验，一般3-6个月内就可以完成初版业务测试策略了。3. 成熟业务顺利运转中，如何定期刷新业务级测试策略？
既然是成熟业务，潜台词是目前三角表现平衡，那么此时需要分析未来半年、一年甚至三年期间，业务会面临什么样的变化，质量效率目标会有什么变化。比如市场中出现了新的强大竞对，竞争态势会对迭代效率提出更高要求；比如业务进入高增长期，用户量业务量急遽增加，此时会对稳定性、性能提出更高要求；再比如产品形态发生变化，从原本异步交互转为实时交互，这也是对质量的挑战。识别到三角目标的变化趋势，才能提前布局，建设技术能力，在业务需要时就能直接落地应用，产生收益。在预判未来趋势过程中，尤其要注意业务模式或产品形态的变化，它们通常会带来风险类型的变化。如原本独立经营的金融业务，引入了合作机构，转变为平台生态型时，风险引入和风险表现都增加了机构端，会对三角指标都带来显著影响。再比如原本免费的业务开始对某些场景进行收费，或营销活动增加了现金类优惠，这些业务变化都代表着业务有了资金属性，那么相应的资金类风险也应全盘考虑。除了分析未来变化趋势，还需要对现状有更全面细致的了解，虽然是三角平衡，但三角不可能都是完美表现，针对每一角的具体表现提出更高要求，分析现状的差距，也能够指明我们的提升方向：质量优先、效率其次、成本持续驱动。这个场景说来简单，实操最难。因为成熟业务下，从业务团队、研发团队传导到质量团队的压力相对可控，如果质量负责人自驱力不足，很容易陷入战术性的忙碌中，毕竟项目一个接一个，peer只关心我们交付的结果，对测试策略难以感知、也很少提出建议和要求。质量负责人必须要持续跟踪质量、效率、成本表现，定期回溯分析质量策略执行情况，主动刷新测试策略，调优三角表现。4. 再举一个极端场景，有一个大项目（开发+测试工时>1000人日），因为种种原因需要倒排发布，倒排后只有正常周期的一半，怎样保证发布质量和发布时间？
这个场景的问题本质是效率和质量的明确冲突，最简单方案是调整第三角 -- 成本目标，也就是加人/加班增加投入时间来解决。此处极端场景强调了倒排只有一半周期，基本已经无法通过单纯加班解决（个人经验值：加班极限是同等自然日内增加50%工作量，很难做到增加100%）。加人也有可能无人可加，或即使有其他项目人员可以借调，如果没有匹配的经验积累，加人并不能等比例提高效率，还会因为新加成员需要有经验成员的传帮带，更加占用原有项目人员的投入。所以如果增加成本不能解决效率和质量冲突时，我们还有哪些策略可做？倒排等同于效率目标中的交付日期锁定。那么效率目标的其他目标是否有可调空间？列举几个可调整角度：1)提测日期提前，把测试周期尽可能拉长。分批提测也是类似思路，都是把实际测试工作执行的时间尽可能往前提。把测试时间窗口拉长，以容纳工作量。2)在开发阶段提前准备测试工具，提高测试执行阶段效率。3)在开发阶段提前准备测试自动化用例，提高测试case并发效率。还能充分利用夜间时间，扩展case执行周期。以上两条的测试工具和自动化用例就不用再遵从默认的成本收益回收策略，而是专注于解决此次项目交付要求，增加执行并行度。这也是通过增加投入解决效率问题，只不过不是增加新人，而是用项目原有测试人员，在研发阶段进行提前投入。如果调整成本、效率，都不能解决，就需要慎重考虑质量目标这个角了。同样列举几个可调整角度：1）部分功能延后发布。如理财业务中，有一种最低持有期的理财产品，申购后一定日期后才能赎回，那么可以和业务技术协商，先保证申购功能的测试覆盖，再在项目发布后，赎回功能尚未打开这个短短的小窗口内，补充保证赎回功能的测试覆盖。这样可以把一些功能的质量保证工作后置，减少倒排周期的影响。2）评估后裁剪部分回归测试用例集。回归用例顾名思义是此次变更不涉及修改，仍应保持原有功能的用例，如果时间充裕，回归用例需要实际执行并确认结果，但如果时间非常紧张，且没有过往成熟的回归自动化快速执行，那么可以通过评估系统实现方案+CR后确认是否有部分回归功能不受此次变更影响，然后裁剪该部分回归测试用例。特别提醒！！评估后裁剪部分回归用例集，能显著减小工作量，但评估不全（系统历史设计未考虑到，CR不全等）导致这部分回归用例产生漏测的案例也比比皆是。所以这个策略风险极高，对核心回归功能不建议采用该策略。对非核心回归功能也要谨慎进行。3）对核心回归功能，更建议做功能场景覆盖调整。一个功能的用例集可以细分为多种触发场景条件的具体用例（case），这里也基本遵循二八原理：80%的用户场景（用户操作流量或业务数据等价类）密集落在20%的场景上，而剩下80%的场景，流量分布更稀疏，触发概率更小。举例某个业务功能用例集涉及150个用例：这种情况下，从150个场景用例中，优先选择用户操作流量占比最大的用例（如选择80个用例，可覆盖99%流量），即可大幅减少测试时间。这样可以保证大范围业务没问题，让可能遗漏的问题只表现在小范围业务流量上，减小影响面。未选择的用例，是发布后观察线上表现，还是在发布后验证或补测，也可以根据具体业务情况进行策略再确认。灰度也是类似道理，通过灰度比例控制新代码生效的业务流量占比，以此控制可能问题的影响面。特别提醒！！该策略仅能用于问题影响在业务上可接受的情况，如果是高风险场景，如高客单业务的资损风险，一笔操作可能就会触发一个P1，仍然不建议采用该策略。4)发布后进行线上验证。和第一条延后发布不同，如果存在线下测试成本极高，线上测试成本很低的情况（如一些历史数据构造成本大，使用线上数据成本小），可以基于效率考虑，在发布后在线上进行验证。由于项目已发布，那么一定要同步发布线上监控核对观察线上表现，且第一时间进行线上验证，把可能的问题影响面控制到最小。5)以上除了第一条延后发布不会带来实际质量风险外，2,3,4都有质量风险，那么要补充两点：a)已知线下测试裁剪或未覆盖的场景，必须要有线上主动发现能力。
b)已知会产生线上问题可能的场景，必须要测算线上风险敞口（线上pv *时长 * 影响表现，如果涉及客诉的，要计算客诉转化率），并进行相应业务报备。
以上是比较简化的几个场景。其实业务的变化时刻在发生，每个团队也一直以专业能力见招拆招，是着眼于一个月的变化，还是预判一年的变化？对业务级测试负责人而言，需要把视野拉到业务全局，把目标放到三角整体，每一个测试策略的决策，要兼顾当下和未来，避免只见树木不见森林。更重要的是，如果没有明显的当下的问题，要把成本作为默认驱动，用技术的方法持续优化三角表现。总结：测试策略对测试中长期布局有着非常重要的意义，对测试负责人来说，解决问题只是基础要求，在多种有效方案中选择最优解，才是更大的挑战。通过三角目标做牵引，对业务做预判，刷新目标，主动规划，时刻调整，和业务共同应对不确定的未来，才能持续为业务保驾护航。
