1.团队成员简介及个人博客地址
| 岗位 | 人员&博客 | 介绍 | 照片 |
|---|---|---|---|
| PM | 木鬼 | - 计算机系大三 - 编码能力不强，稍微擅长写文档 - 咸鱼，死宅 - 希望能学到更多东西 |
 |
| 测试 | bhlt | -计算机系大三 - 喜欢运动 - 喜欢看球赛 - 不喜欢写作业。。 |
 |
| 开发 | dsz | - 肥宅 - 喜欢运动，偶尔也打打游戏，希望和队友的合作愉快，也希望自己能为团队做贡献… |
 |
| 开发 | swoip | - 目前专业水平还不是很高,但愿意向队友们多学习 - 希望在团队协作的过程中提高自己的水平，丰富自己的经历 - 平时喜欢玩游戏，也希望可以向游戏开发方向发展。 |
 |
| 开发 | SiMrua | - 好好休息，天天早睡 - 做好计划里的每一份工作 - 希望在团队项目中收获新的知识 |
 |
2.工程相关信息
我们的用户
需求
之所以会做这样一个项目，第一是我们组内或多或少对游戏有一定的接触，其次是我们其中一位组员有安卓游戏的开发经验，这促进了我们选择这个项目。结合现状，目前测试仍然是一件很麻烦的事情，尤其对于手游的黑箱测试需要手动操作，如果使用各种如我们采用的monkeyrunner之类的测试工具，需要付出些许学习成本，且测试都需要自己编写脚本，相当麻烦；又或者找到网络上的付费服务，这又是另一方面的付出了。如果能做出一个直接编辑测试序列的工具，省去学习和编写，自动报错，那么测试起来就会方便很多。
典型用户
用户 开发者A 身份 不知名安卓游戏的开发者 年龄 25岁 重要性 非常重要，所占比例较大，对本产品需求较高 使用场景 测试产品，修改提高产品质量 使用环境 工作室、办公室、家中 工作/生活 工作就是开发，生活就是工作，压力较大 知识层次/能力 熟悉计算机相关知识，有一定的实践经验，但总的开发经验不足 动机/目的 提升产品质量 用户偏好 希望能精准的测到问题，精准的报告问题 用户 学生C 身份 大学计算机系/软件学院学生 年龄 20岁 重要性 比较重要，所占比例较大，对本产品需求较高 使用场景 测试产品，修改提高产品质量 使用环境 图书馆、教室、宿舍、家中 工作/生活 在实践中学习，为将来打下铺垫 知识层次/能力 掌握基本的计算机相关知识，实践经验不足 动机/目的 学习、完成作业、参赛获奖等 用户偏好 主要用于检查、完善自己的作业/作品 预期功能和用户数量
通过连接手机或者模拟器，对连接设备设置测试序列，测试开始后能够对异常状态进行识别，并生成报告，报告将显示在捕获异常前的操作以便用户进行判断和定位bug。
由于时间有限，alpha阶段应该功能还不够完备，基本功能可以使用但是操作体验可能不是非常好，预计用户较少，期望用户达到50人。
下载量
分工协作及经验教训
团队只有5名成员，其中4位担任开发，1位担任PM，其中一位开发和PM进行主要的测试。
开发工作总共分为4个部分，一部分是前端界面绘制，一部分是报告方面的生成，一部分是模型训练以进行异常捕获，一部分是对用户使用的测试脚本的编写。
任务划分好了之后由PM每天派发任务给对应的组员，组员如有情况需及时向PM进行反馈，在没有意外的情况下每次例会需完成上一次的任务。
出现临时任务或者重大难题时，将问题分配给工作较少的或者能力较强的组员，以免进度滞后。
由于大三的各种安排，组员们较为繁忙，因此任务分配需要明确具体，任务分解到个人，目标明确并带有DDL。在冲刺阶段结束后的测试稳定阶段，由于没有了明确的任务以及PM监督不力，导致了测试阶段有懈怠，此引以为戒。
项目管理
使用Github进行项目管理，利用GitHub的issue来分解分配任务。
平衡时间/质量/资源的对策
- 在忙于其他课程的时候，安排任务难度和工作量相对较少的任务，实在有困难当天不安排任务。
- 优先完成功能清晰明确的任务，将对接任务放到后面，但是这需要做好接口定义，这一点没有做好。
- alpha阶段重视功能多余用户体验和界面美观。
- 在最后将不重要且不常用的功能舍弃。
在产品之外，团队代码的软件工程质量如何？如何用数据来证明？
对使用工具进行测试不熟悉，没有这个方面的的相关测试，测试是黑盒测试，通过运行完成的程序来进行。
代码规范
原来的项目有些代码混乱，没有注释，没有详细的文档，你们的项目是如何更好解决这个问题的？
我们有详细的代码规范，对注释也有很高的要求，详见上一问。
3.项目的实际进展
燃尽图
燃尽图是第10次scrum meeting的燃尽图，真实反映了当时的工作情况，最后剩余的几个工作是开的有关测试的issue，所以当时还未完成，基本的开发工作在第10次会议时已经完成。中间空的一长条是由于清明节没有及时整理issue导致的。
发布的功能
- 解压即可直接使用
- 内置功能说明，点击引导，弹出引导界面对各个功能进行简易说明
- 连接真机或模拟器皆可，等待窗口出现提示"start"后，选择连接设备，稍加等待即可连接成功。
- 编辑测试队列模拟用户行为对游戏进行测试，现阶段包含最基本的指定位置点击、随机点击、指定位置划动、随机滑动四种基本行为。
- 自动识别可能存在的异常并报告，生成在当前文件目录下的exception_x.txt，x是数字编号，内容为记录的异常前进行的操作。
发布地址
由于是离线的桌面程序，为了统计用户，使用下载量代替用户数，利用百度云的分享统计获得下载量，百度云，提取码：hc3c，或者使用小程序码如下：
用户反馈
关于误报这一点，由于是直接计算截图间的距离，所以现阶段还没有好的解决办法，对于卡死和卡顿确实分不清。
关于通用性是将在下一阶段的内容，主要增加各类游戏进行测试。
文件的目录方面确实是考虑不周了。
4.团队成员的角色和具体贡献
| PM/Test | Dev/Test | Dev | Dev | Dev | |
|---|---|---|---|---|---|
| 木鬼 | bhlt | swoip | dsz | SiMrua | |
| 组织例会，催促项目进度 | 学习monkeyrunner | 学习monkeyrunner | 完善代码规范 | 寻找并训练识别模型 | |
| 每日例会报告 | 编写简单测试用例单独测试 | 主界面绘制 | 测试界面绘制 | 利用模型捕获异常 | |
| 管理Github项目issue情况 | 编写模拟用户行为的单独测试 | 引导界面绘制 | 测试记录生成、显示、优化 | 优化模型 | |
| 完成大部分博客整理 | 封装测试用例提供组合 | 引导撰写 | 将测试记录转化为测试报告 | 对工程进行封装 | |
| 进行宣传和反馈收集 | 暂停、终止功能 | 界面美化 | 异常处理 | 建立模型再训练数据 | |
| 编写socket对接 | 对接前后端 | 异常检测到的实时提示 | |||
| PM评价工作量*难度 | 1.5*0.9 | 1.2*1 | 1.2*0.9 | 1*1 | 0.9*1.1 |
| 讨论 | 1.5*0.9 | 1.2*1 | 1.2*0.9 | 1*1.05 | 0.9*1.1 |
| 投票 | 3 | 3 | 2 | 2 | 2 |
| 最终贡献分 | 52 | 54 | 49 | 47 | 48 |
5.总结和展望
学到的东西：
技术上更加规范，熟悉团队协作的模式。
相互磨合和包容。
beta阶段初步计划：
进一步优化界面
增加更多可能的操作
增加对操作的编辑性，比如可以点击位置可以设置多个
进一步对游戏异常的识别进行改进