Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 647 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
647 questions
421
EN + हिं Medium
GB What is the fundamental difference between 'composition' and 'inheritance' as reuse mechanisms in OOP?
IN OOP में पुन: उपयोग तंत्र के रूप में 'संरचना' और 'विरासत' के बीच मूलभूत अंतर क्या है?
A
Composition only with interfaces; inheritance requires abstract classes केवल इंटरफेस के साथ रचना; विरासत के लिए अमूर्त वर्गों की आवश्यकता होती है
B
Inheritance is static compile-time reuse creating 'is-a' relationships exposing parent internals; composition is dynamic runtime 'has-a' relationship that is more flexible, testable, and avoids the fragile base class problem वंशानुक्रम स्थैतिक संकलन-समय का पुन: उपयोग है जो मूल आंतरिक को उजागर करने वाले 'ए-ए' संबंध बनाता है; रचना गतिशील रनटाइम 'है-ए' संबंध है जो अधिक लचीला, परीक्षण योग्य है, और नाजुक बेस क्लास समस्या से बचाती है
C
Composition always produces faster code than inheritance कंपोज़िशन हमेशा इनहेरिटेंस की तुलना में तेज़ कोड उत्पन्न करता है
D
Both are equivalent; choice depends only on preference दोनों समतुल्य हैं; चुनाव केवल प्राथमिकता पर निर्भर करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The 'fragile base class problem' shows inheritance's weakness: changing a parent class can break subclasses unexpectedly. GoF's 'favour composition over inheritance' recommends building objects from collaborating components, enabling runtime behaviour changes through dependency injection.
व्याख्या (हिन्दी) 'नाजुक आधार वर्ग समस्या' वंशानुक्रम की कमजोरी को दर्शाती है: मूल वर्ग को बदलने से उपवर्ग अप्रत्याशित रूप से टूट सकते हैं। GoF की 'विरासत पर अनुकूल संरचना' निर्भरता इंजेक्शन के माध्यम से रनटाइम व्यवहार परिवर्तन को सक्षम करने, सहयोगी घटकों से वस्तुओं के निर्माण की सिफारिश करती है।
422
EN + हिं Medium
GB What problem does the 'Observer' pattern solve and when does it introduce risk?
IN 'ऑब्जर्वर' पैटर्न किस समस्या का समाधान करता है और यह कब जोखिम उत्पन्न करता है?
A
Solves performance bottlenecks; introduces risk in single-user applications प्रदर्शन संबंधी बाधाओं को हल करता है; एकल-उपयोगकर्ता अनुप्रयोगों में जोखिम लाता है
B
Solves notifying multiple dependent objects when a subject changes without tight coupling; introduces risk of memory leaks (observers not unsubscribed), unexpected update cascades, and non-deterministic notification order जब कोई विषय बिना टाइट कपलिंग के बदलता है तो कई आश्रित वस्तुओं को सूचित करने का समाधान करता है; मेमोरी लीक (पर्यवेक्षकों ने सदस्यता समाप्त नहीं की है), अप्रत्याशित अपडेट कैस्केड और गैर-नियतात्मक अधिसूचना आदेश का जोखिम पेश किया है
C
Solves creating objects without specifying their exact classes वस्तुओं को उनकी सटीक कक्षाओं को निर्दिष्ट किए बिना बनाकर हल करता है
D
Introduces risk only in multithreaded environments; safe for single-threaded use केवल बहु-थ्रेडेड वातावरण में जोखिम का परिचय देता है; एकल-थ्रेडेड उपयोग के लिए सुरक्षित
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Observer (GoF) decouples subjects from observers using publish-subscribe. Risks: memory leaks when observers are not removed; update avalanches where one notification triggers uncontrollable chains; unexpected re-entry when an observer modifies the subject during notification.
व्याख्या (हिन्दी) ऑब्जर्वर (जीओएफ) पब्लिश-सब्सक्राइब का उपयोग करके विषयों को पर्यवेक्षकों से अलग करता है। जोखिम: जब पर्यवेक्षकों को नहीं हटाया जाता है तो मेमोरी लीक हो जाती है; अद्यतन हिमस्खलन जहां एक अधिसूचना अनियंत्रित श्रृंखलाओं को ट्रिगर करती है; जब कोई पर्यवेक्षक अधिसूचना के दौरान विषय को संशोधित करता है तो अप्रत्याशित पुनः प्रवेश।
423
EN + हिं Medium
GB What is 'separation of concerns' and how is it architecturally implemented in MVC?
IN 'चिंताओं का पृथक्करण' क्या है और इसे एमवीसी में वास्तुशिल्प रूप से कैसे लागू किया जाता है?
A
Different developers work on different parts simultaneously अलग-अलग डेवलपर अलग-अलग हिस्सों पर एक साथ काम करते हैं
B
Organising code so each module addresses a distinct aspect; MVC implements this by separating data/business logic (Model), presentation (View), and user interaction handling (Controller) कोड को व्यवस्थित करना ताकि प्रत्येक मॉड्यूल एक विशिष्ट पहलू को संबोधित करे; एमवीसी डेटा/बिजनेस लॉजिक (मॉडल), प्रेजेंटेशन (व्यू), और यूजर इंटरेक्शन हैंडलिंग (कंट्रोलर) को अलग करके इसे लागू करता है।
C
Separation of concerns only applies to database design चिंताओं का पृथक्करण केवल डेटाबेस डिज़ाइन पर लागू होता है
D
MVC implements separation by storing all state in Controller एमवीसी नियंत्रक में सभी स्थितियों को संग्रहीत करके पृथक्करण लागू करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Dijkstra's separation of concerns reduces complexity by preventing one concern from bleeding into another. MVC applies it to UI: the Model knows nothing about presentation; the View knows nothing about business rules; the Controller knows nothing about storage.
व्याख्या (हिन्दी) दिज्क्स्ट्रा की चिंताओं को अलग करने से एक चिंता को दूसरे में फैलने से रोककर जटिलता कम हो जाती है। एमवीसी इसे यूआई पर लागू करता है: मॉडल प्रस्तुति के बारे में कुछ नहीं जानता है; व्यू व्यावसायिक नियमों के बारे में कुछ नहीं जानता; नियंत्रक को भंडारण के बारे में कुछ नहीं पता है।
424
EN + हिं Medium
GB What is the 'magic number' anti-pattern in coding and how does it violate maintainability principles?
IN कोडिंग में 'मैजिक नंबर' एंटी-पैटर्न क्या है और यह कैसे रखरखाव सिद्धांतों का उल्लंघन करता है?
A
Randomly generated cryptographic keys embedded in code कोड में एम्बेडेड बेतरतीब ढंग से उत्पन्न क्रिप्टोग्राफ़िक कुंजियाँ
B
Unexplained numeric literals without context in code (e.g., 'if status == 4'); they make code intent opaque and require future maintainers to guess what the value represents कोड में संदर्भ के बिना अस्पष्ट संख्यात्मक अक्षर (उदाहरण के लिए, 'यदि स्थिति == 4'); वे कोड के इरादे को अपारदर्शी बनाते हैं और भावी अनुरक्षकों को यह अनुमान लगाने की आवश्यकता होती है कि मूल्य क्या दर्शाता है
C
Performance-critical constants that must remain unexplained to prevent reverse engineering प्रदर्शन-महत्वपूर्ण स्थिरांक जिन्हें रिवर्स इंजीनियरिंग को रोकने के लिए अस्पष्टीकृत रहना चाहिए
D
Only refers to values 0 and 1 in boolean contexts केवल बूलियन संदर्भों में मान 0 और 1 को संदर्भित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A magic number like 'if (retries == 3)' conveys no meaning. Naming it 'MAX_RETRY_ATTEMPTS = 3' documents intent, enables searching, and makes updates trivial. This is a fundamental readability and DRY violation.
व्याख्या (हिन्दी) 'if (पुनः प्रयास == 3)' जैसी जादुई संख्या का कोई मतलब नहीं है। इसे 'MAX_RETRY_ATTEMPTS = 3' नाम देने से दस्तावेज़ का उद्देश्य खोज करना संभव हो जाता है, और अपडेट को तुच्छ बना देता है। यह एक मौलिक पठनीयता और DRY उल्लंघन है।
425
EN + हिं Easy
GB What does the DRY principle prohibit and what is its violation called?
IN DRY सिद्धांत किस पर रोक लगाता है और इसका उल्लंघन क्या कहलाता है?
A
Writing comments in code; violations called 'over-commenting' कोड में टिप्पणियाँ लिखना; उल्लंघन जिसे 'अति-टिप्पणी' कहा जाता है
B
Having multiple representations of the same knowledge in the system; violations called 'WET' leading to inconsistent updates when one copy changes but others don't सिस्टम में एक ही ज्ञान के कई प्रतिनिधित्व होना; 'WET' नामक उल्लंघनों के कारण जब एक प्रति बदलती है लेकिन अन्य नहीं बदलती तो असंगत अद्यतन होते हैं
C
Using the same variable name in different scopes विभिन्न क्षेत्रों में एक ही चर नाम का उपयोग करना
D
Only about avoiding copy-pasted code blocks, not data duplication केवल कॉपी-पेस्ट किए गए कोड ब्लॉक से बचने के बारे में, डेटा डुप्लिकेशन के बारे में नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hunt and Thomas defined DRY as: 'Every piece of knowledge must have a single, unambiguous, authoritative representation.' WET code creates synchronisation problems — if business rule X is encoded in three places and one changes, the system becomes inconsistent.
व्याख्या (हिन्दी) हंट और थॉमस ने DRY को इस प्रकार परिभाषित किया: 'ज्ञान के प्रत्येक टुकड़े में एक एकल, स्पष्ट, आधिकारिक प्रतिनिधित्व होना चाहिए।' WET कोड सिंक्रनाइज़ेशन समस्याएँ पैदा करता है - यदि व्यवसाय नियम X को तीन स्थानों पर एन्कोड किया गया है और एक में परिवर्तन होता है, तो सिस्टम असंगत हो जाता है।
426
EN + हिं Medium
GB What is the 'Boy Scout Rule' in software development and how does it relate to managing technical debt?
IN सॉफ्टवेयर विकास में 'बॉय स्काउट नियम' क्या है और यह तकनीकी ऋण प्रबंधन से कैसे संबंधित है?
A
Requires all developers to attend outdoor team-building activities monthly सभी डेवलपर्स को मासिक रूप से आउटडोर टीम-निर्माण गतिविधियों में भाग लेने की आवश्यकता है
B
'Leave the campground cleaner than you found it' applied to code: whenever you touch a module leave it slightly cleaner — incrementally paying down technical debt without dedicated refactoring sprints कोड पर लागू 'कैंपग्राउंड को जितना आपने पाया था उससे अधिक साफ-सुथरा छोड़ें': जब भी आप किसी मॉड्यूल को छूते हैं तो इसे थोड़ा साफ छोड़ दें - समर्पित रीफैक्टरिंग स्प्रिंट के बिना तकनीकी ऋण का क्रमिक रूप से भुगतान करना
C
Junior developers clean up code written by senior developers जूनियर डेवलपर्स वरिष्ठ डेवलपर्स द्वारा लिखे गए कोड को साफ़ करते हैं
D
A security practice requiring code review before deployment एक सुरक्षा अभ्यास जिसमें तैनाती से पहले कोड समीक्षा की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Robert Martin's Boy Scout Rule addresses the reality that dedicated refactoring sprints are often deprioritised. By making incremental improvement routine — rename a confusing variable, extract a long method — teams prevent codebase degradation without special effort allocation.
व्याख्या (हिन्दी) रॉबर्ट मार्टिन का बॉय स्काउट नियम इस वास्तविकता को संबोधित करता है कि समर्पित रिफैक्टरिंग स्प्रिंट को अक्सर प्राथमिकता नहीं दी जाती है। वृद्धिशील सुधार की दिनचर्या बनाकर - एक भ्रमित करने वाले चर का नाम बदलें, एक लंबी विधि निकालें - टीमें विशेष प्रयास आवंटन के बिना कोडबेस गिरावट को रोकती हैं।
427
EN + हिं Easy
GB What is 'defensive coding' and in what scenario is it specifically inappropriate?
IN 'रक्षात्मक कोडिंग' क्या है और किस परिदृश्य में यह विशेष रूप से अनुपयुक्त है?
A
Writing code that anticipates errors; inappropriate in cryptographic implementations where branches create timing side-channels त्रुटियों का पूर्वानुमान करने वाला कोड लिखना; क्रिप्टोग्राफ़िक कार्यान्वयन में अनुपयुक्त जहां शाखाएं टाइमिंग साइड-चैनल बनाती हैं
B
It is unnecessary when using statically typed languages स्थिर रूप से टाइप की गई भाषाओं का उपयोग करते समय यह अनावश्यक है
C
Inappropriate in any performance-critical system due to overhead ओवरहेड के कारण किसी भी प्रदर्शन-महत्वपूर्ण प्रणाली में अनुपयुक्त
D
Should be avoided in test code to keep tests simple परीक्षणों को सरल बनाए रखने के लिए परीक्षण कोड से बचना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Defensive coding proactively validates inputs and handles error conditions. In cryptographic code, defensive branches can create timing variations measurable by attackers — timing side-channel attacks exploit different execution times depending on secret values. Constant-time algorithms deliberately avoid conditional branches.
व्याख्या (हिन्दी) रक्षात्मक कोडिंग सक्रिय रूप से इनपुट को मान्य करती है और त्रुटि स्थितियों को संभालती है। क्रिप्टोग्राफ़िक कोड में, रक्षात्मक शाखाएं हमलावरों द्वारा मापने योग्य समय भिन्नताएं बना सकती हैं - टाइमिंग साइड-चैनल हमले गुप्त मूल्यों के आधार पर विभिन्न निष्पादन समय का फायदा उठाते हैं। लगातार-समय एल्गोरिदम जानबूझकर सशर्त शाखाओं से बचते हैं।
428
EN + हिं Medium
GB What is the key difference between a 'code smell' and a 'bug' and why do code smells matter?
IN 'कोड गंध' और 'बग' के बीच मुख्य अंतर क्या है और कोड गंध क्यों मायने रखती है?
A
Code smells are compiler warnings; bugs are runtime errors कोड गंध संकलक चेतावनियाँ हैं; बग रनटाइम त्रुटियाँ हैं
B
A bug is a functional defect causing incorrect behaviour; a code smell is a structural indicator of potential design problems that may not currently fail but increase likelihood of future bugs and raise maintenance costs बग एक कार्यात्मक दोष है जो गलत व्यवहार का कारण बनता है; कोड गंध संभावित डिज़ाइन समस्याओं का एक संरचनात्मक संकेतक है जो वर्तमान में विफल नहीं हो सकती है लेकिन भविष्य में बग की संभावना बढ़ जाती है और रखरखाव लागत बढ़ जाती है
C
Code smells only relevant in Python and JavaScript due to dynamic typing गतिशील टाइपिंग के कारण कोड केवल पायथन और जावास्क्रिप्ट में ही प्रासंगिक लगता है
D
Code smells and bugs are synonymous in code review कोड समीक्षा में कोड गंध और बग पर्यायवाची हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Fowler's code smells (long methods, large classes, duplicate code) are structural warning signs suggesting refactoring is needed. They don't cause immediate failures but signal design decay making future modification error-prone.
व्याख्या (हिन्दी) फाउलर के कोड की गंध (लंबी विधियां, बड़ी कक्षाएं, डुप्लिकेट कोड) संरचनात्मक चेतावनी संकेत हैं जो सुझाव देते हैं कि रीफैक्टरिंग की आवश्यकता है। वे तत्काल विफलताओं का कारण नहीं बनते हैं लेकिन सिग्नल डिज़ाइन ख़राब हो जाते हैं जिससे भविष्य में संशोधन में त्रुटि-प्रवण हो जाता है।
429
EN + हिं Easy
GB What is the correct interpretation of 'responsibility' in the Single Responsibility Principle (SRP)?
IN एकल उत्तरदायित्व सिद्धांत (एसआरपी) में 'जिम्मेदारी' की सही व्याख्या क्या है?
A
A class should have only one method एक कक्षा में केवल एक ही विधि होनी चाहिए
B
A class should have only one reason to change — where 'reason to change' corresponds to a stakeholder group or business concern, not merely a functional category एक वर्ग के पास परिवर्तन का केवल एक ही कारण होना चाहिए - जहां 'परिवर्तन का कारण' एक हितधारक समूह या व्यावसायिक चिंता से मेल खाता है, न कि केवल एक कार्यात्मक श्रेणी से।
C
Each developer is responsible for maintaining exactly one class प्रत्येक डेवलपर ठीक एक वर्ग को बनाए रखने के लिए जिम्मेदार है
D
Only applicable to functional programming, not OOP केवल कार्यात्मक प्रोग्रामिंग पर लागू, OOP पर नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Robert Martin clarified that 'responsibility' means 'a reason to change' corresponding to a specific stakeholder or user group. A class generating a report AND emailing it has two reasons to change — finance team wanting different content, and IT changing email infrastructure. These are separate responsibilities.
व्याख्या (हिन्दी) रॉबर्ट मार्टिन ने स्पष्ट किया कि 'जिम्मेदारी' का अर्थ किसी विशिष्ट हितधारक या उपयोगकर्ता समूह के अनुरूप 'परिवर्तन का एक कारण' है। एक वर्ग जो रिपोर्ट तैयार करता है और उसे ईमेल करता है, उसमें बदलाव के दो कारण होते हैं - वित्त टीम अलग सामग्री चाहती है, और आईटी ईमेल बुनियादी ढांचे को बदल रही है। ये अलग जिम्मेदारियां हैं.
430
EN + हिं Medium
GB What specific problem does the 'assert' statement solve and why should it NOT be used for input validation?
IN 'जोर' कथन किस विशिष्ट समस्या का समाधान करता है और इसका उपयोग इनपुट सत्यापन के लिए क्यों नहीं किया जाना चाहिए?
A
Used to improve performance by eliminating runtime type checks रनटाइम प्रकार की जांच को समाप्त करके प्रदर्शन में सुधार करने के लिए उपयोग किया जाता है
B
Asserts document and enforce invariants about program's internal state; should not validate external inputs because assertions are typically disabled in production builds allowing invalid inputs to pass unchecked प्रोग्राम की आंतरिक स्थिति के बारे में दस्तावेज़ पर जोर देता है और अपरिवर्तनीयताओं को लागू करता है; बाहरी इनपुट को मान्य नहीं करना चाहिए क्योंकि उत्पादन बिल्ड में दावे आम तौर पर अक्षम होते हैं जिससे अमान्य इनपुट अनियंत्रित हो जाते हैं
C
Assert statements equivalent to unit tests and can replace them यूनिट परीक्षणों के समतुल्य कथनों पर जोर दें और उन्हें प्रतिस्थापित कर सकते हैं
D
Asserts should only be used in languages without exception handling दावे का उपयोग केवल अपवाद प्रबंधन के बिना भाषाओं में किया जाना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Assertions check internal assumptions that should never be false if code is correct. For user-supplied data, use explicit validation with informative exceptions because: assertions may be compiled out, they produce poor user-facing messages, and they conflate internal logic errors with external input errors.
व्याख्या (हिन्दी) दावे आंतरिक धारणाओं की जाँच करते हैं जो कोड सही होने पर कभी भी गलत नहीं होने चाहिए। उपयोगकर्ता द्वारा प्रदत्त डेटा के लिए, सूचनात्मक अपवादों के साथ स्पष्ट सत्यापन का उपयोग करें क्योंकि: दावे संकलित किए जा सकते हैं, वे खराब उपयोगकर्ता-सामना वाले संदेश उत्पन्न करते हैं, और वे बाहरी इनपुट त्रुटियों के साथ आंतरिक तर्क त्रुटियों को मिलाते हैं।
431
EN + हिं Medium
GB What is 'cyclomatic complexity', how is it calculated, and what threshold typically indicates need for refactoring?
IN 'साइक्लोमैटिक जटिलता' क्या है, इसकी गणना कैसे की जाती है, और कौन सी सीमा आम तौर पर रिफैक्टरिंग की आवश्यकता को इंगित करती है?
A
Ratio of comments to code lines; above 0.5 needs refactoring कोड पंक्तियों पर टिप्पणियों का अनुपात; 0.5 से ऊपर रिफैक्टरिंग की आवश्यकता है
B
McCabe's metric counting linearly independent paths: M = E - N + 2P; complexity above 10 indicates code difficult to test and maintain — should be refactored into smaller units मैककेब की मीट्रिक गणना रैखिक रूप से स्वतंत्र पथ: एम = ई - एन + 2पी; 10 से ऊपर की जटिलता इंगित करती है कि कोड का परीक्षण और रखरखाव करना मुश्किल है - इसे छोटी इकाइयों में दोबारा तैयार किया जाना चाहिए
C
Measures total number of variables declared in a function किसी फ़ंक्शन में घोषित वेरिएबल्स की कुल संख्या को मापता है
D
Above 100 requires refactoring; below 100 always acceptable 100 से ऊपर रिफैक्टरिंग की आवश्यकता होती है; 100 से नीचे सदैव स्वीकार्य
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) McCabe's cyclomatic complexity: M = E (edges) - N (nodes) + 2P (components). Practically equals 1 plus number of decision points. McCabe recommended M ≤ 10; above 10, code becomes too complex to reliably test all paths. Studies show strong correlation with defect density.
व्याख्या (हिन्दी) मैककेबे की चक्रीय जटिलता: एम = ई (किनारे) - एन (नोड्स) + 2पी (घटक)। व्यावहारिक रूप से निर्णय बिंदुओं की संख्या 1 से अधिक के बराबर होती है। मैककेबे ने एम ≤ 10 की सिफारिश की; 10 से ऊपर, सभी पथों का विश्वसनीय परीक्षण करने के लिए कोड बहुत जटिल हो जाता है। अध्ययन दोष घनत्व के साथ मजबूत संबंध दिखाते हैं।
432
EN + हिं Medium
GB What is the key difference between structural (white-box) and behavioural (black-box) testing?
IN संरचनात्मक (व्हाइट-बॉक्स) और व्यवहारिक (ब्लैक-बॉक्स) परीक्षण के बीच मुख्य अंतर क्या है?
A
Both provide complete coverage when used independently स्वतंत्र रूप से उपयोग किए जाने पर दोनों पूर्ण कवरेज प्रदान करते हैं
B
White-box tests based on code structure cannot detect missing functionality; black-box tests cannot ensure structural paths are exercised; both alone are insufficient कोड संरचना पर आधारित व्हाइट-बॉक्स परीक्षण गुम कार्यक्षमता का पता नहीं लगा सकते हैं; ब्लैक-बॉक्स परीक्षण यह सुनिश्चित नहीं कर सकते कि संरचनात्मक पथों का प्रयोग किया गया है; अकेले दोनों अपर्याप्त हैं
C
White-box testing is superior for all categories of defects व्हाइट-बॉक्स परीक्षण सभी श्रेणियों के दोषों के लिए बेहतर है
D
Black-box testing requires access to source code ब्लैक-बॉक्स परीक्षण के लिए स्रोत कोड तक पहुंच की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) White-box testing achieves code coverage but cannot detect requirements never implemented — you can have 100% branch coverage and still miss critical user functions. Black-box drives from specifications but may never exercise rare code paths. Effective testing combines both.
व्याख्या (हिन्दी) व्हाइट-बॉक्स परीक्षण कोड कवरेज प्राप्त करता है लेकिन कभी लागू नहीं की गई आवश्यकताओं का पता नहीं लगा सकता है - आपके पास 100% शाखा कवरेज हो सकता है और फिर भी महत्वपूर्ण उपयोगकर्ता फ़ंक्शन छूट सकते हैं। ब्लैक-बॉक्स विशिष्टताओं से संचालित होता है लेकिन कभी भी दुर्लभ कोड पथों का प्रयोग नहीं कर सकता है। प्रभावी परीक्षण दोनों को जोड़ता है।
433
EN + हिं Hard
GB What does 'mutation testing' evaluate that conventional coverage metrics cannot?
IN 'म्यूटेशन परीक्षण' क्या मूल्यांकन करता है जो पारंपरिक कवरेज मेट्रिक्स नहीं कर सकता?
A
Performance impact of code changes under production load उत्पादन भार के तहत कोड परिवर्तन का प्रदर्शन प्रभाव
B
Quality and sensitivity of the test suite by introducing deliberate faults (mutations) and measuring whether tests detect them — a suite with high coverage but weak assertions will fail to kill many mutants जानबूझकर दोष (उत्परिवर्तन) पेश करके परीक्षण सूट की गुणवत्ता और संवेदनशीलता और यह मापना कि क्या परीक्षण उनका पता लगाते हैं - उच्च कवरेज वाला एक सूट लेकिन कमजोर दावे कई म्यूटेंट को मारने में विफल होंगे
C
How well the system handles concurrent user sessions सिस्टम समवर्ती उपयोगकर्ता सत्रों को कितनी अच्छी तरह संभालता है
D
Replaces integration testing by simulating broken API endpoints टूटे हुए एपीआई एंडपॉइंट का अनुकरण करके एकीकरण परीक्षण को प्रतिस्थापित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Code coverage measures whether code was executed, not whether tests would detect if that code were wrong. Mutation testing introduces small syntactic faults and checks if the test suite fails. The mutation score reveals whether tests are truly sensitive to defects.
व्याख्या (हिन्दी) कोड कवरेज यह मापता है कि कोड निष्पादित किया गया था या नहीं, न कि परीक्षण यह पता लगाएगा कि क्या वह कोड गलत था। उत्परिवर्तन परीक्षण छोटे वाक्यात्मक दोषों का परिचय देता है और जाँच करता है कि क्या परीक्षण सूट विफल हो जाता है। उत्परिवर्तन स्कोर से पता चलता है कि परीक्षण वास्तव में दोषों के प्रति संवेदनशील हैं या नहीं।
434
EN + हिं Medium
GB What specific condition causes 'pesticide paradox' in a test suite and how is it remedied?
IN कौन सी विशिष्ट स्थिति परीक्षण सूट में 'कीटनाशक विरोधाभास' का कारण बनती है और इसका निवारण कैसे किया जाता है?
A
Running too many tests simultaneously on a multi-core machine मल्टी-कोर मशीन पर एक साथ बहुत सारे परीक्षण चलाना
B
The same set of tests run repeatedly stops finding new defects because surviving code has been adapted to pass those specific tests — remedied by regularly reviewing and augmenting the test suite बार-बार चलाए जाने वाले परीक्षणों का एक ही सेट नए दोष ढूंढना बंद कर देता है क्योंकि जीवित कोड को उन विशिष्ट परीक्षणों को पास करने के लिए अनुकूलित किया गया है - नियमित रूप से परीक्षण सूट की समीक्षा और संवर्द्धन करके इसका समाधान किया जाता है।
C
Only occurs in systems using TDD केवल टीडीडी का उपयोग करने वाले सिस्टम में होता है
D
Refers to chemical pesticides near server room AC units सर्वर रूम एसी इकाइयों के पास रासायनिक कीटनाशकों को संदर्भित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Myers' 7 Testing Principles includes pesticide paradox: tests become ineffective as bugs they targeted are fixed and remaining bugs require different approaches. Test suites must evolve — adding new tests, varying data, and using exploratory/fuzz testing.
व्याख्या (हिन्दी) मायर्स के 7 परीक्षण सिद्धांतों में कीटनाशक विरोधाभास शामिल है: परीक्षण अप्रभावी हो जाते हैं क्योंकि उनके द्वारा लक्षित बग ठीक हो जाते हैं और शेष बग के लिए अलग-अलग दृष्टिकोण की आवश्यकता होती है। परीक्षण सुइट्स विकसित होने चाहिए - नए परीक्षण जोड़ना, डेटा बदलना और खोजपूर्ण/फ़ज़ परीक्षण का उपयोग करना।
435
EN + हिं Easy
GB What does 'boundary value analysis' test that equivalence partitioning may miss?
IN 'सीमा मूल्य विश्लेषण' क्या परीक्षण करता है कि तुल्यता विभाजन छूट सकता है?
A
System response time at peak load conditions चरम लोड स्थितियों में सिस्टम प्रतिक्रिया समय
B
Values at the edges of equivalence partitions (exact boundary, one below, one above) because defects cluster at boundaries due to common off-by-one errors समतुल्य विभाजन के किनारों पर मान (सटीक सीमा, एक नीचे, एक ऊपर) क्योंकि सामान्य ऑफ-बाय-वन त्रुटियों के कारण दोष सीमाओं पर एकत्रित होते हैं
C
Boundaries between different software modules during integration एकीकरण के दौरान विभिन्न सॉफ्टवेयर मॉड्यूल के बीच की सीमाएँ
D
Only applicable when number of inputs is exactly two केवल तभी लागू होता है जब इनपुट की संख्या बिल्कुल दो हो
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Empirical evidence shows programmers frequently make mistakes at condition boundaries: 'if (x < 10)' vs 'if (x <= 10)' is a classic off-by-one. BVA supplements equivalence partitioning with boundary values — for range 1-100: test 0, 1, 2, 99, 100, 101.
व्याख्या (हिन्दी) अनुभवजन्य साक्ष्य से पता चलता है कि प्रोग्रामर अक्सर स्थिति सीमाओं पर गलतियाँ करते हैं: 'if (x <10)' बनाम 'if (x
421–435 of 647