Alpha阶段项目展示

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来分解分配任务。

  Github仓库链接

• 平衡时间/质量/资源的对策

  • 在忙于其他课程的时候，安排任务难度和工作量相对较少的任务，实在有困难当天不安排任务。
  • 优先完成功能清晰明确的任务，将对接任务放到后面，但是这需要做好接口定义，这一点没有做好。
  • 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阶段初步计划：

• 进一步优化界面

• 增加更多可能的操作

• 增加对操作的编辑性，比如可以点击位置可以设置多个

• 进一步对游戏异常的识别进行改进

转载于:https://www.cnblogs.com/buaatbxl/p/10754133.html