Reusability of existing (Web HTTP\HTML) scripts on different environment
I need help on how can we increase existing script re-use. We have different environments on which we have created scripts for Web HTTP\HTML protocol. The code base & environment changes with every sprint & releases. How can we achive reusability of existing scripts throghout different environment.
Looking for option other than re-scripting and find-replace methode.
Re: Reusability of existing (Web HTTP\HTML) scripts on different environment
First of all make the Development department understand, that each change they make have extra costs on testing. One way to achieve this is to make a simple performance test part of their nightly build step (That step might fail when they break the protocol).
With larger applications you can discover 3 or more layers:
- backen technical core layer (tools)
- application layer
- web (UI) layer.
Each has its own impact on your scripting and each has its own release cycle. The most two critical layers in respect to testing are the latter two. You might try to bring your recordings to a higher abstraction level (you develop a C-library that hide and bundles details at HTTP/HTML level). Create tools that transform the recorded HTML/HTTP script into this higher abstraction level scripting.
The UI layer team might be responsible or assist to update your C library when they change common patterns. I know a case where the UI team made a tool to convert all the messages of GWT from one version to the next version in our LR scripting.
The application layer is more difficult: when they change things you might need to apply a new recording, but when your abstraction is good, you only need to copy/change the changed parts. But when the application changes only a lable of adds a new action that you can ignore, there is no need to change any thing.
All comes down to good communication (contracts) and change management. THe organization should not see (performance) testing as a last step but should incorporate the testing in the nightly build and test cycle.
Another aspect is that you 'protect' your scripting against not communicated changes. You need to build a lot of verification in your scripts (e.g. version checks, form-lable-name checks etc).
This also implies that the performance LR team members need to have senior C-script level experience. Sound understanding of the use of macro's with __LINE__, __FILE__, so proper error message can be genereted. Consider to use varags (need to introduce this yourself, LR does not supply this).
Reward community members who take time to respond and help.