用結構化思維解一切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 的使用者也沒有任何明顯不同點。
直覺很有價值，可以更快找到正確路徑。但直覺未經過嚴格證明，不能把它直接當做結論，還需要做試驗證實。
另外，不用擔心自己直覺不準，它並不會影響最終結果，因為它只是猜測。只要你按照「假設樹」的路徑逐個遍歷，總會到達終點，只是要多做幾次試驗罷了。