【CodingNoBorder - 07】无际软工队 - 求职岛：ALPHA 阶段测试报告_java

无际软工队 - 求职岛：ALPHA 阶段测试报告

项目	内容
这个作业属于哪个课程	2022年北航敏捷软件工程
这个作业的要求在哪里	团队项目-Alpha阶段测试报告
我们在这个课程的目标是	熟悉敏捷开发的方法论，并通过实际开发产品进行实践。
这个作业在哪个具体方面帮助我实现目标	熟悉敏捷开发的方法论：学习测试报告的编写。通过实际开发产品进行实践：基于我们完成的项目进行测试和分析。

Author: 无际软工队

Date: 2022.05.08

Bug 前端鉴权与注册

bug说明	修复方式	修复结果
用户在未注册的情况下仍然能够访问到信息页面（内容为空）	将鉴权与跳转逻辑封装为中间件，实现全局自动鉴权跳转	成功
用户在注册时无法收到邮箱验证码，系北航邮箱过滤策略所致	更换系统验证码邮箱为校园邮箱	成功
用户跳转到注册页面时页面反应迟滞	添加页面跳转动画来弥补迟滞跳转的用户体验	成功
用户在注册时退出，再次进入后可以访问信息页面（内容为空）	前端中间件对后端返回的用户注册信息进行检查，如果用户基础信息为空时也跳转到注册页面	成功
用户在登录后个人头像为空	在注册时采用微信小程序接口请求用户头像并传递给后端永久存储在COS中	成功
用户使用非指定邮箱仍然能够注册后跳转	前端对注册接口的返回结果进行检查，对非指定邮箱注册的行为进行处理	成功

用户个人页

bug说明	修复方式	修复结果
用户无法编辑用户信息	前端通过识别用户所点击的对象，来识别是否编辑	成功
用户在编辑已有的简历信息时，相关条目未被保留，需要手动重新添加	前端将用户的信息存储在viewmodel中，当进入编辑页面时识别用户点击的信息条目id并将相应信息装载至当前页面对象中	成功
用户编辑到一半不保存就退出后，简历信息仍然显示为被修改后的状态	前端在退出编辑时重新刷新viewmodel使其与后端保持同步	成功
用户输入非法的简历信息，前端没有准确识别，在提交简历时显示上传异常	前端对每一条用户输入添加规则并展示相应提示信息	成功
用户在删除自己的简历条目仍然能看到该条目，并对该条目进行编辑	前端在退出删除页面时后对当前viewmodel进行刷新	成功
用户输入条目信息过长时引发排版崩坏	前端对条目展示块添加自适应设置	成功
用户在选择奖项类型时，初始情况下条目内容为空，缺乏正确的引导	前端将条目内容提前进行适量填写，对选择类条目添加默认选项“-请选择-”	成功
日期选择组件无法正确获得符合格式规范的日期	换装微信小程序自带的日期选择器	成功
个人消息始终保持未读状态，即使在浏览后也如此	前端对查看消息的行为绑定一个事件，将相应消息id发送给后端进行状态更新	成功

广场页

bug说明	修复方式	修复结果
点击关注无法正确切换为已关注的团队列表	修复了关注按钮绑定的状态变量名	成功
点击活动Banner无法触发正确的活动搜索行为	为活动Banner添加了触发搜索更新的行为	成功
主页向下滑动距离有限，无法触发微信小程序的下滑更新事件	将dock栏从absolute改为relative形式	成功
从个人简历页切换到广场页有明显的闪烁感	增加一定时长的纯白背景作为切换过渡	成功

需求详情页与团队详情页

bug说明	修复方式	修复结果
在需求详情页无法看到发布者头像和对应团队的logo	删除了开发阶段用占位的纯色方块，该方块遮盖了理应展现的头像和logo	成功
点击收藏该团队后，无法在已收藏列表中看到该团队	回到已收藏页面时触发一次相应的viewmodel刷新事件	成功
向需求投递简历后，无法在详情页面看到相应的通知消息	前端在刷新的同时向后端查询是否有新的相关消息	成功
点击团队logo无法正确跳转至团队详情页面	修复了合并导致的跳转链接错误问题	成功

待解决问题

bug说明	修复方式	修复结果
页面之间切换较为僵硬，因为当前采用单个页面内嵌套多个组件而非拆分为多个页面，因此无法使用微信小程序自带的切换动画	将组件拆分为多个不同页面，再重新修改dock栏，使其能够在保持美观且可自定义样式的情况下在多个页面之间保持一致性与连续性	待修复

后端

bug说明	修复方式	修复结果
外键字段未设置on_delete参数无法运行	添加on_delete参数	成功
分布式开发的数据模型之间连接错误	阅读所有模型定义，处理遇到的所有异常，使其能通过编译	成功
在应当使用OneToOneField的地方错误使用ForeignKey	修改为OneToOneField	成功
uid若采用单调递增的数字容易被爬虫爬取用户信息	将uid生成方式修改为随机的字符串	成功
后端项目不能方便地同时兼具服务器部署和本地调试能力	增加若干特判使其识别各种环境，并按照期望正常运行	成功
CI 中 PyLint缺少依赖无法测试	添加PyYAML依赖	成功
错将wx_openid协作openid，导致字段访问错误未通过测试	改为正确的wx_openid	成功
微信鉴权服务器返回的json中在成功时不包含errcode导致程序出现KeyError	特判若不出现errcode则认为返回成功	成功
后端开发对框架使用不熟练导致无用代码过多不利于维护	由熟练框架的同学进行重构修改	成功
广播消息忘记考虑到已收消息的bug	改为筛选所有以自己的id为终点或者以广播地址为终点的消息	成功
User的管理界面密码设置界面错误	增加ModelAdmin	成功
项目组成员应该尽可以为招聘者	将member的类型改为Employer的外键	成功
新消息创建时所需数据格式错误	修复新消息创建时所需数据格式	成功
数据库全文搜索搜两遍效率低	合并数据库配置	成功
模型的关联数据查询时多次访问了数据库导致效率低下	利用prefetch优化	成功
在PostgreSQL上做测试时主键递增id可能不从1开始导致测试不通过	不再做第一个用户id为1的假设，重写编写test	成功
不能处理对一个Job重复申请的情况	添加新的联合Union约束	成功
由于Username可能为null，这与Django内置的一个__str__函数产生冲突	重写__str__函数使其一定返回str	成功

场景测试

用户信息	用户情况
姓名	LLLeo
身份	计算机学院学生，大三下，还没找好暑期实习，计划寻找校内实习，但没有想好要找的实习类型。
用户痛点	1. 各大微信群内发布的实习招聘信息过于杂乱，种类太少。 2. 现在有很多求职平台，但是缺少一个汇总校内实习信息的平台，寻找寻找校内实习时无从下手。 3. 可能有多个合适的实习岗位，缺少一个工具对合适的实习信息进行收藏。 4. 缺乏简历编写经历，希望寻找高效的方式投递自己的申请。
预期使用场景	通过「求职岛」高效浏览和搜索现有校内实习岗位，并对适合的实习岗位进行收藏，找到合适的实习岗位后，通过给定的模板进行简历的编写后进行投递，之后等待申请结果。
实现该用户需求的功能	1. 汇总校内实习平台的信息，并支持搜索功能，解决痛点 1 和痛点 2。 2. 支持对实习岗位的收藏和一键查询，解决痛点 3。 3. 支持编写简历并一键投递简历，可以随时查看投递状态和申请结果，解决痛点 4。

用户信息	用户情况
姓名	LLJeo
身份	计算机学院学生，大二下，计划寻找校内实习，确定了一些想进的实验室，但还没有确定去哪个实习岗位。
用户痛点	1. 实验室主页分散，甚至主页上可能缺少有效的实习信息，浏览和检索上耗费大量时间。 2. 无法快速获取每个实验室对应实习岗位的最新信息。 3. 无法对不同实习岗位进行高效对比。
预期使用场景	通过「求职岛」关注对应的实验室团队，高效浏览和搜索关注实验室所推出的实验岗位，比较不同岗位之间的优劣，选定合适的岗位后，通过给定的模板进行简历的编写后进行投递，之后等待申请结果。
实现该用户需求的功能	1. 汇总校内各大实验室的信息，并支持搜索功能，避免在实验室主页上低效检索，解决痛点 1。 2. 支持关注团队，可以一键搜索和查询所关注团队所推出的需求岗位，解决痛点 2 和痛点 3。

用户信息	用户情况
姓名	Chernoff
身份	计算机学院教授，课题比较多，有招聘实习生的需求。
用户痛点	1. 所在实验室主页较为古老，翻新成本过高。 2. 缺乏发布招聘实习生需求的途径。
预期使用场景	通过「求职岛」创建实验室团队，并发布实习生招聘需求，查看投递学生的简历并进行反馈，实现实习生的高效招聘。
实现该用户需求的功能	1. 招聘需求详情页会详细展示实习生岗位的具体信息，团队详情页会详细介绍实验室团队的信息，画面简洁精美，可以很好地吸引相关学生，解决痛点 1。 2. 每个发布的招聘需求都会在广场页上被展示，有效拓宽了发布招聘需求的途径，解决痛点 2。

压力测试

在使用 nginx+uwsgi 部署好服务器之后，我们使用了 JMeter 进行压力测试，并按照以下步骤进行分段测试。测试过程均采用高并发利用全部服务器资源。

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，里面的内容填充有意义的中文文本）

测试截图示例

测试结果

测试项目	平均延时 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

改进措施

测试结果表明在列表和搜索性能上，基本满足了我们的需要。通过分析，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编写了测试用例，每个API至少包含了一个测试正例保证功能可用性，并针对登录注册鉴权等等API编写了若干恶意输入和错误输入确保系统的安全性和鲁棒性。

同时我们还将自动测试部署到CI，每次合并到开发主分支时会自动进行单元测试与生成覆盖率报告，持续保持代码的正确性。我们的代码覆盖率达到了93%，仅一些无法自动测试的API（如微信认证登录和管理员界面）没有编写测试用例。

通过单元测试，我们在进行大规模重构时可以自动的发现大量的由此牵连导致的错误并迅速将其修复，极大地降低了思维负担。

出口条件前端

要求	完成情况	下一步
实现求职者前端的最小可用版本	目前发布的版本，覆盖了求职者简历编辑、需求查看与申请、组织关注、需求收藏等基本需求。	完成功能更为丰满的求职者小程序端平台。
UI 美观	UI 风格一致，较为美观。	进一步丰富 UI 元素。
UX 合理	用户 *** 作流畅，较为符合直觉。	进一步优化 UX 体验。
前端的验证和提示	添加了对绝大多数输入的前端验证和提示。	对新产生的功能组件接续添加前端验证支持。
跨端兼容性	小程序前端在 iOS 端和安卓端皆运行良好。	扩展对桌面平台小程序端的支持。

后端

要求	完成情况	下一步
数据库设计	前端能够正常访问，并支持正常的数据修改	继续完善设计数据库
权限验证	限制不同类型用户的权限，用户不能通过自主发送请求突破权限限制	继续完善权限处理系统
支持邮箱验证和邀请码双途径注册	限制恶意注册账号来攻击平台，减少恶意用户	继续完善注册方式
全文检索	支持对于offer的全文检索，并通过压力测试	继续改善相关性能和检索体验