接口测试 接口测试,随便聊聊~

da-pengTT · 2020年04月01日 · 最后由 da-pengTT 回复于 2020年04月07日 · 71 次阅读

这里只是我聊聊,代码贴的并不多,开聊以前先说下,我叙事的路线:

  1. 我准备怎么做 ,理由是什么?
  2. 如何做,做后发现什么问题?
  3. 总结

1. 我准备怎么做 ,理由是什么?

以往的工作种使用过 接口测试的方式和方法,Jmeter Java Request/ BeanShell/ Java Rest Assrued/Python Requst 以及去年说过的Hitchhiker API 测试平台践行等等....等等... Java 语言 JS 语言 Python 语言各种;至于为什么尝试这么多什么原因:1.有为了解决接口签名问题的 2.有单纯就是觉的比较简洁,3.有页面看起来很高大上。。
最终总是感觉有点厌烦,写完一个月后,再回头看自己写的东西,总感觉是坨屎,感觉都缺点啥;后来无意中看了这本书

对其中的一点 BDD 实践小有体会
结合自己的实际情况,本身我自身中小公司待的比较多,公司大多是业务驱动;业务快速试错,迭代速度快强度大,你说要复用以前的东西嘛;必须以前的人写的好,写的至少让后面的人看的懂吧~不然下次迭代想起来用的时候,就悲催了,自己砸自己脚的事情,我还是遇到不少次的;虽然框架规范了写的模式像单元测试框架 Junit Unittest 以前用这种框架特别多,但是现实是:10 个还好,100 个眼花撩乱;而且要这些人写注解那就是对牛弹琴,少了点中文,看着难受要死
所以打算转 BDD,就朝这个方向搜索学习,查了一下也不复杂 Python / Behave +Request ,心里美滋滋~

2. 如何做,做后发现什么问题?

这就开始新建工程,简单考虑了一下:(这里也包含后来工作中完善的功能)
1)每个请求 响应 要 打印
2)返回 数据 解析,要 异常处理捕获
3)测试/线上环境 配置
4)token/uId 类似这样固定的,一般需要提前准备的死数据
5)还有一些活数据,就是可以按一定规律代码生成的数据
6)上面这些数据存个 CSV 文件/Pickle 持久化一下还是需要的
7)必要的时候,咱需要直接查个数据库/redis 缓存
8)测试数据,跟请求字段,数据组装

陆陆续续为了满足自己的需求,在工程目录 utils 包下有了下图这些模块:

也不是很多,我闲的统计了一下,现在这几个文件写了也就 400 行代码
到这里工程目录结构说一下吧:

  • conf 环境配置
    • 不同项目创建一个文件
      • env.ini (下面有截图/没啥就是 DeBug 开关 日志标示/域名/等等/都是硬东西,都不咋变的...)
  • features(了解 behave 的应该都是到,这个看官网不说了)
    • 不同项目创建一个包
      • steps(这个也是 behave 框架的一部分)
      • utils (这个是不同项目下的私有 utils)
      • server(这个放 业务数据库 的查询,也可以说是 DAO)(用词没错吧~)
      • test-data(这个是文件夹不是包,存 csv 格式测试数据)
      • request-body(这个请求字段示例文件)一个.json 文件
      • features 文件(可以写中文哦)/ environment 文件

features 是描述文件,也是执行的入口,给大家看一下,大多数都这么短

不过也比较长的,例如玩个游戏,第一次 第二次,第三次 传不同分数 结果不一样 集成度高一点

姿势有很多种,代码什么都能实现;已经玩了有 7 个项目了
不管代码怎么写,feature 文件最终都会告诉我,在做什么,为的是什么~哪怕 2 个月后我再看也不蒙蔽
而且即写即用,维护反到觉得比其它工具舒服,而且还有一个我个人原因,代码不会生疏了;如果换在游戏里面,就是自由度高~
可以遇到很多场景,在工作中有锻炼:
例如:

  1. 写一个程序按一定规则生成 数据存储于 CSV:日期不重复,长度大于 20,小于 20(批量 3000 条)
  2. 按 给出的请求字段示例.json 文件,组装请求 Body:要注意数据类型,JsonArray 的组装(批量 3000 个)
  3. 查询业务数据库,校验 响应参数 是否正确

还可以改一改,我后来又在有些项目下,用协程的写了一个小压测;结果在写入文件:简单轻量~应付一些日常轻量的工作,也没必要杀鸡用牛刀了~

3. 总结

总体这么做的原因主要还是,以前看过同事写的,实在是参差不齐,而且不知道目的是什么;有种见光死的感觉,代码写起来有激情无实用;没有从业务出发,贴近业务逻辑;业务校验少之又少;测试目的性不明确(这里纯属抱怨......😄,其实还是有写的不错的)
目前这个用了小半年,感觉良好(自己的东西,就是感觉自在)~好吧,就聊到这里了~有不对 的地方欢迎大家来踩!

共收到 6 条回复 时间 点赞

是的,BDD 有描述,实际上逼 TDD 清晰很多,也比较方便后期的维护

我想问问对于那种业务比较复杂,依赖上下游业务透传的场景,还有内部调用的接口,实际工作中如何测试?感觉最麻烦的就是造数据了,用 mock 的方式很容易遗漏问题,因为业务逻辑可能有 bug,mock 就看不出来

还是自己的舒服啊

AWSL 回复

造数据是大学问,一般不造到边界值,感觉都不靠谱;我一般都(写字段范围,或给几个值正交组合),这就是我的数据;你说应该是 流程接口测试,内部接口,业务接口,这种熟悉了调用时序(熟悉这部要看你看你能沟通或愿不愿意有人耐心跟你沟通了),有要用的就存起来应该就 ok 了~

token/uId 这些要动态获取吧,写死过段时间都失效了啊

aibreze 回复

你可以动态获取哈,只是中间找个地方存哦,内存/文件,方式很多

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册