标签：用户 冲刺 Beta 开发 记账 测试 答辩 服务器 Bug
一、设想和目标
1.项目简介
项目背景：随着支付手段及购物场景的日趋多样化，人们对于自己的开支消费未能有着很好的整体把握，而单纯的采用记事本记账，条目繁多而杂乱。用户对于收支记账有着较大的需求。而专业的记账软件，通过良好的归类和便捷的记账功能，让用户方便的记下自己的每一笔开支，并且通过图表形式，清晰的了解自己的收支情况和变化趋势。
项目意义：一款个人记账软件，通过精细的分类、简化的操作流程和优质的报表界面，让用户更清楚的了解到自己的消费习惯，提高自己的理财意识。
解决问题：1.解决记事本记账或纸质账本记账麻烦的操作和数据丢失的风险
2.为用户提供简单方便的记账功能和可视化的数据统计展示功能
3.让用户知晓每一笔钱的去向并让用户通过记账对自己的消费结构有一个清晰的认识， 进而形成良好的消费习惯和理财意识。
2.beta 冲刺目标与完成情况
Android：
- [✅] UI美化
- [✅] Bug修复
- [✅] 功能完善（文件记账，从服务器恢复数据等）
- [✅] 人机交互优化（适当时提示等）
- [✅] 安全性完善（数据传输、保存等）
- [✅] 更详细的测试
Web:
- [✅] UI美化
- [✅] Bug修复
- [✅] 功能完善（文件记账，从服务器恢复数据等）
- [✅] 人机交互优化（适当时提示等）
- [✅] 安全性完善（数据传输、保存等）
- [✅] 更详细的测试
iOS:
- [✅] UI美化
- [✅] 人机交互优化（适当时提示等）
- [✅] 安全性完善（数据传输、保存等）
- [✅] 更详细的测试
- [❌] Bug修复
- [❌] 功能完善（文件记账，从服务器恢复数据等）
3.完成情况评价
Android：
预定功能基本完成，UI界面简洁美观，在交付使用情况下的BUG也基本消除。
Web：
读取支付宝，银行卡账单完成，UI美化界面完成。交付交付使用情况良好。
iOS：
基本功能完成，没有和服务器进行互通，遇到金额输出时，Float类型不精确问题，完成度不理想。原因：1.对iOS开发网络通信不了解，学习周期较长，在规定时间内没有快速的吸收。2.对Swift基本数据类型了解不是很清楚，导致出现数据输出错误。
二、设计和实现
1.测试与文档更新
由于组内成员对开发对测试流程没有理解透彻，开发任务和解决Bug的占用时间太多，导致测试都是自己在编译器中打断点看数据是否获取成功等。测试人员对服务器的接口进行了测试
使用到的测试工具：jmeter，Instruments,postman等，快速找到了一些消耗时间的方法并且进行了优化。
一直按照最开始设计的UML文档进行开发。
2. 遇到的问题
开发阶段每个人遇到了一些Bug，由于我们的开发都是新手开发更是遇到了更多的Bug。
遇到的bug
- 添加账单后不会马上在列表显示
- top10那个列表会出现列表数目异常的情况
- 菜单栏覆盖全局顶部标题栏
- 周期事件的时钟会被系统杀死
- fragment的会覆盖全局顶部标题栏
- Float显示金钱数据时会出现不准备的现象。
- 上传账单数据读取格式错误
- DataTable数据接入错误
- Echart图例不显示
遇到这些Bug的原因
- 开发技术不熟练
- 对数据类型了解不是很清楚
- 对插件不熟悉
- 对view的生命周期不是很了解
- 把别人的方法照搬了下来，没有多思考
3.代码复审
在beta冲刺中，我们安排的专门的人进行代码复审的工作，由于开发经验和词汇量的限制，一些规范不是很理想，但总体按照最开始设定的代码规范完成了本次开发。
三、与 alpha 阶段相比的提升
1.计划方面的提升
alpha阶段只是对任务进行了较大模块的分工。在beta阶段，我们将任务分解成为一个一个的小任务进行分工。
2.分工合作方面的提升
| alpha | bata | 好处 | |
|---|---|---|---|
| 组内分工 | 单兵作战 | 两个人为一个开发小队完成开发任务 | 提升效率和学习的热情 |
| 人员分配 | 未对博客，文档等设立专职人员 | 设置专职的人员完成ppt制作和文案的撰写，开发人员一定完成开发任务。 | 各司其职，优化人员分配 |
3.工具流程方面的提升
| alpha | bata | 好处 | |
|---|---|---|---|
| 会议工具 | 群语音 | 腾讯会议 | 我们选择腾讯会议作为站立会的选择，并且开启视频进行交流沟通，尽量模拟线下的情景。 |
| 测试工具 | 简单的测试 | jmeter，Instruments,postman | 快速找到了一些消耗时间的方法并且进行了优化。 |
4.测试与发布
1.alpha 阶段在测试方面存在什么问题?beta 阶段是否解决这个问题?
alpha测试只是简单的测试数据是否得到，UI是否显示正常。 beta阶段使用专业的测试工具完成了，一些耗时大的方法的一些优化。
2.团队是否有一个测试计划?为什么没有?
测试计划只是针对服务器端进行了完成的接口测试，服务器含有测试计划，但是针对移动端的测试没有一个完成的测试计划，因为开发人员是初学移动端开发，对具体对测试工具和方法不是很清楚。在较短时间内也没有学会测试。
3.团队是否有测试工具来帮助测试?自动化程度如何?
服务器有jmeter进行自动化测试，其他则没有。
4.是否进行了正式的验收测试?
都进行了功能模块的测试后，验收通过上传github，最后打包发布的。
5.团队是如何测量并跟踪软件的效能(Performance)的?压力测试 (Stress Test)呢? 从软件实际运行的结果来看，这些测试工作有用么?应该有哪些改进?
使用jmeter，Instruments测试，找到了一些耗时的方法进行了改进。
6.在发布的过程中发现了哪些意外问题?
在找用户使用的过程中，出现了一些bug，进行了一些修复。
四、总结
1.项目是否出了什么意外?有什么风险是当时没有估计到的，为什么没有估计到?
在开始设计的时候，本来想从支付宝，微信，银行等支付平台上获取记账信息，达到自动记账等手段，但是在实际实现中发现这些信息根本没有办法获取，导致记账功能的自动化损失一半，会减少很多的用户。没有考虑到账单项目是一个很隐私的东西，一般用户不想透露太多。
2.总结第三部分的四个方面，你们学到了什么? 如果重来一遍, 你们会做什么改进?
1.在小组开发的过程中，开发项目前期需要做认真的项目分析，设计等一系列等工作，在编码的过程中，根据前面设计好的东西进行开发，需要做完整的测试来保证上线的质量。
2.需要小组内每个成员的强项找出来，做到人尽其才，将对开发没有多少兴趣的人，做一些资料搜索，文档撰写等文案工作，不能直接分配开发任务。开发小组需要保证两个人为一个小队，这样可以促进学习，相互监督开发过程。
3.需要熟悉团队合作的一些软件如GitHub，看板等一些工具的使用
3.你们觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?你们觉得团队目前 处于萌芽/磨合/规范/创造阶段的哪一个阶段?
根据CMM的定义，我们小组达到了可重复级(Repeatable)。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。属于规范阶段。
五、用户使用调查报告
我们做的还行的地方是没有出现用户可感知的严重错误，主要不足集中在交互逻辑以及便利性的优化上，这方面我们都缺乏相关知识，确实需要以后好好学习。从中间的调查结果以及最后用户对产品的总评分来看，用户总体还是比较认可我们的记账软件。这次调查虽然规模小，但相信也能对我们做出让用户更满意的产品有很大帮助
六、项目展示
七、下一阶段展望
1.你们的应用还有什么不完善的功能?是否还打算扩展新功能?
1.没有的对金钱种类的分类。
2.没有进行按月统计，按年统计，按周统计的选项
3.对各个账本间的转账没有做好优化
2.对于 1 中提到的改进/新增功能，你们的计划是?
后期对软件进行升级维护。
3.你们的应用是否计划投入使用?如果是，你们的发布、推广计划是?如果不是，为什么?
暂时不会投入使用。原因如下：
- 1.记账软件的数据对用户来说，是否需要上传服务器保存，那样用户的账单信息是否流入第三方的监控当中？
- 2.如果不上传服务器当中怎么保存用户数据？
- 3.记账软件如果自动化不是很高的话用户的群体有多大，如果吸引用户使用记账类app。
标签：用户,冲刺,Beta,开发,记账,测试,答辩,服务器,Bug 来源： https://www.cnblogs.com/money6/p/13127581.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。