iWork Keynote - JavaScript הניתן לבדיקה - תכנון האפליקציה שלך לבדיקה
Mark Trostler (Google)
JavaScript שניתן לבדיקה הוא תהליך. בין אם מדובר בהתחלה ריקה או באפליקציה שכבר הוטמעה (או בין אם בשלב כלשהו), ניתן לבדוק את קוד JavaScript בצורה פשוטה, נקייה ויעילה. קוד שלא ניתן לבדוק ייכתב מחדש.
אמנם JavaScript הוא ייחודי בשל מגוון הסביבות שבהן הוא פועל, אך יש כמה שיטות 'אמיתיות' שניתנות לבדיקה משפות אחרות. וכמובן, עדיין יש את האתגרים הייחודיים שעומדים בפני מפתחי JavaScript בזמן שהם כותבים ובודקים את הקוד שלהם.
אילו תבניות גורמות לקוד לבדוק? אילו אנטי-תבניות מונעות את הבדיקה? באילו מדדים ומדריכי הדרכה הגיוניים נוכל להשתמש כדי למדוד את הקוד שניתן לבדיקה? אחרי שהתחיל תהליך של יצירת קוד שניתן לבדוק, מה?
אני רוצה להצטרף אליי כדי להסביר את תהליך הכתיבה של JavaScript שניתן לבדוק. אנחנו נבדוק רעיונות, תבניות ומתודולוגיות שמגדילות באופן משמעותי את מידת יכולת הבדיקה, וכתוצאה מכך גם את הקיימוּת, התקינות ומשך החיים של הקוד. גם אם אתם כותבים JavaScript בצד השרת או בצד הלקוח, תוכלו לשפר משמעותית את איכות הקוד.
שבר את המטריצה – בדיקות Android בקנה מידה רחב
תומאס קיין (Google), שטפן רמסואר (Google) ווולרה זכרוב (Google)
מוכן להשתמש בכדור האדום?
הנייד שינה את הדרך שבה בני אדם מקיימים אינטראקציה עם מחשבים. זה נהדר, אבל בתור המהנדסים שלנו, אנחנו נתקלים במטריצת סביבה שהולכת וגדלה שהקוד שלנו פועל בה. הימים שבהם מביאים בחשבון רק כמה דפדפנים ורזולוציות מסך לא חוזרים. איך מהנדסים יכולים להתמודד עם המטריצה? נסביר איך Google נאבקת בבעיית הבדיקה הזו בתחנות עבודה, בענן ובראשכם...
"אני מנסה לשחרר את דעתך, נאו. אבל אוכל להראות לך רק את הדלת. אתם צריכים לעבור את זה".
אוטומציה של ממשק המשתמש ב-Android
גואנג ז'ו (朱光) (Google) ו-אדם מומטז (Google)
ככל ש-Android צובר פופולריות בעולם הנייד, מפתחי אפליקציות וספקי OEM (יצרן ציוד מקורי) בוחנים דרכים לביצוע בדיקות מקיפות של ממשק המשתמש באפליקציות או בכל הפלטפורמה. אחרי שסקרנו בקצרה את פתרונות האוטומציה הקיימים של ממשק המשתמש ב-Android, ריכזנו כאן הסבר על מסגרת האוטומציה של ממשק המשתמש ב-Android שפורסמה לאחרונה, וממשיכים לספק מבט פנימי על המסגרת, תרחישים לדוגמה ותהליכי עבודה.
Appium: אוטומציה של אפליקציות לנייד
Jonathan Lipps (Sauce Labs)
Appium הוא שרת Node.js שמבצע אוטומציה של אפליקציות לנייד היברידיות (היברידיות ו-iOS). הפילוסופיה של אפיום מציינת שאין לשנות אפליקציות כדי שיהיו אוטומטיות, וכי יש צורך לכתוב את קוד הבדיקה בכל שפה או מסגרת. התוצאה היא שרת Selenium WebDriver שמדבר כמו בנייד באופן טבעי. Appium פועל באמולטורים אמיתיים ובאמולטורים, והוא מקור פתוח לחלוטין, כך שהוא דרך נהדרת להתחיל לעבוד עם אוטומציה של בדיקות בנייד. בשיחה הזו אפרט את העקרונות המנחים את העיצוב של אפיום, נדון על אפום במרחב של מסגרות אוטומציה אחרות בנייד, ונציג את הארכיטקטורה שמעודדת את הקסם. לבסוף, אתעמק בקוד כדי לבצע בדיקה פשוטה של אפליקציה חדשה לנייד, ואדגים שבדיקת האפליקציה פועלת ב-iPhone וב-Android.
יצירת תשתית לבדיקה מותאמת לניידים ב- Google+ לנייד
אדוארדו בראבו (Google)
בדיקה של אפליקציות מקוריות בצורה משמעותית, יציבה וניתנת להתאמה היא אתגר. צוות G+ פיתח פתרונות יעילים לטיפול בבעיות האלה. לשם כך, הוא מספק את התשתית המתאימה לכל אחד מתרחישי הבדיקה המורכבים שמוצגים בניידים. תשתית הבדיקות הנוכחית שלנו מספקת את הכלים הנכונים לאפליקציות ל-iOS ול-Android, כדי לאפשר לצוות הפיתוח שלנו לדעת ששינויים חדשים לא יגרמו לכשלים לקוחות קיימים.
אספרסו: התחלה חדשה לבדיקות ממשק המשתמש ב-Android
Valera Zakharov (Google)
פיתוח בדיקה אמינה של Android צריך להיות מהיר ופשוט כמו שליפת שוט אספרסו. לצערנו, בעזרת כלים קיימים יכול להיות שתרגישו יותר כמו לצלם רוטב קרמל-רוטב הפוך, הפוך, עם חטיף-אלקטר - מבלבל ונדיר. Espresso היא מסגרת בדיקה חדשה ל-Android שמאפשרת לכתוב ניסויים תמציתיים, יפים ואמינים בממשק המשתמש. ממשק ה-API הבסיסי הוא קטן, ניתן לחיזוי וקל ללמידה, אך הוא גם פתוח להתאמה אישית. בבדיקות אספרסו מוצגים בבירור הציפיות, האינטראקציות והטענות שלהם בלי להסיח את הדעת, פרטים לגבי תשתית מותאמת אישית או פרטים ממושכים של הטמעה מפריעות. הבדיקות רצות בצורה אופטימלית – פשוט משאירים את ההמתנה, הסנכרון, השינה והסקרים ברקע, ומאפשרים למסגרת לפעול בחינניות ולהגיש תלונה על ממשק המשתמש במצב מנוחה. רוצים להתחיל לכתוב ניסויים ולבצע פעולות בממשק המשתמש? כדאי לנסות את אספרסו.
בדיקת ביצועי אינטרנט עם WebDriver
מייקל קליפיקקוב (Google)
בבדיקת הביצועים באינטרנט, אנחנו יודעים איך לנתח את טעינת הדף. עם זאת, עלינו להתקדם מעבר לטעינת דף: אפליקציות מודרניות הן אינטראקטיביות מאוד, ופעולות נוטות לא לטעון מחדש את כל הדף, אלא לעדכן אותן. אנשים שונים, בעצמי, שילבו את WebDriver ברתמות בדיקת ביצועים באינטרנט, וזה עוזר, אבל עדיין להפריד בין בדיקות ביצועים לשאר חבילות הבדיקה של ממשק המשתמש. ההצעה שלי היא לפתח תכונות של בדיקת ביצועים ישירות ב-WebDriver עצמו, כדי להשתמש ב-Logging API. כך תוכלו לאסוף מדדי ביצועים במהלך הרצה של בדיקות פונקציונליות רגילות, ולשלב בצורה חלקה יותר את בדיקות הביצועים בשלבי הפיתוח והבדיקה הכוללים. הוא גם הרבה פחות מפריע לשרשראות הכלים של build/בדיקה בהתאמה אישית, שכמעט כל ארגון גדול יוצר.
אני רוצה להדגים את זה ב-ChromeDriver החדש (WebDriver בדפדפן Chromium).
בדיקות נתונים רציפות של מפות Google
Yvette Nameth (Google) ו-Brendan Dhein (Google)
בדיקות שוטפות מבוססות בדרך כלל על הרצת בדיקות של יחידה ובדיקות אינטגרציה. אבל כאשר הנתונים שהשרת שלך מעבד הם אכן הגורם הגדול ביותר לשינוי, כיצד אתם מבטיחים שצרכנים של הנתונים עדיין יוכלו להשתמש בהם, וששום דבר לא יקרוס בקצב של שינוי או שינוי שגוי? במאמר מתוארות מפות Google בנושא טכניקות לבדיקת נתונים רציפים.
איתור אשמים אוטומטיים בבניינים שנכשלו - כלומר, מי פרץ את ה-build?
Calal Ziftci (UCSD) ו-Vivek Ramavajjala (UCSD)
פיתוח רציף הוא אחת מתשתיות המפתח של Google. כשגרסאות build נכשלות, חשוב לאתר במהירות את רשימת השינויים העיקריים (CL)/רשימות השינויים, כדי שאפשר יהיה לתקן אותן כך שהפרויקט יחזור לירוק.
יש פתרונות לגילוי הפרות של גרסאות build קיימות, קטנות ובינוניות, אבל לא עבור גרסאות build גדולות לשילוב.
הכלי שלנו לאיתור אסימונים מתמקד באיתור אוטומטי של חומר ה-CLV המשמש לבניית גרסאות build גדולות, תוך זמן קצר מאוד. על סמך שימוש בסביבת ייצור במספר פרויקטים ב-9 החודשים האחרונים, הכלי איתור הפרות מוביל לתוצאות מבטיחות מאוד. אנחנו רוצים לדבר על זה. רוצים לראות איך הטמענו את כלי איתור האחים, עד כמה הוא מצליח בייצור ואיך הוא נראה?
חקירה אימפריאלית של איכות קו המוצרים של תוכנה
קטרינה גוסבה-פופוסטג'נובה (אוניברסיטת וירג'יניה המערבית)
קווי מוצרים של תוכנה מציגים מידה רבה של קושי משותף בין המערכות בקו המוצרים, ומספר מוגדר היטב של וריאציות אפשריות. על סמך נתונים שנלקחו משני מקרים לדוגמה – קו מוצרים תעשייתי בגודל בינוני וקו מוצרים גדול ומתפתח בקוד פתוח – בדקנו לעומק אם השימוש החוזר השיטתי משפר את האיכות ותומך בחיזוי מוצלח של כשלים עתידיים שמקורם בשגיאות קודמות, במדדי קוד מקור ובמדדי שינויים. תוצאות המחקר שלנו אישרו, שבהגדרת קו מוצרים של תוכנה, יש מתאם גבוה יותר בין הממצאים של פגמים אחרים לבין שינויים במדדים לעומת מדדי קוד סטטיים. תוצאות ההערכה של האיכות הראו שאף על פי שהחבילות הישנות (כולל תחומי עניין משותפים) השתנו ללא הרף, הן שמרות צפיפות פיקסלים נמוכה. בנוסף, קו המוצרים בקוד פתוח השתפר באיכותו כשהתפתח עם גרסאות. החיזוי מבוסס על מודלים של רגרסיה לינארית כללית, והוא דירגת בצורה מדויקת את החבילות בהתאם לפגמים שלהן שהושקו לאחר השקת המודל. התוצאות גם חשפו שתחזיות לגבי תקלות לאחר השקה נהנות מפרטי מידע נוסף על קו המוצרים.
addressSanitizer, ThreadSanitizer ו-MemorySanitizer -- כלי בדיקה דינמיים עבור C++
Kostya Serebryani (Google)
AddressSanitizer (ASan) הוא כלי שמאפשר לאתר גלישת חוצץ (בערימה, ערימה וגלובליים) ובאגים לאחר השימוש בתוכניות C/C++. ThreadSanitizer (TSan) מוצאת מירוצי נתונים בתוכניות C/C++ ו-Go. MemorySanitizer (MSan) הוא כלי בתהליך חיפוש המבוסס על שימוש בזיכרון שלא אותחל (C++ ). כלים אלה מבוססים על אינסטרומנטציה מהדר (LLVM ו-GCC), שגורמת להם לפעול במהירות גבוהה מאוד (למשל, Asan צורכת האטה פי 2 בלבד). נשתף את הניסיון שלנו בבדיקות בקנה מידה רחב באמצעות הכלים האלה.
נאום הפתיחה – שתיית האוקיינוס – חיפוש XSS בקנה מידה של Google
Claudio Criscione (Google)
סקריפטים חוצי-אתרים, או XSS, הם המקבילה המודרנית של המגמה השחורה של ימי הביניים בעולם של אפליקציות אינטרנט: זהו תופעה נפוצה, היא גרועה ואין הרבה דרכים טכניות לזהות אותה עד שיהיה מאוחר מדי. DOM XSS הוא וריאציה כזאת במיוחד, כי יש צורך להשתמש בדפדפן אמיתי או בדפדפן דומה: בעיה בעייתית עם מעט פתרונות אוטומטיים זמינים.
היה לנו צורך בכלים חזקים ומבוססים ללמידה עצמית כדי לזהות את DOM XSS בשלב מוקדם במחזור החיים של הפיתוח. המהנדסים, שלא היו רשומים בצוות האבטחה, היו יכולים להשתמש במוצר הזה: כל מה שחיפשנו הוא מוצר שיכול לסרוק את מאגר הכלים העצום והמהיר שלנו, המורכב ממגוון רחב של אפליקציות... וכמובן, לא מצאנו. לכן בנינו את הסורק שלנו: סורק אפליקציות אינטרנט שמטרגט DOM XSS שעוצב בנוסף לטכנולוגיות סטנדרטיות של Google. הוא פועל ב-App Engine ומנצל את דפדפן Chrome העוצמתי וכמה מאות מעבדים של מעבדים כפלטפורמה לסריקת אבטחה.
היא גם אזרחים נחמדים של מחסן הבדיקות של Google: היא נמצאת בתוך תשתית הבדיקות שלנו, במקום לשמש ככלי צוות האבטחה.
בשיחה הזו אנחנו מתארים את הגישה החדשנית שלנו, עם האתגרים שמולנו התמודדנו עם התאמת המערכת לגודל Google, ואת הרעיונות שעומדים מאחורי המודלים שלנו לזיהוי וסריקה באפליקציות אינטנסיביות של JavaScript.