最近一直在思考接口测试覆盖率我之前也发过一些帖子，现在有一些想法和疑问
设计
如何保证一个接口的覆盖率
- 对接口的各个参数，如参数类型,是否必填,参数最最大/小值进行全对偶组合测试，那么一个接口可能就会测试多次
接口的依赖性
- 一个接口可能会依赖一个或者多个接口。如接口 A 需要依赖接口 B 和 C,那么接口设计：
- 接口 B 和 C 测试通过
- 接口 A 取接口 B 和 C 的响应参数的某个字段
检查点
- 对于接口异常 (缺参数,类型错误) 情况直接读取接口的 json
- 对于接口正常情况可以远程查询数据库为检查点（可以设计是否需要对该接口进行数据库检查）
疑问
接口加密
- 加密方式越来越多，加密规则也越来越多，一直没有想好如何设计一套完善的方案，或者接口测试的时候要开发不加密？
接口监控
- 上线后，对某些关键接口的监控设计，一直不知道好的设计方案,特别是分布式存在的情况
其他
- 补上之前的组合接口测试
- 我的设计是否有问题，如果大家有什么好的想法，欢迎讨论
沙发
1.接口的依赖性可以通过 mock 来进行，解耦很重要
2.另外检查点一块不仅从值方面来设计，更多的可以从各种类型方面来进行
3.加密是需要的，可以以中间件模式来 (抑或 mock 也是 ok 的)
1.关联性接口必须解耦，抽象到单接口层面就不需要考虑其他接口返回的值的情况了，都应该包含在待测接口的参数矩阵中
2.正向测试和负面测试只要在前期对参数进行建模，再通过程序来达成覆盖度，基本上可以解决大部分输入和输出场景
3.参数加密，cookie 等具有业务特点的，建议在输入阶段就解决这些问题
@kasi 对于一个 HTTP 接口，依赖登录接口返回的 token，这种情况怎么 mock 这个 token?这个 token 有存储在 session 中。
子凡
回复
看你怎么设计，我的设计是。
1.通过登录接口拿到 token，然后在 testcase 用。（合适值不变化）
2.每测试一条 testcase，都去请求一次登录接口拿到 token，然后用这个 token 去测试。（合适值变化）
我说下加密的吧，就是每次请求 session 都是变化的，也是可以做到的。
从开发那里了解他们是怎么做生成这个 session 的，然后你用你的语言去实现它即可
对于加密的，最简单的就是让开发提供个加密接口。一则大家都基于没什么工作量，再则加密算法变了开发改一遍就可以了
对于加密，传参加密方式应该与服务端加密方式一样，这块需要和开发确认加密方式
一个接口可能会依赖一个或者多个接口。如接口 A 需要依赖接口 B 和 C,那么接口设计：
接口 B 和 C 测试通过
接口 A 取接口 B 和 C 的响应参数的某个字段
我们对于这块是写单独的测试脚本来解决的，用上层接口值 与 当前接口值 ，进行逻辑、业务需求组合来判断当前接口是否正确的
如何保证一个接口的覆盖率
对接口的各个参数，如参数类型,是否必填,参数最最大/小值进行全对偶组合测试，那么一个接口可能就会测试多次
参数比较多的话，可以使用正交表的方法来减少用例数量。
simple
回复
你好~想问一下，关于第二点：2.正向测试和负面测试只要在前期对参数进行建模，再通过程序来达成覆盖度，基本上可以解决大部分输入和输出场景。是否有相关的资料推荐，刚在学习，正好需要学习这块。
社区里面，之前发过几篇文章，比如@lose 的文章https://testerhome.com/topics/6650，
以及我的文章https://testerhome.com/topics/6150，
还有腾讯 TMQ 同学的https://testerhome.com/topics/6092，
我们也是基于 PICT 的二次开发，你可以看一下这个开源工具，多交流