期待回复！面对越来越多的试题类型，真的是遇到覆盖测试的瓶颈了

前端主要看不同题型的兼容性，
验证数据正确，用接口来做，交给脚本来做。分分钟跑完。

每套题都是有流程的，而且一套题耗时 1 分钟到 20 分钟不等，接口没问题，不代表客户端没问题。就比如评分的接口没问题，但客户端会有不发起评分请求的 bug，导致用户一直在等待评分。

这种 bug 一般是什么情况下会发生呢？

我觉得可能也可以在关键点 mock 服务器数据，来看客户端表现？

倒不是跟服务器的数据有什么关联，就是纯粹是 app 的 bug，比如有 app 自身在播放试题的过程中会突然卡住的 bug。谢谢回复呢，我感觉这个只能做 UI 自动化了，但是公司没有那么多时间让我们去研究这个。

啊，不是啊，我意思是，这种 app 自身播放试题卡住，这种在测试所有试题类型在前端的兼容时，应该就可以发现，不涉及地区的吧。感觉你是头痛的是，题型和地区的排列组合太多？

是的，排列组合太多。比如说这个版本需要支持北京市的题型，客户端适配了之后，可能又会对广州市题型造成影响。结果就是，每次涉及到新地区题型适配的修改，我就需要去看以往已经适配好的题是否会受影响。

比如有 app 自身在播放试题的过程中会突然卡住
客户端会有不发起评分请求的 bug

如果这种问题是在特定的题型才出现，很可能是软件架构出现了设计问题的信号。用覆盖全题型的方法去找这种 bug，大概就像用泼水的方式向瓶子里倒水。

关于选择哪些用例执行
全排列出来的所有用例不是同等重要的，试试正交表。技术实现、产品设计和代码变动之类的信息都可以用来判断哪些更重要。

关于接口测试自动化
有 1 个用例，测试版本 v1，手动执行第一遍，发现后端一个缺陷。修复后手动执行第二遍，发现前端一个缺陷，修复后执行第三遍，测试通过。
有 1 个用例，测试版本 v1，接口测试脚本执行一遍，发现后端一个缺陷。修复后测试脚本执行第二遍测试通过，手动执行第一遍，发现前端一个缺陷，修复后手动执行第二遍，测试通过。

感谢回复！
### 关于选择那些用例执行
目前的做法是对热门地区的试题进行全面覆盖，对于用户使用不多的地区抽测。不同地区之间的题型表现形式会不一样，但是有共同特征，所以目前这个方式还是能够支撑。但是最近发版太频繁，面对这些题型还是会很疲惫，上面的回复也说了，每套题时间 1 分钟到 20 分钟不等，总花费时间还是很长。所以才发出该帖子。
### 接口自动化
目前后端功能状态稳定，且后端几乎没发生过问题。客户端做试题适配，评分等接口无需改动。所以觉得接口在此场景不是最适合的方式。

像这个每套题需要花费这么长时间的情况，我猜应该题目刷新时间或者是提交时间有限制？
测试应该去争取开发的协助，增加一个开关——在测试环境内，允许将上述时间调短（或者调整到方便你测试的时间）。

PS:我觉得这种题库 app 测试，应该和地区无关吧。将所有题型进入测试环境某一个库，然后能遍历到所有题型在客户端的显示、答题、做题（如果是随机的，让开发配合写一个刷固定题目的方法给你）

题目是按照流程走下去的，比如先要有原文题干的录音 -- 原文内容的录音 -- 用户开始录音 -- 录音完成 -- 进入下一题等等。其实每个流程之间确实有下一步的按钮，点击之后可以跳过该流程，能够节省点时间，但是用户可以选择跳过或不跳过，所以我们都需要去测跳过的场景和不跳过的场景。

很多地区都是定制型的题型，虽然有一定的共性，但是不能确保选择题 A 类型与选择题 B 类型的测试结果是统一一致的。

你说的遍历是否是调用某个做题方法，就像人点击试题做题那样，开始进入试题流程，去检查显示、做题、评分等操作吗？

app 的可操作性太多了，不可能保证功能百分百覆盖，如果发版比较快的话可以考虑多增加一些埋点，统计下重点区域，然后测试的时候着重看下。类似评分这种应该是功能上共有的问题，应该和试卷类型没有太大关系吧。

如果有的话，那要考虑下是哪些地方影响了，试卷篇幅大请求慢了还是什么

将接口测试的服务端数据保存，然后 mock 服务端，这样可以让客户端自动化

我怎么觉得你的这个问题，和你的软件设计的原始架构有关系呢？比如客户端不发起评分请求，是什么原因？还有地区覆盖的问题，我感觉这个就是接口设计不够完善造成的，假如你的接口结构里包含一个 “覆盖地区” 的 key，value 是对应覆盖的城市，是不是就没有这种问题了呢？