Forum Discussion
- AlexKarasChampion Level 3
Hi Mathijs,
You are asking really good question...
Unfortunately, I cannot be of much help here as I did not participate in a real large-scale performance project and clauses below are based on my considerations and experience obtained from the proof-of-concept demos. All clauses can be disputed and this is welcome.
It is my understanding that the load project can be implemented in one of two ways:
a) The test that consists of one long scenario that implements some end-to-end use case. This use case may use dynamic data (e.g. obtained from external data source), but separate scenario is recorded for any other use case. Even if this another use case if quite similar to the already existing one. The load project consists of tests each of which contains one end-to-end scenario. If the tested application is changed in some area in a way that the network communication changes between this area and the server, all relevant scenarios must be re-recorded.
b) The project contains a set of small scenarios, one scenario per 'atomic' user action (e.g.: login, browse items list, order item(s), purchase item(s), logout). The 'actual test' consists from a set of Call Scenario operations that implement different use cases. E.g.:
-- login - logout;
-- login - get random number of pages with items list - logout;
-- login - order random number of items - purchase items - logout.And the load project consists of a set of these 'actual tests'.
Approach a) looks as if it requires more maintenance efforts: a lot of long scenarios must be re-recorded with a data correlation applied a-new. And this must be done frequently if the tested application is evolving. On the other hand, if in TestComplete you already have automated functional tests that cover required end-to-end scenarios, the efforts required to re-record scenarios might be much lower (this is where the integration you are talking about is used), data correlation can be done using the means provided by LoadComplete with the reuse of the already existing variables that feed load tests with data from external sources.
Approach b) looks as if it potentially requires less maintenance efforts and provides better scenarios reusability because only a small 'atomic' scenarios should be re-recorded. However, it requires data correlation between different scenarios executed sequentially within one test via a set of Call Scenario operations. And this is something that seems to be lacking integrated support from LoadComplete at the moment. There is a feature request that talks about this approach (https://community.smartbear.com/t5/LoadComplete-Feature-Requests/Make-it-possible-to-compare-and-synchronize-requests-for/idi-p/138803) and comments are welcome.
As a bottom line: I am not sure at the moment which of the mentioned approaches is more preferable in a long-term run as I did not tried them in a real project.
Maybe others with a serious real experience with LoadComplete or some other similar tool (tristaanogre ?) can comment more on this.
Anyway, I hope that the above text may appear to be helpful for you in some way...
- tristaanogreEsteemed Contributor
It's been a LOOOONG time since I've had a chance to play around with LoadComplete... it was version 2 last time I touched it.
As for the two approaches that AlexKaras mentions, I've used both and, honestly, it depends a bit on what you're trying to do, the application under test, etc. As with functional testing in TestComplete, the needs of the project many times dictate the approach in creating the automation. As mentioned, there is coordination that needs to happen in the scenario with the traffic broken up into multiple pieces to make sure that you are doing things the same way every time.As for the feature to turn a functional test into a load test, I have not used it. I've done all my work in the past directly in LoadComplete (or, when it was still part of the tool, TestComplete). The thing to remember is that LoadComplete is all about GET and PUT requests. The actual UI, clicking on the buttons, links, etc., really doesn't come into play. So, the feature mentioned is simply a way of taking a functional test and feeding it through the LoadComplete transponder. From what I understand, it's more of a convenience thing. You have a scenario created in TestComplete that mirrors a scenario you want to use for load testing. In the past, what is described in that article, was a more manual process. You would start the recording in LoadComplete then load up TestComplete and run the test. The integration that is present now just removes some of that manual stuff. But at the core, what you are doing is having your workstation send web traffic to your web server and having LoadComplete record that traffic for playback. Whether you do it by running a TestComplete functional test or manually is immaterial in this end result.
I do wish I had that feature back when I was doing this because the convenience factor would have been VERY nice. Recording a load test means a requirement of a lot of accuracy and repeatability. If I need to re-record a load test, I would have had to remember in the past EXACTLY what steps I executed and make sure I did them the same way EVERY time if I wanted to compare one set of load tests to another. If the set of transponder traffic changes between load tests, you can't necessarily compare the results 1 to 1. By having an automated script in TestComplete to build my load test, I could guarentee that EVERY time I needed to record the load test I could have the same traffic recorded.
- mgroen2Super Contributor
AlexKaras, tristaanogre thank you both for sharing your thoughts on this.
I am pretty new to LoadComplete and I am particularly interested in transforming data driven TestComplete tests, to LoadComplete tests. Do I need to create a link between each GET and PUT requests to the data store? Or is this recorded by LoadComplete itself (during TC's test playback).
Related Content
- 14 years ago
- 8 years ago
Recent Discussions
- 3 years ago
- 3 years ago
- 3 years ago