测试作战能力level-up

众所周知，头部互联网公司测试团队已经逐渐由人海战术过渡到精干单体作战阶段，测试人员与开发人员的比例已经由1:1逐渐过渡到1:12甚至更多，而产品质量也是步步高升。

在测试人员精简的前提下，他们是如何做到的呢？

秘诀有很多，最关键的有两点，工具和人员。今天就暂且抛开各种辅助提效工具，重点说一下测试人员素质的提升。

传统意义上的测试人员无非关注以下几点：

1. 良好的业务理解能力

2. 良好的沟通表达能力

3. 一定的抗压能力

4. 最基础的技术能力

具备以上素质，基本可以胜任大部分公司的业务功能测试了。但是随着业务迭代的加速，由于测试人员不能根据具体变动分析到位，在资源有限的条件下，只能是局部重点无脑覆盖，至于是否命中以及命中了多少，只能根据经验粗略估算。如果要追求一个较高的场景覆盖，那只能增加资源的投入。一是人力的增加，而这明显与前面提到的比例趋势背道而驰；二是单人工作时长的延长，但这个明显只能偶尔为之，不可持续。
那正确的做法是什么呢？

提升人员素质，提高单兵作战能力。不仅需要在测试方面精益求精，还需要深入了解开发的技巧。而这方面的提升，可以保证测试人员清楚洞察开发的架构设计与代码实现，进而针对实际变更，从整体和局部两方面入手，合理设计测试用例，并编写针对的脚本，进而提高单位时间的覆盖率，从而保证质量的一致性。

现在手头有这么一个需求，某项服务的IP地址需要进行变更，而该项服务IP地址是通过配置中心的某个值设定的，要求在变更后保证服务的可用性。

那对于测试人员需要如何入手呢？

首要问题是需要评估通过修改配置中心的对应IP地址，是否需要重启服务才能生效。对于传统人员来说，可能会先执行一遍测试用例，发现实际结果与预期结果不一致，才能推断出需要重新启动该项服务。

那正确的做法呢？

可以从该配置项生效的地方入手。如下文所示，实例是定义在单例模式中：

public static synchronized XXXClientFactory getInstance(address){
   
    
    if (instance !=null){
   
        return instance;
    }else
    {
   
        instance = new XXXClientFactory(address);
    }
}

很明显该方法是静态方法，由此我们可以得出该实例仅仅会初始化一次。如果直接进行配置中心相关配置项的变更，IP变更并不会生效，所以我们应该在变更地址后，果断重启服务，这样前面的试错就可以避免了，效率自然而然就提高了。由此可见，了解单例模式对于测试人员还是很有帮助的。

接下来就让我们从简单的单例模式的学习开始吧。Java单例模式有如下5种实现方式。

1、饱汉模式——非线程安全

public class Singleton1 {
   
    private static Singleton1 singleton