Test the performance of your Salesforce web applications using TruClient

hilale Honored Contributor.
Honored Contributor.
1 0 1,984

(This post was written by Michal Barak from the Performance Protocols team)

 

michalBarakS.png 

 

 

 

 

TruClient is a powerful browser-based technology for automation and performance testing that caters to all user types. It provides simple record and replay in an automatic manner, enabling even the nontechnical business users to participate in the testing process. It also includes a wide set of features for script development, which offer more layers for extending, synchronizing, and stabilizing the automatic script. These include capabilities for DOM object search, various synchronization methods, a rich set of API utilities, and more.

Salesforce is the world’s #1 customer relationship management (CRM) platform. It provides complex, modern and rich applications that require a powerful tool to handle the complexity of developing automatic scripts for performance testing.

In our last Salesforce web application testing session with TruClient, we made some script enhancements to make the scripts more robust and accurate. In this article, you can find some great troubleshooting tips to make scripting a faster and easier process.

 

Tip #1: How to handle timeouts and some cases of “Object not found”

There are two common use cases:

1) A timeout error occurs when TruClient has not received the event that should end the step execution, (for example, network complete, document loaded) within a specified period of time (the default is 180 seconds).

2) “Object not found” may occur when a step finishes its execution too soon. Usually there are still active downloads that are not yet complete, or the next page is still being processed when the next step starts to replay. In these cases, the relevant object is not loaded and “Object not found” error will be returned.

For example, the step for pressing the login button of the Salesforce application might end while the application is still in loading state.  

Solution: Use an “Object Exists” end event

In some use cases, it’s crucial to wait for an object to appear on the screen before the next step starts.

Instead of using an automatic end event, you can use “Object Exists” as the end event to ensure the next step does not start until a specific object is loaded and visible on the screen.

With an “Object Exists” end event, you manually select an object. While the selected object does not have to be the object in the next step, it is recommended to select one that is unlikely to be affected by changes to the application flow or code. Only when TruClient identifies this object, does the step end and the next step start. This ensures the step ends only when the application is in the appropriate state and can continue the replay.


ObjectExist.png--Example: using the Object Exists end event for the login action step—

 

 

  You can read more about this in the TruClient Help Center: Understanding End Events

 

Tip #2: How to handle short transaction response time (TRT)
One possible reason for getting shorter transaction response time than expected is because some AJAX requests are excluded from the transaction response time measurements. Salesforce applications use background AJAX requests that are fired periodically. If the interval between requests is too long (usually more than 150 milliseconds), requests fired after this interval will not be included in the TRT.

Solution: Increase the network threshold

Where the step end event is “Step network completed” or “Step synchronous network completed,” TruClient tracks the request and response traffic until each request receives a response. After TruClient has identified that all requests have been fulfilled, it starts a timer for the “End-of-network identification timeout” (defined in Runtime Settings > Replay). In case there is no network during this time period, the step replay ends and TruClient continues to the next step.

The default value of “End-of-network identification timeout” is 150 milliseconds. In some cases, this is insufficient because requests (mostly AJAX) keep being sent from the browser after a period of no traffic. If you want to include these requests in the transaction response time measurements, you should increase the “End-of-network identification timeout” value. Keep in mind that “End-of-network identification timeout” is considered as wasted time of the transaction, and so it does not affect the transaction accuracy.

 

Network.png-- End-of-network identification timeout runtime setting—

Tip #3: Handle network timeout and Long TRT

If not all responses have arrived before step timeout, the step fails with a network timeout and displays a list of open requests. This might happen for steps that are configured to wait for responses that have a “Step network completed” or “Step synchronous network completed” end event.

Solution: Use a network filter

TruClient has an API, TC.addNetworkFilter (available from LR 12.53 patch 4), to filter network requests that are waiting for a response. This does not mean that the request will not occur—just that TruClient will not wait for the response for this filtered request.

You might want to filter some of the requests where the step has a “Step network completed” or “Step synchronous network completed” end event. Perhaps it is not relevant for the transaction and you want to exclude its download time from the TRT. It could also be useful when you get network timeouts on some requests.

Note: We recommend using the Generic API Action step for TruClient API instead of using the API directly which we plan to discontinue in future versions. For example, use Generic API Action with the parameters: Category Name – TC, Method Name - addNetworkFilter.

There might be other background traffic in Salesforce apps not relevant for the TRT which you can also filter out.

 

NetworkFilter.png--Example: filter AJAX requests with the https://*/cometd/replay/36.0 format--

With a Generic API Action with TC, addNetworkFilter parameters, you can include or exclude requests for URLs with particular patterns. Filters can be applied to AJAX requests only, Synchronous HTTP requests only, or both.

You can also use a Generic API Action with TC.startLogRequests parameters. This can be useful if you want to see a list of the requests. From the moment the script executes this method, TruClient logs the requests for steps that have a Step network completed or Step synchronous network completed end event, or that do not have any end event. (Not set yet)

 

You can get more information about all of these features from the TruClient Help Center.

 

 

 

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.