不同纬度的造数方式
从创建测试数据的纬度看，测试数据的准备主要可以分为三大类：
- 通过GUI操作生成测试数据
- 通过API调用生成测试数据
- 通过DB操作生成测试数据
这三种方式都有各自的问题：
通过GUI创建测试数据的效率极其低下，以咖啡的配送用例为例子，为了测试这个用例，QA需要到客户端去下一个外卖订单，再到门店端去咖啡师制作完成，最后才到配送端接单配送，这一过程跨了多个端通过GUI需要多个APP甚至多个设备间切换，效率低，操作繁琐。
这时有人可能会问，那我可以把这些操作封装到一个方法内呀！
我劝你别，干过UI自动化的同学都知道，UI自动化的不稳定性，所以不适合封装成测试数据工具，这类工具创建数据的成功概率不会太高。
通过API创建数据，能解决GUI的不稳定和效率低的问题。但并不代表通过API创建数据就完美了， 它同样存在不少痛点，如同样配送用例的案例，通过API造数，尽管你不需要拿多个设备，但你依旧需要跨多端，你需要按一定的顺序依次调用多个API，如果需要频繁使用或需要造出批量数据时，依旧是非常麻烦的事情。
再举个单API的造数场景，创建用户，一个API可能需要传入用户的N多数据信息如邮箱，姓名，体重，身高等等信息，入参的Json字段可能多达几十个，而造用户的场景我可能只需要一个正常用户ID，我压根不关心用户的具体信息，但每次调用这个API来造数，还是得多个入参，一个不落的编辑入参。
这是自动化同学可能又会跳出来，那我可以把这些操作封装成一个方法呀！
对！思路是对的，多个API调用封装成1个方法，简化调用。 复杂API封装成一个方法，简化入参，如创建用户API封装成方法后，你可能只需要传入用户ID就足以，别的参数都默认值或随机值便可。
思路是对的，但不代表就能广泛推广使用，毕竟你封装成方法通常只给你自动化测试使用，你想给QA手工测试或者性能测试使用，那就得封装成restful API甚至做成一个带有GUI的工具，那这就大大提高了门槛，毕竟并不是所有QA都会前后端开发。
再来聊聊通过DB生成测试数据，他的优点跟API基本一样，效率高，稳定，但是最大问题是容易产生脏数据。特别对于一些复杂业务，多表关联的容易某张表漏了插入或者更新。
所以真实情况下，我们通常是综合使用1-3种方式创建测试数据，特别是综合利用API和DB方式生成测试数据。
不同时机的造数方式
从创建测试数据的时机看，测试数据的准备主要分两种：
- On-the-fly，也就是实时创建。 需要测试数据时，实时的通过工具或者代码中创建，这种方式适合绝大多数场景，特别是自动化测试基本使用这种方式，但是需要数据量大时就不合适这种方式，因为比较耗时。
- Out-of-box，也就是开箱即用的方式，指在准备测试环境时就预先对需要用到的数据全部准备好，这种方式适合需要大数据量的测试场景，例如性能测试。同样也适合其它需要预先准备数据的场景，但这方式也容易产生“脏数据”，数据是对的，但是可能最后没被用到，也可能数据有时效性，还没被用上就已经状态过期或被无意识被更改。
所以真实情况下，还是不同场景不同分析，综合运用 On-the-fly 和 Out-of-box。
了解了上面文纠纠的方式后，那我们希望我们的造数应该是什么样的？
应该高效、稳定、简便、门槛低、能灵活的使用API和DB、并同时支持实时创建和预先创建。
再来看看我们为了达到这个目标，我们都做了造数都经历了哪些方案。
造数1.0
通过Postman、Jmeter等工具串联API。
Postman方案相信目前是最多QA使用的的方案，把多个API串成一个场景，灵活使用环境变量、全局变量等，做好接口与接口之间的数据传递，造数时逐个API调用或者使用Runner功能，如果需要加入DB操作就改用Jmeter。
这方式不便于多人协作和共享， Postman 和 Jmeter 生成的脚本文件都是本地文件，多人协作需要互相传递合并等，不便于集中管理，同个造数场景可能A B C 同学本地都自己写了一套。
无法给自动化测试使用，自动化测试的数据更多需要实时生成，而不管哪种开发语言都不方便去调用和修改Postman、Jmeter生成的脚本文件，所以通常自动化测试得额外再搞一套。
同时通过Postman 和 Jmeter 并没办法去简化入参。
所以这个我称之为1.0时代。
造数2.0
因为1.0时代，存在不方便多测试共享和没办法简化入参问题，我曾经在运营测试团队尝试过解决这个痛点，所以也就有了当时的鲁班平台。
鲁班平台后端把原本在Postman、Jmeter配置的调用链，封装成一个对外的Restful API服务。 为了简便，在封装过程中尽可能使用默认参数，并提供了UI界面方便操操作。
1.0的痛点得以解决，但又有了新的问题，因为业务不稳定经常变动，这样就造成封装的API需要经常改动，而这个往往就我一个人能去维护，并且如果QA想自己添加一个新的造数场景，那么对他们来说还是门槛过高，至少得懂点Sping Boot 等。
所以这个阶段我称之为2.0时代，解决了多人共享、多测试共享、简便了使用，但是门槛高了，能参与的人就少了。
造数3.0 - OTP 造数中心
问题驱动！发现问题就尝试去解决问题。
那 OTP 造数中心就应该同时满足：简便、高效、稳定、共享、低门槛
低门槛
OTP 设计过程中保留了Postman、Jmeter 类似的界面化配置调用链关系，且保留变量的概念，整个过程中完全不用涉及到代码的编写(Json除外)。
简便
能快速创建
调用链的接口可以直接从API管理中快速导入，生成基础模板，并可以任意修改。
简化入参
简便除了上面的能快速创建场景，OTP 造数中心还努力做到如简化入参，一样拿创建用户为案例，看看OTP实际操作可以怎么简化入参。
创建场景：
创建这个场景时，我们发现如果我们需要通过开发提供的API来创建一个用户，该API只会做 telephone 和 empLoginId 两个字段是否唯一的判断，那我们就把这个两个字段设置成 全局变量的随机数，同时为了支持多环境我把创建了一个叫 url 的参数，并设定默认值和可选值，并给到入参给到请求调用时使用 {{url}}。
场景运行：
OTP 平台提供了场景运行的方式，用户根据需要可以任意次数的运行，每运行一次就生成一条用户数据，提供多次运行也就是为了满足需要批量数据或者性能测试数据时，使用，而这个界面化的场景运行既能满足手工测试的 On-the-fly，也能满足性能等测试场景的 Out-of-box 。 
结果查看
高效、稳定
OTP 造数中心的场景设计中，不支持不稳定GUI造数方式，而是采用更稳定和高效的 API、DB，并且比起原本的Postman，OTP支持RPC类型接口和DB的交互。
共享
多人共享
OTP 本身就是B/S架构，多人多团队共享只要控制好权限便可。
造数中心，目前只要是能登录平台的用户，就可以去执行造数场景，生成想要的数据，同时如果是非当前测试库下的用户，做了场景CUD的权限控制。
测试共享
OTP 除了提供平台上GUI执行方式，同样对每个场景也提供了单独的API，API的路径再创建造数场景时自行填写，如刚创建用户场景的 /otp/createUser，
那么这个场景创建完成，可以在场景列表看到这个场景对应的API 信息（URL 和入参模板）：
有了这个接口后我们可以直接给自动化测试代码或者其它地方调用，既解决了多测试共享也解决了自动化测试要求造数的实时性 On-the-fly 。
postman 调用：
从postman 调用上看，如果我们想创建一个用户，不再想以往传入一个 用户长长的Json串， 而是只有1个入参 url (execEmail默认入参用于后续统计谁调用等)
后记
OTP 的造数中心，目前来看同时同时保留了1.0，2.0的优点，但2.0时代还有个优点就是通过代码方式足够自由，而通过工具平台简便化的过程中或多或少会有一些约束，OTP造数中心在设计时充分考虑了跨测试库，跨系统，跨类型的接口组合，甚至后期的场景套场景等，所以在简便和自由中找个平衡点，在尽可能简便下，也尽可能给用户更多自由。 但理想可能还是会被现实狠抽几巴掌，所以多使用，多反馈，共同探讨，共同建设。
若有收获，就点个赞吧
0 人点赞
