組件級(jí)測(cè)試
很顯然，首先必須開發(fā)單個(gè)組件，然后才能將它們"裝配"成功能系統(tǒng)。因?yàn)榻M件可以進(jìn)行早期測(cè)試，所以在 TAP 中端到端測(cè)試是從組件測(cè)試開始的。在組件測(cè)試中，隨著環(huán)境的建立，適當(dāng)?shù)臏y(cè)試也分別實(shí)施于各個(gè)不同的單個(gè)組件上。
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
功能測(cè)試和性能測(cè)試在組件測(cè)試階段都相當(dāng)有價(jià)值，它們幫助診斷了在整個(gè)環(huán)境構(gòu)建前和構(gòu)建中的各種缺陷。
組件測(cè)試中的功能測(cè)試
組件級(jí)功能測(cè)試驗(yàn)證了每個(gè)組件所執(zhí)行的事務(wù)。這包括了組件或系統(tǒng)所要求的任何數(shù)據(jù)轉(zhuǎn)換和組件所處理的事務(wù)的業(yè)務(wù)邏輯的驗(yàn)證。在應(yīng)用程序功能的開發(fā)中，基礎(chǔ)設(shè)施測(cè)試（infrastrUCture testing）驗(yàn)證并量化整個(gè)環(huán)境中的數(shù)據(jù)流量，并以這種方式來同時(shí)進(jìn)行功能和性能測(cè)試。數(shù)據(jù)完整性必須當(dāng)數(shù)據(jù)在組件間傳遞時(shí)進(jìn)行驗(yàn)證。例如，XML 測(cè)試在逐個(gè)事務(wù)地驗(yàn)證 XML 數(shù)據(jù)內(nèi)容，并在需要時(shí)驗(yàn)證正式 XML 結(jié)構(gòu)（元數(shù)據(jù)結(jié)構(gòu)）。對(duì)組件測(cè)試來說，諸如 IBM Rational Robot 這樣的自動(dòng)可擴(kuò)展的測(cè)試工具可以大大的減少用在 GUI 測(cè)試和非GUI組件的功能測(cè)試上的時(shí)間和精力。Rational Robot 的腳本語言支持對(duì)外部 COM DDLs 的調(diào)用，是非 GUI 對(duì)象測(cè)試的理想工具。此外，Rational Suite TestStudio 和 Rational Team Test 所附帶的新的 Web 和
java 測(cè)試功能，提供了測(cè)試 J2EE 架構(gòu)和使用 java 語言來編寫測(cè)試腳本的附加功能。
組件級(jí)可伸縮性測(cè)試和性能測(cè)試
與這些功能測(cè)試并行的是組件級(jí)可伸縮性測(cè)試，在環(huán)境中檢驗(yàn)每個(gè)組件來確定其事務(wù)（或者說容量）的限度。一旦有足夠的應(yīng)用功能來創(chuàng)建業(yè)務(wù)相關(guān)的事務(wù)，事務(wù)特征測(cè)試（transcation characterization testing）就被用來確定業(yè)務(wù)事務(wù)中的各個(gè)定量描述，包括消耗的帶寬和后臺(tái) CPU 以及內(nèi)存的占用率。資源測(cè)試（Resource testing）將這個(gè)概念擴(kuò)展到多用戶測(cè)試，從而確定應(yīng)用程序和子系統(tǒng)或模塊中全部的資源消耗。最后，配置測(cè)試（configuration testing）可以用來確定哪些硬件、操作系統(tǒng)、軟件、網(wǎng)絡(luò)、數(shù)據(jù)庫或者其他配置上的變更可以優(yōu)化性能。與功能測(cè)試一樣，有效的自動(dòng)工具如 Rational Suite TestStudio 和 Rational Team Test 所提供的那些工具可以極大地簡(jiǎn)化可伸縮性測(cè)試和性能測(cè)試。在這種情況下，創(chuàng)建、計(jì)劃和驅(qū)動(dòng)多用戶測(cè)試以及監(jiān)控資源利用率的能力是有效且成功完成資源測(cè)試、事務(wù)特征測(cè)試和配置測(cè)試的基礎(chǔ)。
系統(tǒng)級(jí)測(cè)試
系統(tǒng) "裝配"完成后，對(duì)環(huán)境的整體測(cè)試就可以開始了。同樣，端到端架構(gòu)測(cè)試需要對(duì)整個(gè)環(huán)境的功能以及性能/可伸縮性進(jìn)行驗(yàn)證。
系統(tǒng)級(jí)功能測(cè)試
集成是首要考慮的問題之一。集成測(cè)試 ( Integration Testing ) 從數(shù)據(jù)的角度檢查了整體系統(tǒng)是否完成了集成。也就是說，需要互相交互的硬件或軟件組件是否通訊正常？假如是，那么，在它們間傳遞的數(shù)據(jù)是否正確呢？假如可以，數(shù)據(jù)應(yīng)當(dāng)在系統(tǒng)組件傳送的中間階段被訪問和驗(yàn)證。例如，當(dāng)數(shù)據(jù)被寫到臨時(shí)數(shù)據(jù)庫中時(shí)，或者數(shù)據(jù)在被目標(biāo)組件處理之前已經(jīng)存在于消息隊(duì)列中時(shí)，就應(yīng)該對(duì)數(shù)據(jù)進(jìn)行驗(yàn)證。在這些組件邊界對(duì)數(shù)據(jù)進(jìn)行訪問能夠?yàn)閿?shù)據(jù)完整性驗(yàn)證和數(shù)據(jù)問題的描述提供一個(gè)重要的附加尺度。假如在兩個(gè)數(shù)據(jù)傳輸點(diǎn)之間檢測(cè)出數(shù)據(jù)錯(cuò)誤，那么有缺陷的組件必定是位于這兩個(gè)傳輸點(diǎn)之間。 系統(tǒng)級(jí)可伸縮性測(cè)試和性能測(cè)試
可以通過創(chuàng)建一個(gè)測(cè)試往返答以下關(guān)于環(huán)境的可伸縮性或者完成情況的問題：
·在系統(tǒng)仍能維持可以接受的響應(yīng)時(shí)間下，最多可以有多少用戶同時(shí)訪問它？
·我的高可用性架構(gòu)是否可以按照設(shè)計(jì)的那樣工作？
·在加入新的應(yīng)用程序或者對(duì)正在使用的應(yīng)用進(jìn)行更新后會(huì)發(fā)生什么情況？
·最初使用時(shí)，系統(tǒng)應(yīng)該如何配置以支持我們所期望的用戶數(shù)？6個(gè)月之后該如何配置呢？一年之后呢？
·我們只能得到部分功能－－設(shè)計(jì)是否合理？
這些問題的答案可以通過一定的測(cè)試技術(shù)來獲得, 包括可伸縮性/負(fù)載測(cè)試、性能測(cè)試、配置測(cè)試、并發(fā)測(cè)試、壓力和容量測(cè)試、可靠性測(cè)試，以及失敗轉(zhuǎn)移（failover）測(cè)試。
在系統(tǒng)容量方面，總體環(huán)境測(cè)試通常是從可伸縮性/負(fù)載測(cè)試開始的。這種測(cè)試方法逐漸增大目標(biāo)環(huán)境上的負(fù)載，直到某些性能要求如最大響應(yīng)時(shí)間達(dá)到極限或者特定的資源被耗盡。這些測(cè)試的目的在于確定事務(wù)處理和用戶容量的上限，它們經(jīng)常會(huì)和其他測(cè)試手段結(jié)合起來以優(yōu)化系統(tǒng)性能。 性能測(cè)試與可伸縮性/負(fù)載測(cè)試相關(guān)，它通過測(cè)試特定的業(yè)務(wù)場(chǎng)景來確定環(huán)境是否滿足所設(shè)定的負(fù)載和事務(wù)組合的要求。（圖 4）
與組件級(jí)配置測(cè)試并行的是系統(tǒng)級(jí)配置測(cè)試，它提供了特定的硬件和軟件設(shè)置下的權(quán)衡信息，同時(shí)也提供了有效的資源分配所需的度量標(biāo)準(zhǔn)和其他信息。
圖 4：性能測(cè)試：系統(tǒng)具有特定的用戶負(fù)載時(shí)能夠按照要求執(zhí)行嗎？
并發(fā)測(cè)試（concurrency testing）（圖 5）剖析了當(dāng)多個(gè)用戶同時(shí)訪問同一段應(yīng)用代碼、同一個(gè)模塊或者數(shù)據(jù)庫紀(jì)錄時(shí)的效果。它鑒別并度量了系統(tǒng)加鎖和死鎖的級(jí)別以及系統(tǒng)中單線程代碼和加鎖信號(hào)的使用。從技術(shù)角度講，并發(fā)測(cè)試可以歸為一種功能測(cè)試，不過它經(jīng)常和可伸縮性/負(fù)載測(cè)試配合使用，因?yàn)樗枰嘤脗€(gè)戶或者虛擬用戶來驅(qū)動(dòng)系統(tǒng)。
圖 5：并發(fā)測(cè)試能夠識(shí)別死鎖和其他并發(fā)訪問問題
壓力測(cè)試（stress testing）（圖 6）在系統(tǒng)達(dá)到飽和（指資源如 CPU、內(nèi)存耗盡等情況）時(shí)來測(cè)試系統(tǒng)以判定其行為是否發(fā)生變更，或者是否會(huì)對(duì)系統(tǒng)、應(yīng)用程序和數(shù)據(jù)產(chǎn)生不利影響。容量測(cè)試（volume testing）是和壓力測(cè)試及可伸縮性測(cè)試相關(guān)聯(lián)的，它可以確定整個(gè)系統(tǒng)能夠處理的事務(wù)容量。通過壓力和容量測(cè)試能夠知道系統(tǒng)分別在處理突發(fā)的訪問量增加或進(jìn)行持續(xù)的大容量活動(dòng)時(shí)所具有的彈性，這不包括那些因?yàn)閮?nèi)存泄漏或者隊(duì)列溢出所引發(fā)的失敗。
圖 6：壓力測(cè)試能夠確定高容量使用時(shí)的效應(yīng)
一旦應(yīng)用環(huán)境開始工作并進(jìn)行了性能優(yōu)化，可以在 75％到 90％的環(huán)境利用率下進(jìn)行一項(xiàng)長(zhǎng)期可靠性測(cè)試（reliability testing），用來發(fā)現(xiàn)任何與較長(zhǎng)的運(yùn)行時(shí)間有關(guān)的問題。在應(yīng)用了冗余和負(fù)載平衡的環(huán)境中，失敗轉(zhuǎn)移測(cè)試（failover testing）（圖 7）分析理論上的失敗過程并測(cè)試和測(cè)量總體失敗轉(zhuǎn)移進(jìn)程及其對(duì)終端用戶的影響。本質(zhì)上，失敗轉(zhuǎn)移測(cè)試回答了這樣一個(gè)問題："假如一個(gè)特定的組件運(yùn)行失敗，用戶還可不可以在最小的中斷下繼續(xù)進(jìn)行訪問和處理？"
圖 7：失敗轉(zhuǎn)移測(cè)試：假如組件X失敗，那么將發(fā)生什么情況呢？
最后，假如在環(huán)境中使用了第三方軟件，或者主機(jī)供給商及其他外部來源所提供的組件，那么 SLA（Service level Agreement服務(wù)水平協(xié)議）測(cè)試則可以用來確保雙方合同規(guī)范中所規(guī)定的終端用戶響應(yīng)時(shí)間，以及流入和流出的數(shù)據(jù)量。一個(gè)典型的協(xié)議通常會(huì)指明在既定時(shí)間范圍內(nèi)的活動(dòng)容量和一個(gè)特定的最長(zhǎng)響應(yīng)時(shí)間。
一旦外部數(shù)據(jù)或軟件到位后，對(duì)這些來源進(jìn)行持續(xù)監(jiān)控是明智的做法，這樣就可以在問題發(fā)生時(shí)快速的采取補(bǔ)救措施，將對(duì)終端用戶的影響降到最小。 與組件級(jí)的可伸縮性測(cè)試一樣，Rational suite TestStudio、Rational TeamTest 和其他類似的工具提供了一些高級(jí)的，多用戶的測(cè)試能力，它們可以用來高效進(jìn)行上述的大多數(shù)或者全部的可伸縮性和性能測(cè)試。進(jìn)入討論組討論。
一個(gè)實(shí)際例子
也許舉一個(gè)例子是說明的最好辦法。請(qǐng)考慮下面的情況：
通過 eRetailer 構(gòu)建一個(gè)公共的 Web 書店，并在它的內(nèi)容層中使用了四種由內(nèi)容提供的 Web 服務(wù)。第一種服務(wù)提供目錄，包括書名，介紹語和作者。第二種服務(wù)提供所有產(chǎn)品的當(dāng)前庫存信息。第三種是價(jià)格服務(wù)器，它提供商品定價(jià)信息，并根據(jù)購買者的所在地提供運(yùn)費(fèi)和稅費(fèi)信息并完成交易。最后一種服務(wù)用來保存用戶檔案和歷史購買紀(jì)錄。 表示層將用戶通過 UI 圖形界面輸入的請(qǐng)求轉(zhuǎn)換成 XML 并發(fā)送給相應(yīng)的內(nèi)容服務(wù)器。接著響應(yīng) XML 就會(huì)通過表示層轉(zhuǎn)換成 Html 并服務(wù)于用戶會(huì)話。每一種內(nèi)容層的服務(wù)都會(huì)根據(jù)需要更新其他的服務(wù)。（參見圖 8）例如，在用戶的歷史購買紀(jì)錄發(fā)生變更時(shí)，價(jià)格服務(wù)器必須更新相應(yīng)的用戶檔案服務(wù)。
圖8：典型的 eRetailer 應(yīng)用程序的訪問點(diǎn)
對(duì)上述的系統(tǒng)來說，一個(gè)端到端測(cè)試策略的起點(diǎn)是分別對(duì)內(nèi)容層的每種服務(wù)同時(shí)應(yīng)用功能測(cè)試和可伸縮性/負(fù)載測(cè)試。XML 請(qǐng)求被提交給每種內(nèi)容服務(wù)，而相應(yīng)的響應(yīng) XML 文檔則被捕捉，從而對(duì)它的數(shù)據(jù)內(nèi)容或者響應(yīng)時(shí)間進(jìn)行評(píng)估。隨著這些內(nèi)容服務(wù)逐個(gè)的集成到系統(tǒng)中，通過向 Web 服務(wù)器提交事務(wù)，功能測(cè)試和可伸縮性/負(fù)載測(cè)試也都可以在集成系統(tǒng)中進(jìn)行。事務(wù)可以貫穿整個(gè)站點(diǎn)進(jìn)行驗(yàn)證，不論是為功能測(cè)試（使用 SQL 查詢）還是為可伸縮性/負(fù)載測(cè)試。
在系統(tǒng)開發(fā)過程中，應(yīng)用于所有訪問點(diǎn)的單個(gè)測(cè)試可以被用來調(diào)協(xié)各個(gè)服務(wù)，以便使其能夠在整個(gè)系統(tǒng)中正常運(yùn)作――無論從數(shù)據(jù)內(nèi)容（功能性）還是性能方面（可伸縮性）來說。當(dāng)前端發(fā)現(xiàn)問題時(shí)（比如,通過瀏覽器），那些原來用來測(cè)試單個(gè)組件的測(cè)試用例和數(shù)據(jù)可以幫助我們快速定位錯(cuò)誤位置。
網(wǎng)絡(luò)建模的優(yōu)點(diǎn)
作為設(shè)計(jì)過程的一部分，無論在硬件獲取之前還是在最初的測(cè)試階段中，為不同的網(wǎng)絡(luò)架構(gòu)進(jìn)行建模都可以擴(kuò)大端到端測(cè)試的優(yōu)點(diǎn)。因?yàn)樗梢詭椭O(shè)計(jì)更有效和低錯(cuò)誤率的網(wǎng)絡(luò)。在部署之前進(jìn)行網(wǎng)絡(luò)基礎(chǔ)設(shè)施的建模可以幫助指出性能的瓶頸所在，以及路由表和配置中的錯(cuò)誤。此外，在測(cè)試中獲取的應(yīng)用程序事務(wù)物證可以輸入到這種模型中，用來識(shí)別和分離應(yīng)用程序的"chattiness" 和基礎(chǔ)設(shè)施中的潛在問題。
結(jié)束語
端到端測(cè)試從一個(gè)概括的質(zhì)量角度對(duì)計(jì)算環(huán)境進(jìn)行測(cè)試和分析。每一個(gè)組件的可伸縮性和功能性在開發(fā)階段和前期的質(zhì)量評(píng)估中都進(jìn)行了單個(gè)測(cè)試和集成測(cè)試。這為開發(fā)的有效性提供了診斷信息，同時(shí)為系統(tǒng)的發(fā)布提供了高度的質(zhì)量保證。端到端測(cè)試為治理當(dāng)今架構(gòu)和分布式計(jì)算環(huán)境的復(fù)雜性提供了一個(gè)全面而可靠的解決方案。 當(dāng)然，在需要做大量的測(cè)試和分析時(shí)，端到端測(cè)試要求有相當(dāng)?shù)膶I(yè)技術(shù)和經(jīng)驗(yàn)來組織、治理和實(shí)踐。但是從商業(yè)角度來說，那些應(yīng)用端到端測(cè)試的組織能夠得到應(yīng)用軟件、系統(tǒng)性能和可靠性上的高度保證。最終，這些組織將獲得質(zhì)量的提高所帶來得種種好處：更好的顧客關(guān)系，較低的運(yùn)營成本和巨大的收入增長(zhǎng)。
在過去的六年中，RTTS 作為 IBM Rational 的伙伴之一，開發(fā)并完善了自己的端到端測(cè)試方法，并與數(shù)以百計(jì)的客戶一起努力確保了應(yīng)用的功能性、可靠性、可伸縮性和網(wǎng)絡(luò)性能。進(jìn)入討論組討論。
