Software Engineering — MCQ Practice

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

📚 2726 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2726 questions
2191
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 की 'विरासत पर अनुकूल संरचना' निर्भरता इंजेक्शन के माध्यम से रनटाइम व्यवहार परिवर्तन को सक्षम करने, सहयोगी घटकों से वस्तुओं के निर्माण की सिफारिश करती है।
2192
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.
व्याख्या (हिन्दी) ऑब्जर्वर (जीओएफ) पब्लिश-सब्सक्राइब का उपयोग करके विषयों को पर्यवेक्षकों से अलग करता है। जोखिम: जब पर्यवेक्षकों को नहीं हटाया जाता है तो मेमोरी लीक हो जाती है; अद्यतन हिमस्खलन जहां एक अधिसूचना अनियंत्रित श्रृंखलाओं को ट्रिगर करती है; जब कोई पर्यवेक्षक अधिसूचना के दौरान विषय को संशोधित करता है तो अप्रत्याशित पुनः प्रवेश।
2193
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.
व्याख्या (हिन्दी) दिज्क्स्ट्रा की चिंताओं को अलग करने से एक चिंता को दूसरे में फैलने से रोककर जटिलता कम हो जाती है। एमवीसी इसे यूआई पर लागू करता है: मॉडल प्रस्तुति के बारे में कुछ नहीं जानता है; व्यू व्यावसायिक नियमों के बारे में कुछ नहीं जानता; नियंत्रक को भंडारण के बारे में कुछ नहीं पता है।
2194
EN + हिं Medium
GB What is the primary purpose of coding standards in a multi-developer project and what happens when inconsistently applied?
IN मल्टी-डेवलपर प्रोजेक्ट में कोडिंग मानकों का प्राथमिक उद्देश्य क्या है और असंगत रूप से लागू होने पर क्या होता है?
A
Reduce compilation time by optimising code structure कोड संरचना को अनुकूलित करके संकलन समय कम करें
B
Ensure code is readable and maintainable by any team member; inconsistent application creates cognitive overhead, introduces subtle bugs in misunderstood conventions, and makes code review ineffective सुनिश्चित करें कि कोड किसी भी टीम सदस्य द्वारा पढ़ने योग्य और रखरखाव योग्य है; असंगत अनुप्रयोग संज्ञानात्मक ओवरहेड बनाता है, गलत समझे गए सम्मेलनों में सूक्ष्म बग पेश करता है, और कोड समीक्षा को अप्रभावी बनाता है
C
Only needed for open-source projects where external contributors work on the code केवल ओपन-सोर्स परियोजनाओं के लिए आवश्यक है जहां बाहरी योगदानकर्ता कोड पर काम करते हैं
D
Automatically enforce themselves through modern IDEs आधुनिक आईडीई के माध्यम से स्वयं को स्वचालित रूप से लागू करें
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Coding standards create a shared vocabulary for the codebase. When inconsistently applied, developers must context-switch between styles. More dangerously, inconsistent conventions can obscure bugs that consistent formatting would make obvious.
व्याख्या (हिन्दी) कोडिंग मानक कोडबेस के लिए एक साझा शब्दावली बनाते हैं। असंगत रूप से लागू होने पर, डेवलपर्स को शैलियों के बीच संदर्भ-स्विच करना होगा। अधिक खतरनाक रूप से, असंगत परंपराएँ उन बगों को अस्पष्ट कर सकती हैं जिन्हें लगातार स्वरूपण स्पष्ट कर देगा।
2195
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 उल्लंघन है।
2196
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 को तीन स्थानों पर एन्कोड किया गया है और एक में परिवर्तन होता है, तो सिस्टम असंगत हो जाता है।
2197
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.
व्याख्या (हिन्दी) रॉबर्ट मार्टिन का बॉय स्काउट नियम इस वास्तविकता को संबोधित करता है कि समर्पित रिफैक्टरिंग स्प्रिंट को अक्सर प्राथमिकता नहीं दी जाती है। वृद्धिशील सुधार की दिनचर्या बनाकर - एक भ्रमित करने वाले चर का नाम बदलें, एक लंबी विधि निकालें - टीमें विशेष प्रयास आवंटन के बिना कोडबेस गिरावट को रोकती हैं।
2198
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.
व्याख्या (हिन्दी) रक्षात्मक कोडिंग सक्रिय रूप से इनपुट को मान्य करती है और त्रुटि स्थितियों को संभालती है। क्रिप्टोग्राफ़िक कोड में, रक्षात्मक शाखाएं हमलावरों द्वारा मापने योग्य समय भिन्नताएं बना सकती हैं - टाइमिंग साइड-चैनल हमले गुप्त मूल्यों के आधार पर विभिन्न निष्पादन समय का फायदा उठाते हैं। लगातार-समय एल्गोरिदम जानबूझकर सशर्त शाखाओं से बचते हैं।
2199
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.
व्याख्या (हिन्दी) फाउलर के कोड की गंध (लंबी विधियां, बड़ी कक्षाएं, डुप्लिकेट कोड) संरचनात्मक चेतावनी संकेत हैं जो सुझाव देते हैं कि रीफैक्टरिंग की आवश्यकता है। वे तत्काल विफलताओं का कारण नहीं बनते हैं लेकिन सिग्नल डिज़ाइन ख़राब हो जाते हैं जिससे भविष्य में संशोधन में त्रुटि-प्रवण हो जाता है।
2200
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.
व्याख्या (हिन्दी) रॉबर्ट मार्टिन ने स्पष्ट किया कि 'जिम्मेदारी' का अर्थ किसी विशिष्ट हितधारक या उपयोगकर्ता समूह के अनुरूप 'परिवर्तन का एक कारण' है। एक वर्ग जो रिपोर्ट तैयार करता है और उसे ईमेल करता है, उसमें बदलाव के दो कारण होते हैं - वित्त टीम अलग सामग्री चाहती है, और आईटी ईमेल बुनियादी ढांचे को बदल रही है। ये अलग जिम्मेदारियां हैं.
2201
EN + हिं Medium
GB Why is 'premature optimisation' considered a coding standard violation and when is optimisation legitimate?
IN 'समयपूर्व अनुकूलन' को कोडिंग मानक का उल्लंघन क्यों माना जाता है और अनुकूलन कब वैध है?
A
Premature optimisation is when code is optimised before compilation समयपूर्व अनुकूलन तब होता है जब कोड को संकलन से पहले अनुकूलित किया जाता है
B
Premature optimisation prioritises performance over correctness and maintainability without profiling data — Knuth's rule applies; optimisation is legitimate after profiling identifies actual hotspots समयपूर्व अनुकूलन प्रोफाइलिंग डेटा के बिना शुद्धता और रखरखाव पर प्रदर्शन को प्राथमिकता देता है - नथ का नियम लागू होता है; प्रोफाइलिंग से वास्तविक हॉटस्पॉट की पहचान होने के बाद अनुकूलन वैध है
C
All performance optimisation is premature सभी प्रदर्शन अनुकूलन समयपूर्व हैं
D
Premature optimisation only applies to sorting algorithms समयपूर्व अनुकूलन केवल सॉर्टिंग एल्गोरिदम पर लागू होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Knuth's full quote: 'Premature optimisation is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.' Profiling data identifies which 3% matters. Optimising guessed bottlenecks makes code complex and unmaintainable for no measurable gain.
व्याख्या (हिन्दी) नथ का पूरा उद्धरण: 'समयपूर्व अनुकूलन सभी बुराइयों की जड़ है। फिर भी हमें उस महत्वपूर्ण 3% में अपने अवसर नहीं गंवाने चाहिए।' प्रोफ़ाइलिंग डेटा पहचानता है कि कौन सा 3% मायने रखता है। अनुमानित बाधाओं को अनुकूलित करने से कोड जटिल हो जाता है और बिना किसी मापनीय लाभ के रखरखाव योग्य नहीं रह जाता है।
2202
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.
व्याख्या (हिन्दी) दावे आंतरिक धारणाओं की जाँच करते हैं जो कोड सही होने पर कभी भी गलत नहीं होने चाहिए। उपयोगकर्ता द्वारा प्रदत्त डेटा के लिए, सूचनात्मक अपवादों के साथ स्पष्ट सत्यापन का उपयोग करें क्योंकि: दावे संकलित किए जा सकते हैं, वे खराब उपयोगकर्ता-सामना वाले संदेश उत्पन्न करते हैं, और वे बाहरी इनपुट त्रुटियों के साथ आंतरिक तर्क त्रुटियों को मिलाते हैं।
2203
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 से अधिक के बराबर होती है। McCabe recommended M ≤ 10; 10 से ऊपर, सभी पथों का विश्वसनीय परीक्षण करने के लिए कोड बहुत जटिल हो जाता है। अध्ययन दोष घनत्व के साथ मजबूत संबंध दिखाते हैं।
2204
EN + हिं Easy
GB What is the fundamental distinction between 'error', 'fault', and 'failure' in software testing?
IN सॉफ़्टवेयर परीक्षण में 'त्रुटि', 'त्रुटि' और 'विफलता' के बीच मूलभूत अंतर क्या है?
A
Error, fault, and failure are synonymous terms in IEEE standards आईईईई मानकों में त्रुटि, गलती और विफलता पर्यायवाची शब्द हैं
B
An error is a human mistake producing a fault (defect) in code; a fault is the static defect; a failure occurs when the fault is executed and the system behaves incorrectly त्रुटि एक मानवीय गलती है जो कोड में दोष (दोष) उत्पन्न करती है; एक दोष स्थैतिक दोष है; विफलता तब होती है जब गलती निष्पादित हो जाती है और सिस्टम गलत तरीके से व्यवहार करता है
C
Error is a failing test; fault is a passing test when it should fail; failure is when no tests are written त्रुटि एक असफल परीक्षा है; गलती एक उत्तीर्ण परीक्षा है जब उसे असफल होना चाहिए; विफलता तब होती है जब कोई परीक्षण नहीं लिखा जाता है
D
Error in hardware; fault in software; failure in UI हार्डवेयर में त्रुटि; सॉफ्टवेयर में खराबी; यूआई में विफलता
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) IEEE 610 defines: Error (human action introducing a fault), Fault (defect present in code), Failure (observable incorrect behaviour when fault manifests). Not all faults cause failures — a fault in dead code never executes.
व्याख्या (हिन्दी) आईईईई 610 परिभाषित करता है: त्रुटि (मानव क्रिया गलती का परिचय देती है), दोष (कोड में मौजूद दोष), विफलता (गलती प्रकट होने पर देखने योग्य गलत व्यवहार)। सभी दोष विफलताओं का कारण नहीं बनते - मृत कोड में कोई दोष कभी निष्पादित नहीं होता।
2205
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 White-box tests based on code structure cannot detect missing functionality; black-box tests cannot ensure structural paths are exercised; अकेले दोनों अपर्याप्त हैं
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% शाखा कवरेज हो सकता है और फिर भी महत्वपूर्ण उपयोगकर्ता फ़ंक्शन छूट सकते हैं। ब्लैक-बॉक्स विशिष्टताओं से संचालित होता है लेकिन कभी भी दुर्लभ कोड पथों का प्रयोग नहीं कर सकता है। प्रभावी परीक्षण दोनों को जोड़ता है।
2191–2205 of 2726