解決軟件測(cè)試的三大棘手問題

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

許多人談到測(cè)試，總是有滿腹牢騷，因?yàn)樗坪跏且患钢仔须y」的麻煩工作。為何測(cè)試總是做不好？大致可歸類成下述三大原因。

測(cè)試排最后

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

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

時(shí)間不夠

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

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

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

風(fēng)險(xiǎn)太高

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

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

解決之道：采用 RUP 流程

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

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

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

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

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

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

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

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