Am 21.01.19 um 20:56 schrieb Philippe Mouawad:
On Monday, January 21, 2019, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:
Am 21.01.19 um 11:40 schrieb Philippe Mouawad:
Hello,
This will better explain feature:
Menu:
- http://ubikloadpack.com/demo/schematic/MenuSchematicView.png
Plan:
- http://ubikloadpack.com/demo/schematic/testRequest.jmx
Schematic View:
- http://ubikloadpack.com/demo/schematic/testRequest.html
Where do the names "handle Cookies", "add Headers", "Virtual Users
executing", ... come from? How would extensions (plugins) fit into this?
It currently comes from the xsl file.
There would be a default display using element name. For now plugins would
have a very basic display.
There would be a need to provide registration for implementations, I see
how to do it for java implementation, but for XSLT, for now I don't.
Yes, I think the java implementation would have advantages over the
xsl-only version, especially with respect to extensibility.
Working on this feature (within some consulting work, I was asked to
document a plan to provide a textual description and ease understanding of
errors (make other users find to what request an assertion was related)), I
find that it makes the reading/understanding of a test plan more easy.
I ran it on previous plans, and I see at least this major benefit.
Another one (if we move forward) , would be to provide a more source
version friendly representation of a JMX test plan.
Would this lead to something like Vladimir described? A textual
representation of the test plan, possibly with explanations for the
elements, that is diff and reader friendly.
On the other hand, this reminds me of something. I sometimes dream of
having markers in the test plan tree, that could be used to show
* errors that happened during execution of a test plan (linked to/by
samples in result tree)
* common misconfigurations like double timers (scoping issues mostly)
or beanshell/javascript scripts :)
* samplers with long response times
* ...
Felix
Felix
For now, it's html (I'm using XSLT), but a textual format like YAML would
be better for source comparison.
Regards
On Mon, Jan 21, 2019 at 11:04 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
Paulo Maia Borges> Why not export to standard HTML?
For instance, if jmx is stored in a Git repository (GitLab? GitHub?),
then
markdown would be much easier to review in diffs than HTML.
E.g. https://twitter.com/jamiebuilds/status/1085377471057412096
In other words, it could make sense to render markdown representation on
save.
However, it is not clear how tables should be rendered (e.g. HTTP
parameters).
Vladimir
<https://www.openstreetmap.org/#map=18/50.69454/3.16455>
