TestRail - प्रकल्पासाठी वैयक्तिक सेटिंग्ज

परिचय

मी काम केलेल्या अनेक प्रकल्पांमध्ये, लोकांनी स्वतःसाठी TestRail सानुकूलित केले नाही आणि मानक सेटिंग्जसह केले. म्हणून, या लेखात मी वैयक्तिक सेटिंग्जच्या उदाहरणाचे वर्णन करण्याचा प्रयत्न करेन जे आपल्या कामाची कार्यक्षमता सुधारण्यास मदत करू शकतात. उदाहरणार्थ, मोबाईल ऍप्लिकेशन डेव्हलपमेंट प्रोजेक्ट घेऊ.

एक छोटा अस्वीकरण. या लेखात TestRail च्या मूलभूत कार्यक्षमतेचे वर्णन नाही (यावर बरेच मार्गदर्शक आहेत) आणि विक्री अभिव्यक्ती रंगीतपणे वर्णन करतात की तुम्हाला चाचणीसह भांडार तयार करण्यासाठी हा विशिष्ट विक्रेता का निवडण्याची आवश्यकता आहे.

औचित्य योजना (काय अंमलात येईल)

1. सामान्य आवश्यकता

   1. नक्कीच कोणीही केस पास करण्यास सक्षम असावे.

   2. प्रकरणे शक्य तितक्या काळ संबंधित राहिली पाहिजेत

   3. केसेसमध्ये मोबाईल ऍप्लिकेशनची कार्यक्षमता शक्य तितक्या चांगल्या प्रकारे समाविष्ट केली पाहिजे जेणेकरून हे पहिल्या दोन मुद्द्यांचा विरोध करत नाही

2. TestCase आणि TestScenario मध्ये विभाजित करा

3. विविध प्रकारच्या TestRun ची जलद निर्मिती

   1. धुरा

   2. नोंदणी करा

   3. प्रभाव चाचणी इ.

4. केस समर्थन ऑप्टिमायझेशन

   1. "डेड" हार्डकोड केलेले स्क्रीनशॉट सोडून देणे आणि "जंगम डेटा" वर स्विच करणे

आवश्यकता

फील्ड संपादित करण्यासाठी तुम्हाला प्रशासक प्रवेश आवश्यक असेल

प्रकल्पाचा प्रकार निवडणे

निवडण्यासाठी तीन प्रकल्प प्रकार आहेत:

आपण डीफॉल्ट प्रकार निवडू. त्यात सर्व प्रकरणे एकाच वेळी उपलब्ध असतील. आम्ही स्मार्ट फिल्टरिंग वापरू आणि एकाच वेळी सर्व केस डायनॅमिकपणे व्यवस्थापित करू.

चाचणी प्रकरणांची सूची पाहण्यासाठी फील्ड जोडत आहे

प्राधान्य चाचणी प्रकरणे प्रदर्शित करण्यासाठी फील्ड जोडूया:

तुम्ही इतर फील्ड देखील जोडू शकता.

चाचणी केस फील्ड आणि टॅग सेट करणे

सेटिंग्ज मेनू उघडा:

आम्हाला खालील फील्डची आवश्यकता असेल:

"सारांश" फील्ड (चाचणी प्रकरण शीर्षलेख)

हे फील्ड आधीपासूनच अस्तित्वात आहे, आम्ही फक्त त्याचा वापर व्यवस्थित करत आहोत. आम्ही प्रकरणे TestCase आणि TestScenario मध्ये विभागू. प्रकरणांच्या मोठ्या सूचीच्या चांगल्या वाचनीयतेसाठी, सारांश लिहिण्याच्या नियमांवर आगाऊ सहमत होणे चांगले.

चाचणी परिस्थिती:

उदाहरण: TestScenario - मोबाइल अनुप्रयोग वापरण्यासाठी मूलभूत परिस्थिती

चाचणी प्रकरण:

उदाहरण: मेनस्क्रीन - अधिकृतता विभाग - लॉगिन प्रविष्ट करा

एकूण, आम्ही प्रकरणाच्या सारांशात क्लासिक समज पाहतो: "काय, कुठे, केव्हा." आम्ही उच्च-स्तरीय चाचणी स्क्रिप्ट्स आणि निम्न-स्तरीय चाचणी प्रकरणे ऑटोमेशनसाठी सर्वात योग्य स्वरूपात देखील दृष्यदृष्ट्या विभक्त करतो.

"StartScreen" टॅग (ज्या स्क्रीनवरून TestScenario सुरू होते; तसेच, अनेक चाचणी प्रकरणे लगतच्या स्क्रीनला स्पर्श करू शकतात)

त्याची गरज काय असू शकते: आम्ही मजकूरातून केसेसचा मजकूर काढून टाकू जे वापरकर्त्याला वर्तमान चाचणी केसच्या स्क्रीनवर घेऊन जातात. (विशिष्ट चाचणी परिस्थिती निर्माण करण्यासाठी ठराविक पायऱ्या) सर्व चाचणी प्रकरणांसाठी सर्व ठराविक पायऱ्या एका फाईलमध्ये लिहिल्या जातील. मी याबद्दल स्वतंत्रपणे अधिक तपशीलवार लिहीन.

नवीन फील्ड तयार करा:

नवीन फील्डचे घटक भरा:

या प्रकरणात, आम्ही मूल्यांच्या सूचीमधून एक निवडक फील्ड तयार करत आहोत. या फील्डची मूल्ये प्रविष्ट करा:

कृपया लक्षात घ्या की आयडी व्हॅल्यू एकने सुरू होत नाहीत आणि सलग नाहीत. हे का केले जाते? मुद्दा असा आहे की आमच्याकडे नोंदवलेल्या आयडीसह चाचणी प्रकरणे असल्यास,

आणि त्यानंतर आम्हाला दोन विद्यमान स्क्रीनमध्ये तिसरा स्क्रीन तयार करावा लागेल,

मग आम्हाला आयडी पुन्हा लिहावा लागेल आणि विद्यमान मजकूर प्रकरणांचे टॅग आधीच जोडलेले असल्याने ते फक्त हटवले जातील. ते खूप अप्रिय असेल.

"स्क्रीन" टॅग करा (टेस्टकेसवर परिणाम करणाऱ्या स्क्रीनचे नाव)

तुम्हाला काय आवश्यक आहे: प्रभाव चाचणीसाठी अँकरपैकी एक. उदाहरणार्थ, विकसकांनी नवीन छान वैशिष्ट्य बनवले. आम्हाला याची चाचणी घेणे आवश्यक आहे, परंतु यासाठी आम्हाला हे समजून घेणे आवश्यक आहे की या वैशिष्ट्याचा नेमका काय परिणाम होऊ शकतो. डीफॉल्टनुसार, आम्ही अॅप्लिकेशनच्या वेगवेगळ्या स्क्रीन्स (अॅक्टिव्हिटीज) चे वेगवेगळे वर्ग असतात आणि त्यामुळे अॅप्लिकेशनचे वेगवेगळे घटक बनतात या पॅराडाइमपासून सुरुवात करू शकतो. अर्थात, या प्रकरणात वैयक्तिक दृष्टिकोन आवश्यक आहे.

उदाहरण: home_screen, MapScreen, PayScreen, इ.

"MovableData" फील्ड (बदलण्यायोग्य चाचणी डेटासह प्रॉक्सी डेटाबेसचा दुवा)

पुढे, आम्ही चाचणी प्रकरणांमध्ये डेटाची प्रासंगिकता राखण्याच्या समस्येचे निराकरण करण्याचा प्रयत्न करू:

1. वर्तमान लेआउटचे दुवे (डेड स्क्रीनशॉट घेण्यापेक्षा हे बरेच चांगले आहे)

2. चाचणी परिस्थितीसह स्क्रीनवर जाण्यासाठी ठराविक पायऱ्या

3. SQL क्वेरी

4. बाह्य डेटा आणि इतर डेटाचे दुवे

प्रत्येक चाचणी केसमध्ये चाचणी डेटा लिहिण्याऐवजी, आम्ही एक बाह्य फाईल तयार करू आणि सर्व चाचणी प्रकरणांवर ती लिंक करू. हा डेटा अद्ययावत करताना, आम्हाला सर्व चाचणी प्रकरणांमधून जावे लागणार नाही आणि ते बदलण्याची गरज नाही, परंतु केवळ एकाच ठिकाणी हा डेटा बदलणे शक्य होईल. अप्रस्तुत कोणीतरी चाचणी केस उघडल्यास, त्याला चाचणी प्रकरणाच्या मुख्य भागामध्ये फाईलची लिंक दिसेल आणि त्याला चाचणी डेटासाठी त्यावर जाण्याची आवश्यकता आहे असा इशारा दिसेल.

आम्ही हा सर्व डेटा एका बाह्य फाइलमध्ये पॅक करू, जो प्रकल्पातील प्रत्येकासाठी उपलब्ध असेल. उदाहरणार्थ, तुम्ही Google शीट किंवा एक्सेल वापरू शकता आणि फाइलमध्ये शोध सेट करू शकता. हे विशिष्ट विक्रेते का? वस्तुस्थिती अशी आहे की संघातील कोणतीही व्यक्ती प्रथम कोणतीही साधने स्थापित न करता चाचणी प्रकरण उघडण्यास आणि उत्तीर्ण होण्यास सक्षम असावी या आदर्शापासून आम्ही सुरुवात करतो.

करण्यासाठी Google पत्रक तुम्ही SQL क्वेरी वापरू शकता. उदाहरण:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

करण्यासाठी एक्सेल तुम्ही सोयीस्कर झटपट शोध मॅक्रो सेट करू शकता. (फिल्टरिंग) उदाहरण दुवा.

वास्तविक, ही कल्पना नवीन नाही आणि पहिल्या परीक्षकाच्या पुस्तक "टेस्टिंग डॉट कॉम" मध्ये वर्णन केले आहे. (लेखक सॅविन रोमन) आम्ही फक्त रोमन सॅविनने प्रस्तावित केलेल्या पद्धती TestRail मध्ये एकत्रित करत आहोत. हे करण्यासाठी, तयार केलेल्या फाईलच्या दुव्यासह फील्ड तयार करा:

दुव्याचे डीफॉल्ट मूल्य भरा जेणेकरून प्रत्येक नवीन चाचणी केसमध्ये आधीपासूनच एक लिंक असेल:

जर बाह्य फाइलचे स्थान बदलले (आम्ही कोणत्याही फोर्स मॅजेरसाठी प्रदान करतो), तर तुम्ही सर्व चाचणी प्रकरणांमध्ये एकाच वेळी एक किंवा अधिक फील्ड सोयीस्करपणे बदलू शकता:

फील्ड "वर्णन" (चाचणी प्रकरणाचे वर्णन किंवा कल्पना, मानक सूचना)

तुम्हाला काय आवश्यक आहे: या मजकूर फील्डमध्ये आम्ही चाचणी केस आणि मानक सूचनांचे संक्षिप्त वर्णन देऊ.

उदाहरण: या चाचणी केसमधील सर्व चाचणी डेटा (वर्तमान मांडणी, साधनांचा वापर आणि इतर डेटा) लिंक्स {...} द्वारे दर्शविला जातो आणि MovableData फाइलमध्ये स्थित आहे. शीर्षस्थानी संबंधित फील्डमध्ये MovableData ला लिंक करा.

टॅग "घटक" (मोबाइल अनुप्रयोग घटक)

याची कशासाठी आवश्यकता असू शकते: प्रभाव चाचणीसाठी. जर मोबाईल ऍप्लिकेशन घटकांमध्ये विभागले जाऊ शकते (जे एकमेकांवर शक्य तितक्या कमी परिणाम करतात), तर एकाच घटकामध्ये तपासण्यासाठी एका घटकातील बदल पुरेसे असतील (काही जोखमीसह) आणि ते पार पाडण्यासाठी कमी कारणे असतील. प्रत्येक गोष्टीचे सामान्य प्रतिगमन. एक घटक दुसऱ्या घटकावर परिणाम करू शकतो अशी माहिती असल्यास, प्रभाव चाचणी मॅट्रिक्स संकलित केले जाते.

उदाहरण घटक: GooglePay, ऑर्डर, वापरकर्ते, नकाशा, अधिकृतता इ.

"TAG" टॅग करा (फिल्टरिंगसाठी इतर टॅग)

अनियंत्रित फिल्टरिंगसाठी टॅगसह चाचणी केस टॅग करणे. 

यासाठी खूप उपयुक्त: 

1. विविध वैशिष्ट्यपूर्ण कार्यांसाठी पटकन TestRun संकलित करणे: धूर, प्रतिगमन इ.

2. चाचण्या स्वयंचलित असतील की आधीच स्वयंचलित असतील?

3. इतर कोणतेही टॅग

उदाहरण: स्मोक, ऑटोमेटेड, व्हाइटलेबल, फॉरडिलीट इ.

चाचणी केसमध्ये फील्डचा डिस्प्ले ऑर्डर सेट करणे

आम्ही बरीच नवीन फील्ड तयार केली आहेत, त्यांना सोयीस्कर क्रमाने व्यवस्था करण्याची वेळ आली आहे:

TestRun तयार करणे

आता आम्ही तीन क्लिकमध्ये धुम्रपान चाचणी आयोजित करण्यासाठी वर्तमान प्रकरणांसह एक नवीन चाचणी तयार करू:

इतर उपयुक्त टिपा

1. जर TestRail कडे अनेक प्रकल्प असतील, तर फक्त तुमच्या प्रकल्पासाठी नवीन फील्ड तयार करायला विसरू नका, अन्यथा शेजारील संघातील सहकारी नवीन असामान्य फील्ड दिसल्याने खूप आश्चर्यचकित होतील. स्थानिक बेहोशी शक्य आहे.

2. मोठ्या संख्येने फील्ड असलेली प्रकरणे नवीन तयार करण्यापेक्षा समान गट प्रकारातून कॉपी करणे सोपे आहे:

3. खाती सामायिक केली जाऊ शकतात. उदाहरणार्थ: एक प्रशासक, अनेक वापरकर्ता.

निष्कर्ष

वर वर्णन केलेली उदाहरणे अनेक प्रकल्पांवर लागू केली गेली आहेत आणि त्यांची प्रभावीता दर्शविली आहे. मला आशा आहे की ते या साधनाची तुमची समज सुधारण्यात मदत करतील आणि तुम्हाला प्रभावी आणि सोयीस्कर "चाचणी स्टोरेज" तयार करण्यात मदत करतील. तुम्ही TestRail वापरण्याचा तुमचा अनुभव आणि उपयुक्त टिपा टिप्पण्यांमध्ये वर्णन केल्यास मी खूप आभारी आहे.

दुवे:

TestRail विक्रेता वेबसाइट

पुस्तक: "चाचणी .COM" (लेखक रोमन सॅविन)

दखल घेतल्याबद्दल तुझे अनेकानेक आभार!

स्त्रोत: www.habr.com