关于我如何使用一个工具让前后端和领导傻眼的二三事（篇一）
说在前头
大家🐒啊，我是小🍬，小伙伴们一般都叫我苏苏。我在软件测试行业有5年的经验，目前是一家小公司技术部门的测试主管。在社会上，特别是技术圈，大家会有刻板印象：测试工作的含金量不高。因为大家觉得测试不重要，导致给测试的薪水也偏低；这又反向导致好的人才不想来测试行业，测试从业人员的平均水平、工作体现的价值也一直起不来。恶性循环了属于是。所以我也想通过这篇文章，来分享我的一些实际经历给测试同学们（特别是打算入行、已入行的新人）作为参考，期望大家能够更好的完成自己的测试工作，能力更强、更有价值。
工作面临的挑战
我一共有两家公司的工作经历，第一家公司是做 B 端软件的公司，老板只关注能否成功销售产品给客户，对于企业员工在使用过程中遇到的问题不关心（客户的老板也是如此😅）。所以我的工作内容和挑战性都很少，只需基本点过产品的主流程即可。
在第一家公司工作了1年后离职，然后加入了我的第二家公司，一直持续到现在。这家公司主要从事跨境电商业务，在他们的技术团队只有不到 20 人的时候我就加入了。因为业务扩展和产品复杂度的增加，测试团队的人数逐步扩大。由于我一直坚持下来，还愿意主动学习和提升自己的工作能力，而且领导认为我的工作成果也还不错，所以在第2年时我晋升为测试主管，负责管理整个测试团队的工作和产出。目前，我的测试团队比较稳定，一共有 5 个小伙伴一起奋斗。
我们的业务主要面向海外用户，提供网购服务，目前用户量在十万级。现在的系统是分 web 端和管理后台。web 端面向 C 端客户，管理后台面向内部运营人员，主要管理库存、物流、商品信息等数据。我们测试的最重要目标是确保每次迭代的质量，解决所有的迭代 bug 确保迭代发版没有问题，同时确认线上 bug 能够及时发现、跟进和处理。
其实领导还希望我们测试团队能够做到自动化测试、产品监控、可视化测试、持续集成等高级测试工作，更高效和有价值的产出测试结果，确保产品稳定。但由于测试人手本来就不算充足，小伙伴们的能力又参差不齐，部分同事仅做黑盒测试，少部分可以编写简单的接口测试脚本。所以测试工作非常繁忙，又没法找更多的高级测试人才，只能维持现状，这些高级需求一直无法推进。
目前只能做最基本的功能验证测试，确保主流场景可用，很少时间和精力去覆盖更多边界情况。我会挤出时间用 Postman 写自动化测试用例，会尽量确保上线前跑过一遍，但上线完之后才有时间来写自动化测试用例也是经常的事。在这种工作方式下，虽然能基本保证线上产品不会有太多 bug，但还是存在很多的问题：
- 定位调试效率低，测试同事需要截图反馈给研发，研发再通过截图一个个去定位问题，反复确认沟通成本高，导致 bug 修复周期长。
- 回归测试重复劳动大，每次迭代都要完全重新手工验证一遍所有流程，大量重复操作，效率很低。
- 自动化测试覆盖面窄，只能依靠个别能力强的同事使用 Postman 等工具编写部分用例，但无法推广，大部分同事编写用例困难，所以自动化运行的用例有限。
- 编写用例需要耗费大量时间精力，同事们需要编写多接口复杂的用例以及脚本代码，实操难度大，许多人试着写了几次后就放弃使用了。
所以总得来说，在工作过程中最大的挑战和最难受的点主要有下面两个：
- 测试时间赶。当前，我们的迭代周期非常紧凑，每周二前需确定下周上线的需求，然后疯狂地赶进度。测试同事只有两天时间编写用例，之后就要立即投入测试验证和 bug 修复，一直到下周二在灰度环境回归&发版。
- 加班严重。有时候产品经理临时加紧急需求，我们不得不打乱原计划，停掉其他工作来处理插入的需求，全力以赴确保紧急需求如期上线。经常需要加班加点，我和我的小伙伴怨声载道，感觉完全没有自己的时间，满脑子只有工作，到了周末难得一天两天休息也只想睡觉。
因为以上的各种情况，导致测试团队工作压力大、没法抽出时间总结、复盘和学习来提升自己效率；没法解决问题和提升效率，又导致了工作压力大没有空余时间。我也知道目前测试团队存在这个恶性循环、问题的核心是提效，但是很久也没找到一个实际可行的解决方案，来从这个情况中帮大家解脱出来。
初步试用&上手生产力工具
有一次我跟几个大学同学周末一起聚餐，吃饭时聊到了自己工作的事儿，我就跟他们吐槽了我目前的现状。有个也是半路转行测试的小伙伴就告诉我说他们公司现在在推使用 Apifox 来做自动化测试。他说这个工具很有意思，他们后端搭好全部的接口数据居然只用了半天，然后调试工作就逐渐全从 postman 转过来了。后来有一天开技术评审会，有一个后端直接在会上把一个新需求的新接口文档定下来并且展示出来了，效果很好震惊了他，所以他也立刻装了个 Apifox 然后加入了后端的团队里开始用。他发现测试人员用这个产品的门槛也非常低，接口文档后端都定义好了，测试可以在自动化测试直接复用，再也不用很低效的复制乱七八糟的接口请求参数等东西到 postman 来测接口和流程了。而且功能比 postman 还要强大，强烈推荐一下。
听他说的挺神的，虽然有点怀疑，但是反正现在我自己工作的问题也客观存在，而且他说门槛低上手快也确实打动到我。之前没有去学使用 jmeter 的核心原因就是上手确实没那么简单，安装各种环境就比 postman 开箱即用的体验差多了。所以我想可以我自己先试一下看看。
第二天中午起来边刷剧边吃外卖，吃完就开始捣鼓一下昨晚大学同学推荐的工具。搜索、下载安装都跟一般软件一样，安装好了之后点开就可以登录使用了。一般学习一个新的产品使用，肯定还是要先找找有没有教程能让用户快速上手的。在官网找到了他们的帮助文档，哟居然还有 b 站上的官方视频教程，这是有点让我意外的。看着 20 多分钟也就一集动漫的时间，就直接点进去先看一看了。
才看了几分钟，就看到把我工作上最头疼的问题给点出来了，这个是真好。看完了第一遍之后我就觉得这个 Apifox 可能真的可以给我解决一些问题的工具，于是马上配合视频+文档开始实操起来。大致跟着视频用一开始就有的示例项目数据点了一遍基本流程，我大概了解这个工具的核心是围绕 API 文档（画重点，要考）来做各种不同角色的相关工作的，例如他们自己讲的后端基于接口文档写业务代码，前端基于接口文档 Mock 数据来写界面，测试也是基于接口文档来构建自动化测试用例的。这个核心思路跟我之前熟悉的 postman 还是略有不同，postman 主要是以请求集合作为核心来用的（当然我是测试我主要用请求和批量请求，runner 功能）。在基本摸过一遍这个工具之后，我就使用我们真实的业务接口来开始真正试试看了。以下是一些我依然记得印象很深刻的点。
一键导入接口文档
之前我们公司就有接口文档的管理，也用了工具，是由后端维护在 swagger 上的。开发同学整理的挺好，写的描述说明也够详细，但是 swagger 那界面也就只能算勉强能用。在 Apifox 的视频和文档有看到可以直接将 swagger 文档导入进去生成 Apifox 的文档，导出了一份我们接口文档 json 文件版再导入到 Apifox 里。点击完成就能在工具里看到了所有的接口文档，组织形式跟我们 swagger 是一模一样的，目录树的整体 UI 也很赞。随便点了一个接口文档看详情，好家伙，这界面不吊打 swagger 两条街？接口文档原来也可以这么易读易懂的。让人感觉这款产品才像是 3202 年的产品啊，给大家一点小小的新时代震撼。
只要 2 分钟就把接口文档给全部在 Apifox 整好了，很快啊。然后其它的接口相关功能也可以暂时先不多管了，直接先试试自动化测试功能。
从接口导入来快速编排自动化测试请求步骤
在 Apifox 里建立一个测试场景，可以添加测试步骤，点了一下看到测试的请求步骤的添加是可以从接口/接口用例导入的，直接选择本测试场景需要使用到的接口，就会生成请求步骤。
点击进入请求步骤中，里面的详情是这个接口的请求参数填写内容。路径是直接就是文档里已经写好的内容直接复制过来了，在请求参数中点击自动生成就会自动根据接口文档的内容， 生成出参数名和按一定规则随机的参数值，帮助快速填写，不用再手动抄一遍接口定义，只要改一下实际的参数请求值就行，很好很高效。
添加流程控制组件模拟真实业务流程
在真实的业务流程里，可能涉及到分支、循环、等待等实际业务需要的流程，Apifox 都支持了相关的可视化组件，可以在编排中设置这些组件来让测试场景中的接口请求流程更贴合业务流程。例如我们电商的浏览商品场景，从接口角度看就是先调用商品列表接口，再从列表中选择几个商品调用商品详情接口查看。在这里就可以使用 ForEach 组件编排出这个场景。
接口鉴权可视化配置
做好了最基本的测试场景请求流程，到了运行环节，要确保每个请求中的请求值正确，同时还涉及到鉴权问题。我们公司的接口鉴权是在 Header 上带一个 bearer token 进行请求，值为用户登录成功后接口返回来的。这里就可以使用他们的 Auth 功能和变量功能来实现。在测试场景中的步骤详情会看到一个 Auth 功能，点击就可以看到这个请求的 Auth 是怎么处理的，可以看到这里也是强关联接口文档，在接口管理的接口文档上设置好，自动化测试这边就能直接引用了。
回去接口管理中，找到我们 store 接口的目录，点击一下发现目录内容里也可设置 Auth，设置了类型为我们接口实际用的 bearer token，然后具体值要写成一个变量，因为这个值是要获取登录接口请求成功后的返回值作为实际值的。
在接口管理的右上角或者测试场景的运行环境右边，有环境管理功能入口。这里是类似 postman 环境功能一样，可以管理各种环境变量，在里面设置一个 token 的环境变量给 Auth 那边使用。
回来继续设置 Auth，这里怎么在这个文本框中设置一个变量进去， 可以使用“动态值”功能，在这个地方看到了这个小魔棒，就点击使用这个功能来插入变量。这里不仅能插变量，还能自己随机生成数据，还能自己写复杂表达式。
设置好了之后，发现目录下的所有接口都是跟着父级，也就是跟着这个目录的 auth 设置走的，所以都会带上 bearer token 来请求，在自动化测试那边的步骤里也是一样，这样就完全解决了接口鉴权这个场景了，不用一个个步骤都来搞，非常高效好用。这个功能真的想的很到位！
通过“动态值”直接引用前置步骤的请求/响应详情
在写到加购接口时，碰到一个参数传递的问题，需要把上一个商品接口返回的商品 id，作为加购接口的请求参数请求出去。以 postman 的经验来说还是用变量解决这个问题，但是在 Apifox 里在自动化测试功能中可以直接通过他们的“动态值”功能，直接读取前面步骤的运行结果！所以果断用了这个功能，比回去商品接口提取变量再在加购接口写入这个变量更快更舒服了。
在实际请求内容中检查一下使用动态值提取的变量到底对不对，发现确实是符合预期的，有点东西。。
可视化添加断言、数据库操作等前后置操作
我们之前实际的自动化测试用例里，基本大部分请求内都要写断言，在这个时候 Apifox 跟 postman 很大不一样。postman 都是在 test 中写 pm.test 这种脚本来进行断言的，在 Apifox 是有一个专门的断言、数据库等前后置操作功能。可以可视化的照着界面上设置就好了，效果跟用脚本写的完全一样。对脚本、SQL 不熟悉的同学都可以随意轻松设置断言、执行数据库操作。
简洁直观的测试报告
运行完成就可以看到完整的测试报告，还是比较清晰的，核心的接口成功失败数据在最上面，还有一些请求时间、断言执行情况等指标；下面就是每个接口的请求详情。一开始可能会比较奇怪，怎么这么多失败甚至超出了实际写的断言数。Apifox 的测试报告里除了断言之外，响应结果也会自动校验是否符合接口文档规范，这个点可以帮忙快速揪出来是文档维护有问题，还是真的接口开发有问题。
让我想到以前每隔一段时间领导就要抓我们核对现有接口文档跟实际接口情况是不是一致的，那真的是要花好多时间一个个接口对啊，很痛苦也很花时间。现在可好，每次自动化测试都可以发现这个问题然后让开发当场维护好文档或者改接口。
一键切换环境运行测试场景
在运行设置中，有一个运行环境，这个设置可以统一切换测试步骤内的接口前置 URL ，写一个测试场景就可以快速切换环境测多个环境的接口情况。又比以前在 postman 里把环境的前置 URL 设置成变量，每次开始运行前都要 set up 这个变量来指定环境的麻烦操作，变得简单高效了。
初次体验总结
这下我一开始的基本目标跑通一个简单的自动化测试用例，就算达成了。最后的结果说实话是超出我的预期的，主要以下几个点：
- 简单易用！简单易用！简单易用！我只花了半个小时左右就把这一套玩完了，相关的功能使用起来都很简单没有什么学习成本，一看就会；界面很美观；有的要写脚本的地方直接可视化来设置对于一般水平的测试人员来说真的很友好！
- 功能强大。我不得不说这个动态值功能真的有点东西，可以直接在写本接口的请求值的时候用起来取到前面所有步骤的请求/响应详情数据！节省了很多提取变量再设置的操作时间；还有自动的校验响应也很好可以确保接口文档与接口的一致性。其它还有很多好像很厉害的功能我看到了但这个时候还没有用的，例如编排实际还有循环、分支等功能，可以配很复杂的流程；前后置操作里可以进行数据库操作，又可以满足我很多的测试需求。
- 测试结果直观易懂，问题定位快速高效。Apifox 生成的测试报告数据没有很多，但是重点指标基本有覆盖，出问题的地方一眼就能看到并发现实际什么问题，这样跟开发的沟通会更高效，不用再反复聊天扯皮了。
所以，我决定要在实际工作中也用起来，让这个工具能够真的帮助我和我的小伙伴的工作提效。
实战 - 给开发&领导一点小小惊喜
过了上手 Apifox 的周末回去上班，我印象很深那一周应该是有 4 个小需求要安排在下周周迭代上线，其中有一个需求是“在用户查询商品库存详情时在库存信息中增加展示库存点是否可用”，这个需求要给获取仓库点信息接口的返回多加一个是否可用状态字段，创建/更新库存点接口请求参数多加一个是否可用字段，比较简单。
通过同步功能保证测试场景数据与接口数据对齐
评审完成确认进入开发后，我自己去在 Apifox 中把这几个接口的文档根据会上说的内容更新了一下，并且把主流程里这一个步骤，通过“手动同步”的方式更新到我自己的自动化测试步骤里，我只要填写请求值就好了。又提高了一点点效率，关键是还不会出错。以前也是升级接口，然后改自动化测试用例的时候，贴错结果找半天原因是多一个空格的问题仍历历在目。。
开发完成后的快速测试验证
这个需求开发在 2 天后提测了，在他们群里圈我说可测之后，我立马 Apifox，启动！然后直接设置测试环境运行了我的测试场景。好家伙，真是好家伙，你永远不能期待开发大佬们给你一步到位，看看这报错：
我直接截图并且在图上标记了我的问题，然后把图发群里。并说：“我初步跑了一下流程，有这些问题，后端大佬先看一下，我整理到 bug 里去；前端我下午看然后提交 bug。”然后群里一下就炸了锅。
我在群里笑而不语，后端小哥后面亲自私聊我问我这工具是啥，我告诉他这是 Apifox，除了自动化测试可做，文档也很好看。如果说用这个工具提前就把文档写好，现在都不会出现这种实际开发结果跟约定不符的情况了。然后我把这几个接口的文档通过链接分享了给他。
到了下午，我看早上提的几个问题已经被后端修复，于是我再运行了一遍，发现测试场景的运行确实符合预期了，便去界面上整体再点了一遍流程，对着设计稿提了一些 ui 上的不一致的 bug，前端也马上修完了。基本上这个需求从提测到准备可上线的状态，包括测试和修 bug 时间，大半天就搞完了。想想以前即使类似的小需求，其他测试同学去测试，走流程、发现问题、定位、提 bug、修复 bug、重新验证，起码也得 1 天多才可以搞定到可上线状态，效率上起码提升了有 50%，确实有点夸张。
新版发布后的测试回归
到了下周二需要整个周迭代进行发布，测试这边是肯定需要进行线上回归的。这次因为在 Apifox 上写了自动化测试场景，所以新版本刚上预发布，我直接把所有需求相关的测试场景和业务主流程测试场景都调整成了预发布环境，然后批量运行。简单点几下，立刻就把核心的回归工作完成了。我把这些测试场景的报告截图发到群里并写了个总结，告知大家本次发布没有问题。当然也不能完全只看接口，平时该去产品上回归的流程还是要保留的，后续还会去做。这次的发版就普遍很让人安心，我后续和其他技术同学和领导总结有以下几个点：
- 非常快速的就把新功能与核心业务流程跑通了，确保整个产品的稳定性。以前直接在产品上走一遍这些流程真的要花蛮多时间的；
- 结果清晰可见，可视化的信息有总结有细节，让大家感觉到所有情况都在被掌控之中。以前都是负责回归的测试同学走到哪算到哪，他报问题就是有问题，没报没说那就是没问题，都是看他个人的反馈的；但这次连领导都说回归结果他能很直观的看到客观情况，非常好；
后续，前后端大佬，以及我们的技术经理，都普遍赞同这个周迭代的交付效率非常高，测试效率变高了很多。前端和后端同学在了解到了 Apifox 这个工具之后自己也都去试了试，发现了可以给自己提效的功能。我把这个例子在我们测试周会上做了一个简单分享，并且给其他测试小伙伴也介绍了这个工具，大家普遍兴趣很高并且当场就下载，学习使用了起来。我自己也在工作过程中逐渐加深对这款工具的使用，把各种业务流程的自动化测试场景补全，写了 44 个标准业务自动化测试场景，以及数不清的独立功能的测试场景；也使用到了更多好用、强大的能力。
总结
这就是我一开始初步上手与使用 Apifox 这个工具来做自动化测试的经历，我也跟团队的其他小伙伴交流过，他们都认为 Apifox 的优点有这几个：
- 上手简单，学习成本不高，可视化能力强。不会写脚本也可以很好的使用这款工具来满足测试需求；
- 功能强大，可以数据库操作、任意提取测试场景中前面步骤的请求/响应结果、一键切换环境运行、可进行各种复杂流程控制的编排等这些功能能够满足很多复杂高级的需求；
- 高效好用，所有的自动化测试用例内容都跟接口强相关，创建自动化测试用例可以直接导入接口，接口改了自动化测试用例内容也可以一键同步更改，大大提高了自动化测试用例的编排效率；
- 用户体验好、UI 好看，大家普遍觉得这个工具基本做到所见所得，看到就大概知道这功能怎么用干嘛的，整体的设计感不错。
在我后续深入的使用中，还有用到一些更高级和自动化的方式去做测试工作，让测试的工作不仅提速而且更高质量了。不过因为本篇内容已经太多，所以这些内容如果以后有机会再跟大家进行分享啦！下次有缘再见👋
