Belastingstests plannen met Apache JMeter

  • 6 minuten

In deze sectie verkent u belastingtests en leert u hoe u belastingstests toevoegt aan de pijplijn. De belastingstests maken gebruik van Apache JMeter om meerdere gebruikers te simuleren die tegelijkertijd toegang hebben tot de web-app. De tests halen de webinhoud op uit de app die wordt uitgevoerd op Azure App Service in de stagingomgeving.

Tim begint met het ophalen van de Apache JMeter-gebruikersinterface op een laptop. Hij voert een basistestplan uit. Vervolgens exporteren Tim en Mara het testplan naar een bestand dat vanaf de opdrachtregel kan worden uitgevoerd. Ten slotte voegen ze taken toe aan Azure Pipelines om de loadtests uit te voeren tijdens Staging.

Notitie

Voor kortheid hoeft u Apache JMeter niet te installeren op uw lokale computer. Je kunt gewoon meelezen.

Belastingstests uitvoeren vanuit Apache JMeter

Apache JMeter is een opensource-hulpprogramma voor belastingstests waarmee prestaties worden geanalyseerd en gemeten. Het rapport dat wordt gegenereerd, is een XML-bestand.

Azure Pipelines kan het Apache JMeter-rapport lezen en een grafiek genereren. U hebt geen speciale hardware nodig om deze tests uit te voeren, zodat u een door Microsoft gehoste agent kunt gebruiken om ze uit te voeren. In het Space Game-scenario zou je deze tests waarschijnlijk uitvoeren in Staging.

Het testplan maken

Zo ziet Apache JMeter eruit op een laptop met Linux:

schermopname van de Apache JMeter-gebruikersinterface.

U maakt een nieuw testplanbestand; bijvoorbeeld LoadTest.jmx. Vervolgens voegt u een threadgroep toe aan het bestand. Elke gesimuleerde gebruiker wordt uitgevoerd op een eigen thread. Een threadgroep bepaalt het aantal gebruikers en het aantal aanvragen van elke gebruiker.

In het volgende voorbeeld ziet u 10 gesimuleerde gebruikers (threads). Elke gebruiker doet 10 aanvragen, dus het systeem krijgt in totaal 100 aanvragen.

schermopname van het opgeven van de threadgroep in Apache JMeter.

Een sampler is één aanvraag van JMeter. JMeter kan query's uitvoeren op servers via HTTP, FTP, TCP en verschillende andere protocollen. Samplers genereren de resultaten die aan het rapport worden toegevoegd.

Vervolgens voegt u standaardinstellingen voor HTTP-aanvragen en een HTTP-aanvraag-sampler toe aan de threadgroep. U geeft de hostnaam op van de Space Game-website die draait in de stagingomgeving op Azure App Service.

Schermopname van het opgeven van de HTTP-aanvraag in Apache JMeter.

In het voorgaande scenario wordt een basistestplan gemaakt.

Het testplan uitvoeren

Met JMeter kunt u allerlei soorten tests uitvoeren. Het is mogelijk om uw testplan uit te voeren vanuit de grafische JMeter-gebruikersinterface. In de JMeter-documentatie wordt echter aanbevolen om het testplan vanaf de opdrachtregel uit te voeren voor belastingstests.

U voert het testplan uit met behulp van deze opdracht:

apache-jmeter-5.4.1/bin/./jmeter -n -t LoadTest.jmx -o Results.xml

Het argument -n geeft aan dat JMeter moet worden uitgevoerd in de modus niet-GUI. Het argument -t geeft het testplanbestand op, LoadTest.jmx. Het argument -o geeft het rapportbestand op, Results.xml.

JMeter voert uit en produceert het rapportbestand, Results.xml. In dit voorbeeld van het bestand ziet u de eerste paar resultaten:

<?xml version="1.0" encoding="UTF-8"?>
<testResults version="1.2">
<httpSample t="180" it="0" lt="95" ct="35" ts="1569306009772" s="true" lb="HTTP Request" rc="200" rm="OK" tn="Thread Group 1-1" dt="text" by="40871" sby="144" ng="1" na="1">
  <java.net.URL>http://tailspin-space-game-web-staging-1234.azurewebsites.net/</java.net.URL>
</httpSample>
<httpSample t="174" it="0" lt="96" ct="38" ts="1569306009955" s="true" lb="HTTP Request" rc="200" rm="OK" tn="Thread Group 1-1" dt="text" by="40869" sby="144" ng="1" na="1">
  <java.net.URL>http://tailspin-space-game-web-staging-1234.azurewebsites.net/</java.net.URL>
</httpSample>
<httpSample t="160" it="0" lt="121" ct="35" ts="1569306010131" s="true" lb="HTTP Request" rc="200" rm="OK" tn="Thread Group 1-1" dt="text" by="40879" sby="144" ng="2" na="2">
  <java.net.URL>http://tailspin-space-game-web-staging-1234.azurewebsites.net/</java.net.URL>
</httpSample>

Elk voorbeeld produceert een knooppunt in het rapport. Het kenmerk t geeft de reactietijd op in milliseconden (ms). Hier ziet u drie aanvragen die 180 ms, 174 ms en 160 ms hebben geduurd.

De ideale aanvraagtijden moeten minder dan één seconde gemiddeld zijn. Het duurt niet meer dan 10 procent van de aanvragen meer dan één seconde. U kunt JMeter configureren om statistieken te rapporteren, zoals de minimale, maximale en gemiddelde reactietijden of de standaarddeviatie. U kunt een script schrijven om deze informatie te verstrekken.

Als u de testresultaten wilt visualiseren, moet u deze opgeven in een indeling die Azure Pipelines begrijpt. Azure Pipelines kan een XML-bestand parseren dat testresultaten bevat, maar het bestand moet een ondersteunde indeling hebben. Ondersteunde indelingen zijn CTest, JUnit (inclusief PHPUnit), NUnit 2, NUnit 3, Visual Studio Test (TRX) en xUnit 2. U kunt een XSLT-bestand schrijven waarmee de JMeter-resultaten worden geconverteerd naar JUnit.

Het rapport transformeren naar JUnit

XSLT staat voor XSL-transformatiesof eXtensible Stylesheet Language Transformations. Een XSLT-bestand lijkt op een XML-bestand, maar hiermee kunt u een XML-document transformeren naar een andere XML-indeling.

Onthoud onze vereisten voor belastingstests:

  • De gemiddelde aanvraagtijd moet minder dan één seconde zijn.
  • Het duurt niet meer dan 10 procent van de aanvragen meer dan één seconde.

Hier ziet u hoe een XSLT-bestand dat aan deze vereisten voldoet, eruitziet:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:math="http://exslt.org/math">
  <xsl:output method="xml" indent="yes" encoding="UTF-8"/>
  <xsl:template match="/testResults">
    <xsl:variable name="times" select="./httpSample/@t" />
    <xsl:variable name="failures" select="./httpSample/assertionResult/failureMessage" />
    <xsl:variable name="threshold" select="1000" />
    <testsuite>
      <xsl:attribute name="tests"><xsl:value-of select="count($times)" /></xsl:attribute>
      <xsl:attribute name="failures"><xsl:value-of select="count($failures)" /></xsl:attribute> 
      <testcase>
          <xsl:variable name="avg-time" select="sum($times) div count($times)" />
          <xsl:attribute name="name">Average Response Time</xsl:attribute>
          <xsl:attribute name="time"><xsl:value-of select="format-number($avg-time div 1000,'#.##')"/></xsl:attribute>
          <xsl:if test="$avg-time > $threshold">
            <failure>Average response time of <xsl:value-of select="format-number($avg-time,'#.##')"/> exceeds <xsl:value-of select="$threshold"/> ms threshold.</failure>
          </xsl:if> 
      </testcase>
      <testcase>
          <xsl:variable name="exceeds-threshold" select="count($times[. > $threshold])" />
          <xsl:attribute name="name">Max Response Time</xsl:attribute>
          <xsl:attribute name="time"><xsl:value-of select="math:max($times) div 1000"/></xsl:attribute>
          <xsl:if test="$exceeds-threshold > count($times) * 0.1">
            <failure><xsl:value-of select="format-number($exceeds-threshold div count($times) * 100,'#.##')"/>% of requests exceed <xsl:value-of select="$threshold"/> ms threshold.</failure>
          </xsl:if>
      </testcase>
    </testsuite>
  </xsl:template>
</xsl:stylesheet>

We zullen hier niet ingaan op de werking van XSL. Maar om samen te vatten, verzamelt dit bestand eerst de volgende gegevens uit de JMeter-uitvoer:

  • Elke HTTP-aanvraagtijd.

    Deze gegevens worden verzameld door het kenmerk t te selecteren in elk httpSample element. (./httpSample/@t)

  • Elk foutbericht.

    Deze gegevens worden verzameld door alle failureMessage knooppunten in het document te selecteren. (./httpSample/assertionResult/failureMessage)

Het XSLT-bestand stelt ook de drempelwaarde in op 1000 ms. Deze reactietijd is het maximum dat we eerder hebben gedefinieerd.

Gezien deze variabelen biedt het XSLT-bestand het totale aantal tests en het totale aantal fouten. Vervolgens worden deze twee testcases aangeboden:

  • De gemiddelde reactietijd en een fout als het gemiddelde de drempelwaarde van 1000 ms overschrijdt.
  • De maximale reactietijd en een fout als meer dan 10 procent van de aanvragen de drempelwaarde van 1000 ms overschrijdt.

De resultaten van de XSLT komen overeen met de JUnit-indeling, die Azure Pipelines begrijpt. U kunt uw XSLT-bestand JMeter2JUnit.xslnoemen.

Vervolgens hebt u een XSLT-processor nodig. In dit voorbeeld gebruiken we xsltproc-. Dit is een opdrachtregelprogramma voor het toepassen van XSLT-opmaakmodellen op XML-documenten.

U kunt xsltproc- als volgt installeren:

sudo apt-get install xsltproc

Vervolgens voert u xsltproc- uit om het JMeter-rapport te transformeren naar JUnit:

xsltproc JMeter2JUnit.xsl Results.xml > JUnit.xml

Dit is het resulterende JUnit-bestand, JUnit.xml:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite xmlns:math="http://exslt.org/math" tests="100" failures="0">
  <testcase name="Average Response Time" time="0.17"/>
  <testcase name="Max Response Time" time="0.373"/>
</testsuite>

In dit voorbeeld is de gemiddelde reactietijd 170 ms. De maximale reactietijd is 373 ms. Geen van beide testcases genereert een fout, omdat beide keren onder de drempelwaarde van 1000 ms vallen.

Binnenkort voert u deze tests uit in de pijplijn. U kunt denken aan Results.xml, het bestand dat JMeter schrijft, als een tussenbestand dat niet wordt gepubliceerd in de testresultaten van de pijplijn. JUnit.xml is het eindrapportbestand. Dit bestand wordt gepubliceerd naar de pijplijn, zodat het team de resultaten kan visualiseren.