Forum Discussion
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.
- 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.
Related Content
- 3 years agoLucian
- 5 years agosuperv0672
- 4 months agoeykxas