在当今企业推动数字化转型的背景下，如何在提升研发效率的同时守住质量底线，成为了技术团队尤为关注的话题。软件测试是确保软件质量的重要实践之一，而其中的测试分层策略更是关键。尽管“测试分层策略”这一概念对许多团队来说还比较陌生，它实际上是软件测试中的一个重要组成部分，决定了团队如何根据代码架构的不同，制定相应的测试方法。
然而，很多团队在面对测试分层策略时存在认知缺乏、设计不完整、以及与实际工作脱节等问题，这直接影响了测试实践的效率。本文旨在通过提出一个模型，帮助团队建立统一的测试分层策略认知，提升测试实践的效果。
什么是测试分层策略?
提到的测试分层策略，大家感觉可能是既熟悉又陌生。其实测试分层策略是测试策略的一部分，对于测试策略，目前业界的普遍说法是测试策略主要包含的两个方面内容：
- 测什么？- 指测试的目标，是功能、是性能、还是安全？
- 怎么测？- 指测试的手段，由谁，在什么时候，是手动还是自动？
所以依照上述的特征，为了沟通时更聚焦，我更喜欢将测试策略分为流程策略和分层策略：
- 流程策略 - 即以时间为主线确定测试方法。明确产品需求研发过程中的测试活动、角色职责、门禁标准等。
- 分层策略 - 即以软件的代码层次为主线确定测试方法。从技术的角度，针对被测单元不同的颗粒度，规划测试相应的测试方法。
在过往的咨询经历中，我们发现多数开发团队对测试流程策略相对更了解，因为它和人员的日常工作密切相关，每个人都需要知道在什么时候应该和谁协作来做什么事。但往往询问起团队某个系统的测试分层策略，却极少有人能够说清。
分层策略常见的问题
每当我们调研团队有关分层策略的问题时，一般会有下面三类典型现象：
- 缺乏统一认识 - “什么是测试分层？我不知道啊！” 一般团队中极少有人能够将团队的测试分层说得清楚，即使是团队的技术或测试负责人也只能从团队实操层面说明团队都做了什么，甚至部分人连测试分层的概念都搞不清，不同角色之间更多是关心自己的一亩三分地，把自己职责上要做的测试做了就行了。
- 缺少顶层设计- “单元测试是开发团队做的，和测试团队没什么关系。” 有部分团队的技术或测试负责人可以说清楚对某个系统都做了哪些测试，比如有单元，接口，UI等，但是各类测试之间是割裂的，缺乏整体设计与层次间的配合规划。这样最容易出现的问题就是将原本应该是金字塔的策略做成了水桶型，不同层次的测试间做了大量重复的工作。
- 与实际工作脱节 - “测试金字塔？在墙上贴着呢。没啥用，还是该咋做咋做！” 部分有策略意识的团队有时会短期突击梳理系统的测试分层策略，梳理过后大家对实践高质量信心百倍。进入到了具体工作时大家发现这东西不知道怎么和实际的工作结合起来，慢慢的也就忘记了它的存在，回归最初的工作方式了。
这三种情况的存在会使团队的测试实践效率低下，团队即使投入了大量的资源来增强某些测试实践也很难达到好的质量保障效果。
分层策略实践模型
为了尝试解决这些问题，我们的构想是希望能够给团队建立一个对测试分层策略的统一认知与目标，可视化的管理各个层次的测试实践，并且让团队能够用这个统一的目标来指导自己的工作，所以就产生了本文要给大家介绍的测试分层策略模型。
1.维度设计
首先模型定义了纵向与横向两个维度，形成一个四象限的模型框架。其目的是希望对目标被测系统进行分类，不同类别的被测系统会有不同的测试策略推荐：
- 纵向维度考量被测系统的“可测试性”：直观的理解可测试性就是一个计算机程序在各个层次上能够被测试的容易程度。我们期望通过可测性维度来体现团队为该系统添加各层自动化测试的成本，测试成本的高低肯定会影响团队对测试策略的选择，毕竟无论哪个团队的资源都是有限的，需要考虑最合适的投入产出比。
- 横向维度考量被测系统的“质量风险”：我们期望通过“质量风险”维度来体现被测系统对质量风险的承受能力与团队现阶段的质量保障能力，一个银行结算系统的测试覆盖率肯定要比一个公司的门户网站的要求更高一些，同样一个各层次自动化测试防护完善的系统肯定也不需要团队再花太多的精力去做更多的回归测试。
实际的使用中这两个维度都可以进一步拆分成若干个评分因子，比如下图例子中蓝色因子代表系统可测性，绿色因子代表系统质量风险。不同的系统可以根据自身情况决定需要采用的因子或者给因子添加权重。
2.策略推荐
接下来团队可以根据自己系统在两个维度因子的得分，综合评定系统在象限中所处的位置，不同的象限会根据系统不同的特点有相应的分层策略原则推荐。
- 理想系统 - 1号象限（可测性高，风险低）：这个象限是一个比较理想的区间，首先处于这个维度的系统可测性好，实施各层测试的成本较低。同时质量风险低意味着系统对缺陷的容忍度高，测试实践的基础较好。这种系统是很多团队的期望与目标，所以业界较为推崇的金字塔分层策略适合这样的系统。
- 遗留系统 - 2号象限（可测性低，风险低）：相比1号象限，2号象限的系统的质量风险低，但可测性也很低。这样的情况往往出现在企业中的一些遗留系统，这种系统往往因为技术栈的老旧使其添加更细粒度自动化测试成本很高，甚至有些层次无法测试。所以对于这类系统与其固执的继续高成本的添加细粒度的自动化测试，不如先从成本较低的粗粒度（比如UI）层测试加起形成质量防护网，以待后续系统可测性提高之后再将测试点逐步下移，所以倒三角型的测试策略会更适合2号象限系统的现状。
- 核心系统 - 3号象限（可测性高，风险高）：同样相比1号象限，这个维度的系统虽然也有着很高的可测性，但是他们也有更高的质量风险，系统对质量的要求更加苛刻。比如一些企业的核心业务系统或者银行中涉账业务比重较高的系统，业务的重要性使他们承担不起金字塔策略中下移测试点带来的质量妥协，在各层中都要追求更高的测试覆盖率以保障系统功能的安全。例如我们见到的银行系统中对于UI端核心交易流程的测试投入明显要比其他行业高出许多，所以这类系统在各个层次上的测试覆盖率都需要比金字塔要更高些，梯形的测试策略就更适合当前象限。
- 遗留核心 - 4号象限（可测性低，风险高）：这个象限的系统基本上综合了各种不利因素，各层次测试成本高的同时，对质量要求又苛刻。团队的目标只能是不顾成本的在各层都竭尽可能的增加测试资源，毕竟高质量风险之下的质量要求是不可妥协的。这时候团队最应该关注的是需要尽早提升系统的可测性，尽可能的降低测试成本。
2.策略演进
使用本模型，一般系统的分层策略的演进会分为两个阶段：
- 第一阶段：在明确系统所处的象限之后，对比现状与该象限的推荐策略，改善系统的测试实践使它尽可能符合对应象限推荐的原则。
- 第二阶段：通过提升系统的可测性与系统的测试基础降低质量风险，实现维度跃迁。让系统可以具备更科学，性价比更高的分层策略。
因此最后从演进的整体趋势来看，策略应当是“从左向右，从下向上”的，一旦你发现团队的策略在上面的模型中呈现相反的趋势，那就需要小心了。配合下一段的实际案例大家对策略的演进应该能有一个更直观的理解。
实践落地过程及案例
模型实际的落地过程中通常要经历模型定制，评估打分，制定改进计划与落地实施4个环节，在具体落地实施的过程中也会对计划进行迭代调整。
1.模型定制
在模型定制的过程中，模型的维度（可测性与质量风险）是固定的，但对应拆分出的因子可以根据实际的业务类型，系统与团队状况进行适当的定制调整。最好能够与团队的关键干系人以共创工作坊的形式来定制因子，一方面可以让关键的干系人更深的了解模型的运作原理。同时也增加他们的参与感，后续有更强的实施动力。
2.调研 & 评估阶段
调研评估这一步的目的是收集被测系统的信息得出因子评分，同时另一个重要的目的就是需要了解系统的测试基础现状。一般建议采用关键角色访谈加实地调研的方式来收集信息。仅访谈得到的信息往往容易受其他因素干扰，必须现地现物的看到具体的产出。
3.制定改进计划
改进计划的制定基本对标策略演进的两阶段：
第一阶段，对标系统所在象限的策略原则建议进行改进。
图中的被测系统通过因子打分定位到了第2个象限，目前系统只有部分自动化接口测试。根据当前象限的策略推荐，系统应该采用倒三角形策略，又因为当前是一个纯后端系统，没有UI层测试，所以主要改进两个方面：完善现有接口测试与增加单元级别自动化测试，使当前的分层策略更符合推荐的策略。
第二阶段，提升可测性，提升测试基础实现维度跃迁，进一步优化分层策略。
通过对架构的改造，编码与持续集成实践的提升，系统实现维度的迁移，但受制于当前系统的实际情况与技术栈，无法将可测性提升到最高，目前阶段只能采用半纺锤形策略。
改进举措可以和团队的技术负责人以协作的方式共创得出，外部教练往往只能从原则方向的角度去引导团队，技术负责人则更清楚实际的系统状况，只有与他们协作才能产出切实可行的改进举措。
4.策略改进实施
实施过的团队中改进的具体举措大都会直接形成技术债卡片，在日常的迭代中把技术债逐步消化掉。这样就需要团队的技术负责人统筹、管理这些具体的改进举措，把他与技术债融合统一排定优先级。为了更科学的管理改进举措，我们还会通过类似精益价值树的方式将粗颗粒度的改进举措逐层进行拆解并制定相应的成功度量指标（MoS）。
总结
在实际辅导客户团队的过程中，我们发现：
- 首先，测试分层策略模型能够帮助团队建立一个可视化的顶层设计，实现统一规划，并明确各层次的测试职责，从而实现测试点在各层的合理分布，达到层次间的有效互补与配合。
- 其次，通过分层策略的演进，团队可以分析并识别当前测试分层的优化点，规划改进措施。同时，通过可视化现状问题，推动架构改造等具体措施，以提升系统的可测试性。
- 最后，将策略模型与技术债务偿还的实际操作结合，能够确保测试策略改进与实际工作紧密对接，使测试实践与最初设计一致，从而实现测试活动的高性价比。
