我是耿晓,25 岁,在北京做了 3 年的软件测试。
近 2 年服务于一家做医疗培训的创业公司,平时在做功能测试之余,也会做接口测试相关。
在开荒、实践过程中会遇到很多问题,我会将阶段性的总结发布于此,渴望交流,希望佬儿哥佬儿姐们多多指点。

  • 我把测试脚本上传到了 git 上,git 上就能看到地址,比如我的:

  • 🍻

  • 那还要感谢伙伴儿们的指点纠偏,找准了方向,行动起来就顺利多了☀

  • 感谢你能读文,我没太了解你的问题。我现在的公司情况也不是很,,我们部门就我一个测试,可是测试任务就是那么些,作为唯一的测试,要么就选择每次发版后手动回归,要么就是像我这样做接口测试,当然了,不管你怎么选,过程是没有领导要求或者强制的,领导只看结果,所以接口测试两分钟就搞定的事,谁会去选择手点半小时呢,哈哈,加油

  • 大概一周哇😁

  • 有两种解决办法,第一种是一个 case 下仅涉及一个接口,那么你可以 case1 新建,然后断言成功够将 id 存储起来 (可以是全局变量形式),然后 case2 删除,在 case2 中先判断 id 是否有效 (是否被 case1 成功赋值),然后再拿着 id 编写删除的相关 case。这种方式就会导致 case 间的耦合性很强,不太适合经常只执行脚本中部分 case 的场景。第二种方式就是一条 case 下涉及多个接口,也就是在一条 case 下先写新建接口的用例,然后断言通过后取到新建的 id,可以保存为局部变量 (在一个 case 里变量存储就方便多了),然后再写删除接口相关的 case。第二种方式的优势就是降低了 case 间的相互依赖,适用于经常单独运行脚本中部分 case 的场景。但是这种方式我总感觉每一条 case 都不太纯粹 (这条 case 到底是验证新建呢,还是验证删除呢),还有就是如果遇到复杂点的场景,那么一条 case 就会很长,臃肿。以上仅仅是我个人的一点经验,😀

  • 这并不是懒,你这套是前期投入产出比最高的组合,能立竿见影,随着接口测试的收益越来越大,工具的局限性越来越多的时候,才会促使我们向更深层次的地方探索呀。👍

  • “所以在有限的环境内找到更适合落地的尝试对于小厂的测试人员来说算是最佳的选项了”👍

  • ☀

  • 很开心你能读文,很开心你能给我留言。☀

我是耿晓,25 岁,在北京做了 3 年的软件测试。
近 2 年服务于一家做医疗培训的创业公司,平时在做功能测试之余,也会做接口测试相关。
在开荒、实践过程中会遇到很多问题,我会将阶段性的总结发布于此,渴望交流,希望佬儿哥佬儿姐们多多指点。