拾光友人帐——Alpha 冲刺测试

2026-10-29 18:04:38 94 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

STM32F4驱动ADS1220高精度ADC：从SPI配置到数据校准的完整实战指南本文详细介绍了如何使用STM32F4微控制器驱动ADS1220高精度ADC，涵盖从SPI接口配置、寄存器设置到数据采集与校准的全过程。通过实战代码示例和硬件设计要点，帮助开发者快速构建高精度数据采集系统，适用于工业测量和精密仪器等应用场景。阅读详情

这个作业属于哪个课程	2601_FZU_SE 软件工程实践
这个作业要求在哪里	团队第四次作业——站立式会议＋α 冲刺
这个作业的目标	介绍拾光友人帐 Alpha 阶段的测试安排、工具、测试用例、结果和测试体会
其他参考文献	《构建之法》第 2 章、第 13 章；项目接口契约与验收记录

一、项目与测试目标
测试关注的业务不变量
二、测试工作安排
用例交接与缺陷闭环
三、测试工具与使用方式
分层验证的配合方式
四、测试用例文档
样本与反例设计
五、测试结果与问题处理
5.1 执行结果
5.2 典型问题
5.3 结果判定与回归优先级
六、AI 技术员与自动化测试
AI 角色与审核重点
七、测试体会与项目测试评述

一、项目与测试目标

“拾光友人帐”是面向校园场景的失物招领小程序。Alpha 阶段围绕登录认证、寻物／招领发布、浏览搜索、匹配线索、认领归还、匿名消息和个人中心推进，同时补充首页聚合、认证审核和收纳点管理。

测试目标是确认主要接口与页面能按照契约协作，并检查身份隔离、重复操作、数据一致性和错误恢复。测试与开发并行：每完成一段业务，先检查模块内部规则，再联调相邻页面和接口，最后把重复测试固化为可复跑脚本。代码存在不等于功能验收通过，接口返回成功也要结合业务状态和数据库结果判断。

本篇整理时以仓库主干 9f3fd07 及 D1—D7 阶段记录为依据。后端测试、页面源码检查和真实 MySQL／Redis HTTP 检查采用不同环境，结果分别记录；D7 按团队调整后的范围，不进行七屏连续走查、真机及真实微信身份验收。

测试关注的业务不变量

测试首先围绕业务规则建立判断依据。公开信息可以被浏览，但私有核验、本人流水与会话历史必须受身份约束；重复点击和请求重放不能产生额外认领、重复结算或重复通知；页面切换条件或账号后，旧响应不能覆盖新的查询结果。这些规则贯穿多个模块，适合在每日增量开发后持续复验。

对成功路径的检查也需要落到结果。发布接口成功后，应能通过列表或本人查询找到对应记录；归还完成后，应能同时解释物品状态、认领进度、积分增量和通知；匹配返回候选后，应能根据判据说明为什么出现该条线索。这样可以避免把 HTTP 成功与业务正确简单等同。

二、测试工作安排

阶段	工作重点	对应成果与检查
D1	工程、数据库、身份及运行基础	初始化 21 表、字典和约束；核对健康检查、登录基础链路与环境依赖
D2	寻物／招领发布和草稿	检查表单、图片数量、登录认证、草稿回填和请求失败处理
D3	列表、筛选、详情与收藏	检查分页、地点和类别筛选、详情、收藏状态及本人入口
D4	认领、归还与消息	使用拾主、申请人、第三人检查权限、重复操作、善意值、通知和会话
D5	匹配与个人中心	检查自动重算、真实判据、本人数据、流水、换号与分页恢复
D6	首页聚合与管理	检查公开／本人数据范围、管理员审核、收纳点维护和普通用户越权拒绝
D7	冻结回归与交付检查	执行全量自动化、空库建库、隔离实库 HTTP、安全及代表性查询计划检查

团队按六人分工推进：李明学侧重接口、自动化与回归整理；许煜煌负责用户路径与交付材料核对；许毅君复核认证、资源归属和管理员权限；王永臻检查表结构、约束、事务、匹配和积分；刘传浩检查页面交互与失败恢复；刘伟鑫协调集成版本、契约和问题处理。测试由对应开发人员自测后，再由其他成员交叉核对，任务关联不等于每个测试均由单一成员独立执行。

用例交接与缺陷闭环

开发成员自测时先提供最小可复现输入和预期，交叉检查成员再改变身份、参数或请求顺序，寻找规则边界。对于失败场景，记录触发条件、现象和影响范围，定位到接口、页面状态或数据库约束后再修复。修复完成仍回到原用例复跑，同时检查相邻操作是否受到影响。

测试记录采用统一语义：通过表示对应版本和环境下的断言满足；跳过表示条件未具备，不能当作成功；未纳入本轮范围则单独说明。阶段报告之间存在重叠场景，不按每日数字累加计算全项目覆盖率。

三、测试工具与使用方式

工具或环境	用途	范围与限制
Maven、JUnit、Spring 测试	后端单元与集成测试	默认测试使用 H2 和测试会话；不能直接替代真实数据库验收
Node.js、`node:assert`、`vm`	直接执行小程序页面源码，构造可控异步响应	可检查页面状态、路由和竞态；不能验证微信渲染与触控
MySQL 8、Redis、HTTP 脚本	校验真实数据库与会话依赖下的请求、业务数据和权限	使用独立库与 local 模拟身份；不代表真实微信登录
SQL 初始化／验证脚本	检查建表、字典、唯一约束与负向约束	单独验收指定测试库，不执行团队库重置
MySQL `EXPLAIN`	查看代表性列表查询的执行计划	当前样本量小，只能作为性能观察起点
Git 与静态检查	核对版本、提交、JS／JSON 和页面事件及路由	静态检查不等同设备运行
AI 技术员	辅助拆解用例、识别契约差异、分析失败和整理证据	生成内容需人工结合代码与实测结果复核

典型复测命令，在 sgyrz-code 目录执行：

./tools/mvn.ps1 test
node tools/qa/qa-d1d2-regression.cjs
node tools/qa/qa-d3-frontend.cjs
node tools/qa/qa-d4-frontend.cjs
node tools/qa/qa-d5-match.cjs
node tools/qa/qa-d5-mine.cjs
node tools/qa/qa-d6-home.cjs
node tools/qa/qa-d6-admin.cjs
node tools/qa/qa-d6-points.cjs

实库脚本需要先启动明确指向隔离库的本地服务，并按仓库验收记录设置连接参数。测试账号与物品使用随机标识；脚本按本轮创建的记录清理，不清空团队业务库或 Redis。

分层验证的配合方式

单元与 H2 集成测试用于尽早暴露服务规则和参数边界问题，适合频繁执行；页面源码脚本可以控制请求先后顺序，复现手工操作中不容易稳定出现的竞态。两者执行快，但对真实 MySQL 的约束、SQL 行为和 Redis 会话仍需要额外检查。

实库 HTTP 测试将服务、数据库与会话依赖连接起来，核对请求是否真正产生预期记录。它可以验证权限拒绝、重复写入与余额变化，但不会验证微信组件如何渲染，也不会自动覆盖真实网络与设备差异。选择工具时按问题使用相应层次，再把结果放到同一业务路径中解释。

测试环境同样是用例前置条件。确认服务连接的是指定隔离库后，再创建带随机标识的测试账号与物品；清理时只处理本轮记录，不依赖全库重置获得“干净结果”。对于失败后残留的数据，先核对关联关系与归属，避免清理动作影响其他成员的联调材料。

四、测试用例文档

以下是覆盖主要业务与边界的代表用例；结果指所列环境中的已有记录。完整脚本和接口参数可在项目 tools/qa 与 docs/api-contract.md 中复核。

编号	前置条件与操作	预期结果	记录结果
T-01	新建隔离库，执行建库和验证脚本	21 表、字典与约束符合设计，重复记录被约束拒绝	通过；17 类／68 条字典，6 项负向约束通过
T-02	未登录或未认证用户尝试受保护操作	服务端拒绝，页面提示登录或认证	自动化覆盖身份及权限边界
T-03	认证用户发布寻物／招领并查询	服务端生成编号，记录进入对应列表与本人发布	页面和接口回归覆盖；D7 匹配实库样本发布成功
T-04	分页、类别、地点、时间筛选，切换筛选后旧请求晚返回	仅展示当前条件结果，越界为空，旧响应不覆盖新条件	D3 页面 13 项通过
T-05	对物品收藏、取消、重新进入详情	收藏状态与服务端一致，重复操作不产生重复收藏	D3 页面与接口回归覆盖
T-06	申请人提交认领，第三人访问私有核验	申请可回读，第三人请求被拒绝	D7 隔离实库通过
T-07	拾主确认归还并重复确认	物品与认领状态完成、善意值增加一次、流水和通知不重复	D7 隔离实库通过
T-08	两名参与者匿名会话，第三人读取或代标已读	双方可沟通，第三人被拒绝，未读按接收者更新	D7 隔离实库通过
T-09	发布异色耳机并等待自动匹配	返回对侧线索，颜色不一致不命中颜色判据，其他判据按当前规则计算	D7 隔离实库通过；命中类别、地点、时间和标题关键词
T-10	对同一物品重复重算	物品对不重复，未变化线索不反复标新	D7 隔离实库通过
T-11	归还后读取个人概览与善意流水	本人统计和余额与流水一致；其他用户不能读取拾主流水	D7 隔离实库通过
T-12	管理员审核申请，普通用户调用管理接口	通过／驳回更新状态并通知；普通用户访问受限接口被拒绝	D6 实库报告与页面脚本覆盖
T-13	管理员新增、修改、关闭收纳点	接口持久化可用字段，关闭保留历史；重复名称按契约处理	D6 实库报告与页面脚本覆盖
T-14	页面加载失败、分页失败或快速切换账号	有错误提示，重试原页；过时响应不覆盖当前身份	页面源码脚本覆盖

测试数据的输入和预期必须一致。D5 曾出现“蓝色耳机”使用黑色色码的样本问题；当时修正色码后分别设置异色和同色对照。之后匹配规则又加入标题关键词判据，因此 D7 更新旧脚本，不把 D5 的历史分数作为当前所有配置下的固定结果。

统一任务台账在 D7 结清剩余 23 点，累计记账 162 点、剩余 0 点。任务点数与下文的测试覆盖、跳过项及验收范围分别记录。

样本与反例设计

同一功能需要正常样本与对照样本。例如匹配的异色与同色耳机能帮助区分颜色维度是否生效；参与者与第三人使用相同资源编号，能检查授权是否真正依赖身份；第一次归还与再次归还使用相同业务记录，能检查幂等是否保护最终数据。

分页用例同时检查第一页、下一页、越界与失败重试。追加失败后保留已有内容，重试仍请求原来的下一页，不能因为一次失败跳过记录。查询条件变化后，需要确认页码和列表对应同一轮查询，而不是只检查请求发出过。

异步用例用可控响应安排返回顺序。先发旧请求、再发新请求，让新请求先返回、旧请求后返回，最终页面仍应显示新条件或新账号的数据。该场景还要区分正常换号与同一用户自动重登：令牌变化不必然表示用户变化，保护过严也可能导致正确结果无法显示。

个人中心则采用跨视角对照。拾主的帮助归还与积分来自归还记录，认领人的成功找回来自本人认领结果，第三人不应读取任何一方的私有流水。空账户应显示真实零值或空态，接口失败时应有明确提示，不能以演示分数掩盖故障。

五、测试结果与问题处理

5.1 执行结果

检查	结果	说明
D7 后端全量	160 项，0 失败、0 错误、2 项跳过	默认 H2／测试会话；两项外部依赖条件检查未执行
D1/D2 页面源码	17 项通过	登录失效重放、发布和草稿等
D3 页面源码	13 项通过	筛选、分页、详情、收藏和导航
D4 页面源码	15 项通过	认领、消息、未读和异常恢复
D5 页面源码	匹配 10 项、个人中心 11 项通过	独立线索页、本人统计、换号及分页
D6 页面源码	首页、认证审核、收纳点三组检查通过	检查各自关键交互与权限反馈，记录未给出统一项数
D7 认领与消息 HTTP	20 项通过	MySQL／Redis、local 模拟身份、隔离测试数据
D7 匹配与个人中心 HTTP	23 项通过	同上；脚本创建的数据已清理
D7 数据库初始化	正向检查 0 失败，6 项负向约束通过	新建隔离库；21 表、17 类／68 条字典
打包与静态检查	Maven 打包、相关页面 JS 语法及事件／路由检查通过	本地 JAR 与静态结果，不代表正式部署

这些数字来自不同脚本和不同测试层次，不直接相加作为全项目用例总数。D6 早期记录的后端测试集合为 159 项；D7 集合为 160 项，两者也存在重叠。

5.2 典型问题

登录失效后的重复失败。 请求层统一识别后端登录失效码，清理旧状态、尝试重新登录并重放请求；回归检查新令牌生效和请求次数。演示登录使用固定账号，不能据此代表真实微信登录通过。

重复归还导致积分风险。 归还同事务更新状态与善意流水，重复确认回读完成状态；实库检查首次与重复操作后的积分和流水数量。

首页待处理预览去重顺序。 一件物品有多条申请时，先限制申请行数会挤掉其他物品。后续改成先按物品分组再截取；早期实库报告中的发现和后续修复属于不同版本。

匹配脚本与最新规则不一致。 原 D5 脚本按历史三判据判断，D7 对照当前标题关键词规则调整后重新通过。测试断言应跟随契约和实现变化，但不能仅为通过而改预期。

查询性能需要继续观察。 代表性列表查询在 8 行样本下的 EXPLAIN 返回全表扫描和文件排序；样本规模不足以推断实际高负载，应使用更有代表性的数据量和查询条件复测。

5.3 结果判定与回归优先级

影响身份边界、写入一致性或主流程继续操作的问题优先检查。第三人能够访问私有数据，或重复确认导致额外计分，都不能因为其他页面正常就降低关注；失败后无法重试、旧响应覆盖当前结果等问题，也会直接影响用户继续完成操作。

回归范围随修改影响确定。只修改页面状态时，重点检查相关异步和错误恢复用例；涉及服务规则、查询或事务时，同时复核对应接口与数据结果。对仅改变排版的提交，可通过固定工具和差异核对确认范围，避免将无关修改混入业务修复。

通过数用于说明已经执行的测试集合，缺陷是否解决则取决于原触发路径能否复验。匹配样本和首页去重问题都说明，测试本身也需要审查：样本可能没有表达目标场景，断言也可能只检查到表面结果。

六、AI 技术员与自动化测试

AI 测试员协助把业务路径拆成身份、前置状态、操作和预期结果，例如针对认领补充申请人、拾主和第三人三种视角，再分别检查私有核验、确认、消息及已读。它也帮助整理请求序号测试，使用可控 Promise 让旧响应晚返回，以复现快速切换账号或筛选条件的问题。

AI 程序员协助追踪接口、事务和数据表关系；AI 文档助手将测试输出与提交版本对应。成员需要审查生成的测试数据、断言和清理范围：历史耳机色码错误表明，测试能通过并不自动说明样本有效。实库脚本通过随机测试身份和指定隔离库减少数据混淆，执行后检查清理结果。

AI 角色与审核重点

AI 角色	辅助任务	人工审核重点
AI 设计师	从用户路径展开正常、空态、失败和返回重进场景	页面负责人与验收成员确认这些路径属于当前实现范围
AI 程序员	追踪请求、服务、事务与表约束，分析失败原因	数据和安全负责人核对权限来源、写入范围及异常处理
AI 测试员	构造重复请求、第三人访问、旧响应晚返回等反例	测试成员检查前置条件、样本编码及断言是否有效
AI 文档助手	按版本整理命令、结果、跳过项和清理范围	集成负责人核对是否混用了历史结果与当前结论

AI 给出的测试建议需要转化为具体证据。针对“可能有越权”，应明确哪个身份访问哪个资源、预期拒绝什么操作；针对“可能重复结算”，应核对首次和再次请求后的余额及流水数量。只有把泛化建议落到可执行场景，才能为后续回归提供价值。

自动化脚本也要保持可读性。用例名称说明业务意图，失败输出提供定位线索，公共初始化与清理步骤控制在明确范围内；避免让脚本为了获得通过结果而自动改动团队数据或隐藏失败。这样的测试更适合作为交接资产，而不只是一次性的检查工具。

七、测试体会与项目测试评述

本轮测试的优点是覆盖从页面状态到真实数据库的多个层次。H2 与源码脚本执行快，适合每日回归；MySQL／Redis HTTP 检查能够核对真实写入、唯一约束和多账号边界。将测试与功能开发同步安排，也让问题可以在模块合并前暴露。

不足是现有自动化主要验证既定场景，不能证明所有并发、异常网络、视觉布局及外部服务都可靠。D7 按团队调整后的范围不做七屏连续走查、真机和真实微信身份验收；当前结论仅适用于已列出的模拟身份、自动化和实库检查。认证材料图片预览、收纳点营业时间、举报及代管页面、匹配阅读回执、独立双方确认与取消等仍有实现边界。

后续应补代表性数据规模的性能测试，扩展事务失败注入、并发竞争和敏感字段检查；根据实际产品范围完善管理与消息能力。测试随笔的目的不仅是汇总通过数，也要让下一位成员能够知道哪些结果可信、哪些场景尚未被覆盖。

...全文