ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

Issue with DevTest- ALM Integration(Bulk Records in Excel) Test Hanging

book

Article ID: 133385

calendar_today

Updated On:

Products

CA Application Test

Issue/Introduction

Running DevTest ALM integration and it was successful. We have framework created for Automation Testing in DevTest and when trying with 5 rows data in excel and creating mar and giving that mar in ALM it's working fine. But when we are trying with more that like 20-25 rows in excel, ALM is getting timed out after 10 min and test is not successful. While checking the test in Portal it's going in hung state.

Cause

Explaination of  the way the parameter "dt_testRunTimeout" which is the crux to this issue works.


dt_testRunTimeout - The amount of time in milliseconds to allow the DevTest test to run.


This parameter whose unit is milliseconds, control the test execution in Devtest. This parameter is used by the ALM Test Runner. If the test execution in Devtest goes beyond this prescribed value, the test execution cycle in ALM ceases to wait for Devtest to finish and throws an error that typically states the cause "Test took too long to finish. Test Run Timeout is XYZ"


How does this parameter takes effect ?


Can set this value either by setting a value for the attribute dt_testRunTimeout in file DevTestConnection.properties. The unit is milliseconds


Can also set the value through the script, however if the value is already present in DevTestConnection.properties file, the value provided in the file takes precedence. If wanting to pass the value only through the script, then the property dt_testRunTimeout must be commented out in the file DevTestConnection.properties


Would typically use the following construct to pass the value in script:


//To set 20 minutes of Test Run Timeout. Make sure to comment out the entry dt_testRunTimeout in DevTestConnection.properties


lisa.SetTestRunTimeout(1200000);


In case if neither set the value in DevTestConnection.properties, nor pass it through the script, then a default value of 10 minutes is used.


Root cause:


The Test Run timeout value was mentioned in DevTestConnection.properties as 1000000 milliseconds or 1000 seconds or 16 Minutes 40 seconds. The same value was passed on using the script as well and as explained before.


The test execution couldn't complete within the duration of 16 minutes and 40 secodns, hence the ALM Test Runner stopped at the top of the time box.

Environment

Release : 10.2

Component : CA Application Test

Resolution

Since your test run needs more time to complete, here is what would suggest:


1. Understand the time it takes for DevTest to complete the test run.  Run the test from DevTest to get an idea of how long its going to take


2. Arrive at a Test Run Timeout value in milliseconds based on observation in step 1. Add an additional 10% time as buffer


3. Comment out the entry dt_testRunTimeout in file DevTestConnection.properties


4. Change the ALM test script to use the new Test Run Timeout value computed in step 2.


lisa.SetTestRunTimeout(<NEW TIMEOUT VALUE IN MILLISECONDS>);


In addition to increasing the value of Test Run Timeout, please add the following construct to get TRACE level logging. Add this immediately after init step in the script.


VB Script: (provide the syntax as shown below)


        lisa.Init TDConnection, TDOutput


        lisa.setTrace true


        lisa.Reload ThisTest


Javascript: (provide the syntax as shown below)


        lisa.Init(TDConnection, TDOutput);


        lisa.setTrace("true");


        lisa.Reload(ThisTest);

       

This issue has nothing to do with the response timeout and there is no need to alter this value. The default value of 100 seconds is good enough.


Do not worry about response timeout. Suggest to comment out setting response timeout value in both properties file and the script.



Able to run the test successfully by not considering the warnings as errors.