为什么选择这个话题？
一是发现很多“点工”在转型迷茫期都会问一些自动化测试相关的问题，可以说自动化测试是“点工”升级的必经之路；二是Google一下接口自动化测试，你会发现很多自动化测试框架相关的文章，但是大部分文章都有一个通病，就是只告诉读者how(怎么做)，很少介绍why，还有框架开发完成之后的事情（例如如何推广、维护等）。那下面就聊一聊我的接口自动化测试框架建设的一些经验和教训吧，希望能给大家一些借鉴。
工作多年，第一次听说接口测试是在《软件测试的艺术》的书上面，那时候校招复习软件测试理论，当时没有体感，甚至不知道什么是接口。第一次接触接口测试并非来源于项目需要，而是来源于团队KPI需要。当时校招刚入职没多久，团队内部有测试相关知识与技能培训（虽然只是测试工具的使用），当时接触的第一个接口测试工具是 JMeter。还记得我同事通过一个word文档给我介绍它的一些常用组件，然后就给我安排上了一个任务 - 将团队 xx 平台接口代码覆盖率提升至40%以上。当时还不知道代码覆盖率是什么，但是只晓得通过 JMeter 开发更多单接口/业务场景组合的用例就是了，于是乎就开始通过针对单接口的入参类型、边界、是否必传做各种组合，而场景组合用例就做接口间的笛卡尔积生成不同的业务流。第二份工作老板想打造一个团队内部使用的接口测试平台，当时就给我这个机会负责接口测试框架的建设。这也是第一次实践接口自动化测试框架。今天聊的故事就从这里开始。
一、为什么要自建测试框架
1.1先谈谈接口测试
何为接口？通俗来讲生活中常见的电灯开关就是接口，它接收开、关（默认）指令（值），输出对灯泡的控制结果（亮、灭）。接口测试是测试系统组件间接口的一种测试。测试的重点是要检查数据的交换，传递以及系统间的相互逻辑依赖关系等。
1.接口测试“套路”
根据我举的例子，可以知道对接口测试，从功能上可以把接口当做黑盒进行输入以观察其输出，根据不同的输入去测试其内部的逻辑，我们可以借助边界值分析、等价类等方法设计用例。非功能上要测试接口性能、安全、幂等。此外，如果所测接口存在上下接口调用的依赖，则还需要进行全链路联调测试（不部分接口不是独立存在的，都是和其他接口相互调用的），联调测试是为了保证上下联路接口之间契约的准确性。
2.为什么适合自动化
根据分层测试思想，可以将系统测试分为单元测试、接口测试以及界面测试。一般来说，单元测试就像一座房子的地基，地基打得好，房子也就比较稳固；接口测试就像房子的架子，决定房子的形态；而界面测试就像房子的装修，体现房子的外观。诚然，地基以及房子架子是比较稳定的，变化不大的，而房子的装修是可以根据心情不断更换的。大家都知道变化和成本是成正比的，变化越大成本越高，根据ROI=产出/投入，分子不变，分母越大，ROI越小，这也是界面测试不适合自动化的主要原因。当然不代表所有项目都不适合做UI自动化，如果UI比较固定也是可以做自动化的。
当然，大公司在这方面已经走在了前列了。就拿行业标杆Google来说，《How Google Tests Software》书中也有提到，70%自动化在单测，20%自动化在接口测试，10%自动化在UI测试。
3.常用的接口测试工具
介绍下我使用过的JMeter、Postman这两工具。
总体而言JMeter更适合作为接口自动化工具的，虽然官网将其定义为压测工具（The Apache JMeter? application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance.）因为JMeter几乎能满足接口自动化测试的所有诉求，有丰富的函数（类似utils）（例如生成个随机数、uuid等，这些都是测试过程经常用的能力，而且还支持自己扩展）、断言丰富、结合Jenkins做持续集成、有测试报告、有丰富的插件库可供下载等等，非常适合技术感不强的测试团队。Postman也是可以做自动化，但是我还没有实践过，平常更多将其作为接口调试的工具，不做过多赘述。
1.2自动化测试目的
本来这个小标题是“接口自动化测试目的”，提笔写的时候发现所有自动化目的貌似是公途的。我先抛出来两个论点：发现缺陷？提高测试效率？
大家可能觉得实现自动化的话，这两个目的是自然而然的。当然我不否认但也不完全赞同。那我为什么要把这两个论点拿出来讨论下呢？因为自动化测试是一个有计划的过程，不同的目的可能会有不同的实现过程，有不同的实现侧重点。
如果目的是 发现缺陷，那么自动化测试用例就要覆盖的比较全面且细致（业务层面、断言层面），这无疑会加大自动化测试用例的开发成本，所以投入过程需要重点分析业务以及多排期些开发时间。
而提高测试效率呢？当然这里的提效不仅仅体现在测试过程，而且还体现在测试者的日常工作中，类似造数据等工作内容。因此如果以提效为目标，那么自动化测试用例开发要重点分析哪些业务流是调用比较频繁的，而在断言层面也没有必要太过细致，以造数为例，毕竟提效的目的在于获得结果，只要结果符合预期就是OK的。当然，这些都是笔者个人看法，大家可以各抒己见。
1.3为什么需要自研框架？
上文也说道做接口自动化测试，当下有现成的开源工具 JMeter、Postman等可以选择，也有一些开源的自动化测试平台。但是，这些开箱即用工具也有弊端：
1. 测试工具开发的测试用例往往不易于维护，试想一下当你维护JMeter生成的各种JMX文件场景。
2. 大量的测试用例可重用性差，例如登陆模块，每个接口调用前都要获取cookie，而登陆则是前置模块，使用JMeter开发用例需要每个JMX文件都要包含登陆，重复度太高。
3. 无法满足自动化平台诉求，短期内确实可以快速实现自动化，但是这些工具对于平台非自动化能力的拓展成本较高，毕竟改动开源工具的成本比自研高很多。
4. 使用开源工具不利于提升团队在自动化技术方面的成长。自动化能力的提升离不开编程能力的提升，使用开源工具能提升工具学习使用能力，最终你的成长无外乎又掌握了一个测试工具的使用。
5. 无法最大化提升自己解决问题的能力。
1.4接口测试框架选型
· 关于语言
语言建议和负责项目的系统语言保持一致，如果被测项目语言是Java，测试框架就选用Java语言开发，结合Spring boot框架搭建。
· 关于扩展性
扩展性是非常重要的，因为框架不是一蹴而就的，是一个需要基于业务的迭代不断“更新”的，良好的扩展性，可以让你更高效的开发所需的feature。这点可以参考JMeter的架构设计。
· 关于实现方案
确定使用的技术后，务必要将的实现思路整理出来，写一个实现方案，就像项目的系分文档一样，这样对你来说具备指导意义。仔细想想，测试框架的开发，就是要求自己兼顾产研测的角色（条件可以的话，可以让产品/UI帮你设计平台草图）。
二、经验沉淀
1.计划的重要性
万事预则立，不预则废。对于测试来说，计划尤为重要。一方面测试框架建设的任务并不会允许你100%工作时间去做，因为你还有业务测试工作要负责和跟进。另一方面，老板要看结果，制定每个阶段的里程碑是非常重要的，当然计划这些会在OKR里体现的。
以我的经验，可以制定按照feature数量给自己排期，例如每周实现x个feature，这样就可以大概推出完成测试框架开发需要的周数，尽量周报里有所体现实现的进度，以及下周的todo。
2.文档必不可少
为什么文档这么重要？文档其实是另一种“自动化测试框架”的实现方式。代码实现框架本身，文字为框架“穿上衣服”。再者，文档可以节约你未来非常多的“客服”时间。文档内容范围不限，总的来说有三类：技术实现文档、使用说明文档以及问题记录的文档。
1. 技术实现文档用于描述框架实现的技术手段以及编码规范，可以在系分文档上继续补充。
2. 使用说明文档用于介绍使用方法，最好是先以快速入门为例，教大家如何利用测试框架开发一个测试用例。再详细介绍如何使用（调用）某些公共组件（工具）。当然建议录制操作视频。
3. 问题记录文档 用于协作开发的时候供其他小伙伴参考使用，毕竟你踩过的坑别人也有可能踩过。这样可以减少同类问题排查和定位时间。（笔者曾经在帮助小组同学排查问题方面就耗费了不少时间。）
3.多人协作下的开发模式
自动化框架最终的是推广给大家使用它去开发接口测试用例，以替代JMeter这些接口测试工具。在平台化实现之前，就避免不了多人同时提交开发好的用例代码。针对这个，我建议使用master\dev分支，每日的自动化用例运行使用master分支代码，而dev分支用于大家提交各自分支的代码。这就需要经常dev分支的代码合到master分支。
4.做好代码review工作
正如经验3一样，确定好开发模式之后，同样不能避免有些同学在提交代码时“乱来”（不规范开发和提交，例如随意修改别人的代码等），导致代码冲突。而作为项目的负责人，就像一个门神，要做好代码review工作。这样可以在一定程度上降低代码冲突的概率。总之尽量不要将宝贵的时间消耗在这些代码管理的问题上。
5.推广小组试用
框架开发好后，不建议急于大批量推广，建议先“小流量”灰度试用。我们大团队下面分了很多小团队，基本上业务owner带一些外包保障项目质量。而管理者注重框架的结果。框架开发者是全职员工，框架的使用者主要是外包和偏业务测试全职同学。当时搞定框架开发之后（算是1.0版本，已经可以使用），就在我的小组进行使用。这样可以先搜集一下使用效果和反馈的问题，先做一版小迭代，把他们觉得比较影响使用的问题先解决掉。
6.分享和培训
先给大家做了一次分享，演示框架操作原理，如何开发接口测试用例。为了让大家好理解，我就拿postman 的使用步骤和框架测试一个接口做类比。即使如此， 大家刚使用测试框架时候仍遇到了不少问题（也是意料之中，大多数外包几乎 0 编程经验），包括接口测试用例开发成本高，外包同学代码能力差遇到问题解决不了，不会debug代码，开发好的用例上传gitlab经常搞出冲突需要解决，每个同学用例的写法千奇百怪等等。还记得当时那段时间的内容，除了做手上的业务就是帮忙看大家在写用例遇到的各种问题。为了解决这些问题，我也挤时间编写测试框架使用说明书，对大家进行git使用培训，debug培训等，鼓励大家多学点Java，多读读《Java编程思想》。
7.注重大家的使用反馈
使用反馈是非常重要的。因为它是你进行版本迭代的驱动力。其实就和产品做项目一样，每个版本都要分析用户的使用反馈，根据反馈进行版本优化和迭代。可以和使用者沟通，发现一些他们使用过程的痛点。当然这只是第一步，更重要的是要有解决方案。
8.考虑代码生成
针对用例开发成本高的问题，我通过在测试用例开发过程总结到HTTP不同请求方法对应的接口测试写法不一样，同方法的测试接口写法几乎一致，突然想到可以使用模板（freemarker）自动生成接口测试用例，然后我就整理几种接口测试用例生成模板（post、get等），这样大大降低测试用例开发成本，大家更多在于测试数据的准备和断言。
个人觉得代码生成是每个测试框架设计的必须考虑的点，因为像postman、jmeter等这些工具本质上和你开发测试框架是雷同的，如果做到用例之间可以相互转化，可以提高用例的可迁移性和复用性。
三、教训总结
1.缺乏自动化效果的统计&度量
上文说了，相比过程，老板更看重结果。如何体现结果，那就是要有数据统计与度量。记得被开发挑战过，你们搞得自动化发现了多少缺陷、节约了多少时间等问题。这块当时做的不好。
1是框架本身还没有平台化，当时实现的功能是测试用例开发模块的实现，统计数据没有落DB，这块需要靠人工统计比较费时间（当时为了统计自动化用例运行结果数据，在Jenkins服务器上捞日志，简直是痛苦）。
2是当时没有明确的度量目标，像节约了多少时间这类，确实难以衡量。
现在我觉得当时的框架设计之初是遗漏了这个问题的，建议后来者可以将测试数据都落DB。
2.没有对测试进行测试
这个主要是没有对测试框架本身进行测试，特别是多人协作开发模式，单测尤为重要，单测在一定程度上是保障代码质量的手段，可以有效避免部分同学“乱改”别人的代码。当然，如果时间充足，建议对测试框架写单测。
3.自动化用例开发计划没有突出侧重点
这个也是教训1的一个原因。框架完成之后，我们就在okr里计划xx完成接口100%自动化覆盖，刚开始阶段没有对被测接口重要性做分析，导致没有将时间花在核心的接口用例开发上，也间接导致产出不高。
现在想想，其实是计划不明确且没有突出重点的问题，颗粒度还不够，现在的建议是大家要优先实现核心接口，这些接口流量大，更容易有产出。不要为了追求覆盖率而本末倒置。
4.断言的不完善
当时的框架没有开发DB checker，所以断言全靠http 响应，其实这样的用例是质量不高的，也就是测试预期不全面，可能会存在漏网之鱼（遗漏缺陷）。
建议大家一定要断言模块重点考虑到。包括http层面（响应时间、响应码、key字段断言、状态码等）、DB层面（key字段值比对等）。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
