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
2446
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 से ऊपर, सभी पथों का विश्वसनीय परीक्षण करने के लिए कोड बहुत जटिल हो जाता है। अध्ययन दोष घनत्व के साथ मजबूत संबंध दिखाते हैं।
2447
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 परिभाषित करता है: त्रुटि (मानव क्रिया गलती का परिचय देती है), दोष (कोड में मौजूद दोष), विफलता (गलती प्रकट होने पर देखने योग्य गलत व्यवहार)। सभी दोष विफलताओं का कारण नहीं बनते - मृत कोड में कोई दोष कभी निष्पादित नहीं होता।
2448
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% शाखा कवरेज हो सकता है और फिर भी महत्वपूर्ण उपयोगकर्ता फ़ंक्शन छूट सकते हैं। ब्लैक-बॉक्स विशिष्टताओं से संचालित होता है लेकिन कभी भी दुर्लभ कोड पथों का प्रयोग नहीं कर सकता है। प्रभावी परीक्षण दोनों को जोड़ता है।
2449
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.
व्याख्या (हिन्दी) कोड कवरेज यह मापता है कि कोड निष्पादित किया गया था या नहीं, न कि परीक्षण यह पता लगाएगा कि क्या वह कोड गलत था। उत्परिवर्तन परीक्षण छोटे वाक्यात्मक दोषों का परिचय देता है और जाँच करता है कि क्या परीक्षण सूट विफल हो जाता है। उत्परिवर्तन स्कोर से पता चलता है कि परीक्षण वास्तव में दोषों के प्रति संवेदनशील हैं या नहीं।
2450
EN + हिं Easy
GB What is a 'test oracle' and what is the 'oracle problem' in software testing?
IN 'टेस्ट ओरेकल' क्या है और सॉफ्टवेयर परीक्षण में 'ओरेकल समस्या' क्या है?
A
A senior tester who manually approves all automated test results एक वरिष्ठ परीक्षक जो सभी स्वचालित परीक्षण परिणामों को मैन्युअल रूप से अनुमोदित करता है
B
A test oracle is the mechanism determining expected output to compare against actual results; the oracle problem is that for many complex systems no reliable oracle exists to determine correct output एक परीक्षण दैवज्ञ वास्तविक परिणामों की तुलना करने के लिए अपेक्षित आउटपुट निर्धारित करने वाला तंत्र है; ओरेकल की समस्या यह है कि कई जटिल प्रणालियों के लिए सही आउटपुट निर्धारित करने के लिए कोई विश्वसनीय ओरेकल मौजूद नहीं है
C
Legal liability of testing incorrect software in production उत्पादन में ग़लत सॉफ़्टवेयर के परीक्षण का कानूनी दायित्व
D
An automated tool that generates test cases from source code एक स्वचालित उपकरण जो स्रोत कोड से परीक्षण मामले उत्पन्न करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Weyuker (1982) identified the oracle problem: to verify a test result, you need an oracle. For ML models, concurrent systems, or simulations where ground truth is unavailable or expensive to compute, constructing reliable oracles is itself a research challenge.
व्याख्या (हिन्दी) वेयुकर (1982) ने ओरेकल समस्या की पहचान की: एक परीक्षण परिणाम को सत्यापित करने के लिए, आपको एक ओरेकल की आवश्यकता होती है। एमएल मॉडल, समवर्ती सिस्टम, या सिमुलेशन के लिए जहां जमीनी सच्चाई अनुपलब्ध है या गणना करना महंगा है, विश्वसनीय दैवज्ञ का निर्माण करना अपने आप में एक शोध चुनौती है।
2451
EN + हिं Medium
GB What is 'equivalence partitioning' and how does it reduce test case count without sacrificing coverage quality?
IN 'समतुल्यता विभाजन' क्या है और यह कवरेज गुणवत्ता से समझौता किए बिना टेस्ट केस की संख्या को कैसे कम करता है?
A
Divides development team into groups each responsible for testing one module विकास टीम को समूहों में विभाजित करता है, प्रत्येक एक मॉड्यूल के परीक्षण के लिए जिम्मेदार होता है
B
Divides input data into classes where members are expected to cause identical behaviour — testing one value per class is assumed equivalent to testing all values, reducing redundant tests इनपुट डेटा को उन वर्गों में विभाजित करता है जहां सदस्यों से समान व्यवहार की अपेक्षा की जाती है - प्रति वर्ग एक मान का परीक्षण सभी मूल्यों के परीक्षण के बराबर माना जाता है, अनावश्यक परीक्षणों को कम करता है
C
Only applies to string inputs; cannot be used with numeric data केवल स्ट्रिंग इनपुट पर लागू होता है; संख्यात्मक डेटा के साथ उपयोग नहीं किया जा सकता
D
A test management technique allocating test cases to team members एक परीक्षण प्रबंधन तकनीक जो टीम के सदस्यों को परीक्षण मामले आवंटित करती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) If a function accepts integers 1-100, equivalence partitioning identifies valid inputs (1-100) as one partition, invalid negatives as another, and values > 100 as another. Testing one representative from each partition reduces test cases while maintaining reasonable defect detection confidence.
व्याख्या (हिन्दी) यदि कोई फ़ंक्शन पूर्णांक 1-100 स्वीकार करता है, तो समतुल्य विभाजन वैध इनपुट (1-100) को एक विभाजन के रूप में, अमान्य नकारात्मक को दूसरे के रूप में, और मान > 100 को दूसरे के रूप में पहचानता है। प्रत्येक विभाजन से एक प्रतिनिधि का परीक्षण उचित दोष पहचान आत्मविश्वास बनाए रखते हुए परीक्षण मामलों को कम करता है।
2452
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 परीक्षण सिद्धांतों में कीटनाशक विरोधाभास शामिल है: परीक्षण अप्रभावी हो जाते हैं क्योंकि उनके द्वारा लक्षित बग ठीक हो जाते हैं और शेष बग के लिए अलग-अलग दृष्टिकोण की आवश्यकता होती है। परीक्षण सुइट्स विकसित होने चाहिए - नए परीक्षण जोड़ना, डेटा बदलना और खोजपूर्ण/फ़ज़ परीक्षण का उपयोग करना।
2453
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
2454
EN + हिं Easy
GB What is 'regression testing' and what risk does inadequate regression testing introduce into CI/CD pipelines?
IN 'प्रतिगमन परीक्षण' क्या है और अपर्याप्त प्रतिगमन परीक्षण सीआई/सीडी पाइपलाइनों में क्या जोखिम लाता है?
A
Checks system performance under decreasing load conditions घटती लोड स्थितियों के तहत सिस्टम के प्रदर्शन की जाँच करता है
B
Re-executes tests after changes to ensure previously working functionality has not been broken; inadequate regression testing allows regressions to reach production where detection and repair cost is highest यह सुनिश्चित करने के लिए कि पहले से काम कर रही कार्यक्षमता टूटी नहीं है, परिवर्तनों के बाद परीक्षण दोबारा निष्पादित करता है; अपर्याप्त प्रतिगमन परीक्षण प्रतिगमन को उत्पादन तक पहुंचने की अनुमति देता है जहां पता लगाने और मरम्मत की लागत सबसे अधिक होती है
C
Only required when programming language version is upgraded केवल प्रोग्रामिंग भाषा संस्करण अपग्रेड होने पर ही आवश्यक है
D
In CI/CD, automatically replaced by monitoring and alerting systems सीआई/सीडी में, स्वचालित रूप से निगरानी और चेतावनी प्रणालियों द्वारा प्रतिस्थापित किया जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Regression testing is critical in CD pipelines: every commit potentially affects unrelated functionality through shared dependencies. Without comprehensive automated regression suites, teams either slow delivery or accept the risk of silent regressions surfacing only after deployment.
व्याख्या (हिन्दी) सीडी पाइपलाइनों में प्रतिगमन परीक्षण महत्वपूर्ण है: प्रत्येक प्रतिबद्धता संभावित रूप से साझा निर्भरता के माध्यम से असंबंधित कार्यक्षमता को प्रभावित करती है। व्यापक स्वचालित रिग्रेशन सुइट्स के बिना, टीमें या तो डिलीवरी धीमी कर देती हैं या केवल तैनाती के बाद सामने आने वाले साइलेंट रिग्रेशन के जोखिम को स्वीकार करती हैं।
2455
EN + हिं Easy
GB What is the core principle behind TDD and what design benefit does it provide beyond defect reduction?
IN टीडीडी के पीछे मूल सिद्धांत क्या है और यह दोष कम करने के अलावा क्या डिज़ाइन लाभ प्रदान करता है?
A
Tests written by QA after development to verify functionality कार्यक्षमता को सत्यापित करने के लिए विकास के बाद क्यूए द्वारा लिखे गए परीक्षण
B
TDD's Red-Green-Refactor cycle writes tests before code; beyond defect reduction it forces testable design (high cohesion, low coupling, DI) because untestable code cannot pass tests written before implementation टीडीडी का रेड-ग्रीन-रिफैक्टर चक्र कोड से पहले परीक्षण लिखता है; दोष कम करने से परे यह परीक्षण योग्य डिज़ाइन (उच्च सामंजस्य, कम युग्मन, डीआई) को मजबूर करता है क्योंकि अप्राप्य कोड कार्यान्वयन से पहले लिखे गए परीक्षणों को पास नहीं कर सकता है
C
Only beneficial for unit tests; no value for integration or system testing केवल इकाई परीक्षणों के लिए फायदेमंद; एकीकरण या सिस्टम परीक्षण के लिए कोई मूल्य नहीं
D
Guarantees zero defects if all tests pass before deployment यदि तैनाती से पहले सभी परीक्षण पास हो जाते हैं तो शून्य दोष की गारंटी देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) TDD's primary design benefit is forcing testability. If you cannot write a test for functionality before implementing it, the design is likely wrong. TDD acts as real-time design feedback, naturally producing decoupled injectable single-responsibility code.
व्याख्या (हिन्दी) टीडीडी का प्राथमिक डिज़ाइन लाभ परीक्षण योग्यता को बाध्य करना है। यदि आप इसे लागू करने से पहले कार्यक्षमता के लिए परीक्षण नहीं लिख सकते हैं, तो संभवतः डिज़ाइन गलत है। टीडीडी वास्तविक समय डिज़ाइन फीडबैक के रूप में कार्य करता है, जो स्वाभाविक रूप से डिकॉउल्ड इंजेक्टेबल सिंगल-जिम्मेदारी कोड का उत्पादन करता है।
2456
EN + हिं Medium
GB What distinguishes 'alpha testing' from 'beta testing' and in what order do they occur?
IN 'अल्फा परीक्षण' को 'बीटा परीक्षण' से क्या अलग करता है और वे किस क्रम में होते हैं?
A
Beta testing occurs first with internal users; alpha testing follows with external users बीटा परीक्षण सबसे पहले आंतरिक उपयोगकर्ताओं के साथ होता है; अल्फा परीक्षण बाहरी उपयोगकर्ताओं के साथ होता है
B
Alpha testing is conducted at the developer's site by internal users in a controlled environment before beta; beta testing is then by selected external users in their real-world environments अल्फा परीक्षण बीटा से पहले नियंत्रित वातावरण में आंतरिक उपयोगकर्ताओं द्वारा डेवलपर की साइट पर आयोजित किया जाता है; बीटा परीक्षण तब चयनित बाहरी उपयोगकर्ताओं द्वारा उनके वास्तविक दुनिया के वातावरण में किया जाता है
C
Alpha and beta testing are conducted simultaneously अल्फा और बीटा परीक्षण एक साथ आयोजित किए जाते हैं
D
Alpha is automated; beta is always manual अल्फ़ा स्वचालित है; बीटा हमेशा मैन्युअल होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Alpha testing precedes beta: done in-house under controlled conditions where testers can observe user behaviour and collect detailed logs. Beta testing exposes the product to real users in real environments — uncovering hardware/OS configuration issues and real-world edge cases.
व्याख्या (हिन्दी) अल्फा परीक्षण बीटा से पहले होता है: नियंत्रित परिस्थितियों में घर में किया जाता है जहां परीक्षक उपयोगकर्ता के व्यवहार का निरीक्षण कर सकते हैं और विस्तृत लॉग एकत्र कर सकते हैं। बीटा परीक्षण उत्पाद को वास्तविक वातावरण में वास्तविक उपयोगकर्ताओं के सामने उजागर करता है - हार्डवेयर/ओएस कॉन्फ़िगरेशन समस्याओं और वास्तविक दुनिया के किनारे के मामलों को उजागर करता है।
2457
EN + हिं Medium
GB What distinguishes 'debugging' from 'testing' as activities in the software development lifecycle?
IN सॉफ़्टवेयर विकास जीवनचक्र में गतिविधियों के रूप में 'डीबगिंग' को 'परीक्षण' से क्या अलग करता है?
A
Debugging is automated; testing is always manual डिबगिंग स्वचालित है; परीक्षण हमेशा मैन्युअल होता है
B
Testing finds that a defect exists; debugging locates and understands the defect so it can be fixed — debugging begins where testing ends परीक्षण से पता चलता है कि कोई दोष मौजूद है; डिबगिंग दोष का पता लगाता है और उसे समझता है ताकि इसे ठीक किया जा सके - डिबगिंग वहीं से शुरू होती है जहां परीक्षण समाप्त होता है
C
Debugging by QA teams; testing by developers क्यूए टीमों द्वारा डिबगिंग; डेवलपर्स द्वारा परीक्षण
D
Testing and debugging are synonymous and always occur simultaneously परीक्षण और डिबगिंग पर्यायवाची हैं और हमेशा एक साथ होते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Testing is evaluative: it reveals the presence of failures. Debugging is diagnostic and corrective: given a known failure, locate the fault, understand why it causes the failure, and remove it. Testing can be systematic; debugging is often a creative hypothesis-driven investigation.
व्याख्या (हिन्दी) परीक्षण मूल्यांकनात्मक है: यह विफलताओं की उपस्थिति को प्रकट करता है। डिबगिंग नैदानिक ​​और सुधारात्मक है: किसी ज्ञात विफलता को देखते हुए, गलती का पता लगाएं, समझें कि यह विफलता का कारण क्यों है, और इसे हटा दें। परीक्षण व्यवस्थित हो सकता है; डिबगिंग अक्सर एक रचनात्मक परिकल्पना-संचालित जांच होती है।
2458
EN + हिं Easy
GB What is the 'Heisenbug' phenomenon in software debugging and what commonly causes it?
IN सॉफ़्टवेयर डिबगिंग में 'हेइज़नबग' घटना क्या है और आमतौर पर इसका कारण क्या है?
A
A bug only occurring in production, never in development or staging बग केवल उत्पादन में होता है, विकास या स्टेजिंग में कभी नहीं
B
A defect that disappears or changes behaviour when you attempt to observe or debug it — commonly caused by timing-dependent race conditions that the debugger's pausing alters एक दोष जो गायब हो जाता है या जब आप इसे देखने या डिबग करने का प्रयास करते हैं तो व्यवहार बदल जाता है - आमतौर पर समय-निर्भर दौड़ स्थितियों के कारण होता है जो डिबगर के रुकने से बदल जाता है
C
A security vulnerability impossible to patch without replacing hardware हार्डवेयर को बदले बिना एक सुरक्षा भेद्यता को ठीक करना असंभव है
D
A bug introduced by the debugger tool itself डिबगर टूल द्वारा ही पेश किया गया एक बग
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Named after Heisenberg's uncertainty principle, Heisenbugs arise in concurrent code where race conditions depend on precise execution timing. Attaching a debugger introduces delays that change thread interleaving, eliminating the exact conditions causing the bug.
व्याख्या (हिन्दी) हाइजेनबर्ग के अनिश्चितता सिद्धांत के नाम पर, हाइजेनबग्स समवर्ती कोड में उत्पन्न होते हैं जहां दौड़ की स्थिति सटीक निष्पादन समय पर निर्भर करती है। डिबगर संलग्न करने से देरी होती है जो थ्रेड इंटरलीविंग को बदल देती है, जिससे बग पैदा करने वाली सटीक स्थितियाँ समाप्त हो जाती हैं।
2459
EN + हिं Easy
GB What is 'rubber duck debugging' and what cognitive principle does it exploit?
IN 'रबर डक डिबगिंग' क्या है और यह किस संज्ञानात्मक सिद्धांत का उपयोग करता है?
A
A waterfall-era technique for testing on limited memory hardware सीमित मेमोरी हार्डवेयर पर परीक्षण के लिए एक वॉटरफॉल-युग तकनीक
B
Explaining code step-by-step to an inanimate object; the act of articulating the problem forces explicit processing revealing the solution — exploiting the principle that verbalisation activates different reasoning pathways किसी निर्जीव वस्तु को चरण-दर-चरण कोड समझाना; समस्या को स्पष्ट करने का कार्य स्पष्ट प्रसंस्करण को समाधान प्रकट करने के लिए मजबूर करता है - इस सिद्धांत का शोषण करते हुए कि मौखिककरण विभिन्न तर्क मार्गों को सक्रिय करता है
C
A formal IEEE-standard debugging technique requiring peer review documentation एक औपचारिक आईईईई-मानक डिबगिंग तकनीक जिसके लिए सहकर्मी समीक्षा दस्तावेज़ की आवश्यकता होती है
D
Testing using voice-controlled hardware like Amazon Echo अमेज़ॅन इको जैसे ध्वनि-नियंत्रित हार्डवेयर का उपयोग करके परीक्षण
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Rubber duck debugging works because explaining code to a non-expert forces you to articulate assumptions and skip no steps. This shifts from pattern-recognition mode to sequential explanation mode, often revealing incorrect assumptions through metacognition.
व्याख्या (हिन्दी) रबर डक डिबगिंग काम करती है क्योंकि किसी गैर-विशेषज्ञ को कोड समझाना आपको धारणाओं को स्पष्ट करने के लिए मजबूर करता है और कोई भी कदम नहीं छोड़ता है। यह पैटर्न-पहचान मोड से अनुक्रमिक स्पष्टीकरण मोड में स्थानांतरित हो जाता है, अक्सर मेटाकॉग्निशन के माध्यम से गलत धारणाओं को प्रकट करता है।
2460
EN + हिं Easy
GB In multithreaded debugging, what is a 'deadlock' and what four Coffman conditions must simultaneously hold?
IN मल्टीथ्रेडेड डिबगिंग में, 'गतिरोध' क्या है और कौन सी चार कॉफ़मैन स्थितियाँ एक साथ होनी चाहिए?
A
Program runs out of memory; Coffman conditions are CPU, RAM, I/O, network saturation प्रोग्राम की स्मृति समाप्त हो जाती है; कॉफ़मैन स्थितियाँ सीपीयू, रैम, आई/ओ, नेटवर्क संतृप्ति हैं
B
Two or more threads permanently blocked waiting for each other; Coffman conditions: mutual exclusion, hold and wait, no preemption, and circular wait — all four must hold simultaneously दो या दो से अधिक थ्रेड एक-दूसरे की प्रतीक्षा में स्थायी रूप से अवरुद्ध हो गए हैं; कॉफ़मैन की शर्तें: पारस्परिक बहिष्कार, रोकें और प्रतीक्षा करें, कोई छूट नहीं, और परिपत्र प्रतीक्षा - इन चारों को एक साथ रखना होगा
C
Program enters infinite loop consuming all CPU time प्रोग्राम सभी सीपीयू समय का उपभोग करते हुए अनंत लूप में प्रवेश करता है
D
Exactly two threads deadlock; three or more cannot बिल्कुल दो धागे गतिरोध; तीन या अधिक नहीं कर सकते
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Coffman et al. showed deadlock requires all four conditions simultaneously: 1) Mutual exclusion, 2) Hold and wait, 3) No preemption, 4) Circular wait. Breaking any one prevents deadlock — resource ordering breaks circular wait; timeouts enable preemption.
व्याख्या (हिन्दी) कॉफ़मैन एट अल. दिखाया गया है कि गतिरोध के लिए सभी चार स्थितियों की एक साथ आवश्यकता होती है: 1) पारस्परिक बहिष्कार, 2) रुकें और प्रतीक्षा करें, 3) कोई छूट नहीं, 4) परिपत्र प्रतीक्षा। किसी एक को तोड़ने से गतिरोध रुकता है - संसाधन क्रम चक्रीय प्रतीक्षा को तोड़ता है; टाइमआउट प्रीएम्प्शन को सक्षम बनाता है।
2446–2460 of 2726