對性能測試更快處理大量的測試數據參數(2)

　　當該測試啟動時，測試之中的 Username 變量就會由運行時通用代碼的執行，來替換返回的值。

　　重點：

　　插入變量論斷非常關鍵，它可以確保在退出通用代碼之后，全局變量的論斷發生時，通用代碼之中全局變量的更新值仍然能夠發揮作用。

　　根據這種操作，可以避免較大的數據匯文件規模以及相應的 I/O 操作。這還可以改進生成測試負載的 Rational Performance Tester 代理的性能，因為與從硬盤中操作相比，從內存中獲得數據匯值更快，因為這可以減少硬盤讀取的延遲性。

　　Note:

　　對于字段之中的“Visible”來說，如果測試腳本在日程安排的層次之上進行循環，那么您可以選擇 All tests for this user，如果循環是測試腳本 之內完成，那么您可以選擇 This test only 選項，如圖 6 所示。

　　圖 6. 測試 Username 變量可視性的不同層次

　　在一些場景之中，對于許多迭代來說，有很大的可能會重復使用到一些測試數據，您最好將數據匯條目(行條目)存儲在一個變量字符串數組中，并從該數組中讀取值，然后在運行時進行替換。

　　這種方法可以避免由于硬盤延遲所導致的性能降級，對數據匯文件重復數據讀取 I/O 操作。相反，它會從物理內存中讀取數據，訪問起來更快，這樣使得 Rational Performance Tester 代理的性能有較大的提高。

　　回頁首

　　采用大量數據匯的另外一種好的實踐方法

　　當一個需要多個值(通常 > 30-40 值)參數的測試場景出現時，您最好不要使用大量的數據匯文件。相反，使用整個測試數據被分開的許多個小型的數據匯文件，并由變量進行組織，在運行時設置參數。

　　當您從數據匯中讀取測試數據時，這有助于增加 I/O 并發操作，因此顯著改善 Rational Performance Tester 代理的性能。

　　盡管對于數據參數最好使用通用代碼，那么在任何合適的時候，您都應該謹慎選擇該選項。這是因為通用代碼會創建大量的負載(主要是對進程使用和內存)，這取決于代碼中執行邏輯的復雜性，以及通用代碼論斷的數量。

　　對于許多通用代碼，協同，等等中已經大量存在的腳本，盡可能避免地使用 Content 確認點，因為使用它們，將會從服務器端分析整個響應過程以確認特定的標準。對于有限長度的字符串來說，分析整個響應過程將會消耗相當可觀的 CPU 資源以運行進程。您應該盡可能地使用 Response Code 或者 Title 確認點。

原文轉自：http://www.kjueaiud.com