思慮不周的捉迷藏遊戲

在 ASP.NET 設計環境中，幾乎所有控制項都可以設定 Visibility，也就是顯示/隱藏的開關。此外，還有 Div, Panel, PlaceHolder 等等 Container，也可以設定 Visibility，一次就讓一群控制項隱藏或是消失。

在一般情況下，我認為大部份程式設計師都會使用這點便利性來設計程式。例如，我在網頁上放了一段文字和控制項，是專門用來顯示Ａ商品的，並且以 Div 包起來(命名為 divA)。另外又寫了一段文字是控制項，是專門用來顯示Ｂ商品的，同樣用 Div 包起來(命名為 divB)。

接著，我在網頁最上面放了一個 DropDownList，當使用者從裡面挑選了Ａ商品，我就把設定 divA.Visible = True，並設定 divB.Visible = False。而當使用者挑選了Ｂ商品，我就把設定 divA.Visible = False，並設定 divB.Visible = True。

上述這種情境是最單純、而且沒有出錯空間的。但是當情況開始複雜，例如要控制的 Div 不只兩個(或者不同 Div 之間的顯示/隱藏有關連性)、觸發隱藏/顯示的事件也有許多個的時候，問題就會開始發生了。其複雜度，會以 2 的次方而急速的增加。例如 Div 有兩個時，會有四種路徑要考慮，Div 有三個時，有八種路徑... 當 Div 有十個時，則有 1,024 種路徑。而現實的情況更為複雜，例如使用者挑選Ａ商品時，divA、divD、divF要開啟，而 divB、divC、divE 要關閉；而當 divA 裡面又有按鈕被按下時，divB、divC 又要被開啟... 等等。

若要完全解決這種問題，就是簡化設計，讓可能的路徑愈單純、愈少愈好。不過通常實際上恐怕沒有辦做到完全的簡化，因為各控制項的顯示/隱藏邏輯就是那麼複雜，簡化不了。在這種情況下，測試人員可以發揮創意的時候就來了。

測試理論中的「路徑分析」，就是要用在這種地方啦！這個理論不只是用在程式碼的分析而已，而是更應該使用在情境的邏輯分析裡面。唯有撰寫面面俱到的 Test Case，準備多樣化的測試 Pattern，才有辦法把所有可能發現的問題給逼出來。所以如果你是測試者，當你發現程式設計師大量使用控制項的隱藏/顯示功能的時候，就可以注意某個訊息或控制項是不是沒有在該出現的時候出現，在該消失的時候消失。而當你在 Bug Report 中寫出來，在某某狀況下，某個訊息或控制項沒有指定 Visible = True 或 False，那麼程式設計師可能會崇拜你喔（呵呵，或是恨死你）!

身為一個程式設計師，我可以告訴你，這就是程式設計師的弱點之一。只要稍稍有點思慮不周，錯誤就跑出來了。對於一頭埋在程式碼裡面的程式設計師，這種情形是一個很大的盲點，如果沒有專業又有經驗的測試工程師，這種問題就只有等到客戶來發現了。

Technorati 的標籤：測試,Testing,錯誤,Visibility