परीक्षण कब रोकें?

Question

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

Comments

जब यह विफल हो जाता है ..

— जेवियर

मुझे लगता है कि आप माइकल बोल्टन के ब्लॉग पोस्ट को पढ़ने के लिए उपयोगी परीक्षण के लिए उत्तराधिकारियों को रोकने के बारे में जानेंगे: http://www.developsense.com/blog/2009/09/when-do-we-stop-test/ आप इनमें से कुछ को पहचान सकते हैं लोगों ने इस सूत्र में सुझाव दिया है।

— टेस्टेरैब

मेरे अनुभव में यह पेरेटो सिद्धांत को लागू करने के लिए पर्याप्त है ।

— अमीर रज़ाई 22

Answer 1

ग्लेनफोर्ड मायर्स की पुस्तक द आर्ट ऑफ़ सॉफ्टवेयर टेस्टिंग में इसके लिए एक सरल लेकिन अच्छी तरह से राजसी नियम है: परीक्षण पूरा हो गया है जब आपने बग ढूंढना बंद कर दिया है। या, अधिक व्यावहारिक रूप से, जब दर जिस पर आपको नए कीड़े मिलते हैं, वह बहुत धीमा हो जाता है।

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

अपनी प्रगति की कल्पना करने के लिए, आपकी टीम ने प्रति दिन कितने बग पाए हैं। यदि चार्ट धीमा हो जाता है, तो आप जानते हैं कि आपकी टीम जिन तकनीकों का उपयोग कर रही है, वे वैसे भी उन्हें खोजने नहीं जा रहे हैं। बेशक, यदि आपको लगता है कि आपकी तकनीकें बराबर नहीं हैं, तो कृपया सिद्धांतों को लागू करने के लिए मायर्स की किताब पढ़ें।

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

Comments

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

— testerab

Answer 2

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

यह वास्तव में एक अच्छे सिस्टम परीक्षक के लिए एक सवाल है (और मैं एक नहीं हूं) लेकिन मैं इसे एक शॉट दूंगा।

आपका मूल उपाय परीक्षण कवरेज होने जा रहा है: आवेदन का वास्तव में कितना परीक्षण किया गया है (दोनों इकाई परीक्षण और कार्यात्मक रूप से)।

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

उस मूल्यांकन के आधार पर आपको यह पता लगाने की आवश्यकता है कि उनमें से कौन सा परीक्षण किया जा रहा है और कितने विस्तार से। एक बार आपके पास इस तरह की एक सूची (टीम एक उत्पाद प्रबंधक / परियोजना प्रबंधक / उपयोगकर्ता प्रतिनिधि सहित) उस सूची से गुजर सकती है और आपके पास मौजूद बाधाओं के आधार पर प्राथमिकता दे सकती है।

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

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

(मुझे लगता है कि यह स्ट्रिपिंग के रूप में संदर्भित है लेकिन मुझे उस पर उद्धृत नहीं करते हैं।)

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

Answer 3

जब सॉफ्टवेयर के उपयोग से जुड़ा जोखिम स्वीकार्य स्तर तक कम हो गया है।

Comments

ठीक है कि समस्या का बयान है, बस rephrased, है ना?

— मार्टिन विकमन 13

@ मर्टिन: जाहिरा तौर पर नहीं। टेस्ट केस 1 के साथ शुरू करने और टेस्ट केस this के साथ समाप्त होने के बजाय, इस उत्तर को प्रश्नकर्ता को सबसे महत्वपूर्ण टेस्ट केस के साथ शुरू करना चाहिए और समाप्त करना चाहिए जब वे अब मूल्य नहीं जोड़ते हैं।

जबकि दार्शनिक रूप से सही (और विचारशील), मुझे लगता है कि ओपी कुछ और अधिक हाथों की तलाश में है।

— मार्टिन विकमन

"स्वीकार्य" को पहले से परिभाषित किया जा सकता है। जो काफी मदद करता है।

@ थोरबजोरन: "परिभाषित किया जा सकता है"। हाँ पर कैसे? वही ओपी की तलाश में है।

— मार्टिन विकमन 18

Answer 4

"कार्यक्रम परीक्षण का उपयोग बग की उपस्थिति दिखाने के लिए किया जा सकता है, लेकिन उनकी अनुपस्थिति को दिखाने के लिए कभी नहीं!" --डिजर डिक्स्ट्रा

किसी भी परीक्षण, स्वचालित या अन्यथा करते समय ध्यान में रखने के लिए कुछ अच्छा है। आप केवल यह साबित कर सकते हैं कि आपको कोई और बग नहीं मिला है, ऐसा नहीं है कि कोई और नहीं है।

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

अनिवार्य रूप से, आप दो बड़े स्थानों में शामिल होना चाहते हैं:

1. क्या सॉफ्टवेयर BDD परीक्षण पास करता है जो यह प्रदर्शित करता है कि यह निर्दिष्ट आवश्यकताओं को पूरा करता है। यदि यह सत्य नहीं है तो सॉफ्टवेयर को कॉल भी नहीं किया जा सकता है।

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

Answer 5

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

Comments

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

— टेस्टरब

Answer 6

यदि आप इकाई परीक्षण के बारे में बात कर रहे हैं और आप टीडीडी (पहले परीक्षण लिख रहे हैं) कर रहे हैं तो यह एक गैर-मुद्दा है: आप सुविधाओं के पूरा होने पर परीक्षण करना बंद कर देते हैं।

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

यहाँ एक बढ़िया उदाहरण है।

Answer 7

सांख्यिकीविदों ने इस मुद्दे पर भी गौर किया है - वास्तव में 1970-80 के दशक की शुरुआत में। बग की खोज कैसे की जाती है, इस पर उपयुक्त धारणा को देखते हुए वे परीक्षण के डेटा से बग की संख्या का अनुमान लगाने की कोशिश करते हैं। इसके बाद यह निर्धारित करने के लिए उपयोग किया जाता है कि हानि फ़ंक्शन के अनुकूलन के आधार पर कब रोकना है। उदाहरण के लिए देखें https://rpubs.com/hoehle/17920 ... व्यवहार में इसे कैसे करें, इस पर R कोड सहित इस मुद्दे पर एक पेपर के एक छोटे से उपचार के लिए।

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

Answer 8

जब शिपिंग की तारीख आ गई है। एक सॉफ्टवेयर के लिए परीक्षण का कोई अंत नहीं है। लेकिन तब फिर से शेड्यूल के रूप में जाना जाता है। आपको निर्धारित समय में अपनी अधिकांश कार्यक्षमता का परीक्षण करना होगा और आपके द्वारा सामना किए जाने वाले बग को ठीक करना होगा। ऐसा कोई तरीका नहीं है जिससे आप गारंटी दे सकें कि सॉफ्टवेयर सही है।

Comments

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

— जॉन हॉपकिंस

यह केवल परीक्षक में एक निश्चित मनोवैज्ञानिक इस्तीफे का उत्पादन करेगा। मैं यह सोचने जा रहा हूं कि "मैं जो भी करता हूं, मैं इस चीज को पूरी तरह से परख नहीं सकता हूं क्योंकि यह जनवरी की तारीख को जहाज पर जा रहा है, वैसे भी बीमार बस तब तक कर सकते हैं जब तक मैं कर सकता हूं"। जिस तरह से हमें सॉफ्टवेयर का निर्माण करना चाहिए वह नहीं है?

— rsman

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

— 14

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

— टेस्टेरैब

Answer 9

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

Answer 10

यह सब विश्वास की बात है। क्या आप आश्वस्त महसूस करते हैं कि सिस्टम का परीक्षण पर्याप्त है?

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

यहाँ कुछ परीक्षण संबंधित "संपन्न-संकेतक" दिए गए हैं:

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

यदि आप इन बिंदुओं की जांच कर सकते हैं, तो आप शायद कह सकते हैं कि आपने पर्याप्त परीक्षण किया है।

Answer 11

कभी नहीं, मुझे लगता है कि आप कभी भी एक सिस्टम में परीक्षण समाप्त नहीं करेंगे .. ऐसे कई चर हैं जिन्हें आप प्रबंधित नहीं कर सकते हैं।

लेकिन, जैसा कि हम जानते हैं, आप "हमेशा के लिए" परीक्षण नहीं कर सकते हैं, इसलिए मुझे लगता है कि सीमा मूल रूप से इस पर निर्भर करती है:

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

Answer 12

जब कि जिन लोगों को तैनाती पर हस्ताक्षर करना है वे संतुष्ट हैं।

या कुछ मामलों में जिम्मेदार पार्टियों के बहुमत संतुष्ट हैं।