无际软工队 - 求职岛:BETA 阶段测试报告
项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2022年北航敏捷软件工程 |
这个作业的要求在哪里 | 团队项目-Beta阶段测试报告 |
我们在这个课程的目标是 | 熟悉敏捷开发的方法论,并通过实际开发产品进行实践。 |
这个作业在哪个具体方面帮助我实现目标 | 熟悉敏捷开发的方法论:学习测试报告的编写。 通过实际开发产品进行实践:基于我们完成的项目进行测试和分析。 |
Author: 无际软工队
Date: 2022.06.17
Bug
前端
招聘者端
bug说明 | 修复方式 | 修复结果 |
---|---|---|
登录界面,登录失败时界面无任何响应。发现请求返回了后端抛出的异常,只是前端缺乏对异常的处理 | 添加了对后端抛出异常的处理 | 已修复 |
登录界面,登录按钮的动效失效 | 重新导入并安装了tailwind css的相关依赖 | 已修复 |
编辑Job信息界面,前端没有对招聘人数进行逻辑检查,导致后端可能接收到负数值,进而返回报错导致前端无法理解 | 在表单提交逻辑中加入逻辑检查,并在前端样式中进行错误提醒 | 已修复 |
注册界面,用户在前端注册输入的表单中存在显性的邀请码一栏,但是邀请码是非必须的,导致用户认为邀请码是必须的 | 将邀请码输入栏隐藏,并新增一个选择按钮来调出邀请码输入栏,并辅以文字描述 | 已修复 |
注册界面,用户在无邀请码的情况下注册后,无法再与邀请码进行绑定 | 在队伍选择界面加入绑定邀请码功能 | 已修复 |
全局,Nuxt的auth组件始终无法正常从后端取得登录状态。发现是由于axios的全局中间件在进行驼峰-蛇形转换时存在缺陷,导致字段名称不一致,而Nuxt同样适用axios向后端请求,导致用户信息fetch失败。 | 修复axios中间件的驼峰-蛇形转换模块 | 已修复 |
全局,突然所有请求几乎全部失效,所有请求均能正常返回但是内容为空。发现是新的axios中间件从返回的数据中的data字段获取对象以实现对UI逻辑函数的透明,但是原UI逻辑函数中依然考虑了data这一层嵌套 | 从axios中间件中去除了对data层嵌套的透明化 | 已修复 |
主页,登出按钮无任何响应。开启调试,主页的登出功能处于not implemented状态。 | 在主页实现了登出逻辑 | 已修复 |
尚未完全解决的问题
bug说明 | 修复方式 | 修复结果 |
---|---|---|
当前端项目通过development形式启动后,经过一段随机时间,会出现前端所有发往后端的请求均被挂起的情况,且通过网卡无法捕获到报文 | 目前在通过build形式构建出的发布版本产品中没有发现该问题,因此目前在调试过程中使用发布版本 | 发布版产品中不存在上述问题 |
后端
bug说明 | 修复方式 | 修复结果 |
---|---|---|
获取offer列表的方式与前端要求的方式不一致 | 按照前端的需求进行修改 | 成功 |
如果数据最外层是一个列表,发送到前端的时候会被转换成奇怪的样子无法解析 | 与前端协同,将某个发送包改为最外层为字典的形式,解决了问题 | 成功 |
已经被软删除的Job出现在了Offer内置的列表里 | 修改Offer的Serializer,使得其中的jobs经过筛选 | 成功 |
目前登录的账号未注册Employer时没有正确输出报错码,原因是没有正确调用模型api | 修改API为同一的Employer验证方式 | 成功 |
前端要求用户名必须为name字段,而不能是username字段 | 编写额外的to_representation方法来将username字段复制到name字段 | 成功 |
过期的Offer仍然出现,被测试用例发现该错误 | 修复检测方式,并完善测试用例 | 成功 |
新版本的数据表和旧版本数据包存在较大的不兼容,无法通过django进行迁移 | 由roife专项处理,dump出生产数据,更改结构,重建数据表,将数据还原 | 成功 |
前端对offer对象调用DELETE方法时将状态设置为FINISH而不是INVALID,这不符合前端的需求也不符合RESTful的预期 | 修正为INVALID | 成功 |
场景测试
用户信息 | 用户情况 |
---|---|
姓名 | LLLeo |
身份 | 计算机学院学生,大三下,还没找好暑期实习,计划寻找校内实习,但没有想好要找的实习类型。 |
用户痛点 | 1. 各大微信群内发布的实习招聘信息过于杂乱,种类太少。 2. 现在有很多求职平台,但是缺少一个汇总校内实习信息的平台,寻找寻找校内实习时无从下手。 3. 可能有多个合适的实习岗位,缺少一个工具对合适的实习信息进行收藏。 4. 缺乏简历编写经历,希望寻找高效的方式投递自己的申请。 |
预期使用场景 | 通过「求职岛」高效浏览和搜索现有校内实习岗位,并对适合的实习岗位进行收藏,找到合适的实习岗位后,通过给定的模板进行简历的编写后进行投递,之后等待申请结果。 |
实现该用户需求的功能 | 1. 汇总校内实习平台的信息,并支持搜索功能,解决痛点 1 和痛点 2。 2. 支持对实习岗位的收藏和一键查询,解决痛点 3。 3. 支持编写简历并一键投递简历,可以随时查看投递状态和申请结果,解决痛点 4。 |
用户信息 | 用户情况 |
---|---|
姓名 | LLJeo |
身份 | 计算机学院学生,大二下,计划寻找校内实习,确定了一些想进的实验室,但还没有确定去哪个实习岗位。 |
用户痛点 | 1. 实验室主页分散,甚至主页上可能缺少有效的实习信息,浏览和检索上耗费大量时间。 2. 无法快速获取每个实验室对应实习岗位的最新信息。 3. 无法对不同实习岗位进行高效对比。 |
预期使用场景 | 通过「求职岛」关注对应的实验室团队,高效浏览和搜索关注实验室所推出的实验岗位,比较不同岗位之间的优劣,选定合适的岗位后,通过给定的模板进行简历的编写后进行投递,之后等待申请结果。 |
实现该用户需求的功能 | 1. 汇总校内各大实验室的信息,并支持搜索功能,避免在实验室主页上低效检索,解决痛点 1。 2. 支持关注团队,可以一键搜索和查询所关注团队所推出的需求岗位,解决痛点 2 和痛点 3。 |
用户信息 | 用户情况 |
---|---|
姓名 | LJJeo |
身份 | 软件学院学生,大三下,希望寻找开发相关校内外实习工作,技术栈明确,但对找实习相关事宜关注较少,比较迷茫。 |
用户痛点 | 1. 市面上的招聘平台信息量过大,对于刚接触实习和工作的本科生来说并不友好,很难挑选合适的岗位。 2. 面向北航学生的实习信息分布较为分散,尤其难以寻找和特定技术栈相关的实习岗位。 3. 针对校内和校外岗位可能要编写不同的简历,缺少一个合适的工具进行版本管理。 |
预期使用场景 | 通过「求职岛」选定自己技术栈对应的标签,查看推荐岗位,高效获取有效信息。同时在搜索时添加相应的标签,高效过滤适合自己技术栈的岗位。通过「求职岛」简历版本管理功能实现多份简历的高效编写与管理,并在投递时选择对应的简历,针对不同的岗位展现不同的闪光点。 |
实现该用户需求的功能 | 1. 汇总校内外各大岗位信息,并支持通过标签搜索岗位和推荐岗位,高效获取有效信息,解决痛点 1 和痛点 2。 2. 支持简历编写的版本管理,可以在投递时选择相应的版本,解决痛点 3。 |
用户信息 | 用户情况 |
---|---|
姓名 | Chernoff |
身份 | 计算机学院教授,课题比较多,有招聘实习生的需求。 |
用户痛点 | 1. 所在实验室主页较为古老,翻新成本过高。 2. 缺乏发布招聘实习生需求的途径。 |
预期使用场景 | 通过「求职岛」创建实验室团队,并发布实习生招聘需求,查看投递学生的简历并进行反馈,实现实习生的高效招聘。 |
实现该用户需求的功能 | 1. 招聘需求详情页会详细展示实习生岗位的具体信息,团队详情页会详细介绍实验室团队的信息,画面简洁精美,可以很好地吸引相关学生,解决痛点 1。 2. 每个发布的招聘需求都会在广场页上被展示,有效拓宽了发布招聘需求的途径,解决痛点 2。 |
用户信息 | 用户情况 |
---|---|
姓名 | 切诺夫 |
身份 | 北航职协负责人,正在筹划群面大赛。 |
用户痛点 | 1. 需要一个较为正式的平台实现简历编写、浏览需求、简历投递的功能。自行搭建平台成本过高,若无合适平台则只能使用问卷星。 2. 需要一个较为正式的平台实现面试信息的反馈。 |
预期使用场景 | 通过「求职岛」举办群面大赛,比赛选手们在小程序上报名并投递简历,相关工作人员收集信息并进行反馈。 |
实现该用户需求的功能 | 1. 「求职岛」小程序完美充当了群面大赛所需的「正式平台」,解决痛点 1。 2. 「求职岛」小程序可以将用户们投递的简历收集,提供给相关招聘团队进行反馈,解决痛点 2。 |
用户信息 | 用户情况 |
---|---|
姓名 | Hoeffding |
身份 | 软件学院教授,所在实验室定期招收一定数量的研究生。 |
用户痛点 | 1. 以往宣传实验室和招收实习生的方式为,编写实验室说明后发布到各大微信群内,感兴趣的同学可以发送简历到对应邮箱以进行筛选。该方法需要频繁查看邮箱,一旦出现遗漏可能会错过同学们的投递请求,投递方也因为收不到回复而迷茫,双方都没有足够好的体验。 2. 微信群内发布的内容很容易被刷上去,无法吸引足够数量的同学们。 |
预期使用场景 | 通过「求职岛」招聘者网页端发布实习生招聘需求,详细查看每个投递请求并给予相应的回复,通过平台强大的一体化功能同时提升求职者和招聘者的体验。 |
实现该用户需求的功能 | 1. 「求职岛」招聘者网页端解决了传统的发邮件审核简历方式,实现整个招聘流程的一体化,解决痛点 1。 2. 「求职岛」小程序内的主要内容即为招聘需求信息,不会出现信息被刷上去找不到的情况,此外每个招聘信息都会根据求职者所添加的标签进行推荐,大幅提升了招聘需求的宣传力度,解决痛点 2。 |
压力测试
在使用 nginx+uwsgi 部署好服务器之后,我们使用了 JMeter 进行压力测试。Beta 阶段额外补充了一个对招聘者端相对更耗费时间的 API.
- echo: 最简单的一个API,将 request 中的 params 转换成 reponse 中的 body,不访问数据库,用于测试纯网络连接性能作为参考。
- authenticate: 单纯用于验证token是否可用的API,会查询数据库获得User信息以及部分加密,所有其他API的参考基准
- retrieve info: 列出已登录用户的个人信息的API。
- list offers: 列出某已登录用户所能查看的所有Offer的详细信息,最耗费时间的API之一。(测试数据库中一共有113个Offer和226个OfferJob,每个查询会列出其中的10个)
- retrieve offer: 列出一个用户指定的Offer的详细信息,与list offer进行比较。
- search offers: 用于测试Postgresql上的jieba插件的分词和全文搜索性能,这是本项目功能最复杂最耗费时间的API。(测试数据为113个Offer和226个OfferJob,里面的内容填充有意义的中文文本)
- 新增加的测试 - list applications: 列出关于某个招聘需求的全部求职请求,因为相关数据较多所以序列化和传输会比较耗费时间,我们采用分页的方式降低传输上的压力。
测试截图示例
测试结果
测试项目 | 平均延时 ms | 延时标准差 ms | 错误率 % | 吞吐量 packet/sec |
---|---|---|---|---|
echo | 282 | 53 | 0.00 | 215 |
authenticate | 285 | 32 | 0.23 | 223 |
retrieve info | 442 | 132 | 0.00 | 127 |
list offers | 4239 | 3748 | 1.73 | 11.6 |
retrieve offer | 1007 | 656 | 0.00 | 58.2 |
search offers | 3790 | 3392 | 0.00 | 10.3 |
*list applications | 7565 | 340 | 0.00 | 8.1 |
改进措施
测试结果表明在列表和搜索性能上,基本满足了我们的需要。通过分析,serach offers和list offers性能差距不大,说明在数据库层面搜索没有什么消耗,而主要在于Django对数据的处理的时间或拉取相关数据上。故对该API进行改进,利用prefetch_relate和select_relate方法来提前拉取关联数据避免多次查询数据库,改进后结果如下:
测试项目 | 平均延时 ms | 延时标准差 ms | 错误率 % | 吞吐量 packet/sec |
---|---|---|---|---|
retrieve offer | 1034 | 596 | 0.00 | 58 |
list offers | 4580 | 2722 | 1.73 | 12.9 |
虽然有改善但是改善并不大,说明性能瓶颈在Python代码执行上,无更多优化空间。
对于新加入的压力测试项,列出求职请求的确会耗费较大资源,不过吞吐量仍在可以接受的范围内,在合理分页、控制访问频率、前端按需请求的情形下,后端无需再进行更多处理。
单元测试
在本项目中,我们基于Django的Test框架对所有的可测的API编写了单元测试。单元测试共有74组,单元测试相关代码达到2300+行。
我们还将自动测试部署到CI,每次合并到开发主分支时会自动进行单元测试与生成覆盖率报告,持续保持代码的正确性。**至 Beta 阶段终点,**下图是自动生成的代码覆盖率报告,可以看出我们的代码总体覆盖率达到了92%。未能覆盖的部分主要包括数据库移植文件、微信登录相关API、对象存储相关API等无法在此处进行自动化单元测试的部分。
出口条件
前端
要求 | 完成情况 | 下一步 |
---|---|---|
进一步完善求职者小程序端 | 目前发布的版本,包括标签系统、Offer 推荐等多项功能增加和既有功能优化及改进。 | 为求职者带来更多便捷功能。 |
完成用户友好的招聘者端 | Beta 阶段结束时,完成了招聘者可用的 Web 端,将大多数功能下放至用户自助。 | 完善机制并进行代码实现,以图实现平台的用户自治。 |
UI 美观 | UI 风格一致,较为美观。 | 进一步丰富 UI 元素。 |
UX 合理 | 用户操作流畅,较为符合直觉。 | 进一步优化 UX 体验。 |
前端的验证和提示 | 添加了对绝大多数输入的前端验证和提示。 | 对新产生的功能组件接续添加前端验证支持。 |
跨端兼容性 | 招聘者 Web 端在桌面及移动端均运行良好。 | 进一步优化求职者端逐步将其迁移至 Web 平台。 |
后端
要求 | 完成情况 | 完成度(满分 10 分) |
---|---|---|
数据库设计 | 能够支持正常的数据修改与查询 | 10 |
权限验证处理 | 限制不同类型用户的权限,用户不能通过自主发送请求突破权限限制 | 10 |
支持邮箱验证和邀请码双途径注册 | 限制恶意注册账号来攻击平台,减少恶意用户 | 8 |
全文检索 | 支持对于 offer 的全文检索,并通过压力测试 | 9 |
支持求职者相关操作 | 支持完善简历、提交申请等求职者的相关操作 | 9 |
支持招聘者相关操作 | 支持添加工作、查看提交的申请等招聘者的相关操作 | 9 |
测试矩阵
求职者端
终端设备 | 操作系统版本 | 登录 | 首页显示 | 完善简历 | 搜索招聘信息 | 招聘详情显示 | 投递简历 | 关注与收藏 | 查看申请 | 多份简历管理 | 关键词搜索 | 添加tag | 根据tag搜索和推荐 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
安卓 | HarmonyOS 2.0.0 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
iPhone | iOS 15.5 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
招聘者端
终端设备 | 操作系统版本 | 浏览器版本 | 登录 | 首页显示 | 发布招聘需求 | 添加岗位 | 招聘详情显示 | 查看投递 | 关注与收藏 | 加入组织 | 关键词搜索 | 添加tag | 身份认证 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
联想笔记本电脑 | Windows10 | Chrome 102.0 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
iPhone 13 | iOS 15.5 | Safari | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
iPad Pro (2021) | iOS 15.5 | Safari | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
MacBook Pro (2021) | MacOS Monterey 12.4 | Safari 15.5 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |