2009/10/11

思慮不周的捉迷藏遊戲

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

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

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

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

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

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

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

Technorati 的標籤:,,,

沒有留言:

張貼留言