接口测试 大佬们,准备对新的后台管理项目做接口测试,我想问下我这样做接口测试有没有问题?

autogG · 2023年04月03日 · 最后由 autogG 回复于 2023年04月07日 · 8148 次阅读


后端要求我们这次适当放松要求,想问下这种情况怎么做。
大佬们可以让我看看你们怎么做接口测试的咩。

共收到 16 条回复 时间 点赞

反向接口的场景挺多的,但是正向感觉少了,可以结合业务场景,多补充一些正向的用例,比如:
移动单个文件,文件类型为 xxx;
移动多个文件,文件类型为 xxx,yyy...;
移动单个文件夹,文件夹为空;
移动单个文件夹,文件夹包含 1 个文件,文件类型为 zzz;
移动单个文件夹,文件夹包含多个文件,文件类型为 xxx,yyy..;
移动多个文件夹......

文件的大小,格式,数量是重点需要验证的地方

后端肯定希望你放松要求,你放松要求他就减少工作量,你可以通过业务评估优先级,如果确实是很少量的场景也可以放到后续迭代(一般是不做),不过要和 TL 敲定,建议是自己汇总好了之后拉会评估

感觉有些偏
Tid、FileIds 这两个在后端体现上,只是两个入参,而且在代码层面上是被确定的参数类型,同时也包括是否为必输项。
只要传入格式不正确,程序就会拒绝访问。

单从这个场景来看,建议从正确参数组合非正确参数,fileids 组合存在不非在文件 id,tid 和 fileids 非对应关系组合这些角度来测试

接口测试要结合功能来,而不是仅仅针对参数的测试。可测的点很多,举个简单例子,你的用例没有多个 fileids 情况,没有 tid 和所有 fileids 不匹配或者部分 fileids 不匹配情况,没有对不存在的 tid 和 fileids 情况的覆盖。这几种哪怕我没看到需求,也觉得是应该要覆盖的。

至于你列的各种类型的 tid 和 field,我反而觉得可以归入到等价类,合并成一个就行。

小轩 回复

非常有用,感谢,我总以为在功能测试里做过的内容可以在接口上省点事,但是大佬说了句保障前后端的一致性。我就明白了。😊

沫沫sir 回复

感谢,我们都是把功能测试点和接口测试点写完后评估的

49875183 回复

你表达的意思是我这里欠缺了对正确参数与不正确参数的组合情况吗?

Ouroboros 回复

这里的确忽略到了,因为像文件类型这些内容,我在功能测试上有做,忽略了。

除了功能层面外,是否还要考虑其他方面,比如接口性能,安全,异常告警之类的
1)接口性能方面,大并发接口响应速率等
2)安全方面,是否要考虑合规的内容,比如敏感信息
3)异常告警方面,接口是否有限流,异常告警等,如果有的话触发一下,确认一下风控相关功能是否正常

autogG #10 · 2023年04月04日 Author
green2022 回复

好的

autogG #11 · 2023年04月04日 Author
green2022 回复

1.接口性能的方面有没有比较常规的一种方式?比如说 Jmeter 多少的并发量和用户数之类的。我从别人哪里学习的都是尝试自己去预计用户数量和最大并发来设置场景。但是我入行时间不长,不能很好地做到这一点啊。
2.安全方面内容和敏感信息,我这边的接口基本算是对内的,是否不需要。如果需要可以补充一个常见的情况咩。
3.这一点现在的确没做到位。以后改进

仅楼主可见
autogG #13 · 2023年04月05日 Author
知無涯 回复

我们的业务是指的软件系统的核心功能点吗?

autogG 回复

嗯嗯。再结合测试用例设计方法:等价类,边界值法

有代码仓库权限吗 可以结合走读代码 确认接口逻辑是否符合业务需求进行测试
如果有代码覆盖率平台就更好了

autogG #16 · 2023年04月07日 Author
Null 回复

没有😭

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