一.基本功能
1.1 计划说明
(1)对比测试产品
产品A:扇贝单词
扇贝单词是当下年轻人广泛使用背单词app,使用智能启发式的学习方法,通过循循善诱,可帮助用户对单词进行学习或复习。其中扇贝打卡逐渐成为微信朋友圈风气之一。
产品B:百词斩
百词斩是一个广受新手好评的背单词软件,因其为每一个单词提供了趣味的配图和例句,让记单词成为一种乐趣,故许多用户以“有趣”作为这个软件的基本评价。
(2)测试进度表
项目 |
内容说明 |
预估耗时 (分钟) |
实际耗时 (分钟) |
Planning |
|
40 |
30 |
· Estimate |
· 估计这个任务需要多少时间 |
40 |
30 |
Testing Design |
|
90 |
110 |
· Analysis |
· 需求和测试需求分析 |
30 |
30 |
· Design Test Cases |
· 设计测试用例 |
60 |
80 |
Testing Environment |
|
40 |
50 |
Testing Implementation |
|
90 |
120 |
· Test |
· 执行测试 |
90 |
120 |
Reporting |
|
70 |
60 |
· Test Report |
· 测试报告 |
40 |
30 |
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
30 |
30 |
合 计 |
330 |
370 |
1.2 需求说明
(1)功能模块划分图
根据百词斩界面将软件划分为如下几个功能模块。
(2)本人负责功能模块
在这个百词斩的功能测试中,我负责复习模块以及用户模块,而在扇贝单词中,我主要负责用户模块以及复习模块。
1.3 测试说明
(1)测试用例设计思路
按照我们所学的课程内容,我们学过了黑盒测试,白盒测试,单元测试,集成测试,功能测试,系统测试等测试方法,在这次作业中,我们有必要综合之前的测试思想,缩小测试成本,扩大测试覆盖,测试用例设计思路主要体现在在正常使用两个软件一定时间之后,通过观察我所负责的功能模块,复习模块测试用例主要的设计思路有:
a. 等价类测试
在相同数量的待复习单词情况下,点选不同的测试方案
b. 边界值测试
选择0,1个待复习单词,看看复习计划的完成是否符合预期
c. 场景测试
基于不同场景设计不同测试用例以完成场景的覆盖。
用户模块测试用例设计思想则包含如下
a. 边界测试
输入为程序边界时,观察程序的反应
b. 等价类测试
点选不同按键,测试程序是否可以正常运行
(2)功能测试运行截图
单词量评测界面,不难看出可以正常运行
在复习模块中有不少子模块,经测试,均可以正常使用。
边界值测试,分别对应需要复习单词数为0或1的情况,可以看出,程序给出了合理反馈。
上述场景图描述了复习功能模块所涉及的大致场景,子功能模块并未细分,主要针对划分的场景进行场景测试,另附上单词原意界面。
上图是个人管理模块的运行截图,下图另附扇贝单词的个人界面的运行截图:
(3)测试管理工具
版本:9.8.3
下载地址: http://www.zentao.net/article-browse-1067.html
(4)工具使用关键截图
如图所示,分别是百词斩和扇贝单词的测试用例表,通过情况各有不同
1.4 结论说明
作为两个在用户群体中有较高人气的单词软件,百词斩和扇贝单词显然没有明显的bug,美中不足的是扇贝单词没有自己的复习界面,复习过程高度依赖程序的算法,相对百词斩定制程度较低,一定程度上算不上那些喜欢自己设置复习计划的单词老手的选择。而百词斩在交互层面,逻辑层面没有明显的硬伤,根据我的测试,发现在复习模块中存在加载时间过长的情况,如下图所示:
而且在性别差异化层面,百词斩做的仍然不够,在个人管理界面中可以设置自己性别,但是除了交互时称谓有区别,其他的貌似并没有不同,比如在个人管理中心的编辑词书中,不知百词斩是想营造江湖大侠的感觉还是出于其他原因,对话框中的用户选项比较粗野,对于“少侠”称谓的男性用户,“废话!删掉”相对可以接受(虽然我是个男的,我还是觉得粗鄙了一点),对于“女侠”称谓的女性用户,对话框仍没有改变则显得不合时宜,对比隔壁扇贝单词,别人没有做性别选项,也就没有这个问题,具体问题如下所示:
综上所述,很显然在系统完备性上百词斩更胜一筹,包含了复习等功能,复习也是有诸多复习方法可供选择,可定制化程度也更高,扇贝单词系统界面简单直观,明显更适合短平快的用户使用,对应用深度也没有过多执念,对于定制化要求高的的用户,可以选择百词斩,对于日常简单实用的用户,扇贝明显效率更高。经过我的测试,也发现扇贝十分明显的缺点:没有收藏夹,这一点在网上反馈普遍,亟待改进。
最后的最后,在敏感头像和用户名方面,两者都没有很好的审查力度,这点需要厂商注意。
1.5 工作说明
本人的小组贡献分:0.25
二. 扩展任务
扩展任务部分与照片详见所提交的可用性测试报告。
三. 高级任务
3.1 测试专题和测试工具说明
测试专题:移动测试
测试工具:阿里云测
3.2 测试设计核心思想
本次主要针对移动测试中的兼容性测试对两款APP进行测试,即检测两款APP对于不同的手机机型是否能够做到完全兼容进行测试。所以,我们使用阿里云,将两款APP对现在主流的30款手机机型进行测试,查看其兼容性,以下为运行中的截图,详细的运行过程请看上传的视频:
3.3 个人感受
在高级任务中,按照老师的说明,我们是要使用专题测试的思想,并选择一种测试工具展开专题测试,我们出于时间的考虑,并未采用代码编写复杂的测试方式,转而使用阿里云进行兼容性测试,其中,测试结果如下图
接下来是扇贝单词的测试结果:
不难看出,两款APP即使不可以完全兼容所有的手机机型,但是手机兼容率仍然是较高水平(>80%),且不兼容的多为老旧机型,足以说明厂商在兼容性上付出的努力。
个人认为,在自己以往的应用使用经历中,兼容性从来都不是小问题,如果存在这类问题,在应用商店评论区早就炸开锅了,可以见得这是一个很重要的需要纳入考虑的部分,作为乙方,十分有必要进行完备的兼容性测试,至少要保证应用在主流机型上拥有完备的兼容性,才可以更好地满足用户需求。
3.4 三次作业总结体会
经过了这三次作业,我的能力有了长足的提升,可以体现在如下几点:
(1)代码能力增强,在oldbook大佬的帮助与指导下,我的代码能力相比以前有了不少提升,虽然可能还是不能像他那么厉害,不过对我自身而言已经是突破,也开始有了一定自信,了解了一些代码技巧以及编程理念,这都是我从来没接触过的,大致是因为这门课要求紧,我自己也意识到了紧迫性。
(2)代码规约意识形成,在此之前,我从没如此接近大佬,作业也是水一水,函数,包名都是乱写一气。不过这一次老师课程要求高,抓得紧,和队友的配合比以往任何一次都要紧密,虽然辛苦,但是和同学形成了坚实的队友情,着实难能可贵
(3)工具的接触,接触了很多有趣的工具,虽然只是限定一定范围的函数集,但是至少建立起了信心,有助于以后的发展。
(4)作业量讲句实话,在队友和自己的努力下,适中。每个人各司其职,精诚合作,并不像许多同学反映的那样难那样多那样烦。
(5)养成博客撰写的习惯,博客园上有很多的他山之石,值得我们借鉴参考,这次作业,会让我们一部分人养成博客的习惯,也算是一种财富吧。
(6)提一点欠佳的地方,就是作业的需求希望可以在布置下来的时候得到清晰的说明,而不是在群里面一直讨论,或者说像第一次那样改了一次又一次。
(7)自己在软件开发这条路上还有很长的路要走,很荣幸成为老师的学生,这节课我会一直记得的,也想一直以来辛苦的老师,助教表示敬意,改变现有的状况总归是艰难的,感谢诸位的付出与努力,Salute!
3.5 工作说明
本人的小组贡献分:0.25