Microsoft Dynamics NAV Performance Testing 24. May 2016 Max Kleyzit Performance Testing (0) Summary: Learn how to record any Microsoft Dynamics NAV 2015 and 2016 test scenario and correlate your performance testing script without writing a single line of code. Microsoft Dynamics NAV is a premium ERP solution. Like other enterprise systems, it requires in-depth load testing to successfully plan, deploy and maintain user experience. In this post we will learn how to record any Dynamics NAV test scenario in StresStimulus and then configure it to run a load test using the Comprehensive Correlation Method. The benefit of this approach is that it fixes every correlation error without manual scripting. All test configuration steps are performed via UI which makes it easier to use. By following the steps in this blog you will be able to record and correlate virtually any scenario in Microsoft Dynamics NAV 2015 or 2016 without writing a single line of code.The step-by-step process described below for load testing Microsoft Dynamics NAV is also shown in the following video. NAV load testing environment and approach Our performance testing environment included a Microsoft Dynamics NAV 2016 instance with Web Client. We recorded multiple user scenarios on an NAV demo application and then configured the scripts using the methodology described below. While configuring every scenario required creating different parameters, we used only a limited number of patterns for creating extractors and parameters. In the end, all correlation errors were fixed, scripts ran successfully, and application transactions were completed correctly. Base on that, we believe that knowing and using such patterns will help to correlate virtually any Navision test case. The discovered patterns are described below so you can replicate them when you configure your test. Test configuration process Initially every recorded Dynamic NAV test script can have any number of correlation errors. To fix them we will go through a repetitive process during which we will make incremental improvements to the script. In every iteration of the process, we will fix at least one error by creating the necessary correlation rules and will continue until all errors are cleared. Here are the main steps of the process: Record the user scenario which you want to load test. Start the iterative process where at the beginning you verify the script by replaying it once to identify all remaining errors. Analyze the first error to find dynamic values in the request. On the first iteration of the process, record the same test case again to help find dynamic values. Create an extractor. Create the first parameter and as many of its clones as necessary. Proceed to the next iteration of the process by verifying the test script to make sure that at least one error is resolved. If no more errors are left, the test correlation is complete. Finding dynamic values After you record your test case, run Verify to discover all of the errors and critical warnings that occurred when a VU tried to access Dynamics NAV pages. Do not be alarmed by the long list of yellow warnings, as this is expected. In the following steps, we will describe how to resolve all of these errors by creating missing extractors and parameters. Begin by right-mouse clicking on the first warning and selecting Highlight non-correlated dynamic values. The Select a Session to Compare dialog will appear. We will use the Double-Recording Technique to find dynamic variables. Before fixing the first error, you will need to re-record the exact same test case once more to enable StresStimulus to automatically detect dynamic values by comparing two recorded scripts. Try to keep the second recording as close to the first recording as possible. For example, if the first recorded test case was adding a new record with several fields, the second recording should add the same record with the same fields. If adding the exact same record is not possible due to system constraints, then add a record with as little differences as possible to satisfy the system’s constraints. For example, if a new customer record has a unique name constraint, then during the second recording, change the name of the customer but the address field should match the first recording’s. Once the second recording is complete, it will be used to fix all subsequent errors. Click Record New and the recorder will appear. All of the fields will be pre-filled so just click Next through the steps until you reach Record. Navigate through your test, but do not worry about creating transactions as this test case will be deleted after correlation is complete. Once your scenario is re-recorded, you will return to the same verify tree. Right-mouse click on the first warning and again select Highlight non-correlated dynamic values. The Select a Session to Compare dialog will appear again, but this time in the Test Case drop-down, the re-recorded test case name and the corresponding session should be pre-selected. If it is not, then select it from the list and click OK when ready. Note: The re-recorded test case name is <xxx>-Compare. The corresponding sessions will likely have different session numbers because while the re-recorded test case is similar, it’s almost never identical. In the appeared Dynamic Val. Tab, all of the dynamic values that are not already correlated will be highlighted. Some, but not all of them, should be correlated. After load testing multiple different user scenarios, we discovered the following two rules as to what should and should not be correlated: All dynamic values that need correlation in NAV are expressed as 3-5 digit hexadecimal numbers. Highlights that are not hexadecimal numbers can be ignored. Highlights appearing in the “cookie” or “referrer” header can be ignored as well. Creating an extractor Select a dynamic value, right-click and select Find selection in responses. A good rule of thumb is, when searching for suspected values in responses, select only alphanumeric characters in the search as they are less likely to be encoded. The responses which contain the value will be highlighted on the test case tree on the left. Since all of the highlighted sessions precede the request that we need to correlate, you can create an extractor from any of them. Right-mouse click it and select Create Extractor. The extractor creation dialog will appear. The dynamic value that we need to extract will be highlighted in the response window. What we learned about Dynamics NAV extractors After performance testing multiple different user scenarios, we discovered that hexadecimal dynamic values in Dynamics NAV responses appear in two forms: The hexadecimal value is part of a JSON string. Either the entire response is a JSON string, or The response includes a JSON string surrounded by HTML, JavaScript or other JSON strings. The hexadecimal value is a part plain HTML. 1a. If the response is pure JSON, then the Json Jpath query extractor type will be automatically selected. Simply select the dynamic value and click Create JPath Query on the toolbar or the context menu. The JPath Query field will be automatically populated with the required search expression. Then give the extractor a unique name. Verify that the extractor returns the desired value by clicking Verify Extractor on the toolbar and then Save and Close the extractor. 1b. If the dynamic value is inside a JSON string but the response is not entirely JSON, then the Text Delimited extractor type will be automatically selected. You should extract the JSON that surrounds the selected value first and then create a second extractor from the first extractor. First find and note the text that surrounds the JSON string that contains the dynamic value. The JSON string surrounded by a pair of brackets is usually positioned as a javascript function parameter. For example: DN.BrowserLogicalClient.get_instance().register([<Long Json String>]);The suggested text delimiters are highlighted. Select the left delimiter, right-click and select Set Before Text. Then find the first instance of close parenthesis that occurs after the selected value, highlight it, along with the close brace that precedes it and the semicolon that follows ]);, right-click and select Set After Text. Click Verify Extractor to make sure that the extractor returns pure JSON, give it a unique name and then click Save & Close. The new extractor will appear on the test case tree. Right-click the newly created extractor and select Create Extractor. Continue creating the second extractor as if it were pure JSON (described above). 2. If the dynamic value is found in plain HTML tags, then it will usually be the id of an HTML div tag with some associated class name. For example <div id=”%value%” div=”xxx” >. To extract it, we used a regular expression extractor with the following regular expression: id="(\w+)" class="xxx" To find the class name for the given value, find the div tag with the value id and replace the xxx inside the double quotes with the class name. Remember to use the exact spelling, including all extra spaces that appear inside the quotes. Verify that the extractor returns the value and then save and close. Note: Sometimes if the extractor for the dynamic value was created previously, you will receive a message displaying the extractor name. In this case, when creating a parameter, use this extractor name. Creating parameters Back in the Dynamic Val. Tab, select the same dynamic value for which you just created the extractor, right click and select Replace selection with parameter. A parameter creation window will pop up. The value should already be highlighted. Right click on it and select the extractor you just created. Your Parameter is created. Very often, one dynamic value is used several times in one request or across several requests. Always check if the parameter that you just created needs to be replicated. To do so, right click it and select Create more like this. The find and replace dialog will appear. All fields should be pre-filled, so just click Bulk Replace. Finally, save the parameter. After you create the parameters, run verify again and you should have less warnings this time. Repeat the process over again until there are no more warnings. After your test case verification completed error free, your script is ready to run tests. The approach described here makes it possible to load test Microsoft Dynamics NAV without manual scripting.