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 |
扣分项 | 博客提交延误共计-5 | - | - | 代码规范延误-2 | 打包延误-0.8 |
投票 | 3 | 3 | 2 | 2 | 2 |
最终贡献分 | 52 | 54 | 49 | 47 | 48 |
5.总结和展望
学到的东西:
-
技术上更加规范,熟悉团队协作的模式。
-
相互磨合和包容。
beta阶段初步计划:
-
进一步优化界面
-
增加更多可能的操作
-
增加对操作的编辑性,比如可以点击位置可以设置多个
-
进一步对游戏异常的识别进行改进