הערות פתיחה
Tony Voellm (Google)
קישורים: סרטון
נאום פתיחה – ההתפתחות מאבטחת האיכות ועד הנדסת הבדיקות
Ari Shamash (Google)
יצרת אפליקציה. הפעלת אותה. החלטתם להוציא את הסכום הזה, להגדיל את הנפח, לקבל מימון, להשליך אותו, ואז להתחיל מאפס כדי שתוכלו "לעשות את זה כמו שצריך". עם זאת, הביקוש לפיצ'רים חדשים גבוה מאוד, ונכון לעכשיו, אתם מתבקשים להתקדם בהיקפים חסרי תקדים בקצב שלא נראה למציאות. אוי! מה עכשיו?
אי אפשר לוותר עליו ולהתחיל מחדש, פשוט צריך לפתח את מה שרוצים, ולהמשיך להוסיף תכונות איכותיות במהירות עוצרת נשימה. בנוסף, חשוב לוודא שהתוכן שכבר מופיע בו לא נשבר. איך עושים את זה? למרבה המזל, שדה חדש נוצר בתעשיית הנדסת התוכנה ומתייחס לתרחיש הנפוץ הזה: אנחנו ב-Google מכנים זאת "הנדסת בדיקות".
ההרצאה הזו תתמקד מהי הנדסת בדיקות, איך היא התפתחה מהבטחת איכות, ואיך התעשייה כולה הטמיעה הנדסת בדיקה (עם דוגמאות ספציפיות לאופן ההטמעה ב-Google).
מערכות בדיקה בהיקף רחב @Twitter
James Waldrop (Twitter)
ג'יימס ידבר על הכלים, התהליך והפילוסופיה שבודקים את הביצועים ב-Twitter. דגש מסוים יוצב בספריית הבדיקה של הקוד הפתוח של Iago, אשר כתבה כדי לאפשר לצוותי ההנדסה של Twitter לבצע בדיקות טעינה לפני פריסת הקוד לייצור. בדיון נדון בפרטי ההטמעה של חלק מהבדיקות האלה (כולל קוד המקור) ועל האופן שבו מנוהלים גורמים שונים, כמו פרוטוקולים של OAuth ו-Thrift שרירותי.
איך בודקים מערכת הפעלה לנייד?
דייוויד ברנס (Mozilla) ו-Malini Das (Mozilla)
זו הבעיה שבה נתקלנו ב-Mozilla, כאשר החלטנו לצאת לעולם של FirefoxOS. איפה כדאי להתחיל ואיך לעשות זאת, כדי להוכיח שהמשימה מעניינת. נשמח לשמוע איך פתרנו את הבעיה הזו ואיך יצרנו מסגרת חדשה.
אוטומציה לנייד בצינור עיבוד נתונים לפיתוח רציף
איגור דורובסקי (Expedia) ו-Kaustubh Gawande (Expedia)
בתחילת 2012, Expedia התחילה להשקיע באפליקציות לנייד ו-iOS ו-Android. במקביל, מהנדסי הבדיקה התחילו לפתח פתרונות לאוטומציה של בדיקות כדי לבנות מוצרים איכותיים ויכולת בדיקה בתוך המוצרים. בשיחה הזו נשתף את הניסיון והלמידה שלנו לגבי שימוש בכלים של קוד פתוח כדי ליצור בדיקות אוטומטיות בסביבת Agilia לפיתוח ולפיתוח רציף. נדבר על פירמידת הבדיקה ונפרט יותר על כלים ספציפיים של קוד פתוח שהניבו תוצאות טובות. חלק מכלי הקוד הפתוח שבהם אנחנו משתמשים הם כלי BDD כמו כלי הקיטור, כלי האוטומציה של האינטרנט Selenium-WebDriver, הכלי לאוטומציה של iOS פרנק, כלי האוטומציה ל-Android Robotium ו-Calabash, ו-Continuous Integration System (ג'נקינס). בנוסף, נשתף כמה מהעקרונות של Agile מפורסמת, כמו TDD, צמד תוכניות, בנייה ובדיקת רדיאטורים. לבסוף, נסביר על כמה מהיתרונות שמימשנו מההשקעה שלנו ב-Agile וביצענו בדיקות אוטומציה, והסברנו איך אנחנו מגיעים ליעדים של פיתוח רציף (continuous delivery).
בדיקות אוטומטיות לממיר עם GStreamer ו-OpenCV
David Röthlisberger (YouView)
נבנה מערכת לזיהוי תמונות לצילום סרטונים בתוך 3 דקות, באמצעות כלי שורת הפקודה ו-OpenCV של GStreamer. (GStreamer היא מסגרת בקוד פתוח לטיפול במדיה. OpenCV - "Open Computer Vision" - ספריית קוד פתוח לעיבוד תמונות.)
דוגמה בולטת למערכת כזו היא http://stb-tester.com, כלי בקוד פתוח שפותח ב-YouView כדי להפוך את בדיקת הממשק של הממירים שלנו לאוטומטית. נתאר את ה-STB-tester, את הגמישות שאפשר לקבל מהתשתית של GStreamer ואת היתרונות שלה, ואת האתגרים שבבסיסם.
קישורים: סרטון
מנהל התקן של Chrome
Ken Kania (Google)
Chrome פועל כדפדפן Windows בלבד והתרחב ל-Mac, ל-Linux, ל-ChromeOS, ולאחרונה גם ל-Android ול-iOS. היה קשה לבצע בדיקות ברמת המשתמש של יישומי האינטרנט בפלטפורמות האלה, ונדרשת גישות שונות לאוטומציה. לדבר זה תתאר את העבודה שצוות Chrome עושה כדי ש-WebDriver יהיה זמין ל-Chrome בכל הפלטפורמות. השינוי יכלול בדיקה טכנית של הגישה הבסיסית, אך יתמקד באופן שבו מפתחים יכולים להשתמש ב-ChromeDriver החדש כדי לכתוב בדיקות לפלטפורמות השונות של Chrome. בנוסף, נשקף את מצב הפרויקט הנוכחי ומפת דרכים לעתיד שלו.
קארמה – Runner Test עבור JavaScript
Vojta Jina (Google)
מבוא לקארמה – מפעיל בדיקות שהופך את בדיקות ה-JavaScript בדפדפנים אמיתיים למהנות וקלות.
לא חובה לבצע בדיקה כשבונים אפליקציית JavaScript שחייבת לעבוד בדפדפנים ובמכשירים רבים. עם זאת, קשה לבצע בדיקות בכל הסביבות השונות. קארמה הופכת את המשימה בדרך כלל קשה לעוגה. היא מאפשרת לכם להריץ בדיקות JavaScript בדפדפנים או במכשירים אמיתיים, כמו הטלפון או הטאבלט, ישירות מהמסוף או מה-IDE המועדף עליכם.
קישורים: סרטון
מדידות אוטומטיות של איכות וידאו
Patrik Höglund (Google)
כן, אפשר לבדוק באופן אוטומטי מדידות סובייקטיביות ומורכבות, כמו איכות הסרטונים. בדיון הזה נדגים איך בנינו בדיקה אוטומטית רציפה מקצה לקצה של שיחת וידאו ב-WebRTC. נבדוק את הכלי הזה ברמה גבוהה ואת האתגרים שבהם נתקלנו במהלך הבנייה. זו אפשרות מושלמת אם אתם רוצים לקבל רעיונות לשיפור בדיקת המדיה שלכם.
מה קורה כשאנחנו נתקלים באפליקציות לא רצויות...
מינאל מישרה (Netflix)
עולם המחשוב של המכשירים הניידים זינק את תעשיית התוכנה באמצעות פלטפורמות לפיתוח אפליקציות. פיתוח אפליקציות לצרכנים בפלטפורמות מחשוב מאפשר למשתמשי הקצה שלהם חוויה קסומה משלהם. חברות שעוסקות בתוכנה הפונה לצרכנים תמיד משתדלות להתאמץ כדי לפתח אפליקציה לפלטפורמות האלה. עם זאת, האתגר הגדול ביותר בפיתוח אפליקציות הוא רק לאחר שחברות משיקות את הגרסה הראשונה של האפליקציה. הצרכנים וחברות התוכנה רוצים לפתח את התכונות והפונקציות החדשות בהקדם האפשרי, באיכות הגבוהה ביותר. הדבר מוביל לנטישה קבועה של קוד בכל שכבת המחסנית. אנחנו, מהנדסי אוטומציה בממשק המשתמש, בונים מגוון מערכות זיהוי כדי לזהות בעיות באפליקציות בשלב מוקדם יותר. בשיחה הזו אשתף כמה מהאתגרים וההצלחות שלנו מאחורי מערכת זיהוי אחת כזו, שעזרה באיתור בעיות מחוץ לשכבת האפליקציה, אבל עדיין השפיעה לרעה על חוויית המשתמש.
בדיקה לגיימינג חינוכי וגיימינג חינוכי לבדיקות
טאו שיה (האוניברסיטה של מדינת קרוליינה הצפונית)
דיון זה מציג את Pex4Fun (http://www.pexforfun.com/), שבו נעשה שימוש ביצירת בדיקות אוטומטיות כדי לאפשר מתן ציונים באופן אוטומטי במערכת תכנות וירטואלית שמתאימה למאות אלפי משתמשים. הוא מספק חוויית גיימינג מוכוונת מחוץ לכיתה, ומלמד את המשתמשים ללמוד מיומנויות שונות של תכנות והנדסת תוכנה, כולל מיומנויות כמו כתיבת בדיקות של יחידות עם פרמטרים. Pex4Fun תורם באופן משמעותי לבעיה המוכרת למתן ציונים, וכן מספק חוויית למידה מהנה המבוססת על משחקים אינטראקטיביים. Pex4Fun זוכה לפופולריות רבה בקהילה: מאז השקתו ביוני 2010, מספר הקליקים על הלחצן 'שאל פקס!' (המציין את הניסיונות של המשתמשים לפתור משחקים ב-Pex4Fun) הגיע ליותר ממיליון מקומות בתחילת 2013.
נאום פתיחה - איך Facebook בודקת את Facebook ב-Android
סימון סטיוארט (Facebook)
Facebook היא אחת מהאפליקציות הפופולריות ביותר ב-Android. בשיחה הזו, נדבר על כל מה ש-Facebook עושה כדי שכל גרסה תהיה טובה ככל האפשר. נעסוק בכל מה שקשור לאופן שבו אנחנו מנהלים את הקוד, החל מגישות הבדיקה שלנו ועד לשלב של ניסוי המוצר לפני הפצה (dogfood).
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)
עדכון [אוקטובר 2013]: אספרסו הוא קוד פתוח. מידע נוסף זמין בכתובת https://code.google.com/p/android-test-kit/.
פיתוח בדיקה אמינה של 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 (Google)
פיתוח רציף הוא אחת מתשתיות המפתח של 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.