虽然我也没做过接口，但是排除业务，我肯定不会这样写，最多只会校验必填的参数为空时，不会写这些中文英文特殊字符。。。我觉得接口测试主要精力还是放在，通过不同请求参数以及参数的组合，来校验接口处理的业务逻辑是否正确以及一些异常场景

学习了

看需求是啥。仅从功能上看，我一般按以下思路来：

1. 查询不存在的页数（比如结果有 5 页，页数传 6 什么的）
2. 查询页面记录数为空的页数
3. 查询某个应用 id
4. 查询某几个应用 id
5. 查询多个应用 id，但是某些 id 不存在
6. 查询 IOS
7. 查询 Android
8. 查询其他系统类型
9. 查询指定某个开发者名称
10. 查询指定某个不存在的开发者名称
11. 查询某个开发者 id
12. 查询某些开发者 id
13. 查询某些开发者 id，但是部分不存在
14. 每个参数必填非必填验证
15. 查询某些参数不匹配的情况，比如开发者 id 和名称不匹配
16. 其他一些报错情况 。。。 等等

至于参数中英文情况，没特别要求，我一般不咋管，特殊字符也是根据实际情况再考虑。

面试的时候我会这么答。测试的时候不会这么做，啊哈哈哈

只能说做的太冗余了

没校验开发也不会改这样的，除非领导要求

这样设计，肯定是覆盖率不足的，而且，可能测完，还有一堆 bug。

第一个问题，先拿最常见的例子来说，前端 pageNum，一般不会传中文，所以这点可以不需要测，除非公司项目要求，因为即使你测了，开发可能也不会改，因为在前端调用的情况，根本不可能出现 pageNum 去传一个中文字符串，除非有人恶意通过接口调用（所以，这个要看测试范围，看具体公司具体项目具体要求）

第二个问题，像 appids，你肯定要校验，存在的 appids，不存在的 appids，可能还有多种不同类型的 appids，能否查询等等其他业务逻辑，更多精力要把业务逻辑，覆盖到。

这其实属于一类通用的测试点，还是更多从业务逻辑和流程上来考虑

大部分项目都是以前端为入口的，接口不会面对这么多考验，而且项目的人力成本投入也不支持做这么详细的校验。所以一般接口测试是用来保障正常入参、正常业务场景，项目有特殊要求除外

建议多和前端研发沟通沟通，可以精简不少 case，同时增加一些从业务角度的特殊情况，比如边界值等测试