穿行测试一般在系统设计前做，比如开发一个订餐软件，先让用户试用，看看流程哪里卡了，再调整程序。这就像先让朋友帮忙试吃新菜，发现盐放多了就改，而不是等做出菜再吃。主要目的是检查需求有没有被搞错，设计有没有漏洞。比如用户说“点菜后显示支付”不对，这时候才发现设计师没画清楚步骤，得赶紧改。测试人员带着纸笔跟着用户走一遍流程，记下每个卡点，给开发团队提改进意见。

为什么穿行测试要在设计前做呢？去年有调查显示，提前穿行测试的团队，需求错误率降低40%，返工成本减少60%。比如某公司做物流系统，穿行测试发现“包裹跟踪”页面跳转太复杂，用户平均要按7次才能找到信息，团队立刻调整了界面布局。其实穿行测试就像给程序穿行时检查鞋带，早发现松了就能避免后面跑断腿。但要是等到开发完才测试，可能发现需求文档和实际功能差得远，得重新返工。比如有个团队在穿行测试时发现“订单修改”功能根本没做，结果多花了2个月补代码。所以穿行测试就像给程序打补丁，越早做越省事。测试人员得提前准备流程图和问题清单，现场记录每个步骤的耗时和卡点，给开发团队列改进清单。