基本任务
1、被测产品：百词斩、扇贝单词。
2、测试进度表
| 项目 |
内容说明 |
预估耗时 （分钟） |
实际耗时 （分钟） |
| Planning |
1.计划 |
30 |
20 |
| · Estimate |
· 估计这个任务需要多少时间 |
30 |
20 |
| Testing Design |
2.测试设计 |
120 |
180 |
| · Analysis |
· 需求和测试需求分析 |
60 |
90 |
| · Design Test Cases |
· 设计测试用例 |
60 |
90 |
| Testing Environment |
3.搭建测试环境（安装测试工具、管理工具等相关运行和支撑软件） |
30 |
60 |
| Testing Implementation |
4.测试实施 |
60 |
60 |
| · Test |
· 执行测试 |
60 |
60 |
| Reporting |
5.报告 |
60 |
60 |
| · Test Report |
· 测试报告 |
40 |
40 |
| · Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
20 |
20 |
| 合 计 |
300 |
360 |
|
3、 功能模块图：
我负责学习模块，包括单词查询、学习单词等功能。
4、测试用例：学习模块主要是在确定使用者词汇量之后，进入学习界面，然后按照软件给定的学习方式进行学习，同时不断地复习巩固。设计测试用例的方法如下：
（1）等价类测试：查询单词分为中译英和英译中。单词学习分为点击答案区域和点击非答案区域。查询单词时考虑查询专用单词。
（2）边界值测试：查询单词时，输入复合单词，或存在一两个字母的拼写错误的单词（谬误单词），观察查询结果。
（3）场景测试：给定场景，设计测试用例，以便覆盖每个场景，可以考虑一些特定的场景。。
这是单词学习的事件流，以开始到结束的一条直线为基本事件流，其它分支为备选时间流设计测试用例。
这是单词查询的事件流，以开始到结束的一条直线为基本事件流，其它分支为备选时间流设计测试用例。
5、功能测试：
（1）单词查询测试截图（查询“华中科技大学”，依次为百词斩和扇贝单词）
（2）单词学习测试截图（选择正确答案，依次为百词斩和扇贝单词）
6、测试管理工具：禅道；
版本号：9.8.3；
下载链接地址：http://www.zentao.net/download/80072.html
导出文件（见附件）：需求、测试用例、缺陷；
界面截图：（依次为执行测试用例、导出测试用例、缺陷）
7、测试结论：两款软件的单词查询功能能满足用户的基本需求，但在一些专有名词上显得有些匮乏。例如在查询“python”时，两款软件都只能得到“巨蟒”这个解释，而不能得到其作为计算机专用名词的一个解释，这对于一些具有特殊需求的用户来说显然无法满足需求。此外，在查询“华中科技大学”时，百词斩能够准确地将其英文译名显示，但扇贝单词则只能截取其中部分中文进行翻译，而无法将其作为整体进行翻译，这应该算是软件设计的严重缺陷，与竞品的差距也可以体现出来。从用户友好度上来说，百词斩会保留历史记录，而扇贝单词并没有，显然前者会更受青睐。对于学习单词的功能，百词斩很新颖地采用图片四选一的方法来进行学习，而扇贝单词会让使用者选择是否认识该单词。前者较注重寓教于乐，而后者则偏于对单词的深度掌握，二者在这个功能上不分伯仲。从测试情况和个人经历来看，我认为百词斩在查询单词和学习单词上更具优势。
8、基本功能小组贡献分：0.29。（小组情况：17044:0.29;17062:0.21;17064:0.19;17065:0.31）
扩展任务
（项目作业和小组贡献率见附件）
8、个人说明：
工作内容：设计测试任务卡，负责第一批次的采访，负责结果统计。
心得体会：通过采访，了解了新用户对于软件的使用情况和看法，也对“百词斩”这款软件的优缺点有哦了更深入的了解。作为软件测试人员，不能闭门造车，仅仅自己对软件进行评测，要多倾听其他人的意见，进行汇总，才能对软件进行更好的测试。
高级任务
（该测试方法无脚本；运行视频见附件，视频内容为测试完成后各部分内容展示；定性和定量分析报告见附件）
9、测试专题：性能测试；
测试工具：阿里云测。
10、测试设计：通过阿里云平台进行云端测试，从程序安装包的安装速度，程序的运行性能以及程序的后台性能占用程度三个方面来评测软件的性能。
11、工作感受：我负责性能测试的执行过程。从测试结果和分析报告中可以看出，百词斩CPU占用率较高，fps较低，电量和内存耗用正常，性能属于中上水平。除去软件本身的创新性，其高性能也是吸引用户的必要条件，毕竟没有人会愿意使用一款使自己手机崩溃的APP。这也给了我启示：软件开发人员不仅要会写程序，还要会写高效的程序。
12、高级任务小组贡献率：0.45。（17044:0.45；17062:0.05；17065:0.50）。
附加题
13、实践作业感受：
第一次作业断断续续做了四五天，到截止时间前一小时全部写完。最烦的就是需求不明确，频繁改动，老师博客园的例子一开始也是错的，加在一起就无从验证自己的算法正确性。而且以老师说会跑代码，以为会跑得非常严格，就对于无效输入做了很多考虑，最终程序正确性倒是满分。但是当时还没开始细讲测试，对测试用例和测试脚本的设计毫无头绪，事实证明设计的确实不到位。本来想用C++做的，因为MFC实现图形界面很方便，但考虑后续作业可能会有影响还是用了Java（其实根本没影响，不知道老师为什么第一次非得让我们用Java，莫不是需求崩盘所以第二次只能推倒重建）最后来不及了就没做附加题，后来想想有点不甘，其实也不难。
第二次作业确实是体会到了分组编程的舒适，但是编40个测试用例是真的累，只能说分组要谨慎。需求明确就好写很多，而且简化了需求，还有队友分担输入输出部分，单写核心模块真的是很舒适。测试的时候也找出了自己的设计缺陷。然后了解了一些代码规范，性能优化，代码评审方面的知识，当然我对于左大括号不换行的事实在不能苟同。这次的附加题还是图形界面，花了不久就做完了，想想第一次作业就觉得很可惜。
第三次作业，一开始对软件的测试用例想了很久，完全没想法。测试真是不如编程简单，软件的测试也比单元测试难。后来时间来不及了，只能硬着头做，照着自己的想法来。可用性测试很有趣，采访用户的确不失为一种很好的测试方法，而且最实用，最能体现核心需求。
总的来说，三次作业又当编程人员，又当测试人员其实不太好找自己的缺陷，因为会先入为主地认为自己的代码不可能错。这也体现了测试人员的重要性。软件测试的作业也算让我重拾了Java和Github，又学了点测试的知识，显然是有所进步的。另外写博客也无可厚非，但是对着要点来写是不舒服的，比较费时间。
14、参考文献：
禅道软件使用：http://www.zentao.net/book/zentaopmshelp/38.html
用户调研：http://www.cnblogs.com/xinz/archive/2013/02/03/2890786.html
15、小组贡献分（一开始没注意是总体算分，现统一更改小组内）：
17044:0.35；
17062:0.15；
17064:0.14；
17065:0.36