NJUSE-COLLECT

《软件工程与计算Ⅲ》与《人机交互》大作业 总算是有一个拿得出手的项目了

COLLECT： Collaborative Crowdsourced Testing Platform协作式众包测试平台。

项目用例图如下。下面的用例图仅展示主要功能，一些细节功能已略去。

项目的部署情况如下。

文件结构

backend_mxyzyyds/ # 后端
developdocs_mxyzyyds/ # 文档
frontend_mxyzyyds/ # 前端
python_mxyzyyds/ # 算法
HCI.pdf # 人机交互复习笔记
README.assets # 本文档配图
README.md # 本文档

交互视频请在这里获取（PPT里已经内嵌有）。

https://box.nju.edu.cn/f/9bb4ef5aba524951b8a3/

网站课程结束后自动下线。

《软件工程与计算Ⅲ》相关（92分）

该项目的得分相当的高，且文档被某企业级BI工具的前端工程师表扬。

（但是其数据库设计一言难尽，被某跳动面试官予以批评）

由于剩下的三个人都不想把自己的名字挂上来，所以这里也就是YDJSIR本人了。

YDJSIR一定要和他们重构这个项目。（要不然拿去应聘太丢面子了）

截至2023年3月，就改了点UI

凭据信息已去除，且文档也只保留了必要部分。

《人机交互》相关（96分）

HCI附赠一个PDF复习笔记。

项目选题：题目一

选择已有课程项目，对其交互进行重新设计（注意：交互变更可能会改动后端）。要求项目规模中等，有适量交互界面，没有交互或全自动化的不考虑；提交：项目源码、现场演示检查、用户与场景视频；

本项目采用2022年春《软件工程与计算Ⅲ》工程项目作为项目基础。原班人马相互配合带来更好的设计。

用户分析

在交互视频中，我们设计了更细致的人物形象。这里仅作基本勾勒。

目标用户是什么？

发包方

有应用测试需求、希望通过奖励的方式尽快得到社区帮助的应用开发者。

受限制于成本等因素，这类开发者往往难以维持一支稳定的、庞大的且富有多样性的测试团队。他们希望以众包的形式低成本地获得合适的、符合期望的且多样化的（如被期望的设备和操作系统的多样性等）测试，以方便自身优化产品。他们也希望平台能对众包工人提交的报告进行把关，不淹没在海量的垃圾报告中。

众包工人

具有一定的应用测试经验、愿意从事应用测试获取奖励的应用测试者。

他们很可能是自由职业者或者兼职人员，希望通过从用户角度体验待测产品的方式，向发布任务者提供反馈并可以获得相应的积分作为奖励。他们不仅被期望着提供自己的报告，更被期望着参与到众包测试社区的建设中。例如，他们可以补充协作他人的报告，并在这样的过程中同样获得积分奖励。

本系统并未对接支付系统，也没有开发者方面的支出展示。测试者获得的激励暂时以积分表示。

• 审核通过1份报告+10，
• 发现1个新BUG+10
• 审核不过1份报告-10，
• 发1条补充报告+3，
• 给写1条评价+1

目标用户有什么问题？

发包方

开发者希望在发布项目前获得成本低廉的，用户多样的众包测试服务。

• 软件产品迭代快速、运行环境碎片化；
• 传统测试测试周期长，测试环境单一；
• 维持专职测试团队成本高；
• 难以量化接包测试人员的能力；

众包工人

测试者希望在在相互协作过程中完成众包任务并获得激励。

• 能在列表中检索符合自己期望的众包任务；
• 能够获得符合自己情况的任务的推荐；
• 能够对他人的报告做出补充；

产品可以解决目标用户的什么问题？

发包方

• 召集大量具有不同测试环境的众包工人，以软件用户的身份在线完成测试任务，适合快速迭代的软件开发实践和碎片化的软件运行环境；
• 对复杂真实应用场景和真实用户表现的良好模拟；
• 缩短测试周期短，降低测试成本；
• 有效衡量众包工人的能力，能获得针对任务的众包工人推荐；

详情请参看 交互视频。

众包工人

• 可以在任务广场广泛浏览各种任务并选择符合自己情况的任务；
• 可以根据特定任务获得更多任务的推荐；
• 可以与他人进行报告协作，共同进步。

参考原理： 黄金规则 by Ben Shneiderman

✅ ​规则1. 尽可能保证一致

一致的颜色，字体等

对于类型相同的列表，保持相同的格式。网站整体字体和行距样式保持一致。

一致的菜单结构

以个人中心为例。

发包方和接包方的个人主页整体结构是一致的。

类似比分板的结构里，展示着相近颜色按钮对应的数量。查看已完成任务以及新建类按钮均选用绿色，符合普遍认知。

❌ 规则2. 符合普遍可用性

我们的系统暂未拥有符合该原则的设计。

✅ ​规则3. 提供信息丰富的反馈

丰富的详情信息

我们提供了对众包工人详细信息的展示。

恰当的操作反馈

对于各种数据提交，我们设计了结果反馈的提示。

以消息页面为例。下图中会提示页面所有消息已读设置成功。随后页面会自动刷新。然后就可以看到所有的消息已读。

✅ ​规则4. 设计说明对话框以生成结束信息

结束操作对话框提示

我们在许多提交数据之处设计了说明对话框，以反馈已结束的操作的结束信息。例如，管理员在调整任务推荐策略时，每一步都会有反馈。

✅ ​规则5. 预防并处理错误

输入值校验

对基本所有输入值进行错误校验，防止错填漏填。

❌ **规则6. 让操作容易撤销 **

我们的系统暂未拥有符合该原则的设计。

❌ 规则7. 支持内部控制点

我们的系统暂未拥有符合该原则的设计。

✅ ​规则8. 减轻短时记忆负担

我们将诸多功能以可折叠的抽屉或者对话框的方式展示在同一页面中，以极大减轻使用者的负担。

实例：任务详情页

例如，在任务详情页中，我们将一个任务下围绕的任务放在同一个页面里，用户看到任务相关描述可以做对应的操作，且元素数量在4-6个（下图是功能按钮最多的情况），在人的短期记忆能力内。

例如，打分评论等功能，都集成在这个页面内。用户在打分的时候还可以看见任务详情，方便判断。

查看我自己的报告同理。其他就不一一展示了。

实例：报告详情页

报告详情页也是类似的。

实例：报告协作页

最值得一提的还是报告协作页。用户可以看着另一个人的报告对照着进行补充。