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

軟體專案的生命週期，從需求的產生開始，經過系統分析、設計、程式撰寫到後續維護，週而復始。在整個軟體專案的開發過程中，有許多關鍵因素會影響到專案的成效，例如專案的管理、專案進行的流程以及專案品質的管制等。其中會讓需求單位來評斷開發單位的， 則不外乎專案完成的時效以及專案成果的品質。而如何確保各種應用系統的開發，能符合一定水準的標準及安全性，又能具有快速回應的高度效能，是每個資訊開發單位所必須面臨的挑戰。

在軟體工程涵蓋的領域?，深入探討了軟體規格的建立、需求的對應、程式的建構、程式的正確性、規格的達成度，以及如何因應使用者需求的改變、如何切割分工專案、如何管理並準交軟體專案，這之中的過程及要求標準都和「測試」息息相關。

單單只挑出軟體開發過程中所需的測試工作，就可包括單元測試、整合測試、功能測試、回歸測試、壓力測試、效能測試、系統測試、驗收測試、有效性測試、正規分析等等；在圖 1的「開發測試V型關係圖」中，可簡單明瞭的告訴我們各不同的開發階段和幾個主要的測試項目之間的對應關係。

圖 1 開發測試V型關係圖

從V型關係圖中，可以印證現代管理學大師彼得．杜拉克要我們落實的一個觀念，Do the right things & do the things right。因為在任何專案進行的過程中，我們常常要停下來思考的就是，在什麼時候該做什麼事情對我們最有幫助？然後，用什麼方法可以讓我們把事情做到最好？軟體生命週期中的不同階段，都有該執行的測試工作，而且這些測試工作都是有所依循的。整合測試會依據系統分析階段的系統設計規格書及系統分析規格書加以設計進行，而系統測試會依據分析使用者需求的系統需求規格書設計進行。所以當系統分析人員做好相關的規格書時，接續工作的除了程式開發人員，同時應該還有品管測試人員。

但一個在系統上線前，是否都真正通過了那麼多層的考驗？如果沒有進行測試，是本來就沒有規劃執行？還是來不及實施？如果沒有執行測試，如何在系統上線後，評估、規劃管理並控制系統可能產生的風險？如何知道改善系統缺失的方向及目標？

在Barry Boehm博士1981年的著作「軟體工程經濟學」中曾指出，程式的bug數量和除錯所花費的cost 兩者間是成反比的關係；附帶一提，Barry Boehm博士也是第一個指出「軟體支出，是資訊系統的主要成本」的人。在coding的階段，大量的錯誤發生是不可避免的，可是每個開發人員可以很輕易地在編譯的過程，以及藉由工具的幫助，對自己撰寫的程式碼進行修改、除錯。但隨著開發進到程式模組整合以及系統整合等階段，bug被發現的數量會逐漸下降，在這些階段要找bug就像大海撈針，為了找出bug就要花費更高的成本，所以我們一定要有有用、有效率的方法，以降低測試期殘存的bug。

在應用系統的生命週期中，每個階段都或多或少會遇到各種不同的bug。當我們仔細檢視這些日常工作中伴隨著我們的那些不斷發生的問題時，會發現這些問題雖然發生在不同階段，但都是相互關聯的。比如說，如果能在程式開發階段，從程式的撰寫就考慮到邏輯、效能、錯誤處理的完整性，避免使用可能遭致破壞的程式語法，並做好軟體安全的檢查，就不用在系統上線後提心吊膽地擔心系統被攻擊、被入侵。再比如說系統資源分配的問題，如果能在品管測試階段，就預先收集系統執行效能數據、做好完善的分析、建立應用系統效能模型、並進行容量規劃，在系統上線維運時，就能針對需要使用較多資源的部份加以準備，而讓資源不足的狀況能有效避免。

所以早期找出錯誤，並且在軟體生命週期中使用有效率的測試方法排除錯誤，是今日我們提昇軟體專案品質的重要課題。而完整的驗測機制，能提供有規劃的流程以協助我們達成這個目標。測試是軟體開發過程中的一個重要階段，是用來確認程式的品質或效能是否符合開發之前所訂定的需求及規格。我們執行測試的目的，主要是能確認軟體的開發品質，提供系統風險評估的資訊，並進而檢驗、評估專案開發的過程。如果一個系統開發完成之後發現了很多問題，這不僅是說明開發品質不良，也代表開發過程的規劃很可能是有問題的。因此執行測試的目的，也是要確保整個系統開發的流程規劃是否正確。

測試的執行，除了以人工實施，也已經有相當部份可以使用自動化測試工具輔助執行。我們可分別從系統開發的幾個階段，包括程式開發、模組整合、準備上線、使用維運等，分別來討論如何讓自動化測試工具輔助測試工作的進行，並協助驗測機制流程的建立。

程式開發階段的品質控制，是整個系統成敗的根基。在這個階段，我們需以單元測試的執行，來確保品質符合要求。傳統認為單元測試的方法，就是要再額外去開發一些其它程式來對自己的程式進行檢測。但隨著軟體工程科學的進步，自動化單元測試工具已經被廣泛的使用在資訊開發單位。一般的自動化單元測試工具，都提供對程式碼進行靜態分析及動態測試等兩種以上的功能。靜態分析就是直接掃描所有程式碼，可自動的幫助我們執行各種品質檢查，包括：檢查程式內變數的的命名是否依循既定規則，程式是否有發生邏輯操作、記憶體使用、錯誤處理、效能、安全性上等等的錯誤。動態測試則會在程式編譯後執行，透過經過規劃的操作步驟執行程式的功能，讓測試工具分析程式碼是否有可能在不同的執行狀況下發生錯誤；過程中同時將已經測試的程式碼記錄下來，以確保程式測試的涵蓋率。因為是以白箱測試為基礎所發展出來的工具，所以可以讓我們檢測程式的各種記憶體空間分配狀況、程式死結發生的狀況、程式實際執行的效能狀況等。不過，執行了單元測試、使用了自動化工具就是開發品質的保證了嗎？該如何設計驗測機制，如何讓工具的使用及驗測機制整合於整個開發流程中呢？這都是在導入自動化工具後我們要思考的問題。

有了單元測試的品質基礎，我們可在系統整合階段，對整合後的功能模組繼續執行安全性的整合測試。以白箱測試的方法測試程式的安全性有很多好處，檢測的結果可為我們明白指出程式碼中不符合程式撰寫原則的語句，並直接指導我們修改，以避免產生可能遭受包括SQL Injection、Buffer Over-run或跨網站指令碼等模式攻擊的程式碼。

程式的開發都是為滿足實際發生的需求，當系統分析人員依照需求訂出系統規格後，整個開發的過程就是為了達成這個目標。但為系統品質把關的測試工作要做到的不只是如此，測試工作除了要驗證系統功能能滿足客戶的需求、系統的規格，更要能在系統未上線前，驗證系統不會發生意外的、不正常的錯誤，以讓我們可對系統潛存的風險進行管理。所以，在系統整合階段還有一個重要的測試工作項目，就是功能測試。理論上，程式開發人員不會交出功能不正確的程式單元；理論上，各單元組成的模組功能也會是正確的。但我們仍然需選擇以等價分析、邊界值分析、因果律圖解或錯誤揣測等方法，對系統執行功能測試，驗證各項輸入、輸出所得的正確性。執行功能測試不可避免的要以多種不同的輸入帶入相同的一組操作步驟，以驗證系統的反應。這之中的重覆操作部份就可倚賴自動化測試工具來達成。由於不斷變更的需求將導致應用程式不斷地產生不同的版本，每一個版本都需要再執行重覆的測試工作，因?每一個被改寫或增加的內容往往是最容易隱含錯誤的，所以這樣的功能迴歸測試是測試中最重要的階段，而迴歸測試透過人工方式很難確實執行，工具在這方面可以大大的增加測試的效率，提高測試的精確度。

而在系統上線前，可針對應用系統的軟、硬體效能進行壓力測試，幫助開發團隊了解應用系統面對壓力時的各項資源的運作，系統能夠負荷多少同時使用者進行操作，和系統在大量同時使用者上線時的回應時間等等。一旦測試執行完畢後，如果測試的結果不能滿足未來系統上線後的要求，接下來要面對的問題就是如何改善。一般而言，壓力測試後都一定會有系統效能的問題必須改善。因此效能分析與調校的工作是一定少不了的。為了使測試後發現的缺失能快速的改善，尚需規劃一個效能分析、調校及容量規劃的機制，以協助系統開發團隊快速地找到問題的所在並加以解決。

在系統開發過程中，輔以自動化測試工具的使用，可大幅提升程式開發的品質，並可明顯降低整個開發週期的成本。