软件质量与测试第6周小组做业：软件测试和评估

基本任务

一、被测产品：百词斩、扇贝单词。

二、测试进度表

项目	内容说明	预估耗时 （分钟）	实际耗时 （分钟）
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

三、 功能模块图：

 

 我负责学习模块，包括单词查询、学习单词等功能。

四、测试用例：学习模块主要是在肯定使用者词汇量以后，进入学习界面，而后按照软件给定的学习方式进行学习，同时不断地复习巩固。设计测试用例的方法以下：

　　（1）等价类测试：查询单词分为中译英和英译中。单词学习分为点击答案区域和点击非答案区域。查询单词时考虑查询专用单词。

　　（2）边界值测试：查询单词时，输入复合单词，或存在一两个字母的拼写错误的单词（谬误单词），观察查询结果。

　　（3）场景测试：给定场景，设计测试用例，以便覆盖每一个场景，能够考虑一些特定的场景。。

 

这是单词学习的事件流，以开始到结束的一条直线为基本事件流，其它分支为备选时间流设计测试用例。

 

这是单词查询的事件流，以开始到结束的一条直线为基本事件流，其它分支为备选时间流设计测试用例。

五、功能测试：

（1）单词查询测试截图（查询“华中科技大学”，依次为百词斩和扇贝单词）

（2）单词学习测试截图（选择正确答案，依次为百词斩和扇贝单词）

六、测试管理工具：禅道；

     版本号：9.8.3；

     下载连接地址：http://www.zentao.net/download/80072.html

     导出文件（见附件）：需求、测试用例、缺陷；

     界面截图：（依次为执行测试用例、导出测试用例、缺陷）

七、测试结论：两款软件的单词查询功能能知足用户的基本需求，但在一些专有名词上显得有些匮乏。例如在查询“python”时，两款软件都只能获得“巨蟒”这个解释，而不能获得其做为计算机专用名词的一个解释，这对于一些具备特殊需求的用户来讲显然没法知足需求。此外，在查询“华中科技大学”时，百词斩可以准确地将其英文译名显示，但扇贝单词则只能截取其中部分中文进行翻译，而没法将其做为总体进行翻译，这应该算是软件设计的严重缺陷，与竞品的差距也能够体现出来。从用户友好度上来讲，百词斩会保留历史记录，而扇贝单词并无，显然前者会更受青睐。对于学习单词的功能，百词斩很新颖地采用图片四选一的方法来进行学习，而扇贝单词会让使用者选择是否定识该单词。前者较注重寓教于乐，然后者则偏于对单词的深度掌握，两者在这个功能上不分伯仲。从测试状况和我的经从来看，我认为百词斩在查询单词和学习单词上更具优点。

八、基本功能小组贡献分：0.29。（小组状况：17044:0.29;17062:0.21;17064:0.19;17065:0.31）

 

扩展任务

（项目做业和小组贡献率见附件）

八、我的说明：

工做内容：设计测试任务卡，负责第一批次的采访，负责结果统计。

心得体会：经过采访，了解了新用户对于软件的使用状况和见解，也对“百词斩”这款软件的优缺点有哦了更深刻的了解。做为软件测试人员，不能闭门造车，仅仅本身对软件进行评测，要多倾听其余人的意见，进行汇总，才能对软件进行更好的测试。

 

高级任务

（该测试方法无脚本；运行视频见附件，视频内容为测试完成后各部份内容展现；定性和定量分析报告见附件）

九、测试专题：性能测试；

     测试工具：阿里云测。

十、测试设计：经过阿里云平台进行云端测试，从程序安装包的安装速度，程序的运行性能以及程序的后台性能占用程度三个方面来评测软件的性能。

十一、工做感觉：我负责性能测试的执行过程。从测试结果和分析报告中能够看出，百词斩CPU占用率较高，fps较低，电量和内存耗用正常，性能属于中上水平。除去软件自己的创新性，其高性能也是吸引用户的必要条件，毕竟没有人会愿意使用一款使本身手机崩溃的APP。这也给了我启示：软件开发人员不只要会写程序，还要会写高效的程序。

十二、高级任务小组贡献率：0.45。（17044:0.45；17062:0.05；17065:0.50）。

 

附加题

1三、实践做业感觉：

第一次做业断断续续作了四五天，到截止时间前一小时所有写完。最烦的就是需求不明确，频繁改动，老师博客园的例子一开始也是错的，加在一块儿就无从验证本身的算法正确性。并且以老师说会跑代码，觉得会跑得很是严格，就对于无效输入作了不少考虑，最终程序正确性却是满分。可是当时还没开始细讲测试，对测试用例和测试脚本的设计毫无头绪，事实证实设计的确实不到位。原本想用C++作的，由于MFC实现图形界面很方便，但考虑后续做业可能会有影响仍是用了Java（其实根本没影响，不知道老师为何第一次非得让咱们用Java，莫不是需求崩盘因此第二次只能推倒重建）最后来不及了就没作附加题，后来想一想有点不甘，其实也不难。

第二次做业确实是体会到了分组编程的温馨，可是编40个测试用例是真的累，只能说分组要谨慎。需求明确就好写不少，并且简化了需求，还有队友分担输入输出部分，单写核心模块真的是很温馨。测试的时候也找出了本身的设计缺陷。而后了解了一些代码规范，性能优化，代码评审方面的知识，固然我对于左大括号不换行的事实在不能苟同。此次的附加题仍是图形界面，花了不久就作完了，想一想第一次做业就以为很惋惜。

第三次做业，一开始对软件的测试用例想了好久，彻底没想法。测试真是不如编程简单，软件的测试也比单元测试难。后来时间来不及了，只能硬着头作，照着本身的想法来。可用性测试颇有趣，采访用户的确不失为一种很好的测试方法，并且最实用，最能体现核心需求。

总的来讲，三次做业又当编程人员，又当测试人员其实不太好找本身的缺陷，由于会先入为主地认为本身的代码不可能错。这也体现了测试人员的重要性。软件测试的做业也算让我重拾了Java和Github，又学了点测试的知识，显然是有所进步的。另外写博客也无可厚非，可是对着要点来写是不舒服的，比较费时间。

1四、参考文献：

禅道软件使用：http://www.zentao.net/book/zentaopmshelp/38.html

用户调研：http://www.cnblogs.com/xinz/archive/2013/02/03/2890786.html

1五、小组贡献分（一开始没注意是整体算分，现统一更改小组内）：

17044:0.35；

17062:0.15；

17064:0.14；

17065:0.36