Dynamics 365 USD Performance Testing (Part 1)
These tests are more designed to identified the client side impact of using USD. It can be a very CPU intensive program and depending on your configuration on CE, some of the pages can take a while to load and/or use up a lot of client side resource.
Microsoft know this and if they could burn IE to the ground I am sure they would, but in the meantime their Dev teams have been hard at work and have a public preview of leveraging Edge instead of IE.
After this I would get the coordinates by using get-window powershell script which can be found here. I would then subtract a certain amount of pixels to determine where the button I wanted to click was!
You can create a simple function and just call it at certain points in your script. Just put the code from the link above at the top of your script.
You cannot answer a Skype call unless you have a proper Microphone device on your computer. This can be a problem if you are using XenApp through RDP or something similar.
I created a function called Check-Status
I know that when USD loads for the first time, it loads a dashboard. This loads 7 CE pages before it has finished. So it will call the function and the function will loop round once and repeat 6 more times. It will provide feedback on the GUI form I created.
If something has gone wrong and 100 seconds passes by (200x500ms), the script will exit. If the error occurred, then I called a separate function that would email me and exit the script.
This worked really well for most things. There were a couple of steps which didn't have a definitive log entry item or they were not reliable.
For these I created a more generic function called Check-LogIdle. This would check the total amount of lines in the Log File. If this number remained constant for a total of 10 iterations (of a second of so each) it would move onto the next step.
The resultant CSV file looks like the below.
Hopefully the above shows some good techniques to testing USD. The key here is profiling the specific tests you wish to complete and gathering information such as mouse-clicks and keyboard strokes. There is not one size fits all approach here unfortunately.
I would love to build a script which you could use to automatically profile a specific scenario, but that is one for another day!
The next blog post in this series will have a sanitised version of the script I use and hopefully a video of it in action. The last post in the series will cover the controller script which launches these workloads from a central location.
Please leave comments on any of the above. If there is a better way of completing certain tasks, or other features that could be useful. Let me know!
update, here is part 2