这个作业属于哪个课程 | 2302软件工程 |
---|---|
这个作业要求在哪里 | 软工实践——GitCode团队实战总结 |
团队名称 | 爱背单词不摆烂 |
这个作业的目标 | 多人协同工作、事先设计好模块分工、团队博客发表一篇博客 |
其他参考文献 | 《构建之法》、CSDN |
目录
一、GitCode项目仓库地址
二、GitCode 的提交日志截图
2.1、052101413任广湃
2.2、222100318张璟楠
2.3、222100303陈昕
2.4、222100122洪冠诚
2.5、222100308向至尚
2.6、112101225吴淇
2.7、222100305庞财莹
2.8、182000214廖文焘
学号姓名 | Commit次数 |
---|---|
052101413任广湃 | 3 |
112101225吴淇 | 10 |
182000214廖文焘 | 11 |
222100122洪冠诚 | 5 |
222100308向至尚 | 12 |
222100318张璟楠 | 5 |
222100303陈昕 | 3 |
222100305庞财莹 | 9 |
三、程序运行环境
腾讯云服务器
后端接口部署:maven打包jar包上传服务器,使用nohup java -jar xxxx.jar &实现后台运行。
前端web部署:npm run build打包vue项目上传服务器,使用nginx部署服务。
移动端部署:使用 flutter 开发,flutter build apk。
四、功能实现思路描述
实现的基本功能:
用户模块:
- 用户注册
- 用户登录
- 用户基本信息
投票模块:
- 每名用户都可以参与投票,为自己喜欢的运动员进行投票
- 投票信息展示(运动员信息、最大可投票数(不限制)、投票活动开始时间、投票活动截止时间、投票结果公布)、投票选项不可修改
排名模块:
- 统计所有运动员的得票数
- 对所有的运动员综合票数进行排名
实现的附加功能:
- 附加功能1:设置投票策略,用户登入可获得一定的票数,来为自己喜欢的运动员进行投票。
- 附加功能2:管理员模块:可以查看所有投票情况,还能看到后台统计信息如用户所属IP的账号数,并且能够封禁账号。
- 附加功能3:压力测试,模拟大量的用户同时参与。
4.1、问题的思考与解决
-
Q1:用户如何快速知道有投票功能并参与投票?
-
A1:用户登录以后会看到当前运动员的投票排行,用户点击某个运动员的信息栏时会进入该运动员的详细信息页面,可以通过点击support支持按钮为运动员投票。
-
Q2:投票结果如何告知用户?
-
A2:用户点击运动员信息时,会有一个support支持按钮,用户点击即可为运动员投票,投票成功后以提示框返回提示信息告知用户已经投票成功。
-
Q3:如何保证一人一号?防止用户多次注册账号参与投票。
-
A3:通过检查用户注册的用户名是否在数据库中已经存在,若已存在则提醒用户更改注册的用户名;若不存在则继续判断电话号码是否重复,若存在则提醒用户更改电话号码,若不存在则注册成功。
4.2、思路描述
4.3、代码展示
4.3.1、后台管理员主页面
4.3.2、后台管理员子页面
4.3.3、管理员端获取所有运动员接口
4.3.4、根据比赛名称查询比赛信息
4.3.5、用户类
4.3.6、判断是否一人一号
4.3.7、获取运动员列表
4.3.8、用户展示设计
用户展示首先从数据库提取出所有的用户,再对每个用户进行ip地址的查询记录,通过建立辅助表ipUserCounts得到ip地址和用户的映射,从而获取每个ip地址对应的用户,最后使用vo类返回给前端具体的用户信息。
4.3.9、封禁以及解封用户
封禁用户首先根据管理员传的用户id得到用户,调整用户状态后,遍历vote表,使该用户投过的票无效,同时我们封禁用户只做状态的改变而不做delete操作,解封用户后用户投票依然会恢复。
五、程序截图说明
5.1、登录界面
用户通过输入自己注册的用户名和密码进行登录。
5.2、注册界面
用户输入自己的用户名、密码、邮箱地址、电话号码进行注册。
5.3、用户投票
用户登录成功后,自动获得票数(票数不做限制)。可以点击进入运动员的详细信息页面进行投票。
5.4、运动员综合投票排名
用户登陆成功后,主页显示运动员在票数下的综合排名。
5.5、投票开始时间与截止时间
该页面展示赛事的投票时间和截止时间。
5.6、模糊查询搜索运动员与比赛信息
用户可以通过运动员姓名、比赛名称、国家三个搜索框进行查询。
5.7、运动员投票信息
后台管理员可以查看所有投票情况。
5.8、管理员用户管理
管理员可以看到后台统计信息如用户所属IP的账号数,并且能够封禁账号。
5.9、用户信息
用户登录成功后可以看到自己的基本信息。
5.10、赛事投票信息
管理员可以查看具体赛事的投票信息
六、组员职责分工
学号姓名 | 职责分工 |
---|---|
052101413任广湃 | 压力测试、协助移动端开发 |
112101225吴淇 | 数据库设计、后端开发 |
182000214廖文焘 | 用户移动端开发 |
222100122洪冠诚 | 博客撰写、进行移动端和Web端功能测试、协助后端开发 |
222100308向至尚 | 数据库设计、后端开发 |
222100318张璟楠 | 压力测试、协助后端debug |
222100303陈昕 | 压力测试、协助前端开发 |
222100305庞财莹 | 管理员页面前端开发 |
七、组员贡献度比例
学号姓名 | 贡献度 |
---|---|
052101413任广湃 | 9.5 |
112101225吴淇 | 14.9 |
182000214廖文焘 | 15.1 |
222100122洪冠诚 | 10.6 |
222100308向至尚 | 15 |
222100318张璟楠 | 10.4 |
222100303陈昕 | 12.5 |
222100305庞财莹 | 13 |
八、合作中遇到的困难及解决方法
8.1、052101413任广湃
- 遇到的困难:一开始进行压力测试时,出现了测试工具使用不一致的问题。
- 解决方法:与团队成员进行沟通交流后,统一了测试工具。
- 心得体会:团队成员需要积极沟通和交流。
8.2、112101225吴淇
- 遇到的困难:参与数据库设计和后端代码编写,遇到数据库表名、方法和变量名不一致的问题
- 解决方法:通过与团队成员的沟通和认真debug解决了问题。
- 心得体会:在团队协作中,要尊重和信任团队成员,鼓励和支持彼此,共同完成项目。此外,debug能力也是作为一个程序员必不可少的能力。
8.3、182000214廖文焘
- 遇到的困难:环境配置存在问题。
- 解决方法:利用搜索引擎查找网络上的问答,成功解决问题。
- 心得体会:要善用搜索引擎。
8.4、222100122洪冠诚
- 遇到的困难:参与一部分代码开发,但对相应的技术框架使用不熟练,在时间紧张的情况下协助进行功能测试。
- 解决方法:与团队成员进行积极的沟通和交流,通过CSDN与b站等网络资源速成相关知识,并利用chatgpt强大的能力解决了问题。
- 心得体会:在遇到问题和困难时,要保持冷静和乐观的心态,积极与团队成员沟通,互帮互助,解决问题。
8.5、222100308向至尚
- 遇到的困难:项目开发时间非常有限,并且团队协作时存在分工和沟通不畅的困难。
- 解决方法:通过及时沟通和协商解决问题,及时与团队成员讨论交流,统一编码风格和思路。
- 心得体会:这次经历让我深刻理解到,在压力环境下,合理的团队分工和开发规划是多么重要。同时,我也学会了如何在压力下快速做出决策,并带领团队解决问题。
8.6、222100318张璟楠
- 遇到的困难:没有学习过压力测试,不知道压力测试如何进行。
- 解决方法:通过b站上的压力测试速成视频,成功学会了如何利用工具进行压力测试。
- 心得体会:作为开发者,我们需要持续学习,不断更新自己的知识库。团队内部的技术交流对于个人成长和团队发展都极为有益。
8.7、222100303陈昕
- 遇到的困难:压力测试过程不顺利,error率高。
- 解决方法:通过查阅网上资料并与团队成员沟通交流成功解决问题。
- 心得体会:遇到困难时也需要保持冷静,要善于利用各种资源解决问题。
8.8、222100305庞财莹
- 遇到的困难:参与前端代码编写,遇到前后端意见不一致和代码问题。
- 解决方法:前后端开发人员之间需要积极沟通和交流,以便在遇到问题时快速解决。
- 心得体会:在团队协作中,要注意任务分工和沟通交流。
九、PSP表格
9.1、052101413任广湃
PSP | Personal Software Process Stages | 预计耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 15 | 15 |
• Estimate | • 估计这个任务需要多少时间 | 15 | 10 |
Development | 开发 | 110 | 130 |
• Analysis | • 需求分析 (包括学习新技术) | 10 | 5 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 10 | 20 |
• Coding | • 具体编码 | 230 | 245 |
• Test | • 测试(自我测试,修改代码,提交修改) | 5 | 15 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 5 | 25 |
合计 | 415 | 435 |
9.2、112101225吴淇
PSP | Personal Software Process Stages | 预计耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 15 | 15 |
• Estimate | • 估计这个任务需要多少时间 | 15 | 10 |
Development | 开发 | 330 | 350 |
• Analysis | • 需求分析 (包括学习新技术) | 10 | 5 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 10 | 20 |
• Coding | • 具体编码 | 480 | 480 |
• Test | • 测试(自我测试,修改代码,提交修改) | 5 | 15 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 5 | 25 |
合计 | 810 | 835 |
9.3、182000214廖文焘
PSP | Personal Software Process Stages | 预计耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 10 | 10 |
• Estimate | • 估计这个任务需要多少时间 | 5 | 10 |
Development | 开发 | 320 | 420 |
• Analysis | • 需求分析 (包括学习新技术) | 5 | 5 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 15 | 15 |
• Coding | • 具体编码 | 380 | 420 |
• Test | • 测试(自我测试,修改代码,提交修改) | 10 | 15 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 15 | 20 |
合计 | 730 | 855 |
9.4、222100122洪冠诚
PSP | Personal Software Process Stages | 预计耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 25 | 15 |
• Estimate | • 估计这个任务需要多少时间 | 5 | 10 |
Development | 开发 | 180 | 200 |
• Analysis | • 需求分析 (包括学习新技术) | 5 | 5 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 15 | 15 |
• Coding | • 具体编码 | 300 | 315 |
• Test | • 测试(自我测试,修改代码,提交修改) | 5 | 10 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 5 | 10 |
合计 | 515 | 525 |
9.5、222100308向至尚
PSP | Personal Software Process Stages | 预计耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 20 | 20 |
• Estimate | • 估计这个任务需要多少时间 | 15 | 30 |
Development | 开发 | 270 | 310 |
• Analysis | • 需求分析 (包括学习新技术) | 10 | 10 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 5 | 5 |
• Coding | • 具体编码 | 430 | 490 |
• Test | • 测试(自我测试,修改代码,提交修改) | 5 | 5 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 5 | 5 |
合计 | 745 | 835 |
9.6、222100318张璟楠
PSP | Personal Software Process Stages | 预计耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 15 | 15 |
• Estimate | • 估计这个任务需要多少时间 | 15 | 10 |
Development | 开发 | 140 | 160 |
• Analysis | • 需求分析 (包括学习新技术) | 10 | 5 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 10 | 20 |
• Coding | • 具体编码 | 250 | 255 |
• Test | • 测试(自我测试,修改代码,提交修改) | 5 | 15 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 5 | 25 |
合计 | 465 | 495 |
9.7、222100303陈昕
PSP | Personal Software Process Stages | 预计耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 6 | 8 |
• Estimate | • 估计这个任务需要多少时间 | 10 | 5 |
Development | 开发 | 160 | 167 |
• Analysis | • 需求分析 (包括学习新技术) | 4 | 12 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
• Coding | • 具体编码 | 375 | 385 |
• Test | • 测试(自我测试,修改代码,提交修改) | 5 | 13 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 5 | 15 |
合计 | 535 | 545 |
9.8、222100305庞财莹
PSP | Personal Software Process Stages | 预计耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 10 | 15 |
• Estimate | • 估计这个任务需要多少时间 | 20 | 20 |
Development | 开发 | 400 | 380 |
• Analysis | • 需求分析 (包括学习新技术) | 5 | 5 |
• Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 15 | 5 |
• Coding | • 具体编码 | 400 | 420 |
• Test | • 测试(自我测试,修改代码,提交修改) | 5 | 10 |
• Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 10 | 10 |
合计 | 855 | 875 |
十、压力测试
小组使用jmeter和apipost两种工具进行压力测试,测试板块包括用户Login,register接口等;分析接
口/页面的平均响应时间、最大响应时间、错误率。
步骤
- 创建测试计划:右键单击测试计划并选择 “Add” -> “Threads (Users)” -> “Thread Group”。创建一个线程组,用于模拟并发用户
- 配置线程组参数:设定线程数目,攀升时间,循环轮数等
- 添加 HTTP 请求:配置登录接口的 URL、请求方法和参数。(api测试需添加HTTP信息头管理器)
- 添加监听器,运行测试分析结果
测试结果
登录模块
平均响应时间(ms) | 1457.543 |
---|---|
最长响应时间(ms) | 20015 |
异常率(ms) | 0%(6/1000000+) |
注册模块
平均响应时间(ms) | 2862.12 |
---|---|
最长响应时间(ms) | 26280 |
异常率(ms) | 0%(4/1000000+) |
投票模块
平均响应时间(ms) | 2631.261 |
---|---|
最长响应时间(ms) | 23150 |
异常率(ms) | 0%(4/1000000+) |
获取用户信息模块
平均响应时间(ms) | 1418.151 |
---|---|
最长响应时间(ms) | 20000 |
异常率(ms) | 0%(2/1000000+) |
根据id获取运动员信息模块
平均响应时间(ms) | 2122.283 |
---|---|
最长响应时间(ms) | 18072 |
异常率(ms) | 0 |
测试过程中截图(未测试完毕)
测试结果截图(来自apipost)