基本任务
1.计划说明
1.1.本组选择的对比测试产品为百词斩与扇贝单词
1.2.测试进度表
项目 |
内容说明 |
预估耗时 (分钟) |
实际耗时 (分钟) |
Planning |
|
10 | 15 |
· Estimate |
· 估计这个任务需要多少时间 |
10 | 15 |
Testing Design |
|
200 | 260 |
· Analysis |
· 需求和测试需求分析 |
60 | 80 |
· Design Test Cases |
· 设计测试用例 |
140 | 180 |
Testing Environment |
|
30 | 40 |
Testing Implementation |
|
40 | 60 |
· Test |
· 执行测试 |
40 | 60 |
Reporting |
|
50 | 50 |
· Test Report |
· 测试报告 |
30 | 30 |
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
20 | 20 |
合 计 |
330 | 425 |
2.需求
1.1.功能模块划分
1.1.百词斩功能模块划分:
1.1.2.扇贝单词功能模块划分:
1.2.本人负责的功能模块
扩展功能模块(1.单词量测试。2.帖子阅读)
由于百词斩与扇贝单词在扩展功能模块划分中存在很多差异,我就选了两个共同具有的、且与单词学习有直接联系的子模块。帖子阅读即百词斩里的“小讲堂”以及扇贝单词里的“学习活动”。
3.测试
3.1. 测试用例的设计思路
基于课堂上讲的场景测试方法,可以分别作出这2两个APP关于这2个子模块的业务流程图:
3.1.1.扇贝单词量测试业务流程图:
基于这个业务流程图,用独立路径的方法构造典型场景来设计测试用例:
场景 | 路径 | 可行性 | 预期输出 |
1 | 基本流 | 可行 | 显示测试结果然后返回 |
2 | 基本流+备选流1 | 可行 | 返回到主界面 |
3 | 基本流+备选流2+备选流1 | 可行 | 分享成功然后返回到主界面 |
3.1.2.百词斩单词量测试业务流程图:
基于这个业务流程图,用独立路径的方法构造典型场景来设计测试用例:
场景 | 路径 | 可行性 | 预期输出 |
1 | 基本流 | 可行 | 显示测试结果然后返回 |
2 | 基本流+备选流1 | 可行 | 显示测试结果然后返回 |
3 | 基本流+备选流1+备选流2 | 可行 | 显示测试结果然后返回 |
4 | 基本流+备选流1+备选流3+备选流2 | 可行 | 显示测试结果然后再测再显示测试结果然后返回 |
5 | 基本流+备选流1+备选流4 | 可行 | 返回到主界面 |
6 | 基本流+备选流4+备选流5 | 可行 | 分享成功后返回 |
3.1.3扇贝帖子阅读:
基于这个业务流程图,用独立路径的方法构造典型场景来设计测试用例:
场景 | 路径 | 可行性 | 预期输出 |
1 | 基本流 | 可行 | 阅读完文章然后返回 |
2 | 基本流+备选流1 | 可行 | 阅读完文章然后返回 |
3 | 基本流+备选流2 | 可行 | 返回到主界面 |
4 | 基本流+备选流1+备选流3 | 可行 | 阅读完文章然后返回 |
5 | 基本流+备选流4 | 可行 | 分享成功后阅读完文章然后返回 |
6 | 基本流+备选流3+备选流5 | 可行 | 完成评论后阅读完文章然后返回 |
7 | 基本流+备选流7 | 可行 | 点赞成功后阅读完文章然后返回 |
8 | 基本流+备选流7+备选流8 | 可行 | 点赞成功后选择其他文章阅读然后返回 |
9 | 基本流+备选流6 | 不可行 |
备选流6需要支付金额,做这个没有受益,就不做亏本的测试了。
3.1.4百词斩帖子阅读:
基于这个业务流程图,用独立路径的方法构造典型场景来设计测试用例:
场景 | 路径 | 可行性 | 预期输出 |
1 | 基本流 | 可行 | 阅读完文章然后返回 |
2 | 基本流+备选流1 | 可行 | 阅读完文章然后返回 |
3 | 基本流+备选流2 | 可行 | 返回到主界面 |
4 | 基本流+备选流1+备选流3 | 可行 | 分享成功后阅读完文章然后返回 |
5 | 基本流+备选流4 | 可行 | 评论成功后阅读完文章然后返回 |
6 | 基本流+备选流1+备选流5 | 可行 | 申请发送后阅读完文章然后返回 |
7 | 基本流+备选流6 | 可行 | 点赞成功后阅读完文章然后返回 |
8 | 基本流+备选流6+备选流7 | 可行 | 点赞成功后收藏后阅读完文章然后返回 |
3.2. 运行界面截图
3.2.1.扇贝单词单词量测试
3.2.2.百词斩单词量测试
3.2.3.扇贝单词帖子阅读
3.2.4.百词斩帖子阅读
3.3. 测试管理工具
https://www.testin.cn 云测试平台
3.4. 测试管理工具使用的关键界面截图(如测试用例导出、缺陷导出等)
测试用例:
缺陷:
4.结论说明。
4.1单词量测试模块
扇贝单词的单词量测试可以逆推其逻辑与算法过于简单(且其测试结果都是一百的整数倍),测试结果准确率不高;而百词斩的测试逻辑和算法科学性应该更高。
就其反馈来说,百词斩的反馈过于复杂,严重影响用户单词量测试的体验与发挥,即使算法科学性更高,测试结果也不够准。
总的来说在这个模块,这两个APP都做得不够好。用户体验很差。
4.2帖子阅读模块
扇贝单词的精选(帖子阅读)基本能让用户满意,除了评论成功得不到有效反馈,问题还不算严重。
百词斩的小讲堂(帖子阅读)用户界面不错,但是我无法评论,我也得不到有效反馈,不知道无法评论的原因,给用户恶心的体验。
5.工作说明
扩展任务
1.个人工作说明
1.1.设计了单词量测试功能的场景,任务和反馈问题。
场景3:百词斩单词量测试可用性测试
您需要先打开手机,进入百词斩app,点击底部的“复习”功能,点击右上方“我的评测”。在阅读板块点击绿色按钮“测试”。
任务1:在百词斩->复习->我的评测->测试中,完成单词量的测试。
任务1的难度是:2
问题1
你是完成了预测试还是点击了“直接开始测试”?
A.完成了预测试 B.点击了直接开始测试
问题2
你认为计时会影响你作答吗?
A.非常影响 B.较大影响 C.有点影响 D.完全不影响
问题3
你认为显示单词量范围会影响你作答吗?
A.非常影响 B.较大影响 C.有点影响 D.完全不影响
问题4
你看到了“差不多了,看结果之后”吗?你还继续作答了吗?
A.多测了几个之后查看的结果 B.我直接查看了结果 C.没看到,测了几个之后才看到
问题5
你认为测试结果准确吗?
A.非常准确 B.还算准确 C.比较不准 D.完全不准
1.2.完成了一部分可行性测试报告的编写。
问卷地址:http://test.baidu.com/qss/fd1c/455593.html
2.结果
完整结果见可用性测试报告
部分结果:
可以看到,百词斩单词量测试的这些反馈信息对作答是有一定影响的。
3.三次实践作业的看法
第一次(WordCount):无力吐槽... 最耗时间的实现部分与课程无关,导致没有精力做与课程相关的测试部分。同时赶上实习招聘最紧张的时候,忙得吐血,也没什么收获。
第二次(WordCount优化):作业量只有第一次的一半不到,却小组4人作业,功能简单到划分模块都觉得麻烦。作业分配真的合理吗。
第三次(软件测试和评估):走很正规的软件测试流程,深刻了解到软件声明周期中最花费时间和金钱的就是测试。正规到还要进行用户调研和可用性测试,真的很想知道没有工资的情况下去哪里请10多个愿意浪费自己时间免费给你做测试的良心用户,如果有请给我来一打。最后以组员请吃饭为代价邀到了10多个用户。