接口自动化测试实践

背景

温馨提示：下文中大量提到的内容使用了美团的实践和生哥分享的实践！

业务系统上线迭代、重构，如何保证被修改后系统原有业务的正确性非常重要。简单业务手工测试即可，但对于业务十分复杂庞大的系统，回归测试将变成一项浩大的工程，但是至关重要！

举个例子：某电商公司，离职了一批又一批人，进来了一波波新人，几乎没有人能梳理清楚其中的业务和代码。譬如增删或修改字段和方法、修改条件语句及算术逻辑等，各种条件分支场景尤为复杂，手工测试覆盖不全，耗时长，这时自动化测试势在必行。

单元测试规范

单元测试规范基于阿里规范，自动化测试主要是离不开集成测试，集成测试细分又是一个个单元测试组合而成。我们先粗略的过一下单元测试的一些规范事项。

三、单元测试 
1. 【强制】好的单元测试必须遵守 AIR原则。 说明：单元测试在线上运行时，感觉像空气（AIR）一样并不存在，但在测试质量的保障上，却是非常关 键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。 
⚫ A：Automatic（自动化） 
⚫ I：Independent（独立性） 
⚫ R：Repeatable（可重复） 
2. 【强制】单元测试应该是全自动执行的，并且非交互式的。测试用例通常是被定期执行的， 执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。 单元测试中不准使用 System.out来进行人肉验证，必须使用 assert来验证。 
3. 【强制】保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之 间决不能互相调用，也不能依赖执行的先后次序。 反例：method2 需要依赖method1 的执行，将执行结果作为method2 的输入。 
4. 【强制】单元测试是可以重复执行的，不能受到外界环境的影响。 说明：单元测试通常会被放到持续集成中，每次有代码 check in 时单元测试都会被执行。如果单测对外部 环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。 正例：为了不受外界环境影响，要求设计代码时就把 SUT 的依赖改成注入，在测试时用 spring 这样的DI 框架注入一个本地（内存）实现或者 Mock 实现。 
5. 【强制】对於单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类 级别，一般是方法级别。 说明：只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑， 那是集成测试的领域。 
6. 【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。 说明：新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正。 
7. 【强制】单元测试代码必须写在如下工程目录：src/test/java，不允许写在业务代码目录下。 说明：源码编译时会跳过此目录，而单元测试框架默认是扫描此目录。 
8. 【推荐】单元测试的基本目标：语句覆盖率达到 70%；核心模块的语句覆盖率和分支覆盖率 都要达到 100% 说明：在工程规约的应用分层中提到的 DAO层，Manager 层，可重用度高的 Service，都应该进行单元 测试。 
9. 【推荐】编写单元测试代码遵守 BCDE原则，以保证被测试模块的交付质量。 
⚫ B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。 
⚫ C：Correct，正确的输入，并得到预期的结果。 
⚫ D：Design，与设计文档相结合，来编写单元测试。 
⚫ E：Error，强制错误信息输入（如：非法数据、异常流程、业务允许外等），并得到预期的结果。 10. 【推荐】对于数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的， 或者直接操作数据库把数据插入进去，请使用程序插入或者导入数据的方式来准备数据。 反例：删除某一行数据的单元测试，在数据库中，先直接手动增加一行作为删除目标，但是这一行新增数 据并不符合业务插入规则，导致测试结果异常。 
11. 【推荐】和数据库相关的单元测试，可以设定自动回滚机制，不给数据库造成脏数据。或者 对单元测试产生的数据有明确的前后缀标识。 正例：在企业智能事业部的内部单元测试中，使用 ENTERPRISE_INTELLIGENCE _ UNIT_ TEST_ 的前缀来 标识单元测试相关代码。 
12. 【推荐】对于不可测的代码在适当的时机做必要的重构，使代码变得可测，避免为了达到测 试要求而书写不规范测试代码。 
13. 【推荐】在设计评审阶段，开发人员需要和测试人员一起确定单元测试范围，单元测试最好 覆盖所有测试用例。 
14. 【推荐】单元测试作为一种质量保障手段，在项目提测前完成单元测试，不建议项目发布后 补充单元测试用例。 
15. 【参考】为了更方便地进行单元测试，业务代码应避免以下情况： 
⚫ 构造方法中做的事情过多。 
⚫ 存在过多的全局变量和静态方法。 
⚫ 存在过多的外部依赖。 
⚫ 存在过多的条件语句。 说明：多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。 
16. 【参考】不要对单元测试存在如下误解： 
⚫ 那是测试同学干的事情。本文是开发手册，凡是本文内容都是与开发同学强相关的。 
⚫ 单元测试代码是多余的。系统的整体功能与各单元部件的测试正常与否是强相关的。 
⚫ 单元测试代码不需要维护。一年半载后，那么单元测试几乎处于废弃状态。 
⚫ 单元测试与线上故障没有辩证关系。好的单元测试能够最大限度地规避线上故障。 

我们看一个简单的SpringBoot单元测试代码

愿景

自动化测试任重道远，现实是残酷的，愿望是美好的，我期望的功能和目标有如下一些要求和特点：

• 用例统一管理及可视化。流水线（代码扫描、单元测试、打包与镜像、环境部署、自动化测试）平台化统一管理

• 减少用例录入成本，支持从生产引流复制用例。简化测试用例录入的成本，尽可能多的提示，如果可以，开发一些批量生成测试用例的工具；将生产的部分流量复制，将录制的流量作为用例管理起来进行日常自动化归回

• 减少工具开发的成本。尽可能的减少开发工具的时间、工具维护的时间，尽可能使用公司已有的，或是业界成熟的工具或组件。

• 减少用例维护成本，可复用。减少用例维护成本，尽量只用在页面上做简单的输入即可完成维护动作，而不是进行大量的代码操作。

• 减少界面交互复杂性，页面操作简单。

• 丰富的用例分析和统计。

• 消息通知方式多样，通知相关人员。

自动化测试实践

下面的实战篇主要讲解的实战主要基于Jenkins+Ant/maven/TestNG/+ReportNG/Jacoco技术方案
主要以自身实践、美团、云集三个结合来简述：
美团自动化测试
云集持续集成解决方案

开发流程图

研发流程工作方式对比

Dcoker/Jenkins+Ant+Junit实践

流程图和技术方案如下，在一些未开发完或者不方便调用的接口可以使用Mock去代替，该方案用例脚本均为Java或者Scala等语言去编写->调用RPC接口或者其他接口。最终自动化执行之后产生报告，可以比较快的运用到团队自动化测试方案中。


单元测试项目的涉及到的比较关键的文件及部分目录介绍：

• 数据库连接地址设置文件：DBConfig
• 清除数据库操作文件：DBUtil
• 数据集com.biz.set.*
• 数据库变更文件com.biz.data.*
• 业务用例和数据集相关 com.biz.case.*
• 基于Ant的配置文件build.xml
  /docker/build.xml（doker容器使用)
  /build.xml(本地cmd里执行ant操作使用)
• build.xml文件内包含邮件群发、单元测试运行包含的用例范围、邮件报告的生成
• 单元测试项目依赖RPC基础调用服务包

脚本样例

脚本使用Scala编写，顺便提一下，Scala是将面向对象和面向函数式整合在一起,基于JVM的编程语言。
Scala相对Java语法更丰富，更简洁，丰富的函数操作，写起来更像脚本，能够提高开发效率。不过新版的Java也越来越简洁的语法

后置检查，期望值查询对比

build.xml配置用例范围、生成分析报告、邮件发送

执行过程

基于docker-compose的执行过程，在sanbox测试服务器的沙箱环境中执行的方法步骤

• docker-compose stop （停止所有服务）
• 切换到单元测试的变量export nodeName=unittest ，使所有业务系统启动时候连接单元测试库/缓存/MQ，(如果代码做了影子隔离，则无需重新启动所有服务)
  检查env |grep nodeName 是否切换成功
• docker-compose up -d（启动单元测试需要的服务，所有服务连接单元测试的库、缓存、MQ）
• docker ps 查看是否有项目启动异常
• docker-compose -d unittest yml文件会去读取执行Docker、build.xml的Ant配置，使用Ant进行自动化测试。
  同理，普通非容器的后台应用，也可以编写触发器监听分支代码提交状况，然后更新代码，打包构建部署，接着切换节点重启，执行Ant等一些列操作，结合Jenkins工作流的方式也非常方便。

邮件报告生成样例

Jenkins+TestNG的实践

上述方式直接写在代码中，在复用性和可维护性上非常不好管理。下面介绍的方式更利于维护拓展和管理。
如下图所示， 将自动化测试用例存储至MySQL数据库中。做成比较常见的“数据驱动”做法。很多团队也是使用这样的结构来进行接口自动化，沿用的话，那在以后的“推广”中，学习和迁移成本低都会比较低

自动用例执行顺序大概是如下图这样：
简单区分一下各个部分，可以看到：

上面的传统方式其实已经做到了简单维护、界面统计分析交互、分析消息通知等。那么在此基础上，再加上引流复制生产数据的功能，那就更加强大了。

阿里Doom自动化测试框架

Doom功能同样非常强大，未开源。部署架构图如下，复制生产流量数据到测试用例的思路可以借鉴，减少了大量造数据成本

上述美团和阿里的更详细的全文如下链接进入
云集-互联网持续集成解决方案
Lego-美团接口自动化测试实践
阿里创新自动化测试工具平台–Doom

下面是其他的一些主流互联网公司的做法，目标基本一致，实现方案各有千秋。

京东自动化测试最佳实践
去哪儿持续集成
阿里巴巴自动化测试发展思路
美团自动化测试1
美团自动化测试2
饿了么自动化测试
羚珑项目自动化测试方案实践

全链路压测系统

有了自动化测试同样随着系统的发展，发展到需要全链路压测
直接对生产进行压测有利于快速找到生产的问题和瓶颈，比自动化测试更加直接有效。

提一提：影子区域概念——全链路压测的所有数据都在生产环境做了数据隔离，包含存储、缓存、消息、日志等一系列的状态数据。在压测请求上会打上特殊的标记，这个标记会随着请求的依赖调用一直传递下去，任何需要对外写数据的地方都会根据这个标记的判断写到隔离的区域，我们把这个区域叫做影子区域
揭开云集全链路压测的神秘面纱 感谢生哥分享亲身实战
全链路压测集合
阿里全链路压测
京东全链路压测
饿了么全链路压测
滴滴全链路压测解决之道
美团全链路压测自动化实践
逻辑思维在全链路压测方面的实践
饿了么全链路压测平台的实现与原理
接口自动化测试实践的记录

以上是自己或者身边的人经验所得，也有很多互联网公司的亲身实践，结合以上经验分享，针对自己的团队，择优而从，打造适合的自动化测试、全链路测试平台。