请问下,接口请求 body,有 40 多个参数,然后我现在一个 body 里面设计的参数,验证了 20 个规则,然后断言 respond 里面是否有 20 个参数的 error 信息 这样设计 body,有没有问题呀
下面是一部分参数的有效和无效参数输入
我的设计想法是,一个 body 里面验证了 20 个参数的无效输入,这样大概 20 个 body 就能覆盖所有的无效,有效参数. 如果一个 body 只验证一个参数的一个无效输入,那 case 的数量可能要 200 多条了.
第一种 body 的设计方法:开发写代码时候的 respond 信息就要非常详细
第二种,用例的维护和设计难度偏大
大佬们有什么看法呢?
你这个场景看起来有点冗余了，自动化的一个目的之一就是提效，如果后台框架本身是支持配置化参数校验的话，你就没必要一个参数一个参数的验证有效性，更多的应该把精力放在业务逻辑和整体流程治理上，边角的异常场景虽然也可以做，但从投入产出比上看收效不大，而且写了这种用例后期的维护工作是不是也要同样的有付出。所以建议你先把流程建立，把 0 到 1 搭建完成。
服务端遇到一个参数不对，应该就不会做后续参数的校验了吧。
你一个 req 带那么多个无效参数，你接口响应也要给你返相同数量的报错响应吗?尽管后端并不会校验完全部的无效参数再给你返回错误。如果对应的前端需要拿到后台返回的报错信息展示给用户，那用户弹出满屏的报错信息这个体验感合理吗？
正常就是一个场景一条 case，就是参数化测试啊
自动化不是这么做的吧，
看起来像是注册接口
这个入参的规则验证，在手工测试时做一次就行了，验证下前后端的正则过滤是否正确，还有前端的错误信息提示是否正确。
你自动化主要是确定两件事：1. 接口返回的状态码是否正确 2.业务逻辑是否走通
如：
1. 检查接口连通性，断言返回码和响应时间
2. 首次注册人员注册请求，断言返回码和响应时间
3. 已注册人员注册请求，断言返回码和响应时间
4. 非法用户注册，断言返回码和响应时间
等
入参规则这种没必要写成自动化，这种写死或者支持后台配置的规则基本不会变的
这个接口测试搞得太复杂了，最后多用场景化来测试接口
控制变量 + 实际业务场景设计请求参数
哥们,这么弄不累吗,确定能完全执行?
你这个场景看起来有点冗余了，自动化的一个目的之一就是提效，如果后台框架本身是支持配置化参数校验的话，你就没必要一个参数一个参数的验证有效性，更多的应该把精力放在业务逻辑和整体流程治理上，边角的异常场景虽然也可以做，但从投入产出比上看收效不大，而且写了这种用例后期的维护工作是不是也要同样的有付出。所以建议你先把流程建立，把 0 到 1 搭建完成。
根据业务决定，接口对应的有前端页面，哪些是用户能参与输入和看到的，体现的形式是什么，枚举、文本等信息才是你测试的重点，像身份证一般正则的校验，无需过多关注。
