这不就是回归测试的典型场景么？

回归测试：每天来回走一遍，看看哪里的砖有晃动；

自动化测试：骑个车（轮子宽一点的那种），碾压过去，提高效率，

埋点测试：路上等距离安装摄像头，然后在监控室里观察

用户反馈：人家都投诉了，你还不知道哪块砖有问题？做好安抚，快速修复。

业务需求：有没有一种可能，从业务的角度上看，确实有可能是故意设计的这么脆弱的，否则怎么签二期合同。（别对号入座哈），很多时候有些奇葩的需求都是服务于某些特定的场景，只是测试不知道而以。

我先来个现实点的：

1. 不被水呲不是人行道应该考虑的功能，属于正常现象——甩锅
2. 想要不被水呲，需要提需求，重新开发——加功能
3. 用户反馈太模糊，被水呲可能受到天气强度，人体体重，踩路面的角度，走路或者是蹦跳的方式有关，复现需要一定时间，期间我们先把人行道封了，禁止使用——配置关闭
4. 基于用户投诉被水呲，我们决定砍掉人行道，防止用户被水呲——产品重构
5. 有人恶意破坏路面——被黑
6. 路面维护人员被裁，路面年久失修——降低人力成本
7. 被投诉呲水的那块砖修复了，至于其他还有没有，发现再说——属遗留问题

回到题目，这题相当于在规模大的系统找到一类 bug，可以分以下几步：

1. 被水呲的砖应该有一定共同特征，肉眼扫描把 3kg 内所有符合此类特征的砖找出来标记好。（静态测试）
2. 扫描完后应该有漏网之余，也就是看着正常但是还是能呲水的砖，不计成本，可以每块砖挨个踩一下。（手工测试）
3. 由于有进度压力，每块砖踩一下花时间，决定加 3000 个人，每个人负责 1 米（项目冲刺）
4. 3000 人成本太高，决定买个检测工具，一个人执行一下就能检查 100 米，裁掉 2970 人。（降本增效）
5. 为了快速监测线上用户问题，决定每隔 100 米增加摄像头，并设置呲水报警系统。（监控报警）
6. 30 个人还是太多，引入智能机器人，每天按时在人行道巡逻，发现有问题的地砖报警，裁掉 29 人。（智能化）
7. 为了避免以后用户被水呲，定期加固地砖。（迭代）
8. 地砖的人行道始终可能导致呲水，决定换成沥青的。（产品重构）