टेस्टिंग क्या है

सॉफ़्टवेयर लिखते समय, जांच के ज़रिए इस बात की पुष्टि की जा सकती है कि वह सही तरीके से काम कर रहा है या नहीं. टेस्टिंग को मोटे तौर पर, खास तौर पर सॉफ़्टवेयर चलाने की प्रोसेस के तौर पर परिभाषित किया जा सकता है ताकि यह पक्का किया जा सके कि वह वैसा ही काम करे जैसा वह चाहती थी.

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

वेब पर व्यवहार के कुछ उदाहरण, जिनकी जांच आप कर सकते हैं:

• यह पक्का करना कि किसी बटन पर क्लिक करने पर, वेबसाइट की सुविधा ठीक से काम करती है.
• यह पुष्टि करना कि कोई कॉम्प्लेक्स फ़ंक्शन सही नतीजे देता है.
• वह कार्रवाई पूरी करना जिसके लिए उपयोगकर्ता के लॉगिन की ज़रूरत है.
• यह जांच की जा रही है कि गलत डेटा डाले जाने पर, फ़ॉर्म सही तरीके से गड़बड़ी की सूचना देता है या नहीं.
• यह पक्का करना कि उपयोगकर्ता जब भी बहुत ज़्यादा मुश्किल से काम कर रहा हो, तब जटिल वेब ऐप्लिकेशन लगातार काम करता रहे कम बैंडविथ या ऑफ़लाइन हो जाता है.

ऑटोमेटेड बनाम मैन्युअल टेस्टिंग

सॉफ़्टवेयर की जांच दो सामान्य तरीकों से की जा सकती है: ऑटोमेटेड टेस्टिंग और मैन्युअल टेस्टिंग हो रही है.

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

ऑटोमेटेड टेस्टिंग ऐसी प्रोसेस है जिसकी मदद से टेस्ट को कोड किया जा सकता है और चलाया जा सकता है बिना आपके सॉफ़्टवेयर के अभी काम करने के तरीके की पुष्टि करने के लिए, कंप्यूटर से बार-बार किसी व्यक्ति से बार-बार किसी काम को करवाना. जैसे, सेटअप करना या नतीजे देखना. अहम बात यह है कि अपने-आप होने वाली जांच को कॉन्फ़िगर करने के बाद, इसे बार-बार चलाया जा सकता है. यह अब भी बहुत बड़ी परिभाषा है और ध्यान दें कि ऑटोमेटेड ये टेस्ट अलग-अलग तरह के आकार और तरीकों से किए जा सकते हैं. इस कोर्स से जुड़ी ज़्यादातर समस्याएं अपने-आप टेस्ट करने की सुविधा देता है.

मैन्युअल तरीके से जांच करने की सुविधा अलग-अलग प्लैटफ़ॉर्म पर उपलब्ध है. इसे अक्सर ऑटोमेटेड स्क्रिप्ट से पहले की तरह ही इस्तेमाल किया जाता है से पता चलता है. यह जांच तब भी की जा सकती है, जब अपने-आप होने वाली जांच की सेवा भरोसेमंद साबित न हो और उसका दायरा बहुत बड़ा हो. या आसानी से नहीं लिख सकते.

एक उदाहरण की मदद से बुनियादी बातें

हमारे लिए, JavaScript या उससे जुड़ी भाषाएं लिखने वाले वेब डेवलपर के तौर पर, ऑटोमेटेड टेस्ट एक ऐसी स्क्रिप्ट भी हो सकती है जिसे आप हर रोज़ चलाते हैं नोड के ज़रिए या ब्राउज़र में लोड करके:

import { fibonacci } from "../src/math.js";

if (fibonacci(0) !== 0) {
  throw new Error("Invalid 0th fibonacci result");
}
const fib13 = fibonacci(13);
if (fib13 !== 233) {
  throw new Error("Invalid 13th fibonacci result, was=${fib13} wanted=233");
}

यह एक सरल उदाहरण है, जिससे यह अहम जानकारी मिलती है:

• यह एक टेस्ट है, क्योंकि यह कुछ सॉफ़्टवेयर (फ़िबोनाची) फ़ंक्शन) से कनेक्ट करता है और पक्का करता है कि व्यवहार ठीक वैसे ही काम करता है जैसे वह करना था अपेक्षित मान. अगर व्यवहार सही नहीं है, तो इसकी वजह से गड़बड़ी होती है, JavaScript, Error को फेंकने के बारे में बताता है.

• भले ही आप इस स्क्रिप्ट को अपने टर्मिनल या है, तो यह अब भी अपने-आप काम करने वाला टेस्ट है, क्योंकि इसे बार-बार चलाया जा सकता है इसके लिए, आपको अलग से कुछ करने की ज़रूरत नहीं है. अगले पेज पर, जहां का इस्तेमाल करने के बारे में ज़्यादा जानकारी देते हैं.

• भले ही इस टेस्ट में किसी लाइब्रेरी का इस्तेमाल नहीं किया जाता है, लेकिन यह JavaScript कहीं भी चलाएं—यह अभी भी एक परीक्षण है. ऐसे कई टूल हैं जो आपकी मदद कर सकते हैं टेस्ट लिखें. इसमें वे टेस्ट भी शामिल हैं जिन्हें इस कोर्स में बाद में शामिल किया जाएगा, लेकिन वे सभी अब भी गड़बड़ी पैदा करने के बुनियादी सिद्धांत पर काम करते हैं, अगर कुछ गलत हो जाता है.

लाइब्रेरी की जांच की जा रही है

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

दावे, नतीजे की जांच को जोड़ने का एक तरीका है, जिसकी वजह से अगर कोई गड़बड़ी होती है, तो कुछ गलत हो जाता है. उदाहरण के लिए, पिछले टेस्ट को ज़्यादा छोटा बनाया जा सकता है assert को पेश करके:

import { fibonacci } from "../src/math.js";
import { assert } from "a-made-up-testing-library";

assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");

इस टेस्ट को और बेहतर बनाने के लिए, इंडिपेंडेंट टेस्ट तय करें. हालांकि, ऐसा करना ज़रूरी नहीं है सुइट के हिसाब से ग्रुप बनाया जाता है. नीचे दिए गए सुइट, अलग-अलग फिबोनाची का परीक्षण करते हैं फ़ंक्शन और Catalan फ़ंक्शन:

import { fibonacci, catalan } from "../src/math.js";
import { assert, test, suite } from "a-made-up-testing-library";

suite("math tests", () => {
  test("fibonacci function", () => {
    assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
    assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");
  });
  test("relationship between sequences", () => {
    const numberToCheck = 4;
    const fib = fibonacci(numberToCheck);
    const cat = catalan(numberToCheck);
    assert.isAbove(fib, cat);
  });
});

सॉफ़्टवेयर टेस्टिंग के इस मामले में, संज्ञा के तौर पर test का मतलब टेस्ट केस से है: a एकल, स्वतंत्र, समाधान योग्य स्थिति, जैसे कि "आपसी संबंध सीक्वेंस" परीक्षण केस पिछले उदाहरण में दिखाया गया है.

अलग-अलग नाम वाले टेस्ट, नीचे दिए गए कामों के साथ-साथ अन्य कामों के लिए काम के होते हैं:

• यह तय करना कि समय के साथ कोई टेस्ट कैसे सफल या फ़ेल होता है.
• किसी गड़बड़ी या स्थिति को नाम से हाइलाइट करना, ताकि आप आसानी से यह जांच सकें कि समस्या का हल हो जाता है.
• कुछ जांचों को दूसरों से अलग स्वतंत्र रूप से चलाना, जैसे कि ग्लोब फ़िल्टर के ज़रिए.

टेस्ट केस के बारे में सोचने का एक तरीका है "तीन A" का इस्तेमाल करना यूनिट टेस्टिंग का इस्तेमाल करें: व्यवस्थित करने, कार्रवाई करने, और दावा करने में मदद मिलती है. हर टेस्ट केस के मूल में:

• कुछ वैल्यू या स्थिति व्यवस्थित करें (यह सिर्फ़ हार्ड कोड किया गया इनपुट डेटा हो सकता है).
• कोई कार्रवाई करें, जैसे कि किसी तरीके को कॉल करना.
• assert का इस्तेमाल करके, आउटपुट वैल्यू या अपडेट की गई स्थिति पर दावा करें.

टेस्ट का स्केल

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

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

एक व्यक्तिगत परीक्षण पैमाना इसे एक ऐसे सिद्धांत में डाल सकता है, जिसे अक्सर को "टेस्टिंग पिरामिड" कहा जाता है. यह इस बात का अच्छा नियम हो सकता है कि टेस्ट की जांच कैसे की जाती है और वह कैसे काम करती है.

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

इन टाइप को ऑटोमेटेड टाइप टेस्टिंग.

देखें कि आपको कितना समझ आया है