http://www.dsc.com.tw/newspaper/43/43-3.htm

邁向軟體品質之路－談軟體開發過程與軟體測試

第三事業群研發工程師 王舜民

　　軟體品質在過去幾年，一直是被國內軟體業所忽略的一環，因為過去為了搶占國內市場，各廠商皆將心力放在軟體的功能及價格上面，對於品質的要求也就力有未逮了。而近一兩年來，由於與國外廠商的競爭壓力及消費者的品質意識抬頭，使得軟體品質的觀念也逐漸受到大家的重視。然而，軟體品質這條路要怎麼走呢？讓我們先瞭解一下軟體公司所面臨的軟體危機（Software Crisis）。

軟體危機
　　軟體危機是指在軟體開發及維護的過程中所面臨的嚴重問題，這些問題皆可能導致軟體產品的壽命縮短、甚至夭折，常見的問題如下：

1. 專案的時程估計錯誤，專案不斷地延遲、進度不如預期
2. 開發好的系統問題（Bug） 一堆，抓不甚抓
3. 修改一個問題產生另外兩個問題，新功能加愈多，新的問題就愈多
4. 沒有系統分析與設計的文件
5. 軟體的生產力低，投入的時間與產能不成比例
6. 程式版本混亂，沒有控管

　　會造成上述問題，主要是因為軟體開發及維護的進行沒有「方法」。沒有方法的開發模式就是，開發時沒有制訂的開發過程，分析和設計不是被忽略就是時間被壓縮，大部份的時間都在寫程式，但不會要求程式設計師寫程式時要寫註解，而測試的工作和分析設計一樣，不是被忽略就是時間被壓縮。
　　如此開發系統，系統很快就完成了，但後來維護所花的時間及成本卻是開發時的好幾倍，但很少有公司會去估算一個系統完成後，又花了多少成本與時間去把它調整成「真正完成」的系統，所以這些問題就這樣在每個軟體專案中不斷地出現。

軟體工程
　　為了要克服軟體危機，於是有了軟體工程（Software Engineering）的出現，其目的是希望能透過工程化的方式來開發出功能與品質兼具的軟體。軟體工程所涵括的範圍很廣，包括軟體開發過程（Software Development Process）、軟體型態管理（Software Configuration Management）、軟體專案管理（Software Project Management）等主題。本文針對其中最關鍵的主題－軟體開發過程及軟體開發過程中的測試活動做更深入的探討。

軟體開發過程
　　軟體開發過程是軟體工程中最重要的一環，因為它定義了進行軟體開發時所會經歷的階段活動及產出（artifact）。因此，落實軟體工程的第一步，就是制訂出合用的軟體開發過程。現今已有許多方法論闡揚各自的軟體開發過程，主要可以分成傳統的瀑布式開發過程（Waterfall Development Process）及往覆式開發過程（Iterative Development Process）。

瀑布式開發過程
　　 瀑布式開發過程在過去是最普遍的開發形式，主要分成需求、分析、設計、實作、測試（包括整合測試及系統測試）等階段（如圖1），階段間都是線性前進的，也就是在系統全部的需求分析完後再進行設計，全部的功能設計好後再進行實作，各子系統實作完再進行測試，屬於先廣後深的開發方式。

　　此種開發過程的缺點在於開發較大型的系統時，失敗風險較高。因為它在分析及設計階段是進行整個系統的分析設計，當對象是大型系統時，便得花掉非常多的時間進行分析與設計，而且許多分析上或設計上的問題，往往要到了整合測試階段、系統測試階段，甚至是交給客戶手上時才會發現。而發生問題後，則必須再重覆整個開發過程以進行修改，此時修改的困難度與成本都會比第一次開發時還要高。所以，如果能讓早期發現分析和設計上的問題，那就能有效地降低軟體開發失敗的風險，接下來要介紹的往覆式開發過程便具備這樣的優點。

往覆式開發過程
　　往覆式開發過程是近幾年隨著物件導向分析設計的發展所產生的一種開發過程，其彌補了瀑布式開發過程的一些缺陷。往覆式開發過程概念如圖2所示，專案開始時，將整個系統的開發週期切分成一個一個的循環週期（Iteration），而每個循環週期皆進行一次小型瀑布式開發過程，第一個循環週期完成後再進行第二個循環週期，依次類推下去直到所有的循環週期完成後，專案也就完成了。

圖2. 往覆式軟體開發過程

　　相較於傳統瀑布式開發過程採用分析全部、設計全部、實作全部、測試全部的「先廣後深」策略，往覆式開發過程則採用分析一點點、設計一點點、實作一點點、測試一點點的「先深後廣」策略。先深後廣的好處是我們可以在前幾個循環週期開發時，把整個系統架構實作出來，以驗証架構設計的可行性，所以能將技術風險轉移到開發初期，提早發現架構上的問題。

　　每個循環週期皆進行一次改良型瀑布式開發過程，改良型瀑布式開發過程和傳統瀑布式開發過程的差異在於測試階段活動是支援開發過程所有的階段活動。以往測試只著重在實作階段，但事實上許多問題都是在需求、分析、設計等階段就發生了，所以各階段的產出皆應進行測試。

　　一個循環週期是多久的時間呢？又如何將整個系統切分成多個循環週期呢？一個循環週期大多會訂在一個月到二個月之間，太短可能來不及進行一個瀑布式開發過程，太長又會失去往覆式開發的好處，所以一到二個月間最合適。至於如何將整個系統切分成多個循環週期？這和開發時所採用的開發方法有密切的關係。

　　如果採用物件導向分析與設計的開發方法，一般會以使用案例（Use-Case）為單位做切分，一個循環週期可能是一到數個使用案例，數量多寡要視一個循環週期的時間長短而定。此外，由於使用案例也具備先深後廣的特性，所以每個使用案例在分析、設計及實作時都能將整個系統架構走過一遍，可以讓我們早日將系統架構確認下來。所以，物件導向分析與設計的開發方法與往覆式開發過程搭配，通常是有加乘的效果。

　　如果採用傳統分析與設計的開發方法，可以考慮以子系統為單位做切分，不過要以子系統為單位做切分的前題是，整個系統必須已經切割出多個子系統了，所以這地方可能會有一些矛盾的地方，因為傳統的分析與設計如果沒有把整個系統的分析設計做完，實在很難切割出子系統，除非過去已有類似系統的開發經驗。

　　傳統分析與設計的開發方法和往覆式開發過程在搭配上會有一點問題。我的建議是，試著採用物件導向分析與設計的開發方法，如果仍必須採用傳統的分析設計方式，那可試著在系統分析完成之後，做概略的系統設計將子系統先切割出來作為循環週期的單位，這是一個折衷的方法。

結論
　　瀑布式開發過程是以往較常採用的方式，但經驗告訴我們，這種方式對於中、大型的系統專案而言，風險仍相當地高。而往覆式開發模式能避免掉瀑布式開發過程的缺點，並有效降低風險，所以現今主流的軟體開發方法論幾乎都是以往覆式開發模式為基礎來發展的。

　　不論是哪種軟體開發過程都有其優缺點，也沒有一個軟體開發過程是適合所有軟體公司的，所以不要為了不知道要選擇哪種開發過程而躊?不前，先制訂一個軟體開發過程並依循它，慢慢地就會演化出合適的軟體開發過程了。

軟體測試
　　軟體測試（Software Testing）只是軟體開發過程中的一個階段活動，特別把軟體測試當作一個主題是因為它與軟體品質有相當密切的關係。

不再只有實作後才做測試
　　新的軟體測試概念不再只是實作後的測試了，大家較熟悉的單元測試、整合測試、功能測試、效能測試及壓力測試都是實作後所要進行的測試，那分析結果不需要測試有沒有與需求相符嗎？設計結果不需要測試有沒有與分析結果相符嗎？所以在物件導向世界裡，有一個名為Full Lifecycle Object-Oriented Testing（簡稱FLOOT）的測試方法論，主張測試應該要支援開發過程的所有活動。

　　如圖3所示，需求、分析、設計階段皆有相對應的測試活動，每個測試活動裡都定義一些不同測試目的的測試方法。如程式碼測試（Coding Testing）就包括單元測試（Unit Testing）、整合測試（Integration Testing）、程式碼審核（Code Review）等測試方法。測試要能支援開發過程的所有階段活動，才能確保每個階段產出的正確性及一致性，早期發現各個階段產出的問題，而不會通通等到實作出系統後才發現系統好像與需求不符的或發現一堆分析設計上的問題。

　　這裡所要傳達的一個觀念是 － 測試不再只是寫程式碼後才做的事了。光是在寫程式碼後才做測試是不夠的，唯有在軟體開發的每個環節都有考慮到測試，軟體的品質才能大幅的提昇。

設計時要考慮到測試
　　雖說測試應該要落實在軟體開發過程中的每個階段活動上，但對於本來就沒有確實在做軟體測試的軟體公司而言，這簡直是天方夜譚！所以要落實測試，比較實際的作法是先把實作後（即寫出程式碼後）的測試工作做好，因為實作後的測試是品質的最後一道防線，所以至少要做好這部份的測試工作。
　　實作後的測試包括單元測試、整合測試、功能測試、效能測試、壓力測試、使用者測試等，其中單元測試、整合測試及功能測試是最基本也最重要的三種測試，三種測試簡單定義如下：

‧單元測試，測試程式碼單元本身是否依據其所設想的方式執行及執行結果是否合乎預期的結果。單元測試通常是由程式設計師自己進行測試。
‧整合測試，測試各程式碼單元間能否相互合作完成某種功能。整合測試可以由程式設計師或軟體品保工程師進行。
‧功能測試，測試系統是否能待合預期的功能需求。功能測試通常由軟體品保工程師進行。

　　在進行系統設計時，應該要把測試的需求考量進去，如此，將來在進行上述三種測試時才不會勞心又勞力。舉例來說，我們在設計類別時，可以採用五層式的類別架構設計（如圖4），那麼將來會比較容易進行測試的工作，怎麼說呢？先簡單地說明一下五層式類別架構的概念。

五層式類別架構是將類別由內而外分成下列五種層次： Persistence Layer 一些負責存取儲存體（如資料庫、檔案）的類別。 System Layer 一些工具類別或與負責網路存取、與作業系統溝通等類別。 Domain Layer 此層的類別稱為領域類別，代表系統的領域概念及資料實體。 Controller Layer 此層的類別稱為控制者類別，實作企業邏輯以協調領域類別間的互動。 User Interface Layer 此層的類別稱為使用者介面類別，負責呈現介面與使用者進行互動。 　　如圖4所示，層次間的箭頭代表著單向的相依關係，如User Interface Layer相依於Controller Layer，Controller Layer相依於Domain Layer及Persistence Layer。如此分層的好處在於能減少類別變動所造成的影響，如Domain Layer若有變動，所影響的範圍僅限於Controller Layer，若Persistence Layer有變動，所影響的範圍也僅限於Domain Layer及Controller Layer，所以分層架構提供相當好的設計彈性。

圖4. 五層式的類別架構圖

　　類別分層架構的設計在測試上又有什麼好處呢？一般來說實作時我們會先從較底層的類別開始，如System Layer，在System Layer類別撰寫完並完成單元測試後，我們寫Persistence Layer，Persistence Layer 完成後會進行單元測試，此時對Persistence Layer而言雖然是單元測試，但因為Persistence Layer有用到System Layer的類別，所以對System Layer而言是在進行整合測試；同樣地Domain Layer的單元測試會是對Persistence Layer及System Layer的整合測試，依此類推，整個類別層次的測試關係如圖5所示。

圖5. 五層式類別架構的測試關係圖

　　 所以，我們不會把所有層次的類別都寫完才進行整合及測試，在開發過的過程中就進行整合了，當某一層次所有類別的單元測試結束也就代表已完成該層次以下類別的整合測試。那User Interface Layer的整合測試呢？在User Interface Layer完成單元測試後，接下來就要進行系統的功能測試了，而功能測試也就是User Interface Layer的整合測試了。所以，如果設計時能將測試考慮進來，將來會比較容易進行測試工作。

結論
　　軟體測試是軟體品質保証的一種方法，也是軟體品質的最後一道防線，如果能落實軟體測試，軟體品質便能控制在一定的水準之上。而進行系統設計時，若能考量到測試的需要，將來進行實作後測試的工作時，才能事半功倍。

總結
　　近一兩年，CMM（能力成熟度評量）認証熱已經燒到亞洲來了，中國大陸也十分積極地朝取得CMM認証做努力，而國內也開始有軟體公司計劃去取得CMM認証，這是件好事，代表國內軟體產業也開始把關愛的眼神放在軟體的品質上了。

　　其實，有沒有取得CMM認証並不是那麼地重要，重要的是軟體公司本身有沒有真的落實軟體工的每一環節？有沒有制訂軟體開發過程並依循之？有沒有落實軟體測試？有沒有做好軟體型態管理？有沒有做好專案管理？如果這些都有做到，將來要取得CMM認証並非難事。

邁向軟體品質之路，過程也許崎嶇難行，但路的盡頭卻將會是一條康莊大道。