一线开发同学，可能或多或少都造成过线上bug甚至故障。打几个比方，某同学在开发某功能的时候重构了代码，造成了线上bug或者故障；在开发某个功能时，发现需要修改公共逻辑，害怕影响到其他功能，非常不雅观地拷贝代码，重新写套单独逻辑来支持。
上面的情况都包含了一个关键的问题，无论是功能开发还是逻辑重构，如何来保障代码开发的质量。
保障的方法每个人都知道，就是测试。
首先是新功能测试，保障新功能逻辑正确；其次是回归测试，保障原有业务功能逻辑正确。测试的方式，一般是两种，人工测试和自动化测试。随着测试技术和工具的持续发展，人工测试比例逐步降低，被自动化测试逐步替代。自动化测试是可持续和可重复的，甚至是可AI化的。
测试分层
测试也是分层的，如下图所示：
在一个系统内，自动化测试一般分单元测试、模块测试和接口测试。
单元测试
单元测试的要求基本上是单个类单个方法的测试，在我们当前模式下，编写成本太高。当然，如果是一个工具或者一段比较内聚而又复杂的逻辑(例如算法逻辑)，还是应该使用单元测试来保障逻辑的正确性。
模块测试
在系统比较大、模块比较多的情况下，可以建立模块测试层，保障各模块功能的正确性。不过当前的系统发展趋势是微服务架构，因此模块测试层并非十分必要，可以通过接口测试层来覆盖。
接口测试
这一层，是从系统入口出发进行集成测试。应用入口通常是框架服务，消息，定时任务。
在所有的开发测试中，接口测试是必不可少的一项。有效且覆盖完整的接口测试，不仅能保障新功能的开发质量，还能让开发在修改功能逻辑的时候有回归的能力，同时也是能优雅地进行重构的前提。同时，易测性也是代码结构合理的一个指标，如果发现一段代码编写测试脚本困难或者无法测试，那就说明当前代码结构不合理需要重构。
执行效率
对于接口测试，执行效率是不得不关注的一个点，若一个接口测试执行3分钟以上才能看到结果，会大大降低开发同学编写接口测试的热情。对于测试执行效率提高，建议的方案为：
1、及时更新或编写是自动生成API文档
2、使用合适的自动化测试工具如Eolinker
