接口测试平台代码实现60:后续计划和其他平台技术系列预告

经小伙伴反应，准备调整接口测试平台的后续进度，加快主要核心功能。所以下一篇应该就是开启项目公共变量-请求头/url等的设计实现，接下来是用例的大模块。也就是之前很多小伙伴询问的，有没有多接口关联的上下文的测试用例功能，当然是有，但是要明白一个标准概念，我们目前的接口库和调试，仅仅是调试。并不能作为标准的测试用例，标准的测试用例模块当然是既可以单接口用例又可以多接口关联的用例了，从控制。执行，顺序执行，并发执行，监控轮询执行 到 测试报告/监控报告/报告统计/报警机制/邮件短信/标准测试报告word文档 等功能都需要嵌入，这和我们接口库接口调试的区别还是蛮大的。

当然根据经验来说，大部分同学/开发/测试 ，仍然会把接口调试，就当成用例。因为这样比较方便快捷。

但是这样也就是所谓的原始初始才有的思想。我们之所以要做平台，就是要树立流程，建立标准。不然都去用postman本地调一下通过就行了，谁还用平台呢？

但是标准，规范，流程。这些词组也含有着更麻烦，繁琐的负面因素。

但是我们知道：

大到人类社会/国家，从原始到奴隶到封建到解放的社会主义，文明不断的进步必然伴随着越来越复杂和麻烦的制度和规范法律等。

小到一个公司，一个部门，一个小组。从最原始的所谓敏捷开发，虽然迅速，但是也毫无规则可言，随着发展，必然会逐渐扩大，先进起来。这过程也就伴随着复杂的流程和麻烦的规范。 也就是我们很多人吐槽的大公司办事起来流程太繁琐了，其实都是这样无奈之举。

我们的接口测试也是如此，从原始进步到文明，那么测试平台有着至关重要的意义，当然能不能让大家改掉方便的习惯，来适应繁琐的平台，这是最最难的一关，很多组过不去这关，那就永远都是一个创业公司的样子。但是为什么要做到这样的繁琐呢，谁也不是傻子，没有碾压性的好处没人去这么做，所以我们要做的就是提高测试平台的功能和优点，来抵消掉繁琐麻烦学习成本等缺点，不只是抵消掉，还要达到碾压才能保证大家都用起来，这就是成功进步到下一个阶段了。

当然每次的脱胎换骨必然伴随着巨大的伤痛，不是所有人都能成功渡过，过不去的，也就永远留在了旧时代里，然后面临的就是无情的淘汰。即便你不主动，也总有人会替你做这件事。谁都无法避免的，不然就是逐渐丧失市场竞争力。

当然这个平台系列后续的功能还是不少的，大家不用着急，心急吃不了热豆腐，知识的沉淀很重要，不是学的快做的快就可以的。

最近也收到了不少小伙伴的其他学习需求，比如做数据构造平台，压测平台，白盒测试，selenium自动化测试平台，appium自动化测试平台，测试工具平台 等等。所以我准备过几天同步开启这些技术的讲解系列。因为本人还在全职奋斗在公司一线，所以节奏上会变慢很多，希望大家见谅。