स्वचालित परीक्षण के नुकसान क्या हैं?


49

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

यहाँ कुछ है जो मैं लेकर आया हूँ:

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

संपादित करें
मुझे कहना चाहिए कि मैं स्वचालित परीक्षण का एक बड़ा प्रस्तावक हूं, और मैं इसे करने के लिए आश्वस्त नहीं दिख रहा हूं। मैं यह समझने की कोशिश कर रहा हूं कि जब मैं अपनी कंपनी में जाऊंगा, तो इसके लिए एक केस बनाने के लिए मुझे क्या नुकसान होगा क्योंकि मैं ऐसा नहीं लगता कि मैं अगली काल्पनिक चांदी की गोली के आसपास फेंक रहा हूं।

इसके अलावा, मैं अपने उदाहरणों पर विवाद करने के लिए किसी की तलाश नहीं कर रहा हूं । मैं इस बात को सच मान रहा हूं कि कुछ नुकसान भी होने चाहिए (सब कुछ व्यापार-बंद है) और मैं समझना चाहता हूं कि वे क्या हैं।


18
"जटिल विश्लेषण की आवश्यकता है ..." परीक्षण विफलता का कारण नहीं है, यह एक संकेतक है। कोई परीक्षण नहीं होने का मतलब है कि कोई जटिल विफलता विश्लेषण की आवश्यकता नहीं है, जो आपके सिर को कीचड़ में चिपकाने से बेहतर नहीं है।
पी। ब्रायन। मैके 13

1
* अब समय का निर्माण जब परीक्षण हर बिल्ड चलाया जाता है, और दोहराया कोड जब परीक्षण बहुत कम स्तर (परीक्षण गेटर्स और बसने) पर होते हैं
शाफ़्ट सनकी

2
1. यदि कोई डेवलपर नई विशेषताओं का परीक्षण करने के लिए समय का उपयोग कर रहा है, तो उनके विफल होने का जोखिम कम हो गया है, जिसका अर्थ है कि आपका उत्पाद अधिक स्थिर है। 2. टेस्ट-फोकस दृष्टिकोण के लिए अपनी टीम के सदस्यों को शिक्षित करना एक अच्छी बात है, वे इस ज्ञान का उपयोग काम (और जीवन) में अन्य चीजों के लिए कर सकते हैं। 3. परीक्षण वातावरण के लिए एक स्वचालित स्थापना बनाएं 4. यह मुझे बताता है कि 1 परीक्षण बहुत अधिक करता है।
CS01

1
यदि वही डेवलपर वास्तविक कोड को कोड कर रहा है, तो वे केवल उन्हीं परीक्षण मामलों के बारे में सोचेंगे, जिनके लिए वे कोडिंग करते समय परीक्षण के बारे में लिखते थे।
पॉल टॉम्बलिन

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

जवाबों:


26

आप सबसे महत्वपूर्ण लोगों को बहुत पसंद करते हैं। मेरे पास कुछ मामूली जोड़ हैं, साथ ही परीक्षणों का नुकसान वास्तव में सफल हो रहा है - जब आप वास्तव में उन्हें नहीं चाहते हैं (नीचे देखें)।

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

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

  • टूलींग की जरूरत: तुम वहाँ पर हाजिर हो। इससे जोड़ने के लिए ज्यादा नहीं।

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

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

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

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


1
विफल परीक्षणों पर, यदि वर्तमान परीक्षण विफल होने के कारण आवश्यकताओं में परिवर्तन होता है, तो परीक्षण पास हो जाता है क्योंकि पिछला कार्यान्वयन अब मान्य नहीं है, अगर यह विफल नहीं हुआ तो इसका मतलब यह होगा कि कार्यान्वयन आवश्यकताओं को पूरा नहीं करता ...
CS01

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

@ जवाब के लिए धन्यवाद। वहाँ बहुत अंतर्दृष्टि है। मैंने विशेष रूप से विफल परीक्षणों के विभिन्न कारणों के भेदों की सराहना की। अतिरिक्त परिनियोजन लागत एक और उत्कृष्ट बिंदु है।
RationalGeek

मेरे द्वारा पाई जाने वाली मनोरंजक चीज यह है कि मेरा बग प्रति LOC अनुपात परीक्षणों के लिए कहीं अधिक खराब है क्योंकि यह वास्तविक कोड है। मैं वास्तविक लोगों की तुलना में परीक्षण कीड़े खोजने और ठीक करने में अधिक समय बिताता हूं। :-)
ब्रायन नोब्लुच

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

29

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


2
जैसा कि कोई बहुत बड़े विरासत कोड आधार का 80% काम करता है, मैं और अधिक सहमत नहीं हो सकता। हालाँकि, इसे कम करने के लिए, मैंने इसमें से कुछ का उपयोग किया है [लिंक] amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/…
DevSolo

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

21

शायद सबसे महत्वपूर्ण नुकसान है ... परीक्षण उत्पादन कोड हैं । आपके द्वारा लिखा गया प्रत्येक परीक्षण आपके कोडबेस में कोड जोड़ता है जिसे बनाए रखने और समर्थन करने की आवश्यकता होती है। ऐसा करने में विफल रहने से परीक्षण के परिणाम पर विश्वास नहीं होता है, इसलिए आपके पास कोई अन्य विकल्प नहीं है। मुझे गलत मत समझो - मैं स्वचालित परीक्षण का एक बड़ा समर्थक हूँ। लेकिन सब कुछ एक लागत है, और यह एक बड़ा एक है।


अच्छा बिंदु रॉस यह डालने का एक दिलचस्प तरीका है।
तर्कसंगत '28

सहमत हैं, हालांकि मेरे अनुभव में, यूनिट परीक्षणों के कारण समय की बचत होने के कारण नए लिखित कोड (संभावित प्रतिगमन परीक्षण) में संभावित बग ढूंढने के कारण अतिरिक्त रखरखाव समय समाप्त हो गया है।
dodgy_coder

15

मैं यह नहीं कहूंगा कि ये पूरी तरह से लागू होने वाले नुकसान हैं, लेकिन मैंने जो सबसे ज्यादा मारा है:

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

टेस्ट कवरेज जो पैची है, सुरक्षा की झूठी भावना पैदा कर सकता है। यदि आप एक रिफ्लेक्टर करते हैं और यह साबित करने के लिए परीक्षणों का उपयोग करते हैं, तो यह साबित कर दिया है कि आपके परीक्षण क्या साबित कर पाए हैं?

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

बेशक, मेरा दृष्टिकोण एक ऐसे अनुप्रयोग से है जो इकाई परीक्षणों से पुराना है।


ओपी पहले से ही प्रश्न में समय और अप्रचलित कोड को कवर करता है।
पी। ब्रायन। मैके

@ P.Brian.Mackey वास्तव में समय तत्व व्यक्तिपरक है। परीक्षण को कोड करने के लिए लिया गया समय यह समझने के लिए लिया गया समय से अलग है कि परीक्षण की क्या आवश्यकता है और परीक्षण को सही ढंग से कोड करें।
एडम हल्ड्सवर्थ

@AdamHouldsworth धन्यवाद उन नुकसान के कुछ अच्छे उदाहरण हैं। मैंने वास्तव में झूठे विश्वास कोण पर विचार नहीं किया था।
RationalGeek

9

मैं उनके साथ मुख्य समस्या यह कहूंगा कि वे सुरक्षा की झूठी भावना प्रदान कर सकते हैं । सिर्फ इसलिए कि आपके पास यूनिट परीक्षण हैं इसका मतलब यह नहीं है कि वे वास्तव में कुछ भी कर रहे हैं और इसमें आवश्यकताओं का ठीक से परीक्षण शामिल है।

इसके अलावा स्वचालित परीक्षणों में स्वयं बग भी शामिल हो सकते हैं , जिससे यह सवाल उठता है कि क्या यूनिट परीक्षणों को स्वयं परीक्षण करने की आवश्यकता है ताकि कुछ भी हासिल न हो।


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

परीक्षण के लिए कठिन कोड कोड गंध नहीं है। परीक्षण करने के लिए सबसे आसान कोड कक्षाओं के रूप में फ़ंक्शन कॉलिंग की एक विशाल श्रृंखला है।
एरिक रिपेन

4

हालांकि स्वचालन परीक्षण के कई फायदे हैं, इसके अपने नुकसान भी हैं। नुकसान में से कुछ हैं:

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

उपरोक्त कुछ नुकसान अक्सर स्वचालित स्क्रिप्ट से प्राप्त लाभ से घटते हैं। हालांकि स्वचालन परीक्षण में पेशेवरों और कॉर्न्स हैं, लेकिन यह पूरी दुनिया में व्यापक रूप से अनुकूलित है।


धन्यवाद। अच्छे अंक। मैंने आपकी पोस्ट को व्याकरण और प्रारूपण के लिए संपादित किया है। आशा है कि आप बुरा नहीं मानेंगे
RationalGeek

3

मैंने हाल ही में खेल के विकास में परीक्षणों के बारे में एक सवाल पूछा - यह बीटीडब्ल्यू है कि मैं इस बारे में कैसे जानता था। वहां के जवाब कुछ जिज्ञासु, विशिष्ट नुकसान बताते हैं:

  1. जब आपका कोड अत्यधिक युग्मित होना चाहिए, तो ऐसा करना महंगा है
  2. जब आपको विभिन्न हार्डवेयर प्लेटफार्मों के बारे में पता होना चाहिए, तब करना मुश्किल है, जब आपको उपयोगकर्ता को आउटपुट का विश्लेषण करना चाहिए और कोड परिणाम केवल एक व्यापक संदर्भ में समझ में आता है
  3. यूआई और यूएक्स परीक्षण बहुत कठिन है
  4. और विशेष रूप से, बहुत कम लागत (या मुफ्त) बीटा परीक्षक के एक गुच्छा की तुलना में स्वचालित परीक्षण अधिक महंगा और कम प्रभावी हो सकते हैं

4 वाँ बिंदु मुझे मेरे कुछ अनुभव के बारे में याद दिलाता है। मैंने बहुत दुबले-पतले, एक्सपी-ओरिएंटेड, स्क्रैम प्रबंधित कंपनी पर काम किया जहां यूनिट परीक्षणों की अत्यधिक सिफारिश की गई थी। हालांकि, एक दुबला, कम नौकरशाही शैली के अपने रास्ते में, कंपनी ने सिर्फ क्यूए टीम के निर्माण की उपेक्षा की - हमारे पास कोई परीक्षक नहीं था। तो अक्सर ग्राहकों को कुछ प्रणालियों का उपयोग करते हुए तुच्छ कीड़े मिले, यहां तक ​​कि>> 95% के परीक्षण कवरेज के साथ। इसलिए मैं एक और बिंदु जोड़ूंगा:

  • स्वचालित परीक्षण आपको महसूस कर सकते हैं कि क्यूए और परीक्षण महत्वपूर्ण नहीं हैं।

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

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

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


3

दो जिसका उल्लेख नहीं किया गया है:

  • क्लॉक टाइम की लंबाई एक बड़े टेस्ट सूट को चलाने में लग सकती है

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

  • कुछ परीक्षण लेखन विधियों की विफलता

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

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


2

मैं एक और जोड़ना चाहता हूं, सुरक्षा की झूठी भावना।

बहुत छोटी अच्छी तरह से परिभाषित समस्या सेट से परे, व्यापक परीक्षण बनाना संभव नहीं है। हमारे सॉफ़्टवेयर में अभी भी अक्सर कीड़े हो सकते हैं जो स्वचालित परीक्षण केवल परीक्षण नहीं करते हैं। जब स्वचालित परीक्षण पास हो जाते हैं तो हम सभी अक्सर मान लेते हैं कि कोड में कोई बग नहीं हैं।


0

प्रबंधन / उद्यम पूंजीवादी को समझाना कठिन है

  • testautomation से अग्रिम लागत बढ़ती है।
  • testautomation से बाजार में समय बढ़ता है।
  • Testautomation का लाभ मध्य और लोगो में आता है। भयंकर प्रतिस्पर्धा कम लाभ पर अधिक ध्यान केंद्रित करती है।

देख बाजार यूनिट टेस्टिंग प्रेरित जानकारी के लिए।


-1

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.