接口测试 – 从0不到1的心路历程

我是一名做了三年测试的tester，2020年以功能测试工程师的身份入职北京一家医疗培训公司，入职后为了提高测试效率，接触到接口测试，以下是从零到现在 (还有很大完善的空间，所以不能算是1) 的一些心路历程。

做接口测试的动机

于公司业务和团队现状而言，团队中仅我一名测试，随着产品功能日益丰富，导致回归测试任务量越来越大，紧靠人工回归，效率低，质量低，所以自动化测试势在必行。

于个人职业发展路径而言，每天点点点，看似很忙，但除了对业务流程越来越熟练之外，硬技能长进很慢，要想把测试这条路走宽走远，主动求变是必须的，站在功能测试工程师的角度看职业发展方向，无非就是安全测试、性能测试、自动化测试以及管理方向，刚好公司业务所需，所以决定先从自动化测试入手。

起步阶段，选择JMeter

我认为打算做一件事情之前，如果准备过多，往往会阻碍起步的脚步，过犹不及，不如稍作准备就马上抛竿，实践一下鱼塘里有没有口儿。所以我选择了上手比较容易的JMeter，从接口自动化开始突破。当时手握《全栈性能测试修炼宝典 JMeter实战》这本经典工具书，参考 上优秀的实战经验帖，很快就搭建出了一套200条case的脚本，脚本中尽可能的提取公共变量，解决接口依赖问题。

其中有4个目录和2个文件，需要解释的可能是public下的custom_tools，我将一些通用方法写在这个文件里，例如获取指定个数个字符串的random_str方法、对参数进行 md5 加密的 to_md5 方法等。

正文-test_tanqiang.py的编写思路是这样的：

另外，我将不同环境和不同端的HOST写到了config文件中。

这个版本也能实现生成测试 告，并发送电子邮件的功能，想的是为日后持续集成做铺垫。

效率至上 – 第二代测试框架

根据第一代的经验和问题，重构框架，详细如下：

变动1：弃用数据驱动模式，因为做接口自动化测试的初衷就是为了做回归测试（保障原有功能不受影响），而不是通过接口自动化测试发现新的问题。再加上团队中就我一名测试，我的时间重点还是在保障功能测试上。根据以往接口受影响的经验来看，接口如果受影响更多情况会直接500，而不会是type传1接口正常，type接传2接口异常。所以在第二版中，我仅选择每个接口的正常入参，并将测试数据直接写进了测试脚本里。

变动4：丰富接口断言。接口自动化测试重中之重就是断言设计，所以本次改版丰富了断言类型。

第二版的成果和反思：在这个模式下我共集成了150个接口的自动化case。不过在实践中又发现了新的问题：如果某条 case 错，那么 错后我并不能清楚的知道测试时的请求体的具体内容，以及响应体的具体内容。这会让我在排查以及跟开发反馈时很困难（运行完乌压压一片红，具体错在哪不是很明了）。

提升接口测试结果的可信度、持久化接口测试前中后过程中的信息 – 第三代测试框架

我加入这家公司正是团队刚刚起步的时候，所以那时迭代很快，每天都很忙，转眼入职两年了，产品预期的功能都已上线，我们公司主打的本就不是软件，IT部是职能部门，所以一旦该有的功能都有了之后也不会有太多大动作的更新（懂得都懂）。这个时候我就有时间再重新思考下当前的测试脚本了。

最近在反复的读《测试架构师修炼之道第2版》这本书（强烈推荐给大家），书中系统的教授了如何设计测试用例，从其中教授的多参数组合测试方法中得到启发，大致意思就是比如一个接口有3个必填参数（参数A（可取值：1,2,3,4,5）、参数B（0,1）、参数 C(0,1,2)），相互之间没有关联关系，据此可生成5条case：

（整体思路）

（将测试运行过程中的 response 的相关信息写入到excel（这个方法可公用））

（在testcase中调取响应的方法）

如果你不想一个人野蛮生长，找不到系统的资料，问题得不到帮助，坚持几天便放弃的感受的话，可以加入我们的QQ群：746506216，大家可以一起讨论交流，里面会有各种软件测试资料和技术交流。

资源分享

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取

文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览214496 人正在系统学习中