【读书活动感悟分享】《思考，快与慢》-“除了测试本身，设计测试用例的行为是已知的最好的错误预防措施之一”

      接受了《思考，快与慢》带来的思维之旅，我满脑子都是 “原来咱们的脑子还分‘快’、‘慢’两档”！书中将思维分为两个 “系统”：系统 1 是 “急性子”，靠直觉和经验做事，比如看到 “红灯” 就踩刹车，快是快，但经常犯 “想当然” 的错；系统 2 是 “慢性子”，得集中注意力慢慢琢磨，像解数学题似的，牺牲效率，却是避开坑的关键。作为一名软件测试人员，在工作中，对于这两种“脑子”的使用是随处可见的。

      在测试工作中，系统 1 的 “急性子” 让我们在享受效率时，也承担着“掉坑”的风险。比如遇见熟悉的功能模块，容易进入怪圈 —— 点这里、输那里，流程走得飞快，感觉 “稳了”。可偏偏就是这种 “想当然”，容易把藏在角落的问题漏过去。

       在验证CLP项目中的积分商城时，因为在蜀道项目中验证过类似的功能，验证时更容易关注以前出现过问题的场景，面对熟悉的功能，脑子里“飘渺且熟悉”的章程更容易在测试执行中占据高位。最终导致交付给客户验收的功能存在特殊场景下的bug。一场凌晨四点的失眠，对我的“快脑子” 好好的进行了反思：想提前预防“想当然”的测试工作，需要有更精细化的测试用例，也就是把 “慢脑子” 的系统 2 给激活了。

       设计测试用例这项工作，就是让测试人员从 “按流程点按钮” 的执行者，变身 “猜坑小能手” 的设计者。得慢下来琢磨：用户会不会手滑输错密码？网络卡顿时功能会不会崩？边界值会不会让系统 “懵圈”？

       这往往不是列个清单那么简单，得把需求文档嚼碎了，把业务场景想全了，甚至得站在开发的角度 “反向找茬”（永远不要相信开发者的代码！ps：开玩笑的）。比如设计代币发放的用例，不能只想着 “代币能够成功发放”，还得确认 “如果代币对应的代币包被下架了还能够发放么？”“这条代币发放中的代币数据被从代币包中删除了是否继续允许发放？”—— 每一条用例的琢磨，都是提前给潜在错误 “挖好陷阱”，同时也可以补充需求的漏洞。就像卡尼曼说的，系统 2 能 “翻遍脑子找知识，把问题掰碎了琢磨”，设计用例就是靠这股 “慢劲儿”，把藏着的风险都摆到明面上，实现 “没测先防”。

       设计测试用例的价值，不只是给执行找个依据，更在于用系统 2 的 “慢思考”，提前把错误挡在门外。以后工作中，可少依赖 “急性子” 的直觉，多花点心思用于打磨用例 —— 用 “慢劲儿” 换软件质量，协助测试工作更好的进行。好的用例设计，能让测试从 “事后补锅” 变成 “事前防坑”，既省了后期改 bug 的功夫，又能让交付质量提升，加大客户的信任度。