तय करें कि किस चीज़ की जांच करनी है, अपने टेस्ट केस तय करें, और प्राथमिकता तय करें.
पिछली पोस्ट में, आपको टेस्ट की रणनीतियों, किसी ऐप्लिकेशन की जांच करने के लिए ज़रूरी जांचों की संख्या, और अपने संसाधनों को ध्यान में रखते हुए नतीजों पर सबसे ज़्यादा भरोसा पाने के लिए, सबसे सही तरीके के बारे में जानकारी मिली थी. हालांकि, इससे हमें सिर्फ़ यह पता चलता है कि कितनी जांच करनी है. आपको अब भी यह तय करना होगा कि किस चीज़ की जांच करनी है. इन तीन शर्तों से यह समझने में मदद मिल सकती है कि टेस्ट में क्या उम्मीद की जानी चाहिए. साथ ही, यह भी पता लगाया जा सकता है कि किस तरह की जानकारी और टेस्टिंग का टाइप सबसे सही है:
- अपनी खुशियों का ख्याल रखें. यह आपके ऐप्लिकेशन के बारे में सबसे सामान्य या मुख्य उपयोगकर्ता के तौर पर बताई गई कहानी है, जिसमें आपके उपयोगकर्ता को बहुत जल्दी गड़बड़ी दिखेगी.
- जानकारी के लेवल पर सावधानी से फ़ैसला लें. अगर आपके इस्तेमाल के उदाहरण में जोखिम है या किसी गड़बड़ी की वजह से ज़्यादा नुकसान हो सकता है, तो ज़्यादा जानकारी पाएं.
- जब भी मुमकिन हो, हाई लेवल के एंड-टू-एंड टेस्ट के बजाय, यूनिट और इंटिग्रेशन जैसे लोअर लेवल के टेस्ट को प्राथमिकता दें.
इस लेख के बाकी हिस्से में, इन शर्तों के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि टेस्ट केस तय करत�� समय, ये शर्तें कैसे लागू होती हैं.
टेस्ट केस क्या होता है?
सॉफ़्टवेयर डेवलपमेंट में, टेस्ट केस, कार्रवाइयों या परिस्थितियों का एक क्रम होता है. इसका इस्तेमाल सॉफ़्टवेयर प्रोग्राम या ऐप्लिकेशन के असर की पुष्टि करने के लिए किया जाता है. टेस्ट केस का मकसद यह पक्का करना होता है कि सॉफ़्टवेयर, प्लान के मुताबिक काम करे और उसकी सभी सुविधाएं और फ़ंक्शन सही तरीके से काम करें. सॉफ़्टवेयर टेस्टर या डेवलपर आम तौर पर ये टेस्ट केस बनाते हैं, ताकि यह गारंटी दी जा सके कि सॉफ़्टवेयर तय की गई ज़रूरी शर्तों और निर्देशों को पूरा करता है.
जब कोई टेस्ट केस चलाया जाता है, तो सॉफ़्टवेयर कई तरह की जांच करता है, ताकि यह पक्का किया जा सके कि वह मनचाहे नतीजे दे रहा है. ऐसा करते समय, टेस्ट से ये काम पूरे होते हैं:
- पुष्टि करने का तरीका. सॉफ़्टवेयर की पूरी तरह से जांच करने की प्रोसेस, ताकि यह पक्का किया जा सके कि वह बिना किसी गड़बड़ी के काम करता है. यह तय करना बहुत ज़रूरी है कि बनाया गया प्रॉडक्ट, काम न करने वाली सभी ज़रूरी शर्तों को पूरा करता है या नहीं. साथ ही, यह तय करना भी ज़रूरी है कि वह प्रॉडक्ट अपने मकसद को पूरा करता है या नहीं. इसका एक सवाल यह है कि: “क्या हम सही प्रॉडक्ट बना रहे हैं?”
- पुष्टि करना. यह पक्का करने की प्रोसेस कि सॉफ़्टवेयर प्रॉडक्ट ज़रूरी मानकों या हाई-लेवल की शर्तों को पूरा करता है. इसमें यह जांच की जाती है कि असल प्रॉडक्ट, उम्मीद के मुताबिक है या नहीं. हम इस सवाल का जवाब दे रहे हैं: “क्या हम लोगों की ज़रूरतों के हिसाब से सही प्रॉडक्ट बना रहे हैं?”
मान लीजिए कि प्रोग्राम उम्मीद के मुताबिक नतीजा नहीं दे रहा. ऐसी स्थिति में, टेस्ट केस मैसेंजर होगा—इस तरह असफल नतीजे की रिपोर्टिंग करता है और डेवलपर या टेस्टर को समस्या की जांच करके समाधान ढूंढना होता है. जांच और कार्रवाइयों को एक पाथ के तौर पर देखें, जिसे कंप्यूटर अपनाता है. इससे कोई फ़र्क़ नहीं पड़ता कि टेस्टिंग किस तरह की है. इनपुट डेटा के ग्रुप या जांच के लिए इस्तेमाल की जाने वाली शर्तों को "इक्वेलेंस क्लास" कहा जाता है. उन्हें जांच के तहत सिस्टम से, मिलता-जुलता तरीका या नतीजे मिलने चाहिए. टेस्ट में लागू किए गए खास पाथ अलग-अलग हो सकते हैं, लेकिन उन्हें आपके टेस्ट में की गई गतिविधियों और दावों से मेल खाना चाहिए.
टेस्ट पाथ: टेस्ट केस के सामान्य टाइप
सॉफ़्टवेयर डेवलपमेंट में, टेस्ट केस एक ऐसा कोड होता है जिसमें एक खास तरह के व्यवहार की उम्मीद की जाती है और उसकी जांच की जाती है. आम तौर पर, टेस्ट केस बनाने की तीन स्थितियां होती हैं.
पहला वाला सबसे मशहूर है, जिसका शायद आप पहले से ही इस्तेमाल कर रहे हैं. यह खुशनुमा पाथ है, जिसे “हैप्पी डे स्थिति” या “गोल्डन पाथ” के नाम से भी जाना जाता है. इससे आपकी सुविधा, ऐप्लिकेशन या बदलाव के सबसे आम इस्तेमाल के उदाहरण के बारे में पता चलता है.
आपके टेस्ट केस में शामिल किया जाने वाला दूसरा सबसे अहम टेस्ट पाथ अक्सर छोड़ दिया जाता है, क्योंकि यह असहज होता है—क्योंकि इसके नाम का मतलब यह हो सकता है. यह एक “डरावने पाथ” या दूसरे शब्दों में, नेगेटिव टेस्ट होता है. यह पाथ उन स्थितियों को टारगेट कर��ा है ��ि����ी वजह से कोड ठीक से काम नहीं करता या गड़बड़ी की स्थिति डालता है. इन स्थितियों की जांच करना खास तौर पर तब अहम है, जब आपके पास ऐसे मामले होते हैं जिन्हें इस्तेमाल करने का जोखिम बहुत ज़्यादा होता है और वे हिस्सेदारों या उपयोगकर्ताओं पर ज़्यादा जोखिम लागू कर रहे हैं.
आप कुछ और पाथ के बारे में जानना और उनका इस्तेमाल करने के बारे में सोच सकते हैं. हालांकि, आम तौर पर उनका इस्तेमाल बहुत कम किया जाता है. इस टेबल में इनके बारे में खास जानकारी दी गई है:
| टेस्ट पाथ | जानकारी |
|---|---|
| एंग्री पाथ | इसकी वजह से गड़बड़ी होती है, लेकिन पहले से ही कोई गड़बड़ी हो सकती है. उदाहरण के लिए, अगर आपको यह पक्का करना हो कि गड़बड़ी को ठीक करने का तरीका ठीक से काम कर रहा हो. |
| पाथ बकाया है | इस पाथ की मदद से, सुरक्षा से जुड़ी उन सभी स्थितियों का समाधान किया जा सकता है जिन्हें आपके ऐप्लिकेशन को पूरा करना होगा. |
| पाथ खाली करें | आपके ऐप्लिकेशन में मौजूद स्थिति की जांच के पाथ को, काम करने के लिए ज़रूरी डेटा नहीं मिलता. उदाहरण के लिए, शून्य वैल्यू की जांच करना. |
| भुलक्कड़ पथ | कम संसाधनों की मदद से अपने ऐप्लिकेशन के काम करने के तरीके की जांच करना. उदाहरण के लिए, डेटा लीक होना. |
| तय नहीं किया जा सका पाथ | ऐसे उपयोगकर्ता के साथ टेस्ट करना जो आपके ऐप्लिकेशन में कार्रवाइयां करने या उपयोगकर्ता की जानकारी को फ़ॉलो करने की कोशिश कर रहा है, लेकिन उसे पूरा नहीं किया गया है. उदाहरण के लिए, ऐसा तब हो सकता है, जब उपयोगकर्ता अपने वर्कफ़्लो में रुकावट डालता है. |
| लालची पथ | बहुत ज़्यादा इनपुट या डेटा का इस्तेमाल करके टेस्ट करना. |
| परेशान करने वाला रास्ता | अपने ऐप्लिकेशन को तब तक लोड करने की कोशिश करना, जब तक वह काम करना बंद न कर दे (लोड टेस्ट की तरह). |
उन पाथ को कैटगरी में बांटने के कई तरीके हैं. दो सामान्य तरीके हैं:
- ��मानता विभाजन. जांच का एक तरीका जो टेस्ट केस को ग्रुप या बंटवारे में बांटता है. इसका नतीजा यह होता है कि इक्वलेंसी क्लास बनाने में मदद मिलती है. यह इस विचार पर आधारित है कि अगर किसी पार्टीशन में मौजूद एक टेस्ट केस में खराबी का पता चलता है, तो उसी पार्टी के अन्य टेस्ट केस में इस तरह की खराबियां हो सकती हैं. किसी खास समतुल्य क्लास में सभी इनपुट एक जैसे व्यवहार करते हैं. इसलिए, टेस्ट केस की संख्या को कम किया जा सकता है. इक्विलेंस पार्टीशन के बारे मे��� ज़्यादा जानें.
- सीमित विश्लेषण. टेस्टिंग का ऐसा तरीका जिसे बाउंड्री वैल्यू का विश्लेषण भी कहा जाता है. यह इनपुट वैल्यू की सीमाओं या चरम सीमाओं की जांच करता है, ताकि सिस्टम की क्षमताओं या सीमाओं की वजह से होने वाली किसी भी संभावित समस्या या गड़बड़ी का पता लगाया जा सके.
सबसे सही तरीका: टेस्ट केस लिखना
टेस्टर के लिखे गए क्लासिकल टेस्ट केस में खास डेटा होता है. इससे आपको उस टेस्ट के कॉन्टेंट को समझने में मदद मिलती है जो आपको करना है. साथ ही, टेस्ट को लागू भी किया जा सकता है. एक सामान्य टेस्टर, टेस्ट की कोशिशों के बारे में एक टेबल में जानकारी देगा. इस चरण में हम दो पैटर्न का इस्तेमाल कर सकते हैं. इससे हमें अपने टेस्ट केस को स्ट्रक्चर करने में मदद मिलती है और बाद में, टेस्ट केस को खुद भी तय करने में मदद मिलती है:
- पैटर्न व्यवस्थित करें, कार्रवाई करें, दावा करें. "व्यवस्थित करें, कार्रवाई करें, दावा करें" (इसे "एएए" या "ट्रिपल A" भी कहा जाता है) टेस्टिंग पैटर्न में, टेस्ट को तीन अलग-अलग चरणों में व्यवस्थित करने का एक तरीका होता है: टेस्ट को व्यवस्थित करना, उसके बाद टेस्ट करना, और आखिर में नतीजा निकालना.
- दिया गया, कब, और फिर पैटर्न. यह पैटर्न, एएए पैटर्न से मिलता-जुलता है. हालांकि, व्यवहार से होने वाले डेवलपमेंट में इसकी कुछ जड़ें शामिल हैं.
जैसे ही हम टेस्ट के स्ट्रक्चर के बारे में बताएंगे, आने वाले समय में आने वाले लेखों में इन पैटर्न के बारे में ज़्यादा जानकारी दी जाएगी. अगर आपको इस चरण में इन पैटर्न के बारे में ज़्यादा गहराई से जानना है, तो ये दो लेख पढ़ें: व्यवस्थित-Act-Assert: अच्छे टेस्ट लिखने के लिए पैटर्न और उसके साथ-साथ पहले से कोई जानकारी दें.
इस लेख में मौजूद जानकारी के हिसाब से, यहां दी गई टेबल में एक क्लासिक उदाहरण के बारे में बताया गया है:
| जानकारी | जानकारी |
|---|---|
| ज़रूरी शर्तें | टेस्ट लिखने से पहले किए जाने वाले सभी काम. |
| ऑब्जेक्ट की जांच की जा रही है | किस चीज़ की पुष्टि करनी है? |
| इनपुट डेटा | वैरिएबल और उनकी वैल्यू. |
| लागू किए जाने वाले चरण | टेस्ट में जान डालने के लिए किए जाने वाले सभी काम: टेस्ट के दौरान की जाने वाली सभी कार्रवाइयां या इंटरैक्शन. |
| अनुमानित नतीजा | क्या होना चाहिए और किन उम्मीदों को पूरा करना चाहिए. |
| असल नतीजा | असल में क्या होता है. |
ऑटोमेटेड टेस्टिंग में, आपको जांच के इन सभी केस को उसी तरह दर्ज करने की ज़रूरत नहीं होती है जैसी जांच करने वाले को करते हैं. हालांकि, ऐसा करना वाकई मददगार होता है. ध्यान दें, आपको यह सारी जानकारी अपने टेस्ट में मिल जाएगी. आइए, इस क्लासिकल टेस्ट केस को ऑटोमेटेड टेस्ट में बदलते हैं.
| जानकारी | टेस्ट ऑटोमेशन में अनुवाद करना |
|---|---|
| ज़रूरी शर्तें | टेस्ट की तैयारी करने और इस बारे में सोचने के लिए कि टेस्ट की स्थिति को पूरा करने के लिए आपको किन चीज़ों की ज़रूरत है. |
| ऑब्जेक्ट की जांच की जा रही है | यह “ऑब्जेक्ट” कई चीज़ें हो सकती हैं: कोई ऐप्लिकेशन, फ़्लो, यूनिट या कॉम्पोनेंट, जिसकी जांच हो रही है. |
| इनपुट डेटा | पैरामीटर वैल्यू. |
| लागू किए जाने वाले चरण | इसमें, टेस्ट में किए जाने वाले सभी ऐक्शन और निर्देश शामिल होते हैं. साथ ही, वे कार्रवाइयां ��िन पर आपकी कार्रवाई की जाती है, और यह पता लगाना कि कुछ खास चीज़ों को करने पर क्या होता है. |
| अनुमानित नतीजा | आपका दावा, ऐप्लिकेशन की पुष्टि करने के लिए इस्तेमाल किया जाता है. साथ ही, इसमें वे बातें भी शामिल होती हैं जिनका इस्तेमाल आपने ऐप्लिकेशन में किया है. |
| असल नतीजा | आपके ऑटोमेटेड टेस्ट का नतीजा. |