क्या सॉफ्टवेयर परीक्षण के कोई औपचारिक / गणितीय सिद्धांत हैं?

12

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

मैं जो कुछ खोज रहा हूं वह कुछ ऐसा है जो परीक्षण करता है कि औपचारिकता है, जिन धारणाओं का उपयोग किया गया है, एक परीक्षण का मामला क्या है, कुछ परीक्षण करने की व्यवहार्यता, कुछ परीक्षण करने की व्यावहारिकता, किस हद तक कुछ परीक्षण किया जाना चाहिए, औपचारिक परिभाषा / स्पष्टीकरण कोड कवरेज, आदि।

अद्यतन: इसके अलावा, मुझे यकीन नहीं है, सहज ज्ञान युक्त, औपचारिक सत्यापन और मैंने जो पूछा उसके बीच संबंध के बारे में, लेकिन स्पष्ट रूप से कुछ प्रकार के कनेक्शन हैं।

— एरिक कपलुन
स्रोत

1

सॉफ्टवेयर परीक्षण बहुत मूल्यवान है (जैसे इकाई परीक्षण को अभ्यास में लाना) लेकिन इसके सिद्धांत में हमेशा कुछ छेद होंगे। इस शास्त्रीय उदाहरण पर विचार करें: double pihole(double value) { return (value - Math.PI) / (value - Math.PI); }जो मैंने अपने गणित शिक्षक से सीखा है । इस कोड में ठीक एक छेद है , जिसे ब्लैक-बॉक्स परीक्षण से अकेले नहीं खोजा जा सकता है। मठ में ऐसा कोई छिद्र नहीं है। यदि आप एकतरफा सीमा के बराबर हैं, तो पथरी में आपको छेद को बंद करने की अनुमति है।

— rwong

4

- यह आप के लिए क्या देख रहे का हिस्सा हो सकता en.wikipedia.org/wiki/Formal_verification

— enderland

1

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

— डोभाल

चूंकि मैंने स्वयं को औपचारिक प्रकारों के माध्यम से आश्रित प्रकारों के माध्यम से परिचित किया है, और मैं पूरी तरह से @ डोवल और एंडरलैंड से सहमत हो सकता हूं।

— एरिक कपलुन

1

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

— दिमित्री जैतसेव

8

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

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

— डकोटा उत्तर
स्रोत

5

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

परीक्षण मोड

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

एक परीक्षण मामला एक ज्ञात वातावरण है जिसमें कोड का एक टुकड़ा निष्पादित किया जाता है, उदाहरण के लिए विशिष्ट परीक्षण इनपुट का उपयोग करके, या अन्य कक्षाओं का मजाक उड़ाते हुए। कोड का व्यवहार तब अपेक्षित व्यवहार की तुलना में होता है, उदाहरण के लिए एक विशिष्ट वापसी मूल्य।

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

कोड कवरेज़

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

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

इसलिए हालत की स्थिति की जांच करना अक्सर उपयोगी होता है ।

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

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

function foo(A, B) {
  if (A && B) x()
  else        y()
}

जरूरतों के साथ परीक्षण किया जाना foo(false, whatever), foo(true, false)और foo(true, true)के लिए पूर्ण कम से कम एक से अधिक शर्त कवरेज।

यदि आपके पास ऐसी वस्तुएं हैं जो कई राज्यों में हो सकती हैं, तो प्रवाह को नियंत्रित करने के लिए सभी राज्य संक्रमणों के अनुरूप परीक्षण समझदार लगता है।

कुछ और जटिल कवरेज मीट्रिक हैं, लेकिन वे आम तौर पर यहां प्रस्तुत मैट्रिक्स के समान हैं।

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

क्रियात्मक परीक्षण

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

इसके अलावा एक परीक्षण करना चाहिए

बढ़त मामलों length(""), foo("x"), length(longer_than_INT_MAX),
मान जो भाषा द्वारा अनुमत हैं, लेकिन फ़ंक्शन के अनुबंध द्वारा नहीं length(null), और
संभव जंक डेटा length("null byte in \x00 the middle")…

संख्या विज्ञान के साथ, इसका मतलब है परीक्षण 0, ±1, ±x, MAX, MIN, ±∞, NaN, और फ्लोटिंग पॉइंट तुलना के साथ दो पड़ोसी फ्लोट का परीक्षण करना। एक और जोड़ के रूप में, यादृच्छिक परीक्षण मूल्यों को समतुल्यता वर्गों से लिया जा सकता है। डिबगिंग को कम करने के लिए, यह उपयोग किए गए बीज को रिकॉर्ड करने के लायक है ...

गैर-कार्यात्मक परीक्षण: लोड परीक्षण, तनाव परीक्षण

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

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

गैर-परीक्षण विधियां

समीक्षा

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

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

औपचारिक सत्यापन

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

assertबयानों का उपयोग करके कुछ निश्चित रूप से स्पष्ट रूप से जाँच की जा सकती है ।

इन सभी तकनीकों में अपना स्थान है, और पूरक हैं। TDD कार्यात्मक परीक्षणों को आगे लिखता है, लेकिन कोड लागू होने के बाद परीक्षणों को उनके कवरेज मेट्रिक्स द्वारा आंका जा सकता है।

टेस्टेबल कोड लिखने का मतलब है छोटी कोड इकाइयाँ जिन्हें अलग से परखा जा सकता है (उपयुक्त ग्रैन्युलैरिटी, एकल जिम्मेदारी सिद्धांत के साथ सहायक कार्य)। प्रत्येक फ़ंक्शन के लिए कम तर्क, बेहतर। इस तरह के कोड भी निर्भरता इंजेक्शन के माध्यम से नकली वस्तुओं के सम्मिलन के लिए खुद को उधार देते हैं।

— आमोन
स्रोत

2

मैं विस्तृत जवाब की सराहना करता हूं, लेकिन मुझे डर है कि मेरे पास जो कुछ भी है उससे मुझे लगभग कोई लेना देना नहीं है :) लेकिन, सौभाग्य से, प्रोग्रामर ।stackexchange.com/questions/78675/… यह उतना ही करीब लगता है जितना मुझे मिला था। लक्ष्य साधना।

— एरिक कापलुन

यह बढ़िया सामान है। क्या आप किसी किताब या चीजों की सिफारिश कर सकते हैं?

— मार्सिन

4

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

टेस्ट :: Lectrotest

जैसा कि लेखक कहते हैं, यह पर्ल मॉड्यूल हास्केल के क्विक-चेक मॉड्यूल से प्रेरित था । इस पृष्ठ पर और लिंक हैं, जिनमें से कुछ मृत हैं।

— KNB
स्रोत

2

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

एईटीजी प्रणाली: दहनशील डिजाइन के आधार पर परीक्षण के लिए एक दृष्टिकोण

(ऐसे और भी कई संदर्भ हैं)

— डेविड केचेसन
स्रोत

2

कुछ गणितीय समीकरणों का उपयोग किया जाता है, लेकिन यह उस सॉफ्टवेयर परीक्षण के प्रकार पर निर्भर करता है जिसका आप उपयोग कर रहे हैं। मिसाल के तौर पर, क्रिटिकल फॉल्ट असेंबल यह मानता है कि असफलताएं मुश्किल से 2 या एक साथ दोष का उत्पाद हैं। निम्नलिखित समीकरण है: f = 4n + 1. f = फ़ंक्शन जो किसी दिए गए चर ( n) + 1 के लिए परीक्षण मामलों की संख्या की गणना करता है, निरंतर का जोड़ है जहां सभी चर नाममात्र मान को मानते हैं।

एक अन्य प्रकार की परीक्षा जिसमें गणितीय समीकरणों की आवश्यकता होती है, रोबस्टनेस टेस्टिंग एक परीक्षण प्रक्रिया में परीक्षण मामलों की मजबूती, या शुद्धता की जांच कर रही है। इस परीक्षण में, आप इनपुट रेंज (गंदे परीक्षण मामलों) के बाहर कानूनी इनपुट रेंज (स्वच्छ परीक्षण मामलों) और इनपुट चर के भीतर चर का इनपुट करेंगे। आप अनुसरण गणित समीकरण का उपयोग करेंगे: f = 6n + 1 । 6n इंगित करता है कि प्रत्येक चर को 6 अलग-अलग मानों को ग्रहण करना है जबकि अन्य मान नाममात्र मान को मानते हैं। * + 1 * निरंतर 1 के अलावा का प्रतिनिधित्व करता है।

— चार्ल्स लुकास शबज़
स्रोत