降本增效下的自动化测试实践

前几天在技术交流群里，大家聊起了自动化测试在当前降本增效大环境下的落地实践，以及遇到的一些挑战。聊了蛮多的话题，我总结下来主要集中在如下三点：

• 自动化测试是否有必要继续投入？
• 降本增效下的自动化测试实践，有哪些可参考案例？
• 除了自动化测试，阻碍效率的因素有哪些？如何解决？

就这三个话题，我想结合我的实践经验，谈谈我观察到的现象和一些解决问题思路。

1、自动化测试是否有必要继续投入？

首先很肯定的说，自动化测试是有必要继续投入且长期投入做下去的，为什么？答案很简单，因为技术的发展本身就是更好的更高效的技术替换原有的低效的技术，这是技术发展的自然规律，不以人的意志为转移。

与软件工程领域很类似的就是工业界，也是通过大规模的自动化流水线替代了原有的手工作坊，这样大规模的自动化流水线才能降低技术研发的前期巨大投入，从实验室作品转变为可以为普通人所接受并使用的工业化产品。比如手机，比如汽车，都是在如此规律中发展变化的。

但是，需要注意：技术的发展和落地演进，前期确实需要投入一定的成本，且短期的收益无法覆盖成本的。只有长期的投入和不断实践优化，前期投入的成本才能在后期被大规模应用所摊薄成本，带来正向的收益，自动化测试也不例外。

前几年经济形势尚可，IT互联网行业还存在泡沫时候，确实涌现出了不少自动化测试相关的工具/框架和最佳实践案例。虽然在当下降本增效的环境中，很多公司在降低IT和技术开支，但借用以前的工具/框架和最佳实践案例，依然可以帮我们少走弯路，为质量保障提升带来些许助力。

当然，从我个人的角度来讲，自动化测试在落地实践前，需要考虑清楚如下几点事项：

• 短期项目，重点关注需求和交付质量即可，自动化测试慎用。
• 迭代快的项目，自动化测试用例和数据维护成本高昂，考虑资源和成本是否充足再决定。
• 自动化测试在当前大环境下，更大的价值是保质量，而不是提高效率(至少短期内成本大于收益)。

2、降本增效下的自动化测试实践案例

当前大环境，各个IT互联网公司都在大搞特搞降本增效，很典型的例子就是，以前会有专职的测试开发负责各种测试平台和工具开发，为业务测试提供支撑。而现在，测试开发的大部分工作内容也是参与业务测试，工具和平台开发占比越来越小。

还有一个典型的例子就是对商业工具的采购。前几年做To B的软件SaaS公司，活的还可以，这几年接连倒闭或转换业务方向，能活下来的越来越少，客单价也越来越低，笔者是深有体会。

当下自动化测试更合理的做法是，开发一些小工具(比如造数据)或者直接用成熟开源的测试工具/平台，能让测试用例跑起来，满足主流程的一些日常回归就足够了。越想深入，成本越高，收益的边界递减效应越明显。

下面是一个技术交流群的群友分享的他们目前的自动化测试案例：

专门的自动化测试组，开发工具+新增脚本，新功能上线，自动化用例再同步。 功能测试同学专注功能测试以及维护自动化测试脚本，UI主流程回归还是手工。 测试任务拆分时，分为功能和自动化测试，新功能发布后，自动化再跟上即可。

当然，上述案例仅是交流时这位同学描述的，具体详细情况我不甚了解。他的这个案例我评估下来，其实投入的成本还是比较高的，一般小公司养不起专职的自动化测试团队。

而且这样做还容易导致这样的问题：自动化测试对功能测试同学来说就是一个黑盒，维护自动化测试脚本没有工作成就感和反馈，时间久了容易懈怠。自动化测试组对业务理解会不够深入，时间久了很容易务虚，向着工具平台组发展。整体来说，他们测试团队的成本应该是居高不下的。

不过他们这样的做法，有一个亮点，就是自动化测试的建设和日常运营是分开的，不会耦合在一起导致更加高企的沉没成本。长期来说这种方式还算比较合理，但这个又很考验管理者的能力，这就是下面我要分享的内容。

3、阻碍效率的因素以及提升效率的思路

其实很多时候我们在讲提高效率，用技术手段解决效率低下问题，我的看法是有点隔靴搔痒。因为真正导致效率低下的因素是需求的不明确、频繁的需求变更、大量的沟通和会议以及跨团队协作，这些占其中大部分因素。少部分因素则是工程师个人技术能力和职业素养问题，以及更少部分的工具平台问题。

用一位技术群同学的话来说，效能提升=管理手段70%+人员能力20%+工具平台10%。虽然不是特别准确，但也很形象地解释了团队越大效率越低的现象背后的原因。

自动化测试在落地之前，一定要明确目标是什么，要解决什么问题。如果是为了提高效率，最后大概率会以失败收尾。应该将自动化的关注点放在和业务低耦合的区域，比如造数据，比如监控跑批，而不是提高自动化测试用例的覆盖率！

相比于用工具和技术手段解决低效率问题，还不如想想，如何让需求写的更明确，如何让产品研发都按照排期交付提测。

如果只是不断压缩测试时间，让测试同学又跟进项目进度，又保证质量，又要落地维护自动化，那很快测试团队会陷入顾此失彼的境地。最终的结果就是，测试更累，质量保障和效率提升都没得到明显效果，领导在那儿气急败坏说测试什么正事都没做好。