IT架構和應用程序的端到端測試

   就在不久之前，工業標準測試實踐（針對 C/S 架構的質量問題而發展起來的）仍聚焦于客戶端的前端功能測試或者服務器端的后端可伸縮性測試與性能測試。這種"工作上的分離"主要是緣于傳統的 C/S（客戶端/服務器）架構比當前的多層架構和分布式環境相對簡單的事實。在標準的 C/S 架構中，問題要么發生在客戶端，要么就發生在服務器端。

  引言

  就在不久之前，工業標準測試實踐（針對 C/S 架構的質量問題而發展起來的）仍聚焦于客戶端的前端功能測試或者服務器端的后端可伸縮性測試與性能測試。這種"工作上的分離"主要是緣于傳統的 C/S（客戶端/服務器）架構比當前的多層架構和分布式環境相對簡單的事實。在標準的 C/S 架構中，問題要么發生在客戶端，要么就發生在服務器端。

  今天，典型的計算環境是一種復雜的，異構的混合環境，其組件和代碼來自遺留系統、自主開發或第三方，或者是標準的組件和代碼（圖示 1）。隨著 Web 的發展，架構的復雜性進一步增加，通常在一個或多個后端數據庫與面向用戶的表示層之間會有一個內容層。該內容層可以提供來自多個服務的內容（其中這些服務集中在表示層中），也可能包含一些原來存在于傳統 C/S 架構前端上的業務邏輯。

  這種復雜度的增加，與遺留系統集成和尖端技術開發交織起來，使軟件及系統問題（包括功能和可擴展性及性能問題）的描述、分析和定位成為軟件系統開發和發布過程中的主要挑戰。此外，隨著 SOAP/XML（簡單對象訪問協議/可擴展性標記語言）成為標準的數據傳輸格式，XML 數據內容的問題對于 .NET 平臺和 J2EE 平臺變得越來越重要。簡單的說，正是現在的架構和計算環境的復雜性，導致了原來的面向 C/S 的測試模式遭到淘汰。

  圖1：現在典型的多層架構

  總體質量策略

  很顯然，一種新的，有效的質量強化策略對成功的軟件開發和部署是必須的。最有效的策略是將環境中單個組件的測試和環境的整體測試結合起來。在這種策略中，組件級和系統級的測試都必須包含功能測試來確保數據完整性，還要包含可伸縮性和性能測試來確保不同的系統負荷下的可接受的響應時間。

  在評估性能和可伸縮性方面，這些并行分析模式能夠幫助您發現系統架構的優勢和缺陷，并在解決與性能和可伸縮性有關的問題時確定必須檢查哪些組件。與此類似的功能測試策略（即全部數據完整性驗證），正顯得越來越關鍵，因為現在數據可能是從分散的數據源派生而來。通過評估組件內外的數據完整性（包括處理過程中的任何功能性的數據轉換），測試人員可以定位每個潛在的錯誤，并使系統集成和缺陷隔離成為標準的開發過程的一部分。端到端架構測試（End to End Architecture Testing）指的是這樣一種概念，它測試計算環境中所有的訪問點，并在組件級和系統級的測試中將功能測試和性能測試整合在一起（見圖2）。

  從某種意義上來說，端到端架構測試實質上是一種"灰盒"測試，一種集合了白盒測試和黑盒測試的長處的測試方法。在白盒測試中，測試員能夠訪問底層系統組件并對其有足夠的了解。盡管白盒測試能夠提供非常詳細和有價值的結果，但在檢測集成和系統性能問題方面卻有些"力不從心"。與此相反，黑盒測試需要很少或者完全不需要對系統的內部工作機制的了解，而將注意力集中在終端用戶上――確保用戶能夠及時得到正確的結果。黑盒測試通常并不能指明問題的原因，也不能保證某段代碼已經被執行并且高效運行，而且也不包含任何內存泄漏和類似的問題。通過將白盒測試與黑盒測試進行"技術嫁接"，端到端架構測試真正實現了取長補短。

  圖2：端到端架構測試包含所有訪問點的功能測試及性能測試

  對可伸縮性測試和性能測試來說，訪問點包括硬件、操作系統、應用程序數據庫和網絡。對功能測試來說，訪問點包括前端的客戶端，中間層，內容源和后臺數據庫。明白了這些，術語"架構"所定義的就是在環境中組件之間以及組件與用戶之間是如何進行交互的。單純從組件來看的優點和缺陷取決于將它們組織在一起的特定架構。正是一種架構將如何響應作用于它的命令的這種不確定性，使我們需要進行端到端架構測試。

  為了有效實現端到端架構測試，RTTS 成功開發了基于風險的測試自動化方法。The Test Automation Process（測試自動化過程，TAP）建立在多年的成功測試實踐基礎之上，利用了最佳的自動測試工具。這是一個迭代的測試方法，包括五個階段：

  項目評估

  測試計劃創建和改進

  測試用例編寫

  測試自動化、執行和跟蹤

  測試結果評估

  端到端架構測試所要求的單項功能和性能測試是在"測試自動化、執行和跟蹤"階段進行的。如圖 3所示，這個階段被不斷重復，而相應的測試也在每一次迭代過程中得到精化。