Load Testing Salesforce Apps
CRM functionality is so integral to many business workflows that writing a Salesforce app is often cheaper and faster than starting from scratch. Why reinvent the wheel with 50%+ of the functionality you need is already in Salesforce? But just like a 100% custom app, Salesforce apps must be tested for performance, not just functionality, especially when integrating into an existing customer back-office or 3rd party system. And Salesforce is one of the more difficult platforms to test because of the complicated field naming conventions typical of auto-generated front ends.
The first challenge is just the sheer overall complexity of a Salesforce app. The last app we tested had around 40,000 separate fields, most needing to be updated dynamically. Often something this complex would require a browser-driven approach, but load testing through selenium still doesn’t collect the breadth of information you get with an HTTP-based approach. To overcome that, we created custom configurations that handle most of the complexity automatically. The downside was running the auto-correlation process took between 15 minutes and several hours, depending on the test case’s length and the computer’s processing power.
The biggest challenge is that Salesforce uses dynamically changing field names when writing values from forms. Here is a typical example of how Salesforce handles writing parameters via a JSON POST:
The name part of the JSON name/value pairs are in the format “a0Y760000…”, and they are different for every user and every field. This is likely a design choice to increase parallelization when writing into the database at scale, but it makes simulating this behavior in a script quite difficult. Upon playback, each virtual user must parse each of the field names and values, and correlate the updated field names with the existing form defined in the test case. The field names are defined earlier in the HTML, and always use the format:
“Id”:”a0Y76000002HH5aEAG”
This means location context inside a larger JSON string must be used to determine exactly which dynamic field name “Id” refers to.
In addition to dynamically named fields, there are 1,400+ fields which dynamic values that need configuring. The most important ones include token, aura.token, jwt, fuid, message, etc. To use just one example, “token”, it is part of a JSON name/value pair, and thus is delimited by a double-quote. The regular expression for parsing would then be “token”:”([\.0-9a-zA-Z_=-]++)” as shown below:
It’s possible to parse Salesforce name/value pairs by simply looking for the typical JSON pattern of “name”:”value” without actually checking with is within the parentheses, but that leaves open the possibility that you’re actually parsing the wrong field, which is definitely possible with dynamic field names changing along with the values. It’s much safer to ensure the value being parsed matches the general pattern of what is expected.
This is just a general overview of Salesforce load testing via HTTP. While the screenshots are specific to our load testing software, the general approach is needed with any load-testing software.