2014年我在另一家公司开始了新的征程。这家公司主要是线下收单业务，所以有大量的POS机和复杂的后台作业系统。这个公司的业务特点决定了他们的页面内容很简单，但是后台接口很多，复杂的业务逻辑需要通过这些接口实现。因此，我需要一个接口测试平台。
这次我有了一个架构师来帮我实现我的自动化测试平台，Bravo！这次我画了一个PPT来说明这个测试平台的未来，这个平台将分四步走：
- 驱动与执行。平台需要能够完成基本的接口调用，能够组装请求并记录响应。
- 数据准备和验证。平台能初始化数据并在接口调用结束后验证数据库中的数据。
- 图形化界面。平台需要图形化界面支持测试人员在网页上通过拖拽的方式组装用例，通过设置检查点并以所见即所得的方式检验结果。
- 完善的用例管理。平台可以通过预设的用例生成逻辑来自动生成用例，支持用例间关系维护，并可以在运行期根据用例间关系自动安排执行顺序。
当时我还孤陋寡闻，如果是今天我会加上第五步，将用例生成和结果判断都交给机器学习（纯粹胡扯）。
用例自动生成这个事儿其实是有理论支撑的，下面这段可以不看。
作为接口测试来说，输入无非是（a0,a1,a2...aN-1）N个参数。所谓用例，就是这N个参数的取值变化。比如说，针对a0号参数，我们有k0个可能的输入，针对a1，我们有k1个可能输入，等等等等。
假设我们有一套标准的N个参数的输入值，比如说，我们让a0等于k0集合中的第一个元素K00，a1等于k1集合中的第一个元素K10，a2=K20，等等等，这就是我们的第一个标准测试用例，或者叫BVT用例。
在这个BVT用例的基础上，我们可以通过修改一个参数的值，来生成一个新的测试用例。比如说，，那么我们的第二个用例就是在BVT用例的基础上，让其他参数不变，只是让a0等于k0集合中的第二个元素K01。那么我们就得到了一个新的用例，这个用例与BVT用例的差异就只有这一个参数的取值变化。这样做的好处是，变动被限制在一个参数内，而且我们可以很方便的确认这个变化到底会带来怎样的后果，作为我们的预期结果。
如果我们每次只修改一个参数的值，让其他的参数值都与BVT用例相同，我们就得到了一组测试用例。这组测试用例我给他们起了个名字叫做N+1，N指参数的总数。
那么，我有幸读到过一篇论文，很有趣。这个论文的结论说，对于一个N个参数的接口来说，N+2的用例覆盖率就约等于N+N，也就是正交法设计出来的测试用例。通俗的说，只要每次改变两个参数的值，我们就几乎等于完成了正交法的覆盖率。
你会发现这个方法很适合自动化测试，你只要把这N个参数列出来，然后给他们分别指定输入域就可以了。考虑到大部分的测试数据都是类似的，因此你甚至可以复制一套输入，略微增删即可。然后就把剩下的工作交给机器吧，你可以让它尝试N+1或者N+2，这已经足够好了。
让我们回到我的接口自动化测试平台。我给出了一个大而全的设计，这个设计的目的是
- 让所有的手工测试逐步迁移到自动化测试平台上来，不需要再有手工测试，所有的测试都可以在自动化测试平台上完成；
- 尽可能的降低测试人员与代码的联系，测试人员面对的只有数据和页面，这样可以让他们更专注于业务和用例设计；
- 尽可能的把所有的重复性工作全部由平台完成，不仅仅局限于接口响应报文，还要包括数据源校验。
那么按照套路，我们下一步遇到的问题是什么呢？
- 测试人员看不懂接口
- 测试人员看不懂数据结构
- 测试人员不会准备初始化数据
- 测试人员懒得维护频繁变化的脚本
- 没有开发资源了！
是的，你看这些问题的顺序就可以大概猜出来我当时经历了什么。我空降到这个团队，公司发生剧烈变动，有经验的测试人员相继离职，我紧急喊来了一个测试经理来帮忙，我们两个带着三个应届生就出发了。
这三只小猫甚至不知道接口是啥，我从最基本的OSI七层模型开始讲起，一步一步带他们梳理大学学过的知识，手把手的教他们什么叫接口，数据库表是怎么设计的，好不容易我们的核心系统全部自动化了，结果我的开发资源突然没了！
你猜这个平台停留在了第几步？
这一次我的经验和教训是：
- 建设自动化测试平台跟创业没什么两样，资金链随时可能断裂！别贪多贪大，完善的设计不如马上就能跑的程序。
- 测试人员的技术水平不高，不仅仅体现在代码能力上，还体现在对系统设计、数据库设计的理解上。
- 但是测试人员对业务理解都不错，可以选择在这里突破。
第三次启航
经过了两次惊心动魄的平台建设后，我终于从这个轮回中涅槃出来，这一次，我来给你们讲一个别人成功的故事。
这位同学很有趣，她以前做过开发打下了代码基础，2016年她做性能测试并且参加了多场架构评审，这让她对系统设计和数据结构都有了了解。2017年，她第一次开始尝试将公司的一个自动化测试平台应用到本部门的测试工作中。