本文是演示了在分布式的、基于 J2EE 的項目中使用 Rational 工具的系列文章（如下面所列）的第 9 部分。
本文中所虛構(gòu)我們是一家軟件公司 Lookoff Technologies Incorporated，我們的客戶 Audiophile Speaker Design, Inc. (ASDI)，它雇用我們實現(xiàn)他們最初的 IT 需求。對于更詳細的信息，參見 第 1 部分。
到目前為止，我們已經(jīng)接近了 ASDI 項目第一階段的尾聲了。ASDI 已經(jīng)獲得了我們提供的一系列的系統(tǒng)演示，并且他們對產(chǎn)品感到十分的滿意。（實際上，我們有一些擔心，因為項目的第一階段已經(jīng)是如此可用的系統(tǒng)，我們擔心 ASDI 會推遲或者取消接下來的第二階段的項目。） 客戶感到滿意的最終因素是我們進行了充分符合需求的系統(tǒng)測試和驗收測試。
包裝開發(fā)
在這個時候，我們的編碼工作已經(jīng)顯著的減少了。我們在修改和精化產(chǎn)品的階段，團隊的工作主要是針對一些小的更改。當集成與測試（I&T）團隊發(fā)現(xiàn)軟件的缺陷時，他們在基于缺陷缺陷跟蹤的數(shù)據(jù)庫模式之上的 Rational ClearQuest 數(shù)據(jù)庫中填寫并對缺陷進行優(yōu)先級劃分。這些缺陷報告被工程團隊復(fù)查。團隊領(lǐng)導(dǎo)和項目工程師通常決定缺陷的優(yōu)先級并維護一個描述對于被給定的構(gòu)建版本哪一個人將對其進行修復(fù)的計劃。
構(gòu)建的頻率
執(zhí)行完整的系統(tǒng)構(gòu)建版本的頻率 — 在一個清潔的環(huán)境中從頭開始構(gòu)建系統(tǒng) — 使我們大大的接近了第一階段項目的尾聲。最初計劃每個月進行一次構(gòu)建，但這些構(gòu)建有時被每周進行一次。這對于大的項目或者缺少高技能的開發(fā)人員的團隊來說，建立一個清潔的構(gòu)建環(huán)境的日常開支、從源代碼庫中得到軟件，構(gòu)建系統(tǒng)和測試系統(tǒng)的行為是不太可行。然而，感謝我們所使用工具的緊密集成、我們良好的文檔建立過程和我們使用了 Rational 的測試工具快速的完成了我們的測試執(zhí)行，我們才能夠?qū)⑾到y(tǒng)的構(gòu)建增加到每周一次的頻率。
自動化的腳本尤其使進行這么頻繁的構(gòu)建變得切實可行。至少我們運行了腳本來測試被我們已經(jīng)解決了的缺陷所影響的系統(tǒng)部分。我們通?？梢愿M一步，為系統(tǒng)的大多數(shù)或者全部運行腳本。我們非常幸運我們能夠通過自動化的測試腳本來測試系統(tǒng)的模塊；Rational 的測試工具能夠非常好的符合我們使用的技術(shù)，然而，有一些其他技術(shù)的結(jié)合可能會給測試腳本的使用帶來挑戰(zhàn)或者根本無法使用測試腳本。
集成測試（I&T） 團隊的介入
目前為止，我們到達了進行系統(tǒng)構(gòu)建的階段，I&T 團隊完全的投入到并領(lǐng)導(dǎo)這個過程。在項目的開發(fā)周期中(在 第六部分)我們就將 I&T 團隊引入到了項目團隊中，并且進行全職的工作，因此現(xiàn)在他們已經(jīng)做好準備了。在我們之前的項目中，我們比較遲的將 I&T 團隊引入到了項目中，幾乎接近開發(fā)周期的尾聲，但這會產(chǎn)生一定的問題。我們最終意識到 I&T 團隊需要一定的準備時間，就像其他項目團隊的技術(shù)成員一樣。雖然對于我們較早的構(gòu)建來說，在組裝系統(tǒng)方面 I&T 團隊要比系統(tǒng)團隊慢，但是這是我們對他們預(yù)期的學習過程的一部分，并使他們自由的進行構(gòu)建，而工程團隊則可以繼續(xù)他們的開發(fā)工作。
I&T 團隊根據(jù)他們對工程團隊進展的理解定義預(yù)計將要構(gòu)建的目標。他們與項目工程師一起討論構(gòu)建以確保構(gòu)建能夠符合他們的預(yù)期。例如，如果因為一些組件或者子系統(tǒng)沒有準備好，工程團隊沒有為功能測試準好準備，對于組裝，檢查每一個被編譯的的代碼、被匹配的接口和第三方的工具（JDK、庫和購買的工具）在線程和子系統(tǒng)團隊成員中是一致的來說，構(gòu)建只是簡單的練習活動。對于系統(tǒng)十分成熟的構(gòu)建來說，團隊將根據(jù)系統(tǒng)特定的方面進行負載測試或者功能測試。
接近開發(fā)周期的尾聲，I&T 的領(lǐng)導(dǎo)是一個項目團隊中非常重要的角色 － 甚至比團隊領(lǐng)導(dǎo)或者項目經(jīng)理還重要。I&T 領(lǐng)導(dǎo)為測試執(zhí)行指定計劃，了解系統(tǒng)區(qū)域的弱點和長處，并不斷的監(jiān)控缺陷分析數(shù)據(jù)。同時，他也管理需求、組件、線程、測試腳本和缺陷的完全的跟蹤映射，這可以幫助他對他的團隊的動作進行計劃和優(yōu)先級劃分。
修復(fù)缺陷
修復(fù)缺陷絕不是微不足道的任務(wù)。每一個缺陷都會引發(fā)以下的問題：
無論 I&T 團隊什么時候在系統(tǒng)中發(fā)現(xiàn)了一個缺陷，他們都會在 ClearQuest 數(shù)據(jù)庫中提交它，在數(shù)據(jù)庫中他們能夠獲得上面所提到的很多細節(jié)。他們在 ClearQuest 中連接數(shù)據(jù)庫，并在提交缺陷表單中填寫缺陷，如圖 1 所示。
 |
| 圖1: 提交一個缺陷 |
| (點擊放大) |
缺陷數(shù)據(jù)庫能夠被所有的工程團隊的成員所共享，并能夠通過網(wǎng)絡(luò)在任何時間內(nèi)被訪問。例如，在圖 1 中被提交的缺陷的所有者，他的工作是在產(chǎn)品的搜索能力上，他與搜索團隊負責用戶信息的成員分在同一組中。為了保持對任何被分配的打開狀態(tài)的測試問題的跟蹤，I&T 團隊使用了一個 ClearQuest 的查詢。圖 2 顯示了搜索團隊的查詢結(jié)果，圖 1 中被提交的缺陷被顯示在了結(jié)果集中。查詢（結(jié)果總是反映被 I&T 團隊更新的數(shù)據(jù)庫的最新內(nèi)容）結(jié)果被過濾了，僅僅包括搜索團隊的缺陷，并通過優(yōu)先級和提交時間進行排序。
 |
| 圖 2: 被過濾的缺陷查詢結(jié)果 |
| (點擊放大) |
其他的團隊以相似的方式在他們各自的區(qū)域查詢 ClearQuest ，并收到適當被過濾的結(jié)果。僅僅是 I&T 團隊、項目過程師和團隊領(lǐng)導(dǎo)能夠看到項目進展中的完整的缺陷列表。
在圖 2 中的 Actions 按鈕提供了修改、分配、關(guān)閉、復(fù)制、推遲或者刪除當前被選定查詢結(jié)果的選項。根據(jù)項目團隊成員的職位，不同人能夠進行不同的操作：
系統(tǒng)測試
系統(tǒng)測試通過使用被錄制的測試腳本對整個系統(tǒng)進行測試。這種測試不僅對客戶的驗收測試十分重要，同時它也深層次的檢驗了系統(tǒng)并提供了在測試腳本中的缺陷的洞察力。無論我們多么嚴密的對變更進行跟蹤，也經(jīng)常會有一些小的變更超出我們預(yù)計的范圍從而帶來一些沖突，以未預(yù)料的方式影響其他的代碼片斷。
我們通常在被 I&T 團隊建立的清潔環(huán)境中進行系統(tǒng)的構(gòu)建，因此我們徹底的測試了構(gòu)建的文檔。如果在構(gòu)建文檔中遇到了任何的錯誤，一個問題（在“文檔”分類中）連同任何被識別的測試缺陷被提交到缺陷數(shù)據(jù)庫中。
從單元測試階段（在第 8 部分被討論）到現(xiàn)在，我們測試了系統(tǒng)的功能需求和系統(tǒng)的非功能需求，現(xiàn)在我們在系統(tǒng)的非功能需求上投入了比在早期測試階段更多的精力。我們測試的主要非功能領(lǐng)域是可用性和性能（負載測試），我們將在下面進行討論。
可用性建議
我們用了我們僅有的可用性專家。雖然她被包含在早期的用戶界面的計劃和模擬工作中，幫助人機界面的工作，但她沒有加入到我們和 I&T 團隊的其他成員中。她現(xiàn)在的工作是作為一名用戶與系統(tǒng)一起工作，找出可用性的問題，并將問題提交到缺陷數(shù)據(jù)庫中（通常在“不友好的行為”類別中）。
一些可用性的問題必須被推遲解決，因為他們超出了第一階段的范圍或者處理他們是非常耗成本的。然而，許多容易修復(fù)的和會給客戶帶來混亂的小的可用性問題被發(fā)現(xiàn)了。這是我們最成本高效的測試活動中的一些，因為通常從客戶的角度來看，只不過是一些小的代碼改變就能大大的改進產(chǎn)品?？捎眯缘慕ㄗh包括新的錯誤信息、布局的改進、調(diào)整按鈕的標題和菜單、文檔的整理和屏幕工作流程的修改。
負載測試
我們的系統(tǒng)沒有苛刻的性能需求，但是我們想讓系統(tǒng)在最大負載下是可用的。我們在早期做了一些負載測試，但是這個測試類型會在接近開發(fā)周期的尾聲時達到最高點。我們想確保系統(tǒng)能夠超越 ASDI 的期望。我們希望我們能夠以項目的第二階段的形式得到接下來的工作，我們不希望造成性能的問題。我們對系統(tǒng)的兩個部分進行了負載測試：Web 應(yīng)用接口和通過基于 SSL/XML 的 command gateway （在第 5 部分被介紹）的 B2B接口。
Web 負載測試
對于 Web 的負載測試，我們使用了 Rational SiteLoad 。這個工具能使我們錄制由一系列我們執(zhí)行的 Web 事務(wù)組成的腳本，然后將這些步驟復(fù)制作為多個虛擬的用戶。我們和 ASDI 一起復(fù)查了被預(yù)期的負載模式以確定有多少用戶同時訪問 Web 應(yīng)用，我們決定測試 20 個用戶的負載。
通過使用 SiteLoad ，我們能夠容易的模擬 20 個系統(tǒng)的并發(fā)用戶，并精確的統(tǒng)計相關(guān)的系統(tǒng)性能。當我們啟動 SiteLoad 時，它啟動了我們的瀏覽器，并提示我們創(chuàng)建一個測試或者運行一個已存在的測試（見圖 3）。
 |
| 圖3: SiteLoad 的主屏幕 |
| (點擊放大) |
當我們選擇錄制一個新腳本時，SiteLoad 彈出一個基于 Java 的瀏覽器，并記錄我們在它之上所做的所有動作。例如，當我們在這個瀏覽器中瀏覽我們的 partSearch.jsp 頁面時，SiteLoad 從服務(wù)器端加載這個頁面（如圖 4 所示），并記錄我們的動作，包括我們輸入的任何數(shù)據(jù)值和按鈕的點擊動作。我們設(shè)計了這個特定的測試以執(zhí)行基于多個參數(shù)的很多次數(shù)據(jù)庫查詢操作。這顯然是一個很簡單的測試，因為數(shù)據(jù)庫能夠緩存查詢；其他的一些測試會更加的嚴格和具有挑戰(zhàn)性。
 |
| 圖 4: SiteLoad 記錄瀏覽器的動作 |
| (點擊放大) |
對于我們錄制的每一個腳本，我們也能夠為測試設(shè)置一些通常的性能需求。我們決定當測試 partSearch.jsp 頁面的腳本被回放時，我們希望至少有 90% 的頁面在四秒或者更少的時間內(nèi)被加載（見圖 5）。雖然這并不符合高性能的要求，但這對于我們系統(tǒng)的可用性和整體質(zhì)量來說已經(jīng)足夠了。
 |
| 圖 5: 設(shè)置 SiteLoad 的性能需求 |
| (點擊放大) |
圖 6 顯示了我們?nèi)绾闻渲?SiteLoad 來模擬 20 個并發(fā)用戶反復(fù)的執(zhí)行我們記錄的 partSearch.jsp 頁面的動作。SiteLoad 能夠進行更加復(fù)雜的性能建模以幫助我們找出我們的系統(tǒng)的“性能圍墻”，但是我們選擇在我們的首次嘗試中直接進行 20 個并發(fā)用戶的最大值測試。如果我們遇到問題，我們將減少最初的用戶數(shù)量至 5 個，并每一分鐘或者兩分鐘增加一個用戶。我們也能夠為終止測試設(shè)定一個標準，但我們沒有這樣做，因為我們正可視化的監(jiān)視測試的過程以了解我們的系統(tǒng)有什么樣的行為。
 |
| 圖 6: 設(shè)置 SiteLoad 用戶特性 |
| (點擊放大) |
當測試正在運行時，SiteLoad 顯示并不斷的更新象圖 7 中顯示的統(tǒng)計數(shù)據(jù)。在這個例子中，一個柱狀圖表明我們的測試腳本的性能結(jié)果；幾乎所有的頁面都在 8 秒鐘內(nèi)被加載執(zhí)行（換句話說，只有 0-20% 在我們的 4 秒鐘內(nèi)的性能限制中）。使用在屏幕頂部附近的綠色菜單欄中提供的選項，我們能夠選擇查看更加詳細的測試報告，比如，頁面訪問、CPU 負載和平均負載時間。
|
| 圖 7: SiteLoad 的測試結(jié)果 |
| (點擊放大) |
B2B 負載測試
對于 SSL/XML 的 B2B 負載測試，我們使用了 Rational Robot 來錄制虛擬用戶（VU）腳本。我們輸入我們希望 Robot 執(zhí)行的命令來監(jiān)視并以一個腳本的生成最為結(jié)束，這個腳本與被 Robot 生成的 GUI 腳本（在 第 8 部分被討論）十分不同。不像 GUI 腳本，VU 腳本記錄和接收與傳輸信息相關(guān)的低級信息。通過從多臺機器運行 VU 腳本，我們能夠模擬并發(fā)操作系統(tǒng)的 B2B 客戶端會話。 ASDI 懷疑可能會有多余兩個的并發(fā)會話會發(fā)生，因此我們能夠完成一些超越這個需求的步驟，以確保良好的系統(tǒng)性能。
測試完成情況檢查
在我們計劃中的最后兩周里，工程團隊進行了系統(tǒng)測試，并通過了所有的需求，并且 I&T 團隊關(guān)閉了所有的問題，除了一些我們已經(jīng)與客戶討論過得認為可以被推遲的不重要的問題。對于我們來說下一個里程碑是測試完成情況檢查（TRR），我們執(zhí)行了兩個 TRR ：一個是內(nèi)部的，一個是與客戶一起的。內(nèi)部的 TRR 以下列檢查來實現(xiàn)：
除了檢查上面的項目，我們還復(fù)查并預(yù)排了一個系統(tǒng)演示，整個演示作為產(chǎn)品的最終展示服務(wù)于與客戶進行外部的 TRR 。我們?yōu)槲覀儤?gòu)建的產(chǎn)品自豪，并且我們希望確保顯示系統(tǒng)所有關(guān)鍵的特性，因為我們知道 ASDI 的高層管理人員將出席這個外部的 TRR 。
在外部 TRR 期間，我們按照與內(nèi)部 TRR 相同的日程安排進行。我們與 ASDI 一起審閱了檢查列表以顯示每一件事情都被完成了，并且結(jié)束了這個演示。并不令人驚訝，在最終的演示中出現(xiàn)了更多的一些想法，處于對將來的考慮我們將他們注釋下來。
驗收測試
為了 ASDI 同意項目的第一階段已經(jīng)被成功的完成，系統(tǒng)必須通過一些最終的驗收測試。我們有理由相信系統(tǒng)能夠通過這些測試，因為我們已經(jīng)為執(zhí)行系統(tǒng)的端到端的測試編寫了一套腳本來檢查是否所有的需求都被覆蓋到了。這些腳本使用 Rational Robot 創(chuàng)建的，并且被 ASDI 徹底的檢查過了。我們能夠想到的唯一能夠防礙我們驗收測試成功的事情就是被工程團隊最后時刻的變更可能會影響其他的代碼片斷。但是在我們開始驗收測試之前我們收到了一個令人驚訝的消息， ASDI 在外部 TRR 中告訴我們他們想讓我們手工的進行驗收測。我們認為我們在驗收計劃中指出使用測試腳本的意圖是非常清楚的，但是現(xiàn)在我們意識到我們在計劃中的措詞是含糊不清的。
當我們在外部 TRR 中陳述 CAT （客戶驗收測試）將是相當簡短的，并且我們能夠非?？焖俚膱?zhí)行和檢查腳本的執(zhí)行結(jié)果時， ASDI 表示他們想看到所有一步一步的測試執(zhí)行以便他們知道發(fā)生了什么。雖然我們不希望這樣，但看起來對我們還是公平并且可行的。我們?yōu)槲覀兊臏y試腳本文檔化了所有的測試過程和計劃，甚至當腳本升級時，我們也維護了我們的測試計劃，因此，對于我們來說手工執(zhí)行測試不是什么問題。
我們沒有準備的是手工進行驗收測試要花費多長時間?，F(xiàn)在我們根據(jù)我們文檔化的測試過程進行手工的測試，我們意識到自動化的測試為我們節(jié)省了多少時間。
我們發(fā)現(xiàn)在我們的測試過程中丟失了一些必須提供的細節(jié)。我們不總是能夠獲得足夠的信息來創(chuàng)建一個明確的并且可反復(fù)使用的測試。我們也意識到有時我們更新了測試腳本但沒有修改測試計劃。在對測試計劃進行了小的變更后，我們?yōu)橐粋€快速檢查向客戶交付了測試計劃；我們同意變更是非常小的，并不需要其他的 TRR 。
驗收測試發(fā)生在我們的開發(fā)環(huán)境中，開始于根據(jù)構(gòu)建文檔進行清潔的構(gòu)建，并引發(fā)測試過程的執(zhí)行。這些測試大概會花費一共兩到一天半的時間來執(zhí)行。我們團隊中的三個成員執(zhí)行這些任務(wù)（I&T 領(lǐng)導(dǎo)、項目工程師和團隊領(lǐng)導(dǎo)），還有三個來自 ASDI 的人員（QA、項目經(jīng)理和技術(shù)領(lǐng)導(dǎo)）。
我們引以自豪的是在驗收測試期間沒有軟件缺陷出現(xiàn)。僅僅出現(xiàn)了一些不重要的問題，通常是在“文檔”和“不友好行為”類別中的。所有的需求都被滿足了，客戶在測試結(jié)束時非常的高興。
總結(jié)
這也許是我們的團隊在開發(fā)和測試的結(jié)尾不必花費大量時間工作的第一個項目。其中對此作出貢獻的因素是我們有更好的工具、對技術(shù)的熟悉和一個在項目早期就一起工作的工程團隊。
尤其是測試過程有一個很大的成功。Rational 工具給人印象最深刻的也許是測試的功能。這是我們第一次引入自動化測試，并且我們對它工作的如此好感到驚訝。自動化測試的最大痛處是相應(yīng)需求變化的腳本修改；然而，這個責任被傳遞給了集成與測試團隊，因此不會影響我們的工程團隊的工作。
計劃未來
現(xiàn)在我們在客戶的環(huán)境中安裝了軟件，并給他們一些時間評估系統(tǒng)。雖然沒有一個正式的保證階段，但是 ASDI 一直在向 ClearQuest 數(shù)據(jù)庫中提交問題。最后，一個是否進行項目第二階段的協(xié)議必須被達成。
主要風險
在此時我們覺得已經(jīng)沒有任何主要的風險了。我們很自信所有大的問題都已經(jīng)被解決了，并且我們充分的準備了這個項目剩余部分可能會出現(xiàn)的任何問題。
| 關(guān)于作者 Steven Franklin 在軟件的設(shè)計、架構(gòu)和工程過程方面有非常廣泛的背景，這些經(jīng)驗通常被用到大的，分布式的信息管理和控制系統(tǒng)中。他從1997年開始使用 Rational 工具，他主要的興趣在 XML 、J2EE、無線和軟件工程技術(shù)方面。你可以通過 steve@sfranklin.net聯(lián)系 Steven 。 |
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=240519
