टेस्टकंटेनर-आधारित लोड परीक्षण बेंच के बारे में आपको जो कुछ भी जानना चाहिए

टेस्टकंटेनर का उपयोग करने से परीक्षण परिदृश्यों के साथ काम करने की प्रक्रिया में मौलिक सुधार हुआ है। इस उपकरण की बदौलत, एकीकरण परीक्षणों के लिए वातावरण बनाना सरल हो गया है (लेख काफ़्का के साथ परीक्षण में अलगाव देखें)। अब, हम डेटाबेस, संदेश ब्रोकर्स और अन्य सेवाओं के विभिन्न संस्करणों के साथ कंटेनरों को आसानी से लॉन्च कर सकते हैं। एकीकरण परीक्षणों के लिए, टेस्टकंटेनर अपरिहार्य साबित हुआ है।

हालाँकि लोड परीक्षण कार्यात्मक परीक्षण से कम आम है, लेकिन यह बहुत अधिक आनंददायक हो सकता है। ग्राफ़ का अध्ययन करना और किसी विशेष सेवा के प्रदर्शन का विश्लेषण करना वास्तविक आनंद ला सकता है। ऐसे कार्य दुर्लभ हैं, लेकिन वे मेरे लिए विशेष रूप से रोमांचक हैं।

इस लेख का उद्देश्य लोड परीक्षण के लिए एक सेटअप बनाने के दृष्टिकोण को प्रदर्शित करना है, जिस तरह से नियमित एकीकरण परीक्षण लिखे जाते हैं: ग्रेडल प्रोजेक्ट वातावरण में टेस्टकंटेनर का उपयोग करके स्पॉक परीक्षणों के रूप में। गैटलिंग, WRK और Yandex.Tank जैसी लोड-परीक्षण उपयोगिताओं का उपयोग किया जाता है।

लोड परीक्षण वातावरण बनाना

टूलसेट: ग्रेडल + स्पॉक फ्रेमवर्क + टेस्टकंटेनर। कार्यान्वयन संस्करण एक अलग ग्रेडल मॉड्यूल है। लोड परीक्षण उपयोगिताएँ गैटलिंग, WRK और Yandex.Tank हैं।

परीक्षण ऑब्जेक्ट के साथ काम करने के दो तरीके हैं:

• प्रकाशित छवियों का परीक्षण;
• परियोजना के स्रोत कोड से छवियाँ बनाना और उनका परीक्षण करना।

पहले मामले में, हमारे पास लोड परीक्षणों का एक सेट है जो परियोजना के संस्करण और परिवर्तनों से स्वतंत्र हैं। भविष्य में इस दृष्टिकोण को बनाए रखना आसान है, लेकिन यह केवल प्रकाशित छवियों के परीक्षण तक सीमित है। हम, निश्चित रूप से, इन छवियों को स्थानीय रूप से मैन्युअल रूप से बना सकते हैं, लेकिन यह कम स्वचालित है और पुनरुत्पादन को कम करता है। आवश्यक छवियों के बिना CI/CD में चलने पर, परीक्षण विफल हो जाएंगे।

दूसरे मामले में, परीक्षण सेवा के नवीनतम संस्करण पर चलाए जाते हैं। यह CI में लोड परीक्षणों को एकीकृत करने और सेवा संस्करणों के बीच प्रदर्शन डेटा परिवर्तन प्राप्त करने की अनुमति देता है। हालाँकि, लोड परीक्षण आमतौर पर यूनिट परीक्षणों की तुलना में अधिक समय लेते हैं। गुणवत्ता गेट के हिस्से के रूप में CI में ऐसे परीक्षणों को शामिल करने का निर्णय आप पर निर्भर है।

यह लेख पहले दृष्टिकोण पर विचार करता है। स्पॉक की बदौलत, हम तुलनात्मक विश्लेषण के लिए सेवा के कई संस्करणों पर परीक्षण चला सकते हैं:

 where: image | _ 'avvero/sandbox:1.0.0' | _ 'avvero/sandbox:1.1.0' | _

यह ध्यान रखना महत्वपूर्ण है कि इस लेख का लक्ष्य परीक्षण स्थान के संगठन को प्रदर्शित करना है, न कि पूर्ण पैमाने पर लोड परीक्षण करना।

लक्ष्य सेवा

परीक्षण ऑब्जेक्ट के लिए, आइए सैंडबॉक्स नामक एक सरल HTTP सेवा लें, जो एक एंडपॉइंट प्रकाशित करती है और अनुरोधों को संभालने के लिए बाहरी स्रोत से डेटा का उपयोग करती है। सेवा में एक डेटाबेस है।

Dockerfile सहित सेवा का स्रोत कोड, परियोजना रिपॉजिटरी spring-sandbox में उपलब्ध है।

मॉड्यूल संरचना अवलोकन

जैसा कि हम लेख में आगे विस्तार से बताएंगे, मैं load-tests ग्रेडेल मॉड्यूल की संरचना के संक्षिप्त अवलोकन के साथ शुरुआत करना चाहता हूं ताकि इसकी संरचना को समझा जा सके:

 load-tests/ |-- src/ | |-- gatling/ | | |-- scala/ | | | |-- MainSimulation.scala # Main Gatling simulation file | | |-- resources/ | | | |-- gatling.conf # Gatling configuration file | | | |-- logback-test.xml # Logback configuration for testing | |-- test/ | | |-- groovy/ | | | |-- pw.avvero.spring.sandbox/ | | | | |-- GatlingTests.groovy # Gatling load test file | | | | |-- WrkTests.groovy # Wrk load test file | | | | |-- YandexTankTests.groovy # Yandex.Tank load test file | | |-- java/ | | | |-- pw.avvero.spring.sandbox/ | | | | |-- FileHeadLogConsumer.java # Helper class for logging to a file | | |-- resources/ | | | |-- wiremock/ | | | | |-- mappings/ # WireMock setup for mocking external services | | | | | |-- health.json | | | | | |-- forecast.json | | | |-- yandex-tank/ # Yandex.Tank load testing configuration | | | | |-- ammo.txt | | | | |-- load.yaml | | | | |-- make_ammo.py | | | |-- wrk/ # LuaJIT scripts for Wrk | | | | |-- scripts/ | | | | | |-- getForecast.lua |-- build.gradle

प्रोजेक्ट रिपोजिटरी - https://github.com/avvero/testing-bench .

पर्यावरण

ऊपर दिए गए विवरण से, हम देखते हैं कि सेवा की दो निर्भरताएँ हैं: सेवा https://external-weather-api.com और एक डेटाबेस। उनका विवरण नीचे दिया जाएगा, लेकिन आइए योजना के सभी घटकों को Docker वातावरण में संचार करने में सक्षम करके शुरू करें - हम नेटवर्क का वर्णन करेंगे:

 def network = Network.newNetwork()

और प्रत्येक घटक के लिए नेटवर्क उपनाम प्रदान करें। यह अत्यंत सुविधाजनक है और हमें एकीकरण मापदंडों का सांख्यिकीय रूप से वर्णन करने की अनुमति देता है।

वायरमॉक और लोड टेस्टिंग यूटिलिटीज जैसी निर्भरताओं को काम करने के लिए कॉन्फ़िगरेशन की आवश्यकता होती है। ये पैरामीटर हो सकते हैं जिन्हें कंटेनर में पास किया जा सकता है या संपूर्ण फ़ाइलें और निर्देशिकाएँ जिन्हें कंटेनर में माउंट करने की आवश्यकता होती है।

इसके अलावा, हमें कंटेनरों से उनके काम के परिणाम प्राप्त करने की आवश्यकता है। इन कार्यों को हल करने के लिए, हमें निर्देशिकाओं के दो सेट प्रदान करने की आवश्यकता है:

• workingDirectory — मॉड्यूल की संसाधन निर्देशिका, सीधे load-tests/ पर।

• reportDirectory — मेट्रिक्स और लॉग सहित कार्य के परिणामों की निर्देशिका। इस पर अधिक जानकारी रिपोर्ट वाले अनुभाग में दी जाएगी।

डेटाबेस

सैंडबॉक्स सेवा अपने डेटाबेस के रूप में Postgres का उपयोग करती है। आइए इस निर्भरता का वर्णन इस प्रकार करें:

 def postgres = new PostgreSQLContainer<>("postgres:15-alpine") .withNetwork(network) .withNetworkAliases("postgres") .withUsername("sandbox") .withPassword("sandbox") .withDatabaseName("sandbox")

घोषणा नेटवर्क उपनाम postgres निर्दिष्ट करती है, जिसका उपयोग सैंडबॉक्स सेवा डेटाबेस से कनेक्ट करने के लिए करेगी। डेटाबेस के साथ एकीकरण विवरण को पूरा करने के लिए, सेवा को निम्नलिखित पैरामीटर प्रदान किए जाने चाहिए:

 'spring.datasource.url' : 'jdbc:postgresql://postgres:5432/sandbox', 'spring.datasource.username' : 'sandbox', 'spring.datasource.password' : 'sandbox', 'spring.jpa.properties.hibernate.default_schema': 'sandbox'

डाटाबेस संरचना का प्रबंधन फ्लाईवे का उपयोग करके एप्लिकेशन द्वारा ही किया जाता है, इसलिए परीक्षण में किसी अतिरिक्त डाटाबेस हेरफेर की आवश्यकता नहीं होती है।

https://external-weather-api.com पर मॉकिंग अनुरोध

अगर हमारे पास कंटेनर में वास्तविक घटक चलाने की संभावना, आवश्यकता या इच्छा नहीं है, तो हम इसके API के लिए एक मॉक प्रदान कर सकते हैं। https://external-weather-api.com सेवा के लिए, WireMock का उपयोग किया जाता है।

वायरमॉक कंटेनर की घोषणा इस प्रकार दिखाई देगी:

 def wiremock = new GenericContainer<>("wiremock/wiremock:3.5.4") .withNetwork(network) .withNetworkAliases("wiremock") .withFileSystemBind("${workingDirectory}/src/test/resources/wiremock/mappings", "/home/wiremock/mappings", READ_WRITE) .withCommand("--no-request-journal") .waitingFor(new LogMessageWaitStrategy().withRegEx(".*https://wiremock.io/cloud.*")) wiremock.start()

वायरमॉक को मॉक कॉन्फ़िगरेशन की आवश्यकता होती है। withFileSystemBind निर्देश स्थानीय फ़ाइल पथ और Docker कंटेनर के अंदर पथ के बीच फ़ाइल सिस्टम बाइंडिंग का वर्णन करता है। इस मामले में, स्थानीय मशीन पर निर्देशिका "${workingDirectory}/src/test/resources/wiremock/mappings" वायरमॉक कंटेनर के अंदर /home/wiremock/mappings पर माउंट किया जाएगा।

निर्देशिका में फ़ाइल संरचना को समझने के लिए नीचे परियोजना संरचना का एक अतिरिक्त भाग दिया गया है:

 load-tests/ |-- src/ | |-- test/ | | |-- resources/ | | | |-- wiremock/ | | | | |-- mappings/ | | | | | |-- health.json | | | | | |-- forecast.json

यह सुनिश्चित करने के लिए कि नकली कॉन्फ़िगरेशन फ़ाइलें सही ढंग से लोड की गई हैं और WireMock द्वारा स्वीकार की गई हैं, आप एक सहायक कंटेनर का उपयोग कर सकते हैं:

 helper.execInContainer("wget", "-O", "-", "http://wiremock:8080/health").getStdout() == "Ok"

सहायक कंटेनर का वर्णन इस प्रकार है:

 def helper = new GenericContainer<>("alpine:3.17") .withNetwork(network) .withCommand("top")

वैसे, IntelliJ IDEA संस्करण 2024.1 ने WireMock के लिए समर्थन पेश किया , और IDE मॉक कॉन्फ़िगरेशन फ़ाइलें बनाते समय सुझाव प्रदान करता है।

लक्ष्य सेवा लॉन्च कॉन्फ़िगरेशन

सैंडबॉक्स सेवा कंटेनर की घोषणा इस प्रकार है:

 def javaOpts = ' -Xloggc:/tmp/gc/gc.log -XX:+PrintGCDetails' + ' -XX:+UnlockDiagnosticVMOptions' + ' -XX:+FlightRecorder' + ' -XX:StartFlightRecording:settings=default,dumponexit=true,disk=true,duration=60s,filename=/tmp/jfr/flight.jfr' def sandbox = new GenericContainer<>(image) .withNetwork(network) .withNetworkAliases("sandbox") .withFileSystemBind("${reportDirectory}/logs", "/tmp/gc", READ_WRITE) .withFileSystemBind("${reportDirectory}/jfr", "/tmp/jfr", READ_WRITE) .withEnv([ 'JAVA_OPTS' : javaOpts, 'app.weather.url' : 'http://wiremock:8080', 'spring.datasource.url' : 'jdbc:postgresql://postgres:5432/sandbox', 'spring.datasource.username' : 'sandbox', 'spring.datasource.password' : 'sandbox', 'spring.jpa.properties.hibernate.default_schema': 'sandbox' ]) .waitingFor(new LogMessageWaitStrategy().withRegEx(".*Started SandboxApplication.*")) .withStartupTimeout(Duration.ofSeconds(10)) sandbox.start()

उल्लेखनीय पैरामीटर और JVM सेटिंग्स में शामिल हैं:

• कचरा संग्रहण घटना की जानकारी का संग्रहण.
• JVM प्रदर्शन डेटा रिकॉर्ड करने के लिए जावा फ्लाइट रिकॉर्डर (JFR) का उपयोग।

इसके अतिरिक्त, सेवा के निदान परिणामों को सहेजने के लिए निर्देशिकाएँ कॉन्फ़िगर की जाती हैं।

लॉगिंग

यदि आपको किसी कंटेनर के लॉग को किसी फ़ाइल में देखने की आवश्यकता है, जो संभवतः परीक्षण परिदृश्य लेखन और कॉन्फ़िगरेशन चरण के दौरान आवश्यक है, तो आप कंटेनर का वर्णन करते समय निम्नलिखित निर्देश का उपयोग कर सकते हैं:

 .withLogConsumer(new FileHeadLogConsumer("${reportDirectory}/logs/${alias}.log"))

इस मामले में, FileHeadLogConsumer क्लास का उपयोग किया जाता है, जो एक फ़ाइल में सीमित मात्रा में लॉग लिखने की अनुमति देता है। ऐसा इसलिए किया जाता है क्योंकि लोड-परीक्षण परिदृश्यों में संपूर्ण लॉग की आवश्यकता नहीं होती है, और सेवा सही ढंग से काम कर रही है या नहीं, इसका आकलन करने के लिए आंशिक लॉग पर्याप्त होगा।

लोड परीक्षणों का कार्यान्वयन

लोड परीक्षण के लिए कई उपकरण हैं। इस लेख में, मैं उनमें से तीन का उपयोग करने पर विचार करने का प्रस्ताव करता हूं: गैटलिंग, Wrk, और Yandex.Tank। तीनों उपकरणों का उपयोग एक दूसरे से स्वतंत्र रूप से किया जा सकता है।

गैटलिंग

गैटलिंग स्काला में लिखा गया एक ओपन-सोर्स लोड-टेस्टिंग टूल है। यह जटिल परीक्षण परिदृश्यों के निर्माण की अनुमति देता है और विस्तृत रिपोर्ट प्रदान करता है। गैटलिंग की मुख्य सिमुलेशन फ़ाइल स्काला संसाधन के रूप में मॉड्यूल से जुड़ी हुई है, जिससे इंटेलीज आईडिया से समर्थन की पूरी श्रृंखला का उपयोग करके काम करना सुविधाजनक हो जाता है, जिसमें सिंटैक्स हाइलाइटिंग और दस्तावेज़ीकरण संदर्भ के लिए विधियों के माध्यम से नेविगेशन शामिल है।

गैटलिंग के लिए कंटेनर कॉन्फ़िगरेशन इस प्रकार है:

 def gatling = new GenericContainer<>("denvazh/gatling:3.2.1") .withNetwork(network) .withFileSystemBind("${reportDirectory}/gatling-results", "/opt/gatling/results", READ_WRITE) .withFileSystemBind("${workingDirectory}/src/gatling/scala", "/opt/gatling/user-files/simulations", READ_WRITE) .withFileSystemBind("${workingDirectory}/src/gatling/resources", "/opt/gatling/conf", READ_WRITE) .withEnv("SERVICE_URL", "http://sandbox:8080") .withCommand("-s", "MainSimulation") .waitingFor(new LogMessageWaitStrategy() .withRegEx(".*Please open the following file: /opt/gatling/results.*") .withStartupTimeout(Duration.ofSeconds(60L * 2)) ); gatling.start()

इसकी व्यवस्था अन्य कंटेनरों के लगभग समान है:

• reportDirectory से रिपोर्ट के लिए निर्देशिका माउंट करें.
• workingDirectory से कॉन्फ़िगरेशन फ़ाइलों के लिए निर्देशिका माउंट करें.
• workingDirectory से सिमुलेशन फ़ाइलों के लिए निर्देशिका माउंट करें।

इसके अतिरिक्त, कंटेनर को पैरामीटर पास किए जाते हैं:

• सैंडबॉक्स सेवा के लिए URL मान के साथ SERVICE_URL पर्यावरण चर। हालाँकि, जैसा कि पहले उल्लेख किया गया है, नेटवर्क उपनामों का उपयोग करने से परिदृश्य कोड में सीधे URL को हार्डकोड करने की अनुमति मिलती है।

• -s MainSimulation कमांड एक विशिष्ट सिमुलेशन चलाने के लिए।

यहां परियोजना स्रोत फ़ाइल संरचना का एक अनुस्मारक दिया गया है ताकि यह समझा जा सके कि क्या और कहां पारित किया जा रहा है:

 load-tests/ |-- src/ | |-- gatling/ | | |-- scala/ | | | |-- MainSimulation.scala # Main Gatling simulation file | | |-- resources/ | | | |-- gatling.conf # Gatling configuration file | | | |-- logback-test.xml # Logback configuration for testing

चूंकि यह अंतिम कंटेनर है, और हम इसके पूरा होने पर परिणाम प्राप्त करने की अपेक्षा करते हैं, इसलिए हम अपेक्षा निर्धारित करते हैं .withRegEx(".*Please open the following file: /opt/gatling/results.*") परीक्षण तब समाप्त होगा जब यह संदेश कंटेनर लॉग में दिखाई देगा या 60 * 2 सेकंड के बाद।

मैं इस टूल के परिदृश्यों के DSL में नहीं जाऊँगा। आप प्रोजेक्ट रिपॉजिटरी में इस्तेमाल किए गए परिदृश्य का कोड देख सकते हैं।

वर्क

Wrk एक सरल और तेज़ लोड-परीक्षण उपकरण है। यह न्यूनतम संसाधनों के साथ एक महत्वपूर्ण लोड उत्पन्न कर सकता है। प्रमुख विशेषताओं में शामिल हैं:

• अनुरोधों को कॉन्फ़िगर करने के लिए Lua स्क्रिप्ट का समर्थन।
• मल्टीथ्रेडिंग के कारण उच्च प्रदर्शन.
• न्यूनतम निर्भरता के साथ उपयोग में आसानी।

Wrk के लिए कंटेनर कॉन्फ़िगरेशन इस प्रकार है:

 def wrk = new GenericContainer<>("ruslanys/wrk") .withNetwork(network) .withFileSystemBind("${workingDirectory}/src/test/resources/wrk/scripts", "/tmp/scripts", READ_WRITE) .withCommand("-t10", "-c10", "-d60s", "--latency", "-s", "/tmp/scripts/getForecast.lua", "http://sandbox:8080/weather/getForecast") .waitingFor(new LogMessageWaitStrategy() .withRegEx(".*Transfer/sec.*") .withStartupTimeout(Duration.ofSeconds(60L * 2)) ) wrk.start()

सैंडबॉक्स सेवा के अनुरोधों के साथ Wrk को काम करने के लिए, Lua स्क्रिप्ट के माध्यम से अनुरोध विवरण की आवश्यकता होती है, इसलिए हम स्क्रिप्ट निर्देशिका को workingDirectory से माउंट करते हैं। कमांड का उपयोग करके, हम स्क्रिप्ट और लक्ष्य सेवा विधि के URL को निर्दिष्ट करते हुए Wrk चलाते हैं। Wrk अपने परिणामों के आधार पर लॉग में एक रिपोर्ट लिखता है, जिसका उपयोग अपेक्षाओं को निर्धारित करने के लिए किया जा सकता है।

यांडेक्स.टैंक

Yandex.Tank, Yandex द्वारा विकसित एक लोड-टेस्टिंग टूल है। यह JMeter और Phantom जैसे विभिन्न लोड-टेस्टिंग इंजनों का समर्थन करता है। लोड टेस्ट के परिणामों को संग्रहीत करने और प्रदर्शित करने के लिए, आप निःशुल्क सेवा Overload का उपयोग कर सकते हैं।

कंटेनर कॉन्फ़िगरेशन इस प्रकार है:

 copyFiles("${workingDirectory}/src/test/resources/yandex-tank", "${reportDirectory}/yandex-tank") def tank = new GenericContainer<>("yandex/yandex-tank") .withNetwork(network) .withFileSystemBind("${reportDirectory}/yandex-tank", "/var/loadtest", READ_WRITE) .waitingFor(new LogMessageWaitStrategy() .withRegEx(".*Phantom done its work.*") .withStartupTimeout(Duration.ofSeconds(60L * 2)) ) tank.start()

सैंडबॉक्स के लिए लोड परीक्षण कॉन्फ़िगरेशन दो फ़ाइलों द्वारा दर्शाया गया है: load.yaml और ammo.txt । कंटेनर विवरण के भाग के रूप में, कॉन्फ़िगरेशन फ़ाइलों को reportDirectory में कॉपी किया जाता है, जिसे वर्किंग डायरेक्टरी के रूप में माउंट किया जाएगा। यहाँ प्रोजेक्ट स्रोत फ़ाइलों की संरचना है, जिससे यह समझा जा सकता है कि क्या और कहाँ पास किया जा रहा है:

 load-tests/ |-- src/ | |-- test/ | | |-- resources/ | | | |-- yandex-tank/ | | | | |-- ammo.txt | | | | |-- load.yaml | | | | |-- make_ammo.py

रिपोर्टों

JVM प्रदर्शन रिकॉर्डिंग और लॉग सहित परीक्षण परिणाम build/${timestamp} निर्देशिका में सहेजे जाते हैं, जहां ${timestamp} प्रत्येक परीक्षण रन के टाइमस्टैम्प का प्रतिनिधित्व करता है।

निम्नलिखित रिपोर्ट समीक्षा के लिए उपलब्ध होंगी:

• कचरा संग्रहकर्ता लॉग.
• वायरमॉक लॉग.
• लक्ष्य सेवा लॉग.
• Wrk लॉग.
• जेएफआर (जावा फ्लाइट रिकॉर्डिंग)।

यदि गैटलिंग का उपयोग किया गया था:

• गैटलिंग रिपोर्ट.
• गैटलिंग लॉग.

यदि Wrk का उपयोग किया गया था:

• Wrk लॉग.

यदि Yandex.Tank का उपयोग किया गया था:

• Yandex.Tank परिणाम फ़ाइलें, ओवरलोड पर एक अतिरिक्त अपलोड के साथ।
• Yandex.Tank लॉग.

रिपोर्टों की निर्देशिका संरचना इस प्रकार है:

 load-tests/ |-- build/ | |-- ${timestamp}/ | | |-- gatling-results/ | | |-- jfr/ | | |-- yandex-tank/ | | |-- logs/ | | | |-- sandbox.log | | | |-- gatling.log | | | |-- gc.log | | | |-- wiremock.log | | | |-- wrk.log | | | |-- yandex-tank.log | |-- ${timestamp}/ | |-- ...

निष्कर्ष

लोड परीक्षण सॉफ़्टवेयर विकास जीवनचक्र में एक महत्वपूर्ण चरण है। यह विभिन्न लोड स्थितियों के तहत किसी एप्लिकेशन के प्रदर्शन और स्थिरता का आकलन करने में मदद करता है। इस लेख में टेस्टकंटेनर का उपयोग करके लोड परीक्षण वातावरण बनाने का एक तरीका प्रस्तुत किया गया है, जो परीक्षण वातावरण के आसान और कुशल सेटअप की अनुमति देता है।

टेस्टकंटेनर एकीकरण परीक्षणों के लिए वातावरण के निर्माण को काफी सरल बनाते हैं, लचीलापन और अलगाव प्रदान करते हैं। लोड परीक्षण के लिए, यह उपकरण सेवाओं और डेटाबेस के विभिन्न संस्करणों के साथ आवश्यक कंटेनरों की तैनाती को सक्षम बनाता है, जिससे परीक्षण करना आसान हो जाता है और परिणाम पुनरुत्पादन में सुधार होता है।

गैटलिंग, वर्क और यांडेक्स.टैंक के लिए कंटेनर सेटअप के साथ प्रदान किए गए कॉन्फ़िगरेशन उदाहरण दर्शाते हैं कि विभिन्न उपकरणों को प्रभावी ढंग से कैसे एकीकृत किया जाए और परीक्षण मापदंडों का प्रबंधन कैसे किया जाए।

इसके अतिरिक्त, परीक्षण परिणामों को लॉग करने और सहेजने की प्रक्रिया का वर्णन किया गया, जो अनुप्रयोग प्रदर्शन का विश्लेषण करने और उसे बेहतर बनाने के लिए आवश्यक है। इस दृष्टिकोण को भविष्य में अधिक जटिल परिदृश्यों और अन्य निगरानी और विश्लेषण उपकरणों के साथ एकीकरण का समर्थन करने के लिए विस्तारित किया जा सकता है।

इस लेख पर ध्यान देने के लिए आपका धन्यवाद, तथा उपयोगी परीक्षण लिखने के आपके प्रयास में शुभकामनाएँ!