Forum Discussion
- JMalvin9 years agoOccasional Contributor
No, we are running the load test in SoapUI Pro.
And, yes, we can temporarily disable JDBC steps and run the services, but there are two issues with that approach:
- There are a few dozen JDBC steps for some of these test cases. Enabling and disabling them is a daunting process which should be avoided.
- There are a few hundred assertions that depend on responses coming back from JDBC steps. Disabling the latter steps would result in stream of these failed assertions.
I just need the load test calculation to ignore certain steps if possible and not to take them into consideration.
- nmrao9 years agoChampion Level 3On the whole if you can disable the jdbc steps it is enough. If step is disabled, then there is no question of assertion associated to it, right?
- JMalvin9 years agoOccasional Contributor
I understand that if one to disable JDBC steps, the TPS values would correctly represent the service requests' throughput. However, the "err" columns then would lid up as all the assertions that match values between JDBC returned rows and Soap response fail which is not something I would like to show in the reports.
I tried to run all the steps, then disable the JDBC steps and execute the load test, hoping that the records retrieved through this "manual" run would persist, and can be used in the load test. But, alas, the load test simply ignores them.
P.S. JDBC steps have been marked distinctively, so identifying and disabling them is of no issue.
- nmrao9 years agoChampion Level 3And do you have any certain pattern for the jdbc step name? So that it is can easily be identified to disable.
Related Content
- 3 years agoLucian
- 5 years agosuperv0672
- 4 months agoeykxas