Performance Engineering Best Practices and Methodology

When to Re-Script vs not to

Regular Contributor.

When to Re-Script vs not to

Hi - I'm looking for some understanding of some best practices on when to re-script vs when not to. 


We have a HTTP/HTML script on a web application.  The project team made some code changes within their application that didn't affect the scripts behavior in anyway. 


When doing some monitoring under dyna-trace we still some aspx calls that adding 2 secs to our response time from our old scripts.  Even though the scripts are not showing any failures in them this aspx call are being generated and effecting our times.


Should a re-script be done because of this?

Micro Focus Expert

Re: When to Re-Script vs not to

Hi Hawesch,


My opinion is that if there is a code change in the application it is good idea to record the script again and check if there will be other differences in the new script apart from the dynamic values.

Comparing the scripts you will be able to decide if you should continue working with the new script or not.


Kind regards,

HPE Support
If you haven’t tried it yet, come and join us in our entitled forums at Support Customer Forums

If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution and give Kudos to the author for their assistance.
New Member.

Re: When to Re-Script vs not to

Hi - to add on...


It is up to you when to make this decision.  Here is my opinion..


Granted it can be difficult to parameterize and alter the recorded script - so the effort to record a new script is weighed carefully against making manual edits.


First - We keep the scripts in a version control system.  This allows you to compare a recent recording to the last saved one.   When development triggers us that something "big" has changed - the team will record the scenario again and compare to the previous version.  This helps us understand the scope of the differences.


If the script can be updated/corrected with a simple cut/paste - then we take that path.    If however the newly recorded script doesn't look anything like the previous - this tips the scale towards recording a new script.


I should also point out that we subdivide our web scripts into smaller functions so that it is easier to compare (and therefore reuse).  For example - there is a section of a web page that is common across all pages.  This HTML code was extracted and placed into a shared code library.  When recording we strip out the recorded HTML and replace it with a call to this library method.  This way if the common frame changes - we record it (fix it) once and recompile all of the scenarios... thus propogating the new HTML everywhere.


Have fun.


Re: When to Re-Script vs not to

I think it's critical to understand the performance risk areas of the application, and know the application well enough to make an informed decision about whether to re-script as the application changes.


If there are a few “extra” static resources being loaded that is not usually a concern.   However if there are new AJAX calls to the server, or if the requests have significantly changed, then it is appropriate to re-script. 


I often will look at the underlying requests - using tools such as Fiddler, dynaTrace, and even look at the DB SQL queries that are running.  I am a stickler about making sure that my scripts are driving the expected back-end workloads.


Just like Mike_J I  modularize all of  my scripts.  I typically re-record and compare, and more often than not I can merge in the changes without entirely recreating the script.


Hope that helps.