【测试】在持续集成环境上跑自动化测试

本文字数约810字，阅读约为3分钟

在手工测试几个小项目之后，为了保证后期维护，开始写了一些接口的自动化，因为测试对象主要是小程序，并没有很成熟的用于小程序的自动化工具，就使用了一些框架写的脚本，主要框架使用的是testng，选择好使用的框架，就要完成自己的自动化测试代码，完成的case还是一些主流程和常见会出现bug的case，这些case都是测后端接口返回，而现在负责业务变更频繁，没有做ui相关的自动化，前端展示还是依靠手工来测。

如何将本地写的自动化case能最大化的发挥测试的功能，就是我们这里要说的在持续集成环境上跑自动化测试。

因为持续集成，会强制测试通过才能合并代码，在合并代码之前就能知道测试是不是都通过了，可以帮助程序员获得最直观的反馈，知道哪里可能存在问题，这样才能做到防患于未然，吧bug杀死在摇篮里。

但这样说也不是绝对，因为我在之前写自动化case的时候，需要指定一个人的身份id，后来自动化挂掉的原因，是这个人从数据库改了通过id更改了他自己的身份，所以后续我们也将自动化测试和手工测试数据分离，尽量不影响自动化测试。

下面流程描述的是自动化测试配合持续集成的一个标准流程

• 在提交代码前，先本地跑一边单元测试，这个过程很快，失败了需要继续修改

我的操作一般是，每写完一个@Test都运行一遍，有问题就及时更改，都保证没问题后，运行一遍xml文件，就是跑一遍所有流程的自动化（单元测试成功）

• 单元测试成功后就可以提交到源代码管理中心，提交后持续集成服务会自动运行完整的自动化测试

单元测试没问题后提到我自己的分支，通过jenkins部署我自己的分支，在持续集成环境跑一边我的自动化case

• 通过所有的测试后，可以合并到主分支，如果失败，需要本地修改后再次提交，直到所有测试通过为止

一般我是没有权限将我的分支合并到主分支，所以都是我把我的pr提给leader，再将我的代码合并到主分支，然后每天在固定时间会跑一遍自动化