之前写过有关故障的博客：故障的坑，你踩了多少遍，分析总结了常见问题的原因。平时工作/面试中，常常被问题：XXX类测试，常用的测试方法/常存在的问题？刚被问这个问题的时候，自己通常会根据已经历的项目，遇到的问题等来说典型问题是什么，应该如何避免。但随着接触越来越多的项目实践，对典型问题的理解，不禁思考： 真的有对某类产品独有的典型问题吗？
一、“蒙着面纱”的典型质量问题
平时工作/面试中，常常被问题：
算法类测试通常存在的问题？
支付类产品通常存在的问题？
电商类产品通常存在的问题？
B端产品通常存在的问题？
...
二、典型质量问题根源分析
所谓典型问题，无非是某类产品常常发生的问题。拿支付类产品来说，刚工作的时候，对测试过的支付类产品，“自以为”形成了一套支付类产品的典型问题。但随着测试经验的积累，发现之前的“支付类”经验“竟然”出现在了算法类产品中。随着更多经验的积累，发现典型问题中的90%都是所有系统都会遇到的，剩下10%是某类产品测试所独有的。
究其根本原因在于，质量问题往往是代码问题，技术问题，只要某类产品使用了该技术，就会存在该类技术带来的典型问题。该类技术由于通常会被用在某类产品中，故而才会产生“错觉”：某类产品具有典型的问题。其实与其说是某类产品具有典型的问题，更准确应该说：某种技术具有典型的问题。
三、典型问题总结
-
第三方系统交互。交互是忽略掉了异常场景的交互；依赖第三方时，没有通知第三方直接上线等
-
计算公式使用问题
联动排序问题
打点问题。打点字段等
app独有。SDK crash、横竖屏、3G/4G/WIFI网络问题、
上线配置问题。上线地址、开关等配置项配置错误
代码提交问题。分支提交错误，提交代码被覆盖、代码被误删等
消息队列问题。消息堆积，异常告警处理等
回归场景覆盖不全。边缘场景出问题，没有回归到
性能问题。内存fullgc，没有紧急处理机制，线程阻塞等
告警缺少。异常场景下，缺少有效的告警灯
常用判断。异常时没有catch并处理，并无告警
重试机制。缺少失败后重试机制
异常场景覆盖不全。文件大小，图片格式，空指针等
缺少业务监控。接口502，504等
兼容问题。 代码向下兼容，旧数据兼容等
数据精度问题。
日志/告警不全问题。出现问题时，日志，告警不全
SQL问题。慢SQL，主从延迟等
传参问题。前端传参错误
样式兼容问题
登陆缓存问题。缓存失效，token/cookie问题等
业务场景覆盖不全。排列组合形成场景覆盖不全
支付结果(成功/失败/延迟/超时
支付场景(含第三方，取消->支付，登陆与否，退款)、测试全量场景(各种级别用户*各种金额*各种折扣方式*各种支付方式)
测试场景-幂等
安全场景。敏感信息页面显示、加密等
超时场景。
友好性
总结
面对故障，这里列举几点理解误区：
- 只要发生故障，测试人员就是第一责任人
- 故障复盘会，根本目的就是找出这次的“根源”及解决方案
为了更好预防和避免故障的发生，这里列举几个观点：
- 故障的发生不可避免，能做的就是尽可能做到：提前发现、控制损失、尽早恢复线上
- 故障的预防涉及：需求、设计、编码、测试、运营等等方方面面，不可将其押宝在测试这一个阶段
- 故障的处理措施有效性评估：能否及时发现、能否快速线上恢复
故障的预防、处理、复盘是整个项目团队的责任。从故障中可以窥见整个项目方方面面的问题，如需求合理性、架构设计、预防方案、团队合作友好度等等。故障的真正预防，必须从这些方面入手进行。