他写的ATM能跑，测了47个用例后崩了

一个能正常取款的ATM系统，在47个测试用例面前碎成了渣。开发者亲手给自己写的代码做QA，这种"左右互搏"的狠操作，暴露的bug比代码行数还多。

这不是某个大厂的翻车现场，而是一个程序员的真实复盘。他从"我觉得能跑"到"我不知道能不能跑"，中间只隔了一次认真的手动测试。

01 | 从"能跑"到"能测"：一个开发者的自我背叛

他先写代码，后想需求。ATM系统的转账功能看起来正常——输入金额、确认、扣款、到账。但当他以QA视角写下第一个测试用例时，问题出现了：如果转账金额超过余额，系统该报错还是静默失败？他发现自己从没定义过这个行为。

代码先行的代价是：你写的每一行都在假设需求，而假设不会自己变成文档。

他被迫停下来，重新做了一件"不高效"的事：手写需求文档。不是那种应付检查的模板，而是带验收标准的、可执行的描述。比如"存款金额必须为正整数，且单次不超过10000元"——这条后来成了3个bug的照妖镜。

测试用例设计阶段更像是一场审讯。他问自己：如果存款时输入负数怎么办？如果转账到不存在的账户怎么办？如果用户连续三次输错密码？这些问题不是边缘场景，是设计里根本没考虑的空洞。他数了数，类似这样的"空洞"有11个。

02 | 执行测试：当系统开始"说实话"

真正动手测的时候，幻觉破灭了。他记录了三个典型翻车现场：

存款验证漏洞：系统允许输入负数金额，结果"存款-500元"变成了取款。这不是代码bug，是设计时没把"输入合法性"和"业务规则"分开处理。

转账体验陷阱：转账成功后没有任何确认提示，用户不知道钱到底转没转出去。他作为开发者时觉得"看余额变化就行"，作为QA时意识到这是反人类设计。

输入处理灾难：字母混进数字输入时，系统直接崩溃而非优雅报错。异常处理模块缺失，这是架构层面的偷懒。

他做了张简单的执行表：47个用例，通过31个，失败13个，阻塞3个。没有Jira，没有TestRail，就一个Markdown表格。但数字不会骗人——62%的通过率意味着"能跑"和"能用"之间隔着一整本测试用例。

每个缺陷他都按"现象-步骤-预期-实际"四栏记录。他说工具不重要，重要的是逼自己说清楚：到底哪里不对，怎么复现，应该什么样。这种 clarity of thinking（思维清晰度），比任何缺陷管理工具都值钱。

03 | 设计债：比技术债更难还

测完之后他做了个对比表。开发者视角问的是：功能实现了吗？QA视角问的是：功能能失败吗？这两个问题指向完全不同的代码结构。

他发现所有测出来的问题，根子都在设计阶段。输入验证和业务逻辑耦合，导致负数存款钻了空子；用户反馈和核心流程杂糅，让转账体验变得不可预测；异常处理被当成"后面再加"的东西，结果根本没地方加。

测试不会制造缺陷，它只是让已经存在的缺陷无处藏身。

这个认知让他重新理解了SDLC（软件开发生命周期）。需求模糊→设计凑合→编码硬撑→测试背锅，这是多少项目的真实剧本？他算了笔账：如果在设计阶段多花2小时拆模块，测试阶段能省8小时拆炸弹。但大多数人选择先跑起来再说。

他给自己的ATM做了次"可测试性改造"：把输入解析、业务规则、数据存储拆成三个独立层。改造后的系统还没写自动化脚本，但已经预留了所有接口。他说这是"为测试而设计"，也是为未来的自己留条活路。

04 | 从ATM到真实战场

这个项目的结局有点反高潮：他没有把ATM做成产品，而是把测试过程开源成了学习笔记。但收获比交付一个能用的系统更大——他建立了一套可复用的QA工作流，从需求→用例→执行→缺陷，每一步都有模板。

他特别提到一个细节：手动测试的价值被严重低估。不是因为它能发现多少bug，而是因为它强迫你慢下来，用人的节奏去理解系统。自动化跑一万条用例，也不会问你"用户这时候在想什么"。

现在的他接手新项目时，会先写测试策略再写代码。不是TDD（测试驱动开发）那种严格流程，而是一个更朴素的习惯：假设明天有个QA要测我的东西，我能给他什么？需求文档、接口说明、还是一句"你试试看"？

他说这次经历最大的反转是：本来想做ATM练手，结果练出了一身"给自己找茬"的本事。而在这个行业里，能给自己找茬的人，通常也能帮别人省掉很多凌晨两点的on-call。

如果你现在回头看你上周写的代码，你敢不敢像QA一样测一遍？不是跑一遍主流程，而是拿着需求文档逐条对、逐条问"如果用户不按套路出牌呢"。