इकाइयाँ
1. सॉफ्टवेयर परीक्षण और क्यूए में आर्टिफिशियल इंटेलिजेंस का परिचय: भूमिकाएं, सीमाएं, नकली जोखिम और मान्यता 2. परीक्षण परिदृश्य और परीक्षण केस निर्माण: आवश्यकता से व्यापक नियंत्रण तक 3. खोजपूर्ण परीक्षण और परीक्षण आइडिया जेनरेशन: एआई के साथ क्रिएटिव बग हंटिंग 4. यूआई टेस्ट ऑटोमेशन: एआई के साथ सेलेनियम, नाटककार और साइप्रस कोड उत्पन्न करना 5. एपीआई परीक्षण स्वचालन: एआई के साथ अनुबंध, स्कीमा और एंड-टू-एंड सत्यापन 6. यूनिट टेस्ट जेनरेशन और टेस्टेबिलिटी: एआई के साथ मजबूत परीक्षण 7. त्रुटि रिपोर्ट लेखन और प्राथमिकता: एआई के साथ स्पष्ट, प्रतिलिपि प्रस्तुत करने योग्य रिकॉर्ड 8. परीक्षण कवरेज विश्लेषण और जोखिम-आधारित परीक्षण: एआई के साथ सही निशाना लगाना 9. प्रतिगमन परीक्षण, परीक्षण रखरखाव, और नाजुक परीक्षणों का मुकाबला 10. मिथ्या-विश्वास जोखिम, परीक्षण गुणवत्ता, और उत्परिवर्तन परीक्षण: परीक्षण परीक्षण 11. एंड-टू-एंड वर्कफ़्लो, सीआई/सीडी एकीकरण, नैतिकता और सुरक्षा: एआई का जिम्मेदारी से उपयोग करना
इकाई 10 / 11

मिथ्या-विश्वास जोखिम, परीक्षण गुणवत्ता, और उत्परिवर्तन परीक्षण: परीक्षण परीक्षण

लाभ:

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

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

परीक्षण की गुणवत्ता मापने का स्वर्ण मानक: उत्परिवर्तन परीक्षण

यह समझने का सबसे शक्तिशाली तरीका है कि कोई परीक्षण वास्तव में सुरक्षा करता है या नहीं, उत्परिवर्तन परीक्षण है (उत्परिवर्तन परीक्षण - एक तकनीक जो स्रोत कोड में जानबूझकर छोटी विकृतियाँ/उत्परिवर्तन पैदा करती है और मापती है कि परीक्षण इन विकृतियों का पता लगाते हैं या नहीं)। तर्क सरल है: यदि आप जानबूझकर कोड को तोड़ते हैं (a + को -, a > को >=, a को false में बनाते हैं), तो एक अच्छे परीक्षण सूट को उस भ्रष्टाचार को पकड़ना चाहिए और लाल हो जाना चाहिए। यदि ऐसा नहीं होता है, तो वह व्यवधान एक जीवित उत्परिवर्ती है - इसलिए आपके परीक्षण वास्तव में उस व्यवहार को संरक्षित नहीं कर रहे हैं।

उत्परिवर्तन स्कोर = उत्परिवर्तन समाप्त/कुल उत्परिवर्तन। 90% लाइन कवरेज वाले पैकेज में उत्परिवर्तन स्कोर 40% हो सकता है; यह इंगित करता है कि लाइनें काम कर रही हैं लेकिन व्यवहार सत्यापित नहीं है। म्यूटेशन स्कोर प्रतिशत कवरेज की तुलना में गुणवत्ता का कहीं अधिक ईमानदार माप है।

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

छद्म विश्वास के तीन चेहरे और उसका मारक

छद्म-भरोसा रूप

लक्षण

मारक

बिना दावे के परीक्षण करें

कोड काम करता है, कुछ भी मान्य नहीं है

हर परीक्षा में सच्चा दावा; उत्परिवर्तन के साथ परीक्षण करें

स्व-पुष्टि परीक्षण

अपेक्षित = कोड का आउटपुट

अपेक्षित मूल्य की स्वतंत्र रूप से गणना करें

तुच्छ दावा

"शून्य नहीं", "200 लौटे"

व्यावसायिक नियम/वास्तविक परिणाम को मान्य करें

उच्च गुंजाइश वाली भ्रांति

90% लाइनें, कम सुरक्षा

म्यूटेशन स्कोर देखें

नाजुक परीक्षण सहनशीलता

"फिर अटक गया, पास हो जाओ"

मूल कारण + नियतात्मक परीक्षण

AI को "रेड टीम" के रूप में उपयोग करना

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

सावधानी: एआई से यह न पूछें "क्या मेरी परीक्षण गुणवत्ता अच्छी है?" और उत्तर "हाँ, बढ़िया" को आश्वासन के रूप में लें। एआई दयालु होता है। इसके बजाय, एआई को एक ठोस कार्य के लिए चुनौती दें: "एक बग तैयार करें जो इन परीक्षणों को पास कर ले।" यदि यह इसे उत्पन्न कर सकता है, तो आपके परीक्षण उस त्रुटि के प्रति अंधे हैं।

समतुल्य उत्परिवर्तन और स्कोर की सीमाएँ

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

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

सावधानी: उत्परिवर्तन परीक्षण कम्प्यूटेशनल रूप से महंगा है (प्रत्येक उत्परिवर्तन के लिए सभी प्रासंगिक परीक्षण दोबारा चलाए जाते हैं)। इसलिए एक सामान्य और उचित रणनीति यह है कि इसे प्रत्येक मर्ज के बजाय महत्वपूर्ण मॉड्यूल के लिए साप्ताहिक या प्री-रिलीज़ गहन जांच के रूप में शेड्यूल किया जाए।

कमजोर संकेत/मजबूत संकेत

कमज़ोर: "क्या मेरे परीक्षण पर्याप्त हैं?"
मजबूत: "इस फ़ंक्शन और परीक्षण सूट के लिए एक लाल टीम के रूप में कार्य करें। (1) कोड में 8 उत्परिवर्तन उत्पन्न करें जिन्हें मारा जा सकता है (ऑपरेटर प्रतिस्थापन, सीमा बदलाव, स्थिति उलटा, वापसी मूल्य प्रतिस्थापन)। (2) प्रत्येक उत्परिवर्तन के लिए, इंगित करें कि मौजूदा परीक्षणों में से कौन सा इसे पकड़ लेगा और कौन सा नहीं। (3) प्रत्येक उत्परिवर्तन के लिए जो बच जाता है, एक नया परीक्षण लिखें जो इसे मार देगा। (4) यह भी दिखाएं कि क्या आप एक कोड उदाहरण तैयार कर सकते हैं जो इन सभी परीक्षणों को पास करता है लेकिन व्यापार नियम का उल्लंघन करता है। कोड+परीक्षण: [पेस्ट करें]"

शक्तिशाली संकेत; यह एआई को परीक्षण तोड़ने वाले परीक्षक के रूप में रखता है, प्रशंसा मशीन के रूप में नहीं।

चार प्रतिलिपि योग्य टेम्पलेट

1) मैनुअल उत्परिवर्तन नियंत्रण:

इस कोड के लिए 8 महत्वपूर्ण उत्परिवर्तन (मामूली जानबूझकर व्यवधान) उत्पन्न करें: अंकगणितीय ऑपरेटर प्रतिस्थापन, तुलना सीमा (> बनाम >=), तार्किक उलटा, वापसी/निरंतर प्रतिस्थापन, स्थिति लंघन। प्रत्येक उत्परिवर्तन के लिए, अनुमान लगाएं कि कौन से उपलब्ध परीक्षण इसे पकड़ पाएंगे या नहीं। कोड+परीक्षण: [पेस्ट करें]

2) जीवित उत्परिवर्तन को मारना:

निम्नलिखित उत्परिवर्तन परीक्षण रिपोर्ट में जीवित (अनदेखे) उत्परिवर्तन शामिल हैं: [सूची/रिपोर्ट]। प्रत्येक के लिए, एक न्यूनतम परीक्षण लिखें जो उस उत्परिवर्तन को समाप्त कर देगा (इस तरह से तोड़ने पर कोड लाल हो जाएगा)। परीक्षण किस व्यवहार की पुष्टि करता है, इस पर टिप्पणी करें।

3) रेड टीम - रक्त परीक्षण:

क्या आप ऐसा कोड लिख सकते हैं जो निम्नलिखित सभी परीक्षणों को पास करता है, लेकिन निम्नलिखित व्यावसायिक नियम का उल्लंघन करता है: [व्यावसायिक नियम]। यदि हां, तो इन परीक्षणों में कौन सी खामी इसकी अनुमति देती है? वह परीक्षण जोड़ें जो उस खामी को बंद कर देगा। परीक्षण: [पेस्ट करें]

4) परीक्षण गुणवत्ता निरीक्षण:

गुणवत्ता के लिए इस परीक्षण सूट की जाँच करें। प्रत्येक परीक्षण के लिए टिक करें: - क्या कोई सच्चा दावा है या यह प्रॉप्स है? - क्या अपेक्षित मूल्य स्वतंत्र है, कोड से प्राप्त होता है? - क्या यह व्यवसाय नियम या कुछ तुच्छ को सत्यापित करता है? अंत में एक अनुमानित "सच्चा दावा स्कोर" और 3 सबसे कमजोर परीक्षण दें। परीक्षण: [पेस्ट करें]

तीन मिनी मामले

केस 1 - कवरेज 92%, उत्परिवर्तन स्कोर 38%। एक टीम ने उच्च कवरेज पर भरोसा किया। जब स्ट्राइकर के साथ उत्परिवर्तन परीक्षण चलाया गया, तो स्कोर 38% था: उत्पादित अधिकांश उत्परिवर्तन जीवित रहे। यह इस बात का प्रमाण था कि परीक्षण लाइनें नहीं चला रहे थे और व्यवहार की पुष्टि नहीं कर रहे थे। टीम ने गुणवत्ता परीक्षण में तीन सप्ताह का निवेश किया; उत्परिवर्तन स्कोर बढ़कर 81% हो गया, और अगली रिलीज़ में इन उन्नत परीक्षणों द्वारा दो वास्तविक गणना त्रुटियाँ पकड़ी गईं।

केस 2 - एआई ने परीक्षण में धोखा दिया। "रेड टीम" टेम्पलेट के साथ, एक विशेषज्ञ ने एआई से वह कोड मांगा जो मौजूदा परीक्षणों में उत्तीर्ण हुआ लेकिन छूट नियम का उल्लंघन किया। एआई ने कोड लिखा जो हमेशा शून्य की छूट लौटाता था - और सभी परीक्षण हरे रहे क्योंकि कोई भी परीक्षण वास्तविक छूट मूल्य की पुष्टि नहीं कर रहा था। अंतर देखा गया, वास्तविक दावे जोड़े गए।

केस 3 - प्रशंसा जाल। एक जूनियर परीक्षक ने एआई से पूछा, "क्या मेरे परीक्षण अच्छे हैं?" और उत्तर सुनकर राहत महसूस हुई, "बहुत व्यापक।" उनके वरिष्ठ सहयोगी ने "टेस्ट क्वालिटी ऑडिट" टेम्पलेट का उपयोग करके उन्हीं परीक्षणों का ऑडिट किया था; यह पता चला कि 20 में से 12 परीक्षण सजावट (बिना दावे या कबाड़ के) थे। सही प्रश्न सही उत्तर लेकर आया।

सामान्य गलतियां

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

सारांश

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

आवेदन कार्य

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

जांच सूची

  • [ ] मैंने परीक्षण गुणवत्ता का मूल्यांकन म्यूटेशन स्कोर के आधार पर किया, कवरेज के आधार पर नहीं।
  • [ ] मैंने महत्वपूर्ण कोड के लिए उत्परिवर्तन परीक्षण (या तो उपकरण द्वारा या मैन्युअल रूप से) चलाया।
  • [ ] मैंने प्रत्येक जीवित उत्परिवर्तन के लिए नए परीक्षण लिखे।
  • [ ] मैंने एआई को रेड टीम के रूप में इस्तेमाल किया और अपने परीक्षणों में कमियां ढूंढीं।
  • [ ] मैंने एआई की "आपके परीक्षण अच्छे हैं" प्रशंसा को आश्वासन के रूप में नहीं लिया।
  • [ ] मैंने जाँच की कि प्रत्येक परीक्षण वास्तविक दावे, स्वतंत्र अपेक्षित मूल्य और व्यावसायिक नियम की पुष्टि करता है।