मुख्य बातों को खोलना - टेस्ट करने लायक JavaScript - जांच के लिए अपने ऐप्लिकेशन को तैयार करना
मार्क ट्रॉस्टर (Google)
टेस्ट किया जा सकने वाला JavaScript एक प्रोसेस है. चाहे किसी खाली स्लेट से शुरुआत की जा रही हो या पहले से लागू किए गए ऐप्लिकेशन का इस्तेमाल (या बीच-बीच में) आपके JavaScript कोड की जांच करने में सक्षम हो, उसे साफ़ और असरदार तरीके से आज़माना ज़रूरी है. जिस कोड की जांच नहीं की जा सकती उसे फिर से लिखा जाएगा.
जहां JavaScript के बहुत सारे एनवायरमेंट की वजह से यह चलता है, वहां कई अन्य भाषाओं में आज़माए गए और सही 'टेस्टेबल' तरीके उपलब्ध होते हैं. साथ ही, कुछ खास चुनौतियां भी हैं जिन्हें JavaScript डेवलपर को अपना कोड लिखते और उसकी जांच करते समय करना होगा.
कौनसे पैटर्न से कोड को टेस्ट किया जा सकता है? किन पैटर्न की जांच में रुकावट आती है? हमारे कोड की जांच करने की क्षमता को मापने के लिए, किस मेट्रिक और सामान्य समझ वाले गाइडपोस्ट का इस्तेमाल किया जा सकता है? क्या जांच योग्य कोड बनाने की प्रक्रिया शुरू होने के बाद क्या होगा?
जांच किए जा सकने वाले JavaScript को लिखने की प्रोसेस को अलग-अलग करने के लिए, मुझसे जुड़ें. हम आइडिया, पैटर्न, और काम करने के तरीकों की जांच करेंगे. इनकी मदद से, जांच को बेहतर बनाया जा सकता है और कोड को लंबे समय तक इस्तेमाल किया जा सकता है. आप इस प्रोसेस में महारत हासिल करने वाले क्लाइंट- या सर्वर साइड JavaScript लिखते हैं, इससे आपके कोड की क्वालिटी बहुत बेहतर होगी.
ब्रेकिंग द मैट्रिक्स - Android टेस्टिंग स्केल
थॉमस नायच (Google), स्टेफ़न रामसॉर (Google), और वलेरा ज़ाखारोव (Google)
क्या आप लाल दवाई लेने के लिए तैयार हैं?
मोबाइल ने लोगों के कंप्यूटर से इंटरैक्ट करने का तरीका बदल दिया है. यह बढ़िया है, लेकिन इंजीनियर के रूप में लगातार बदलते माहौल की वजह से हम अपने कोड को चला रहे हैं. सिर्फ़ कुछ ब्राउज़र और स्क्रीन रिज़ॉल्यूशन पर विचार करने के दिन नहीं लौट रहे हैं. इंजीनियर, मैट्रिक्स का सामना कैसे कर सकते हैं? हम इस बारे में बात करेंगे कि Google, वर्कस्टेशन पर क्लाउड में इस टेस्टिंग प्रॉब्लम को कैसे हल कर रहा है...
{0}मैं आपको याद दिलाना चाहती हूं, नियो. हालाँकि, मैं सिर्फ़ आपको दरवाज़ा दिखा सकती हूँ. आपको इस प्रोसेस से गुज़रना होगा."
Android यूज़र इंटरफ़ेस (यूआई) ऑटोमेशन
ग्वांग ज़ू (朱光) (Google) और एडम मोमताज़ (Google)
जैसे-जैसे Android को मोबाइल की दुनिया में लोकप्रियता मिल रही है, ऐप्लिकेशन डेवलपर और OEM वेंडर, ऐप्लिकेशन और पूरे प्लैटफ़ॉर्म की एंड-टू-एंड यूज़र इंटरफ़ेस (यूआई) की जांच को टेस्ट करने के तरीके एक्सप्लोर कर रहे हैं. Android पर, यूज़र इंटरफ़ेस (यूआई) ऑटोमेशन के कुछ मौजूदा समाधानों की समीक्षा के साथ, यह बातचीत, हाल ही में रिलीज़ हुए Android यूज़र इंटरफ़ेस (यूआई) ऑटोमेटर फ़्रेमवर्क के बारे में बताने के साथ-साथ, फ़्रेमवर्क के सामान्य इस्तेमाल के उदाहरणों और वर्कफ़्लो पर भी नज़र रखेगी.
Appium: मोबाइल ऐप्लिकेशन के लिए ऑटोमेशन
जॉनथन लिप्स (सॉस लैब)
Appium एक Node.js सर्वर है जो नेटिव और हाइब्रिड मोबाइल ऐप्लिकेशन (iOS और Android, दोनों) को ऑटोमेट करता है. एपियम का सिद्धांत है कि ऐप्लिकेशन को अपने-आप बदलने के लिए उनमें बदलाव नहीं किया जाना चाहिए. साथ ही, आपको अपना टेस्ट कोड किसी भी भाषा या फ़्रेमवर्क में लिखने की सुविधा मिलनी चाहिए. ऐसा करने से, सेलिनियम वेबड्राइवर सर्वर, मोबाइल की तरह स्थानीय भाषा बोलने लगता है. Appium, असली डिवाइसों और एम्युलेटर पर काम करता है. यह पूरी तरह से ओपन सोर्स है. यह मोबाइल टेस्ट ऑटोमेशन का इस्तेमाल शुरू करने का सबसे शानदार तरीका है. इस बातचीत में, मैं उन सिद्धांतों के बारे में बताऊँगा जिनमें ऐपियम को डिज़ाइन करने के बारे में बताया गया है. साथ ही, उन दिशा-निर्देशों के बारे में भी बताया जाएगा जो ऐपियम को दूसरे मोबाइल ऑटोमेशन फ़्रेमवर्क के ज़रिए बताते हैं. साथ ही, वह आर्किटेक्चर भी पेश करेंगे जो इसे लागू करने में मदद करते हैं. आखिर में, मैं एक नए मोबाइल ऐप्लिकेशन के आसान टेस्ट में कोड की जांच करूंगा. साथ ही, iPhone और Android पर यह टेस्ट करने वाला Appium दिखाऊंगी.
Google+ मोबाइल के लिए बड़े पैमाने पर मोबाइल टेस्ट का बुनियादी ढांचा बनाना
एड्वर्डो ब्रावो (Google)
सही और स्थिर तरीके से नेटिव ऐप्लिकेशन की जांच करना एक चुनौती है. G+ ने मोबाइल से पेश किए जाने वाले हर जटिल परीक्षण की परिस्थितियों के लिए सही इंफ़्रास्ट्रक्चर देकर, इन समस्याओं को हल करने के लिए कारगर समाधान डेवलप किए हैं. हमारी मौजूदा टेस्ट इंफ़्रास्ट्रक्चर, iOS और Android ऐप्लिकेशन, दोनों के लिए सही टूल उपलब्ध कराता है. इससे, हमारी डेवलपमेंट टीम को यह भरोसा मिलता है कि नए बदलाव से मौजूदा क्लाइंट पर कोई असर नहीं पड़ेगा.
एस्प्रेसो: Android यूज़र इंटरफ़ेस (यूआई) की नई जांच
वलेरा ज़ाखारोव (Google)
एक भरोसेमंद Android टेस्ट बनाना उतना ही आसान होगा जितना एस्प्रेसो का शॉट लेना हो. माफ़ करें, मौजूदा टूल की मदद से, आपको ऐसा लग सकता है कि डबल-शॉट-कैरामेल-सॉस-अप-डाउन-डाउन-सिंगल-व्हिप-आधे-लैट-बनाने का तरीका इस्तेमाल करना है. Espeso एक नया Android टेस्ट फ़्रेमवर्क है. इसकी मदद से, कम शब्दों में लिखने वाले, सुंदर, और भरोसेमंद यूज़र इंटरफ़ेस (यूआई) टेस्ट तुरंत लिखे जा सकते हैं. Core API छोटा है, अनुमान लगाने में आसान है, और इसे सीखना आसान है - फिर भी यह कस्टमाइज़ेशन के लिए भी खुला है. एस्प्रेसो टेस्ट ऐसे कॉन्टेंट से उम्मीदों, इंटरैक्शन, और दावों की जानकारी साफ़ तौर पर देता है जो बॉयलरप्लेट, कस्टम इंफ़्रास्ट्रक्चर, और लागू करने के तरीके में परेशान किए बिना परेशान करता है. टेस्ट काफ़ी बेहतर तरीके से किए जाते हैं - इंतज़ार करें, सिंक करें, स्लीप मोड (कम बैटरी मोड) में जाएं, और पोल बनाएं. इसके बाद, फ़्रेमवर्क आपके यूआई में उस समय बदलाव करने और उसे बनाए रखने में मदद करता है जब वह रुका हुआ हो. लिखने और एक्ज़ीक्यूट करने के लिए यूज़र इंटरफ़ेस (यूआई) की जांच करना शुरू करें - एस्प्रेसो का शॉट आज़माएं.
WebDriver की मदद से, वेब की परफ़ॉर्मेंस की जांच करना
माइकल क्लेपिकोव (Google)
वेब परफ़ॉर्मेंस टेस्ट में, हम पेज लोड का विश्लेषण करने के तरीके जानते हैं. हालांकि, हमें पेज लोड से आगे नहीं बढ़ना है: आधुनिक ऐप्लिकेशन बहुत इंटरैक्टिव हैं, लेकिन कार्रवाई पूरे पेज को फिर से लोड नहीं करते, बल्कि अपडेट करते हैं. अलग-अलग लोगों ने खुद को शामिल करके, WebDriver को वेब परफ़ॉर्मेंस टेस्ट के लिए इस्तेमाल किया है. इससे, परफ़ॉर्मेंस टेस्ट को बाकी यूज़र इंटरफ़ेस (यूआई) टेस्ट सुइट से अलग रखा जाता है. मैं सीधे WebDriver में ही परफ़ॉर्मेंस की जांच करने वाली सुविधाएं बनाने का सुझाव देता हूं. इससे, वह हाल ही में जोड़े गए Logging API का इस्तेमाल करेगा. सामान्य तौर पर फ़ंक्शनल टेस्ट करते समय, परफ़ॉर्मेंस मेट्रिक इकट्ठा करना मुमकिन है. इससे, पूरे टेस्ट और फ़्लो में टेस्ट की परफ़ॉर्मेंस को आसानी से इंटिग्रेट किया जा सकता है. साथ ही, यह हर बड़े संगठन के बनाए गए कस्टम बिल्ड/टेस्ट टूलचेन से भी बहुत कम रुकावट पैदा करता है.
मैं इसे नई पीढ़ी के ChromeDriver (Chromium ब्राउज़र के लिए WebDriver) के साथ दिखाऊँगा.
Maps में लगातार डेटा की जांच करना
Yvette Nameth (Google) और Branan Dhein (Google)
लगातार जांच करने का मतलब है, यूनिट की जांच और इंटिग्रेशन की जांच करना. हालांकि, जब आपके सर्वर से प्रोसेस किया जाने वाला डेटा ही बदलाव की सबसे बड़ी वजह होता है, तो आपके हिसाब से, डेटा के उपभोक्ताओं को इसे इस्तेमाल करने लायक कैसे बनाया जाए? साथ ही, यह भी पक्का करें कि बदलाव की दर या खराब बदलाव की वजह से कुछ भी क्रैश न हो? हम Google Maps से मिले नतीजों की मदद से, लगातार डेटा की जांच करने की तकनीकों पर चर्चा करेंगे.
फ़ेल बिल्ड में अपने-आप अपराधियों को ढूंढना - जैसे, बिल्ड को किसने तोड़ा?
सीलाल ज़िफ़्टी (यूसीएसडी) और विवेक रामवाज्जाला (यूसीएसडी)
लगातार बिल्ड करना, Google के मुख्य ढांचे में से एक है. जब कोई बिल्ड फ़ेल हो जाता है, तो यह ज़रूरी है कि इसकी वजह से या देरी से, बदलावों की सूची (सीएल)/बदलाव वाली सूची का जल्दी पता चल जाए. इससे, बिल्ड को वापस हरे रंग में लाया जा सकता है.
अपराधी की पहचान करने वाले समाधान छोटे और मध्यम आकार के बिल्ड के लिए मौजूद हैं, लेकिन बड़े इंटिग्रेशन के लिए नहीं.
गड़बड़ी की खोज करने वाला हमारा टूल, बहुत कम समय में अपने-आप बिल्ड के लिए सीएलआरटी सीएल को अपने-आप ढूंढ लेता है, ताकि ज़्यादा सफलता मिल सके. पिछले नौ महीनों में कई प्रोजेक्ट पर किए गए प्रोडक्शन के आधार पर, कलेक्ट खोजने वाले टूल से काफ़ी अच्छे नतीजे मिलते हैं. आइए देखें कि हमने अपराधी खोजने वाले टूल को कैसे लागू किया. साथ ही, यह भी देखा कि यह कॉन्टेंट प्रोडक्शन में कितना कारगर रहा है और कैसा लगता है.
सॉफ़्टवेयर प्रॉडक्ट लाइन की क्वालिटी की अनुभव जांच
कैतेरीना गोसेवा-पोस्तोस्तोनोवा (वेस्ट वर्जीनिया यूनिवर्सिटी)
सॉफ़्टवेयर की प्रॉडक्ट लाइन, प्रॉडक्ट लाइन में मौजूद सिस्टम के बीच ज़्यादा समानताएं दिखाती हैं. साथ ही, ये संभावित वैरिएंट की एक खास संख्या भी दिखाती हैं. दो केस स्टडी से निकाले गए डेटा के आधार पर - मीडियम साइज़ की इंडस्ट्रियल प्रॉडक्ट लाइन और बड़ी होने वाली ओपन सोर्स प्रॉडक्ट लाइन - हमने इस बारे में अनुभव किया कि सिस्टम में फिर से इस्तेमाल किए जाने पर क्वालिटी पहले से बेहतर हो जाती है और आने वाले समय में होने वाली खराबियों, सोर्स कोड मेट्रिक, और मेट्रिक में बदलाव करने में मदद मिलती है. एक सॉफ़्टवेयर प्रॉडक्ट लाइन सेटिंग में, हमारी रिसर्च के नतीजों ने इस बात की पुष्टि की है कि स्टैटिक कोड मेट्रिक की तुलना में, मेट्रिक में बदलाव करने के लिए आम तौर पर होने वाली कमियों के बारे में पता चलता है. क्वालिटी आकलन के नतीजों से पता चला है कि पुराने पैकेज (इसमें आम तौर पर इस्तेमाल होने वाले पैकेज भी शामिल हैं) में लगातार बदलाव हो रहे थे. हालांकि, वे आज भी खराब क्वालिटी की क्वालिटी की स्थिति में बदलाव करते रहते हैं. साथ ही, ओपन सोर्स प्रॉडक्ट की लाइन रिलीज़ होने के साथ ही उसकी क्वालिटी बेहतर हुई. सामान्य लीनियर रिग्रेशन मॉडल पर आधारित अनुमान ने पिछली रिलीज़ में बनाए गए मॉडल का इस्तेमाल करके, रिलीज़ के बाद की गड़बड़ियों के आधार पर पैकेज की सही रैंकिंग की थी. नतीजों से यह भी पता चला कि रिलीज़ के बाद की गई गड़बड़ियों का अनुमान लगाने के लिए, प्रॉडक्ट लाइन से जुड़ी अतिरिक्त जानकारी का इस्तेमाल किया जाता है.
AddressSanitizer, ThreadSanitizer और MemorySanitizer -- C++ के लिए डाइनैमिक टेस्टिंग टूल
कोस्टिया सेरेब्रीनी (Google)
AddressSanitizer (ASan) एक ऐसा टूल है जो बफ़र ओवरफ़्लो (स्टैक, हीप, और ग्लोबल) में और C/C++ प्रोग्राम में बाद में आने वाली गड़बड़ियों का पता लगाता है. ThreadSanitizer (TSan) को C/C++ और Go प्रोग्राम में डेटा रेस का पता चलता है. MemorySanitizer (MSan) काम को शुरू करने वाला एक टूल है, जो शुरुआत की गई मेमोरी (C++) का इस्तेमाल करता है. ये टूल, कंपाइलर इंस्ट्रुमेंटेशन (LLVM और GCC) पर आधारित होते हैं. इन टूल की मदद से, यह बहुत तेज़ी से काम करता है (उदाहरण के लिए, ASan दो गुना धीमा होता है). हम इन टूल का इस्तेमाल करके, बड़े पैमाने पर टेस्टिंग के लिए अपना अनुभव शेयर करेंगे.
मुख्य दस्तावेज़ - महासागर में पीने का - Google स्केल पर XSS ढूंढना
Claudio Chriscione (Google)
क्रॉस साइट स्क्रिप्टिंग या XSS, वेब ऐप्लिकेशन की दुनिया में मध्य-युग के काले प्लेग के बराबर है, जो कि बड़े पैमाने पर होता है. यह खराब है या इसका पता लगाने के बहुत कम या कोई तकनीकी तरीके नहीं हैं. DOM XSS खास तौर पर सबसे खराब वर्शन है, क्योंकि इसके लिए एक असली ब्राउज़र या इसके बराबर की किसी समस्या का पता लगाना ज़रूरी है: एक छोटी समस्या, जो अपने-आप काम करने वाले छोटे-छोटे समाधानों के साथ उपलब्ध है.
हमें डेवलपमेंट लाइफ़साइकल में डीओएम XSS की पहचान करने के लिए, दमदार और सेल्फ़-ड्राइविंग टूल की ज़रूरत थी. इसे सुरक्षा टीम के बाहर काम करने वाले इंजीनियर इस्तेमाल कर सकते थे. हमें सिर्फ़ एक ऐसा प्रॉडक्ट चाहिए था जो हमारे विशाल, तेज़, और मुश्किल से मुश्किल ऐप्लिकेशन को स्कैन कर सके... और ज़ाहिर है, हमें भी कुछ नहीं मिला. इसलिए, हमने खुद का वेब ऐप्लिकेशन स्कैनर बनाया है. इसे स्टैंडर्ड Google टेक्नोलॉजी के ऊपर डिज़ाइन किया गया DOM XSS टारगेट करता है. यह App Engine में चलता है और यह दमदार Chrome ब्राउज़र और कुछ सैकड़ों सीपीयू के साथ, सुरक्षा स्कैनिंग वाले प्लैटफ़ॉर्म के तौर पर काम करता है.
साथ ही, यह Google में जांच के लिए इस्तेमाल होने वाले आर्सेनल का एक अच्छा नागरिक है. यह सुरक्षा से जुड़ी टीम की भूमिका निभाने के बजाय, जांच करने वाले हमारे इन्फ़्रास्ट्रक्चर में काम करता है.
इस कॉल में, हमने अपने नए तरीके की जानकारी दी है. साथ ही, अपने सिस्टम को Google के साइज़ के हिसाब से स्केल करने और JavaScript की वजह से इस्तेमाल होने वाले ऐप्लिकेशन में हमारे डिटेक्शन और क्रॉल करने के मॉडल के बारे में दिए गए विचारों के बारे में बताया है.