Skip to content

Test description

kgribov edited this page Mar 14, 2013 · 13 revisions

Test description

Test-description is a combination of two elements - info-collectors and scenario. Example of usage :

    <test-description id="googlePageTest">
        <info-collectors>
            <validator xsi:type="validator-not-null-response"/>
            <metric  xsi:type="metric-custom" calculator="responseSize"/>
        </info-collectors>

        <scenario  xsi:type="scenario-query-pool" parent="pageScenario">
            <endpoint-provider xsi:type="endpoint-provider-list">
                <endpoint>http://google.com</endpoint>
                <endpoint>http://google.ru</endpoint>
            </endpoint-provider>

            <query-provider xsi:type="query-provider-list">
                <query></query>
            </query-provider>
        </scenario>
    </test-description>

##Collectors info-collectors is a list of collectors. Collector can be as metric element or as validator element. Collector is a listener that calls after each iteration.

Validator is a kind of collector, which validate each response and display percent of success rate. You can find result of validator in Test Details path -

validator result

Metric is a kind of collector, which calculate some information from responses. All metric results displays in the path Details at the last line -

metric result

In this example metric is called - sdpPureTimeMetricCalculator

There are some standart types of collectors -

validator-not-null-response and metric-not-null-response calculate not null responses.

validator-consistency - see point Calibration

Also you can create your own [custom collector](Custom information collectors).

##Scenario In scenario you can describe what targets will be loaded and what tool use to make load. Possible type of scenario is scenario-query-pool. Example of such scenario -

        <scenario  xsi:type="scenario-query-pool" parent="pageScenario">
            <invoker xsi:type="invoker-http"/> 
   
            <endpoint-provider xsi:type="endpoint-provider-list">
                <endpoint>http://google.com</endpoint>
                <endpoint>http://google.ru</endpoint>
            </endpoint-provider>

            <query-provider xsi:type="query-provider-list">
                <query>hello</query>
            </query-provider>

            <query-distributor xsi:type="query-distributor-round-robin"/>
        </scenario>

###Invoker

Invoker is an object that executes queries.

###Endpoint and query providers

endpoint-provider and query-provider are jagger components that provide sources, where jagger can take queries and endpoints

You can choose standart types - endpoint-provider-list and query-provider-list or create your [own provider](Custom endpoint and query providers).

Example of providers -

            <endpoint-provider xsi:type="endpoint-provider-list">
                <endpoint>https://jagger.griddynamics.net</endpoint>
            </endpoint-provider>

            <query-provider xsi:type="query-provider-list">
                <query>index.html</query>
                <query>screenshots.html</query>
                <query>download.html</query>
            </query-provider>

###Query distributor

Query distributor is an object, that provides an algorithm how to distribute queries by endpoints. Possible types of query-distributor :

query-distributor-one-by-one - Schedules queries across endpoints one by one. For input: endpoints [e1, e2] and queries [q1, q2, q3] executes actions in following order: (e1, q1), (e2, q1), (e1, q2), (e2, q2), (e1, q3), (e2, q3).

query-distributor-round-robin - Encapsulates round robin algorithm. For input: endpoints [e1, e2] and queries [q1, q2, q3] returns (invoker, query) pairs in following order: (e1, q1), (e2, q2), (e1, q3), (e2, q1), (e1, q2), (e2, q3).

You also can create your [own query distibutor](Custom query distributors).

##Calibration

You can turn on calibration in test-description by adding attribute calibration="true". Calibration is a process, when Jagger in a simple(one thread) mode load every target only one time. The results, that were calculated in this process, will be a benchmark for comparison with the new iterations. To use this option add component 'validator-consistency'. You can override comparison by using next attributes - resultEq, queryEq, endpointEq.

Tell about validator-consistency ...