原始網頁:http://taiwan.cnet.com/enterprise/column/0,2000062893,20084061,00.htm IBM軟體事業群Rational協理 吳佳惠 2003/10/13 我們都知道，「測試」是產品的真正試煉場；即使對一項軟體開發工程投注了龐大的心血，如果測試不合格還是枉然，因為客戶要的是「合格產品」，而不是你的「努力過程」。所以測試的重要性應該不必贅述。只不過，「知道」跟「做得到」是兩回事，就如同我們都知道應該多吃青菜水果，然而還是有許多人每餐都是大魚大肉。 許多人談到測試，總是有滿腹牢騷，因為它似乎是一件「知易行難」的麻煩工作。為何測試總是做不好？大致可歸類成下述三大原因。 測試排最後 目前一般的軟體開發工作，大多採用傳統的「瀑布式（Waterfall）」流程法，也就是把開發過程分為「需求」、「分析」、「設計與撰寫」、「整合」、「測試」等階段，一個接一個依序進行。 這種方法很單純，但導致「測試總是排在最後才進行」的狀況。這種設計會產生兩個狀況：一是測試人員直到案子接近尾聲才上工，所以往往在尚未瞭解整個系統架構的情況下，就一頭栽進工作。二是這個時間點距離完工期實在太近，如果有什麼突發狀況，往往導致整個開發專案大亂或失敗。 時間不夠 測試做不好的第二個原因是「時間不夠」，這是開發團隊最常面臨的問題。它其實也是上述「瀑布式」流程法把測試排在最後所導致的另一個致命傷。由於許多開發團隊把大部分時間分配給前面階段（特別是程式設計與撰寫部分），只留少數時間給測試工作。然而突發狀況永遠無法預期，如果前面階段因故導致工作拖延，在出貨時間不能延後的情況下，後面階段的時間就會不斷地被犧牲。 所以我們常常看到，在一個預定進行八個月的軟體專案裡，因為前面階段的狀況百出（電腦當機、同仁生病請假、客戶需求更改、開發不順等），結果前面階段不斷佔用後面階段的時間，最後導致原本排定一個月的測試時間只剩下一週，甚至二、三天而已，根本無法測試。所以常常出現有些產品根本是在未經完整測試的情形下就貿然出貨上市，把測試工作留給客戶或消費者的情況。 另外還有一個與「時間不夠」剛好相反的現象，就是「時間太長」。有時產品經初步測試之後發現問題叢生，實在無法交差（或是被客戶退件），所以開發團隊只好回頭繼續進行大量又重複的「測試→修改→驗證」工作。如此折騰了好一陣子，最後產品終於可以驗收。把這段額外時間加總起來，重新計算整體開發時間，這時才突然驚覺：「天啊，測試竟然佔了將近一半的時間！」 風險太高 第三個問題是「風險太高」，也是流程設計不當所致。如文章開頭所言：「測試才是產品的真正試煉場」，也就是一個專案的各種隱藏性風險，往往是透過「測試」才被完整發掘出來。但是「單向瀑布式」流程法卻把測試集中在最後進行，所以它的風險容易隨著開發流程的推進而越來越高；是一種相當危險的風險控管方式。 事實上，這也是許多專案在後期才突然出現成本失控或失敗的重要原因。因為等到風險爆發之時，往往已經無力回天，或必須付出相當大的代價以為因應。 解決之道：採用RUP流程 該如何解決這些問題？很簡單，因為問題核心出在流程設計，所以解決之道必須摒棄傳統的「單向瀑布式」流程法，改採「往復式」（Iterations）的RUP（Rational Unified Process）流程。它將一個準備開發的系統拆解成好幾個子系統，然後不斷往復循環整個開發流程，直到最終成品。 在RUP標準作業規範裡，測試是從一開始就進行的。首先，當客戶的需求被具體化與文件化之後，測試人員就會配合擬定相對的測試計畫，這個工作隨著客戶需求進入分析等後續階段，不斷被追蹤與進行細部修改，逐步接近系統層次。 然後，當任一子系統（或模組）在初期階段被開發出來，它的測試工作就會立刻進行，檢驗它是否完全吻合客戶需求與各項預定條件，如此就完成了一項子系統（模組）的所有開發工作。這也就是RUP所揭示的一項重要原則：「產品先出來，測試先行」。在整個開發流程裡，從單元、模組、模組整合到最終產品，測試工作始終依此原則不斷地進行。 這種方式的優點就在於可以完全解決前述「測試排最後」、「時間不夠」、「風險太高」等深深困擾許多開發團隊的棘手問題。 在RUP流程裡，測試人員從「一開始」就進入整個開發工作，所以是在完全理解並親身投入產品建置過程的情況下進行工作，不用等到最後階段才嘗試瞭解他所要測試的「到底是什麼東西」，自然可以避免瞎子摸象的危險。 其次，在RUP流程裡，測試人員的工作時間並不是集中在最後階段，而是平均分佈到整個開發流程，隨著過程推展而持續進行測試工作，所以測試人員根本不用擔心時間被佔用而到最後才拼命趕工。 最後，就是深刻影響開發專案成敗的「風險問題」。在RUP流程裡，我們確定「測試先行」的原則，特意讓可能隱藏的高風險在前面階段就先被發覺，然後以逐步降低的方式分散風險，所以不會有傳統瀑布式流程法「風險越來越高」的危機。 根據 Standish Group CHAOS 於1999年的統計報告，同樣一個問題，當它發生在前面階段與後面階段時，所需投入的「解決成本」的平均比例大約是1比200。經過上述兩種流程法對測試工作的優劣分析之後，相信各位應該很清楚要採用哪種流程方法了。 程式不是寫來玩的 而是要創造價值

------
林壽山
網站: http://superlevin.ifengyuan.tw
mail: superlevin@gmail.com