शुरुआती टिप्पणियां
Yvette Nameth (Google)
कीनोट खुल रहे हैं
जुरगेन ऑलगेयर (Google)
क्रॉस-ऐप्लिकेशन/क्रॉस-डिवाइस टेस्टिंग का Uber चैलेंज
Apple Chow (Uber) और Bian Jiang (Uber)
मार्च 2015 में Uber में शामिल होने के कुछ समय बाद, हमें अपने मोबाइल ऐप्लिकेशन के लिए यूज़र इंटरफ़ेस (यूआई) टेस्टिंग टूल की जांच करते समय, Uber से जुड़ी एक यूनीक चुनौती का सामना करना पड़ा. शुरू से आखिर तक की जांच को पूरा करने के लिए, हमारे कई टेस्ट सही हैं. इनमें, राइडर ऐप्लिकेशन और ड्राइवर ऐप्लिकेशन की एक-दूसरे के साथ बातचीत करने/कोऑर्डिनेट करने की ज़रूरत है. इस बातचीत में, हम ऑक्टोपस नाम का अपना प्लैटफ़ॉर्म ऐग्नॉस्टिक समाधान दिखाएंगे. हम इस पर चर्चा करेंगे कि अलग-अलग डिवाइसों पर चल रहे अलग-अलग ऐप्लिकेशन पर, बातचीत करने का तरीका क्या है. यह समाधान ऐसे किसी भी टेस्ट के लिए अपनाया जा सकता है जिसके लिए अलग-अलग ऐप्लिकेशन या डिवाइस में तालमेल/कम्यूनिकेशन की ज़रूरत हो (उदाहरण के लिए, मल्टी-यूज़र गेम, मल्टी-यूज़र मैसेजिंग/कम्यूनिकेशन ऐप्लिकेशन वगैरह)
रोबोट असिस्टेड टेस्ट ऑटोमेशन
हैंस कुओस्मेनन (ऑप्टोफ़िडेलिटी) और नतालिया लीनोन (ऑप्टोफ़िडेलिटी)
ऑप्टोफ़िडेलिटी, फ़िनिश हाई-टेक कंपनी है. इसके पास आर ऐंड डी टेस्ट ऑटोमेशन के समाधान डेवलप करने और उन्हें उपलब्ध कराने का 10 साल का अनुभव है. इसमें, हमारे अनुभव और आने वाले समय में, सेवा में हुए ऐसे बदलावों के बारे में बताया जाएगा जो मोबाइल डिवाइस के यूज़र इंटरफ़ेस (यूआई) की परफ़ॉर्मेंस की जांच करने के दौरान इस्तेमाल किए जाते हैं. क्या आप जानते हैं कि Chrome OS की टीम, Android और ChromeOS डिवाइस के डेटा के इंतज़ार करने के समय का आकलन करने के लिए, OptoFidleity के रोबोट सॉल्यूशन का इस्तेमाल करती है?
मौज-मस्ती और लाभ के लिए करतबी को चुनौती देना: मोबाइल क्रॉस-प्लैटफ़ॉर्म इंटिग्रेशन टेस्टिंग से सीखे गए सबक
डैन जोवानेली (Google)
मोबाइल डेवलपमेंट कठिन होता है. टेस्ट इंफ़्रास्ट्रक्चर तैयार करना मुश्किल है. क्रॉस-प्लैटफ़ॉर्म पर काम करना मुश्किल है. तीनों को मिला दें और आपके पास आपदा से निपटने की रेसिपी है. बातचीत के दौरान, डैन जियोवेनैली ने क्रॉस-प्लैटफ़ॉर्म मोबाइल टेस्ट के इंफ़्रास्ट्रक्चर प्रोजेक्ट पर काम करने के अपने अनुभव के बारे में बताया. वे उन चीज़ों के बारे में चर्चा करेंगे जो सही हो चुकी हैं, कौनसी चीज़ें गलत हुई (और बहुत गलत) और अब वे क्या शुरू करना चाहती थीं. मोबाइल क्रिएटर्स के लिए मोबाइल टूल डिज़ाइन करने के बारे में अहम जानकारी पाएं. साथ ही, यह भी जानें कि द मैट्रिक्स क्या है और इसे अपने गेम में कैसे पीछे छोड़ा जा सकता है.
असली डिवाइस का इस्तेमाल करके मोबाइल गेम टेस्ट ऑटोमेशन
Juko Kaasila (बिटबार/टेस्टड्रोइड)
मोबाइल गेम, आज के ऐप्लिकेशन स्टोर में पैसे कमाने की सबसे बड़ी कैटगरी है. इसलिए, यह पक्का करना ज़रूरी है कि किसी भी उपयोगकर्ता के डिवाइस पर, हर गेम का हर वर्शन काम करता हो या नहीं. हालांकि, इसकी पुष्टि करना ज़रूरी है, लेकिन फिर भी बहुत कम उदाहरण हैं या मोबाइल गेम की अपने-आप होने वाली टेस्टिंग के फ़्रेमवर्क बहुत कम हैं. इसकी वजह से, गेम डेवलपर को मैन्युअल टेस्टिंग के लिए मजबूर करना पड़ रहा है. हालांकि, ऐसा करना इसलिए ज़रूरी नहीं है, क्योंकि गेमिंग कंपनियों को अपना ग्लोबल मार्केट कवर करना पड़ सकता है. इसकी एक मुख्य वजह यह है कि गेम, मोबाइल ऐप्लिकेशन के तौर पर खास तरह से होते हैं. दरअसल, वे स्क्रीन को सीधे ऐक्सेस करते हैं, ओएस की दी गई सभी यूज़र इंटरफ़ेस (यूआई) सेवाओं को नज़रअंदाज़ कर देते हैं. इसलिए, टेस्ट करने के लिए ज़्यादातर फ़्रेमवर्क अपने काम के नहीं होते हैं, क्योंकि परंपरागत ऑब्जेक्ट सार्वजनिक नहीं किए जाते.
अच्छी बात यह है कि कुछ क्रिएटिव और सार्वजनिक तौर पर उपलब्ध लाइब्रेरी का इस्तेमाल करके, गेम के लिए असल मोबाइल डिवाइस पर टेस्ट ऑटोमेशन को बढ़ाने के कई तरीके हैं. जैसे, स्टैंडर्ड मोबाइल टेस्ट ऑटोमेशन फ़्रेमवर्क. अपने प्रज़ेंटेशन में, टेस्टड्रोइड के जूको काशिला असली तरीकों के उदाहरणों और कुछ सैंपल कोड के साथ तीन अलग-अलग तरीकों पर चर्चा करेंगे.
सूप डंपलिंग के कॉम्पोनेंट की जांच करने का तरीका
टोनी चांग (Google)
जिन लोगों ने फ़्लैकी टेस्ट को स्थिर करने में बहुत ज़्यादा समय लगाया है वे इस बात से सहमत हैं कि हमें टेस्ट को डिकम करना होगा. हालांकि, कुछ मामलों में यह मुश्किल होता है और उन्हें पता नहीं होता कि दूसरे लोगों को टीम के सदस्यों के सामने चुनौती दी जा सकती है. उनका मानना है कि सभी स्थितियों की पुष्टि करने के लिए, हमें E2E टेस्ट की ज़रूरत है. प्रॉडक्ट के कॉम्पोनेंट देखने की आदत न होने पर, कभी-कभी मुझे इस आइडिया पर काम करना मुश्किल हो जाता है. इसलिए, मेरे पास सूप डंपलिंग का एक ऐब्सट्रैक्ट उदाहरण है, जिसमें प्रॉडक्ट को अलग-अलग करने और उन पर टेस्ट लागू करने के बारे में बताया गया है.
हम आपको E2E टेस्ट को कॉम्पोनेंट टेस्ट में बदलने का एक मज़ेदार सफ़र बताएंगे. इससे आपको फ़ाइनल प्रॉडक्ट में विश्वास मिलेगा. उम्मीद है कि इससे आपको अपने प्रॉडक्ट के बारे में एक नया नज़रिया मिलेगा.
Chromecast टेस्ट ऑटोमेशन
ब्रायन गोगन (Google)
इंटरनेट के इस्तेमाल की वजह से, कनेक्ट किए गए डिवाइसों की संख्या और ज़्यादा हो गई है. अलग-अलग तरह के इंटरऑपरेट किए जा रहे डिवाइसों पर उपयोगकर्ता के व्यवहार की पुष्टि करना एक बड़ी चुनौती है. Chromecast की जांच करने के लिए, कई तरीके अपनाए गए. हमने टेस्ट फ़्रेमवर्क, लैब इन्फ़्रास्ट्रक्चर, और टेस्ट टूल की रूपरेखा तैयार की है. हमने प्रॉडक्ट से भरोसेमंद क्वालिटी सिग्नल जनरेट करने के लिए डेवलप किया है. हम शोर वाले नेटवर्क पर काम करने वाले प्रॉडक्ट की जांच करने से जुड़ी चुनौतियों के बारे में बताते हैं. हमारा सुझाव है कि Chromecast जैसे डिवाइसों के लिए टेस्टिंग टूल का इस्तेमाल शुरू से ही किया जा रहा है. साथ ही, हम सॉफ़्टवेयर टेस्ट इंजीनियरिंग में इनोवेशन के अवसर पेश कर रहे हैं.
Android ऐप्लिकेशन की जांच करने के लिए रोबोट का इस्तेमाल करना
डॉ॰ शोविक रॉय चौधरी (जॉर्जिया टेक/चेकड्रोइड)
सॉफ़्टवेयर रोबोट, जैसे कि मंकी का इस्तेमाल, मैन्युअल तरीके से कोशिश किए बिना Android ऐप्लिकेशन की जांच करने के लिए किया जा सकता है. शिक्षा से जुड़े ऐसे कई टूल हैं जिनका मकसद, Android ऐप्लिकेशन को टेस्ट करने के लिए टेस्ट इनपुट अपने-आप जनरेट करना है. इस बातचीत में, मैं प्रतिनिधि टेस्ट इनपुट जनरेट करने वाले टूल का एक सेट पेश करूंगा. साथ ही, उनकी खूबियों और सीमाओं को हाइलाइट करने के लिए एक तुलना करने वाला स्टडी प्रज़ेंट करेगा. आपको इन टूल के बारे में जानकारी दी जाएगी. साथ ही, यह भी बताया गया है कि इनका इस्तेमाल करके, अपने आवेदन की जांच कैसे की जा सकती है. अध्ययन के विवरण के साथ टूल के साथ VM सेटअप यहां उपलब्ध है: http://bear.cc.gatech.edu/~shauvik/androtest/
आपके टेस्ट खराब नहीं हैं
ऐलिस्टर स्कॉट (ऑटोमेटिक)
फ़्लैकी परीक्षण किसी भी स्वचालित परीक्षण इंजीनियर की गड़बड़ी हैं; जैसा कि किसी व्यक्ति ने (एक बार शायद एलिस्टर) किया था, एक बार कहता था कि “पागलपन में बार-बार एक ही जांच हो रही है और अलग-अलग नतीजे मिल रहे हैं”. फ़्लैकी की वजह से हमेशा निराशा नहीं होती, लेकिन जाँच की ऐसी कोई गलती नहीं होती, शायद हमें किसी दूसरे लेंस से देखने की ज़रूरत पड़ती है. हमें लचीले और स्थायी टेस्ट तैयार करने के मुकाबले, इस काम के लिए ज़्यादा समय देने वाले, टेस्ट करने लायक, ज़्यादा सिस्टम बनाने में ज़्यादा समय लगाना चाहिए. Alister, जांच करने के लिए भेजे गए गड़बड़ी के कुछ उदाहरण शेयर करेगा. जांच में बताया गया है कि जांच में गड़बड़ी की वजह से, सिस्टम में गड़बड़ी हुई थी. साथ ही, यह भी बताया गया था कि जांच को बेहतर बनाने के लिए, बेहतर सिस्टम कैसे बनाए जा सकते हैं.
बड़े पैमाने पर ऑटोमेटेड विज़ुअल टेस्टिंग
ऐडम कार्मी (टूल)
डेवलपर / टेस्ट समुदाय में, ऑटोमेटेड विज़ुअल जांच एक सबसे लोकप्रिय ट्रेंड है. इस बातचीत में आपको यह पता चलेगा कि विज़ुअल टेस्टिंग क्या है और उसे अपने-आप क्यों चालू होना चाहिए. हम विज़ुअल टेस्ट ऑटोमेशन से जुड़ी कुछ टेक्नोलॉजी से जुड़ी समस्याओं के बारे में गहराई से जानेंगे. साथ ही, दिखाएंगे कि नए टूल इनका इस्तेमाल कैसे करते हैं. हम आधुनिक टेक्नोलॉजी का डेमो देंगे, जिससे क्रॉस ब्राउज़र और क्रॉस डिवाइस विज़ुअल की जांच की जा सके. साथ ही, बड़े पैमाने पर विज़ुअल टेस्टिंग से सफलता पाने के लिए अहम सलाह भी दी जाएगी.
हैंग ऑफ़ रिग्रेशन टेस्टिंग
कैरिन लुंडबर्ग (Twitter) और प्यूनेट खंडुरी (Twitter)
आपकी टीम ने अभी-अभी एक सेवा का एक बड़ा रिफ़ैक्चर पूरा किया है और आपकी सभी इकाई और एकीकरण परीक्षण पास हो गए हैं. बहुत बढ़िया! हालांकि, आपने यह काम अभी पूरा नहीं किया है. अब आपको यह पक्का करना होगा कि आपने कोई भी गड़बड़ी तो नहीं छोड़ी है. साथ ही, यह भी पक्का करें कि फ़िलहाल कोई ऐसी गड़बड़ी न हो जो आपने अभी तक न पकड़ी हो. डिफ़ी को काम पर रखने का समय आ गया है.
यह पक्का करने के लिए कि आपका कोड, आवाज़ जैसे कि यूनिट या इंटिग्रेशन टेस्ट है, डिफ़ी आपकी नई सेवा के व्यवहार और पुराने सेवा के इंस्टेंस को अलग-अलग खड़ा करके, उनकी तुलना करता है. साथ ही, रिस्पॉन्स की तुलना करता है और रिग्रेशन से मिलने वाले रिग्रेशन को दिखाता है.
हमने इस टूल को हाल ही में लॉन्च किया है. यह Twitter के ओपन सोर्स प्रोजेक्ट में सबसे ज़्यादा लोकप्रिय हो गया है.
Android ऐप्लिकेशन के लिए ऑटोमेटेड सुलभता टेस्टिंग
केसी बुर्कहार्ट (Google)
इस चर्चा से, Android प्लैटफ़ॉर्म पर सुलभता के मुख्य खर्चों के बारे में पता चलेगा. साथ ही, सुलभता से जुड़ी कुछ सामान्य डेवलपर समस्याओं के बारे में बताया जाएगा. इसमें, नए Android सुलभता टेस्ट फ़्रेमवर्क के बारे में जानकारी मिलेगी. साथ ही, यह जानकारी भी है कि एस्प्रेसो और रोबोलेट्रिक टेस्टिंग फ़्रेमवर्क में इसका इंटिग्रेशन क्या है. आखिर में, आप मौजूदा Android प्रोजेक्ट की जांच में, अपने-आप सुलभता जांचने की सुविधा को जोड़ना आसान बना पाएंगे.
आंकड़ों के डेटा का सैंपल
Celal Ziftci (Google) और Ben Greenberg (MIT ग्रैजुएट छात्र)
टेस्ट में प्रोडक्शन डेटा के नमूने का इस्तेमाल करना आम बात है. उदाहरण के लिए:
- सैनिटेशन टेस्ट: अपने सिस्टम में प्रोडक्शन डेटा के नमूने को फ़ीड करें, ताकि यह पता चल सके कि कोई गड़बड़ी हुई या नहीं.
- A/B टेस्ट: प्रोडक्शन डेटा का एक बड़ा हिस्सा लें, उसे अपने सिस्टम के मौजूदा और नए वर्शन के ज़रिए चलाएं, और जांच के लिए आउटपुट में अंतर करें.
प्रोडक्शन डेटा का सैंपल लेने के लिए, टीमें आम तौर पर ऐड-हॉक सलूशन का इस्तेमाल करती हैं, जैसे:
- खास फ़ील्ड के डिस्ट्रिब्यूशन को मैन्युअल तरीके से देखना (जैसे, संख्या वाले फ़ील्ड),
- कोई भी सैंपल चुनना
हालांकि, इन तरीकों का गंभीर असर नहीं होता है: इनसे आपको कुछ खास मौकों (जैसे, किनारे के केस) में कमी मिल सकती है. इसकी वजह से, प्रोडक्शन में आने वाली गड़बड़ियों का खतरा बढ़ जाता है. इस जोखिम को कम करने के लिए, टीमें बहुत बड़े सैंपल चुनते हैं. हालांकि, इतने बड़े नमूनों के अलावा, इसमें और भी कमियां हैं:
- कभी-कभार होने वाले इवेंट छूट सकते हैं,
- जांच के रनटाइम में काफ़ी बढ़ोतरी हुई है,
- किसी व्यक्ति के लिए इसे समझने के लिए अंतर बहुत बड़े होते हैं और इसमें बहुत ज़्यादा दोहराव होता है.
इस बातचीत में, हमने आंकड़ों वाले डेटा के नमूने का विश्लेषण करने की तकनीक को "स्मार्ट तरीके से" इस्तेमाल करने का सुझाव दिया. इस सैंपल को प्रोडक्शन डेटा में से "अच्छा" चुना गया, ताकि:
- इस बात की गारंटी देना कि कोई भी खास इवेंट देखने में न लगे,
- डुप्लीकेट को हटाकर चुने गए नमूने के आकार को कम करता है.
हमारी तकनीक बहुत कम/सीमा वाले मामलों का पता लगा लेती है. साथ ही, नमूने के साइज़ को कम से कम रखती है और डेवलपर पर टेस्ट आउटपुट/अंतर देखने के मैन्युअल तरीके से किए गए दबाव को कम कर देती है. साथ ही, यह पैरलल एक्ज़ीक्यूशन (जैसे कि MapDown) भी काम करता है, ताकि सैंपल चुनने के लिए, कम समयसीमा में ज़्यादा डेटा प्रोसेस किया जा सके.
Nest ऑटोमेशन का इंफ़्रास्ट्रक्चर
उस्मान अब्दुल्ला (Nest), ज्यूलिया गुइदी (Nest) और सैम गॉर्डन (Nest)
Thoughtful Home के लिए Nest के विज़न में एक-दूसरे से जुड़े हुए, समझदार डिवाइस शामिल हैं. इससे, आपके घर को ज़्यादा सुरक्षित, ज़्यादा ऊर्जा की बचत करने वाला, और ज़्यादा जानकारी देने वाला डिवाइस मिलता है. इस चर्चा का फ़ोकस उन ऑटोमेशन इन्फ़्रास्ट्रक्चर और टेस्ट टूल पर होगा जिन्हें उस लक्ष्य को हकीकत में बदलने के लिए बनाया गया है. Nest की अलग-अलग टीमें, अपने-आप होने वाले रिग्रेशन टेस्ट और विश्लेषण के लिए, क्रॉस-प्लैटफ़ॉर्म और डिवाइस/सुविधा, दोनों के सिस्टम पर काम कर रही हैं. असल दुनिया के प्रॉडक्ट की जांच के खास उदाहरणों का इस्तेमाल करते हुए, हम लूप टेस्टिंग इंफ़्रास्ट्रक्चर और पावर रिग्रेशन विश्लेषण टूल में क्रॉस-प्रॉडक्ट हार्डवेयर के साथ-साथ कैमरा और हलचल का पता लगाने वाले खास टूल सेट भी शामिल करेंगे.
इवेंट जनरेटर
रौसी रूसे (स्प्लंक)
इस बातचीत में, Splunk में सॉफ़्टवेयर इवेंट जनरेटर बनाने और इस्तेमाल करने के हमारे अनुभवों के बारे में बताया गया है. कण भौतिकी से प्रेरित, जहां बड़े पैमाने पर एक्सपेरिमेंटल मशीनें चलाए बिना भी इवेंट जनरेटर से वास्तविक दुनिया को समझना ज़रूरी हो गया है. लॉग जनरेटर से, हम तीसरे पक्ष के आधुनिक और पुराने सॉफ़्टवेयर के साथ कई इंटिग्रेशन को टेस्ट कर रहे हैं. इस बातचीत में, बुनियादी सुविधाओं और असल के लॉग जनरेट करने में आने वाली चुनौतियों के बारे में बताया गया है.
मल्टी-थ्रेड टेस्ट सिंथेसिस
मुरली कृष्ण रामनाथन (भारतीय विज्ञान संस्थान, बेंगलुरु)
सिर्फ़ सटीक तकनीकों का इस्तेमाल करके, कई थ्रेड वाली ऐसी लाइब्रेरी में एक साथ कई गड़बड़ियों को ठीक नहीं किया जा सकता जो गलत या सिंक की गई सिंक की वजह से आती हैं. वहीं, डाइनैमिक डिटेक्टर कितने असरदार हैं, यह कई थ्रेड वाले ऐसे टेस्ट सुइट पर निर्भर करता है जिनका एक्ज़ीक्यूशन, डेटा रेस, डेडलॉक, और ऐटॉमिकिटी से जुड़े उल्लंघनों के साथ-साथ, एक साथ कई गड़बड़ियों को पहचानने और ट्रिगर करने के लिए किया जाता है. आम तौर पर, इस तरह की मल्टी-थ्रेड वाली जांच के लिए, खास तरीकों के कॉम्बिनेशन का इस्तेमाल करना ज़रूरी होता है. इसमें शुरू करने के लिए इस्तेमाल किए जाने वाले ऑब्जेक्ट के साथ सही तरीके से जानकारी शेयर करना शामिल है. गड़बड़ी की पहले से जानकारी न होने पर, ऐसी जांच करना चुनौती भरा हो सकता है.
इस बातचीत में, हम आसान और बड़े स्तर पर इस्तेमाल की जाने वाली तकनीक पेश करेंगे, जिसमें थ्रेड को सुरक्षित रखने वाले उल्लंघनों का पता लगाने की जांच की जाएगी. कई थ्रेड वाली लाइब्रेरी और क्रम में चलने वाले टेस्ट सुइट को ध्यान में रखते हुए, मैं पूरी तरह से अपने-आप होने वाले विश्लेषण के बारे में बात करूंगा/करूंगी, जो एक्ज़ीक्यूशन एक्ज़ीक्यूशन ट्रेस की जांच करता है. साथ ही, यह एक प्रॉजेक्ट को एक कनकरेंट क्लाइंट प्रोग्राम के तौर पर तैयार करता है. इससे, एक साथ कई गड़बड़ियों को ट्रिगर करने के लिए, राज्य के तरीके से 'शेयर किए गए ऑब्जेक्ट' को लाइब्रेरी तरीके से कॉल किया जाता है. अच्छी तरह से टेस्ट की गई Java लाइब्रेरी पर प्रयोग के तौर पर मिले नतीजे, कई जटिल गड़बड़ियों का पता लगाने की हमारी कोशिशों के असर को दिखाते हैं.
Netflix पर स्ट्रीमिंग के प्रयोग चालू करना
मीनल मिश्रा (Netflix)
Netflix के लिए 6.9 करोड़ से ज़्यादा उपयोगकर्ता स्ट्रीमिंग अनुभव बेहद अहम है. इसे तेज़ी से बेहतर बनाने के लिए, हम अडैप्टिव स्ट्रीमिंग एल्गोरिदम को JavaScript लेयर में ले गए. ऐसे में, क्लाइंट के लिए सॉफ़्टवेयर को बार-बार रिलीज़ करने वाली चुनौती का सामना करना पड़ा था. इसलिए, हो सकता है कि इसका सीधा असर उपयोगकर्ताओं के स्ट्रीमिंग अनुभव पर पड़ा हो. लगातार किए जाने वाले डिलीवरी मॉडल पर काम करना, जिसे सेवा आवेदनों के लिए बड़े पैमाने पर और सही तरीके से अपनाया गया है, हमने इसका इस्तेमाल चेकइन की लाइफ़साइकल के जोखिम को कम करने और समय-समय पर अपडेट देने के लिए किया. इस बातचीत में, हम सॉफ़्टवेयर अपडेट चालू करने के लिए, इस मॉडल के खास कॉम्पोनेंट के बारे में बताएंगे. मौजूदा वर्शन के मुकाबले, JavaScript की स्थिति के बारे में सटीक तरीके से तुलना करने के लिए, हम JavaScript क्लाइंट और टूल को लॉन्च करने के तरीके के बारे में ज़्यादा जानेंगे. हम इस प्रक्रिया में आने वाली चुनौतियों को भी शेयर करेंगे.
इंटरनेट का मॉक
Yabin Kang (LinkedIn)
इंटरनेट पर मॉक करने के लिए, Linkedin में मॉकिंग सिस्टम की बात की जा रही है. इससे सेवा स्तर के इंटिग्रेशन की जांच के लिए, सभी आउटबाउंड ट्रैफ़िक को मॉक-इन करने में मदद मिलती है. इस सर्वे में, Linkedin मॉकिंग की रणनीति की खास जानकारी भी मिलती है. जानकारी और हमने जो सीखा है उसे सभी के साथ शेयर करें.
जीपीएस मॉनिटरिंग स्टेशन रिसीवर का असरदार जांच
एंड्रयू नॉड (लॉकहीड मार्टिन)
एयर फ़ोर्स के इस्तेमाल किए जा रहे मौजूदा जीपीएस मॉनिटरिंग स्टेशन का रखरखाव करना मुश्किल हो गया है. इनकी जगह, जीपीयू ऐक्सेलरेटेड सॉफ़्टवेयर डिफ़ाइंड रेडियो (एसडीआर) टेक्नोलॉजी का इस्तेमाल किया जा रहा है. इस खास जीपीएस रिसीवर की टेस्टिंग की खास चुनौतियों की खास जानकारी और कई टेस्टिंग तरीकों की पड़ताल की जाएगी. जीपीएस ऐप्लिकेशन पर फ़ोकस करते हुए, इस तरीके को प्रोडक्शन लेवल के एसडीआर की अन्य कोशिशों में आसानी से लागू किया जा सकता है.
पहने जाने वाले डिवाइसों पर ऑटोमेशन
अनुराग रूट्रॉय (Intel)
जैसे-जैसे पहने जाने वाली टेक्नोलॉजी, निजी और कारोबार के इस्तेमाल में तेज़ी से आगे बढ़ रही है, Android की मार्केट में मज़बूत जगह बनाने वाली सभी कंपनियों ने आने वाले समय में इस टेक्नोलॉजी पर फ़ोकस करना शुरू कर दिया है. इसलिए, पहने जाने वाले डिवाइस के साथ उनका ऐप्लिकेशन बनाना, जिससे पहने जाने वाले डिवाइस पर उन्हें टेस्ट करने की संभावना भी बढ़ जाती है. इसलिए, पहने जाने वाले डिवाइस पर ऑटोमेशन की सुविधा इसलिए ज़रूरी हो जाती है, ताकि जांच में लगने वाले समय को कम किया जा सके और क्षमता को बढ़ाया जा सके.
यूनिफ़ाइड इन्फ़्रास्ट्रक्चर और सीआई इंटिग्रेशन टेस्टिंग (डॉकर/वैगन)
मैक्सिम ग्वानिस (सुपरसोनिक)
डेवलपर को डेवलपर के काम करने के दौरान, लोकल डेवलपमेंट एनवायरमेंट को काम करने के लिए कड़ी मेहनत करनी पड़ती है. इससे, इंटिग्रेट करने के साइकल और उसके इंटिग्रेशन के चरण को आगे बढ़ाया जा सकता है. हम सीआई टूल के साथ इस्तेमाल करने के लिए, डॉकर और डेटा इंटिग्रेशन को इंटिग्रेट करके, इस समस्या को हल कर सकते हैं. इस कॉम्बिनेशन की मदद से, डेवलपमेंट सिस्टम पर स्टैक लेवल पर ऐप्लिकेशन कंट्रोल किए जा सकते हैं. साथ ही, इंटिग्रेशन टेस्ट में भी उसी स्टैक का इस्तेमाल किया जा सकता है. इस बातचीत में हम इन विषयों पर चर्चा करेंगे:
- सीआई इंटिग्रेशन जांच में डॉकर का इस्तेमाल
- एक डॉकर या ऐप्लिकेशन के बजाय स्टैक को कंट्रोल करना.
- यह गेम और डॉकर टूल के साथ आसानी से डिस्ट्रिब्यूट किए गए डेवलपमेंट और टेस्ट एनवायरमेंट का वर्शन कंट्रोल करता है.
- Mac और विंडो पर डॉकर चलाने के लिए आसान समर्थन.
बेकार टेस्ट बिट हटाना
पैट्रिक लैम (यूनिवर्सिटी ऑफ़ वॉटरलू)
टेस्ट सुइट के स्टैटिक विश्लेषण तकनीकों को विशेषज्ञता देने से दिलचस्प नतीजे मिले हैं. हमें पहले ही पता चल गया है कि ज़्यादातर टेस्ट, सिंपल-लाइन कोड वाले आसान होते हैं. जैसे, सेट अप स्टेटमेंट का क्रम और उसके बाद पेलोड. हम दिखाते हैं कि स्टैटिक ऐनलिटिक्स का तरीका, ऐसे सेट अप स्टेटमेंट की पहचान कैसे करता है जो डेवलपर को उनके टेस्ट केस को आसान बनाने और उनकी स्पीड बढ़ाने में मदद करते हैं.
कवरेज, सुइट को असरदार तरीके से टेस्ट करने पर असर नहीं डालता
लॉरा इनोज़ेमत्सेवा (यूनिवर्सिटी ऑफ़ वॉटरलू)
टेस्ट सुइट के कवरेज का इस्तेमाल अक्सर गड़बड़ियों की पहचान करने के लिए, प्रॉक्सी के तौर पर किया जाता है. हालांकि, कोड कवरेज और टेस्ट सुइट के असर के बीच संबंध की जांच करने वाले पिछले अध्ययन, इस बात पर एक साथ नहीं आ पाए हैं कि टेस्ट सुइट की विशेषताओं के बीच क्या संबंध है और उन्हें कितना असरदार माना जाता है. इसके अलावा, कई स्टडी छोटी या सिंथेटिक प्रोग्राम की मदद से की गई थीं. इससे साफ़ तौर पर पता नहीं चला कि उनके नतीजे सामान्य प्रोग्राम के लिए हैं या नहीं. साथ ही, कुछ स्टडी ऐसी थीं जो टेस्ट सुइट के साइज़ पर असर नहीं डालती थीं. हमने इन स्टडी का दायरा बढ़ाया है. इसके लिए, हमने टेस्ट सुइट के साइज़, कवरेज, और Java के लिए रीयल-टाइम के असर के बीच के संबंध का आकलन किया है. हमारी यह स्टडी, आज तक की सबसे बड़ी स्टडी है. हमने इन सुइट के स्टेटमेंट कवरेज, डिसिजन कवरेज, और बदली गई कंडीशन कवरेज को मापा. साथ ही, गड़बड़ी की जांच का पता लगाने के लिए, इनमें बदलाव करने की सुविधा का इस्तेमाल किया. हमने पाया कि जब सुइट में टेस्ट केस की संख्या को कंट्रोल किया जाता है, तब कवरेज और विज्ञापन के असर के बीच कम संबंध होता है. इसके अलावा, हमने देखा कि बेहतर कवरेज से, इस सुइट के असर की अहम जानकारी नहीं मिल पाती.
RpcReplay के साथ नकली बैकएंड
Matt Garrett (Google)
जांच का तेज़ और स्थिर होना बेहद ज़रूरी है. यह तब मुश्किल होता है, जब सर्वर कई बैकएंड पर निर्भर करते हैं. डेवलपर को लंबे और फ़्लैकी टेस्ट या फ़र्ज़ी तरीकों को लागू करने और उनका रखरखाव करने में से किसी एक को चुनना होगा. इसके बजाय, इन बैकएंड से रिकॉर्ड किए गए ट्रैफ़िक का इस्तेमाल करके जांच की जा सकती है. इससे दोनों दुनिया की बेहतरीन सुविधाएं मिलती हैं. साथ ही, डेवलपर को बैकएंड की तुलना में तुरंत टेस्ट करने की सुविधा मिलती है.
ChromeOS टेस्ट ऑटोमेशन लैब
सिमरन बासी (Google) और क्रिस सोसा (Google)
फ़िलहाल, ChromeOS 60 से ज़्यादा अलग-अलग Chromebook/बॉक्स भेज रहा है, जिनमें से हर एक का अपना सॉफ़्टवेयर है. ग्राहकों को हर छह हफ़्ते पर नया सिस्टम मिलता है. हम अपने 200 से ज़्यादा डेवलपर से, एक जैसे स्थायी इंटिग्रेशन सिस्टम की जांच के बिना, यह जांच नहीं कर सकते. इस कॉल में, हम अपने टेस्ट ऑटोमेशन लैब पर खास ज़ोर देते हुए पूरे आर्किटेक्चर के बारे में बताएंगे. इसके अलावा, हम Moblab (मोबाइल के लिए छोटी (जांच) लैब) के बारे में बात करते हैं. यह एक ही chromebox से चलने वाली हमारी पूरी टेस्ट ऑटोमेशन सुविधा है. हमारे कई पार्टनर इस सिस्टम का इस्तेमाल करते हैं, ताकि वे भी हमारे टेस्ट करने के लिए टेस्ट कर सकें.