移动测试基础 产品全面覆盖的测试疑问

leahyezi · 发布于 2017年11月08日 · 最后由 jamesparagon 回复于 2017年11月17日 · 535 次阅读

请教下各位关于产品全面覆盖的测试

先简单介绍下产品业务

我们开发的是一款英语学习的软件,主要是以试题的方式提供给用户练习。用户下载试题后,会进入做题过程,题目有口语评分/选择题/填空题等,做完试题后,进行评分且最终给用户反馈分数。而我们的试题是有多种题型类型的,一个地区的题型类型多达7种(例如纯单词练习、纯选择题、单词与选择题合并在一起的模拟套题),不同地区的试题结构以及试题类型又会有不一致的地方,覆盖的地区已有几十个,意味着测试需要测多达(7*几十)种题型。

题型表如下:

某个题型做题截图:

我们平常用于试题覆盖的测试时间耗时非常长,所以在此想请教各位,对于这种做内容提供型的APP该怎么进行全面的内容覆盖测试。期待能得到各位的建议与回复!

共收到 15 条回复
B75ea9
leahyezi · #1 · 2017年11月08日 作者

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

609

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

B75ea9
leahyezi · #3 · 2017年11月08日 作者
609shixue33 回复

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

609
B75ea9leahyezi 回复

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

609

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

B75ea9
leahyezi · #6 · 2017年11月09日 作者
609shixue33 回复

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

609
B75ea9leahyezi 回复

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

B75ea9
leahyezi · #8 · 2017年11月09日 作者
609shixue33 回复

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

9楼 已删除
480

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

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

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

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

B75ea9
leahyezi · #11 · 2017年11月09日 作者
480sanlengjingvv 回复

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

167d23

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

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

B75ea9
leahyezi · #13 · 2017年11月13日 作者
167d23Innocence 回复

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

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

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

237167

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

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

96
B75ea9leahyezi 回复

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

4389

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

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册