一、Alpha版本测试报告
1. 在测试过程中总共发现了多少Bug？每个类别的Bug分别为多少个？
| BUG名 | 修复的BUG | 不能重现的BUG | 非BUG | 没能力修复的BUG | 下个版本修复 |
|---|---|---|---|---|---|
| 文件路径的表示 | √ | ||||
| 无法输出列表/字典中的中文 | √ | ||||
| 中文url的编码 | √ | ||||
| 根据xpath找不到元素 | √ | ||||
| 写文件覆盖原内容 | √ | ||||
| json字符串存中文乱码 | √ | ||||
| tablewidget输出中文乱码 | √ | ||||
| 自动生成button卡死 | √ | ||||
| json读写模块引入错误 | √ | ||||
| pyc文件导致修改代码无效 | √ | ||||
| 总计 | 4 | 1 | 4 | 1 | 0 |
2.场景测试
- 小明：
小明是一个资深动漫爱好者，他一周要追10部以上的动漫，每天更新什么动漫，这部动漫再哪个平台上观看这些考记忆力的东西让小明头痛不已。小明通过我们的软件，把他追的动漫添加进关注列表里，每天打开我们的软件就能知道更新情况了。 - 小刚：
小刚是一个刚入门的动漫爱好者，他看动漫的目的是在闲暇之余放松自己。但是经常不知道去哪看什么时候看，小明的烦恼在使用我们的软件之后就没有了，他只用在搜索框搜索想看动漫的名称，之后只用每天打开软件查看更新情况就行了。
3.测试矩阵
- spider
| 测试项 | 检验点 | 预期结果 | phantomjs(headless) | firefox | chrome | edge |
|---|---|---|---|---|---|---|
| 打开url | 打开一个窗口 | 窗口打开并加载 | √ | √ | √ | √ |
| 定位元素 | 根据元素的xpath定位 | 成功定位 | √ | √ | √ | √ |
| 模拟鼠标左键点击 | 找到元素并使用click方法 | 点击事件成功响应 | √ | √ | √ | √ |
| 获取元素属性 | 找到元素并使用get_attribute方法 | 成功找到属性 | √ | √ | √ | √ |
- handleJson
| 测试项 | 检验点 | 预期结果 |
|---|---|---|
| 添加数据 | 数据唯一性 | 同一组数据只能添加一次 |
| 删除数据 | 删除指定属性的数据 | 成功删除 |
| 修改数据 | 修改指定属性的数据 | 成功修改 |
| 文件不存在时添加数据 | 新建文件 | 成功添加 |
| 文件不存在时删除数据 | 无法删除 | 抛出异常 |
| 文件为空时删除数据 | 无法删除 | 抛出异常 |
- GUI
| 测试项 | 检验点 | 预期 | win7 | win8 | win10 |
|---|---|---|---|---|---|
| 主table | 显示效果 | 可以显示 | √ | √ | √ |
| 添加订阅PBT | 点击 | 在sublist.txt内添加订阅 | √ | √ | √ |
| 重新抓取PBT | 点击 | 根据sublist.txt生成抓取json | √ | √ | √ |
| 刷新 | 点击 | 点击按钮后刷新table | √ | √ | √ |
| 删除按钮 | 点击 | 在txt和json删除对应的项并刷新 | √ | √ | √ |
4.出口条件
我们的出口条件是，能在各种条件下修改（增、删、改）订阅列表而程序不会报错，且能够通过文件里的数据来更新订阅列表。
二、Alpha版本发布说明
1.功能
- 搜索动漫名并添加订阅列表
- 修改订阅列表
- 更新最新集数
- 显示订阅动漫信息（观看地址、最新集数）
2.运行环境要求
- 防火墙允许phantomjs连接网络
- RAM 2G以上
- win7/win8/win10操作系统均可
3.安装方法
不需要安装直接运行exe文件即可。
4.系统已知限制和问题
- phantomjs消耗内存在100-200MB之间，这个我们无法控制。
- phantomjs相当于一个浏览器，所以爬虫比较耗时（跟网速相关），这个也没有办法因为运行js渲染的页面只有这一种办法。
5.软件发布方式及地址
可运行的exe文件届时会发布在github项目地址上。
项目地址
三、Alpha阶段小结
1.团队的仓库源码地址
2.Alpha回顾过程
团队项目的目标
我们把让各种对动漫感兴趣的用户，使用我们的软件能够尽情享受动漫带来的乐趣摆脱看动漫的过程中遇到的一些烦恼。预期典型用户
| 姓名 | 小明 |
| 性别 | 男 |
| 职业 | 学生 |
| 知识层次和能力 | 武汉大学硕士 |
| 动机、目的、困难 | 动机、目的：喜欢看动漫 困难:记住不所追的动漫的更新日期及观看平台以及自己看到了哪一集 |
| 用户偏好 | 同时追多部动漫 |
| 用户比例 | 40% |
| 典型场景 | 想放松自己的时候忘记了想看动漫的观看平台 |
团队项目如何满足了用户的需求？
我们通过搜索并把相关信息添加到订阅列表的功能，让用户只用一次操作，以后都只用打开软件就能获取信息的方式，没有多余的操作，简单易用。- 团队在Alpha阶段完成了哪些目标？
- 搜索动漫名并添加订阅列表 √
- 修改订阅列表 √
- 更新最新集数 √
- 显示订阅动漫信息（观看地址、最新集数）√
团队成员是如何分工协作的？有什么经验教训？
PM：负责组织开会、反馈、分配任务、撰写文档
dev：负责具体的开发
test：负责测试
我们没有做好风险控制工作，在有团队成员出差后我们的一度手忙脚乱，原定的计划都被打乱，下次会把这种突发情况考虑进去。还有就是我们的分工协作上存在欠缺，有些同学任务太重，等发现的时候已经晚了，因为这时候其他人再介入反而起不到加快进度的作用，其他同学只能做一些辅助性的工作。下次我们会好好考虑任务的难度已经同学自身的能力问题。团队是如何进行项目管理的？
具体的管理事宜都是pm进行的，因为pm没有分配开发任务。但是这样单向的管理有风险，就是如果Pm有突发情况，其他人根本无法接手她的工作，这也是这次项目的一个共性，大家都只顾着自己的事情，没有主动出来分担其他人的任务。团队如何平衡 时间/质量/资源争取如期完成任务的？
因为存在beta版，所以我们优先保证质量，尽量不出bug。这样一步一个脚印在beta版的时候才能更好的加新功能。所以我们并没有一味的追求速度，因为代码不是一个人在写，难免在沟通上出现问题，写太快反而可能你给的接口对方用不了。团队项目的实际进展（拷贝那些 scrum 过程中的燃尽图即可），发布的功能（拷贝发布文档）。说明在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？
我们的燃尽图没有做好，我们没有以开发周期为单位而是以天为单位，所以燃尽图的波动范围很大，这一点是我们的失误，但是可以看出我们每天的计划基本上都完成了。beta阶段我们会注意这个问题团队成员在Alpha阶段的角色和具体贡献
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 黄亦薇 | PM | 18 | 撰写文档 |
| 赵坤 | dev | 26 | 爬虫处理json的代码编写 |
| 李世钰 | dev | 24 | GUI界面编写，整合代码 |
| 王成科 | test | 12 | 测试 |
- Beta
beta版计划我们主要想解决，爬虫速度问题，现阶段的问题是爬虫必须要等到页面完全加载完毕才能继续，也就是阻塞型的。但是我们知道这完全没有必要，因为我们只需要页面的一部分信息，举个例子，打开一个网页，如果浏览器标签栏那个圈在转就说明网页没有加载完毕，但是网页的大部分内容已经出来了。所以说时间大都浪费在这个上面了，如果能优化的那么速度会大幅度提高，用户体验会更好。还有就是，我们继续考虑历史记录以什么样的方式来和用户交互，这个星期时间比较紧这个需求就被暂时搁置了，在Beta阶段我们会继续考虑的。 团队项目的实际进展（拷贝那些 scrum 过程中的燃尽图即可），发布的功能（拷贝发布文档）。说明在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？