2026秋软件工程第二次结对作业

2026秋软件工程第二次结对作业：校园失物招领程序实现（蔡以恒）

项目	内容
结对同学博客	https://www.cnblogs.com/CrisFeion
GitHub 项目	https://github.com/Feion-Chen/102402118-102402117
作业要求	https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering/homework/16744
小组成员	陈飞扬 102402118、蔡以恒 102402117

一、具体分工

陈飞扬负责程序主体实现，包括页面结构、核心数据逻辑、搜索筛选、状态转换和主要单元测试。

我负责从使用者和测试者的角度复核需求与实现：检查寻物、招领两类信息的状态是否合理，补充分类、地点筛选和空结果提示场景，设计异常输入的验收用例，检查 README 的目录说明和运行步骤，并协助核对 PSP 和最终博客内容。这样分工后，编码集中在一个人，测试与验收由另一个人站在相对独立的角度完成，可以减少“只按正常流程测试”的问题。

二、程序完成情况

项目使用原生 HTML、CSS 和 JavaScript，实现了以下核心闭环：

发布信息 → 浏览或搜索 → 查看详情 → 联系发布者 → 更新状态

主要功能包括发布寻物和招领信息、关键词搜索、分类与地点筛选、详情查看、联系方式复制、状态修改、图片预览和本地持久化。没有加入实名认证、即时聊天和地图定位，保持本次作业要求的范围。

三、我重点检查的问题

1. 两类信息的状态不能混用

寻物信息的流程是“寻找中 → 已找到”，招领信息的流程是“待认领 → 已归还”。如果允许所有状态任意切换，界面看起来方便，但数据会变得不真实。因此我重点检查了状态配置，确保寻物信息不能直接变成“已归还”，招领信息也不能变成“已找到”。

const STATUS_OPTIONS = {
  lost: ['searching', 'found'],
  found: ['holding', 'returned'],
};

updateStatus(id, status) {
  const item = this.getById(id);
  if (!STATUS_OPTIONS[item.type].includes(status)) {
    throw new Error('该状态不适合当前信息类型');
  }
  item.status = status;
  item.updatedAt = new Date().toISOString();
  return item;
}

2. 搜索需要支持多个字段

用户可能记得物品名称，也可能只记得地点或特征。如果搜索只能匹配标题，实际使用会很不方便。我检查了搜索逻辑，要求关键词能够跨越物品名称、分类、地点和描述进行匹配，并补充了“透明 图书馆”这种多词跨字段测试。

3. 本地文件也要能够直接运行

作业要求助教下载后能够运行网页。最初代码使用 ES Module 时，直接双击 HTML 可能受到浏览器本地文件策略限制。后来改成普通脚本并从容错后的 localStorage 中读取数据，使项目不需要服务器也能运行；如果浏览器允许，也可以通过 python -m http.server 8080 启动本地服务。

四、单元测试与用例设计

测试使用 Node.js 自带的 node:test，无需安装 Jest 或 Mocha。运行方式：

node --test tests/store.test.js

我重点补充了边界用例，而不是只检查“正确填写后可以发布”：

• 缺少物品名称时是否阻止发布；
• 非法信息类型是否被拒绝；
• 空搜索条件是否会错误过滤数据；
• 多关键词是否能跨字段搜索；
• 寻物和招领的状态是否分别合法；
• 更新不存在的 id 是否安全返回。

最终共有 14 个测试，全部通过。测试代码示例：

test('T14 updateStatus 对不存在的 id 返回 null', () => {
  const store = new LostFoundStore();
  assert.equal(store.updateStatus('missing', ITEM_STATUS.FOUND), null);
});

通过测试设计，我认识到测试数据要同时包含正常值和异常值，不能只沿着一条成功路径验证。

五、目录与运行说明检查

项目根目录包含 index.html、src、tests、docs 和 README.md。打开 index.html 后会直接显示首页；发布表单、详情弹窗和“我的发布”都通过 JavaScript 切换，不需要后端服务。README 中写明了直接双击和使用本地服务器两种方法，也说明了测试命令和目录用途。

我检查后建议把“图片可选”和“数据只保存在本机”写在发布区附近，避免用户误以为图片会上传服务器。最终页面已经显示这两项提示。

六、遇到的问题与解决

问题一：筛选条件变化后，分类或地点下拉框可能保留无效值。解决方式是每次渲染列表时重新生成可选值，并让筛选条件与当前数据保持一致。

问题二：空搜索结果容易让用户误以为数据丢失。解决方式是增加空状态、原因说明和“清除筛选”按钮。

问题三：图片转为 Data URL 后可能占用较大空间。解决方式是限制图片不超过 2 MB，并允许在发布前移除预览。

七、评价队友

代码结构清楚，把数据逻辑和界面渲染分开，便于我独立检查测试逻辑；遇到本地文件运行问题时能够及时调整实现。需要注意的是，部分功能可以在提交前更早提供可运行版本，这样验收测试可以更早开始，减少后期集中修改。

八、PSP

阶段	预估耗时（分钟）	实际耗时（分钟）
需求复核与分工	25	20
界面与字段检查	40	35
测试用例设计	60	50
本地运行与兼容性检查	35	30
README、PSP 与博客检查	45	40
合计	205	175

九、收获

这次结对实现让我体会到，程序完成后并不能立即提交。验收者需要从不同状态、不同输入和不同运行环境出发重新检查。尤其是本地文件、空结果和非法状态这些问题，只按正常流程点击不容易发现。通过把测试数据、状态规则和使用说明一起复核，程序的可信度明显提高。