接口自动化测试平台之一——开篇

开篇

2019年在公司做接口自动化测试平台，目前已经实现了部分功能，接口，用例，用例集查看，参与CI,每日构建，测试报告展示等功能，接下来准备丰富这块的功能，同时完成产品流程测试功能，因为平时还有业务测试的任务，所以平台的建设只能在下班后才能继续，进度稍慢，先整理一波

众所周知，接口自动化测试有着如下优点

• 低投入，高产出。
• 比较容易实现自动化。
• 和UI自动化测试相比更加稳定。

当然不同于大企业，拥有较好的资源，雄厚的人力，财力物力作为支持，作为一般规模公司的测试人员，如果在做平台的时候还要兼顾功能测试任务，那么需要非常好的平衡以下三个方面，时间，人力，收益这三个方面来触发来设计和实现我们的接口自动化测试平台，要投入更少的人力，更少的时间，看到更大的收益，不能由于被测系统发生一些变更，就导致花费了很多时间的自动化脚本无法执行。不能为了100%的成功少做或者不做校验，不能因为加上多的校验而导致更多的维护成本，然而做好这三个方面的平衡并不容易。我们笔者所在的公司就处于后者。

接口自动化的设计要从这两个方面着手展开

1、减少投入成本

1. 减少工具开发的成本。尽可能的减少开发工具的时间、工具维护的时间，尽可能使用公司已有的，或是业界成熟的工具或组件。
2. 减少用例录入成本。简化测试用例录入的成本，尽可能多的提示，如果可以，开发一些批量生成测试用例的工具。
3. 减少用例维护成本。减少用例维护成本，尽量只用在页面上做简单的输入即可完成维护动作，而不是进行大量的代码操作。
4. 减少用例优化成本。当团队做用例优化时，可以通过一些统计数据，进行有针对性、有目的性的用例优化。

2、增加使用率

1. 适用手工测试。不只是进行接口自动化测试，也可以完全用在手工测试上。
2. 学习成本低。不用学习很复杂的技能即可完成接口自动化测试，要让非技术人员可以上手做接口测试。
3. 当测试工具用。将一些接口用例当成工具使用，比如一键进件，一键清除数据。
4. 每天测试。可以进行每日构建测试。能自动触发接口自动化测试脚本，进行测试，并生成测试报告。

测试脚本和测试数据分离，将接口自动化测试用例保存到数据库中，即常见的数据驱动的做法。很多团队也是使用这样的结构来进行接口自动化，使用这种方式在以后的“推广”中，学习和迁移成本低都会比将用例写在代码中要好维护的多。

以下情况避免！！！

1. 将测试用例直接写在JAVA文件中（这样做会带来很多问题）

• 如果被测系统的架构调整，或者业务调整，修改测试用例可能需要改动大量的代码
• 代码不便于交接，因为每个人都有自己的编码风格和设计习惯。最严重的的后果就是后面接手的同学可能会推倒重做。
• 如果测试平台更换，测试数据的迁移将会非常困难，如果用例是有成千上万条，那测试数据和测试 用例的录入将会成为灾难，一条一条录，光想想都觉得累。

2. 用Excel维护用例而不是数据库

• 数据库维护用例更方便
• 实现脚本和测试数据的完美分离，更好维护脚本

如果有一个可视化的平台，知道接口地址，请求头，请求体，期望返回，在页面录入这些信息，然后选定一批用例，设置固定执行时间，每天可以看到实时测试的结果，不用再写一行代码即可完成接口测试，又假如，我不想一个一个用例的配置，我走一遍完整的手工测试，用例便录制好同步上传到平台，并通过复制，修改参数、条件，即可完成同一接口不同场景的测试，从而解放双手，提高效率，提高测试覆盖率，以及测试质量。又或者可以根据代码的if|else分支，不同的判断条件，来反向生成接口测试用例，这样，连测试用例都不用写了，当然，看技术，时间，以及人力的的投入了，说白了就是成本的投入了，并不是每一家公司都适合这样，不同方案有长有短，根据自己公司的需求，然后找到适合本公司和团队的方案才是最好的。

接下来会慢慢讲数据库设计，系统设计，源码等等，更新中