用 Rational 質量檢驗關方法提高軟體質量並降低成本

轉自：http://www.ibm.com/developerworks/cn/rational/09/qualitygates/index.html

今天的軟體開發團隊，正糾結在維護和修改軟體的開發成本正不斷飆升的煩惱之中。他們面臨這樣一種挑戰：一方面要向商業客戶交付高質量、高可靠性的軟體產品，一方面卻要降低總體成本來開發和維護所應交付的軟體應用程式。在有些機構中，這已經成了 IT 壓力的重要來源之一，並使低質量成為了返工問題中的核心問題。

IBM® Rational® 質量檢驗關方法（quality gates）可以幫助我們作為開發人員，來理解並控制我們所採用的軟體開發生命週期方法。隱藏在質量檢驗關背後的思想是，在軟體生命週期中轉向下一個階段或者子階段時，我們需要看到這麼做的訊號。作為一個專案從一個階段轉向另一個階段時的檢查點，它們可以幫助我們提高軟體的質量，因為它們可以確保我們正在執行的是最佳實踐，而且與前期的結果相比較。詳細檢查的層次可以幫助我們分清開發中的重要事件，因此可以更早地解決質量問題。更早地發現問題，意味著它們解決起來成本更低，從而 IT 運作的總體成本也會降下來。

因此，實施質量檢驗關可以增加軟體的質量，降低總體的成本。在軟體開發的實踐活動中，這種方案得到越來越廣泛的應用。

基本原理（Rationale）

如果我告訴您，上週我繞著小鎮逛了一圈，結果耗油量是 25 MPG （加侖/英里），您說這是好還是壞呢？沒有一個基準，這可能很難回答。但是，如果我告訴您再上一週同樣這樣做的耗油量是 18 到 22 MPG。那現在您是否對上週我為何增加耗油量感到很好奇了呢？採取汽車保養最佳實踐所產生的效應，例如更換機油或檢查輪胎的氣壓，並不能用於準確地評價質量，除非我們確實找到了度量質量好壞的手段。

軟體開發與此並沒有什麼不同之處。如果沒有定量評價及記錄結果的手段，是很難理解一項變更對軟體開發是有積極影響，還是消極影響。您要怎樣做，才能知道您上週向開發人員提供的培訓課程能否帶來好處？與機構內部開發的程式碼質量相比，您怎樣才能知道外包專案質量的好壞？答案在於您是怎樣建立評價方法的，以及從質量檢驗關收集到的度量資料。通過這種方式，您可以看到由於縮短最後期限日期對質量所帶來的影響；根據是否滿足既定的評價標準，您可以決定是否值得將專案繼續進行下去。

一般來說，公司都會有一個處在構建階段以及交付階段之間的質量檢驗關：測試階段。在向客戶部署最後的產品之前，公司會進行測試以得到最後的交付許可。這對在部署之前測試機構記錄每一項缺陷構成了極大的壓力，這是不現實的。公司不能只依賴於一次最終的測試或者質量檢驗關，來確定整體的軟體質量。公司需要更加靈活，這樣在深入到開發階段之前，他們就會考慮一下軟體質量問題了。

檢查點及最佳實踐

在軟體生命週期的早期階段，關注其質量問題能夠顯著地提高質量及降低成本，而 Rational 質量檢驗關提供了開發階段的檢查點。簡單地部署最佳實踐，並不夠好。您必須部署評價方法、基準以及重新評價標準，以幫助您確定軟體需要能夠跟得上軟體需求。如果您的專案投資人不能理解，怎樣在決策制定過程中使用最佳的操作手段以及好的過程，那麼僅僅擁有它們就並不足夠。執行者在評價最佳實踐時總是會低估它們。在我的軟體開發生涯的早期，我的管理團隊要求我確保所有的程式碼擁有一個主要的作者，以及與其相聯絡的二級人員，以評審 —一般叫做同等程式碼評審的評審。在同等程式碼評審中，二級人員對評審和評價主要作者的工作負責。同等程式碼評審持續有大約一週的時間（與缺乏任何實際的執行相結合），這種“最佳實踐”會被丟棄掉。

軟體開發由一系列的階段組成。這些階段對於所有形式的操作都是相同的，包括瀑布過程、Rational 統一過程（Rational Unifies Process，RUP）、OpenUp 以及所有敏捷方法。在每一個階段中，都有一個需求階段、設計/編碼階段、構建階段、測試階段以及釋出階段。更重要的是，所有的階段都有與之相聯絡的質量檢驗關，因為您可以為每一個階段使用多個質量檢驗關。例如，在測試階段的中期，您可能想要一個評審質量檢驗關，以在執行任何測試之前自動化測試指令碼框架認證過程。在軟體生命週期的早期階段建立這種質量檢驗關，可以幫助您更早地發現缺陷，這樣就可以花費更少的成本來修復它。在大多數情況下，在需求評審中找到一個需求問題，要比等到程式設計好、編碼好，構建好以及測試好之後再找到，成本要低得多。

需求階段

第一個階段是需求階段。大多數的軟體開發生命週期的最佳實踐，是追蹤與測試用例相關的需求。這可以幫助您理解您的需求，而且在您執行軟體時它能提供更好的使用者經驗。通過識別和跳躍性地開始測試過程，書寫測試用例可以向您提供很大的幫組。這種最佳的操作允許您基於測試用例的複雜性、風險以及功能性區域來安排它們的優先順序，來建立關於測試將要持續多久的質量估計。它還能尋找測試中的再使用過程，並開始構建一個測試框架。

這就是使用像 IBM® Rational® Quality Manager 工具這樣方案的地方，以獲取測試用例，幫助滿足質量目標。為了實現這一點，您可以使用 Rational 工具來獲取您的需求。Rational 工具為追蹤需求提供了多個工具。這些工具的多樣性將會發揮作用，而 Rational Quality Manager 在環境中擁有基本的需求追蹤功能。Rational Quality Manager 可以幫助您簡化追蹤過程，需求有一個測試用例與之相關，而報告功能會向管理團隊提供關於專案的可視性，以評價與專案相關努力的質量。Rational Quality Manager 通過獲取風險、複雜性以及一系列的其他後設資料來支援您的過程，以安排測試活動的優先順序。使用這些資訊，您就可以評審需求，以找到哪一個需求最容易實現自動化的。Rational Quality Manager 還可以幫助您為重複使用建立相關的工作。我們需要怎樣做，才能將這種最佳實踐轉化為一個質量檢驗關？一種方法是將這個質量檢驗關與其他的質量檢驗關聯絡起來，並使用 IBM Rational Insight 工具來向管理人員報告，或者使用 Rational Quality Manager 解決方案中內建的報告功能。使用 Rational Insight 方案，您可以將追蹤範圍與後設資料聯絡起來，以獲取關於以上任務完成情況的報告。

圖 1. 基於需求測試範圍使用 Rational Quality Manager 的質量檢驗關

設計和編碼階段

軟體開發生命週期的設計和編碼階段，為單元測試的質量檢驗關提供了一個機會。有一些軟體操作發展了測試驅動的開發過程，這又為質量檢驗關提供了一個機會。Rational Quality Manager 可以幫助獲取單元測試相關的後設資料，並引用單元測試，這樣您就可以實現單元測試的成功應用了。這些資訊可以得到評審和報告，幫助您識別，程式碼是否需要得到單元測試認證，以及單元測試成功執行的程度。使用 Rational Insight 方案，您就可以將這些任務整合到一個評價好的、基準化的質量檢驗關。

構建階段

構建階段向您提供了一個方法，將質量檢驗關匯入到您的軟體開發生命週期中。建立質量檢驗關的一種方法，便是使用靜態分析，來將 Rational 技術整合到構建過程中。靜態分析與 Microsoft® Word® 程式中的拼寫和語法檢查器相類似。靜態分析會掃描原始碼，以尋找普通的程式錯誤，與 Microsoft Word 掃描檔案以尋找拼寫和語法錯誤相類似。更特別的是，靜態分析能夠尋找與編碼形式相關的編碼，以識別基本的程式碼漏洞。此時，結構分析可以幫助識別類的附屬，並定位迴圈附屬、軸心以及其他的結構。另外，結構分析有助於評價軟體的複雜性，提供資料流分析，並降低所有來自於預編輯原始碼的 —效能問題。軟體還可以掃描安全性問題，例如跨站點的指令碼以及 Structured Query Language （SQL）注射脆弱性。Rational 為程式碼評審提供了兩個產品：IBM Rational Software Analyzer 企業 RSAR 以及 Ounce Lab 分析提供了專家程式碼評審的價值，而不需要程式碼評審過程的普通方面。兩種工具都可以輕鬆整合到構建過程中，並生成關於怎樣完善原始碼的報告。這些報告可以作為質量檢驗關，幫助您決定繼續到測試階段是不是實際的，或者是否需要重新評價原始碼。這些質量檢驗關可以與其他的質量檢驗關聯絡到一起，例如使用 Rational Insight 環境生成的需求質量檢驗關。匯入這個層次的質量，可以幫助您確保您採用的原始碼不是太複雜，並且滿足最佳編碼操作的需求。

圖 2. 構建階段中基於 Ounce Labs 的質量檢驗關

（圖 2 的大圖。）

測試階段

在測試階段執行質量檢驗關，可以向您的團隊提供一些選項。測試門可以包含到測試階段的幾乎所有方面。您可以考慮執行的一個質量檢驗關，是將質量檢驗關整合到測試框架中。這就迫使您去評審測試指令碼，以確保在手動測試步驟中得到重複利用。這些測試框架質量檢驗關可以獲取測試用例搜尋的高層次情況，以便進行重新利用。評價方法應該來自於可重複使用測試步驟的數量，以及不可重新使用測試步驟的數量。這種檢查點允許管理人員去決定，自動化是否應該繼續，以及是否應該花更多的時間去驗證測試建立的過程。

圖 3. 使用 Rational Quality Manager 基於測試執行狀態的質量檢驗關

最終測試階段

在最終測試階段中，Rational Quality Manager 方案可以提供關於通過的以及未通過的報告、產生的缺陷、嚴重缺陷的數量以及其他的狀態的資訊。這些測試結果是最佳實踐的一部分，以提高專案的質量，並且可以使用 Rational Quality Manager 環境來獲取，並且可以輕鬆升級為測試變更。在這個區域中，Rational Insight 工具通過將這些資訊彙編到一個報告中，可以幫助您改善這個過程，這些報告可以得到輕鬆的追蹤，並由管理人員來評價。

使用質量檢驗關來改進開發過程

改善由業務分析員、程式設計師以及測試者所完成的工作，同時讓它們變得更加有效果和效率，對於軟體開發過程的成功十分重要。使用 IBM Rational Jazz™ 技術來儲存這個輸入的“幕後”內容，您可以使用 Rational Insight 方案來輕鬆建立質量檢驗關。這些質量檢驗關十分基本：在不需要會議、審查或者評價方法的基礎之上，就可以檢視和理解它們。因為 Rational 工具會完美地獲取關於軟體開發生命週期的資訊，而不用對您的開發過程產生什麼影響。

當您在開發過程中使用質量檢驗關（quality gates）時，控制和理解您所採用的軟體開發週期方法可以改善您的開發過程。質量檢驗關通過幫助確保採用了最佳實踐手段，並與過往的專案相比較來提高軟體的產品質量。這種詳細檢查的過程幫助您理解您正在開發的軟體的發展趨勢，給您創造一個機會在軟體開發的早期階段就意識到所存在的質量問題。經驗證明，在早期階段發現存在的缺陷，可以使得修復它們成本更低，進而降低 IT 運作的成本。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780914/viewspace-628343/，如需轉載，請註明出處，否則將追究法律責任。