हम कैसे निश्चित हो सकते हैं कि कंप्यूटर प्रोग्रामिंग के निचले घटक जैसे कि कंपाइलर, कोडांतरक, मशीन निर्देश आदि निर्दोष हैं?

Question

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

अधिक तकनीकी रूप से, संकलक और कोडांतरक का परीक्षण कैसे किया जाता है? (मुझे लगता है कि यह रुकने की समस्या से संबंधित है !!

Comments

आप "केन थॉम्पसन हैक" के साथ ट्रस्ट पर भरोसा करना

— ब्रायन ओकले

यहाँ एक संकलक का एक उदाहरण है जिसके लिए एक शुद्धता प्रमाण है: compcert.inria.fr/doc/index.html

— जियोर्जियो

अधिकांश कंपाइलर / लिंकर्स / असेंबलर को बहुत अलग परिस्थितियों में बहुत अधिक उपयोग करके सबसे गहराई से परीक्षण किया जाता है। त्रुटियों को खोजने के लिए, आपके कंपाइलर का उपयोग करने वाले लाखों उपयोगकर्ताओं के ऊपर कुछ भी नहीं है।

— बार्ट वैन इनगेन शेनौ

और ऑपरेटिंग सिस्टम को सूची में जोड़ें, साथ ही।

— एरिक Eidt

संबंधित: कैसे आ संकलक इतने विश्वसनीय हैं? और क्या कंपाइलर और दुभाषियों के पास बग हो सकते हैं, और हम (उपयोगकर्ताओं के रूप में) उनसे निपटने के लिए क्या कर सकते हैं?

Answer 1

आप निश्चित नहीं हो सकते हैं, लेकिन आप केवल यह मानते हैं कि वे हैं, जब तक आपको पता नहीं चलता कि वे नहीं हैं। पिछले कुछ वर्षों में कंपाइलर और हार्डवेयर में काफी बग हैं।

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

SQLite में कोड की लगभग 73k लाइनें होती हैं, जबकि इसके टेस्ट सूट में कोड 91378k लाइनों के बारे में होता है, जो SQLite के 1250x गुना से भी ज्यादा होता है। मुझे उम्मीद है कि संकलक और अन्य मुख्य उपकरण समान अनुपात हैं। वेरिलोग या वीएचडीएल जैसी हार्डवेयर विवरण भाषाओं का उपयोग करके आज प्रोसेसर को सॉफ्टवेयर के साथ अनिवार्य रूप से डिज़ाइन किया गया है, और जिनके पास सॉफ्टवेयर परीक्षण हैं, साथ ही निर्माण के बिंदु पर स्वयं परीक्षण चलाने के लिए विशेष IO पिन भी हैं।

अंतत: यह एक प्रायिकता का खेल है, और बार-बार और मोटे तौर पर परीक्षण को कवर करने से आप दोषों की संभावना को एक निम्न स्तर तक ले जा सकते हैं, अन्य सॉफ्टवेयर परियोजना के समान।

Comments

मैंने अक्सर ओपी के रूप में एक ही प्रश्न सोचा है, लेकिन डीबीएमएस के संबंध में। आपने एक बेहतरीन उदाहरण दिया, जिसने इसे SQLite के संदर्भ में उत्तर दिया। धन्यवाद!

— ब्रैंडन

+1 लेकिन किसी तरह मुझे संदेह है कि "संकलक और अन्य मुख्य उपकरण समान अनुपात हैं"।

— मेहरदाद

ध्यान दें कि (1) SQLite में वास्तव में दो परीक्षण सूट हैं, दोनों के बीच गैर-तुच्छ अतिरेक के साथ और (2) इसके बावजूद अभी भी SQLite में बग पाए गए हैं।

— मैथ्यू एम।

मैं इस धारणा के अधीन रहा हूं कि SQLite सामान्य उपयोग के लिए उपलब्ध सॉफ़्टवेयर के सबसे "बड़े पैमाने पर परीक्षण किए गए" टुकड़ों (परीक्षण कोड / परिचालनात्मक कोड की पंक्तियों के संदर्भ में) में से एक है, बहुत सारे कंपाइलर से भी अधिक। अगर और कुछ नहीं, एक पूर्ण विशेषताओं वाला कंपाइलर सॉफ्टवेयर का एक बड़ा टुकड़ा है, और मैं इसकी कल्पना नहीं कर सकता कि यह परीक्षण कोड की एक हजार गुना राशि है। (जीसीसी 14.5 मिलियन लाइनों को कथित तौर पर है यह संभावना नहीं लगता है कि या तो संकलक संग्रह उचित केवल 14k एलओसी है, या वे एक 14 अरब लाइन परीक्षण codebase पक्ष पर चारों ओर बैठे है :-P।!)

— डेविड जेड

@ डेविड: यह है, यह निश्चित रूप से एकमात्र परियोजना है जिसे मैं उदाहरण के लिए व्यापक ओओएम परीक्षण का उपयोग करना जानता हूं (वे परीक्षण के लिए एक दोष इंजेक्टर का उपयोग करते हैं और उन्हें फिर से दोहराते हैं और फिर से पहली बार असफल हो जाते हैं, फिर 2 आवंटन ... पूरे परीक्षण तक निष्पादित किया जाता है)।

— मैथ्यू एम।

Answer 2

आम आदमी की शर्तों में:

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

जमीनी स्तर:

मैं कहूंगा कि OOP ( O ld, O pen और P opular) के लिए जाना चाहिए। मैंने अभी उस संक्षिप्त को बनाया है।

Comments

+1 एक और TLA (तीन अक्षर का संक्षिप्त नाम) का आविष्कार करने के लिए - दुनिया के पास उनमें से अभी तक पर्याप्त नहीं है।

— s1lv3r

इसके अलावा, कंप्यूटर प्रोग्रामिंग में OOP का कोई मतलब नहीं था। तो KTT (आप के लिए यश)!

— पियरे अरलाउड

पियरे की टिप्पणी एक मजाक @Dannnno है।

— यानिस

वैकल्पिक रूप से, यह P opular, O ld, और O pen सकता है। ;) वास्तव में, यह है कि मैं उन्हें महत्व के क्रम में कैसे रैंक करूंगा।

— jpmc26

@ jpmc26 मैं प्रैक्टिकल, ओल्ड, ओपन और पॉपुलर के साथ जाऊंगा। जैसा कि के लिए ...

— स्टुपिडो

Answer 3

यह सभी तरह से नीचे कछुए है।

कुछ भी निश्चित नहीं है। विश्वास रेटिंग पर समझौता करने के अलावा आपके पास कोई विकल्प नहीं है।

आप इसे एक स्टैक के रूप में सोच सकते हैं: गणित> भौतिकी> हार्डवेयर> फर्मवेयर> ऑपरेटिंग सिस्टम> असेंबलर / कंपाइलर / आदि

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

मुश्किल हिस्सा इन परीक्षणों में से कुछ में पुनरावृत्ति को उजागर कर रहा है क्योंकि हम अब सबूत और अवलोकन विश्लेषण करने के लिए कार्यक्रमों का उपयोग करते हैं जहां हाथ से ऐसा करना बहुत मुश्किल हो गया है।

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

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

Answer 4

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

ज्यादातर सी, सी ++ और जावा में प्रोग्रामिंग के 25+ वर्षों में मैंने पाया है:

• एक कंपाइलर बग (gcc और SunOS C) के कारण दो बग
• जावा जेवीएम समस्या (आमतौर पर मेमोरी खपत / कचरा संग्रह से संबंधित) के कारण हर साल या दो बार बग के बारे में
• लाइब्रेरी में हर महीने या दो बार एक बग के बारे में, जो अक्सर नवीनतम संस्करण का उपयोग करके या लाइब्रेरी के पूर्व संस्करण पर वापस लौटकर तय होता है

अन्य सभी कीड़े सीधे बग से संबंधित हैं या अधिक बार, लाइब्रेरी कैसे काम करती है, यह समझने की कमी है। कभी-कभी जो लगता है कि एक बग एक असंगति के कारण है, उदाहरण के लिए जावा वर्ग संरचना कैसे बदल गई जिसने कुछ एओपी पुस्तकालयों को तोड़ दिया।

Comments

मैं उत्सुक हूं - कौन सी भाषाएं किस वर्ष के लिए? ईजीसीएस में सी ++ से पहले के दिनों को ठीक से मानकीकृत किया गया था, संकलक कीड़े को खोजने के लिए इतना कठिन नहीं था ...

— चार्ल्स डफी

कम्पाइलर, सीपीयू या भाषा को जितना अधिक अस्पष्ट किया जाए उतना आसान है कि यह कंपाइलर्स में बग ढूंढे (किसी और से पहले) इसलिए GCC C में 2 ढूंढना अच्छा है :)

— Surt

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

— Arlie Stephens

बेशक यह संकलक बग नहीं था , या यहां तक ​​कि आमतौर पर उपयोग किए जाने वाले पुस्तकालयों में से एक। और सच कहूं, तो मैं उन लोगों के साथ किसी भी आवृत्ति पर बग नहीं ढूंढता।

— अरली स्टीफेंस

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

— jpmc26

Answer 5

मुझे लगता है कि यहां एक दिलचस्प बात यह है कि वाणिज्यिक सॉफ़्टवेयर (और वास्तव में ओपन सोर्स सॉफ़्टवेयर) के विशाल बहुमत विशेष रूप से निर्दिष्ट करते हैं कि आप सॉफ़्टवेयर पर भरोसा नहीं कर सकते।

सॉफ़्टवेयर किसी भी प्रकार, किसी भी तरह की वारंटी के बिना "IS" के रूप में प्रदान किया जाता है, जो कि एक राज्य सरकार, और गैर-बैंकिंग प्रबंधन के लिए आतंकवादियों के कल्याण के लिए सीमित नहीं है।

Microsoft Word लाइसेंस समझौते से

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

संक्षेप में इस वाक्य को लाइसेंस में लगभग हर सॉफ्टवेयर में जो आप उपयोग करते हैं, वह आपको बताता है कि आप उस सॉफ्टवेयर पर भरोसा नहीं कर सकते जिसे अकेले संकलक इस्तेमाल करते हैं।

सॉफ्टवेयर एक वैज्ञानिक सिद्धांत की तरह है, इसे तब तक काम करने के लिए समझा जाता है जब तक कि यह बंद न हो जाए।

Comments

+1 यह इंगित करने के लिए कि बहुत ही लाइसेंस बताता है कि कोई भी सॉफ्टवेयर सही नहीं है।

— ट्यूलेंस कोरडोवा

मैक के लिए IBM के ViaVoice में इस अभ्यास से एक विचलन को नोट करने के लिए मुझे आभार व्यक्त किया गया था। प्रथागत "के बजाय अगर यह काम नहीं करता है, तो बहुत बुरा" वे वास्तव में कुछ ऐसा कहते हैं जैसे "सॉफ़्टवेयर को निर्दिष्ट के रूप में प्रदर्शन करने के लिए वारंट किया गया है।"

— WGroleau

इस विशेष बिट वारंटी के सादे भाषा का अनुवाद है, "यह सॉफ़्टवेयर का एक टुकड़ा हो सकता है, या यह sh * t का एक टुकड़ा हो सकता है। यह काम कर सकता है। यह नहीं भी हो सकता है। भले ही यह काम करता हो। आप जो चाहते हैं, करो। ओह-बाय-वे, हमने किसी और से इसके बिट्स चुराए होंगे। बहुत बुरा। हमने आपका पैसा ले लिया है और इसका इस्तेमाल बहुत सारे वकीलों को काम पर रखने के लिए किया है। GAME! ON! Nyah-nyah -nyah-Nyah-nyaaah-naah! "। :-)

— बॉब जार्विस

@ याकूब जार्विस: मेरे पसंदीदा वारंटी स्टेटमेंट, जिसका इस्तेमाल कुछ ओपन सोर्स सॉफ्टवेयर (जैसे नैम IIRC) पर किया जाता है, "यदि यह टूटता है, तो आपको दोनों टुकड़े रखने के लिए मिलते हैं"।

— पीटर कॉर्डेस

यह कथन ओपन सोर्स सॉफ़्टवेयर में सर्वव्यापी है, और बहुत सारे नो-कॉस्ट बंद स्रोत सॉफ़्टवेयर हैं। यह अधिकांश व्यावसायिक भुगतान किए गए सॉफ़्टवेयर लाइसेंसों में दिखाई नहीं देता है।

— jwg

Answer 6

एक गणित भाषा के लिए एक संकलक लेखक के रूप में *, अपने अनुभव से मैं कह सकता हूं कि सिद्धांत में आप नहीं कर सकते। और कुछ कीड़े सिर्फ गलत परिणाम देते हैं जैसे (मेरी शर्म की सूची से) 6/3*2सही से गणना करना 6/(3*2)और दुर्घटनाग्रस्त हुए या निरर्थक संकलन त्रुटियों को दिए बिना 1 आउटपुट करना।

लेकिन IMHO कई कंपाइलरों में अन्य सॉफ़्टवेयर के समान कीड़े नहीं हैं क्योंकि:

• इकाई परीक्षण लिखना आसान है। प्रत्येक कथन एक इकाई है और आप परीक्षण को सरल रूप में लिख सकते हैं:test_unit("2+(-2)*(-2+1)*3+1",9);
• एक कार्यक्रम बयानों का एक संयोजन है और किसी भी कार्यक्रम के लिए सही परिणाम के उत्पादन के लिए प्रत्येक व्यक्ति के बयान को सही परिणाम (अधिकतर) देना होगा। तो यह बहुत ही संभावना नहीं है कि किसी भी कीड़े हो, जबकि कार्यक्रम सही परिणाम देता है।
• जैसे-जैसे लिखित कार्यक्रमों का आकार और संख्या बढ़ती है, वैसे-वैसे बग को पकड़ने की संभावना नाटकीय रूप से बढ़ जाती है।

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

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

संक्षेप में, संकलक, मशीन कोड आदि में गंभीर कीड़े होने की संभावना नहीं है।

मेरी विनम्र गणित भाषा *

Comments

इंटेल यादृच्छिक निर्देशों के अनुक्रम चलाकर और अन्य चीजों के साथ एक सॉफ्टवेयर मॉडल के साथ तुलना करके अपने CPUs से नरक का परीक्षण करता है: tweakers.net/reviews/740/4/… । यही कारण है कि आप अक्सर एक असामान्य मोड में निर्देशों के कुछ अप्रत्याशित संयोजन के लिए अक्सर अस्पष्ट इरेटा प्रकाशित देखते हैं।

— पीटर कॉर्डेस

Answer 7

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

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

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

Answer 8

यह दिखाने के लिए कि अंतर्निहित सिस्टम या तो निर्दोष हैं

क) सबूत की जरूरत है कि वे निर्दोष हैं

1. गणितीय प्रमाण
2. तुच्छ कार्यक्रमों के लिए केवल वास्तविक रूप से संभव है

बी) एक संपूर्ण परीक्षण करें

1. केवल तुच्छ कार्यक्रमों और कुछ सरल कार्यक्रमों के लिए ही संभव है
2. जैसे ही कोई टाइमिंग तत्व टेस्ट में प्रवेश करता है वैसे ही एग्जॉस्ट टेस्ट करना संभव नहीं होता क्योंकि समय को अनिश्चित रूप से विभाजित किया जा सकता है।
3. तुच्छ कार्यक्रमों से परे संभावित निष्पादन विकल्प तेजी से विस्फोट होते हैं।

सॉफ्टवेयर परीक्षण में संपूर्ण परीक्षण केवल कुछ सरल कार्यों की इकाई परीक्षण में उपयोग किया जाता है।

उदाहरण: आप किसी क्षेत्र में 8 वर्ण utf-8 इनपुट का परीक्षण करना चाहते हैं, आप इनपुट को कट करने के लिए 8 गुना बाइट्स में utf-8 की अधिकतम लंबाई 6 गुना करने का विकल्प बनाते हैं जो वास्तव में 8 * 6 = 48 बाइट देता है संभावनाओं की परिमित मात्रा।

अब आप सोच सकते हैं कि आपको केवल 8 वर्णों में से प्रत्येक के 1,112,064 वैध कोड बिंदुओं का परीक्षण करने की आवश्यकता है , अर्थात। 1,112,064 ^ 8 (कहते हैं 10 ^ 48) परीक्षण (जो पहले से ही संभव नहीं है), लेकिन आपको वास्तव में 48 बाइट्स या 256 ^ 48 में से प्रत्येक के प्रत्येक मूल्य का परीक्षण करना होगा जो लगभग 10 ^ 120 है जो शतरंज के समान ही जटिलता है लगभग 10 ^ 80 के ब्रह्मांड में परमाणुओं की कुल संख्या की तुलना में।

इसके बजाय आप उपयोग कर सकते हैं, प्रयास के बढ़ते क्रम में और प्रत्येक परीक्षण में पिछले सभी को शामिल करना चाहिए:

a) एक अच्छे और बुरे नमूने का परीक्षण करें।

बी) कोड कवरेज, यानी। कोड की प्रत्येक पंक्ति का परीक्षण करने का प्रयास करें, जो कि अधिकांश कोड के लिए सापेक्ष सरल है। अब आप आश्चर्य कर सकते हैं कि आपके द्वारा परीक्षण नहीं किया जा सकने वाला कोड का अंतिम 1% क्या है ... बग, मृत कोड, हार्डवेयर अपवाद आदि।

ग) पथ कवरेज, सभी संयोजनों में सभी शाखाओं के सभी परिणामों का परीक्षण किया जाता है। अब आप जानते हैं कि जब आपके कार्यों में 10 से अधिक शर्तें होती हैं तो परीक्षण विभाग आपसे घृणा क्यों करता है। इसके अलावा आपको आश्चर्य है कि अंतिम 1% का परीक्षण क्यों नहीं किया जा सकता है ... कुछ शाखाओं को पिछली शाखाओं पर निर्भर किया गया है।

डी) डेटा परीक्षण, सीमा मूल्य, सामान्य समस्याग्रस्त मूल्यों और जादू की संख्या, शून्य, -1, 1, न्यूनतम +/- 1, अधिकतम +/- 1, 42, rnd मान के साथ कई नमूने का परीक्षण करें। यदि यह आपको पथ कवरेज नहीं देता है, तो आप जानते हैं कि आपने अपने विश्लेषण में सभी मूल्यों को नहीं पकड़ा है।

यदि आप पहले से ही ऐसा करते हैं तो आपको ISTQB फाउंडेशन परीक्षा के लिए तैयार होना चाहिए।