如何让测试执行更容易-测试经验谈之可测性改造

一、可测性改造的目的

           项目测试过程中，不同的测试深度、测试广度，会面临不同程度的“不便”。大致有几个方面：

• 项目的技术架构，具体实现导致某些场景不可测
• 压测过程需要“屏蔽”某些功能实现
• 目前实现无法满足自动化/质量运营要求

           以上是经常遇到的迫切需要可测性改造的场景。为了测试需要、质量运营需要，在目前项目实现的基础上进行“实现改造”，使其更加方面项目测试。这是可测性改造的目的。

          可测性改造的同时，要兼顾为了实现改造，带来的线上产品影响。避免为了改造，过多的影响线上产品的实现逻辑。

二、可测性改造的手段

            前面说了，可测性改造除了要满足测试需要、质量运营需要外，还要避免对已有实现产生过多的影响。为了实现这两种目标，常用的改造手段：

• 增加开关。为了避免在压测时、线上故障时，尽可能少的减少用户影响，加个开关，方便又快捷。
• 线上线下配置隔离。为线下需要，单独适配相应的配置
• mock掉第三方接口
• 测试环境，添加类似“彩蛋”一类的操作，方面观看某些信息
• 添加某些核心服务的debug接口
• 打印某些级别的log

              实际的改造手段多种多样，但其中切记一条核心原则：尽可能减少对已有业务层面实现的影响

三、可测性改造的误区

• 为了避免对业务实现造成影响，不进行改造。测试深度不够就不测；测试不方便就靠延迟时间往上砸；
• 为了最大限度满足测试需要，“大刀阔斧”对业务实现进行修改。给业务实现带来较大风险；
• 可测性改造仅仅是为了测试需要，完全不考虑质量运营需要；

               可测性改造的好坏，主要看改造后对测试、业务、故障预防、项目上线等等方面的综合影响，不能单单评估一个方面，而忽略其他方面的负面影响。比如，如果为了进行可测性改造，要大幅度修改掉之