Beta答辩随笔

这个作业属于哪个课程	2020春|S班（福州大学）
这个作业要求在哪里	团队作业第六次——beta冲刺+事后诸葛亮
团队名称	软工实践互动评价小组
这个作业的目标	beta冲刺
作业正文
其他参考文献

一、设想和目标

1.项目简介：做这个项目的背景、意义是什么？要解决什么问题？

我们的项目是《软件工程实践》互动评价系统，要解决的是《软件工程实践》这门课程提交评分表的这个问题。典型用户和典型场景还是很清晰的。(因为我们就是)

2.beta 冲刺目标与完成情况：规划了哪些需要进一步完善的功能和新增功能，对应的完成情况如何？在原计划之上是否有所拓展？

功能	新增功能描述	完成情况
分数统计逻辑优化	在之前的设计中，只有所有小组交齐评分表以后才可以完成自动统分，有小组未交则会统分失败，本次我们将优化业务逻辑，使得有小组未交时也可以完成统分。（本条已咨询用户意见）	已完成
前端页面美化	在alpha阶段中，我们着重完成功能的实现，对页面的美观程度不是很重视，我们将在beta阶段对其进行改进。	已完成
综合得分	完善综合得分相关接口	经过与助教商量，这个功能作用不大所以删除了

功能	需完善功能描述	完成情况
加密功能	由于将密码暴露出来非常不安全，所以我们将在两个维度上进行加密工作来确保密码在通信和使用时不会泄漏： 1.使用md5加密。 2.前端默认密码隐藏。	已完成
后台主页	新增一个后台主页，用于直观地统计某个班级小组的历次得分曲线	已完成

3.完成情况评价：你们原计划的工作是否最后都做完了? 如果有没做完的，为什么?

删除了综合评分功能，其他的工作计划都完成了。因为原定的综合得分是历次答辩互评分数的综合情况，而实际上助教是结合博客评分得出的综合得分，所以原定的综合得分是没有实际作用的，故删除了。

二、设计和实现

1. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新UML文档？

使用了UML和设计模式的知识来帮助设计和实现，很有效。首先之前的课程学过，算是一个良好的实践机会，其次为项目着手实现提供了一个切入点。一开始的UML文档和现在相比主要是一些接口的具体实现和数据库的数据类型有一些变动。变动产生的原因是一开始设计的时候没有考虑到具体实现，所以略显粗糙了。后面专门做了一份接口文档，有进行更新。

2.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug?为什么我们在设计/开发的时候没有想到这些情况?

最困扰我的不是BUG，是一个问题。就是项目在上线以后第一次访问的速度很慢，由于我本地有缓存，自己开发的时候没有遇到这个问题。
后来发现这是因为Vue是单页面应用，因此页面的所有内容是在第一次访问的时候就加载完了的，所以第一次访问会比较慢。
为了解决这个问题，我阅读了一些相关的博文，最后使用了路由懒加载的方式，这个方式可以让页面在需要使用的时候才进行加载以提高第一个页面打开的速度。但是我实际操作以后发现，提升不大、感知不强，然后又找不到其他解决方法，只好作罢。

3.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

我们使用了阿里的代码规范插件来对代码进行规范。
后期由开发人员自己进行复审，Beta阶段在没有新添加功能的时候开发人员的主要任务就是优化代码。

三、与Alpha阶段相比的提升

1.计划安排方面的提升：alpha冲刺中计划安排存在什么问题？beta阶段是否解决这个问题？在燃尽图中，各项任务是如何量化的?

Alpha阶段分工不够细致，Beta阶段细化了分工，比如安排了专门的测试人员。我们任务是根据每人每天的工作时长结合之前的开发经验来量化的。

2.团队分工合作方面的提升：团队分工的规则是什么（自由认领、组长分配等）？alpha冲刺中团队分工合作存在什么问题？beta阶段是否解决这个问题？

在Alpha阶段的时候，我把任务（比如接口）分成了几个部分，后端认领，分配完成后每个人对自己写的部分负责，到了Beta阶段基本上还是延续之前的分工。
alpha阶段存在github使用不熟练的情况，比如没有fetch就commit，覆盖掉了别人提交的内容，虽然内容是可以回档的，但是我们还是约定一定要先fetch再commit，避免不必要的麻烦。

3.工具流程方面的提升：alpha阶段在使用协作工具和测试工具等时，存在什么问题？beta阶段是否解决这个问题？

协作工具上，github的使用更加熟练了。
Alpha阶段测试工具用得比较少，Beta阶段除了使用postman进行接口测试，还使用了Jmeter进行性能测试，LambdaTest进行兼容性测试。

4.测试与发布：

（1）alpha 阶段在测试方面存在什么问题？beta 阶段是否解决这个问题？

如上文所说，Beta阶段相比Alpha阶段的测试更加全面。

（2）团队是否有一个测试计划？为什么没有？

有，在凡事预则立中给出了大致的计划，但是在计划安排的时候对测试工作还不是很了解，因此计划不够细致，所以只安排了测试内容，没有规划具体的时间。

测试任务

接口测试

单元测试

链接测试

表单测试

性能测试

兼容性测试

可用性测试

实际测试完成情况

时间	测试任务	测试报告
Day 1	接口测试	由于新功能及改进部分扔处于开发阶段，今天主要对之前接口进行测试，测试了登录、查看组间评价列表、查看某份组间评价列表、注册等功能。
Day 2	接口测试
Day 3	接口测试	由于一些功能未实现，密码未进行加密，一些检测未实现就录入。
Day 4	接口测试	测试背景：开发继续进行，测试接口是否正确 测试范围：接口的功能性 测试方法：黑盒测试 测试工具：postman 测试结果：与预期相符合
Day 5	性能测试、安全性测试	测试背景：测试接口的性能 测试范围：单个接口多人(100人)共同使用的性能 测试方法：黑盒测试 测试工具：Jmeter 测试结果：如截图所示 登录接口测试100人同时使用，平均时间0.012s，最慢用时0.1s，异常率0% 提交组间评价表接口测试100人同时使用，平均时间0.13s，最慢用时1.176s，异常率0% 密码使用md5具有一定的安全性，但是还是可以被破解，网上有破解网站，但是短时间无法破解。页面之间设置了拦截器保证了一定的安全性。
Day 6	兼容性测试	测试报告：接口测试完毕，大部分都已完成，未发现问题，对浏览器的兼容性进行了测试，不同的window8系统打不开，出现问题，各种浏览器都可以打开，但是打开时间有存在差异，屏幕分辨率的测试没出现问题，都可以良好的适应屏幕，部分手机平板打开测试会存在一定的差异，但是还行，不同系统打开速度也存在一定的差异，测试的时候有的型号的手机打不开，原因还在排查
Day 7	接口测试、兼容性测试	测试报告：接口测试完毕，对之前存在问题的接口测试了，已经解决了问题，对web的性能进行了检测，http请求未发现错误，平均响应时间为289毫秒，部分响应过久，达到预期目标，对56台跨设备的响应式屏幕测试包括平板手机，只有Galaxy Note9未作出响应，原因未知，显示器尺寸改变，显示都正常。

（3）团队是否有测试工具来帮助测试？自动化程度如何？

用了postman、Jmeter和LambdaTest，Jmeter是自动化工具，LambdaTest和postman是手动的。

（4）是否进行了正式的验收测试？

有。

（5）团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

使用Jmeter进行压力测试。Jmeter测试的是接口性能，接口性能情况良好。LambdaTest兼容性测试反应部分机型打开的时间较长。实际运行的结果来看，确实存在这个问题，

（6）在发布的过程中发现了哪些意外问题？

无。

四、总结

1.项目是否出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

有。课程开始不久的时候租了三个月服务器，前不久过期了，然后又配了一台。因为没有估计到这门课会这么久。

2.总结第三部分的四个方面，你们学到了什么? 如果重来一遍, 你们会做什么改进?

（1）计划安排

学到了项目需要安排冲刺阶段，放缓进度慢慢完成可能反而不太实际。
如果重来一遍的话，要多安排小粒度的验收，有的时候一个接口完成后没有经过充分的测试，到后面才发现与预期不符。

（2）团队分工合作

学到了团队的分工要明确，每个人的工作量要尽量均衡，要定期开会，让每个成员都清晰地认识到项目进度以及自己目前工作的意义是什么。
这个意义是指，举个例子，目前编写的接口用在什么地方，怎样才能让这个接口满足使用需求。
如果重来的话，我认为团队分工需要更加细化，一开始我们粗略安排的|3前端|5后端|，到后面变成了|2前端|1文档|3后端|2测试|，我认为能进一步细化出UI和运维会更有利于项目发展。

（3）工具流程方面

学会了github的使用以及一些测试工具的使用。
但是测试与开发的流程结合得不够紧密，如果重来可能会对这个方面进行改进。

（4）测试与发布

可行性测试还是最重要的。
可以写一篇博客记录一下自己配置服务器的过程，也可以记录一下常用的命令。方便自己以后再进行操作，可能还能帮助到别人。

3. 你们觉得团队目前的状态属于CMM/CMMI中的哪个档次?你们觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?

可重复级(Repeatable)；规范阶段。

五、用户使用调查报告

介绍调查方式、参与人数、调查内容和调查结果。参与者评价如何？提出了什么改进建议？

详见用户使用调查报告
概述：
面向人群：老师、助教和学生。
调查方式：老师和助教进行访谈，对同学进行问卷调查。
参与人数：约50人。
调查内容：对系统的接受度以及使用感受。
调查结果：1.大部分用户对我们项目的意义持肯定态度，并且表示愿意使用。
2.老师和助教更在意统计功能。
3.学生们更在意界面的美观性。
收到建议及改进：

问题或建议	回应
端口8080改为80	完成
密码隐藏显示功能	完成
千帆图	由于把综合评价功能删去了，所以这个功能意义不大，故没做
用户管理、小组管理新增跳转到统计页面的链接	完成
在最终答辩使用这个系统	（进行中）
（用户）添加一些统计图表	关于部分用户反馈的统计功能，主要是面向管理员和组长，所以组员比较没有体验到
学生不能自定义表格	关于组员不能提交自定义表格，这个跟一开始的设计有关，我们一开始是设计老师助教发布评分表，学生填表，现在要实现相当于推倒重做
首次打开响应较慢	Vue默认部署包过大，部署后第一次加载比较慢，目前使用了路由懒加载，但未能明显改善

六、项目展示

见答辩演示

七、下一阶段展望

1.你们的应用还有什么不完善的功能？是否还打算扩展新功能？

目前系统还不足以完全贴合这门课程的需求。暂不打算继续扩展。因为我们系统的针对性较强，仅针对这个场景，而不是一个生活社区类的应用，所以我觉得用户不需要花费很多时间在上面，功能并不是越多越好。

2.对于1中提到的改进/新增功能，你们的计划是？

暂时没有打算。

3.你们的应用是否计划投入使用？如果是，你们的发布、推广计划是？如果不是，为什么？

首先感谢老师给了这一次的应用机会。但由于我们已经要大四了，已经在为考研就业做打算了，对项目再进一步的可能性很小。但是如果有机会的话可能可以盘给下一届（让下一届体验随机组队随机接手项目）。