基于 Rational Performance Tester 的持續性測試

　　持續性測試(Long Run)在整個測試過程當中起著舉足輕重的作用，通常被安排在測試的后期來進行。此時，軟件或解決方案的基本的功能已經穩定，但是，有很多重要的問題，比如資源泄漏等都有可能在持續性測試中被發現。因此，持續性測試一般是軟件發布之前的最后一道安全保障。Rational Performance Tester(RPT)是 IBM 性能測試的工具，具有靈活的基于 Http 的錄制與回放功能，而且有著很好的用戶負荷管理功能，又提供了大量的 API 可以方便使用者自定義附加功能。本文就介紹了利用 Rational Performance Tester 來進行持續性測試的一些方法和技巧。

　　1. 持續性測試介紹

　　1.1 持續性測試(Long Run)的基本概念

　　持續性測試(Long Run)是被測產品或解決方案上線之前的簡單性能測試階段，模擬一定程度的并發用戶進行基本的操作，并持續超過 24 小時(持續時間可以依據產品和解決方案的非功能性需求而定)，來測試產品或者解決方案的穩定性，包括使用資源的穩定性，響應時間的穩定性等，是屬于性能測試的一部分，通常發生在性能測試接近尾聲的時候。持續性測試很難由手工來完成，通常需要借助自動化測試工具 如 IBM Rational Function Tester 等，或者借助性能測試工具 如 IBM Rational Performance Tester 等來完成。

　　持續性測試是眾多測試類型中的一種，在持續性測試中，實際客戶的慣用操作被模擬，通過長時間的執行來檢測程序運行所占用的系統資源是否穩定(系統資源包括物理內存、CPU、硬盤使用率、網絡流量、數據庫連接數、網絡連接數等)。在實際的測試過程中，通常使用高于生產環境的等價用戶負荷來進行持續性測試從而爭取更早的發現問題。持續性測試的執行時間會根據待測軟件或解決方案的復雜程度和應用程度不同而不同。但通常不會少于 1 天。

　　持續性測試被安排在軟件測試流程中的后期，此時軟件的功能已經趨于穩定，不會有太大的變動。同時，持續性一旦被執行，就需要等待他執行完預計的時間或者直到由于軟件問題導致測試腳本無法繼續執行下去。

　　1.2 持續性測試的重要性

　　應用軟件或者解決方案當中有些問題是無法在功能或者系統測試中被發現的，比如少量的系統資源泄漏或者長時間運行系統的不穩定性等問題。在功能或者系統測試中，由于側重點的不同，同一個功能點也許只被驗證幾次，但是在持續性測試中，同一個主要功能點可能被重復千次甚至萬次。所以，細微的資源占用問題也將會被放大。這就是在任何的產品上線之前都需要通過持續性測試來保證系統主要功能的正確性和持久性。

　　當然，通過持續性測試并不能發現隱藏在程序代碼中的所有問題，因為持續性的測試用例基本會選取用戶經常使用的或者比較重要的操作用例。因此，一些異常流程導致的資源泄漏等問題將不會被發現。但是持續性測試會通過最大程度的模擬產品上線后用戶的操作來盡量發現隱藏在軟件中的細微資源泄漏等問題。

　　1.3 執行持續性測試的工具

　　根據持續性的測試特征可以選取不同的測試工具來執行測試用例，可以選擇 RFT(Rational Function Tester)，Watir 等自動化測試工具，也可以選擇 RPT 等性能測試工具，也可以自己開發程序或者腳本來執行持續性的測試。

　　相比于 RFT 等自動化測試工具，RPT 具有更好的多用戶負荷管理功能和基于 Web 的頁面響應時間等性能結果分析，更適應于基于 Web 應用的多用戶系統持續性測試的執行。

　　本文就以一個基于 Web 的應用為例，為大家介紹如何使用 RPT 來設計，開發和執行持續性測試。

　　回頁首

　　2. 設計基于 RPT 的持續性測試用例

　　在 RPT 當中，測試用例的基本單元是通過錄制而生成的測試項。將測試項按照不同的順序組織起來，并添加一些分支或者循環的過程控制從而生成測試調度。通過 RPT 提供的數據池的功能來完成多用戶各自的數據存儲。同事還可以在測試項中添加自定義的代碼來實現特定的功能。

　　通過執行測試調度來執行持續性測試，因此在測試調度中的循環控制次數需要大到不會在指定的執行期間之內結束，通常選用無限循環模式。

　　實際的基于 Web 的應用大多都是多用戶分角色的，因此，在設計基于 RPT 的持續性測試用例時，有以下需要注意的地方。

　　將包含在持續性測試范圍內的功能點按照不同的用戶角色進行分類，盡量設計端到端的測試用例來模擬用戶在生產環境上的應用。在設計過程中，將功能點分散到不同的用戶角色上，使所有持續性測試范圍內的功能點都被用例覆蓋到。

　　劃分測試項。測試項是 RPT 測試用例中的最小單位。一個測試項應盡量完成最少但完整的功能，如果一個測試項完成的功能太多，太復雜則會導致測試項腳本非常大，而且還不方便維護，

　　根據不同的用戶角色來區分 RPT 中的用戶組，每一個用戶組由多個測試項組合而成，完成為該用戶設計的測試用例中包含的多個功能。

　　不同用戶之間在測試中用到的數據通過 RPT 數據池來獲取，這樣保證了用戶運行時的數據與控制邏輯相分離，可以大大的減少測試腳本的維護成本。

　　在持續性的測試腳本執行期間并不需要很高的吞吐量，因此，要適量的在測試項之間添加延遲，來緩解程序服務器的壓力。

　　如果由于用戶過多導致 RPT 服務器的系統資源緊張，需要將部分的用戶分散在 RPT 代理上執行來分擔 RPT 服務器的壓力，避免由于測試工具服務器的資源問題影響測試結果數據。

　　完成了 RPT 中測試項的劃分，測試調度的設計和測試用數據的設計之后便可以開發基于 RPT 的測試腳本了，下一章便介紹了在開發基于 RPT 的持續性測試用例中的經驗總結。

　　回頁首

　　3. 開發基于 RPT 的持續性測試用例

　　3.1 分功能段錄制腳本

　　通常使用 RPT 錄制測試腳本時，我們會將整個的場景錄制在同一個腳本中，復雜的腳本會包含幾十個甚至上百個頁面。這樣，RPT 會建立起頁面間數據復雜的關聯引用，即不利于維護，又會造成有時無法正?；胤诺碾[患。

　　為了更好的復用測試腳本，可以分段錄制業務場景的腳本，然后組裝起來覆蓋所有需測試的業務場景，他們之間的數據關聯用自定義代碼實現。下面是一個實例場景，分為三小部分(登錄，業務邏輯操作，注銷)，錄制成三個獨立的腳本。操作步驟如下：

原文轉自：http://www.ibm.com/developerworks/cn/rational/r-cn-rptlongrun/index.html