jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <p.moua...@ubik-ingenierie.com>
Subject Re: New feature : Readable overview of Test Plan
Date Tue, 22 Jan 2019 19:36:37 GMT
Hello,
Do you think this feature as of now (based on XSL) is worth being committed
to core as alpha?

In terms of implementation, it relies on Saxon BasicTransformer as it
supports xslt 2.0 functions.

Regards

On Monday, January 21, 2019, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:

>
> Am 21.01.19 um 20:56 schrieb Philippe Mouawad:
>
>> On Monday, January 21, 2019, Felix Schumacher <
>> felix.schumacher@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.vladimir@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>
>>>>
>>>>
>>>>

-- 


[image: logo Ubik Ingenierie] <https://www.ubik-ingenierie.com> Philippe
Mouawad
Senior Performance Expert
320914981 <+33320914981> | p.mouawad@ubik-ingenierie.com
[image: ubik-ingenierie.com] ubik-ingenierie.com
<https://www.ubik-ingenierie.com> | [image: 03.20.91.49.81] 03.20.91.49.81
<+33320914981> | [image: 23 rue du chemin de fer , 59100 , Roubaix] 23 rue
du chemin de fer, 59100, Roubaix
<https://www.openstreetmap.org/#map=18/50.69454/3.16455>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message