对性能测试更快处理大量的测试数据参数(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.ltesting.net