零代码文档驱动大模型开发---AI办公助手系列-验收测试-不应该只检查代码

多知识库做完，到了阶段性验收测试环节：一口气把代码从头到尾"审查"了五轮，揪出了 16 个 代码上bug，虽然一一解决了，但是，在我逐个功能一一实际使用中发现，真正会出事的那个 bug，五轮审查一个都没发现。这一篇，主要就是讲这次的验收中发现的问题：代码验收和实测验收，根本是两码事。

一、项目需求

功能越堆越多，怎么保证它"真的能用"，而不是"看起来能写对"？要的不只是改代码、跑测试，而是应该把软件跑起来，逐个按钮点过去，看真实效果。而且得有标准——测到什么程度算测完，不能"我觉得可以了"。

二、验收策略

• 六维测试体系：功能正确性、数据完整性（重启还在）、边界异常（空/超长/emoji）、UI 交互（弹窗三种关闭）、体验（空状态/错误提示/深色模式）、数据安全。

• 26 个真实点击的验收用例：从知识库弹窗、文档工具栏，到回收站、版本历史、模板、深色模式，逐个模拟点击验证。

• 一套验收标准：功能用例 100% 通过、缺陷按严重程度分级。

三、验收心得

为什么"代码审查"和"验收测试"是两回事？

前五轮我只审查了代码，修了 16 个"看得见的 bug"——空指针、边界、竞态、正则误匹配，每一个都能在代码里定位到明确的错误。我一度以为这就够了。

但真正把软件跑起来、一样样点，才发现漏掉的那个 bug 根本不在"某一行的错误"里，而在"两段逻辑之间的时序"里——后面细讲。

心得：静态审查抓得住"逻辑上的错"，抓不住"运行时的错"。代码审查是拿放大镜看每一行，但很多 bug 只在"真实跑起来、几件事碰在一起"的那一刻才现形。看代码和用软件，是两种完全不同的感知方式。

为什么测试要分"六个维度"？

一开始我的"测试"，就是"这个功能点了有没有反应"。但事实是——光看"功能对不对"，漏掉的东西太多了：数据重启后在不在？输入 emoji、超长文本会不会崩？弹窗能不能正常关？深色模式下还正常吗？API Key 会不会泄露？

这些东西都没有检查到，经过思考，我决定把测试拆成六个维度，每个功能都从这六个角度交叉检查一遍，而不是只测"主流程走通了"。

心得：测试的盲区，就是真实会踩的坑。 实际使用不会按写代码的顺序去用软件，而是会在边界、异常、深色模式、重启之后这些"冷门角落"里暴露问题。测得全不全，决定了产品能不能用，好不好用。

为什么先"学标准"，再动手测？

我最开始是"觉得这样测就可以"——写几个用例，跑通了就认为"验证通过"。但"觉得可以"和"真的可以"之间，差着一套明确的标准。

我的想法是：先去学正统的方法——用例设计用等价类、边界值、场景法；验收有硬标准（功能用例 100% 通过、缺陷分级）。照着标准来，才知道"测到什么程度算测完"。

心得：没有标准的努力，需要为后面的坑付出代价。 "我觉得测完了"和"按标准测完了"是两码事。

那个五轮审查都没发现的 bug，到底是什么？

我输入了一段文字，然后立刻右键"加入知识库"。结果软件报错说"文档没有可索引的内容"。明明刚敲进去字，怎么就说没内容？

查了半天，发现根因在"时序"——编辑器输入后，有 600 毫秒的防抖窗口，这期间内容还没写进数据库。而"加入知识库"这个动作，是去数据库里读内容的。用户在防抖窗口里点了加入，读到的就是"还没写进去"的旧内容。而这段代码，两半各自都写得对——保存逻辑对，读取逻辑也对，错的是它们之间"差一个 flush"。

心得：最阴的 bug，藏在"两段都对的代码之间"。单看每一段都无懈可击，只有真实跑起来、让"输入"和"点击"真正交错，那个 600 毫秒的空档才暴露出来。这也是为什么"检查代码"永远代替不了"真实点一遍"。