Compartilhar via


Integrate Data Collector Data into Load Test Analyzer (Tables View)

With Microsoft Visual Studio 2010 Ultimate, you can write a custom Data Collector to collect diagnostic data on Agents or machines that are part of System Under Test. The data collected can be files, high-level summary statistics, or server activity logs from the database on a Web server. These data can be integrated into the Load Test Database and viewed in the Load Test Analyzer when test completes.  Together with the information collected by a Load Test, they can be used to diagnose performance issues in your Web applications.

Given a very simple example here, I collected the row count of my Order table in the Web server’s database before and after a load test run. As shown in the following screenshot, the counts were displayed in a table in post run.

image

To implement this, only three major steps are involved.

Step 1 – Create a data collector.

Step 2 – Install the data collector.

Step 3 – Enable/configure the custom data collector in the test project.

I will go through the steps to create a sample data collector in a separate post. In this post, I will highlight the points closely related to Load test that you should know before getting started.

1. Supported Data Format – Tabular data in XML

In order to integrate your report into Load Test Analyzer, the data collector needs to write the report data to a table in XML format.

2. Supported data types in the XML table.

Bit

Byte[]

Int16, Int32, Int64

double, float

String

DateTime

3. Data collector basics

3.1 Data Collector Events

Your data collector can register events in the following table to write log messages and send files back to the client (VS).

Event Description Notes
SessionStart Start of your test run You test run may contain several test types, e.g. one Load test and five Unit test. This event will be fired once for the entire run.
SessionEnd End of your test run  
TestCaseStart Start of each test in the test run If you test run contains only one Load Test, this event will be fired once when the Load test is started.
TestCaseEnd End of each test in the test run If you test run contains only one Load Test, this event will be fired once when the Load test is complete.

Remember, ONLY log/data files sent back through the TestCaseStart and TestCaseEnd events can be integrated into the Load Test database.

Log/data files sent back through the SessionStart and SessionEnd events are listed in the Run Results Summary window. Under section Collected Files.

image

3.2 Data Collector Events Logs

You can log warning/error messages in the following events

Event Description
SessionStart Log messages will be displayed in the Results Summary window
SessionEnd Log messages will be displayed in the Results Summary window
TestCaseStart Log messages will be displayed in the Errors table in Load Test Analyzer

3.3 Data Collector configuration

If any configuration is required for the collector, you need to create an App.config file.

Data collector can be enabled through the Test Settings dialog as shown in the below screenshot.

image

Data collector can be configured if you click on the Configure button. Here you have two choices, you can create a custom UI editor, or you can use a generic XML editor and just do text editing. The later will be covered in Create a Simple Data Collector to Integrate Data into Load Test Analyzer.

As I mentioned in the beginning, what I listed above is just a high-level summary for you to get started. After going through these briefly, you can try the sample collector in my post and start to write your own. For more information on Custom Data Collectors, please read this MSDN page for details.

Comments

  • Anonymous
    August 24, 2011
    When I create something like mentioned in your post, the Visual Studio actually creates tables in the SQL DB. for example, a table per run_id is created something like below: LoadTestLogData_Run40_Log0 (where 40 is the LoadTestRunID) Also, why VSLT stops users from creating results into Tables View at OnSessionEnd? Is there any good reason for this? Thanks, Nanda