解決軟件測試的三大棘手問題

我們都知道，「測試」是產(chǎn)品的真正試煉場；即使對一項軟件開發(fā)工程投注了龐大的心血，如果測試不合格還是枉然，因為客戶要的是「合格產(chǎn)品」，而不是你的「努力過程」。所以測試的重要性應(yīng)該不必贅述。只不過，「知道」跟「做得到」是兩回事，就如同我們都知道應(yīng)該多吃青菜水果，然而還是有許多人每餐都是大魚大肉。

許多人談到測試，總是有滿腹牢騷，因為它似乎是一件「知易行難」的麻煩工作。為何測試總是做不好？大致可歸類成下述三大原因。

測試排最后

目前一般的軟件開發(fā)工作，大多采用傳統(tǒng)的「瀑布式（ Waterfall ）」流程法，也就是把開發(fā)過程分為「需求」、「分析」、「設(shè)計與撰寫」、「整合」、「測試」等階段，一個接一個依序進行。

這種方法很單純，但導(dǎo)致「測試總是排在最后才進行」的狀況。這種設(shè)計會產(chǎn)生兩個狀況：一是測試人員直到案子接近尾聲才上工，所以往往在尚未了解整個系統(tǒng)架構(gòu)的情況下，就一頭栽進工作。二是這個時間點距離完工期實在太近，如果有什么突發(fā)狀況，往往導(dǎo)致整個開發(fā)項目大亂或失敗。

時間不夠

測試做不好的第二個原因是「時間不夠」，這是開發(fā)團隊最常面臨的問題。它其實也是上述「瀑布式」流程法把測試排在最后所導(dǎo)致的另一個致命傷。由于許多開發(fā)團隊把大部分時間分配給前面階段（特別是程序設(shè)計與撰寫部分），只留少數(shù)時間給測試工作。然而突發(fā)狀況永遠無法預(yù)期，如果前面階段因故導(dǎo)致工作拖延，在出貨時間不能延后的情況下，后面階段的時間就會不斷地被犧牲。

所以我們常?？吹?，在一個預(yù)定進行八個月的軟件項目里，因為前面階段的狀況百出（計算機當機、同仁生病請假、客戶需求更改、開發(fā)不順等），結(jié)果前面階段不斷占用后面階段的時間，最后導(dǎo)致原本排定一個月的測試時間只剩下一周，甚至二、三天而已，根本無法測試。所以常常出現(xiàn)有些產(chǎn)品根本是在未經(jīng)完整測試的情形下就貿(mào)然出貨上市，把測試工作留給客戶或消費者的情況。

另外還有一個與「時間不夠」剛好相反的現(xiàn)象，就是「時間太長」。有時產(chǎn)品經(jīng)初步測試之后發(fā)現(xiàn)問題叢生，實在無法交差（或是被客戶退件），所以開發(fā)團隊只好回頭繼續(xù)進行大量又重復(fù)的「測試 → 修改 → 驗證」工作。如此折騰了好一陣子，最后產(chǎn)品終于可以驗收。把這段額外時間加總起來，重新計算整體開發(fā)時間，這時才突然驚覺：「天啊，測試竟然占了將近一半的時間！」

風(fēng)險太高

第三個問題是「風(fēng)險太高」，也是流程設(shè)計不當所致。如文章開頭所言：「測試才是產(chǎn)品的真正試煉場」，也就是一個項目的各種隱藏性風(fēng)險，往往是透過「測試」才被完整發(fā)掘出來。但是「單向瀑布式」流程法卻把測試集中在最后進行，所以它的風(fēng)險容易隨著開發(fā)流程的推進而越來越高；是一種相當危險的風(fēng)險控管方式。

事實上，這也是許多項目在后期才突然出現(xiàn)成本失控或失敗的重要原因。因為等到風(fēng)險爆發(fā)之時，往往已經(jīng)無力回天，或必須付出相當大的代價以為因應(yīng)。

解決之道：采用 RUP 流程

該如何解決這些問題？很簡單，因為問題核心出在流程設(shè)計，所以解決之道必須摒棄傳統(tǒng)的「單向瀑布式」流程法，改采「往復(fù)式」（ Iterations ）的 RUP （ Rational Unified Process ）流程。它將一個準備開發(fā)的系統(tǒng)拆解成好幾個子系統(tǒng)，然后不斷往復(fù)循環(huán)整個開發(fā)流程，直到最終成品。

在 RUP 標準作業(yè)規(guī)范里，測試是從一開始就進行的。首先，當客戶的需求被具體化與文件化之后，測試人員就會配合擬定相對的測試計劃，這個工作隨著客戶需求進入分析等后續(xù)階段，不斷被追蹤與進行細部修改，逐步接近系統(tǒng)層次。

然后，當任一子系統(tǒng)（或模塊）在初期階段被開發(fā)出來，它的測試工作就會立刻進行，檢驗它是否完全吻合客戶需求與各項預(yù)定條件，如此就完成了一項子系統(tǒng)（模塊）的所有開發(fā)工作。這也就是 RUP 所揭示的一項重要原則：「產(chǎn)品先出來，測試先行」。在整個開發(fā)流程里，從單元、模塊、模塊整合到最終產(chǎn)品，測試工作始終依此原則不斷地進行。

這種方式的優(yōu)點就在于可以完全解決前述「測試排最后」、「時間不夠」、「風(fēng)險太高」等深深困擾許多開發(fā)團隊的棘手問題。

在 RUP 流程里，測試人員從「一開始」就進入整個開發(fā)工作，所以是在完全理解并親身投入產(chǎn)品建置過程的情況下進行工作，不用等到最后階段才嘗試了解他所要測試的「到底是什么東西」，自然可以避免瞎子摸象的危險。

其次，在 RUP 流程里，測試人員的工作時間并不是集中在最后階段，而是平均分布到整個開發(fā)流程，隨著過程推展而持續(xù)進行測試工作，所以測試人員根本不用擔(dān)心時間被占用而到最后才拼命趕工。

最后，就是深刻影響開發(fā)項目成敗的「風(fēng)險問題」。在 RUP 流程里，我們確定「測試先行」的原則，特意讓可能隱藏的高風(fēng)險在前面階段就先被發(fā)覺，然后以逐步降低的方式分散風(fēng)險，所以不會有傳統(tǒng)瀑布式流程法「風(fēng)險越來越高」的危機。

根據(jù) Standish Group CHAOS 于 1999 年的統(tǒng)計報告，同樣一個問題，當它發(fā)生在前面階段與后面階段時，所需投入的「解決成本」的平均比例大約是 1 比 200 。經(jīng)過上述兩種流程法對測試工作的優(yōu)劣分析之后，相信各位應(yīng)該很清楚要采用哪種流程方法了。 （ZDNET）