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