第6周小组作业：软件测试和评估
一.基本功能
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
下载地址：
（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
