सेलेनियम के साथ लोड परीक्षण

परिचय

इस लेख में मैं उस उपकरण के उपयोग के बारे में बात करूंगा जो इलेक्ट्रॉनिक परीक्षण प्रबंधन प्रणाली (EDIT) के लोड वेब पार्ट का परीक्षण करते समय मूल रूप से कार्यात्मक परीक्षण के लिए अभिप्रेत है।

इसकी आवश्यकता क्यों थी? हमारे दो लक्ष्य थे: हमारे वेब अनुप्रयोगों के लिए स्वचालित परीक्षणों की शुरुआत और कार्यात्मक परीक्षणों के आधार पर लोड परीक्षणों का निर्माण।

सेलेनियम का उपयोग परीक्षण के लिए क्यों किया गया था, न कि अधिक उपयुक्त उपकरण - लोडरनर, जेमीटर? लोडरनर के साथ, एक लोड परीक्षण किया गया था, लेकिन परिणाम संदेह में डाल दिए गए थे - दो सौ उपयोगकर्ताओं का अनुकरण करते समय, पृष्ठ 2 सेकंड में लोड किया गया, प्लस या माइनस 2%, हालांकि जब ब्राउज़र से एक ही पृष्ठ खोलते हैं, तो डिस्प्ले को 3 सेकंड से अधिक समय लगता है। इसलिए मैं लोड परीक्षणों को वास्तविकता के जितना करीब संभव करना चाहता था, और यह केवल उपयोगकर्ता के व्यवहार के पूर्ण अनुकरण के साथ किया जा सकता है। इसके लिए, ब्राउज़र के साथ अपने काम के साथ कार्यात्मक परीक्षण के लिए उपकरण उपयुक्त थे - साइट एक सामान्य ब्राउज़र के माध्यम से खुल जाएगी, अर्थात। उपयोगकर्ता के रूप में यह करना होगा।

सेलेनियम के बारे में

सेलेनियम को एक साधारण कारण के लिए कार्यात्मक परीक्षण के लिए चुना गया था - यह कार्यात्मक परीक्षण के लिए नि: शुल्क उपकरण का सबसे अच्छा है। अधिक सटीक रूप से, उनके पास रिमोट कंट्रोल (सेलेनियम सर्वर, सेलेनियम ग्रिड) के लिए अच्छा समर्थन है, बहुत सारे दस्तावेज़ीकरण (रूसी में भी शामिल हैं ( habrahabr.ru/post/151715 habrahabr.ru/post/1526533 ) और सभी प्रमुख ब्राउज़रों के लिए समर्थन (हालांकि यह वेबड्राइवर के लिए अधिक है)।

सामान्य वास्तुकला

एप्लिकेशन को स्तरों में विभाजित किया गया है (स्पष्टता के लिए, प्रत्येक स्तर के तत्वों के सार्थक नाम हैं, और न केवल टेस्ट 1, तरीके 2)।

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

दूसरा स्तर स्वयं परीक्षण है। वे व्यवसाय संचालन करते हैं - लॉग इन करें, दस्तावेजों की खुली सूची, दस्तावेज़ खोलें, दस्तावेज़ टैब पर क्लिक करें।

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

उपरोक्त कार्य शुरू करने के लिए सिस्टम के साथ न्यूनतम काम सुनिश्चित करने के लिए पर्याप्त होगा। भविष्य में उन्हें जोड़ा जाएगा।

इन स्तरों में विभाजित होने से निम्नलिखित लाभ प्राप्त होते हैं - आप "धावक" के साथ या उसके बिना परीक्षण चला सकते हैं - विकास पर्यावरण से सिर्फ एक परीक्षण चलाएं। परमाणु उपयोगकर्ता संचालन को एक अलग स्तर पर ले जाने से भविष्य में जावा में परीक्षण लिखने से इंकार करना संभव हो जाएगा, और अपने स्वयं के डीएसएल ( en.wikipedia.org/wiki/Language_programming_language ) को विकसित करना होगा ताकि कोई भी व्यक्ति परीक्षण लिख सके।

परीक्षण चल रहा है

ज्युनिट परीक्षण चलाने का कार्यक्रम काफी सरल है और इसमें तीन वर्ग शामिल हैं - एक वर्ग जो इन परीक्षणों को अपनी स्ट्रीम में करता है; परीक्षण निष्पादन समय की गणना के लिए jUnit परीक्षण "श्रोता" वर्ग; धागे बनाने और उन्हें शुरू करने के लिए कक्षा।
रनर कोड

final int threadCount = readThreadCount(); final int invocationCount = readInvocationCount(); final List<Class> testClasses = readTestClasses(); ExecutorService taskExecutor = Executors.newFixedThreadPool(threadCount); for (int i = 0; i < threadCount; i++) { taskExecutor.execute(new TestRunner(invocationCount, testClasses)); } taskExecutor.shutdown(); taskExecutor.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS); 

परीक्षण चलाने के लिए कक्षा कोड

 public class TestRunner implements Runnable { public void run() { JUnitCore jUnitRunner = new JUnitCore(); jUnitRunner.addListener(new TimeListener()); for (int i = 0; i < invocationCount; i++) { for (Class clazz : testClasses) { jUnitRunner.run(clazz); } Thread.sleep(invocationTimeOut); } } } 

श्रोता कोड

 public class TimeListener extends RunListener { private EtmPoint point; public void testStarted(Description description) throws Exception { point = EtmManager.getEtmMonitor().createPoint(description.getClassName() + "." + description.getMethodName();); } public void testFinished(Description description) throws Exception { point.collect(); } public void testFailure(Failure failure) throws Exception { log.error("Error in test.", failure.getException()); } } 

परीक्षण

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

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

परीक्षणों के अतिरिक्त, अतिरिक्त मॉड्यूल लिखे गए थे - पूल वेबड्राइवर (यहां वेबड्राइवर शब्द सेलेनियम की शब्दावली में उपयोग किया जाता है), उपयोगकर्ताओं का एक पूल, दस्तावेजों का एक पूल, एक नियम (junit शब्दावली में) त्रुटि पर स्क्रीनशॉट लेने के लिए, एक वेबड्राइवर परीक्षण जारी करने के लिए एक नियम, एक प्राधिकरण नियम।

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

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

एक त्रुटि के मामले में स्क्रीनशॉट लेने के लिए नियम, आपको आवश्यकता है, जैसा कि नाम का अर्थ है, यदि परीक्षण निष्पादन विफल हो गया है तो स्क्रीनशॉट लें। वह इसे एक फ़ोल्डर में सहेजता है और स्टैकट्रेस त्रुटि के साथ स्क्रीनशॉट का नाम लॉग करता है। यह भविष्य में त्रुटि को "देखने" के लिए बहुत मदद करता है, न कि इसे केवल लॉग में पढ़ा जाता है। ( internetka.in.ua/selenium-rule-screenshot )
एक परीक्षण के लिए वेबड्राइवर जारी करने के लिए नियम की आवश्यकता है ताकि परीक्षण विधि की शुरुआत से पहले रसीद को स्वचालित किया जा सके और वेबड्राइवर के अंत में वेबड्राइवर्स के पूल से वापसी हो सके।

प्राधिकरण नियम स्वचालन के लिए भी आवश्यक है, केवल अब प्राधिकरण - ताकि प्रत्येक परीक्षा पद्धति में आप लॉगिन \ लॉगआउट न लिखें।

सांख्यिकी संग्रह

आंकड़ों को इकट्ठा करने के लिए, पहिया को सुदृढ़ करने का नहीं, बल्कि तैयार रूपरेखाओं से कुछ का उपयोग करने का निर्णय लिया गया। इंटरनेट पर खोज करना, दुर्भाग्य से, एक विस्तृत विकल्प नहीं दिया - सिर्फ एक उपकरण JETM (http://jetm.void.fm/) है, और यह 2009 के बाद से नहीं बदला है। यद्यपि इसके पास अच्छे दस्तावेज और कुछ प्लस हैं - वास्तविक समय में आँकड़ों को देखने के लिए HTTP के माध्यम से एक दूरस्थ कनेक्शन।
कॉन्फ़िगरेशन कोड की निगरानी करें और http कंसोल लॉन्च करें:

  BasicEtmConfigurator.configure(); EtmMonitor etmMonitor = EtmManager.getEtmMonitor(); etmMonitor.start(); HttpConsoleServer server = new HttpConsoleServer(etmMonitor); server.start(); 

आँकड़े दो स्थानों से एकत्र किए गए थे - कुल समय परीक्षण विधियों के निष्पादन ("लॉन्चर" स्तर से) और परमाणु उपयोगकर्ता संचालन (तीसरे स्तर से) के प्रदर्शन के लिए एकत्र किया गया था। पहली समस्या को हल करने के लिए, RunListener उत्तराधिकारी का उपयोग किया गया था, जिसमें परीक्षण शुरू करने और समाप्त करने के तरीकों को फिर से परिभाषित किया गया था और उनमें निष्पादन के बारे में जानकारी एकत्र की गई थी।

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

पहलू विधि कोड

  @Around("execution(public static * <    >.*.*(..))") public Object profileMethod(ProceedingJoinPoint thisJoinPoint) throws Throwable { EtmPoint point = EtmManager.getEtmMonitor().createPoint(getPointName(thisJoinPoint)); Object result = thisJoinPoint.proceed(); point.collect(); return result; } 

GetPointName विधि विधि और उसके मापदंडों के नाम के आधार पर कटऑफ बिंदु का नाम बनाती है।

लोड परीक्षण ब्राउज़रों

सभी परीक्षणों को लिखने के बाद, यह सवाल उठता है कि इसे किस ब्राउज़र पर चलाना है। कार्यात्मक परीक्षण के मामले में, यहां सब कुछ सरल है - आपको उन ब्राउज़रों पर परीक्षण चलाने की आवश्यकता है जिन पर उपयोगकर्ता चल रहे होंगे। हमारे लिए, यह IE 9. है। इसलिए, मैंने मशीन पर ब्राउज़र के कई उदाहरणों के साथ IE पर परीक्षण चलाने की कोशिश की, ताकि एक कंप्यूटर कई उपयोगकर्ताओं के काम का अनुकरण कर सके (सेलेनियम में, एक वेबड्राइवर ब्राउज़र का एक उदाहरण है)। नतीजतन, मेरी मशीन पर (4GB RAM, 2.3 Core 2 Duo) केवल 4 IE उदाहरणों ने सामान्य रूप से काम किया। जो बहुत अच्छा नहीं है - दो सौ उपयोगकर्ताओं का अनुकरण करने के लिए 50 मशीनों की आवश्यकता होगी। इसका विकल्प तलाशना जरूरी था। और यह: ए) अन्य डेस्कटॉप ब्राउज़र b) हेडलेस ब्राउज़र।

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

फिर मुझे हेडलेस ब्राउज़रों का परीक्षण करना होगा - ब्राउज़र जो पूरी तरह से साइट के साथ काम करते हैं (बिल्ड डोम, जेएस निष्पादित करें), लेकिन इसे प्रदर्शित न करें। सिद्धांत रूप में, उन्हें तेजी से काम करना चाहिए। सभी हेडलेस ब्राउज़रों में से, मैं 2 पर रुक गया - फैंटमजस और हेटपुनिट। वेबकीट पर आधारित, तुरंत PhantomJS को देखा। लेकिन वास्तव में, संसाधन की खपत के मामले में वह एफएफ से अलग नहीं था, लेकिन इसके निम्नलिखित नुकसान थे - कभी-कभी वह पृष्ठ पर तत्व नहीं खोज सका और स्क्रीनशॉट में साइट को सही ढंग से प्रदर्शित नहीं किया। इसलिए यह समझना संभव नहीं था कि त्रुटि क्यों हुई। HtmlUnit के साथ, सब कुछ बहुत सरल है - इसके वेबड्राइवर ने अलर्ट का समर्थन नहीं किया, और यह हमारे वेब एप्लिकेशन के लिए महत्वपूर्ण था।

परिणामस्वरूप, हम लोड परीक्षण में एफएफ के उपयोग पर लौट आए। हालाँकि, इसमें अलर्ट के साथ समस्याएँ भी थीं, कभी-कभी java.lang.Boolean को java.lang.String (java.lang.ClassCastException) में डाला नहीं जा सकता है (यहाँ Google त्रुटि कोड की त्रुटि का लिंक दिया गया है) / सेलेनियम / मुद्दों / विस्तार? आईडी = 3565 )। इस त्रुटि को ठीक करना संभव नहीं था, लेकिन यह पूरी तरह से अलर्ट को छोड़ने के लिए निकला। तो भविष्य में आप फिर से HtmlUnit का उपयोग करके देख सकते हैं। हालाँकि सभी हेडलेस ब्राउज़र में उनकी बारीकियों से संबंधित एक सामान्य असुविधा होती है, वे पृष्ठ प्रदर्शित नहीं करते हैं और यह समझना इतना आसान है कि त्रुटि क्यों हुई। स्क्रीनशॉट लेने की क्षमता बहुत मदद नहीं करती है - कभी-कभी यह जानकारीपूर्ण नहीं होती है।

सेलेनियम का विन्यास

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

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

परीक्षण निष्पादन

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

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

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

संक्षेप

1, 16 वें, 26 वें और 70 वें उपयोगकर्ताओं के लिए परीक्षणों के परिणामस्वरूप प्रत्येक परिदृश्य के लिए शेड्यूल बनाया गया था। अब तक, सटीक निष्कर्ष निकालने के लिए उपयोगकर्ताओं की संख्या बहुत बड़ी नहीं है, लेकिन अब आप समय की वृद्धि दर को ट्रैक कर सकते हैं।
काम करने वाले उपयोगकर्ताओं की संख्या पर दस्तावेजों के शुरुआती समय की निर्भरता:


काम करने वाले उपयोगकर्ताओं की संख्या पर दस्तावेजों की सूची के समय की निर्भरता:

200 उपयोगकर्ताओं तक प्लॉट करने के लिए आगे के परीक्षण जारी रहेंगे। परिणाम इसके जैसा एक ग्राफ होना चाहिए ( msdn.microsoft.com/en-us/library/bb924375.aspx से लिया गया):


इसका उपयोग करना, सिस्टम की क्षमताओं को सटीक रूप से निर्धारित करना और इसकी अड़चनों का पता लगाना पहले से ही संभव होगा।