對這文章發表回應
發表限制: 非會員 可以發表
http://www.dsc.com.tw/newspaper/43/43-3.htm 邁向軟體品質之路-談軟體開發過程與軟體測試 第三事業群研發工程師 王舜民 | ||
軟體品質在過去幾年,一直是被國內軟體業所忽略的一環,因為過去為了搶占國內市場,各廠商皆將心力放在軟體的功能及價格上面,對於品質的要求也就力有未逮了。而近一兩年來,由於與國外廠商的競爭壓力及消費者的品質意識抬頭,使得軟體品質的觀念也逐漸受到大家的重視。然而,軟體品質這條路要怎麼走呢?讓我們先瞭解一下軟體公司所面臨的軟體危機(Software Crisis)。 軟體危機 1. 專案的時程估計錯誤,專案不斷地延遲、進度不如預期 會造成上述問題,主要是因為軟體開發及維護的進行沒有「方法」。沒有方法的開發模式就是,開發時沒有制訂的開發過程,分析和設計不是被忽略就是時間被壓縮,大部份的時間都在寫程式,但不會要求程式設計師寫程式時要寫註解,而測試的工作和分析設計一樣,不是被忽略就是時間被壓縮。 軟體工程 軟體開發過程 瀑布式開發過程 此種開發過程的缺點在於開發較大型的系統時,失敗風險較高。因為它在分析及設計階段是進行整個系統的分析設計,當對象是大型系統時,便得花掉非常多的時間進行分析與設計,而且許多分析上或設計上的問題,往往要到了整合測試階段、系統測試階段,甚至是交給客戶手上時才會發現。而發生問題後,則必須再重覆整個開發過程以進行修改,此時修改的困難度與成本都會比第一次開發時還要高。所以,如果能讓早期發現分析和設計上的問題,那就能有效地降低軟體開發失敗的風險,接下來要介紹的往覆式開發過程便具備這樣的優點。 往覆式開發過程
相較於傳統瀑布式開發過程採用分析全部、設計全部、實作全部、測試全部的「先廣後深」策略,往覆式開發過程則採用分析一點點、設計一點點、實作一點點、測試一點點的「先深後廣」策略。先深後廣的好處是我們可以在前幾個循環週期開發時,把整個系統架構實作出來,以驗証架構設計的可行性,所以能將技術風險轉移到開發初期,提早發現架構上的問題。 每個循環週期皆進行一次改良型瀑布式開發過程,改良型瀑布式開發過程和傳統瀑布式開發過程的差異在於測試階段活動是支援開發過程所有的階段活動。以往測試只著重在實作階段,但事實上許多問題都是在需求、分析、設計等階段就發生了,所以各階段的產出皆應進行測試。 一個循環週期是多久的時間呢?又如何將整個系統切分成多個循環週期呢?一個循環週期大多會訂在一個月到二個月之間,太短可能來不及進行一個瀑布式開發過程,太長又會失去往覆式開發的好處,所以一到二個月間最合適。至於如何將整個系統切分成多個循環週期?這和開發時所採用的開發方法有密切的關係。 如果採用物件導向分析與設計的開發方法,一般會以使用案例(Use-Case)為單位做切分,一個循環週期可能是一到數個使用案例,數量多寡要視一個循環週期的時間長短而定。此外,由於使用案例也具備先深後廣的特性,所以每個使用案例在分析、設計及實作時都能將整個系統架構走過一遍,可以讓我們早日將系統架構確認下來。所以,物件導向分析與設計的開發方法與往覆式開發過程搭配,通常是有加乘的效果。 如果採用傳統分析與設計的開發方法,可以考慮以子系統為單位做切分,不過要以子系統為單位做切分的前題是,整個系統必須已經切割出多個子系統了,所以這地方可能會有一些矛盾的地方,因為傳統的分析與設計如果沒有把整個系統的分析設計做完,實在很難切割出子系統,除非過去已有類似系統的開發經驗。 傳統分析與設計的開發方法和往覆式開發過程在搭配上會有一點問題。我的建議是,試著採用物件導向分析與設計的開發方法,如果仍必須採用傳統的分析設計方式,那可試著在系統分析完成之後,做概略的系統設計將子系統先切割出來作為循環週期的單位,這是一個折衷的方法。 結論 不論是哪種軟體開發過程都有其優缺點,也沒有一個軟體開發過程是適合所有軟體公司的,所以不要為了不知道要選擇哪種開發過程而躊?不前,先制訂一個軟體開發過程並依循它,慢慢地就會演化出合適的軟體開發過程了。 軟體測試 不再只有實作後才做測試 如圖3所示,需求、分析、設計階段皆有相對應的測試活動,每個測試活動裡都定義一些不同測試目的的測試方法。如程式碼測試(Coding Testing)就包括單元測試(Unit Testing)、整合測試(Integration Testing)、程式碼審核(Code Review)等測試方法。測試要能支援開發過程的所有階段活動,才能確保每個階段產出的正確性及一致性,早期發現各個階段產出的問題,而不會通通等到實作出系統後才發現系統好像與需求不符的或發現一堆分析設計上的問題。 這裡所要傳達的一個觀念是 - 測試不再只是寫程式碼後才做的事了。光是在寫程式碼後才做測試是不夠的,唯有在軟體開發的每個環節都有考慮到測試,軟體的品質才能大幅的提昇。 設計時要考慮到測試 ‧單元測試,測試程式碼單元本身是否依據其所設想的方式執行及執行結果是否合乎預期的結果。單元測試通常是由程式設計師自己進行測試。 在進行系統設計時,應該要把測試的需求考量進去,如此,將來在進行上述三種測試時才不會勞心又勞力。舉例來說,我們在設計類別時,可以採用五層式的類別架構設計(如圖4),那麼將來會比較容易進行測試的工作,怎麼說呢?先簡單地說明一下五層式類別架構的概念。
類別分層架構的設計在測試上又有什麼好處呢?一般來說實作時我們會先從較底層的類別開始,如System Layer,在System Layer類別撰寫完並完成單元測試後,我們寫Persistence Layer,Persistence Layer 完成後會進行單元測試,此時對Persistence Layer而言雖然是單元測試,但因為Persistence Layer有用到System Layer的類別,所以對System Layer而言是在進行整合測試;同樣地Domain Layer的單元測試會是對Persistence Layer及System Layer的整合測試,依此類推,整個類別層次的測試關係如圖5所示。
所以,我們不會把所有層次的類別都寫完才進行整合及測試,在開發過的過程中就進行整合了,當某一層次所有類別的單元測試結束也就代表已完成該層次以下類別的整合測試。那User Interface Layer的整合測試呢?在User Interface Layer完成單元測試後,接下來就要進行系統的功能測試了,而功能測試也就是User Interface Layer的整合測試了。所以,如果設計時能將測試考慮進來,將來會比較容易進行測試工作。 結論 總結 其實,有沒有取得CMM認証並不是那麼地重要,重要的是軟體公司本身有沒有真的落實軟體工的每一環節?有沒有制訂軟體開發過程並依循之?有沒有落實軟體測試?有沒有做好軟體型態管理?有沒有做好專案管理?如果這些都有做到,將來要取得CMM認証並非難事。 邁向軟體品質之路,過程也許崎嶇難行,但路的盡頭卻將會是一條康莊大道。 |