测试卡壳？掌握这7招，让你的业务代码“可测性”起飞！
01、为什么要进行可测性改造
业务项目测试前、或者测试的过程中，常常会遇到以下方面的困难：
由于项目历史实现包袱，或者当前项目的技术架构实现，导致某些场景根本无法进行测试；
某些场景虽然可以测试，但测试所需要的时间无法忍受。 比如，为了测试某个离线大数据任务，每次测试需要半天的时间才能跑一轮测试，而且测试中有任何 bug，需要不断从头开始测试，非常耗时。最常见的是，几轮测试下来，不得不花大量时间在覆盖“无改动、且十分麻烦/十分耗时”的逻辑上。
目前代码实现无法满足自动化/质量运营要求。比如，某些业务场景链路特别长，可能设计十几个模块，某个模块不稳定马上会导致场景链路的测试失败；
依赖的第三方接口或服务极其不稳定，或者目前尚无法使用，导致项目根本无法即刻开展测试。 比如，作为 kafka 的 consumer 消费方，由于线下上游业务线没有丰富的流量，或者压根没有流量， 多数情况下，上游业务线不涉及改动。
处于“巧妇难为无米之炊”的下游业务线怎么办？...
以上是项目测试过程中经常遇到的迫切需要可测性改造的场景。通过可测试改造，期望达到某些逻辑可以快速、高效进行测试。
可测性改造的同时，必须要兼顾给线上产品产生的不良影响。避免为了改造，过多的影响线上产品的实现逻辑。
02、可测试改造技
如前所述，可测性改造不仅仅需要满足快速测试高效测试的需求，还需要避免对已有实现产生过多的影响。为了同时实现这两种目标，我们通常需要实际的可测试改造目的、业务代码实现逻辑、最小改造成本等，综合考虑所要采用的改造技术。
结合自己实际的项目经验，常用的改造技术如下：
1、增加开关。如果综合评估后发现某些逻辑需要在测试场景下避开，同时又希望在生产环境正常使用，那么可以考虑在某些逻辑在增加开关。 比如， 为了避免在压测时、线上故障时，尽可能少的减少用户影响，加个开关，方便又快捷。
开关打开且是压测环境时，压测数据不会写入到真实数据库中；反之则会写入。
2、线上线下实现配置隔离。为了线下需要，可以单独适配一套相应的配置用于不同的测试环境中。 比如，某次项目测试，为了对比待测分支代码、master 分支代码的差异，项目中配置了 2 套测试环境，一套测试环境对应待测分支代码，另一套环境对应 master 分支代码，然后通过对比两套环境代码的结果差异，快速暴露了待测分支代码的缺陷。
3、mock 掉依赖的第三方接口或服务。当项目依赖的第三方接口或服务未就绪、不稳定、数据丰富度不够时，可以 mock 掉第三方的接口或服务。mock 可以选择testng 等框架中的 mock 功能，也可以自行实现 mock 功能。
可以到我的个人号：atstudy-js
☑️这里有10W+ 热情踊跃的测试小伙伴们
☑️一起交流行业热点、测试技术各种干货
☑️一起共享面试经验、跳槽求职各种好用的
即可加入领取 ⬇️⬇️⬇️
转行、入门、提升、需要的各种干货资料
内含AI测试、 车载测试、自动化测试、银行、金融、游戏、AIGC...
4、测试前端页面时，在测试环境可以添加类似“彩蛋”一类的操作，方面观看某些信息。比如，某次做蓝领招聘的微信小程序和 APP 的项目，为了测试某些版本的兼容性和页面信息，在页面上添加了“彩蛋”效果方便测试，连续点击页面某个位置 3 次，页面会提示某些需要检查的核心信息和当前页面的版本信息，避免了每次测试都需要使用 debug 或到后台去查询信息，大大提高了测试效率。
5、为某些核心服务或核心逻辑添加 debug 接口。某些核心服务或核心代码逻辑非常复杂，比如常见的金融结算逻辑。当这些逻辑或服务上层还有众多逻辑和服务时，为了高效测试这部分逻辑，可以单独添加 debug 接口，此后通过该 debug接口进行复杂逻辑的测试。还比如与上下文耦合不大的逻辑，可以将新增方法单独封装出一个 debug 接口。
6、打印某些级别的 log。当某些业务链路非常长，逻辑非常复杂，且与第三方服务频繁交互时，某个业务节点出现错误，常常导致整个业务链路失败且非常不容易定义具体是哪方的问题，具体是哪个业务字段回传出现了错误。 这个时候可以在关键逻辑上打日志，通过 log 日志高效定位问题的具体位置。
7、适当减少测试环境需要处理的数据量。比如，某些离线 task 任务模块或逻辑下需要处理的数据量级特别大，几十万条甚至更多，一次执行可能需要若干小时级别的时间。 当评估测试环境不需要处理这么大量级数据时，可以仅针对测试环境支持传入时间段，模拟自动加工生成时间内(几周~几月不等)的数据，缩小一次性需要处理的数据量级，达到快速测试目的。
实际上，可测性改造的手段多种多样，而且在面对比较复杂的业务场景时，常常是多种手段并用的， 而且随着时间的推移和业务逻辑的变化，可测性改造的手段也在升级。
03、可测性改造原则及常见误区
尽管可能性改造有诸多的好处，但无论业务场景如何，项目周期如何紧张，可测性改造人员始终需要谨记一条核心原则：可测性改造应该尽可能减少对已有业务层面实现的影响。
不妨来看一个反面例子，某测试团队为了进行可测性改造，添加了一个测试开关。整个测试过程非常顺利，但在上线前忘记将该测试开关关闭，导致上线后开关影响了生产环境产生了一个严重的故障。
因而在可测性改造时我们需要时刻保持警惕： 任何可测性改造实现，哪怕该可测性改造实现异常时，都不能影响生产环境。
如下一些原则是可测性改造时建议遵守的：
原则1：可测性改造不会对生产环境产生不良影响；
原则2：可测性改造尽可能改造成本小，且方便使用；
原则3: 可测性改造尽可能避免直接改动业务逻辑本身；
原则4：可测性改造尽量一次改造长久使用。
当然了，在考虑进行可测性改造时，也常常会存在以下的误区：
为了不对业务逻辑实现造成影响和风险，干脆选择不进行改造。那么在很多情况下，可能导致项目测试不够彻底和完整。 比如，测试深度不够就不测；测试不方便就靠延迟时间往上砸；
为了最大限度满足测试需要，不仅花费大量时间对业务实现进行“面目全非”改造，而且还给业务实现带来较大风险；
可测性改造仅仅是为了测试需要，完全不考虑质量运营需要。比如，可测性改造后，业务研发工程师可能会带来额外的代码维护成本。
那么究竟如何评估一个可测性改造方案的好坏呢？可测性改造的好坏，可能需要从多个层面来综合评估。
常见的评估方向包括改造后对测试深度和效率、业务周期影响、故障预防影响、项目上线风险、改造成本、代码维护成本等等方面的综合影响，不能单单评估一个方面，而忽略其他方面的负面影响。比如，如果为了进行可测性改造，要大幅度修改掉之前的业务实现逻辑，甚至还要额外增加大量时间和精力进行回归测试。在这种情况下完成的可测性改造，不仅不会提高测试效率，反而会给项目质量本身带来不可沽的影响。
测试团队无论面临的是一个什么样的业务项目，什么样的技术架构，在评估是否需要进行改造、如何改造、改造到什么程度、改造实施的时间等等问题时，需要测试团队成员、研发团队成员一起评估决定，不能为了可测性改造而改造。
磨刀不误砍柴工。虽然可测性改造多多少少会延长项目的时间，甚至技术人员还要为此code代码，但可测性改造后，将会使得项目测试如虎添翼。