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

da-pengTT · April 01, 2020 · Last by da-pengTT replied at April 07, 2020 · 1465 hits

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

  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就看不出来

还是自己的舒服啊

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

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

aibreze 回复

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

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up