You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The DLT and Blazemeter Taurus (BZT) together make an excellent toolset for distributed testing. I used BZT extensively prior to using the DLT in order to configure and execute Gatling and JMeter test scenarios; it is a very feature-rich tool, allowing lots of different configuration parameters to be plugged into one or more test scenarios and executors.
While the DLT is a great tool for mimicking a real-world scenario of multiple distributed clients, it is quite fixed in how it creates the configuration that gets passed to BZT. For example, it is not possible to do things that BZT supports, such as
change the JMeter version
have different result output formats
provide environment variables into the execution
configure multiple scenarios with different executors
easily install plugins (I know this is possible with the current DLT by downloading the plugins and manually packaging them into the zip, but BZT can download and install them automatically from the config json file)
Some of these things might be more complex to implement, such as having multiple scenarios and executors, but it would be relatively easy to add a textbox where a starting config json could be pasted and then read as the initial testScenario object in the API services lambda. Defaults could be added, if no value was provided in the pasted config json (e.g. a sensible JMeter version, or default reporting settings) and other values might be updated/overwritten, even if provided in the json (executors, ramp-up, hold-for, etc.) along with a warning in the app that this would be done.
The text was updated successfully, but these errors were encountered:
The DLT and Blazemeter Taurus (BZT) together make an excellent toolset for distributed testing. I used BZT extensively prior to using the DLT in order to configure and execute Gatling and JMeter test scenarios; it is a very feature-rich tool, allowing lots of different configuration parameters to be plugged into one or more test scenarios and executors.
While the DLT is a great tool for mimicking a real-world scenario of multiple distributed clients, it is quite fixed in how it creates the configuration that gets passed to BZT. For example, it is not possible to do things that BZT supports, such as
Some of these things might be more complex to implement, such as having multiple scenarios and executors, but it would be relatively easy to add a textbox where a starting config json could be pasted and then read as the initial testScenario object in the API services lambda. Defaults could be added, if no value was provided in the pasted config json (e.g. a sensible JMeter version, or default reporting settings) and other values might be updated/overwritten, even if provided in the json (executors, ramp-up, hold-for, etc.) along with a warning in the app that this would be done.
The text was updated successfully, but these errors were encountered: