服务端测试现状
笔者从事服务端测试，业务涉及接口测试、性能测试，我们聊聊接口部分。当业务变更需要你去回归一个接口时，种种原因你并不是很清楚每个字段的含义(构参)、是否必要，而且文档总是那么残缺，那么这时候就要去频繁沟通，成本巨大。时间紧的话，回放线上所有用户真实操作或许是个折中的选择。虽然没有覆盖各种异常场景，有些服务更是每次上线都需要做全量回归，活多人少，一人负责十几二十个服务，维护成本巨大。鉴于此，笔者琢磨了一套方便构造参数、管理参数、发起请求(支持转发)，全量回归(不那么复杂但很实际)，结果校验的可视化接口平台，取名apici：接口持续集成，形体初成后发现还可以做各种衍生。
apici解决的问题
- 参数构造透明方便，维护成本低，可持续集成
- 省掉重复的接口调用代码，专注于业务测试，提高效率
- 降低初级qa的学习操作成本
- 多接口多场景、全量回归方便高效可复用
- 请求转发机制：环境由你控制
- 数据更新规则可配置
- json结果配置式校验<生成对应测试报告>
针对以上问题，apici的设计考虑到了以下几个方面
首先，参数构造数据来源：无需使用者手动生成，解析nginx日志或者记录fiddler里面你的操作记录，非常便捷，打开即用。
其次，要保证数据的唯一性，’同样’的数据不能重复存在。这就要求入库时候需要有默认规则，并且支持使用者编辑数据入库规则。举个例子，你想知道用户注册来源的from字段有哪些具体的值，这时候就可以使用这个配置。
最后，apici具备了这些基础功能：
- 为了达到更可信可用，我们在入库的时候，就加入默认的服务端识别的登录信息，保证每条记录都是独立可执行的
- 为了更方便的结合需求，我们实现了用例集的概念，更方便的整合测试范围
- 所有的测试都需要对结果做校验，现在绝大多数服务都返回各种json响应，我们也开发一套通用的json校验模块
- 众所周知，请求需要对应多个环境，所以我们把apici定位为数据平台，提供请求转发的能力，想让请求到达那个环境由你简单控制
- 对内提供开发接口，供大家获取数据
- 把部分复杂-多样性数据提供给自动化测试用例
架构图
衍生的新实践
在实现了这些功能后，我们也发现了更多好玩有趣的东西，和大家分享讨论一下，或许你有更好的idea
- 发现了一些单词拼写错误，比如oginCausePage就是个明显的错误，全面解决这个问题对apici来说就是小菜一碟
- 协助发现一些危险行为，一些简单的页面注入行为，都会体现在apici平台，方便安全部门查找
- Fiddler导出特定请求的能力是可以开放出来提供给所有互联网从业者的，数据导出后，你就可以做很多你想干的事
- Json校验以及对于测试报告也是可以开放给大家共同开发使用的
最后，简单说一下apici的未来规划
- 定时任务监控线上线下服务可用性，毕竟运维不总是能监控到服务内接口的可用性
- 增加函数式编程支持，动态生成参数值
- 支持定制工作流(类似jmeter)，满足复杂业务场景测试
apici目前的应用
- 接口diff数据源
- 性能测试平台接口数据源
- 部分上线需求的业务回归
- 自动化测试数据源
立意高远，决胜千里，站在上帝视角看待问题，更多好玩有趣的等你探索！如有更多观点想法，评论区等你~
