मॉड्यूल 7 · Test design techniques

इक्विवैलेंस पार्टीशनिंग

Mutqan Soft QA टीम द्वारा · · 17 मिनट · मध्यम

Equivalence partitioning (EP) एक black-box test design technique है जो test object के data को partitions में बाँटती है, जिन्हें equivalence classes भी कहते हैं। एक partition की सभी values के साथ एक जैसा व्यवहार अपेक्षित है: अगर एक value कोई defect दिखाती है, तो माना जाता है कि उसी partition की कोई भी दूसरी value भी उसे दिखाएगी। इसलिए आप हर value नहीं, हर partition से एक value टेस्ट करते हैं।

उदाहरण: एक shop 1 से 10 units के orders स्वीकार करता है। Quantity field का एक valid partition है, 1 से 10, और तीन invalid partitions: 1 से कम, 10 से ज़्यादा, और ऐसा input जो whole number नहीं है, जैसे 2.5 या two। चार tests, जैसे 4, -3, 25 और two, चारों partitions exercise कर लेते हैं; 5 और 6 जोड़ने से कुछ नया exercise नहीं होता।

यह क्यों ज़रूरी है

Exhaustive testing असंभव है, इसलिए हर test suite एक sample है; सवाल यह है कि sample सोच-समझकर चुना गया या नहीं। Partitions के बिना testers अक्सर ऐसी कई values आज़माते हैं जो एक ही logic से गुज़रती हैं, जैसे quantity field के लिए 3, 5 और 7, और वह value कभी नहीं जिसे system को reject करना चाहिए। Suite बड़ा दिखता है, फिर भी पूरे के पूरे behaviours छूट जाते हैं।

EP में हर test values के एक ऐसे group का प्रतिनिधि होता है जिसका व्यवहार एक जैसा होना चाहिए। Suite छोटा रहता है, बिना test वाला partition साफ़ दिखने वाला gap बन जाता है, और आपको ऐसा coverage figure मिलता है जिसका review में बचाव किया जा सके। Boundary value analysis सीधे partitions पर बनती है, और decision table testing व pairwise testing अक्सर partitions को ही वे values बनाती हैं जिनके combinations टेस्ट होते हैं।

Valid और invalid partitions, हर एक से एक value

Partitions test object से जुड़े किसी भी data element के लिए पहचाने जा सकते हैं: inputs, outputs, configuration items, internal values, time-related values और interface parameters। वे continuous या discrete, ordered या unordered, finite या infinite हो सकते हैं, लेकिन उन्हें कभी overlap नहीं करना चाहिए और कोई भी partition खाली नहीं होना चाहिए।

जिन values को test object को process करना चाहिए उनका partition valid partition है; जिन्हें उसे reject या ignore करना चाहिए उनका partition invalid partition है। ISTQB syllabus बताता है कि teams "valid" और "invalid" को अलग-अलग तरह परिभाषित करती हैं (कुछ teams किसी value को तभी valid मानती हैं जब specification में उसकी processing तय हो), इसलिए पहले मतलब पर सहमति बना लें। फिर हर partition से एक value चुनें। कोई भी value चलेगी; testers आम तौर पर बीच की typical value लेते हैं और किनारे boundary value analysis पर छोड़ते हैं।

  • Ranges: "1 से 10 units" से एक valid partition और दोनों तरफ़ एक-एक invalid partition मिलता है।
  • Values के sets: "card, cash या wallet" से अलग तरह process होने वाली हर value का एक valid partition बनता है, और किसी भी दूसरी value के लिए एक invalid partition।
  • Outputs: तीन fee tiers तीन partitions हैं, भले ही input एक ही number हो।
  • शक: अगर partition के किसी हिस्से के साथ अलग व्यवहार हो सकता है, जैसे 1 से कम values के बीच 0, तो partition को बाँट दें और पूछें।

आज़माएँ: इक्विवैलेंस पार्टीशन जनरेटर आज़माएँ: नेगेटिव टेस्ट जनरेटर

Equivalence partition coverage

जैसा test design activity वाले lesson में देखा, coverage coverage items पर गिनी जाती है। EP में coverage items partitions हैं, valid भी और invalid भी। Coverage उन partitions की संख्या है जिन्हें कम से कम एक test case ने exercise किया, पहचाने गए कुल partitions से भाग देकर, percentage में।

यह figure उतना ही अच्छा है जितनी उसके पीछे की list: जिस partition को किसी ने पहचाना ही नहीं वह गिना नहीं जाता, इसलिए उसके छूटे रहते भी coverage 100% दिख सकती है। Partitions को ऐसे test design में रखें जिसे दूसरे review कर सकें, सिर्फ़ अपने दिमाग़ में नहीं।

Field: quantity, whole numbers, valid 1..10

Partitions:    Q1 below 1 (invalid)      Q2 1..10 (valid)
               Q3 above 10 (invalid)     Q4 not a whole number (invalid)

Tests so far:  4 -> Q2,  25 -> Q3
Coverage:      2 of 4 partitions = 50%

Add:           -3 -> Q1,  "two" -> Q4
Coverage:      4 of 4 partitions = 100%

कई parameters और each choice coverage

ज़्यादातर test objects एक से ज़्यादा input लेते हैं। हर parameter का partitions का अपना set होता है, और एक test case एक साथ हर set से एक partition इस्तेमाल करता है। Combinations तेज़ी से बढ़ते हैं: 3, 2 और 2 valid partitions वाले तीन parameters से 3 × 2 × 2 = 12 combinations बनते हैं।

कई sets के लिए सबसे सरल criterion each choice coverage है: हर set का हर partition कम से कम एक test case से exercise हो, combinations की परवाह किए बिना। जब सभी combinations allowed हों, तो valid partitions के लिए उतने ही test cases चाहिए जितने valid partitions उस parameter में हैं जिसके valid partitions सबसे ज़्यादा हैं। Combinations pairwise testing का विषय हैं, जो इसी module में आगे आती है।

हर invalid partition को उसका अपना test case दें और बाकी सभी parameters valid रखें; practice में यह आम नियम है। अगर एक test दो invalid values भेजे और system पहले error message पर रुक जाए, तो दूसरा partition असल में exercise ही नहीं हुआ: दूसरी value की handling में कोई defect हो तो वह छिपा रह जाता है।

Worked example: parcel की shipping fee

Requirement: "0.1 से 2.0 kg weight की fee 20 SAR, 2.1 से 10.0 kg की 35 SAR, 10.1 से 30.0 kg की 60 SAR। Weight में एक decimal होता है; 30.0 kg से भारी parcels refuse होते हैं। Destination Domestic या GCC है; GCC पर 30 SAR जुड़ते हैं। Speed Standard या Express है; Express पर 25 SAR जुड़ते हैं।"

Weight के छह partitions हैं: शून्य या उससे कम, तीनों fee tiers, 30.0 kg से ज़्यादा, और ऐसा input जो number नहीं है। Destination के तीन (Domestic, GCC, कोई और देश) और speed के दो: कुल 11 partitions, 7 valid और 4 invalid। अगर field में दो decimals वाला weight, जैसे 2.05, आ सकता है, तो पूछें कि वह round होता है या reject; जवाब से एक और partition जुड़ सकता है।

Shipping fee वाले उदाहरण में parcel का weight पाँच ordered partitions में बँटता है, दो invalid और तीन valid fee tiers, और हर partition से एक weight टेस्ट होता है।

weight: kg, one decimal, accepted 0.1..30.0

अक्ष 0 kg से 30 kg तक
  • ≤ 0.0W1 · अमान्य: शून्य या कम
  • 0.1–2.0W2 · वैध: 20 SAR
  • 2.1–10.0W3 · वैध: 35 SAR
  • 10.1–30.0W4 · वैध: 60 SAR
  • ≥ 30.1W5 · अमान्य: बहुत भारी
  1. 1−2.0 kg TC4: अस्वीकारW1 का प्रतिनिधि
  2. 21.5 kg TC1: 20 SARadd-ons से पहले की weight fee
  3. 36.0 kg TC2: 35 SARadd-ons से पहले की weight fee
  4. 418.5 kg TC3: 60 SARadd-ons से पहले की weight fee
  5. 542.0 kg TC5: अस्वीकारW5 का प्रतिनिधि

W6, यानी ऐसा input जो number नहीं है (test case 6, abc), number line पर नहीं आ सकता, न ही destination और speed के partitions; नीचे की table सभी 11 partitions दिखाती है।

  • Test cases 1 से 3 valid partitions की each choice coverage पूरी करते हैं; तीन काफ़ी हैं क्योंकि सबसे बड़े set, weight, में तीन valid partitions हैं।
  • Test cases 4 से 7 में से हर एक, बाकी सभी values valid रखते हुए, एक invalid partition cover करता है। सात test cases सभी 11 partitions exercise करते हैं: 100% EP coverage।
  • अगर destination drop-down list है, तो D3 user interface में चुना नहीं जा सकता; इसे API से टेस्ट करें, या पूछें कि server इसे validate करता है या नहीं।
  • अभी cover नहीं हुआ: Express के साथ सबसे हल्का tier जैसे combinations, और किनारे 0.0|0.1, 2.0|2.1, 10.0|10.1 और 30.0|30.1, जिन्हें आप boundary value analysis से जोड़ सकते हैं, जो अगले lesson की technique है।
Partitions
  Weight       W1 <= 0.0 (invalid)   W2 0.1-2.0 (valid)    W3 2.1-10.0 (valid)
               W4 10.1-30.0 (valid)  W5 > 30.0 (invalid)   W6 not a number (invalid)
  Destination  D1 Domestic (valid)   D2 GCC (valid)        D3 other country (invalid)
  Speed        S1 Standard (valid)   S2 Express (valid)

TC  Weight  Destination  Speed     Covers     Expected
1   1.5     Domestic     Standard  W2 D1 S1   fee 20 SAR
2   6.0     GCC          Express   W3 D2 S2   fee 35 + 30 + 25 = 90 SAR
3   18.5    Domestic     Express   W4 D1 S2   fee 60 + 25 = 85 SAR
4   -2.0    Domestic     Standard  W1         refused: weight must be above 0
5   42.0    Domestic     Standard  W5         refused: parcel over 30.0 kg
6   abc     Domestic     Standard  W6         refused: weight must be a number
7   1.5     Egypt        Standard  D3         refused: destination not served

Coverage: 11 of 11 partitions = 100% with 7 test cases

आज़माएँ: टेस्ट केस जनरेटर आज़माएँ: वैलिडेशन टेस्ट जनरेटर

आम गलतियाँ

  • सिर्फ़ inputs के partitions बनाना और outputs भूल जाना: एक weight field से बनने वाले तीन fee tiers तीन partitions हैं।
  • सिर्फ़ valid partitions टेस्ट करना। Invalid partitions coverage में गिने जाते हैं, और error handling वहीं टूटती है।
  • एक test case में कई invalid values डाल देना, जिससे पहली value का reject होना बाकी values की handling छिपा देता है।
  • "0 से 10" और "10 से 20" जैसे overlapping partitions लिखना; हर value ठीक एक partition में होती है।
  • एक ही partition से कई values टेस्ट करके उसे thorough मानना: cost ज़्यादा, coverage उतनी ही।
  • 100% EP coverage को quality का सबूत मानना; इसका मतलब सिर्फ़ इतना है कि हर पहचाना गया partition कम से कम एक बार exercise हुआ।

QA का नज़रिया

EP test basis पढ़ते समय ही शुरू होती है। Requirement या acceptance criterion का हर rule partitions सुझाता है, और हर अस्पष्ट rule एक सवाल है: "0 weight पर क्या होगा?", "क्या GCC parcel Express से जा सकता है?"। Refinement के दौरान product owner से पूछें और जवाब लिख लें; वही आपके expected results बनते हैं।

Test design में partitions को IDs (W1, D2…) के साथ दर्ज करें, हर test case को उसके cover किए partitions से link करें, और हर feature की EP coverage report करें, ताकि reviewers किसी छूटे partition पर सवाल उठा सकें। जब कोई test fail हो, तो bug report में value के साथ partition भी लिखें: शायद values का पूरा group प्रभावित है, सिर्फ़ एक number नहीं।

अभ्यास

Cinema ticket form के partitions बनाएँ

आपका काम

एक cinema booking form में दो fields हैं। Age पूरे सालों में: 0 से 12 पर child price, 13 से 59 पर adult price, 60 से 120 पर senior price; बाकी values reject होती हैं। Seat type: Standard, Premium या VIP; इसके अलावा कुछ भी reject होता है।

दोनों fields के partitions पहचानें और सबसे छोटा test set design करें जो 100% equivalence partition coverage दे, invalid partitions एक-एक करके टेस्ट करते हुए।

चरण
  1. हर field के partitions लिखें, invalid partitions समेत, हर एक के ID के साथ।
  2. Each choice coverage से valid partitions cover करें।
  3. हर invalid partition के लिए एक test case जोड़ें, दूसरा field valid रखते हुए।
  4. Partitions और test cases गिनें, और coverage बताएँ।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Age: A1 0 से कम (invalid), A2 0 से 12 child, A3 13 से 59 adult, A4 60 से 120 senior (valid), A5 120 से ज़्यादा (invalid), A6 whole number नहीं, जैसे ten या 7.5 (invalid)। Seat type: T1 Standard, T2 Premium, T3 VIP (valid), T4 कोई और value (invalid)। कुल 10 partitions।

Valid, each choice, तीन test cases में, क्योंकि दोनों fields में तीन-तीन valid partitions हैं: (8, Standard) A2 और T1 cover करता है; (35, Premium) A3 और T2; (70, VIP) A4 और T3।

Invalid, एक-एक करके: (-5, Standard) A1; (130, Standard) A5; (ten, Standard) A6; (35, Balcony) T4।

सात test cases सभी 10 partitions cover करते हैं: 100% EP coverage। पूछें कि क्या एक साल से छोटे बच्चे की age 0 डाली जाती है, और 7.5 reject होता है या round; अगर 7.5 और ten अलग-अलग तरह handle होते हैं, तो A6 को दो partitions में बाँटें।

अक्सर पूछे जाने वाले सवाल

क्या equivalence class और equivalence partition एक ही हैं?

हाँ। कई किताबें और tools, जिनमें Mutqan का Equivalence Partition Generator भी है, equivalence class कहते हैं; ISTQB syllabus equivalence partition कहता है। दोनों का मतलब values का ऐसा set है जिसे test object से एक ही तरह process किए जाने की उम्मीद है।

Partition से कौन-सी value चुनूँ?

Technique की परिभाषा के हिसाब से कोई भी value सही है, क्योंकि partition की सभी values का व्यवहार एक जैसा माना जाता है। Testers आम तौर पर बीच की typical value लेते हैं और किनारे boundary value analysis पर छोड़ते हैं। अगर लगे कि कोई value बाकी partition से अलग व्यवहार करती है, तो शायद partitioning गलत है: उस partition को बाँट दें।

कई parameters हों तो क्या each choice coverage काफ़ी है?

यह न्यूनतम है: हर parameter का हर partition एक बार exercise होता है। यह parameters के बीच interactions टेस्ट नहीं करती, इसलिए जब एक parameter की values दूसरे के result को बदलें, तो decision table testing या pairwise testing से combinations जोड़ें।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
टूल्स

Mutqan tools से अभ्यास करें

नेगेटिव टेस्ट जनरेटर

फ़ॉर्म फ़ील्ड और API के लिए negative टेस्ट केस बनाएँ: खाली, null, ग़लत टाइप, बहुत लंबा, injection, अमान्य फ़ॉर्मेट।

टेस्ट डिज़ाइन

वैलिडेशन टेस्ट जनरेटर

फ़ॉर्म फ़ील्ड के लिए validation टेस्ट केस बनाएँ: required, फ़ॉर्मेट, लंबाई, रेंज, pattern और cross-field नियम।

टेस्ट डिज़ाइन

टेस्ट केस जनरेटर

फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।

टेस्ट डिज़ाइन

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा