Hi all
I wanted to know do we have an option to get a consolidated HTML report after running the different test cases under 1 package. Curently when we run the cases using mvn gatling:test command it executes sequentially all the cases and generate separate html reports .
It would be a great gesture if someone could help or suggest .Thanks in advance
Hi @Debashish,
Do you know you can have multiple scenario in one Simulation?
You can define a Simulation with a sequence of scenario that will produce its own reports.
There is no one solution fit all use cases for this “consolidation”.
Should the value be aggregated as if all Simulations started at the same time? One after the other (which order?) How much time between them? What about conflicting request name? group name? scenario name?
The higher kind for gatling IS the Simulation.
Hope that explanation helps!
Cheers!
Thanks @sbrevet for your prompt reply.Im aware of the multiple scenarios under 1 simulation, but i’m thinking on microservice architecture framework level where having all the scenarios under 1 cases doesnt make sense and not feasible as well.
Moreover if gatling is producing different reports for individual simulations, there can be a provision provided to concatenate all the reports and show a summary of the reports under 1 file , though configs and load might be different irrespective of the duration for which they were triggered . Once run is complete it can just summarise under details tab .Let me know if thjis makes sense to you .
Thanks Deb
Hi @Debashish,
Sorry but it doesn’t make sense to me.
So, I bet the “consolidated” HTML reports doesn’t make sense either
I doubt it.
If you can create a Simulation right now, you can extract the scenario of this microservice.
In another component (module, jar, etc) you might aggregate the different scenarios for the different cases, so you can build the Simulation that consolidates your wanted reports.
If you are talking about things as httpprotocol, baseUrl, etc. They are only base configuration and each injection profile may use their own, or the request may override it.
If you are talking about shared global variables, as they will lie in their own class and their own package, the variables won’t collide.
If you are talking about external configuration (system properties, environment variables), it is about the custom code and we can think about prefix or other way to distinguish them.
As stated in my previous message, there is no solution that fit all use cases. Without knowing the particular use case, no one will be able to “consolidate” for your needs.
Even the stored percentile may be different (as it is a configuration of the simulation), you can’t compare apples and oranges.
Cheers!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.