用结构化思维解一切BUG（3）：实际案例

背景
本文是系列文章《用结构化思维解一切BUG》的第 3 篇，也是最高潮篇！本系列文章主要介绍一种「无需掌握技术细节，只需结构化思维和常识即可解一切BUG的方法」。
在前序文章《用结构化思维解一切BUG（1）：核心思路》中，我介绍了本方法的核心思路，即，基于结构化的「假设树」，通过重复多次执行「做试验→造现象→缩范围」动作序列，逐级下钻，缩小问题范围，直到找到问题根因。
在前序文章《用结构化思维解一切BUG（2）：实践原则》中，我介绍了本方法的实践原则，「程序断案三字经」，总结为 5 条 30 个字：

• 先诊断，后开药。
  
• 信机器，慎信人。
  
• 做试验，缩范围。
  
• 找不同，看变化。
  
• 先脆弱，后稳定。
  

本文我将带大家进入真实BUG场景，在场景中介绍「假设树」如何生长、如何执行「做试验→造现象→缩范围」小闭环、如何运用实践原则。同时，您也从中感受到该方法的强大！

_提醒：_本文中，假设树的生长图和试验记录表格是重点，建议点击图片全屏预览，如用手机建议横屏观看。

案例背景
这个客户是创立了 20 年的国际贸易和海外工业制造公司，目前在筹备上市。为应对上市要求，需要搭建自己的质量管理系统。
这个应用由一个「导航应用」和多个「子应用」构成。导航应用中有多个子应用的链接。当用户登录导航应用后，点击任何一个子应用的链接，即可快速进入这些子应用，无需再次登录。请记住这里的「导航应用」和「子应用」，后文会多次提到。
有一天，客户反馈，部分用户有「跳转到子应用后无法自动登录」的问题。

显然，这仅有的信息，我无法做出任何有效判断。
大多数业务用户，甚至是程序员，在反馈问题时都缺乏必要细节。作为问题解决者，我的第一个任务就是，问对问题，得到我想要的信息。我一般会用 5W2H 的方法来问问题（请注意后续问题的中括号标注），以全面了解信息。

提醒：如果您是程序员，强烈建议刻意培养自己「提出一个好技术问题」的能力，因为好的问题才有更大几率被快速回答。具体请参考我的另一篇文章《如何提出一个好的技术问题？》。

明确问题
首先，我需要明确问题[What]。即，问 3 个问题：

• 希望的现象是什么？[To-Be]
  
• 实际的现象是什么？[As-Is]
  
• 哪个点不满足希望？[Gap]
  

在本场景中，三个问题的答案为：

• 希望用户可以免登录地进入子应用。
  
• 实际现象是，用点击子应用链接后，应用自动在新标签页打开一个登录页面。且这个登录界面就算输入正确密码和账号，也无法登录。
  
• 无法正常访问子应用。
  

缩小范围
根据上一篇文章的「假设树」方法，我们第一层需判断此问题是前端问题还是后端问题。
为了方便引用，我们把发生 BUG 和不发生 BUG 的用户分为两组，发生 BUG 的用户成为 N （Negative）组，未发生 BUG 的用户成为 P （Positive）组。
于是，我问了如下问题：

这个诊断过程，我践行了如下原则：

• 「先诊断，后开药」。在没有弄清楚问题根因之前，不做任何正式的修改建议。
  
• 「找不同，看变化」。尽量从现有现象中，找到大家的不同点，看有什么变化，变化就是线索。
  

有了这些信息，我靠直觉猜测，大概率是前端问题，且是浏览器问题。因为，从后端来看，我很难想到这两组用户在代码和数据上有显著的不同特征。具体来说：

• 后端代码，两组用户肯定是一样的。
  
• 后端数据，发生了 BUG 的用户没有任何明显相似点，发生 BUG 的用户与没发生 BUG 的用户也没有任何明显不同点。
  

直觉很有价值，可以更快找到正确路径。但直觉未经过严格证明，不能把它直接当做结论，还需要做试验证实。
另外，不用担心自己直觉不准，它并不会影响最终结果，因为它只是猜测。只要你按照「假设树」的路径逐个遍历，总会到达终点，只是要多做几次试验罢了。

<strong>
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！