"सॉफ्टवेयर परीक्षण": अवतरणों में अंतर
Content deleted Content added
छो Bot: अंगराग परिवर्तन |
|||
पंक्ति 1:
'''सॉफ्टवेयर परीक्षण'''
यह भी कहा जा सकता है कि सॉफ्टवेयर परीक्षण वह प्रक्रिया है, जो यह विधिमान्य और सत्यापित करती है कि एक सॉफ्टवेयर प्रोग्राम/अनुप्रयोग/उत्पाद:
# उन व्यावसायिक और तकनीकी आवश्यकताओं को पूरा करता है, जिसने इसके डिज़ाइन और विकास को प्रेरित किया;
# आशा के अनुरूप काम करता है, और
# उन्ही विशेषताओं के साथ लागू किया जा सकता है।
कार्यरत परीक्षण पद्धति के आधार पर, सॉफ्टवेयर परीक्षण को विकास की प्रक्रिया में किसी भी समय लागू किया जा सकता है।
== सिंहावलोकन
परीक्षण,
हर सॉफ्टवेयर उत्पाद के लक्षित दर्शक होते हैं।
2002 में [[NIST]] द्वारा किए गए एक अध्ययन से यह पता चलता है कि सॉफ्टवेयर बग से अमेरिकी अर्थव्यवस्था को सालाना $59.5 बीलियन की चपत लगती है।
== इतिहास ==
प्रारंभ में परीक्षण से डीबगिंग के पृथक्करण को ग्लेन्फोर्ड जे. मायर्स द्वारा 1979 में प्रवर्तित किया गया.<ref name="Myers 1979">{{cite book|first=Glenford J.|last=Myers|title=The Art of Software Testing|publisher=John Wiley and Sons|year=1979|isbn=0-471-04328-1}}</ref> हालांकि उनका ध्यान ब्रेकेज परीक्षण पर था ("एक सफल परीक्षण वह है, जो एक बग को खोजती है"<ref name="Myers 1979" /><ref>{{cite journal|journal=Dr. Dobb's journal of software tools for the professional programmer|publisher=M&T Pub|year=1987|volume=12|issue=1-6|page=116|url=http://books.google.com/books?id=7RoIAAAAIAAJ&q="a+successful+test+is+one+that+finds+a+bug&dq="a+successful+test+is+one+that+finds+a+bug&ei=U44OSsOxBpKSzgSxo4mXAg&pgis=1}}</ref>) इसने सॉफ्टवेयर इंजीनियरिंग समुदाय की बुनियादी विकास गतिविधियों, जैसे डीबगिंग को सत्यापन से अलग करने की इच्छा की पुष्टि की. [[डेव गेल्परिन]] और [[विलियम सी. हेत्ज़ेल]] ने 1988 में सॉफ्टवेयर परीक्षण में प्रावस्थाओं और लक्ष्यों को निम्नलिखित चरणों में वर्गीकृत किया है:<ref>{{cite journal|first=D.|last=Gelperin|coauthors=B. Hetzel|title=The Growth of Software Testing|journal=CACM|volume=31|issue=6|year=1988|id=ISSN 0001-0782}}</ref>
* 1956 तक - डीबगिंग उन्मुख<ref>''1956 तक यह डीबगिंग उन्मुख अवधि थी, जब परीक्षण को अक्सर डीबगिंग से संबद्ध किया गया था: डीबगिंग और परीक्षण के बीच कोई स्पष्ट अन्तर मौजूद नहीं था।''
* 1957-1978 - निरूपण उन्मुख<ref>''1957-1978 तक, प्रदर्शन उन्मुख अवधि थी, जहाँ डीबगिंग और परीक्षण अब प्रतिष्ठित थे - इस अवधि में यह दिखा कि सॉफ्टवेयर आवश्यकताओं को संतुष्ट करता है। ''
* 1979-1982 - विनाश उन्मुख<ref>''1979-1982 के बीच के समय को विनाश उन्मुख अवधि कहा गया, जहाँ लक्ष्य त्रुटि खोजने का था।''
* 1983-1987 - मूल्यांकन उन्मुख<ref>''1983-1987''
* 1988-2000 - निवारण उन्मुख<ref name="Gelperin 1988">''1988 से इसे सुरक्षा उन्मुख अवधि के रूप में देखा गया, जहाँ परीक्षण यह दिखाते थे कि सॉफ्टवेयर अपने विनिर्देशन को संतुष्ट करता है, दोष का पता लगाना और दोष को रोकना।''
== सॉफ्टवेयर परीक्षण विषय ==
=== कार्यक्षेत्र
परीक्षण का एक प्राथमिक उद्देश्य, सॉफ्टवेयर विफलताओं का पता लगाना है, ताकि दोषों को खोजा और सुधारा जा सके. यह एक गैर-नगण्य खोज है।
=== कार्यात्मक बनाम ग़ैर-कार्यात्मक परीक्षण ===
फंक्शनल परीक्षण उस परीक्षण से संबन्ध रखता है, जो कोड की एक विशिष्ट कार्रवाई या प्रकार्य को सत्यापित करता है।
नॉन-फंक्शनल परीक्षण, सॉफ्टवेयर के उन पहलुओं को दर्शाता है, जो संभव है कि किसी विशेष प्रकार्य या उपयोगकर्ता की क्रिया, जैसे [[आरोहण]] या [[सुरक्षा]] से संबन्धित ना हों.
=== त्रुटियाँ और असफलताएं ===
सॉफ्टवेयर के सभी दोष, कोड की त्रुटियों के कारण नहीं होते हैं।
सॉफ्टवेयर दोष निम्नलिखित प्रक्रियाओं के माध्यम से होते हैं।
=== शीघ्र ग़लतियाँ खोजना ===
पंक्ति 83:
|}
=== संगतता ===
सॉफ्टवेयर विफलता का एक आम कारण, अन्य अनुप्रयोग, एक नए [[ऑपरेटिंग सिस्टम]], या, बढ़ते हुए [[वेब ब्राउज़र]] संस्करण के साथ [[संगतता]] है।
इसे एक "सुरक्षा उन्मुख रणनीति" मान सकते हैं, जो कि [[डेव गेल्परिन]] और [[विलियम सी. हेत्ज़ेल]] द्वारा सुझाए नवीनतम परिक्षण चरण के साथ सटीक बैठता है, जैसा कि नीचे उद्धृत है।<ref name="Gelperin 1988" />.
=== इनपुट कॉम्बिनेशन और प्री-कंडीशन ===
सॉफ्टवेयर परीक्षण के साथ एक मुख्य समस्या है कि इनपुट और प्री-कंडीशन (प्रारम्भिक
=== स्टैटिक बनाम डाइनेमिक परीक्षण ===
सॉफ्टवेयर परीक्षण के लिए कई दृष्टिकोण हैं।
=== सॉफ्टवेयर सत्यापन और प्रमाणीकरण ===
सॉफ्टवेयर परीक्षण का प्रयोग [[सत्यापन और प्रमाणीकरण]] के साहचर्य से किया जाता है:<ref name="tran">{{cite book
|last=Tran | first=Eushiuan | editor=Koopman, P. | title=Topics in Dependable Embedded Systems | location=USA | publisher=Carnegie Mellon University | year=1999 | chapter=Verification/Validation/Certification |chapterurl=http://www.ece.cmu.edu/~koopman/des_s99/verification/index.html | accessdate=2008-01-13}}</ref>
पंक्ति 101:
* [[प्रमाणीकरण]]: क्या हमने सही सॉफ्टवेयर बनाया? (यानी, क्या यह वैसा ही है जैसा ग्राहक चाहता है)।
सत्यापन और प्रमाणीकरण शब्द का आम तौर पर प्रयोग, उद्योग में अन्तर-परिवर्तनशीलता से किया जाता है; इन दोनों शब्दों को ग़लत तरीके से परिभाषित करना भी आम है।
:सत्यापन, यह जानने के लिए एक सिस्टम या घटक के मूल्यांकन की प्रक्रिया है कि दिए गए विकास चरण के उत्पाद, चरण के आरंभ में निर्धारित शर्तों को पूरा करते हैं या नहीं।
::प्रमाणीकरण विकास की प्रक्रिया के दौरान या अन्त में यह निर्धारित करने के लिए सिस्टम या घटक के मूल्यांकन की प्रक्रिया है कि क्या यह निर्दिष्ट आवश्यकताओं को पूरा करता है।
=== सॉफ्टवेयर परीक्षण दल ===
सॉफ्टवेयर परीक्षण [[सॉफ्टवेयर टेस्टर|''सॉफ्टवेयर टेस्टर'']] द्वारा की जा सकती है।
=== सॉफ्टवेयर क्वालिटी अश्युरेन्स (SQA) ===
हालांकि विवादास्पद, सॉफ्टवेयर परीक्षण को [[सॉफ्टवेयर क्वालिटी अश्युरेन्स]] (SQA ) प्रक्रिया के एक महत्वपूर्ण हिस्से के रूप में देखा जा सकता है। <ref name="Kaner1">[39] ^ पृ. 347</ref>
एक "स्वीकार्य दोष दर"
यद्यपि SQA के साथ घनिष्ठ संबन्ध हैं, परीक्षण विभाग अक्सर स्वतंत्र रूप से कार्य करते हैं, और हो सकता है कि किसी कंपनी में SQA का कोई कार्य ना हो।
सॉफ्टवेयर परीक्षण, एक कंप्यूटर प्रोग्राम के अपेक्षित परिणामों को, दिए गए एक इनपुट सेट के लिए, इसके वास्तविक परिणामों से तुलना करते हुए, सॉफ्टवेयर में दोषों का पता लगाने के उद्देश्य से किया गया कार्य है।
== परीक्षण तरीक़े
=== बॉक्स दृष्टिकोण ===
सॉफ्टवेयर परीक्षण तरीक़ों को परंपरागत रूप से [[ब्लैक बॉक्स परीक्षण]] और [[व्हाईट बॉक्स परीक्षण]] में विभाजित किया गया हैं।
==== ब्लैक बॉक्स परीक्षण
[[ब्लैक बॉक्स परीक्षण]], सॉफ्टवेयर से एक "ब्लैक बॉक्स" के रूप में व्यवहार करता है - बिना किसी आंतरिक कार्यान्वयन की जानकारी के ब्लैक बॉक्स परीक्षण तरीकों में शामिल हैं: [[इक्विवेलेंस पार्टिशनिंग]], [[बाउंड्री वैल्यू एनैलिसिस]], [[ऑल पेयर्स परीक्षण]], [[फ़ज परीक्षण]], [[मॉडल-बेस्ड परीक्षण]], [[ट्रेसेबिलिटी मेट्रिक्स]], [[एक्स्प्लोरेटरी परीक्षण]] और स्पेसीफिकेशन-बेस्ड परीक्षण।
:'''स्पेसीफिकेशन-बेस्ड परीक्षण''' : विनिर्देशन आधारित परीक्षण, प्रयोज्य आवश्यकताओं के अनुसार सॉफ्टवेयर की कार्यक्षमता का परीक्षण करती है। <ref>{{cite paper | last = Laycock | first = G. T. | title = The Theory and Practice of Specification Based Software Testing | publisher = Dept of Computer Science, Sheffield University, UK | year = 1993 | url =http://www.mcs.le.ac.uk/people/gtl1/thesis.ps.gz | format = [[PostScript]]| accessdate = 2008-02-13 }}</ref> इस प्रकार, परीक्षक, डाटा को टेस्ट ऑब्जेक्ट में डालता है, और आउटपुट को सिर्फ टेस्ट ऑब्जेक्ट से देखता है।
:विनिर्देशन आधारित परीक्षण जरूरी है, लेकिन यह कुछ जोखिमों से बचाव करने के लिए अपर्याप्त है। <ref>{{cite journal
पंक्ति 144:
}}</ref>
:'''फ़ायदे और नुक़्सान''' : ब्लैक बॉक्स परीक्षक के पास कोड के साथ कोई "बॉन्ड" नहीं होता, और एक परीक्षक की धारणा बहुत सरल है: एक कोड में ''ज़रूर''
इसलिए, ब्लैक बॉक्स परीक्षण में एक ओर "एक असम्बद्ध राय" का फायदा है, और दूसरी ओर "अंधी तलाश" का नुक्सान।
<ref>{{cite book | last = Savenkov | first = Roman | title=How to Become a Software Tester|publisher=Roman Savenkov Consulting|year=2008|isbn = 978-0-615-23372-7|page=168}}</ref>
==== व्हाइट बॉक्स परीक्षण
[[व्हाइट बॉक्स परीक्षण]] तब होती है जब परीक्षक के पास, आंतरिक डाटा संरचनाओं और इसे लागू करने वाले कोड सहित एल्गोरिदम तक पहुंच सुलभ होती है।
पंक्ति 166:
:कोड कवरेज के दो आम प्रकार हैं:
:* ''फंक्शन कवरेज'' , जो सम्पादित प्रक्रियाओं पर रिपोर्ट देता है
:* ''स्टेटमेंट कवरेज'' , परीक्षण को पूर्ण करने में निष्पादित लाइनों की संख्या पर रिपोर्ट करता है
वे दोनों एक [[कोड कवरेज मीट्रिक]] को लौटाते हैं, जिसे [[प्रतिशत]] के रूप में मापा जाता है।
==== ग्रे बॉक्स परीक्षण
'''ग्रे बॉक्स परीक्षण'''
== परीक्षण स्तर ==
परीक्षणों को अक्सर, सॉफ्टवेयर विकास प्रक्रिया में उनके शामिल होने की जगह के आधार पर वर्गीकृत किया जाता है, या परीक्षण की विशिष्टता के स्तर द्वारा।
=== यूनिट परीक्षण ===
{{main article|Integration testing}}
'''यूनिट परीक्षण'''
इस प्रकार के परीक्षण आम तौर पर डेवलपर्स द्वारा लिखे जाते हैं, जब वे कोड पर काम कर रहे होते हैं (व्हाइट बॉक्स शैली), यह सुनिश्चित करने के लिए कि एक विशेष प्रक्रिया अपेक्षानुरूप ठीक ढंग से काम कर रही है।
=== इंटीग्रेशन परीक्षण ===
{{main article|Integration testing}}
'''इंटीग्रेशन परीक्षण'''
[[इंटीग्रेशन परीक्षण]], इंटरफेस में त्रुटियाँ उजागर करने और एकीकृत घटक (मॉड्यूल) के बीच पारस्परिक क्रिया को दर्शाने के लिए काम करता है।
=== सिस्टम परीक्षण ===
पंक्ति 195:
=== सिस्टम इंटीग्रेशन परीक्षण ===
{{main article| System integration testing}}
[[सिस्टम इंटीग्रेशन परीक्षण]] यह पुष्टि करता है कि एक सिस्टम, सिस्टम आवश्यकताओं में परिभाषित किसी भी बाहरी या अन्य पक्ष के सिस्टम से एकीकृत है। {{citation needed|date=January 2008}}
=== रिग्रेशन परीक्षण ===
{{main article|Regression testing}}
'''रिग्रेशन परीक्षण'''
=== एक्सेपटेंस
{{main article|Acceptance testing}}
पंक्ति 207:
# [[स्मोक टेस्ट]] को मुख्य परीक्षण प्रक्रिया के लिए, यानी [[इंटीग्रेशन]] या [[रिग्रेशन]] से पहले, एक नए निर्माण को पेश करने से पहले एक स्वीकृति परीक्षण के रूप में प्रयोग किया जाता है।
# ग्राहक द्वारा निष्पादित एक्सेपटेंस परीक्षण, अक्सर उनके प्रयोगशाला परिवेश में उनके खुद के HW पर, को [[यूज़र एक्सेप्टेंस परीक्षण]] (UAT) (उपयोगकर्ता स्वीकृति परीक्षण) के रूप में जाना जाता है।
=== अल्फा परीक्षण ===
''अल्फा परीक्षण'' , संभावित उपयोगकर्ताओं/ग्राहकों या डेवलपर की साइट पर एक स्वतंत्र टेस्ट टीम द्वारा नकली या वास्तविक संचालन परीक्षण है।
=== बीटा परीक्षण ===
''बीटा परीक्षण''
== ग़ैर कार्यात्मक परीक्षण ==
सॉफ्टवेयर के ग़ैर-कार्यात्मक पहलुओं के परीक्षण के लिए विशेष तरीक़े मौजूद हैं।
=== सॉफ्टवेयर परफोर्मेंस परीक्षण|परफोर्मेंस परीक्षण, या लोड परीक्षण ===
[[परफोर्मेंस परीक्षण]], या [[लोड परीक्षण]] यह देखने के लिए जांच करता है कि सॉफ्टवेयर, बड़ी मात्रा में डाटा या [[उपयोगकर्ताओं]] को संभाल सकता है या नहीं. आम तौर पर इसे सॉफ्टवेयर [[स्केलेबिलिटी]] के रूप में जाना जाता है।
=== स्टेबिलिटी परीक्षण ===
[[स्थाईत्व परीक्षण]] यह देखने के लिए जांच करता है कि सॉफ्टवेयर एक स्वीकार्य अवधि में या उससे ऊपर, लगातार अच्छी तरह से कार्य करता सकता है या नहीं। ग़ैर-कार्यात्मक सॉफ्टवेयर परीक्षण की यह गतिविधि अक्सर लोड (या एंड्युरेंस) परीक्षण के रूप में निर्दिष्ट होती है।
=== युसेबिलिटी परीक्षण ===
[[प्रयोज्यता परीक्षण]] की जरूरत यह जांचने के लिए होती है कि यूज़र इंटरफ़ेस का उपयोग करना और उसे समझना आसान है या नहीं।
=== सिक्योरिटी परीक्षण ===
[[सुरक्षा परीक्षण]] उस सॉफ्टवेयर के लिए जरूरी है जो [[हैकर्स]] द्वारा [[सिस्टम घुसपैठ]] को रोकने के लिए गोपनीय डाटा को परिष्कृत करता है।
=== अन्तर्राष्ट्रीयकरण और स्थानीयकरण ===
[[अन्तर्राष्ट्रीयकरण और स्थानीयकरण]] की जरूरत सॉफ्टवेयर के इन पहलुओं की जांच के लिए होती है, जिसके लिए एक [[छद्मस्थानीयकरण]] विधि का इस्तेमाल किया जा सकता है।
=== डिसट्रकटिव परीक्षण ===
{{main article|Destructive testing}}
विनाशक परीक्षण, सॉफ्टवेयर या उप-प्रणाली को इसकी मजबूती के जांच के लिए, विफल करने का प्रयास करती है।
== परीक्षण प्रक्रिया ==
=== पारंपरिक [[CMMI]] या [[वॉटरफ़ॉल विकास]] मॉडल ===
सॉफ्टवेयर परीक्षण के एक आम तरीके को, इसे ग्राहक को भेजे जाने से पहले और इसकी कार्यक्षमता विकसित किये जाने के बाद, परीक्षकों के एक स्वतंत्र समूह द्वारा सम्पादित किया जाता है। <ref>[http://www.etestinghub.com/testing_lifecycles.php#2 e)Testing Phase in Software Testing:-]</ref> इस अभ्यास के परिणामस्वरूप अक्सर परीक्षण चरण का, परियोजना में हुई देरी की क्षतिपूर्ति के लिए [[परियोजना]] बफर के रूप में उपयोग किया जाता है, और इस प्रकार से परीक्षण के लिए समर्पित समय के साथ समझौता होता है। <ref>{{cite book|first=Glenford J.|last=Myers|title=The Art of Software Testing|publisher=John Wiley and Sons|year=1979|isbn=0-471-04328-1|page=145-146}}</ref> एक और परिपाटी है परियोजना के शुरू होने के क्षण ही सॉफ्टवेयर परीक्षण को शुरू कर देना और परियोजना के समापन तक यह एक सतत प्रक्रिया है। <ref>{{cite book | last = Dustin | first = Elfriede | title=Effective Software Testing|publisher=Addison Wesley|year=2002|isbn = 0-20179-429-2|page=3}}</ref>
=== फुर्तीला या तीव्र विकास मॉडल ===
जवाब में, कुछ ऐसे उभरते सॉफ्टवेयर विषय जैसे [[एक्सट्रीम प्रोग्रामिंग]] और [[एजाइल सॉफ्टवेयर डिवेलपमेंट]] आंदोलन, एक "[[टेस्ट ड्रिवेन सॉफ्टवेयर डेवेलपमेंट]]" मॉडल का पालन करते हैं।
=== एक परीक्षण चक्र नमूना ===
हालांकि संगठनों के बीच भिन्नता मौजूद है, परीक्षण के लिए एक विशिष्ट चक्र होता है। <ref>{{citation
|url=http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/
पंक्ति 256:
}}</ref> निम्न नमूना, [[वॉटर फॉल डेवलपमेंट]] मॉडल को अपनाने वाले संगठनों के बीच आम है।
* '''[[आवश्यकताओं का विश्लेषण:]]'''
* '''परीक्षण योजना''' : [[परीक्षण रणनीति]], [[परीक्षण योजना]], [[टेस्टबेड]] निर्माण. चूंकि परीक्षण के दौरान कई गतिविधियों को अंजाम दिया जाएगा, एक योजना की जरूरत है।
* '''परीक्षण विकास''' : सॉफ्टवेयर परीक्षण में उपयोग के लिए परीक्षण प्रक्रियाएं, [[परीक्षण परिदृश्य]], [[परीक्षण मामले]], परिक्षण डाटासेट, परीक्षण स्क्रिप्ट.
* '''परीक्षण निष्पादन''' : परीक्षक सॉफ्टवेयर को योजनाओं और परीक्षण के आधार पर निष्पादित करते हैं और किसी भी खोजी गई खराबी की सूचना विकास टीम को देते हैं।
* '''परीक्षण रिपोर्ट''' : एक बार परीक्षण पूरा हो जाने के बाद, परीक्षक मैट्रिक्स उत्पन्न करते हैं और अपने [[परीक्षण प्रयास]] और जिस सॉफ्टवेयर का परीक्षण किया गया है, वह जारी होने के लिए तैयार है या नहीं, इस बात की अन्तिम रिपोर्ट बनाते हैं।
* '''परीक्षण परिणाम विश्लेषण''' : या दोष विश्लेषण, विकास दल द्वारा आम तौर पर ग्राहक के साथ किया जाता है, ताकि यह निर्णय किया जा सके कि किन दोषों का निवारण, सुधार, खारिज किया जाना चाहिए, (अर्थात, पाया गया सॉफ्टवेयर ठीक से काम कर रहा है) या बाद में निपटने के लिए स्थगित करना चाहिए.
* '''दोष पुनर्परीक्षण''' : एक बार एक दोष को विकास दल द्वारा निपटाने के बाद, इसका परीक्षण टीम द्वारा पुनर्परीक्षण होता है।
* '''प्रतिगमन परीक्षण''' : नए, संशोधित, या नियत सॉफ्टवेयर के प्रत्येक एकीकरण के लिए परीक्षण के एक सब-सेट से निर्मित एक छोटे परीक्षण कार्यक्रम का होना आम है, ताकि यह सुनिश्चित किया जा सके कि नवीनतम सुपुर्दगी ने कुछ बर्बाद नहीं किया है, और यह कि संपूर्ण रूप से सॉफ्टवेयर उत्पाद अभी भी सही ढंग से काम कर रहा है।
* '''परीक्षण समाप्ति''' : एक बार परीक्षण निकास मानदंडों के अनुरूप हो जाता है, तो गतिविधियों को, जैसे प्रमुख आउटपुट को कैप्चर करना, सीखे गए सबक, परिणाम, लॉग्स, परियोजना से संबन्धित दस्तावेजों को संग्रहीत किया जाता है और भविष्य की परियोजनाओं के लिए एक संदर्भ के रूप में इस्तेमाल किया जाता है।
पंक्ति 269:
{{main article|Test automation}}
कई प्रोग्रामिंग समूह, [[स्वचालित परीक्षण]] पर अधिकाधिक निर्भर कर रहे हैं, विशेष रूप से ऐसे समूह जो
[[टेस्ट चालित विकास]] का उपयोग करते हैं।
जबकि स्वचालन वह सब कुछ निर्मित नहीं कर सकता, जो कि एक मानव कर सकता है (और वे अजीब तरीके, जिसे वे ऐसा करने की खातिर अपनाते हैं), यह रिग्रेशन परीक्षण के लिए बहुत उपयोगी हो सकते हैं।
=== परीक्षण उपकरण ===
प्रोग्राम परीक्षण और गड़बड़ी का पता लगाने में परीक्षण उपकरण और [[डिबगर]] द्वारा काफी सहायता प्राप्त हो सकती है।
परीक्षण/डिबग उपकरणों की विशेषताओं में शामिल हैं:
पंक्ति 288:
इन गुणों में से कुछ को एक [[एकीकृत विकास परिवेश]] (IDE) में शामिल किया जा सकता है।
=== सॉफ्टवेयर परीक्षण मापन
आम तौर पर, जिन विषयों तक गुणवत्ता सीमित होती है, वे हैं [[शुद्धता]], संपूर्णता, [[सुरक्षा]],{{citation needed|date=January 2008}} लेकिन [[ISO]] मानक [[ISO 9126]] के तहत वर्णित अधिक तकनीकी आवश्यकताएं भी शामिल हो सकती हैं, जैसे क्षमता, [[विश्वसनीयता]], [[दक्षता]], [[सुवाह्यता]], [[रख-रखाव]], संगतता, और 0}प्रयोज्यता।
कई आम सॉफ्टवेयर उपाय मौजूद हैं, जिन्हें अक्सर 'मैट्रिक्स' कहा जाता है, जिनका प्रयोग सॉफ्टवेयर की हालत या परीक्षण की पर्याप्तता के मापन के लिए किया जाता है।
== आर्टीफैक्ट्स परीक्षण ==
सॉफ्टवेयर परीक्षण प्रक्रिया कई [[आर्टीफैक्ट]] को उत्पन्न कर सकती है।
;टेस्ट प्लान
: एक परीक्षण विनिर्देश एक [[टेस्ट प्लान]] कहलाता है।
;ट्रेसेबिलिटी मैट्रिक्स
: एक [[ट्रेसेबिलिटी मैट्रिक्स]] एक ऐसी तालिका है, जो अपेक्षाओं या डिजाइन दस्तावेजों को परीक्षण दस्तावेजों से संबद्ध करता है।
;टेस्ट केस
: [[परीक्षण मामले]] में आम तौर पर शामिल होते हैं- एक अनूठा पहचानकर्ता, एक डिजाइन विनिर्देशन से अपेक्षा संदर्भ, पूर्व शर्तें, घटनाएं, अनुसरण के लिए चरणों की एक श्रृंखला (कार्रवाई के रूप में भी ज्ञात), इनपुट, आउटपुट, अपेक्षित परिणाम, और वास्तविक परिणाम. चिकित्सकीय रूप से परिभाषित करें तो, एक परीक्षण मामला एक इनपुट और अपेक्षित परिणाम है। <ref>{{cite book|author=IEEE|title=[[IEEE 829|IEEE standard for software test documentation]]|publisher=IEEE|location=New York|year=1998|isbn= 0-7381-1443-X}}</ref> यह 'X परिस्थिति के लिए आपको हासिल परिणाम Y है' जबकि अन्य टेस्ट केस ने इनपुट परिदृश्य और कैसे परिणामों की संभावना हो सकती है, इसकी विस्तार से व्याख्या की है।
;टेस्ट स्क्रिप्ट
: [[परीक्षण स्क्रिप्ट]], एक टेस्ट केस, टेस्ट प्रक्रिया, और टेस्ट आंकड़ों का संयोजन है।
;टेस्ट स्वीट
: परीक्षण मामलों के संग्रह के लिए सबसे आम शब्द [[टेस्ट स्वीट]] है।
;टेस्ट डाटा
: अधिकांश मामलों में, मान या डाटा के कई सेटों का प्रयोग एक विशेष प्रक्रिया की समान कार्यक्षमता के परीक्षण के लिए किया जाता है।
;टेस्ट हार्नेस
: सॉफ्टवेयर, उपकरण, डाटा के इनपुट और आउटपुट नमूने, और विन्यास, सभी को सामूहिक रूप से एक [[टेस्ट हार्नेस]] के रूप में संदर्भित किया जाता है।
== प्रमाणन ==
सॉफ्टवेयर परीक्षकों और गुणवत्ता आश्वासन विशेषज्ञों की पेशेवर आकांक्षाओं को बल देने के लिए कई प्रमाणन कार्यक्रम मौजूद हैं।
;सॉफ्टवेयर परीक्षण प्रमाणीकरण प्रकार
पंक्ति 332:
:* CATe ''इंटरनेशनल इंस्टीट्यूट ऑफ़ सॉफ्टवेयर परीक्षण'' <ref name="testinginstitute.com">[http://www.testinginstitute.com/ International Institute for Software Testing]</ref> द्वारा प्रदत्त
:* सर्टिफाइड मैनेजर इन सॉफ्टवेयर परीक्षण (CMST) [[क्वालिटी अश्योरेन्स इंस्टीट्यूट]] (QAI) द्वारा प्रदत्त <ref name="Quality Assurance Institute" />
:* सर्टिफाइड सॉफ्टवेयर परीक्षण (CSTE) [[क्वालिटी अश्योरेन्स इंस्टीट्यूट]] (QAI) द्वारा प्रदत्त
:* सर्टिफाइड सॉफ्टवेयर टेस्ट प्रोफेशनल (CSTP) ''इंटरनेशनल इंस्टीट्यूट ऑफ़ सॉफ्टवेयर परीक्षण''
:* [[CSTP (TM)]] (ऑस्ट्रेलियाई संस्करण), ''के.जे. रॉस एंड एसोसिएट्स''
:* ISEB [[इन्फ़र्मेशन सिस्टम्स इक्ज़ैमिनेशन बोर्ड]] द्वारा प्रदत्त
:* ISTQB सर्टिफाइड टेस्टर, फाउंडेशन लेवल (CTFL) [[इंटरनेशनल सॉफ्टवेयर परीक्षण क्वालिफिकेशन बोर्ड]]<ref name="istqb">{{cite web |url=http://www.istqb.org/ |title=ISTQB}}</ref><ref name="astqb">{{cite web |url=http://www.astqb.org/ |title=ISTQB in the U.S.}}</ref> द्वारा प्रदत्त
:* ISTQB , सर्टिफाइड टेस्टर, एडवांस्ड लेवल (CTAL) [[इंटरनेशनल सॉफ्टवेयर परीक्षण क्वालिफिकेशन बोर्ड]]<ref name="istqb" /><ref name="astqb" /> द्वारा प्रदत्त
:* TMPF [[TMap]]{{Dubious|TMAP advertisement|date=December 2008}} नेक्स्ट फाउंडेशन ''इक्ज़ैमिनेशन इंस्टीट्यूट फॉर इन्फर्मेशन साइंस''
;गुणवत्ता आश्वासन प्रमाणन
:
:* CMSQ ''क्वालिटी अश्योरेन्स इंस्टीट्यूट''
:* CSQA ''क्वालिटी अश्योरेन्स इंस्टीट्यूट''
:* CSQE [[अमेरिकन सोसायटी फॉर क्वालिटी]] (ASQ) द्वारा प्रदत्त <ref name="American Society for Quality">[http://www.asq.org/ American Society for Quality]</ref>
:* CQIA [[अमेरिकन सोसायटी फॉर क्वालिटी]] (ASQ) द्वारा प्रदत्त <ref name="American Society for Quality" />
पंक्ति 354:
: "कांटेक्स्ट-ड्रिवेन" परीक्षण स्कूल<ref>[http://www.context-driven-testing.com context-driven-testing.com]</ref> के सदस्यों का मानना है कि परीक्षण की कोई "सर्वोत्तम प्रथा" नहीं है, उसके बजाय परीक्षण, कौशल का एक सेट है जो परीक्षक को प्रत्येक अनोखी परिस्थिति से मेल खाती परीक्षण प्रथाओं के आविष्कार की अनुमति देता है। <ref>[http://www.technicat.com/writing/process.html Article on taking agile traits without the agile method.]</ref>
; फुर्तीला बनाम पारंपरिक
: क्या परीक्षकों को अनिश्चितता और निरंतर परिवर्तन की स्थितियों के तहत काम करना सीखना चाहिए या उनका लक्ष्य [[प्रक्रिया "परिपक्वता"]] पर होना चाहिए? [[एजाइल परीक्षण]] आंदोलन को मुख्य रूप से व्यापारिक हलकों में 2006 के बाद से काफी लोकप्रियता मिली<ref>[http://stpcollaborative.com/knowledge/272-were-all-part-of-the-story “We’re all part of the story”] डेविड स्ट्रोम द्वारा, 1 जुलाई, 2009</ref><ref>[http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/10705/33795/01609838.pdf?temp=x IEEE article about differences in adoption of agile trends between experienced managers vs. young students of the Project Management Institute.] [http://www.ambysoft.com/downloads/surveys/AgileAdoption2007.ppt Agile adoption study from 2007] भी देखें</ref>, जबकि सरकारी और सैन्य सॉफ्टवेयर प्रदाता इस पद्धति को अपनाने में धीमे हैं{{POV-statement|date=February 2009}}, और अधिकतर अभी भी [[CMMI]] से बन्धे हैं। <ref>[http://www.stsc.hill.af.mil/crosstalk/2004/04/0404willison.html Agile software development practices slowly entering the military]</ref>
पंक्ति 360:
: क्या परीक्षण को उसी समय डिजाइन करना चाहिए, जब उन्हें निष्पादित किया जाता है या उन्हें पहले से तैयार किया जाना चाहिए?
; मैनुअल परीक्षण बनाम ऑटोमेटेड
: कुछ लेखकों का मानना है कि [[स्वचालन परीक्षा]] अपने मूल्य की तुलना में इतना महंगा है कि इसका प्रयोग किफ़ायती तौर पर किया जाना चाहिए.<ref>एक उदाहरण हैं मार्क फ्युस्टर, डोरोथी ग्राहम: ''सॉफ्टवेयर टेस्ट ऑटोमेशन''
; Software design vs. software implementation<ref>[http://java.dzone.com/news/why-evangelising-unit-testing- Article referring to other links questioning the necessity of unit testing]</ref>
: क्या परीक्षण को सिर्फ अन्त में करना चाहिए या पूरी प्रक्रिया के दौरान करना चाहिए?
;चौकीदार की चौकीदारी कौन करता है? //हु वॉचेस द वॉचमेन?
: विचार यह है कि, निरीक्षण का कोई भी रूप एक पारस्परिक क्रिया है - परीक्षण का कार्य उसे भी प्रभावित कर सकता है, जिसका परीक्षण किया जा रहा है। <ref>[http://channel9.msdn.com/forums/Coffeehouse/402611-Are-you-a-Test-Driven-Developer/ Microsoft Development Network Discussion on exactly this topic]</ref>
पंक्ति 386:
* [[ऑटोमेटेड परीक्षण]]
== संदर्भ ==
{{reflist|2}}
== बाह्य लिंक ==
* [http://www.economist.com/science/tq/displaystory.cfm?story_id=10789417 "Software that makes Software better" Economist.com]
* [http://www.applabs.com/internal/app_whitepaper_future_software_testing_1v001.pdf Future of Software Testing]
* [http://www.qatutor.com/glossary.html Software QA Testing Glossary]
[[श्रेणी:सॉफ्टवेयर परीक्षण]]
|