接口和协议组成 接口测试的响应结果是一样的,但是触发原因是不一样的。怎么确定这个响应结果是由于原因 A 引起的,而不是 B

kawa · 2018年05月02日 · 最后由 JMasche 回复于 2018年05月18日 · 2970 次阅读

例如,触发原因为 A 时,响应结果是 failed;触发原因为 B 时,响应结果也是 failed。而我的传入参数是一个图片,图片可能包含 A 也可能包含 B,也可能只包含一个,怎么知道是由于什么原因导致 failed 的?
描述的可能有点乱,大家想到啥说啥吧。。。

共收到 13 条回复 时间 点赞

你传入的参数,自己看不到?请求里会显示的啊

kawa #2 · 2018年05月02日 Author
黑山老妖 回复

请求里看不到具体的原因,这么说吧,一个参数里可能有原因 A 也可能有原因 B

看后台日志;
接口测试是测试环节,不看日志,不看库;基本瞎测

kawa #10 · 2018年05月02日 Author
hellohell 回复

看了一眼,日志有百来行,看的两眼茫茫就放弃了。那我再捣鼓下日志看能提出出来有用信息不

另外对于失败性测试,一个用例应该只携带一个导致失败的因素,比如上传图片,你非要上传个 超过最大允许大小的被破坏的把后缀改成 txt 的图片文件 ...

kawa #6 · 2018年05月02日 Author

嗯嗯,你说的对。但是有时候会遇到我认为只有一个因素,但是其实有多个因素这种情况。

那就是用例设计的太粗.

  • rd 告知你,先做 xxx 判断,后做 xxx 判断
  • 前端负责哪部分判断, 后端负责哪部分判断;
  • prd 上写着:发生 xx 问题,给予用户 xxx 提示;然后报错后已填写数据不丢失不需要用户重新填写

以上都在幻想中出现

远程 debug 一下就好吧

5楼 已删除
kawa #4 · 2018年05月02日 Author
Fresh 回复

是部署好的服务启动后测试的,没法 debug 吧

为什么你要在一个输入里面包含两种都可能出错的输入呢?如果能分开,就尽量分开,这个是最快捷的办法。如果分不开,那么从客户的视角来看,是哪个出得错已经不重要了。

kawa #12 · 2018年05月03日 Author
JMasche 回复

从客户的视角来看,是哪个出得错确实不重要。但是接口测试时,如果接口本身有问题,有可能会出现这种情况,得自己去找出定位这个原因,是不

kawa 回复

你没看清楚我说不重要的前提,也就是我回答的前半部分。
首先你得努力去将可能导致出错的输入条件分开,也就是在用例设计的时候,就要考虑一旦出错可以大概知道什么地方出错。这个要根据开发具体的实现进行分析。
怎么说呢,就好像物理公式中的前提条件 --- 真空中。
如果分不开,那么实际上就没必要花那么多心思去分开了,造成这种情况的原因会非常的多。除非这个是核心环节的核心,否则一般是没那么多时间去耗费的。

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