完善的驗測機制焠煉出高品質的應用系統

可分別從系統開發的幾個階段，包括程式開發、模組整合、準備上線、使用維運等，來討論如何藉由自動化測試工具輔助測試工作的進行，並協助驗測機制流程的建立。

首頁 叡揚e論壇 EIS43 完善的驗測機制　焠煉出高品質的應用系統 論壇文章完善的驗測機制　焠煉出高品質的應用系統 下一篇-服務水平管理專家─Vantage 提昇軟體開發品質 節省開發週期成本 軟體專案的生命週期，從需求的產生開始，經過系統分析、設計、程式撰寫到後續維護，週而復始。

在整個軟體專案開發過程中，又有許多關鍵因素會影響專案的成敗，例如專案的管理、進行的流程及品質管制等，其中又以專案完成的準交率及成果品質最容易招人詬病。

因此，如何確保各種應用系統的開發，能符合一定水準的標準與安全性，同時又具有快速回應的高度效能，便成為每個資訊開發單位必須面臨的挑戰。

在軟體工程所涵蓋的領域裏，包括了軟體規格的建立、需求的對應、程式的建構、程式的正確性、規格的達成度，以及如何因應使用者需求的改變、如何切割分工專案、如何管理並準交軟體專案，這當中的過程及要求標準都與「驗測機制」息息相關。

驗測機制做得好 軟體開發沒煩惱 試就僅以軟體開發過程中所需的測試工作舉例，就包括單元測試、整合測試、功能測試、迴歸測試、壓力測試、效能測試、系統測試、驗收測試、有效性測試、正規分析等等；在圖1的「開發測試V型關係圖」中，簡單明瞭的呈現出在各不同的開發階段和幾個主要的測試項目之間的對應關係。

從V型關係圖中，可以印證現代管理學大師彼得．杜拉克一個重要的觀念，『Dotherightthings&dothethingsright。

』因為任何專案在進行的過程中，尤其是在軟體生命週期的不同階段，都有其該執行的測試工作，而這些測試工作都必須是有所依循的。

例如，整合測試必須依據系統分析階段的系統設計規格書及系統分析規格書加以設計並進行；而系統測試則是依據分析使用者需求的系統需求規格書設計進行。

因此，當系統分析人員做好相關規格書時，承接後續工作的人員除了程式開發人員，同時應該還有品管測試人員。

但一個系統在上線前，是否都確實通過了這麼多層的考驗？實難以驗證。

倘若系統沒有進行測試，是專案團隊本來就沒有列入規劃並執行？還是因某些原因而來不及實施？如果系統沒有執行測試，又如何在系統上線後，評估、規劃管理並控制系統可能產生的風險？如何知道改善系統缺失的方向及目標？上述問題都值得專案團隊深思。

BarryBoehm博士是第一個提出『軟體支出，是資訊系統的主要成本』的人，在其1981年的著作「軟體工程經濟學」中亦曾明白指出，程式的bug數量和除錯所花費的成本兩者間是成反比的關係（如附圖2所示）。

在coding的階段，大量的錯誤發生是不可避免的，可是每個開發人員可以很輕易地在編譯的過程，以及藉由工具的幫助，對自己撰寫的程式碼進行修改、除錯。

但隨著開發進行到程式模組整合及系統整合等階段，bug被發現的數量會逐漸下降，在這些階段要找到bug如同大海撈針，程式人員為此必須花費更高的成本與代價，也就更需一套有用、高效率的驗測機制從旁協助，以降低軟體於測試期殘存的bug。

在應用系統的生命週期中，每個階段都或多或少會遇到各種不同的bug，然而這些問題或狀況彼此之間卻是相互關聯的。

試以程式開發階段為例，程式人員若能在一開始撰寫程式時就考慮到邏輯、效能、錯誤處理的完整性，並儘可能的避免使用會遭致破壞的程式語法，做好軟體安全的檢查，日後系統在上線後就無須擔心系統被攻擊或遭駭客入侵；又試以系統資源分配的問題為例，程式人員若能在品管測試階段，就預先收集系統執行效能數據，同時做好完善的分析、建立應用系統效能模型、進行容量規劃，日後系統在上線維運時，就能針對需要使用較多資源的部份加以準備，並能有效避免資源不足的狀況發生。

『預防勝於治療』早期找出錯誤，並在軟體生命週期中使用有效率的測試方法排除錯誤，是今日提昇軟體專案品質的重要課題。

而完整的驗測機制，能提供系統性的流程以協助程式人員達成此一目標。

測試是軟體開發過程中的一個重要階段，用以確認程式的品質或效能是否符合開發之前所訂定的需求及規格，而執行測試的目的，是協助程式人員能確認軟體開發的品質，提供系統風險評估的資訊，進而檢驗、評估專案開發的過程。

如果一個系統開發完成後才發現許多問題，這不僅是說明軟體開發的品質不良，也代表開發時的過程規劃有瑕疵。

因此，軟體進行測試的目的，正是為確保系統開發的流程與規劃都正確，讓系統發揮其應有之功用與效能。

測試的執行，除施以人工方式外，也已有相當部份可使用自動化測試工具輔助執行。

可分別從系統開發的幾個階段，包括程式開發、模組整合、準備上線、使用維運等，來討論如何藉由自動化測試工具輔助測試工作的進行，並協助驗測機制流程的建立。

系統成敗的關鍵─開發階段的品質控制 程式開發階段的品質控制，是整個系統成敗的關鍵。

在此階段，我們需以單元測試的執行，來確保品質符合要求。

傳統認為單元測試的方法，是要再額外開發一些其它程式來對原有的程式進行檢測。

但隨著軟體工程科學的進步，自動化單元測試工具在資訊開發單位已被廣泛的使用。

一般而言，自動化單元測試工具均提供對程式碼進行靜態分析及動態測試等兩種以上的功能。

靜態分析亦即直接掃描所有程式碼，可自動幫助程式人員執行各種品質檢查，包括程式內變數的命名是否依循既定規則、程式是否有發生邏輯操作、記憶體使用、錯誤處理、效能、安全性…等的錯誤。

動態測試則是在程式編譯後執行，透過規劃的操作步驟執行程式的功能，讓測試工具分析程式碼是否有可能在不同的執行狀況下發生錯誤，在檢測過程中同時將已測試的程式碼完整記錄下來，確保程式測試的涵蓋率。

由於自動化單元測試工具是以白箱測試為基礎所發展出來的，因此，可以提供程式人員檢測程式的各種記憶體空間分配狀況、死結發生的狀況、實際執行的效能狀況等。

不過，執行完單元測試、使用了自動化工具就等於是完成程式開發品質的保證了嗎？該如何設計驗測機制，讓工具的使用及驗測機制整合於整個開發流程中？上述問題都是程式人員在導入自動化驗測工具後所要思考的問題。

有了單元測試的品質基礎，程式人員可在系統整合階段，對整合後的功能模組繼續進行安全性整合測試。

以白箱測試的方法來測試程式的安全性有很多好處，而檢測的結果不但能明白指出程式碼中不符合程式撰寫原則的語句，並可直接指導程式人員加以修改，避免產生可能遭受包括SQLInjection、BufferOver-run或跨網站指令碼等模式攻擊的程式碼。

做好系統潛藏風險管理 功能迴歸測試不可少 程式都是為滿足業務上實際產生的需求而開發的，因此，當系統人員依照需求訂出系統規格後，整個開發的過程就算是大功告成了。

然而，實際上為系統品質把關的測試工作要做的還不只如此，測試工作除了要驗證系統功能能確實滿足系統的規格、業務的需求外，更要能在系統未上線前，保證驗證系統絕不會有意外或不正常的錯誤發生，讓程式人員可對系統潛藏的風險進行管理。

也因此，在系統整合階段中還有一個重要的測試工作項目，就是功能迴歸測試。

理論上，程式開發人員是絕不可能交出功能不正確的程式單元，且各單元間組成的模組功能也都會是正確無誤的。

但是，程式開發人員仍需選擇以等價分析、邊界值分析、因果律圖解或錯誤揣測等方法，對系統進行功能測試，以驗證各項輸入或輸出所得的正確性。

由於不斷變更的需求將導致應用程式不斷地產生新版本，加上每個被改寫或增加的內容往往最容易產生隱含的錯誤，而每個版本都需要進行重覆的測試工作，這樣的功能迴歸測試很難藉由人工方式確實執行，此時就可倚賴自動化測試工具完成，不但可大幅的增加測試的效率，更可提高測試的精確度。

系統上線在前，可針對應用系統的軟、硬體效能進行壓力測試，如此可協助開發團隊更了解應用系統在面對壓力時各項資源的運作情形、在同一時間內系統究竟能負荷多少名使用者操作，及系統在大量使用者同時上線時的回應時間等等。

一旦測試工作執行完畢，如果測試結果無法滿足系統在未來上線後的要求，那麼接下來程式人員就會面對「如何改善」的問題了。

為了使測試後發現的缺失能快速獲得改善，系統需要妥善的效能分析、調校及容量規劃的機制，幫助開發團隊迅速找到問題發生點並加以解決。

結論 在系統開發過程中，隨著應用系統的複雜化，會遭遇軟體品質是否能夠達到實際的功能要求、回應時間是否能夠達到預期的標準、資料庫能夠支援多少用戶端的登入，及資料庫伺服器的硬體配置是否達到要求等問題。

叡揚資訊多年來致力於軟體開發的測試、調適及流程改善等相關領域工作，所代理的“QACenter”更是一套專門為開放系統程式及應用系統測試的輔助工具，我們並從自身經驗及廣泛的關鍵性應用系統案例實作中，累積大量的知識經驗庫，遂發展出多種規劃需求解決方案的模型；在可預見的未來，透過自動化測試工具的使用，除大幅提昇程式人員軟體開發的品質，並協助企業節省整個軟體開發週期的成本，以焠煉出高品質的應用系統。

完善的驗測機制　焠煉出高品質的應用系統 目錄 封面故事 20歲的叡揚-期待　 內頁 下一場生產力競賽─知識競賽 WirelessMeshNetwork　無線網狀網路　 漫談從ITIL到BSM　 開放軟體的社會動力學　 學習型組織與組織績效之關係　 無形資產於知識經濟時代─價值篇（下）　 臺北市政府單一申訴服務系統　 日盛金控共享旗下子公司資源　延伸集團核心競爭力 有了DevPartnerStudio　華寶通訊對開發軟體有信心 知識管理─一場意識革命　胡佳文EC-Council知識管理講師 完善的驗測機制　焠煉出高品質的應用系統 服務水平管理專家─Vantage 「好東西和大家分享！」就是知識管理 DevPartnerJava實務技術探討─效能分析篇