平时走在人行道上，尤其是下雨天，踩到一块砖总会有污水呲出来。
假设现在有 3KM 的人行道，有人投诉下雨天被水呲了，怎么样快速定位是哪些地方的砖有问题？
我先来个现实点的：
- 不被水呲不是人行道应该考虑的功能，属于正常现象——甩锅
- 想要不被水呲，需要提需求，重新开发——加功能
- 用户反馈太模糊，被水呲可能受到天气强度，人体体重，踩路面的角度，走路或者是蹦跳的方式有关，复现需要一定时间，期间我们先把人行道封了，禁止使用——配置关闭
- 基于用户投诉被水呲，我们决定砍掉人行道，防止用户被水呲——产品重构
- 有人恶意破坏路面——被黑
- 路面维护人员被裁，路面年久失修——降低人力成本
- 被投诉呲水的那块砖修复了，至于其他还有没有，发现再说——属遗留问题
回到题目，这题相当于在规模大的系统找到一类 bug，可以分以下几步：
- 被水呲的砖应该有一定共同特征，肉眼扫描把 3kg 内所有符合此类特征的砖找出来标记好。（静态测试）
- 扫描完后应该有漏网之余，也就是看着正常但是还是能呲水的砖，不计成本，可以每块砖挨个踩一下。（手工测试）
- 由于有进度压力，每块砖踩一下花时间，决定加 3000 个人，每个人负责 1 米（项目冲刺）
- 3000 人成本太高，决定买个检测工具，一个人执行一下就能检查 100 米，裁掉 2970 人。（降本增效）
- 为了快速监测线上用户问题，决定每隔 100 米增加摄像头，并设置呲水报警系统。（监控报警）
- 30 个人还是太多，引入智能机器人，每天按时在人行道巡逻，发现有问题的地砖报警，裁掉 29 人。（智能化）
- 为了避免以后用户被水呲，定期加固地砖。（迭代）
- 地砖的人行道始终可能导致呲水，决定换成沥青的。（产品重构）
在定位砖的问题之前，先检查投诉的有效性
这不就是回归测试的典型场景么？
回归测试：每天来回走一遍，看看哪里的砖有晃动；
自动化测试：骑个车（轮子宽一点的那种），碾压过去，提高效率，
埋点测试：路上等距离安装摄像头，然后在监控室里观察
用户反馈：人家都投诉了，你还不知道哪块砖有问题？做好安抚，快速修复。
业务需求：有没有一种可能，从业务的角度上看，确实有可能是故意设计的这么脆弱的，否则怎么签二期合同。（别对号入座哈），很多时候有些奇葩的需求都是服务于某些特定的场景，只是测试不知道而以。
我先来个现实点的：
- 不被水呲不是人行道应该考虑的功能，属于正常现象——甩锅
- 想要不被水呲，需要提需求，重新开发——加功能
- 用户反馈太模糊，被水呲可能受到天气强度，人体体重，踩路面的角度，走路或者是蹦跳的方式有关，复现需要一定时间，期间我们先把人行道封了，禁止使用——配置关闭
- 基于用户投诉被水呲，我们决定砍掉人行道，防止用户被水呲——产品重构
- 有人恶意破坏路面——被黑
- 路面维护人员被裁，路面年久失修——降低人力成本
- 被投诉呲水的那块砖修复了，至于其他还有没有，发现再说——属遗留问题
回到题目，这题相当于在规模大的系统找到一类 bug，可以分以下几步：
- 被水呲的砖应该有一定共同特征，肉眼扫描把 3kg 内所有符合此类特征的砖找出来标记好。（静态测试）
- 扫描完后应该有漏网之余，也就是看着正常但是还是能呲水的砖，不计成本，可以每块砖挨个踩一下。（手工测试）
- 由于有进度压力，每块砖踩一下花时间，决定加 3000 个人，每个人负责 1 米（项目冲刺）
- 3000 人成本太高，决定买个检测工具，一个人执行一下就能检查 100 米，裁掉 2970 人。（降本增效）
- 为了快速监测线上用户问题，决定每隔 100 米增加摄像头，并设置呲水报警系统。（监控报警）
- 30 个人还是太多，引入智能机器人，每天按时在人行道巡逻，发现有问题的地砖报警，裁掉 29 人。（智能化）
- 为了避免以后用户被水呲，定期加固地砖。（迭代）
- 地砖的人行道始终可能导致呲水，决定换成沥青的。（产品重构）
#1 说的对
我的建议是直接全部覆盖沥青，解决现有和后续可能出现的板砖问题，全方位提高产品质量
派 20 个测试人员在雷雨天一个一个用脚踩, 确保每块砖都被踩过 ---- 让点工去点点点
3KM 的人行道，就很考验系统架构设计了吧，
最烂的系统就是需要你挨个砖块去踩，才能知道具体那块砖有问题；
最好的可能就是监控砖块状态，提前报警去把控分险
租一台机器狗，设定好步幅，遍历一遍也就是几个小时的事情
下雨天去看一遍不就清楚了
其实这种是属于硬件问题吧？ 而且大概率和施工场地的地面情况有关系？
如果套用我们软件系统问题排查的方式，应该先看看正式环境上有没有 log，然后根据 log 去分析原因，再到测试环境去重现问题，验证分析结果是否正确；之后就是修复问题，测试环境验证和回归测试，部署上线然后验证问题已修复。
但是在这个场景下，一般是没办法造一个一摸一样的测试环境出来模拟的（不可能建一条一样的路出来吧？）。所以最好的方式，还得去同一条路上找问题，比如浇一遍水，走一走看那些砖会有问题；或者从工程的角度，看是否使用的材料，施工方式，排水设施是否有改进的措施，等等。
1、首先，先解决问题，如找替代方案，安抚客户；
2、分析、定位问题，目前的产品设计下雨天，某些地方（模块）呲水是否符合预期，为什么
3、若不符合预期，如何改进（流程或技术等）
投诉的频率是多少？
价值有多大？
用什么方法可以解决？
成本是多少？
Jerry li
回复
是的，这种问题的难点，可能就在生产条件的模拟。 不下雨的时候检查，可能没那么有用。 雨天检查，是不是还得考虑雨下多大，积水有多少，踩上去的是个胖子还是瘦子？
如果按照不下雨天的检查结果来保障，那么标准就相当于向上拔高，质量保障没有达到 “刚刚好” 的这个限度，成本会有损失。