應用 Rational 工具簡化基於 J2EE 的項目第 8 部分 ：測試軟體

本文是示範了在分布式的、基於 J2EE 的項目中使用 Rational 工具的系列文章（如下面所列）的第 8 部分。

• 第 1 部分: 項目介紹；高層次計劃
• 第 2 部分: 風險管理；需求管理
• 第 3 部分: 模型建立和存取控制；需求分析
• 第 4 部分: 用例細化；產成報告；工具和技術選擇
• 第 5 部分: 體系架構和設計
• 第 6 部分: 詳細設計；早期開發；雙向工程；早期單元測試
• 第 7 部分: 繼續開發；早期的構建；示範
• 第 8 部分: 單元測試策略；功能測試；GUI 測試指令碼
• 第 9 部分: 系統構建和測試；缺陷跟蹤；產品交付
• 第 10 部分: 項目完成；結論；未來的工作

本文中所虛構我們是一家軟體公司 Lookoff Technologies Incorporated，我們的客戶 Audiophile Speaker Design, Inc. (ASDI)，它僱用我們實現他們最初的 IT 需求。對於更詳細的資訊，參見 第 1 部分。

本文是這個系列文章的第 8 部分，本文中對最初在這個系列的第 6 部分介紹的測試方面的主題進行了詳細的討論。在第 6 部分的文章中，我們看到了在早期的開發當中我們開始使用 Rational Purify 和 Rational Quantify 檢查記憶體的使用方式和效能的瓶頸。同時也討論了我們在早期的單元測試工作的很多細節。本文將描述這些工作的進展，並回顧我們使用 Rational 測試載入器的自動化測試的能力來減少測試的成本，主要是 Rational PureCoverage 和 Rational Robot 的使用方式。在項目的這個階段，我們主要關注在功能測試（包括 GUI 測試）上，雖然我們也從事了一些早期的負載測試。

注意，這裡使用的 Rational 統一過程（RUP）術語反映了測試的兩個不同的維度：“單元測試”是在將要被測試的軟體的開發階段進行的 — 在這個時候測試是針對最小的可測試的軟體單元的 — 而“功能測試”和“負載測試”是針對特定測試目標的，不管是在被測試軟體的哪個開發階段。本文中所討論的關於單元測試的大多數內容也可以應用在我們後面的開發階段的測試工作中（例如，在整合測試期間合并不同的組件或者子系統）。

第 8 部分快照

在第 8 部分示範的工具和技術： Rational PureCoverage — 用於在單元測試期間分析代碼的覆蓋率（代碼被執行的次數） Rational Robot — 為可重複的自動化執行錄製和回放測試指令碼 Rational Administrator — 用於建立項目，與 Rational Robot 一起使用，關聯與項目相關的測試指令碼 Rational TestManager — 組織和管理測試，並查看測試的結果 被建立或者更新的產物： Robot 測試指令碼 — 為自動化測試的執行而被建立

單元測試

在開發的進展過程中，我們發現我們的單元測試工作超過了我們的開發工作，因為我們正在構建的應用具有非常複雜的使用者互動。單元測試總是要求大量的工作，並且我們也許沒有足夠的預算和時間來執行大量的單元測試工作。我們發現我們的 GUI 測試，包括單調的手工測試的過程，尤其減慢了我們的速度。

雖然 ASDI 項目的第 1 階段只是一個概念上的驗證，但是我們也具有艱苦的時間忍耐在系統中顯而易見的 bug 。在擁有堅固、可靠的軟體和頻繁的整合、快速的示範之間找到一個平衡是非常不容易的。我們定義了第 1 階段項目的範圍，這樣我們就必須進行不止一次的技術上的示範；客戶期望示範是一個可以使用的系統的 beta 版本。

這裡，我們將看一下我們的單元測試工作的範圍，我們可以選擇（或者不）使用自動化的能力，並且我們使用 Rational PureCoverage 來確定我們測試的徹底性。

測試的範圍

單元測試的範圍 — 什麼、多少次和什麼時候測試 — 是幾個可變數的基礎，包括：

• 軟體的複雜程度
• 產品的特性和介面
• 被測試部分對整個產品是否是非常關鍵的
• 團隊對軟體中缺陷的容忍程度

在代碼測試的次數方面，在之前的項目中我們沒有打算在我們的軟體中進行 100% 程式碼涵蓋範圍的測試。完全的覆蓋是非常昂貴的並且很難達到，因為我們必須要手工的檢查我們的代碼以確定哪一行代碼沒有被測試覆蓋到。對單元測試的小的變化將要求我們重新檢查代碼以確保完全的覆蓋率被維護。然而，我們得感謝 Rational PureCoverage ，在 ASDI 項目中我們能夠容易得實現了接近 100% 的程式碼涵蓋範圍（由於項目預算和範圍的原因，少量的未測試的殘留是被允許的）。PureCoverage 很大程度的簡化了檢查程式碼涵蓋範圍的任務，這使識別哪一部分的代碼已經或者還沒有被測試變得非常簡單。

就像我們在這個系列的第 6 部分提到的那樣，我們的單元測試工作幾乎與核心的軟體開發本身開始的一樣早。我們多數的開發人員在他們擁有一個能夠被測試的軟體單元不久就開始編寫單元測試。他們喜歡當代碼在他們的頭腦中產生時測試軟體的內部構件。

單元測試的執行總是先於系統的構建；將明顯能夠通過單元測試來消除的簡單缺陷引入到一個構建版本中是讓人不可接受的。單元測試總是在代碼被分發檢查之前被執行。此外，開發人員以規範的基礎運行他們的單元測試以確保他們的定期變化不會破壞軟體。我們的方法不像一些軟體方法那樣激進 — 比如 極限編程（XP），在 XP 中單元測試的開發通常是先於代碼的開發的 — 但是我們將單元測試當作是一個重要的軟體開發的早期步驟。

自動化的能力

這裡當然也有一些如何進行測試的問題，特別是什麼樣的測試應該被自動化的範圍。編寫“後台”（非 GUI ）代碼的開發人員是幸運的，他們能夠編寫自動化的測試，包括 Java 驅動程式、程式碼端和指令碼。然而，就像我們早些時候提到的，GUI 開發人員的測試是更加困難的。

對於我們的非 GUI 測試，我們觀察了與每一個類相關聯的單元測試的習慣；我們編寫驅動代碼訪問類，並報告成功或者是失敗。我們嘗試使用能夠為我們自動產生、管理和運行測試的測試架構，比如被 XP 所推薦的那些工具，但是他們將產生混雜的結果。雖然理論是很好的，但是這些架構（包括，比如 JUnit）對於我們的項目目的來說來是不夠成熟的。不過，我們的開發人員非常自信如果他們有時間熟悉和對這些工具進行改進，這些測試架構對我們的單元測試是非常有價值的。我們也許在將來的項目中更多的使用這些測試架構。在我們的 ASDI 項目中，採用 XP 的方法也許是太冒險了；相反，我們更加願意接受 XP 在控制和風險降低方法方面的概念和思想。你能夠在 the XProgramming.com 網站上找到大量有關 XP 思想的內容。

我們沒有使用 Rational 的測試載入器來測試非 GUI 的代碼，因為我們覺得他們不能達到一個足夠底層的層級。對於自動化測試我們的 GUI 驅動的代碼，Rational 的測試載入器真的表現的非常出色。使用者介面測試是非常手工和互動的，並且要求大量的內容確認； Rational 的測試載入器以一種一致的並快速的方式使我們反覆的進行這些測試變得更加的簡單容易。

程式碼涵蓋範圍

通過使用 Rational PureCoverage ，在我們的單元測試執行期間，我們能夠大幅的降低我們花在確定程式碼涵蓋範圍上的時間 — 也就是說，哪些方法或者程式碼被執行或者被遺漏 。這個工具能夠使我們觀測我們提供的代碼覆蓋測試，然後決定是改進測試還是通過手工檢查的方法來測試代碼。

PureCoverage 除了可以支援 C 或者 C++ 的應用程式以外，還可以支援 Java 程式，並且可以通過與 Quantify 相同的方式來配置和運行（在這個系列的第 6 部分被討論過）。這個工具能夠使我們瀏覽我們的單元測試；以兩種方法進行代碼覆蓋測試：使用 Coverage Browser 或者指定檔案的 Coverage Fileview 方式。

使用 Coverage Browser 的方式（圖 1 ），我們能夠看到在單元測試中被包括的每一個檔案（和目錄）的代碼覆蓋測試的統計學的總結。這些統計表包括了所有方法的調用次數，方法被訪問或者遺漏的次數，還包括被訪問或者遺漏的程式碼的數量。

圖 1: Coverage Browser

(點擊放大)

我們能夠雙擊一個在總結中的方法來進入 Coverage Fileview ，僅僅顯示在那個方法中哪些程式碼被訪問或者被遺漏。就像被顯示在圖 2 中的例子，被遺漏的程式碼被用紅色突出出來（被訪問的程式碼用藍色標識）。

圖 2: Coverage Fileview

(click here to enlarge)

功能測試

功能測試根據被定義在用例中的需求來驗證軟體是否正確的工作。為了確保我們測試了所有的需求，我們在設計和組織我們的功能測試時使用 Rational Robot 和 Rational TestManager 。（一個關於使用 Robot 的功能測試策略的討論能夠在 Robot 的使用者指南中被找到。）Robot 能夠使測試指令碼更加容易的被錄製，然後為自動化測試回放。使用 Robot 能夠建立兩種類型的測試指令碼：

• GUI 指令碼 記錄你的使用者介面動作，當進行回放時，就像一個使用者在操作應用的登陸和控製程序的視窗。一些用戶端的測試 — 比如，嵌入到我們的 Web 應用程式中的 ActiveX 控制項 — 需要使用這些指令碼。因為 GUI 測試為我們造成了特殊的問題，因此這類的功能測試將在下一部分被詳細的討論。
• VU scripts 當你使用它在包的層級上跟蹤什麼樣的網路資訊被發送和接受時，檢測你的應用。當進行回放時，這些指令碼不必登陸應用就可以重新運行測試，這使他們比 GUI 指令碼執行的更快。我們為我們的 command gateway 的非 GUI 功能測試和 B2B 的負載測試使用 VU 指令碼。

我們儘可能早的開始建立我們的功能測試集合，因為這些測試對工程團隊來說是非常有價值的工具。我們在代碼被分發檢查之前適當的擁有測試指令碼的目標有時是很難實現的，可能是因為代碼的一些部分和一些組件要比其他的代碼和組件花費更多的時間來完成，或者是因為整合和測試（I&T）團隊太慢以至不能及時的完成測試指令碼。在一種情況下，當使用者介面仍然在變化時，測試指令碼已經被完成了；雖然一些返工是必要的，但是變化的出現是相當容易整合的。

一旦我們擁有了一個強有力的功能測試集合，重新測試系統將是非常容易的。這樣當你需要在後來的迭代中重新測試系統小的改變時得到很大的回報，並且可以確保變化不會影響其他的代碼部分。我們映射我們的功能測試指令碼到用例上，以便我們可以立即知道當被關聯到被給定的用例的需求被修改時哪一個測試應該被運行。

GUI 測試

當非 GUI 代碼的開發人員非常高效的進行他們的單元測試工作時，JSP/servlet 的開發人員將很難的保證時間的進度。刺痛他們的是測試 GUI 域的過程，這個過程包括反覆的執行下面的步驟：

1. 在資料庫中建立測試資料。
2. 通過 網頁瀏覽器登陸應用。
3. 導航被測試的頁面（一個表單要被填充）。
4. 在頁面上填寫一個或者多個域，依賴具體的測試。
5. 點擊適當的按鈕提交表單。
6. 檢查結果。
7. 使用不同的測試（不同的域值或者不同的域）返回到步驟 4 ，直到所有合理的組合都被測試。

一些 GUI 測試尤其令人討厭，包括相同的入口，在幾個域中填寫冗長的值。可以使用剪下和粘貼，但是對於團隊來說一遍一遍的重複這些測試仍然是非常瑣碎的工作。有些頁面有 50 個不同的測試必須被執行，每個測試都包括很多的步驟。

雖然我們最初不傾向使用 Rational 的測試載入器，但是我們覺得我們在 GUI 上的困難是我們深入研究 Rational 測試載入器的很好的理由。我們決定使用 Rational Robot 來自動化我們 GUI 的大部分測試。我們通過以下的方式調整了這些測試：

• 開發人員為每一個測試起草一個單元測試說明。
• 初級的整合與測試團隊成員接受單元測試說明並基於當前的軟體構建版本建立測試指令碼。
• 單元測試指令碼是可組態管理的，以便對測試指令碼的變更可以被跟蹤。
• 週期性，一個開發人員給整合與測試團隊執行單元測試指令碼的任務，並提供一個根據單元測試說明指明成功或者失敗的報告。

這個方法工作的非常好。它不僅僅在整合與測試團隊沒有太多的事情做的開發過程的早期階段給他們在更多的工作，而且也給他們一個機會通過揭示單元測試說明來瞭解整個軟體系統。此外，我們為 GUI 測試使用 Robot 的經驗也為阿我們對其他的功能測試指令碼進行了準備。

當 Rational Robot 啟動時，它需要一個已存在項目（使用 Rational Administrator 建立的）的選擇，測試指令碼將與這個項目進行關聯。在我們的例子中，項目的定位必須是在網路上可訪問的，以便我們能夠在整個團隊中共用項目的資料庫。我們在 Administrator 中建立了 ASDI 項目， 3 所示，並且當 Robot 提示我們選擇一個項目時，我們選擇了這個項目。

圖 3: 使用 Rational Administrator 建立一個項目

一個驗證測試的例子

作為一個 GUI 測試的非常簡單的例子，我們需要確證對於我們的 partSearch.jsp 頁面來說用戶端的驗證是行為正確的，這個頁面執行了 JavaScript 的代碼來驗證他們域。每個 ASDI 的條件，部分數字被輸入到整個頁面中，比如，必須是比 0 要大的整型數字；如果一個使用者輸入一個無效的數字，JavaScript 代碼就會報告一個錯誤，並且不會送壞的資料到伺服器。我們的 JavaScript 代碼遵循了在 對於表單驗證的範例代碼，我們在 FormChek.js 檔案中編寫了我們自己的驗證代碼。適當的使用這個代碼，一個負數的輸入會彈出 4 所示的視窗。

圖 4: 適當的 partSearch.jsp 頁面驗證

建立測試指令碼

我們在 Robot 中建立了一個測試指令碼來測試數字域的驗證是否示適當的。首先 Robot 提示我們為指令碼提供一個名字（圖 5）。

圖 5: 錄製一個新的 GUI 指令碼

在點擊 OK 這後，我們被提供了一個錄製控制器（圖 6），然後當 Robot 錄製我們的動作時，我們使用我們的基於視窗的應用。在這個例子中，我們啟動了 Internet Explorer 5 ，在 partSearch.jsp 頁面進行瀏覽，輸入一個壞的數字 （-123456），點擊 頁面上的 Submit 按鈕。

圖 6: Robot 錄製控制器

Robot 將我們的動作記錄在一個 GUI 指令碼中（圖 7 ）。這是一個非常簡單的例子；我們實際的測試會包括更加複雜的測試指令碼。我們不用建立成百上千個獨立的指令碼，而是盡量為每一個螢幕介面設計一個大的指令碼。在 Robot 的文章中有進行測試設計的非常詳細的資訊，我們能夠從 Robot 文檔中所推薦的內容中得到大量的借鑒。

圖 7: 簡單的 Robot GUI 指令碼

(點擊放大)

通過使用易讀的並且可以容易的進行編輯的指令碼，我們就不必為只是有很小差異的測試重複的錄製測試指令碼了。有時我們可以不用重新運行測試就直接編輯測試指令碼，或者我們只是重新錄製一個測試的一小部分，然後將它粘貼到已存在的指令碼中。

運行測試

為了再一次運行測試，我們簡單的在 Robot 的錄製控制器上（或者選擇 File 菜單上的 Playback ）點擊 “play” 按鈕。指令碼就像我們最初執行測試一樣回放我們的測試操作，並且當指令碼運行完成時，Rational TestManager 被啟動來總結我們的測試結果。對於上面那個簡單的例子，TestManager 在圖 8 中顯示的結果表明，測試指令碼啟動並執行結果是測試被通過。

圖 8: TestManager 報告 Robot 的測試通過

(點擊放大)

假設我們想測試代碼的錯誤處理能力，比如壞的數字不再被捕獲 — 也就是說，沒有出現一個指明錯誤的視窗，我們的應用就會將整個資料傳送到 servlet 來執行查詢。當我們通過回放指令碼重新運行這個 GUI 測試時，Robot 將會捕獲這個問題，並且將結果寫到報告中（圖 9 ），包括顯示出這個測試是失敗的。

圖 9: TestManager 報告 Robot 測試的失敗

(點擊放大)

總結

當我們開始 ASDI 項目時，我們期望使用 Rational 的分析和設計工具而不是 Rational 的測試載入器。到項目第一階段的這個時期，我們非常驚訝並且也很高興的看到我們通過使用 Rational 的測試載入器自動化並且改進了我們的測試過程。這些工具都有一個堅實的學習曲線，但是一旦我們掌握我們每個工具的使用方法，我們的整合與測試團隊的生產力將大大的提高。在一些情況下，個體開發人員使用象 Rational Purify 、Quantify 和 PureCoverage 這樣的工具為他們的單元測試工作提供補充。其他的工具，比如 Rational Robot ，則需要整合與測試團隊具有更高的技能並投入更大的注意力。

計劃未來

團隊仍然必須在系統層級上承擔整合和測試的任務。多數的單元測試工作被分包給了開發人員，但是我們還需要更加全面和正式的測試子系統和整個系統。這就意味著我們需要正式的構建版本、最終的構建文檔和在整合與測試上的重要關注。特定目的的負載測試只是我們測試工作中的一小部分，但是它在整個系統的測試中卻是非常重要的。幸運的是，我們的測試集合已經完成了 95% ，並且我們還稍稍的比計劃的時間提前了一點，因此我們能夠有一些額外的精力來關注系統的測試以確保高品質的第一階段的系統交付。

主要風險

我們的風險列表在此刻已經非常的短了。客戶在演化系統上的合作並不太令人驚訝，我們的技術風險已經非常少了，非常感謝工程團隊帶來的良好的進展。

現在我們必須對我們的代碼開發進行最後的加工、執行系統的測試、識別系統中的任何缺陷並按計劃交付階段一的系統給客戶。當團隊接近主要階段的尾聲時，及時的將所有的細節封裝起來通常時很難的。如果我們想避免超出計劃，我們就需要系統有少量的缺陷，並且能夠快速的矯正在測試中發現的任何問題。

關於作者 Steven Franklin 在軟體的設計、架構和工程過程方面有非常廣泛的背景，這些經驗通常被用到大的，分布式的資訊管理和控制系統中。他從1997年開始使用 Rational 工具，他主要的興趣在 XML 、J2EE、無線和軟體工程技術方面。你可以通過 steve@sfranklin.net聯絡 Steven.