从测试角度看现实问题

Thirty-Thirty 9
2022-08-30 11:59:44 未知地区 1F
回复

在定位砖的问题之前，先检查投诉的有效性这不就是回归测试的典型场景么？

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

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

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

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

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

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

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

被水呲的砖应该有一定共同特征，肉眼扫描把 3kg 内所有符合此类特征的砖找出来标记好。（静态测试）
扫描完后应该有漏网之余，也就是看着正常但是还是能呲水的砖，不计成本，可以每块砖挨个踩一下。（手工测试）
由于有进度压力，每块砖踩一下花时间，决定加 3000 个人，每个人负责 1 米（项目冲刺）
3000 人成本太高，决定买个检测工具，一个人执行一下就能检查 100 米，裁掉 2970 人。（降本增效）
为了快速监测线上用户问题，决定每隔 100 米增加摄像头，并设置呲水报警系统。（监控报警）
30 个人还是太多，引入智能机器人，每天按时在人行道巡逻，发现有问题的地砖报警，裁掉 29 人。（智能化）
为了避免以后用户被水呲，定期加固地砖。（迭代）
地砖的人行道始终可能导致呲水，决定换成沥青的。（产品重构）
#1 说的对
我的建议是直接全部覆盖沥青，解决现有和后续可能出现的板砖问题，全方位提高产品质量 派 20 个测试人员在雷雨天一个一个用脚踩, 确保每块砖都被踩过 —- 让点工去点点点3KM 的人行道，就很考验系统架构设计了吧，
最烂的系统就是需要你挨个砖块去踩，才能知道具体那块砖有问题；
最好的可能就是监控砖块状态，提前报警去把控分险租一台机器狗，设定好步幅，遍历一遍也就是几个小时的事情下雨天去看一遍不就清楚了其实这种是属于硬件问题吧？ 而且大概率和施工场地的地面情况有关系？

如果套用我们软件系统问题排查的方式，应该先看看正式环境上有没有 log，然后根据 log 去分析原因，再到测试环境去重现问题，验证分析结果是否正确；之后就是修复问题，测试环境验证和回归测试，部署上线然后验证问题已修复。

但是在这个场景下，一般是没办法造一个一摸一样的测试环境出来模拟的（不可能建一条一样的路出来吧？）。所以最好的方式，还得去同一条路上找问题，比如浇一遍水，走一走看那些砖会有问题；或者从工程的角度，看是否使用的材料，施工方式，排水设施是否有改进的措施，等等。1、首先，先解决问题，如找替代方案，安抚客户；
2、分析、定位问题，目前的产品设计下雨天，某些地方（模块）呲水是否符合预期，为什么
3、若不符合预期，如何改进（流程或技术等）投诉的频率是多少？
价值有多大？
用什么方法可以解决？
成本是多少？是的，这种问题的难点，可能就在生产条件的模拟。 不下雨的时候检查，可能没那么有用。 雨天检查，是不是还得考虑雨下多大，积水有多少，踩上去的是个胖子还是瘦子？
如果按照不下雨天的检查结果来保障，那么标准就相当于向上拔高，质量保障没有达到 “刚刚好” 的这个限度，成本会有损失。