理想的测试流程
产品经理提供产品需求、原型设计;
开发提供接口文档、单元测试脚本;
接口测试必要文档
接口文档需要的要素:
访问方式;路由;输入参数;返回参数;完整的例子
从0开始测试接口
如果没有提供必要的接口文档、测试同学要学会自己从0开始了解接口。
常用以下三步:
工具辅助:
借助一些工具的辅助来完成接口分析
windws系统:fiddler
Mac OS系统:推荐Charles、mitmproxy
分析问题:
分析接口必要的信息
访问方式:post、get
HOST:访问的服务器域名
Connection 的值为keep-alive,表示需要持久连接
User-Agent:说明请求是从什么浏览器发出的
Sec-Teth-Site 和 Sec-Feth-Mode :JS中对跨域的一些设置
Accept-Encoding :设置为gzip、deflate、br 可以支持的web服务器返回内容压缩编码类型
Accept-Language: 可以接受的语言
Cookie:用来确认身份、鉴定角色权限等需要的参数
询问疑惑,向研发确定参数的含义、作用域、返回值的含义:
参数的含义以及来源:参数的中文意思,参数的赋值时从哪里来的(其他页面返回值、JS生成的)如果是其他页面或接口返回的,确定具体接口具体字段,或者清楚它的生成规则,确保可以手动构造
参数的作用域:这个参数在这个接口中是做什么用的,它在哪个访问周期是一直存在的,它是否导致了业务逻辑分支等。
返回值的含义:针对返回的JSON要搞清楚在返回值中,每一个JSON的key所对应的含义,这样当你需要和这个接口产生交互的时候,就可以快速地拿到对应参数的含义,完成业务逻辑上下文的参数串联
接口测试思维
先从单个接口的测试开始,保障单个接口的正确性和健壮性,然后通过单个接口的测试完成多个接口的业务逻辑串联,站在业务逻辑的角度完成业务逻辑的正确行检测。
单接口测试
保证该接口的正确性和健壮性,既要保证这个接口可以按照需求,正确处理传入的参数,给出正确的返回;
也可以按照需求,正确的拒绝传入非正确的参数,给出正确的拒绝性返回。
业务流程接口测试
通过多个接口的串联操作可以完成原来需求中提出的业务逻辑,这也是它主要关注的内容。
注意:在接口测试中,通过单个接口测试完成了全部异常状态的覆盖;在业务流程中,我们更需要关心业务流和数据流的关系,并不需要在过度关心如何利用业务流的方法覆盖更多的代码逻辑异常
测试用例设计与原则
1、正面测试用例:
覆盖所有的必选参数
组合可选参数
参数边界值
如果参数的取值范围是枚举变量,需要覆盖所有枚举值
结合实际业务应用场景设计输入参数的组合
2、负面测试用例:
空数据、null
包含特殊字符
越界的数据,参数字符长短、最大+1,最小-1
参数个数、顺序、类型错误
3、验证点:
状态码,正常情况下返回200
响应信息数据结构是否与预期结果一致
检查接口返回数据是否与预期结果一致
验证结点的值,针对固定的值或有规则能知道预期结果的值
对于列表,应该根据请求参数,列表的长度是否与期望值一致
负面测试用例,验证error info是否与实际相匹配
检查接口的容错性。传递数据的类型错误时是否可以处理
接口的性能,响应时间
接口的安全性
面试常问:你们公司是如何做接口测试的?
答案1:
获取接口文档,熟悉单接口 以及链路接口(接口业务流程)的业务,包括:接口地址、鉴权方式、入参、出参、错误码等。
编写接口测试用例并评审?
正例:
1-2个,单接口返回成功场景,链路接口业务流程实现(功能业务流程)
反例:
鉴权异常:空、错误、过期;
参数异常:空、类型异常、长度异常;
错误码异常:接口文档中会给出错误码;
其他异常:接口黑名单、接口调用次数现在(分页,少于0, =0, 中间页,最大页,超过最大页)
使用接口测试工具或代码的方式执行接口测试,重要考虑的情况:接口关联、接口加密、接口参数是否签名、是否需要带请求头等
实现持续集成并输出接口测试的电子邮件,有bug 提bug。
答案2:
接口测试实际跟一般测试不同就是测试用例的设计部分。
①获取接口规范。
②设计接口测试功能用例(主要从用户角度出发看接口能否实现业务需求,用例设计就是黑盒用例那一套)。
③各种入参验证(正常情况,异常情况包括输入参数个数不对,类型不对,可选/必选,还有考虑参数有互斥或关联的情况)。
④接口返回值各种验证(符合接口文档需求)
⑤了解接口实现逻辑,实现逻辑覆盖(语句/条件/分支/判定/…)
⑥接口能并发执行吗、安全吗,性能满足要求吗?
⑦采用工具或者自写代码来验证。
⑧发现问题跟功能测试一样,该报bug报bug,该跟踪状态的跟踪状态。
面试题:你平常做接口测试的过程中发现过哪些bug?
答案1:
面试官出这个题,主要是想知道你是不是真的做过接口测试,毕竟现在很多小伙伴简历经过包装(不包装连面试机会都没有,没办法,为了生存,能理解)
常规错误,接口没实现,没按约定返回结果,边界值处理出错等。
输入异常值(空值、特殊字符、超过约定长度等),接口抛错,没做封装处理;
输入错误的参数、多输入、少输入参数,接口可能出现的错误;
安全性问题,如明文传输、返回结果含有敏感信息,没对用户身份信息做校验,没做恶意请求拦截等;
性能问题,如接口并发插入多条相同操作,响应时间过长,接口压测出现瓶颈等;
答案2:
常规bug:接口没有安装文档说明返回结果,输入异常类(空值、特殊字符),接口报错,没有返回合理的提示
如:商品价格 修改为-3
权限bug:测试修改服务包商品信息接口,接口文档要求只有超级管理员才有权限修改,我传入一个普通人员的人员ID 和角色编码,都能修改成功。
接口测试就是为了避免绕过前端测试,直接访问后端接口的BUG。
常问面试题:接口关联是如何处理的?
回答:
接口关联:一个接口依赖于多个接口,或多个接口依赖于一个接口(登录)。很多的接口测试都是登录之后获取鉴权码,然后其他所以的接口都需要这个鉴权码。
以实际做过的案例为主:登录接口-登录成功后,会返回token信息,其他需要登录才能查看的接口都需要这个token,并且是在请求头header里边。
处理办法:将登录成功后的token取出来保存为全局变量,哪里需要直接引用就可以。
jmeter 里边使用json提取器(正则也能实现),将token提取出来,别处直接引用:${token}
postman:用脚本的方式去实现,提取之后都要保存在全局变量。
下面是我整理的2023年最全的软件测试工程师学习知识架构体系图 |
生命短暂而珍贵,不要被安逸束缚。拥抱挑战,超越平凡,用汗水浇灌梦想的花朵。坚持奋斗,永不放弃,唯有努力,才能书写属于自己的辉煌篇章!
不要停留在平庸的舒适区,放飞心灵的翅膀,追逐梦想的火焰。信念是前行的动力,勇气是闯过困境的力量。坚持奋斗,创造属于自己的传奇,成就不凡的人生!
在漆黑的夜里,梦想是指引的明灯;在跌倒的瞬间,坚持是再起的力量。别害怕失败,勇敢面对困难,因为只有奋斗,才能成就自己,创造不可思议的辉煌!