这是《落叶》文集里第 118 片落叶，希望你能喜欢，不为别的，只为这份坚持。
很多测试都头疼在产品上线后听到现网出问题，甚至会害怕听到问题反馈微信群的消息提示声。一旦遇到问题，多半都是以最快的速度将其解决，感觉就松了一口气。
遇到问题，第一时间去解决，的确没错，这是正确的响应行为。但我认为，既然问题已经发生了，解决问题只是一个理所应当的动作，但仅仅解决完，还不到松口气的时候。真正重要的事情其实是在问题被解决之后才刚刚开始，而这些恰恰是最容易被忽略的。
首先，我们要对现网问题进行分类统计，后续才好根据不同类别的问题再进行后续深入动作。我个人理解，主要就两类问题：
一、缺陷
也就是 Bug，对这类问题需要做 WWW 分析，这个分析其实在接到现网问题时就会去分析，但在事后还是需要再分析一次，因为在处理问题时的分析也许相对个体化或特例化，在事后其实就可以集中一些同类别的现网 Bug 做更垂直深入和拓展性的分析。
What's the problem?
对问题做一个清晰且专业的描述，因为，往往现网反馈的问题，只是表象上的描述或者只是非专业的破碎化的叙述，我们需要对它们做一个“转译”，便于后面会说到的再利用。
What's the root cause?
找出会产生此类问题的根本原因，我所遇到过的有这样几类：
1、测试用例没有覆盖到；
2、测试策略没有考虑到；
3、测试执行的遗漏；
4、系统没有做相应的操作保护，用户操作导致的异常数据；
What's the solution?
针对 1 和 2，要从测试用例的设计方法和测试计划环节着手去提高和改进；
针对 3，要从测试过程的监控和测试产物质量的验收环节着手去提高和改进；
针对 4，要从自身系统的易用性和健壮性考虑，去提高和改进；
二、操作问题
从这类问题中，我们一般会汇总产出两样东西：
1、用户操作问题 FAQ；
这个 FAQ 除了可用于产品帮助文档的补充，或客服的问题参考文件之外，还有一个比较重要的功能，就是我们通过整理这个 FAQ 的过程，可以分析出一些我们没有想到过的用户行为习惯，往往可以帮助我们找到一些潜在的系统问题。
2、产品交互设计的改进；
这个产物可以帮助我们的产品交互设计师持续提高产品的用户体验满意度。
在现网问题的处理过程中，还有一个重要的可持续更新的产物，那就是“现网问题信息确认清单”，这个 Checklist 主要包含某一类多发型问题，在用户反馈到客服处时，客服需要跟用户沟通收集哪些必要信息，一方面对问题可以做一次初步筛查，另一方面也为后续技术部门查原因提供了更为完整的信息。
只有做完上述这些事情，我们才可以好好地松一口气。这也是我始终坚持的一个观点，就是现网问题的处理过程一定要和产品研发过程（至少是产品质量检测环节）形成一个闭环，即从现网问题的处理流程中获取到的产物，一定要作用于产品研发或质量检测流程，改进也好，补充也好，杜绝也好，都不能落在空处，否则现网问题的处理就仅仅只是停留在解决问题的表层，而无法真正做到避免同类问题再次发生。
我们可以允许自己第一次犯错，但一定不能允许自己再次犯同一个错。
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
