模板
教程
環境
性能
功能
管理
IT 架構和應用程序的端到端測試
引言：就在不久之前，工業標準測試實踐（針對 C/S 架構的質量問題而發展起來的）仍聚焦于客戶端的前端功能測試或者 服務器 端的后端可伸縮性測試與性能測試。這種"工作上的分離"主要是緣于傳統的 C/S（客戶端/服務器）架構比當前的多層架構和分布式環境相對
引言：就在不久之前，工業標準測試實踐（針對 C/S 架構的質量問題而發展起來的）仍聚焦于客戶端的前端功能測試或者服務器端的后端可伸縮性測試與性能測試。這種"工作上的分離"主要是緣于傳統的 C/S（客戶端/服務器）架構比當前的多層架構和分布式環境相對簡單的事實。在標準的 C/S 架構中，問題要么發生在客戶端，要么就發生在服務器端。
今天，典型的計算環境是一種復雜的，異構的混合環境，其組件和代碼來自遺留系統、自主開發或第三方，或者是標準的組件和代碼（圖示 1）。隨著 Web 的發展，架構的復雜性進一步增加，通常在一個或多個后端數據庫與面向用戶的表示層之間會有一個內容層。該內容層可以提供來自多個服務的內容（其中這些服務集中在表示層中），也可能包含一些原來存在于傳統 C/S 架構前端上的業務邏輯。
這種復雜度的增加，與遺留系統集成和尖端 技術開發交織起來，使軟件及系統問題（包括功能和可擴展性及性能問題）的描述、分析和定位成為軟件系統開發和發布過程中的主要挑戰。此外，隨著 SOAP/XML（簡單對象訪問協議/可擴展性標記語言）成為標準的數據傳輸格式，XML 數據內容的問題對于 .NET 平臺和 J2EE 平臺變得越來越重要。簡單的說，正是現在的架構和計算環境的復雜性，導致了原來的面向 C/S 的測試模式遭到淘汰。
總體質量策略
很顯然，一種新的，有效的質量強化策略對成功的軟件開發和部署是必須的。最有效的策略是將環境中單個組件的測試和環境的整體測試結合起來。在這種策略中，組件級和系統級的測試都必須包含功能測試來確保數據完整性，還要包含可伸縮性和性能測試來確保不同的系統負荷下的可接受的響應時間。
在評估性能和可伸縮性方面，這些并行分析模式能夠幫助您發現系統架構的優勢和缺陷，并在解決與性能和可伸縮性有關的問題時確定必須檢查哪些組件。與此類似的功能測試策略（即全部數據完整性驗證），正顯得越來越關鍵，因為現在數據可能是從分散的數據源派生而來。通過評估組件內外的數據完整性（包括處理過程中的任何功能性的數據轉換），測試人員可以定位每個潛在的錯誤，并使系統集成和缺陷隔離成為標準的開發過程的一部分。端到端架構測試（End to End Architecture Testing）指的是這樣一種概念，它測試計算環境中所有的訪問點，并在組件級和系統級的測試中將功能測試和性能測試整合在一起（見圖2）。
從某種意義上來說，端到端架構測試實質上是一種"灰盒"測試，一種集合了白盒測試和黑盒測試的長處的測試方法。在白盒測試中，測試員能夠訪問底層系統組件并對其有足夠的了解。盡管白盒測試能夠提供非常詳細和有價值的結果，但在檢測集成和系統性能問題方面卻有些"力不從心"。與此相反，黑盒測試需要很少或者完全不需要對系統的內部工作機制的了解，而將注意力集中在終端用戶上――確保用戶能夠及時得到正確的結果。黑盒測試通常并不能指明問題的原因，也不能保證某段代碼已經被執行并且高效運行，而且也不包含任何內存泄漏和類似的問題。通過將白盒測試與黑盒測試進行" 技術嫁接"，端到端架構測試真正實現了取長補短。
對可伸縮性測試和性能測試來說，訪問點包括硬件、操作系統、應用程序數據庫和網絡。對功能測試來說，訪問點包括前端的客戶端，中間層，內容源和后臺數據庫。明白了這些，術語"架構"所定義的就是在環境中組件之間以及組件與用戶之間是如何進行交互的。單純從組件來看的優點和缺陷取決于將它們組織在一起的特定架構。正是一種架構將如何響應作用于它的命令的這種不確定性，使我們需要進行端到端架構測試。
為了有效實現端到端架構測試，RTTS 成功開發了基于風險的測試自動化方法。The Test Automation Process（測試自動化過程，TAP）建立在多年的成功測試實踐基礎之上，利用了最佳的自動測試工具。這是一個迭代的測試方法，包括五個階段：
1、項目評估
2、測試計劃創建和改進
3、測試用例編寫
4、測試自動化、執行和跟蹤
5、測試結果評估
端到端架構測試所要求的單項功能和性能測試是在"測試自動化、執行和跟蹤"階段進行的。如圖 3所示，這個階段被不斷重復，而相應的測試也在每一次迭代過程中得到精化。
組件級測試
很顯然，首先必須開發單個組件，然后才能將它們"裝配"成功能系統。因為組件可以進行早期測試，所以在 TAP 中端到端測試是從組件測試開始的。在組件測試中，隨著環境的建立，適當的測試也分別實施于各個不同的單個組件上。功能測試和性能測試在組件測試階段都相當有價值，它們幫助診斷了在整個環境構建前和構建中的各種缺陷。
組件測試中的功能測試
組件級功能測試驗證了每個組件所執行的事務。這包括了組件或系統所要求的任何數據轉換和組件所處理的事務的業務邏輯的驗證。在應用程序功能的開發中，基礎設施測試（infrastructure testing）驗證并量化整個環境中的數據流量，并以這種方式來同時進行功能和性能測試。數據完整性必須當數據在組件間傳遞時進行驗證。例如，XML 測試在逐個事務地驗證 XML 數據內容，并在需要時驗證正式 XML 結構（元數據結構）。對組件測試來說，諸如 IBM Rational Robot 這樣的自動可擴展的測試工具可以大大的減少用在 GUI 測試和非GUI組件的功能測試上的時間和精力。Rational Robot 的腳本語言支持對外部 COM DDLs 的調用，是非 GUI 對象測試的理想工具。此外，Rational Suite TestStudio 和 Rational Team Test 所附帶的新的 Web 和 Java 測試功能，提供了測試 J2EE 架構和使用 java 語言來編寫測試腳本的附加功能。
組件級可伸縮性測試和性能測試
與這些功能測試并行的是組件級可伸縮性測試，在環境中檢驗每個組件來確定其事務（或者說容量）的限度。一旦有足夠的應用功能來創建業務相關的事務，事務特征測試（transcation characterization testing）就被用來確定業務事務中的各個定量描述，包括消耗的帶寬和后臺 CPU 以及內存的占用率。資源測試（Resource testing）將這個概念擴展到多用戶測試，從而確定應用程序和子系統或模塊中全部的資源消耗。最后，配置測試（configuration testing）可以用來確定哪些硬件、操作系統、軟件、網絡、數據庫或者其他配置上的變更可以優化性能。與功能測試一樣，有效的自動工具如 Rational Suite TestStudio 和 Rational Team Test 所提供的那些工具可以極大地簡化可伸縮性測試和性能測試。在這種情況下，創建、計劃和驅動多用戶測試以及監控資源利用率的能力是有效且成功完成資源測試、事務特征測試和配置測試的基礎。
系統級測試
系統 "裝配"完成后，對環境的整體測試就可以開始了。同樣，端到端架構測試需要對整個環境的功能以及性能/可伸縮性進行驗證。
系統級功能測試
集成是首要考慮的問題之一。集成測試 ( Integration Testing ) 從數據的角度檢查了整體系統是否完成了集成。也就是說，需要互相交互的硬件或軟件組件是否通訊正常？如果是，那么，在它們間傳遞的數據是否正確呢？如果可以，數據應當在系統組件傳送的中間階段被訪問和驗證。例如，當數據被寫到臨時數據庫中時，或者數據在被目標組件處理之前已經存在于消息隊列中時，就應該對數據進行驗證。在這些組件邊界對數據進行訪問能夠為數據完整性驗證和數據問題的描述提供一個重要的附加尺度。如果在兩個數據傳輸點之間檢測出數據錯誤，那么有缺陷的組件必定是位于這兩個傳輸點之間。
系統級可伸縮性測試和性能測試
可以通過創建一個測試來回答以下關于環境的可伸縮性或者完成情況的問題：在系統仍能維持可以接受的響應時間下，最多可以有多少用戶同時訪問它？
我的高可用性架構是否可以按照設計的那樣工作？
在加入新的應用程序或者對正在使用的應用進行更新后會發生什么情況？
最初使用時，系統應該如何配置以支持我們所期望的用戶數？6個月之后該如何配置呢？一年之后呢？
我們只能得到部分功能－－設計是否合理？
這些問題的答案可以通過一定的測試 技術來獲得, 包括可伸縮性/負載測試、性能測試、配置測試、并發測試、壓力和容量測試、可靠性測試，以及失敗轉移（failover）測試。
在系統容量方面，總體環境測試通常是從可伸縮性/負載測試開始的。這種測試方法逐漸增大目標環境上的負載，直到某些性能要求如最大響應時間達到極限或者特定的資源被耗盡。這些測試的目的在于確定事務處理和用戶容量的上限，它們經常會和其他測試手段結合起來以優化系統性能。
性能測試與可伸縮性/負載測試相關，它通過測試特定的業務場景來確定環境是否滿足所設定的負載和事務組合的要求。（圖 4）
與組件級配置測試并行的是系統級配置測試，它提供了特定的硬件和軟件設置下的權衡信息，同時也提供了有效的資源分配所需的度量標準和其他信息。
圖 4：性能測試：系統具有特定的用戶負載時能夠按照要求執行嗎？
并發測試（concurrency testing）
圖 5 剖析了當多個用戶同時訪問同一段應用代碼、同一個模塊或者數據庫紀錄時的效果。它鑒別并度量了系統加鎖和死鎖的級別以及系統中單線程代碼和加鎖信號的使用。從 技術角度講，并發測試可以歸為一種功能測試，不過它常常和可伸縮性/負載測試配合使用，因為它需要多用個戶或者虛擬用戶來驅動系統。
壓力測試（stress testing）
圖 6 在系統達到飽和（指資源如 CPU、內存耗盡等情況）時來測試系統以判斷其行為是否發生變更，或者是否會對系統、應用程序和數據產生不利影響。容量測試（volume testing）是和壓力測試及可伸縮性測試相關聯的，它可以確定整個系統能夠處理的事務容量。通過壓力和容量測試能夠知道系統分別在處理突發的訪問量增加或進行持續的大容量活動時所具有的彈性，這不包括那些因為內存泄漏或者隊列溢出所引發的失敗。
一旦應用環境開始工作并進行了性能優化，可以在 75％到 90％的環境利用率下進行一項長期可靠性測試（reliability testing），用來發現任何與較長的運行時間有關的問題。在應用了冗余和負載平衡的環境中，失敗轉移測試（failover testing）（圖 7）分析理論上的失敗過程并測試和測量總體失敗轉移進程及其對終端用戶的影響。本質上，失敗轉移測試回答了這樣一個問題："如果一個特定的組件運行失敗，用戶還可不可以在最小的中斷下繼續進行訪問和處理？"
最后，如果在環境中使用了第三方軟件，或者主機供應商及其他外部來源所提供的組件，那么 SLA（Service level Agreement服務水平協議）測試則可以用來確保雙方合同規范中所規定的終端用戶響應時間，以及流入和流出的數據量。一個典型的協議通常會指明在既定時間范圍內的活動容量和一個特定的最長響應時間。
一旦外部數據或軟件到位后，對這些來源進行持續監控是明智的做法，這樣就可以在問題發生時快速的采取補救措施，將對終端用戶的影響降到最小。
與組件級的可伸縮性測試一樣，Rational suite TestStudio、Rational TeamTest 和其他類似的工具提供了一些高級的，多用戶的測試能力，它們可以用來高效進行上述的大多數或者全部的可伸縮性和性能測試。
一個實際例子
也許舉一個例子是說明的最好辦法。請考慮下面的情況：
通過 eRetailer 構建一個公共的 Web 書店，并在它的內容層中使用了四種由內容提供的 Web 服務。第一種服務提供目錄，包括書名，介紹語和作者。第二種服務提供所有產品的當前庫存信息。第三種是價格服務器，它提供商品定價信息，并根據購買者的所在地提供運費和稅費信息并完成交易。最后一種服務用來保存用戶檔案和歷史購買紀錄。
表示層將用戶通過 UI 圖形界面輸入的請求轉換成 XML 并發送給相應的內容服務器。接著響應 XML 就會通過表示層轉換成 HTML 并服務于用戶會話。每一種內容層的服務都會根據需要更新其他的服務。（參見圖 8）例如，在用戶的歷史購買紀錄發生變更時，價格服務器必須更新相應的用戶檔案服務。
對上述的系統來說，一個端到端測試策略的起點是分別對內容層的每種服務同時應用功能測試和可伸縮性/負載測試。XML 請求被提交給每種內容服務，而相應的響應 XML 文檔則被捕獲，從而對它的數據內容或者響應時間進行評估。隨著這些內容服務逐個的集成到系統中，通過向 Web 服務器提交事務，功能測試和可伸縮性/負載測試也都可以在集成系統中進行。事務可以貫穿整個站點進行驗證，不論是為功能測試（使用 SQL 查詢）還是為可伸縮性/負載測試。
在系統開發過程中，應用于所有訪問點的單個測試可以被用來調協各個服務，以便使其能夠在整個系統中正常運作――無論從數據內容（功能性）還是性能方面（可伸縮性）來說。當前端發現問題時（比如,通過瀏覽器），那些原來用來測試單個組件的測試用例和數據可以幫助我們快速定位錯誤位置。
網絡建模的優點
作為設計過程的一部分，無論在硬件獲取之前還是在最初的測試階段中，為不同的網絡架構進行建模都可以擴大端到端測試的優點。因為它可以幫助設計更有效和低錯誤率的網絡。在部署之前進行網絡基礎設施的建?？梢詭椭赋鲂阅艿钠款i所在，以及路由表和配置中的錯誤。此外，在測試中獲取的應用程序事務物證可以輸入到這種模型中，用來識別和分離應用程序的"chattiness" 和基礎設施中的潛在問題。
結束語
端到端測試從一個概括的質量角度對計算環境進行測試和分析。每一個組件的可伸縮性和功能性在開發階段和前期的質量評估中都進行了單個測試和集成測試。這為開發的有效性提供了診斷信息，同時為系統的發布提供了高度的質量保證。端到端測試為管理當今架構和分布式計算環境的復雜性提供了一個全面而可靠的解決方案。
當然，在需要做大量的測試和分析時，端到端測試要求有相當的專業 技術和經驗來組織、管理和實踐。但是從商業角度來說，那些應用端到端測試的組織能夠得到應用軟件、系統性能和可靠性上的高度保證。最終，這些組織將獲得質量的提高所帶來得種種好處：更好的顧客關系，較低的運營成本和巨大的收入增長。
在過去的六年中，RTTS 作為 IBM Rational 的伙伴之一，開發并完善了自己的端到端測試方法，并與數以百計的客戶一起努力確保了應用的功能性、可靠性、可伸縮性和網絡性能。歡迎訪問 RTTS 的網站：www.rttsweb.com。.
參考資料
您可以參閱本文在 developerWorks 全球站點上的 英文原文。
作者簡介
Jeffrey Bocarsly,RTTS,自動化功能測試部門經理。
Johanthan Harris，RTTS，可伸縮性測試部門經理。
Bill Hayduk，RTTS，專業服務部門主管。
原文轉自：http://www.anti-gravitydesign.com
