导读：GoAPI平台是专注于API接口生命周期管理的工具类平台，功能涉及API接口管理、测试、监控、Mock、造数等，采用微服务架构设计，支撑每日千万级的用例执行，千条用例控制在10s内完成执行。平台从开发至今已有两年，在考拉、严选、云音乐、新闻、有道等产品有都有了相应的落地，也被集成到网易轻舟微服务平台中。本文由GoAPI意在理清GoAPI平台在业务测试中的定位，可以从哪些方面入手，才能切实的提高接口自动化的收益。
作者：吴桐，网易杭研质量保障部测试平台开发负责人
一、从最初的愿景出发
时间回到2015年下半年，当时负责URS系统相关的测试工作，URS是为整个网易集团提供账号登陆和验证的系统，提供服务的方式以接口为主。虽然当时杭研接手URS系统已经一年多，但由于系统的架构设计已经过时，加上业务代码上本身存在很多黑洞逻辑，导致时不时还是会出现一些线上故障，系统改造和运维难度都相当大。但移动端账号、登陆验证码等新形式业务需求出现，迫使改造又势在必行，于是处于新老系统过渡期的URS，对接口自动化能力是有很高要求的。
屋漏偏逢连夜雨，URS接口有数百个之多，有些接口维护在一个Word文档上，有些接口甚至没有文档可查。于是URS的测试当时恶补了一波接口自动化用例（用例约1700多），通过TestNG+Jenkins的方式来驱动自动化回归和线上接口监控。
实际落地了一段时间后，发现这套方案存在如下痛点：
1、用例失败时，定位排查问题非常耗时，缺乏直观定位问题的手段和必要数据
2、无法灵活的组织各种粒度的自动化回归集合
3、当业务发生变动，维护成本指数级上升，发生人员变跟时，自动化交接成本大
4、开发同学无法直接参与到接口自动化自测中来，线上监控效果不理想
5、无法直观的评估自动化的效果和覆盖度如何
为了解决以上痛点，再结合项目中各个角色的述求，希望能够有一台行之有效的接口自动化解决方案来解决，从项目中各个角色的视角来考虑，对平台有一定的期望。
1、测试的视角：希望用例编写成本足够低，维护足够方便，用例能够可视化管理，可灵活在各种环境执行自动化用例；
2、开发的视角：希望接口能够有组织有规范的维护，可以一键执行接口冒烟测试，定位问题时请求返回等数据足够清晰；
3、运维的视角：希望系统发布时，减少人工验证的介入，线上服务能够定时的从用户视角进行监控；
4、管理者的视角：希望直观的看到接口自动化覆盖的情况，定期执行的报表统计，线上接口问题的跟踪和结论汇总等；
综合以上因素，从2016年下半年，开始筹备接口测试平台设计与开发，并且很快就有了第一个原型版本，当然后面经过多次重构是后话了。 上面就是GoAPI平台被设计出来的背景，接下来就开始介绍我理解的GoAPI的最佳实践。
二、团队使用GoAPI平台第一步应该做些什么？
很多产品在使用GoAPI初期走了不少弯路，据本人观察，绝大部分原因是：刚开始接触平台就全产品线大力推广写用例，追求用例数量和自动化覆盖度，没有从全局的角度规划平台的使用，平台不是本地工具，平台和工具最大的区别就是协作性，因此平台应该有组织有规划的去使用。因此初次接触GoAPI平台，个人认为应先做如下事情：
1、小范围内试用
从产品中抽出一个业务模块，开始小范围试水，在测试、预发、线上等环境将接口-用例-场景-执行集-监控整个流程走通，记录使用过程中遇到的问题，发掘不能满足当前业务场景测试地方，有没有替代方案等。
2、制定一套标准
在大规模推广使用前，制定标准和规范，例如：用例命名、公共参数、校验准则等，避免各个小组标准不统一，导致认知上存在差异，致使平台数据管理混乱。有新人加入时先熟悉标准和规范。
3、专人负责，自上而下的整体推进
随着各个团队组织结构进一步扁平化，产品团队被分割成多个小团队，虽然每个团队内都有具体的测试负责人，但经常会出现团队间信息不对称，需求、遇到的问题被各个小团队重复提，所以还是有必要搞一个虚拟组织并指定一个专人来跟进接口自动化，主要负责跟进使用情况、标准和规范执行情况、需求汇总等工作。形成自上而下的推进机制，各团队内外驱动并行。
4、建立明确的惩奖机制
虽然有规范和专人跟进，但在各个团队和个人落实的时候也可能会低于预期，例如：有些接口线上已经下线，单发现平台上的自动化还在跑，没有及时下线，导致线上监控一直报警。因此应该建立一个明确的惩奖机制，定期对落实得好的团队给与适当的小奖励，对落实得不好的团队给与适当的“惩罚”，例如罚请全团队的人喝杯奶茶之类的。
古人云：凡事预则立，不预则废。规范和维护成本成反比，和自动化收益成正比。接下来我们就来重点讨论一下应该制定哪些标准和规范。
三、应该制定哪些标准？
标准是用户约束用户使用边界，更好的规范平台的数据。本节所讨论的标准都是基于个人经验和认知，另外参考了平台上部分产品的实践。产品团队在实际使用过程中还是要根据实际业务类型来制定相关标准。
1. 目录组织标准
平台最多支持三级目录，产品空间：一级目录--二级目录--三级目录，接口可以挂载在2、3级目录上，这样设计是综合考虑了接口组织和交互易用性之间的平衡。一般情况下目录结构推荐以下两种方式：
o 按业务结构划分：模块--子模块--功能 （例如：营收模块--会员营收--订单）
o 按开发团队划分：团队--业务--功能 （例如：仓配团队--物流管理--引擎）
目录的命名应该和以业务功能为导向，避免出现某某人的接口目录、xxx日期的接口目录这样命名，禁止个人随便定义一级目录，应由整个项目组协商一级目录的划分，二级和三级目录由各个小团队自由定义。
2. 接口定义标准
这里并不讨论接口本身的规范（例如参数命名规则，接口路径如何定义等等），这是业务开发时应该注意的事项，这里主要讲平台上如何定义接口会让团队收益更高。
o 接口的优先级要正确的标识，核心接口是P0，其他接口按优先级可以分为P1\P2\P3，一时无法确定优先级的，可标识为N，明确每个接口的优先级，可以指导测试自动化优先覆盖哪些接口，回归和监控时应优先采用哪些接口下的用例等。
o 响应信息要完善，若存在业务状态码，应填写每个状态码代表的意义，响应信息完善可以有效的指导测试用例的设计，减少漏测或者误测的情况。
o 整个产品下，确保相同的接口只被定义过一次，有些项目经常发现有些接口被重复定义，这样会导致项目中的各个角色不知道应该参考哪个才是最新的，所以应该避免这样的情况发生。
3. 用例编写标准
用例分为单用例和场景用例，单用例是最小单元，挂载在接口下面，一个接口下可以挂载多个单用例，场景用例直接挂载在产品目录下，将单用例和场景用例放在一起，就组成了执行集。
o 用例必须校验，无论是单用例还是场景用例中的一个步骤，都必须校验，没有校验的用例就像没有上链条的自行车，当然还可以根据具体的业务类型设置一些强制校验点，例如强制业务code码等。
o 用例必须有标签，一个接口下的用例得区分线上还是线下，这样做可以方便的统计出这个接口在各个环境的覆盖情况。
o 用例的命名应体现测试要点，用例名不仅仅是一个简单的标识（经常会看到“case1”、"case2"这样的命名），而且还充当了简单文档的作用，团队中其他成员看到用例名就应该知道用例大体的作用。
o 用例的覆盖尽可能全面，例如覆盖不同客户端版本、覆盖正向和反向用例等，这是从测试全面性的角度去考虑，一般正向用例用于冒烟、上线发布等场景，反向用例体现了测试深度，在平时版本测试中使用较多。
o 场景用例中慎用等待时间，尽量避免场景用例中使用过长的等待时间，因为对于线上回归和监控来说，过长的等待时间会拖累整个执行集的执行效率。
o 正确设置执行集类型，例如：线上回归、测试过程，这样做可以准确的知道这个执行集的用处，另外在CI过程中也可以根据类型+模块的方式来批量触发对应的执行集。
o 尽量避免创建“巨无霸”执行集，有些产品将整个回归集放到了一个执行集中，导致执行集中有上千的用例，这样做至少有3点坏处：维护起来不方便 、无法按业务模块单独执行 、执行时间过长，建议将执行集按具体的功能模块划分开。
4、测试数据标准
影响自动化稳定性的两大因素是环境和测试数据，测试数据的管理好坏，会直接影响用例的维护成本。一般测试数据的管理有如下建议：
o 用于自动化的测试数据应该和手工测试数据保持独立
o 模块间如果用到相同的测试数据，应尽量使用两份
o 测试环境、预发环境、线上环境的测试数据要隔离
o 只读测试数据应和状态有改变的测试数据分开
o 线上环境测试数据要避免干扰正常用户行为
测试数据使用完应恢复到原始状态，尽量避免在环境中留下垃圾数据
四、该不该引入流程？
答案是肯定的，应该引入流程来指导用户使用平台。每当提到流程时，可能脑海里浮现的都是繁文缛节、人浮于事、效率低下等字眼，但根据本人经验，让平台发挥了很好价值的产品都制定了很好的流程。前面也提到了，工具和平台最大的区别在于协作性，一个人能把平台使用好不代表一群人能把平台使用好，这是1+1小于2的问题，因此要实现1+1大于2，必须制定很好的流程。
o 接口开发流程
开发新的接口前，开发同学应先定义好接口，然后前端同学根据接口mock数据联调，测试同学根据定义开始写用例，保证整个开发过程中所有角色都是“并发”的。接口开发完了，开发同学应该先在测试环境调通接口，前端同学拿着真实接口联调，然后测试同学再介入做进一步测试。
o 冒烟测试流程
新功能或者新接口提测前，应该先经过冒烟测试，冒烟测试用例由测试同学提供，并放到一个执行集中去，开发同学将最新版本发布到测试环境后，应先先自行触发一下冒烟测试，完全通过或再交由测试同学测试。
o 用例修改流程
如果由于业务发生变化，需要修改用例，应该先确保该用例是否存在于执行集中，如果存在，应确认改执行集是否由于接口业务监控，如果用于监控需先和相关的团队成员沟通好，暂时下线该接口，然后再修改该用例，用例修改完成后要在各个环境测试通过后，再通知相关人员恢复执行。这个流程在一些公共用例的维护中非常有效。
o 执行集失败处理流程
对于任何稳定的执行集一旦失败，测试人员应先初步定为问题，如果排查出问题所在，应在失败处理流程中添加失败原因，如果自己无法排查应找到对应的开发同学定位，直到找出问题所在。如果改执行集用于线上监控，执行失败时，应该先将状态改成处理中，确保报警不会再不停干扰，然后再拉上相关的团队成员一起定位排查，最终在流程中填写失败原因。
五、如何高效支撑持续集成？
持续集成理想的状态是尽可能减少人工介入的情况下，利用各种自动化手段完成从代码提交、验证、集成的整个过程。既然强调持续，那么整个流程应该是高频的被触发，时间是一个敏感因素，如果整个流程跑完需要数小时，那就无法去谈持续谈敏捷。接口测试属于持续集成中的一环，自然这个环节不能拖累整个持续集成的进度。
o 少即是多
加入持续集成的接口不是越多越好，接口多和收益高并没有直接正向对比关系，相反接口多和执行速度倒是有反向对比关系，接口多甚至还会影响稳定性，因此建议加入持续集成的接口应当是核心的、稳定的、人工介入成本低的。
o 有针对性
一次持续集成往往是一个和多和模块的集成，触发的执行集应该也是针对这些模块的，平台上的执行集可以标注模块，可以通过OpenAPI传入模块参数来触发对应的执行集。不建议每次集成都把整个系统的所有执行集都执行一遍，会增加执行时间和引入其他不稳定因素。
o 可并发
几个项目组可能都会依赖某个公共模块，每次触发持续集成都会同时触发这个模块的相关接口，那这个模块的接口自然就成了瓶颈，因此为了减少相互间调用的影响，该模块的接口应该是支持可并发执行的。
六、如何提升接口自动化效率和收益？
关于自动化，业界有这样的观点，“假如某项工作是一次性的或者极低频的，完全没有必要做自动化，因为自动化的投入可能远大于获得的收益”。但是对于接口测试而言，却是每个接口都值得去做自动化，只要做了都会有收益。
个人对接口测试可能会有两个误区，认为要提高接口自动化收益，应该尽可能的提高代码覆盖率，尽可能多的发现问题。个人觉得以下这两个角度不可取。
o 迷信代码覆盖率
随着互联网业务的发展，系统架构设计和以往有很大的区别，传统的单体+集群架构已经逐渐消失，更多的是分布式+微服务架构，随着容器化技术逐步成熟，更是助推了微服务进一步发展，一个接口的调用，在后台会涉及到多个服务模块，每一次请求经过的链路也不一定相同，对于推荐系统、算法系统等等更是没有参考意义，所以通过覆盖率来评估接口测试能力是不现实的。接口测试中引入trace倒是可以协助问题定位
o 迷信自动发现bug
关于测试自动化的功效，我一直持这样的观点：1%用于发现bug，99%解决重复劳动的问题。自动化是团队提效的利器，是支撑项目快速迭代的基础设施，如果从发现bug的维度去做自动化， 千方百计设计的自动化用例可能还没简单的人工点一点发现的bug多，而且随着业务不断变化，自动化维护成本还会不断增加，那么团队的研发效率始终是无法提升的。
那么在朝些方向努力会显著提高接口自动化收益呢？个人觉得从以下几个方面入手：
o 推动开发接口自测
提测质量直接决定了后续测试效率和上线速度，以往保障提测质量都是丢给开发同学一批手工测试用例用于冒烟测试，开发同学测试完了标注一下测试通过，但却无法衡量在真实的测试环境中是否真的测试通过了，GoAPI将接口测试可视化后，开发的自测效果变得可以度量，另外自己预先准备测试用例，也不会给开发同学增加太大的负担。
o 环境自动化验收
随着业务不断发展，团队需要不停的调整测试环境，线上需要经常做业务节点扩容，一些中间件会版本升级等等，环境调整后如何评估达到可用标准，以往的做法往往靠运维同学去检查一下服务状态，或者测试同学手工简单的测试一下。通过已经自动化好的接口用例来验收环境能够显著提升环境的可用指标。
o 支撑发布自动化
产品迭代过程中，发布是非常频繁的，针对某些模块的发布一般采用灰度发布的方式，如果中途出现异常情况就快速回滚。但有些时候回滚后还是会导致系统中出现一部分脏数据，因此通过离线发布-->接口自动化验证-->灰度上线的方式来发布，能够很大程度保障上线的可靠性。对于后端的rpc服务，GoAPI平台也能提供点对点的验证能力，并且提供了OpenAPI接口，要是能够打通发布平台，整个自动化的收益是很明显的。
o 线上业务监控
目前大部分监控系统都是基于系统层、应用层、网络层的监控，却没有从模拟用户行为的角度去监控。GoAPI平台提供端到端的监控能力，可以模拟实际的业务场景来监控，算是对现有监控系统的补充。
七、发挥数据的力量
最后讨论一个与人性有关的问题，记得上大学的时候，体验过很多背单词的软件，发现功能都很棒，但是用一段时间就渐渐的失去了兴趣，很难坚持下去。后来背单词软件的产品经理似乎也意识到这个问题，采用了一招很有效的方法--持续记录数据，每天设定的目标完成情况都被记录下来了，采用小组学习的模式，组员相互点赞，相互鼓励，可以分享到社交软件上。每次看到小组中其他成员每天都在坚持，仿佛有很多双眼睛在盯着自己一样，促使自己不断努力不断坚持，产生一种挑战自己、超越别人的愿望。这种心理效应其实就是著名的霍桑效应。在这个过程中，数据起到了关键作用。
映射到GoAPI平台的使用上，项目成员每天在平台上的活动都是可以量化成数据，工具平台使用一段时间后，容易让人产生枯燥厌倦感，假如某个用户每天的产出能够受到大家的关注和赞赏，会提升该用户的自信和使用平台的积极性。具体的做法就是，搜集用户成员每天数据，让项目中每个成员都能关注到，甚至对做得好的同学有些小奖励，会极大的调动大家使用平台的积极性，形成一个良性循环。PS:平台已经提供了这方面的接口，可以利用起来。
作者简介：吴桐，网易杭研质量保障部测试平台开发负责人，在服务端测试领域有丰富的经验积累，对测试环境治理、异常稳定性方面有完整的落地方案和实践。主导研发了GoAPI接口测试平台、网易故障演练平台等，GoAPI平台以接口测试可视化为核心，不断提升平台体验，优化架构和性能，从单体系统改造成微服务架构设计，支撑每日千万级的用例执行，千条用例控制在10s内完成执行，并推广至各大BU，在云音乐、严选、传媒、有道等项目中被广泛使用，改变了大家对接口测试的认知，提升了自动化在项目中的收益比。
来源：网易云