1、接口测试中,接口中有许多参数,然后在实际测试中,真的会说去通过多个参数的种类,然后去使用正交法组合去得到测试用例,然后说自己去补充一些用例么? 2、接口测试,参数有那么多,如果一一组合的话,要写的测试用例的数量好像有点多啊,是不是应该只考虑一些比较重要的参数,然后其他参数只考虑是否为空的情况,不考虑数据非法。还是说都得考虑。 新手测试,谢谢各位大佬回答
不知道其他人经历,只说我自己的。一般只会针对比较重要的参数做比较全的测试,其它非核心的过一个有正常值 + 一个异常值就完了。
其实参数组合这块,我更喜欢先 review 代码看逻辑。因为很多比较通用的规则,实现开发就一个注解(JSR303)或者 controller 里前几行校验就搞定了。比如非空 @NotNull,指定范围 @Size(max, min) 。
@NotNull
@Size(max, min)
@ 陈恒捷 谢谢老哥回答。我想再问个问题啊,就是做接口测试啊,我自己用的一些工具,例如 postman、fiddler 这些去做。但我在社区里边看别人的一些讨论,总觉得做得不是同种东西,大多数好像都是用一些类似于 httpRunner 这样的框架,然后自己去构造请求,就这样做的好处是便于说实现接口自动化或者 CI 么?我有点无法判断为什么要这么做,是因为这种类型在代码层面可以更好扩展么?新手测试,哪里说得比较搞笑请见谅指正。
1、fildder 是抓包工具,不是接口测试工具吧 2、接口测试相对会比较容易自动化,所以有不少人的用法是直接用可以自动化执行的方式来写接口测试用例的,反正成本差异不大,写起来也差不多(基本都是定义请求参数,然后校验返回参数,只是界面上写,还是 yml 或者代码文件写而已),还能让自己回归开发 bug 的时候直接一键执行,后面加入 CI 持续自动运行,挺爽的。当然实际情况还要考虑数据是否可以重复使用,不一定真的直接能重复执行哈,只是举个简单的例子。
httprunner 本身也可以简化一些写用例的成本(比如通过抓包保存 har 文件,直接导入后,写接口用例时只需要写各个参数的 value ,不用再写 key),也可以支持一些业务特殊的定制化(比如接口参数加密、不同的鉴权方案)以及流程化的接口自动化测试(比如电商的登录 - 选商品 - 下单 - 支付整个流程,印象中 postman 得付费版才有这个功能)。
也有封装成平台,体验和 postman 接近甚至更优的(比如开源的 meterphere,录入接口文档的功能后,写得时候连 key、path 都不用额外写,直接写 value 就好。一个接口多个用例时写起来更爽)。
接口测试的工具还是蛮多的,建议你可以多试试,找到最合适自己的。
1.我一般根据业务场景结合代码来,不影响业务场景的参数正向覆盖就行。另外请不要滥用正交法。。。 2.非法和空等格式校验,定义清楚的情况下,可以自己写个普适性高的工具自己跑,不用单独写用例。
PS:多看代码可以防止纯黑盒的某些场景漏测
很多自动化测试框架都有数据驱动,我们是用二因子正交 + 数据驱动。像上面大佬说的,也只会对核心的接口会做正交
噢噢好的,谢谢大佬
.非法和空等格式校验,定义清楚的情况下,可以自己写个普适性高的工具自己跑
可以详细介绍下吗
只说我自己的做法哈,可能有一定项目特殊性。
由于我们接口(http 协议基于 XML 交互的接口)请求参数非常多,而且对所有空字符、null 等都很敏感,对所有参数要求和文档定义一致,但是产品给字段定义比较痛快,所以我会在接口还没开发但是给了定义文档的时候,根据这个接口最全的字段做一个请求模板,根据这个模板,程序会按规则依次按照每个 XML 结点空、null、字段范围定义等规则,去跑一些 定义之外 的测试(单因素法)。一般会和开发约定此类报错给一个或者一组错误码,用来验证结果,拼接测试报告。
由于基础规则几乎所有接口都差不太多,所以只需要预设一个请求模板就行。用例设计更多关注业务的参数组合。