एक field 1 से 100 तक की मात्रा लेता है। आप कौन से test case लिखेंगे?

equivalence partitioning के साथ boundary value analysis इस्तेमाल कीजिए। partition हैं रेंज से नीचे, वैध रेंज, और रेंज से ऊपर, तो हर एक से एक प्रतिनिधि। असली मजा boundaries में है: 0, 1, 2, 99, 100, 101। फिर गैर संख्या वाले मामले जोड़िए: खाली, ऋणात्मक, दशमलव, खाली जगह, बहुत बड़ी संख्याएं, और text, साथ ही यह कि टाइप करने के बजाय paste करने पर field कैसा बर्ताव करता है।

मैं जगह छांटने के लिए equivalence partitioning इस्तेमाल करूंगा, फिर दिलचस्प हिस्सों के लिए boundary value analysis। partition हैं एक से नीचे, एक से सौ तक, और सौ से ऊपर, तो हर एक से एक value इन वर्गों को कवर कर देती है। फिर boundaries, जहां defects सच में रहते हैं, क्योंकि किसी रेंज की जांच में off by one सबसे आम गलती है: 0, 1, 2, 99, 100, और 101। अगर मैं सिर्फ छह case चला सकता हूं, तो यही छह हैं। इसके बाद मैं हर उस चीज के पीछे जाता हूं जो सीधी सादी integer नहीं है, क्योंकि वहीं validation छूट जाती है: खाली, एक अकेली space, कोई ऋणात्मक संख्या, 1.5 जैसा दशमलव, आगे लगा शून्य, कोई बहुत लंबी संख्या जो पीछे बैठे type से overflow हो जाए, scientific notation, और सादा text। मैं input का तरीका भी टेस्ट करता हूं, क्योंकि टाइप करना, paste करना और browser के spinner तीर अक्सर अलग अलग code path पर जाते हैं, और मैंने ऐसे bug पकड़े हैं जहां टाइप करने पर validation थी और paste पर नहीं। और मैं सिर्फ browser नहीं, server भी जांचता हूं, सीधे API पर 101 भेजकर, क्योंकि client side validation एक सुविधा है, कोई नियंत्रण नहीं।