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

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

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

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

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

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

那就是用例设计的太粗.

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

以上都在幻想中出现

远程 debug 一下就好吧

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

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

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

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