分毫不差·同账——Alpha 冲刺测试随笔

目录

一、测试要和开发一起推进

同账是多人共同记账、结算的移动端 App。主路径按这个顺序走：

1. 登录，建账，邀请加入。
2. 记一笔消费。
3. 看余额，做结算预览，再正式冻结。
4. 登记已还，结清，最后做个人归档。

一笔消费同时碰到图片、分摊、账本版本、审计和幂等。其中一步写错，就可能记成两笔，或余额对不上。测试跟着功能往上加，先保住钱、权限和状态变化。页面能打开，只说明这一屏在。

《构建之法》在这篇里用了两处，写的是同账里的做法：

• 第 2 章「个人技术和流程」。 能单独验算的金额和分摊，放进每次都能跑的快速回归。
• 第 13 章「软件测试」。 证据分成四层：纯逻辑、接口/数据库、组件交互、原生操作。

作者在现代软件工程教学资料里，也把单元测试、回归测试和增量改进放在持续练习中。这里写的是这两章在同账里的用法。

(1) 写功能时就写清怎么验收。
(2) 发现缺陷后留下回归用例。
(3) 后面的修改再跑这些用例。截图留到最后一天集中补。

七天里测试跟着功能走

冲刺从 10 月 23 日到 10 月 29 日，一共七天。功能接到哪一层，当天的测试就补到哪一层。下面每一行只代表那一天那一次执行，不能把七天的通过数加在一起，也不能用后一天的数字改写前一天。

组件通过、JS 导出通过、Doctor 通过，各证一层。Android 上亲手走完的路径另记在当天博客，不写进上面的自动化数字。

（×）36 项算法回归写成业务结算已经完成。
（×）154 或 244 项组件通过写成真机或重新安装已经通过。
（×）某一天的哈希没变，就说今天又把同一套命令跑过一遍。

二、测试工作如何并行安排

上表登记的是各自负责核对的那一层。Day7 这次批量复核由系统架构账号统一组织，并在 Issue 里留言。同一套命令没有写成八个人各自执行了一遍。

测试层是随着功能阶段加上去的：

(1) 冲刺开头：测试命令、共享包检查、登录和权限基线。
(2) 建账和消费接上之后：邀请、分摊、图片。
(3) 正式结算、已还、归档接上之后：事务、并发、隔离。
(4) 后期：整条主路径，加上认证和断网恢复。工程再细化时，受影响的用例重跑。

任务和验收写在检查库 Issue，代码经 PR 审核。

• Day7 的后端复核与自动化 #69、#70、#71、#73 已有证据，直接评论结单。
• 文档同步和输出归档放进 PR #82。
• 固定候选的新安装、40 张原图、SQL 和交付文档在 PR #84 合并后关闭 #68、#72、#74、#75。T17、T18 各 8 点核销，剩余 16→0。最终 CI 是 run 40865952963。

（×）为八个人机械各开一个 PR。

三、为什么选择这些测试工具

这一轮没有另建浏览器端。组件测试负责渲染、事件和门禁，Android 模拟器负责选图、权限和真实界面。两层已经能分工，再叠一套浏览器自动化，对不上这一轮要留下的证据。

数据库测试和普通测试拆开跑：

• Vitest 把 *.integration.test.ts 排除在 pnpm test 之外。
• 集成用独立配置，先做迁移，再跑用例。
• TEST_DATABASE_URL 必须显式传入，库名以 _test 结尾。
• 库名后缀对了，仍要核对实际连上的是专用实例。Day4 曾在本机 PostgreSQL 18 上碰到外键失败，独立 PostgreSQL 17 复核 99 项通过，两份结果都留着。见 Day 4。

命令入口如下，数据库URL由本机未提交配置或CI注入：

pnpm check
pnpm test
pnpm test:mobile
# 显式注入专用 TEST_DATABASE_URL 后执行，不使用开发/共享业务库
pnpm test:integration

pnpm export:mobile 和 Expo Doctor 补的是工程检查。Doctor 在 Day5 候选上是 21/21，记在候选复核。

（×）JS 导出通过，写成原生 App 已经生成或已经安装。
（×）iOS 组件项目通过，写成 iPhone 已经跑通。

四、测试用例文档与三个重点案例

本篇同时提供独立的《同账-测试用例文档》，按“数据/步骤、预期、入口、实际结论”整理19类关键检查。以下编号是整理索引，不是新增测试函数数；完整夹具和断言以对应源码为准。

一行用例写哪四列

独立文档里的每一类都用同一套四列。下面三个案例是从这 19 类里抽出来写细的，其余类别留在随本文提供的《同账-测试用例文档》里。

四列齐了，这一行才能从文档走回仓库。只有预期、没有入口和当次结论的，不算这条用例已经跑过。

1. 金额是否真的一分不差

金额在库里用整数分。100 元是 10000 分，三人均分得不到三个相同的整数。

页面上显示「¥100.00」，只说明格式。上表这几行才说明总额守恒，以及换输入顺序之后分配仍然稳定。

代码在金额分摊测试。Day 6 里饶慧的记录写明：纯函数分摊通过之后，还要核对 expense_splits 里的 bigint 是否真的落库。

2. 请求失败，不能直接认为数据库没写入

消费接口可能已经写进数据库，客户端却没拿到响应。用户若换一个请求标识再保存，一笔就会变成两笔。

同一组集成测试同时看三件事：

• 相同键重放，只留下一笔记录。
• 同键、内容不同，返回冲突。
• 并发请求打进来，仍然不重复写入。

图片上传成功只是第一步。集成测试在绑定之后故意让后续数据库步骤失败，再检查消费、分摊、版本、审计和图片绑定是否一起回滚；显式重试之后应当成功。真实事务和锁竞争放在 PostgreSQL 里做。Day3 还遇到过游标：全连字符 UUID 和非法日期通过了形状校验，数据库类型转换变成 500，约定应是 400。许雅欣补了非法日期和 ID 回归，见 Day 3。

• 消费集成测试
• 图片集成测试

3. 迟到的200响应不一定还能算登录成功

Day6 遇到过这个时序：重新登录后，在线身份核验还没完成，设备已经断网，随后旧的核验请求返回 200。若只按这个 200 恢复页面，已经失效的操作会被重新放行。

回归用例用可以控制完成时刻的 Promise，把顺序钉死：

(1) 进入重新认证门禁。
(2) 发起核验。
(3) 标记断网。
(4) 再让那次请求返回成功。

预期仍停在门禁，业务请求准入为 false。用户显式重新登录，并且在线核验通过之后，才恢复。换账号时，原账号的表单和查询内存清掉。

修复前的失败、调整中和旧预期的冲突、最终结果，三份都留着。最后一张绿色输出单独拿出来，说明不了这条路径。

原生复测另有设备断网和迟到响应的画面，用来核对组件、控制器之外的那一层。代码在认证控制器测试，过程在#58/#59 修复与验收记录。Day5 还留下修复前的失败：反馈和断网保留，两平台各有 1 项先失败，修完才到 120 项，见 Day 5。

五、实际测试结果和CI记录

下表是 2026 年 10 月 29 日对 1d5709f 的一次真实执行。文档和输出随后归档在 df4d773。这篇随笔没有为了行文再跑一遍，这些数字也不延伸到之后的新提交。

计数口径写成三句：

(1) 250 项里，同类场景在 iOS、Android 两个 Jest 项目各跑一次。
(2) 125 + 250 + 136 = 511，是三次执行的通过记录合计。
(3) 511 次记录对不上 511 个互不重复的业务场景，也不是代码覆盖率。

本地 pnpm check 里，编译、类型检查和 Lint 通过。全工作区格式检查被 38 个未跟踪的冲刺报告和附件挡住。这些文件保留；已跟踪文件和本次文档另查了格式。PR #82 在干净检出上，check 和 container 都成功，然后快进合并。

压缩迁移之后，旧本地库和新库走的处理不一样。这次用独立容器和全新 _test 库，验证的是当前提交可以从零跑完迁移。已有开发库还能启动，证明的是另一份环境。

七天各自的通过数

冲刺共七天。上一节的 125、250、136 是 10 月 29 日对 1d5709f 的一次执行。它和表格里已列出的各天日志不是同一次，那些数留在各自的博客里，不并进这 511 次记录。

• Day1 只证明无数据库回归还在。 10 个文件、36 项，退出码 0。日志在华为云 Day1 测试输出。当时就写明：金额和分摊通过，不等于 HTTP 全流程已经接通。
• Day2 开始把数据库按 PR 拆开。 终端复跑是 105 项无数据库、56 项双平台。PR #9、#10、#11 的 27/27、34/34、38/38 是各自复审版本，不是这 105 项的重复计数。早先作者自测里的 35/36、37/38 没有写成最终复审。
• Day3 三层第一次同时出现。 112、154、96 分别对应无数据库、组件、真实 PostgreSQL。组件项目里同时有 iOS 和 Android，154 不是 154 个独立需求。
• Day4、Day5 用箭头留下版本。 集成 124→128，组件 178→180→184；Day5 再记组件 208→230→232、集成 128→129→130。箭头两端都保留，避免用最后一次绿色覆盖修复前的失败。
• Day6 的 125 / 244 / 136 仍是 10 月 28 日的候选。 本文表格里的 125 / 250 / 136 是下一天对 1d5709f 的另一次运行。244 和 250 都含两个 Jest 项目，不能互相替换，也不能和 136 项数据库测试加成一套“总用例数”。
• Day 7 在 250 之外还有一次 256。 #83、#84 的 CI 移动端是 24 套件、256 项，Doctor 21/21。这是后续主线上的另一次执行，不并进上面的 511，也不替换固定候选的 250。原生闭环记在 #72：1 个账本、2 名成员、12000 分消费、两条 6000 分分摊、封面和收据各 43952 字节、1 笔 6000 分 PAID、最终 SETTLED / version 5。SQL 在final-database.txt。归档前与归档后字节一致。40 张原图在验收附件。

检查库提交记录：Liangbai2333/tongzhang commits。七天附件都在华为云 CodeHub。

六、AI技术员在自动化测试中的作用

AI 编程助手参与分析代码、整理用例、定位失败和归纳证据。命令本身仍由 Vitest、Jest、PostgreSQL 和 GitHub Actions 执行。助手口头说的「应该通过」，要等终端退出码。

交给它的输入固定四样：

1. 业务约束。 金额任务写清整数分、最大余数法、稳定成员 ID、合计守恒。认证任务写清同账号恢复、换账号清理、断网后的迟到响应不得放行。
2. 相关源码。 指到当前候选上的测试文件，少给一整仓让它自己猜范围。
3. 已有失败。 修复前的红输出一起交，避免它把第一次失败改写成一开始就通过。
4. 要交回的结果。 可复现用例、真实执行结果、修改说明。缺一件，这篇就不把该项算成已核对。

测试代码没有逐段采纳台账。这篇不把 main 上的提交按代码风格整批算成 AI 生成、再由人逐行采纳。

已经能对上记录的，是它把多个文件串起来、把异常组合归纳出来、把大段输出整理成表。它也会把实现复述成预期，或把相近用例再算一遍。

绿色结果来自断言还在：

（×）删掉失败断言。
（×）把超时调大来躲开竞争。
（×）放宽权限约束换一次通过。

业务规则变了，只改和这条新规则有关的预期。凭据失效、断网阻断、跨账号隔离留在断言里。这篇没有人工耗时和 AI 耗时的对照记录，所以不写「效率提升了百分之多少」。

自动化工具和 AI 各管什么

作业里要写清两件事：自动化测试工具怎么选、怎么用，以及 AI 怎样帮上效率和准确性。同账把这两层分开。

工具是按项目加上去的，和第一节的七天同一条线：Day1 只有无数据库；Day2 加上双平台组件，数据库按 PR 复审；Day3 起无数据库、组件、PostgreSQL 三层一起记。AI 从 Day1 就以「测试」角色在岗，Day3 起这个角色固定叫测试证据核对。它读的是当天的 Issue、失败日志和候选上的测试文件，命令仍由上面这些工具执行。

效率和准确性分开记：

(1) 效率。 能对上记录的，是少在多个文件之间来回翻，把一次终端输出收成表，把不同版本的通过数拆开。没有耗时基线，这里不写百分比。
(2) 准确性。 退出码、原始日志和候选 SHA 由李润君或高娅婷按各自任务核对；不同一次跑出来的数字保持分开；合入仍走 PR。助手说「应该通过」，要等这三步。

（×）另选一套「由 AI 直接判通过」的测试产品，代替 Vitest、Jest 和 Actions。
（×）用整理速度代替准确性。

四个角色与验收人

Day1、Day2 用四个角色名。Day3 起收成三个，用到 Day7。业务提交以检查库 Liangbai2333/tongzhang 的合并记录为准。Day7 的 PR #80、#81、#83 在说明里注明 Claude Code 辅助，未注明的提交保持原作者。

架构核对（Day3 起称 架构资料整理）
七天都在。对照主路径、Service、接口、状态机和已合并 PR，列出已经接通的能力、还留着的入口，以及只读预览、正式冻结、消费事务、图片事务各自的边界。验收人是饶恩哲。

测试（Day3 起称 测试证据核对）
七天都在。Day1 实际执行无数据库回归；Day2 从终端复跑当前版本；Day3 起按版本拆开无数据库、组件、PostgreSQL 集成和原生范围。不同一次跑出来的通过数分开记。验收人是李润君，环境与安装证据由高娅婷核对。

文档整理（Day3 起称 文档与统计）
七天都在。写出八人进展、28 项任务 CSV、燃尽图、协作与签入截图、按正文顺序的图片包。发布前由饶恩哲核读；Day1 的文字另由袁湘湘核对。成员站会发言仍以各人当日四格为准。

编程 / 编程审阅
Day1 没有派新增业务实现，也没有代码采纳记录。Day2 只读已合并的认证、幂等、消费和反馈组件，核对退出清理、UUID 规范化和锁顺序，当天没有新的产品代码。Day3 到 Day6 不再单列。Day7 只把写进 PR 说明的辅助算进来。

（×）把三个整理角色写成第四名程序员。
（×）Day1 的「编程」没有派单，却写成已经生成并采纳了业务代码。
（×）Day2 的编程审阅写成当天又提交了一版产品代码。

测试证据怎么核对

测试证据核对七天都在。人工把关固定在发布前：饶恩哲核读架构边界和最终正文；测试数字由李润君、高娅婷按各自任务的真实日志核对。

Day2 终端里那一次无数据库复跑：

当天取舍的原图按日留在已发布博客里，测试随笔不把六张整理截图再贴一遍。需要对照原文时打开：

• Day1 AI 取舍原图所在博客，附件是测试输出
• Day3 AI 工作记录
• Day4 AI 工作记录
• Day5 AI 工作记录、统计口径
• Day6 AI 工作记录、统计口径
• Day 7、AI 工作记录、统计口径

（×）三个整理角色写成会提交业务代码的成员。
（×）Day1 没有派编程单，却写成业务代码已经生成并采纳。
（×）组件通过、JS 导出通过、Doctor 通过，写成真机或重新安装已经通过。
（×）用前一天的截图、旧的 401 叙述或未推送的本地报告，写成当天的新验收。
（×）没有采纳记录时，按代码风格改写 Git 作者。

能确认的贡献停在：把不同版本的测试数拆开，把命令、日志和原生图对上当天的 Issue / PR。合入、扣点和发布仍由对应职责的人确认。没有逐段采纳台账的测试代码，保持原作者和原提交。

七天验收落在哪

每天的整理稿都要落到具体的人和具体的 PR 上。下面按冲刺总结里已经写明的验收点摘测试相关的几条。

Day1。 架构核对交出接口占位清单和 28 项任务映射，饶恩哲验收。测试执行 pnpm test，10 个文件、36 项，李润君验收。文档整理交出报告、任务 CSV 和燃尽图，袁湘湘核对文字。源码来自 main 与 feat/mobile-figma-preview，当时的报告目录在 docs/sprint/2026-10-23/，整理时尚未推远程。附件是测试输出、任务表、签入清单。

（×）已有页面即登录成功。
（×）算法测试通过即业务结算通过。
（×）首日计划剩余 121 点写成实际业务已经做完。

Day2。 架构核对对照 #1–#8 和 PR #9–#12。只读预览和正式冻结、消费事务和图片事务、当日关闭和整项扣点，各写各的。

PR #11 的修改请求、作者修复和批准记录保留为人工复审。UUID 大小写误拒是饶恩哲用真实 HTTP 和 PostgreSQL 复现后提出的。T22 带收据的请求仍返回 501。协作记录在华为云 Day2 Issue/PR 快照。

（×）只看旧的绿色 CI 就可以合并。
（×）八个 Issue 全关等于跨日任务全部完成。
（×）把早先 35/36、37/38 的作者自测写成最终复审结果。

Day3。 角色名从这一天收成三个。测试证据核对的对象是 112 / 154 / 96 三组日志的来源、版本、真实数据库和原生范围，李润君和高娅婷各自核对。架构侧由饶恩哲核对正式冻结和只读预览的差别，范围是 #13–#20、PR #21–#26。当时本地稿在 docs/sprint/2026-10-25/report.md，整理时尚未推送。发布后的记录：AI 工作记录。

（×）八个 Issue 关闭等于全部冲刺结束。
（×）T22 / T23 自定义封面未完成时全额扣点。

Day4。 输入扩大到 24 个 Issue、17 个 PR 和当日原生截图。人工验收写到具体 PR：PR #35 的复核批准、PR #40 的缺陷修复与回归、PR #41 的审查和最终合并。API 已经跑通，和 App 入口还没接上，分成两句。快照在Day4 Issue/PR 记录。

（×）给任务负责人另编一个 Git 作者。
（×）JS 导出写成 APK 已经安装。
（×）timer 配置交付写成生产已经部署。

Day5。 输入是 32 个 Issue、21 个 PR、原始日志和当天原生截图。验收依据落到 #42–#49、PR #50–#53，以及 #52 的独立审查和验收矩阵。留下的是同键恢复、真实权限检查、三类独立错误、120/232/130 的实际日志、完整 Android 原图，以及旧 SHA 和新 SHA 的对应。业务候选提交和文档提交分开写，当日 Issue 完成和整项核销分开写。

（×）组件替身当作原生。
（×）旧图充当当天的 iOS 验收。
（×）复用客户端写成重新安装。
（×）三位后端联调编成各自独立的功能提交。

Day6。 输入是 40 个 Issue、27 个 PR、原日志和 61 张当日原生图。核对点是 #54 的候选和整项结论、PR #62 与 PR #65 的审查，以及 PR #62–#67 的合并记录。代码和测试上的取舍，以 PR #65 缺陷前后、Figma 原参考、回归和原生证据为准。整理本身没有再往 main 加产品代码。台账按 #54 从 48 点核销 32 点，剩下 16 点。手册里旧的「401 后丢掉表单」改成当前的同账号在线恢复。

（×）用 Day5 的 401 卸载画面证明 Day6 的新规则。
（×）把 #60 复用主链说成当天又跑了一遍完整闭环。
（×）把 12 秒超时探针称为超时内迟到成功。
（×）把 JS 导出写成 iOS 完整原生，或把兼容 APK 复用写成重新安装。

Day 7。 测试证据核对的对象是固定运行源码上的 125 / 250 / 136，以及 #84 CI 上的 256 项和 Doctor 21/21。125、250、136 来自 1d5709f，归档在 df4d773；256 属于更晚的 #83/#84，两次数不合并。原生证据是独立 AVD 上的新安装：40 张原图、结清 SQL（归档前与归档后字节一致）、401 门禁、门禁期间无写入、延迟 8 秒的迟到 200，以及换账号后 NeverTransferDay7 未落库。构建先留下 SDK 路径未继承和默认 JDK25的失败，显式指定 SDK 与 JDK17 后构建成功。饶恩哲确认 iOS 与 Android 真机已通过；本篇引用的操作画面仍是这组 Android 原图。#68–#75 已关闭，T17、T18 核销后剩余 0。

（×）用 df4d773 的 40 张图证明 #83 已经完整验收。
（×）把 250 和 256 加成一套移动端用例。
（×）新构建未再遇到旧图标偶发缺失，就写成所有设备都已修复。
（×）开发 APK 写成可以脱离 API 和 Metro 的生产包。

贡献停在「减少跨模块查找、减少重复排版和计算、把不同版本的测试数拆开」。合入、扣点和发布仍由对应职责的人确认。

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

测试体会

一条失败用例，往往比几十条顺利路径更能把设计问题露出来。金额余数、重复提交、迟到的 200、锁竞争，顺手点界面很难撞上。写进回归之后，后面的重构就有具体约束。

401 的规则中途换过：旧行为是清掉表单，新行为是同账号核验后再恢复。旧断言按新规则改；凭据失效、断网阻断、跨账号隔离留着。

项目测试评述

PR #80 提到部分图标偶现缺失。Day7 的新构建没有复现这一现象，记录停在「这一次未复现」，不扩大成所有设备都已修复。

Day7 收口之后，下面几项已经关闭：

• #68、#72、#74、#75 均为 closed
• 固定候选的新 APK、源码 ZIP、SHA-256 和启动说明在发布页
• T17、T18 各 8 点已经核销，原冲刺剩余 0

消费修改/删除、统计、资料修改和通知偏好保存仍返回 501，扫码未开放。本轮回归通过，这些能力继续记在已知限制里。

下一阶段按这个顺序补，每一项另建任务并写上版本：

(1) 按 #83 的导航和核验方式补受影响的平台复测。
(2) 生产签名和部署单独交付，和当前开发 APK 分开。
(3) 给高风险模块留覆盖率基线，再逐步加稳定性、性能和更多物理设备记录。

附：测试代码与证据入口

• 检查仓库
• Vitest普通测试配置、数据库测试配置、Jest双平台配置
• Day7最终复核与交付边界
• #58/#59修复与验收记录
• 测试文档与结果归档 PR #82、最终交付 PR #84
• 发布页 alpha-day7-20261029、资料提交 65227bd 上的验收说明
• 七天站会：Day 1、Day 2、Day 3、Day 4、Day 5、Day 6、Day 7。测试日志见第七天 unit.txt、mobile.txt、integration.txt
• 每日测试附件目录：华为云 CodeHub

独立用例文档随本文一同提供为《同账-测试用例文档.md》。发布CSDN时可将其表格一并贴入正文或上传附件，表中代码和日志已使用仓库完整链接，不依赖本机相对路径。