测试人
10061163 李雁楠
10061192 张永强
测试软件
必应词典客户端 V 1.6.2 Beta2
测试环境
windows8 64位
第一部分
Bug1：划译功能不正常
使用步骤：1）点击界面右下角划译
2）划取相应文本
bug内容：部分文本不能划译
正确效果截图如下：
bug截图：
1）这是划取工具界面上的句子，没有反应
2）划译功能出现故障时，报错错误，这里产生的错误是取词功能无法正常进行
Bug2：取词功能存在bug
使用步骤：1）点击词典界面右下角取词
2）鼠标选择相应文本
bug内容：无法正确取词。
bug截图：
1）取文本文件中的一部分
2）取网页中内容的一部分
Bug3：发音功能存在bug
操作步骤：打开一个单词，单击左上角的发音按钮
bug内容：不能够发音，或者需要等待较长一段时间才能够发音
bug截图：
Bug4：未知错误
bug截图：
Bug5：两个单词对比后的提示
bug内容，这里点击标签的右上角，应该是展开标签之类的提示，而不应该是关闭标签。
bug截图：
Bug6：皮肤（这一点我不知道能不能够算是bug，不知道是不是设计人员故意这样做的）
bug内容：个人觉得红框中的设计可能存在一点问题，也可能是设计人员本来就是这样打算的。
bug截图：
第二部分
被采访人：孙承根
1）背景：同学，平时主要是在看文献、英语文章以及学习时使用词典。
2）使用过程：
3）使用感受：
孙同学在使用的过程中主要是用这个词典来看一个英文网页。所面对的主要就是一些不认识的词语，解决了问题。
因为软件能够联网查找，所以软件的数据量比较足。但是从这么大的数据量中找到一个想要的就不是很容易了。
在界面上，还是比较满意的，特别是对比这一块，能够较好地看出其中的不同。但是还是感觉有点乱。
功能上，基本上能够满足一般的需要。记单词方面，感觉方式还不是很多样。能够提高。
准确度方面，对于看一般的网页基本上能够完成任务。但是对于专业性较强的一些地方，就差一些了。
4）改进意见：
孙同学觉得可以添加以下专业词汇，能够根据专业整理。这样，对于使用者来说，可能会更方便。比如将该词典与微软学术搜索中的关键词联系起来，这样就专业性上来说是很好的弥补。第二，可以适当增加以下用户使用词典，查询单词方面的学习，记忆功能。比如可以根据用户经常查的但是，当下次用户打开一个网页的时候，如果用户允许，可以事先将经常查找的一些词的意思显示出来。
第三部分
把所有按钮都点击过后，我算是完完整整地试用了必应词典的所有功能（包括背单词）。首先，介绍一下该软件的功能吧，分为查单词和背单词2大部分。然后该软件开发人员对于查单词功能是煞费苦心啊，最实用的就是模糊查询的高准确度，例句的视频朗读以及逐词释义，不过还是有些缺陷，比如词组搭配如果能在右边直接就加上一些常用词义（不需要所有词义），或许会让用户更方便些。对于背单词的功能的话，稍显鸡肋，背诵方法单调，算法简单，不及查单词功能的十分之一。而界面是最有意思的，登陆界面是相当的绚丽多彩，然而试用起来却略显寒酸，有点虎头蛇尾的意味，不过词典最重要的还是查单词嘛，重心在查单词上也是无可厚非的。不过觉得最奇怪的是明明有取词按钮，却不知道如何使用，貌似功能介绍也没有提及。个人认为取词功能还是很重要的。
若是非要估算个开发周期的话。假设一个6人大学毕业生团队，时间充足，每天都有8个小时的工作时长，而且有双休日和正常假期，即每周平均工作时间50个小时/人。（1）分析需求，确定功能的话，至少就需要一周的时间。（2）实现功能时，首先最普通的查单词功能实现要一周的话（已有词库的条件下），再加上近似查询，词-词性-词型查询等多种查询方式都实现至少需要两周以上。然后例句，同义词，近义词，词组搭配等等实现也要两周。（最亮的视频朗读功能不知如何估算时间，姑且不计）。此外，实现标签，对比，全文翻译等等也需要不止两周。综上，光是没有实现视频朗读功能的背单词就需要5周时间。实现背单词和生词本功能的话，估计4周之内能完成。故，排除视频朗读功能，在比较顺利的情况下，也需要三个月的时间才能实现。
优点：视频朗读，还有模糊查询的高准确度
劣：背单词功能稍显粗糙，没有取词功能
建议：很明显，开发人员着重于帮助使用者理解英文，而非对付考试，那么就把这个做的更加完美，让别的产品无法企及，我觉得不能取词太糟糕了，假如我在阅读英文文献，那么我为了提高阅读效率，会想着是否有工具能在我遇到生涩词汇或复杂句子时帮助理解，所以我觉得是不是可以在其它平台（如网页，PPT等）上实现这些功能。
第四部分
假如我是PM，那么我觉得首先要去看别的软件实现的功能，特色等，然后调查可能需求人群，怎样的功能才是他们需要的？
目前市场上类似的产品蛮多的，比如有道，金山词霸等等。说实话，在信息的完整性上，现有的必应已经很有优势了，不过我觉得，譬如对于我，一个在校大学生来说，我不太需要这么完整的信息，一般都是在阅读外国文献时或是在一片汉字中看到一个不懂的英文单词时需要查，而我的选择多半是打开百度（因为我这个时候是在浏览网页，打开百度比打开词典快多了）。这很能说明问题，我觉得可以弄个比较简洁的类似于小插件或是小工具，而非一个完整的应用，或许大家会更乐意于用。这样显得简洁，小巧，方便，而且占内存少，还不影响用户阅读效果。或许并无创新，此处单从其实用性分析。
假如我的团队有5个人（不包括我），那么我会让一人美工，一人负责测试，其它三人进行开发（让开发者自己做单元测试）。
若要在12周时交任务，按照经验，首先，第一周的时间无可厚非的就是需求分析，功能分析及排序（这个很重要，后面时间不足则可适当舍弃次要的），然后制定一个10周的开发计划（没有算错，按经验，最后推迟一周的时间已成必然，加起来正好12周）；2周的时间开发出一个简易的可用的第一版本的程序，界面可以粗糙些，不过必须有，适当测试也需要做；5周的时间去添加其它功能，如全文翻译，出第二版本，这时的界面应该已经成形；然后2周的时间，把一些小功能补充完整，如同义词等等，这里的测试人员应该已经开始一起工作了，并适当提出修改意见供开发者修改，美工要实现换肤功能；然后一周的时间是进行发布前的整体的准备（多出的一周是以防万一的缓冲时间）。