प्रोग्रामरच्या जीवनात चाचणी

प्रोग्रामरना चाचणीची आवश्यकता का आहे?

पुढील दोन स्तर प्रोग्रामरना आवश्यक त्या पद्धतीने चाचणीसाठी समर्पित केले जातील . परंतु प्रथम, चाचणी म्हणजे काय आणि ते का आवश्यक आहे ते शोधूया.

सॉफ्टवेअरच्या संदर्भात, आम्ही असे म्हणू शकतो की चाचणीचे कार्य हे तपासणे आहे की प्रोग्राम:

• तिला जे करायचे आहे ते करते
• तिने जे करू नये ते करत नाही

दुसरा मुद्दा, तसे, पहिल्यापेक्षा कमी महत्त्वाचा नाही, परंतु नंतर त्याबद्दल अधिक.

चला पहिल्या मुद्द्यापासून सुरुवात करूया. "कार्यक्रमाने जे करायचे आहे ते करतो" याचा अर्थ काय?

प्रथम, एखाद्याला प्रोग्रामसाठी सर्व वापर प्रकरणांची सूची तयार करणे आवश्यक आहे. दुसरे म्हणजे, त्यांनी प्रोग्राम कसे कार्य करावे, वापरकर्त्याने कसे वागले पाहिजे आणि कोणते परिणाम अपेक्षित आहेत याचे वर्णन करणे आवश्यक आहे. आपण पुढे चालू ठेवू शकत नाही.

आम्ही "वापरकर्त्याने कसे वागले पाहिजे" असे लिहिताच, चांगले दस्तऐवज लिहिण्याची संपूर्ण कल्पना बाजूला पडली. लोक मशिन नसतात, शिवाय, लोक बर्‍याचदा सॉफ्टवेअरसह त्यांच्या इच्छेनुसार वागतात . सूचनांचा अभ्यास करून कोणीही तंत्रज्ञानाशी परिचित होत नाही. ती वस्तुस्थिती आहे.

म्हणून, आम्हाला एक नवीन तथ्य मिळते: सॉफ्टवेअरचे वैशिष्ठ्य हे आहे की त्यात बरीच भिन्न कार्य परिस्थिती आहे. त्यापैकी काही स्पष्ट आहेत, इतर दस्तऐवजीकरण केले जाऊ शकतात, इतरांना गृहीत धरले जाऊ शकते, इतरांचा अंदाज लावला जाऊ शकतो आणि इतर 50% तुम्हाला होणार नाहीत.

प्रोग्रामरच्या दृष्टिकोनातून, बहुतेक बग्स मुळीच बग नसतात. जेव्हा एखादा प्रोग्राम अपेक्षित किंवा अपेक्षेप्रमाणे कार्य करत नाही तेव्हा त्रुटी असते. आणि अशा बर्‍याच परिस्थिती आहेत जेव्हा प्रोग्राम कसे कार्य करावे हे स्पष्ट नसते किंवा परिस्थिती एकमेकांशी विरोधाभासी असते ...

तेथे असंख्य परिस्थिती आहेत आणि जेव्हा प्रोग्राम अपेक्षेप्रमाणे वागला नाही तेव्हा उत्पादनामध्ये नेहमीच अशी प्रकरणे असतील (प्रोग्रामरने फक्त दोन डझन परिस्थितींसाठी कोड लिहिला). म्हणून, असा युक्तिवाद केला जाऊ शकतो की कोणत्याही प्रोग्राममध्ये नेहमीच बग असतात आणि कोणतेही उत्पादन सतत सुधारले जाऊ शकते .

त्यानंतर, हे सर्व उपयुक्ततेवर येते. प्रथम, प्रोग्रामर सर्वात मोठे बग, नंतर लहान बग, आणि असेच निराकरण करतो. आणि शेवटी, एक टप्पा येतो जेव्हा उत्पादनाच्या मालकाचा असा विश्वास असतो की त्यावर काम करणे आर्थिकदृष्ट्या व्यवहार्य नाही.

परंतु प्रत्येकजण त्रुटी म्हणून ओळखल्या जाणार्‍या त्रुटींकडे परत: प्रोग्राम स्पष्टपणे काहीतरी चुकीचे करतो, पडले, काहीतरी तोडले इ. अशा त्रुटी सशर्तपणे 3 श्रेणींमध्ये विभागल्या जाऊ शकतात: मोठ्या, मध्यम आणि लहान.

आणि बर्‍याचदा असे घडते की प्रोग्रामर मध्यम किंवा अगदी लहान बगचे निराकरण करण्याचे काम करत आहे, तरीही या प्रकल्पात अजूनही बर्‍याच गंभीर समस्या आहेत. त्याला ते सापडले नाहीत , म्हणून तो त्याला माहीत असलेल्या सर्वात मोठ्या गोष्टींवर काम करत आहे.

म्हणून, कोणत्याही प्रकल्पात परीक्षक असले पाहिजेत. हे लोक विशेषतः उत्पादनाकडे वेगवेगळ्या कोनातून पाहण्यास शिकतात. त्यामुळे तुम्ही कार्यक्रमाची अधिक परिस्थिती पाहू शकता. त्यांचे कार्य म्हणजे त्रुटी शोधणे आणि त्या लिहून ठेवणे (जेणेकरुन तीच त्रुटी अनेक वेळा सापडू नये).

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

लक्षात ठेवा, समस्या सोडवण्याची पहिली पायरी म्हणजे समस्या आहे हे मान्य करणे . तुम्हाला माहीत नसलेली चूक तुम्ही दुरुस्त करू शकत नाही.

चाचणी ऑटोमेशन

मला वाटते की चाचणी करणे महत्वाचे आहे यावर आम्ही सर्वांनी सहमती दर्शविली आहे, म्हणून प्रोग्रामरप्रमाणे चाचणी पाहू. प्रोग्रामर चाचणी कशी पाहतात? प्रोग्रामर इतर लोकांचे कार्य स्वयंचलित करतात. गायब होणारा शेवटचा व्यवसाय प्रोग्रामिंग व्यवसाय असेल.

आम्हाला येणाऱ्या कोणत्याही प्रक्रिया आम्ही स्वयंचलित करतो. त्यामुळे चाचणी स्वयंचलित करणे आवश्यक आहे. आणि त्रुटींचा शोध स्वयंचलित कसा करायचा? लहान उत्तर: नाही. पण इथे पुन्हा खरं म्हणजे आम्ही प्रोग्रामर आहोत हे आमच्या मदतीला येते.

सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेमध्ये सतत बदल होतात. फक्त सतत बदल करण्याच्या प्रक्रियेत, प्रोग्रामर बर्‍याचदा असे काहीतरी तोडतात जे अलीकडेपर्यंत चांगले काम करत होते.

आणि परीक्षक, नवीन त्रुटी शोधण्याऐवजी, आम्ही बर्याच काळापासून चांगले कार्य करत असलेले काहीतरी खंडित केले आहे की नाही हे सतत तपासण्यास भाग पाडले जाते. तथाकथित प्रतिगमन चाचणी. या प्रकारची चाचणी स्वयंचलित असू शकते आणि असावी.

येथे सर्व सॉफ्टवेअर दोन भागात विभागले जाऊ शकतात:

• कार्यक्रम व्यक्तीशी संवाद साधतो
• प्रोग्राम दुसर्‍या प्रोग्रामशी संवाद साधतो

पहिला पर्याय स्वयंचलित करणे अधिक कठीण आहे, त्यासाठी विशेष ऑटोमॅटर परीक्षक आवश्यक आहेत, त्यांना QA ऑटोमेशन किंवा सॉफ्टवेअर चाचणी अभियंता देखील म्हणतात.

परंतु दुसरा पर्याय स्वतंत्रपणे स्वयंचलित केला जाऊ शकतो आणि असावा. तुमच्याकडे सॉफ्टवेअरचा भाग असल्यास:

• चांगले कार्य करते
• आधीच चाचणी केली आहे
• स्वतंत्र मॉड्यूल किंवा लॉजिकल ब्लॉक म्हणून अंमलात आणले
• बदलण्याची योजना नाही
• इतर मॉड्यूल किंवा प्रोग्राम त्यावर अवलंबून असतात
• कार्यात्मक अपयश महाग आहे

मी त्याच्या सध्याच्या कार्यक्षमतेचे प्रमुख पैलू कॅप्चर करणार्‍या चाचण्या लिहिण्यासाठी वेळ देण्याची शिफारस करतो. यासाठी तुमच्या कामाच्या वेळेपैकी 5% किंवा दर महिन्याला 1 दिवस वाटप करणे वाजवी असेल.

चाचण्यांसाठी चाचण्या लिहिण्याची गरज नाही.

तुमच्या चाचण्यांना कोणीही पाठिंबा देणार नाही. इतर प्रोग्रामर नाही, स्वतःला नाही. असे कोणी करत नाही. सर्व लेखी चाचण्यांपैकी 99% सोडलेल्या आणि/किंवा अक्षम केल्या आहेत. आपण चाचण्या लिहू शकत नसल्यास - लिहू नका. जर तुम्ही त्यांच्याशिवाय करू शकत नसाल तरच लिहा.

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

प्रत्येक प्रोग्रामर, जर त्याने विशेष प्रशिक्षण घेतले नसेल तर, चाचणी काय आहे हे त्याच्या स्वत: च्या शब्दात सांगण्यास सक्षम असेल: प्रोग्रामने जे केले पाहिजे ते करते की नाही हे तपासणे. तथापि, या क्षेत्रातील व्यावसायिक चाचणीचे संपूर्ण क्षेत्र (प्रकार) वेगळे करतात.

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

समजा तुम्ही एका सामान्य ऑनलाइन स्टोअरची चाचणी करत आहात. नंतर चाचणीची क्षेत्रे खालील प्रकारांमध्ये विभागली जाऊ शकतात: कार्यप्रदर्शन चाचणी, कार्यात्मक चाचणी, एकत्रीकरण चाचणी आणि युनिट चाचणी.

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

हे होण्यापासून रोखण्यासाठी, आपल्याला अशा समस्या अगोदरच ओळखणे आणि त्या दूर करण्यासाठी पावले उचलणे आवश्यक आहे. हे लोड चाचणी वापरून केले जाते किंवा याला कार्यप्रदर्शन चाचणी देखील म्हणतात.

तुमचा बॅकएंड API कसा कार्य करतो याची चाचणी घ्या आणि त्यातील प्रत्येक कार्याची चाचणी घ्या: नोंदणी, लॉगिन, कार्टमध्ये जोडा, पेमेंट प्रक्रिया, डेटाबेस लेखन इ. सर्व काही TOR नुसार कार्य केले पाहिजे. या प्रकरणात, आपल्याला कार्यात्मक चाचणी करणे आवश्यक आहे .

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

शेवटी, जटिल उत्पादने अनेकदा स्वतंत्र मॉड्यूल्समध्ये मोडली जातात. अशा मॉड्यूल्समधून, तुम्ही कन्स्ट्रक्टर प्रमाणे अंतिम उत्पादन एकत्र करू शकता. जर तुम्ही असे मॉड्यूल विकसित करत असाल किंवा अशा मॉड्यूल्सशी संवाद साधत असाल, तर तुम्हाला युनिट चाचणी करणे आवश्यक आहे .

सारांश, आम्ही असे म्हणू शकतो की साइटच्या प्रत्येक वैयक्तिक कार्याची चाचणी घेण्यासाठी कार्यात्मक चाचणी आवश्यक आहे. एकत्रीकरण - आपल्या उत्पादनाच्या मोठ्या मॉड्यूल्स आणि सिस्टमच्या परस्परसंवादाची चाचणी घेण्यासाठी. मॉड्यूलर - वेगळ्या मॉड्यूलची चाचणी घेण्यासाठी, तसेच, कार्यप्रदर्शन चाचणी - लोड अंतर्गत आपल्या साइटचे ऑपरेशन तपासण्यासाठी.

चाचणीचे आणखी प्रकार असू शकतात: उत्पादन जितके अधिक जटिल असेल तितके त्याच्या विकासाचे अधिक पैलू नियंत्रित करणे आवश्यक आहे.