למרות ניסיוני בתחום המובייל, אני חושב שתמיד טוב להתעדכן ולשמוע מה אחרים חושבים וללמוד מניסיונם. לשם כך קראתי את הספר הזה: Hands-On Mobile App Testing והחלטתי לשתף כמה מהדברים החשובים ממנו. בסוף המאמר ארשום את דעתי הכללית עליו.
מי שרוצה רק רשימת בדיקה מוזמן לקפוץ ל-מה צריכות הבדיקות לכלול ומי שמעוניין רק באוטומציה יחפש אוטומציה.
מי שרוצה רק רשימת בדיקה מוזמן לקפוץ ל-מה צריכות הבדיקות לכלול ומי שמעוניין רק באוטומציה יחפש אוטומציה.
מה השוני בין מוצרים אחרים למוצרי מובייל?
1. הציפיות של המשתמשים הן גבוהות הרבה יותר במובייל. ביצועים, פשטות השימוש, אמינות ואסתטיקה חשובים כאן הרבה יותר מאשר באפליקציית PC או בדפדפן. מידע חשוב בנושא ניתן למצוא כאן.
2. המשתמשים זזים ממקום למקום. יש לבדוק את האפליקציה בסביבה האמתית שבה משתמשים בה. נתונים סביבתיים כמו מזג אוויר עשויים להשפיע.
3. יש להתחשב במקרים בהם האינטרנט נפסק או איטי ובמעבר בין שתי האפשרויות, מעבר בין ספקים ועוד.
על הסביבה - מכשירים ומערכות הפעלה
אפליקציות באנדרואיד מפותחות בג'אווה. ב-iOS הן מפותחות ב-swift ו Objective C.
יש 3 סוגי אפליקציות:
- אפליקציות נייטיב - נכתבו בשפה שבה אפליקציות בנויות על המכשיר (נניח ג'אווה באנדרויד). כך קל יותר לאפליקציה להשתמש במשאבי המערכת ובפיצ'רים שלה.
- הייבריד: גם בשפה של מערכת ההפעלה וגם בטכנולוגיות ווב כמו HTML ו-Java Script.
- אפליקציות ווב: מורצות ע"י דפדפן.
השוני בבדיקות מובייל והקושי שלהן:
fragmentation - המספר (הרב) של קומבינציות בין מע' הפעלה למכשירים. במובייל לא מדובר על מספר יחסית קטן של אפשרויות בניגוד למשל לבדיקות אתרים.
אז איך בכ"ז לבחור אילו מכשירים לבדוק?מתחשבים בקהל היעד - user base:
גיל,
כמה גברים ונשים בקבוצת היעד שלי,
איזו פלטפורמה הכי נפוצה בקהל היעד,מכשיר הכי נפוץ,
איזו גרסת OS מצויה אצל רוב הלקוחות,
באילו אילו סנסורים המכשיר משתמש,
דרכי התקשורת החיצונים של האפליקציה,
הדרכים העיקריות לשימוש באפליקציה.
בכדי לבדוק לפי שימוש קהל היעד כדאי:
לקבל מידע על המשתמשים,
לבצע בדיקות יוזביליות עם הלקוחות,
לראיין לקוחות,
בטא,
ביקורות שאנשים פרסמו בסטור.
בכדי לעמוד בקצב הפרגמנטציה יש:
לעקוב אחרי שוק המכשירים ומערכות הפעלה,
לדעת מתי יש גרסאות חדשות,
להיות מעודכן בפיצ'רים החדשים של מערכת ההפעלה,
לעקוב אחרי מה שהמשתמשים שלך משתמשים,
לחשוב פעמיים לפני שדרוג מכשיר,
לקנות או לשכור טלפונים חדשים עם מערכת הפעלה חדשה,
לבדוק מכשירים חדשים, חדשים עם מערכות הפעלה ישנות ועוד. אפשר להשאיר טלפון עם מערכת ישנה ולקנות את אותו אחד שכבר בא עם חדשה.
אחד מהדברים החשובים בשלם בודקים את הפרגמנטציות הוא לוודא שה-UI לא משתנה ומשנה את התנהגות האפליקציה
.
אבל יש גם דברים אחרים כמו אפליקציות פנימיות של ספקים שעלולות להפריע, השוני בחומרה . OS יכול להביא אפילו לקראש בטלפון אחד ולא באחרים וכד'.
אפשר לשכור מכשירים או מעבדות מבוססות ענן כל עוד מדובר גם במכשירים אמתיים.
על אתר המספק מעבדות מבוססות ענן לספק:
מכשירים אמתיים,סימולטורים ואמולטורים,מכשירים שאינם "רוטד",אפשרות בדיקה על פלטפורמות שונות,כתיבת טסטים אוטומטיים,תמיכה ב-CI,ניטור ביצועים,יצירה של דוח בדיקות בסוף התהליך,לוודא שיש רק לך גישה למכשירים והם יפורמטו בסוף השימוש. דוגמאות לספקים:
איך לבדוק:
אמולטורים: הרצה על PC ע"י תרגום הוראות ההרצה בצורה כזו שהמחשב "יבין". האמולטור מתנהג בדיוק כמו שהחומרה של המכשיר וה-OS שלו.
סימולטורים: פחות מורכבים מאמולטורים והם מדמים רק סבסט או חלק מהתנהגות המכשיר והחומרה. כיוון שהם מדמים חלקית, הם מהירים יותר מאמולטורים אך אי-אפשר לבדוק איתם חומרה ספציפית של מכשיר. סימולטורים יעילים בעיקר בתחילת הפיתוח לפידבק מהיר.
אבל הבדיקה הטובה ביותר היא במכשיר אמתי עם סנסורים ויכולת תנועה.
אוטומציה או ידניות?
רק אוטומציה זה לא מספיק וחסרים דברים כמו דטה של מיקום ספציפי (?) או סנסורים. גם רק בדיקות ידניות זה לא תמיד מספיק אלא אם האפליקציה בסיסית וזמנית. בד"כ צריך שילוב של השניים. עדיף להתחיל בבדיקות ידניות.
מה צריכות הבדיקות לכלול:
סנסורים:
הבדיקות צריכות לבדוק גם אם האפליקציה משתמשת נכון בסנסורים מה קורה אם הסנסורים אינם פועלים במכשיר.
סנסורים יכולים למדוד:
- כמות אור בחדר,קרבה למכשיר,שינוי בתנועת המכשיר, כולל הפיכה מפורטרייט ללנדסקייפ,
- גירוסקופ,
- סנסור מגנטי, למשל למצפן,
- לחץ אוויר, טמפרטורה ולחות,
- GPS,
- מסכי נגיעה,זיהוי מחוות מבלי לגעת במכשיר.
האפשרויות של מסך הנגיעה
כדאי לבדוק נגיעה במסך בזמן שכמה אצבעות כבר נוגעות במסך, מעבר ממחווה למחווה ולבדוק ביצועים. גם מזג אוויר שונה עשוי לשנות את תוצאות הבדיקה.
ראו קטע מהספר:
שימוש במיקרופונים.
מצלמה.
אפליקציות מערכת:
הרבה מחליפים את אפליקציות המערכת בכאלה טובות יותר, למשל הקלידים. זה אומר שכדאי לבדוק את האפליקציה עם כמה כאלה ולוודא למשל שעדיין רואים את ה-UI בצורה טובה. אם האפליקציה שלך צורכת אפליקציות מערכת עליך להכיר תחליפים פופולריים ולבדוק אותם על האפליקציה שלך.
יש לבדוק i16n l10n
ראו כאן.
יש לזה השפעה (מערכת) על ה-UI.
גודל האותיות, הפורמט של הזמנים. מה קורה אם יש בטלפון שפה לא נתמכת - האם האפליקציה תשתמש בשפה הדיפאולטיבית?
אם המוצר משתמש באלמנטים של דפדפנים יש לבדוק עם הדפדפנים הנפוצים.
יוזביליטי - מבחר מקורות:
יש סעיפים מעניינים על יוזביליטי כולל התחשבות במקרי אקססביליטי לאנשים עם לקויות.
צריכת הסוללה
חשוב לבדוק את צריכת הסוללה של האפליקציה שלך.
בדיקה אחת היא במכשיר "נקי" לפתוח את האפליקציה ובזמן שהיא נראית בטלפון להניח אותו שיעבור ל-standby (כלומר ריצה ב-foreground). יש לבדוק על מספר מכשירים. יש לבדוק ריצה ב-background. בדוק את מצב הסוללה במכשיר מדי פעם.
יש לבדוק מצבי סוללה בזמן שימוש ביכולות של הטלפון כמו GPS. יש לוודא שהאפליקציה מפסיקה להשתמש בהם כשהיא לא צריכה אותם יותר.
בדיקת של תקשורת מיותרת. ניתן לבדוק עם:
או
בדיקה אחרת היא כשלסוללה יש 10-15%. המכשיר עשוי לסגור אוטומטית כמה פיצ'רים. איך האפליקציה עובדת אז? אפשר ליזם שימוש בפיצ'ר של המכשיר לשמירה על הסוללה.
איך ההתנהגות אחרי ריקון הסוללה? האם אבד דטה?בדיקה של מה קורה לאפליקציה בזמן תהליך של ריקון ומילוי סוללה.
בכדי לבדוק אפשר להשתמש בפיצ'רים פנימיים של המכשירים אבל יש גם כלי מדידת ביצועים חינמי.
אחרי הפרסום בפייסבוק Ronny Relin הוסיף עוד מידע חשוב הנושא שאינו מכוסה בספר:
קודם כל הכלי battery historian שהוא בעיני רוני הכלי הכי חשוב לבדיקות צריכת סוללה אינו מוזכר כלל. רוני אומר: "מדובר בסקריפט של פייטון שיודע להמיר המון מידע לתצוגה. המידע נשלף בעזרת כמה פקודות adb ואז יש כמה אפשריות להשתמש בסקריפט. זה הדבר הכי אמין וחשוב לבדיקת סוללה. יש שם מידע הכי רלוונטי מה גורם לבזבוז המשאבים."
בנוסף חסרות בדיקות, למשל: "אם תבצע את הבדיקה על מכשיר חדש שנטען פעם אחד או על מכשיר ישן שכבר הוטען מאות פעמים התוצאה תהייה שונה ולא תדע למה".
תודה עבור התוספות!
סטרס ואינטראפציות
אינטראפציות יכולות להיות:
קבלת הודעות,
שיחות,
הודעות מערכת (אינטראפציות של תוכנה),
לחיצה על כפתורים (אינטראפציות של חומרה).
כלי טוב לעזור בבדיקות אלה ע"י יצירה של אינטראפטים ניתן למצוא כאן.
ל-iOS ניתן להשתמש בכלי זה.
כדאי גם לעקוב אחרי ביצועי הסוללה בזמן הסטרס.
ביצועים - דגש בעיקר על הצד הבקאנדי.
בדיקות של מעבר ל-standby וחזרה, בחזור על האפליקציה להיות מעודכנת. יש לבדוק מה קורה אם אין תקשורת.
האם המכשיר מתחמם?
יש לוודא שסגירה סוגרת את הפרוססים.
בדיקות התקנה
התקנה על זיכרון פנימי וגם חיצוני, אינטרנט ו-WiFi ושינוי תוך כדי התקנה, סגור תקשורת, לעבור לאפליקציות אחרות בזמן ההתקנה, מה קורה אם אין מספיק מקום, התקנה דרך כבל או סנכרון.
בדיקת הסרה - אכן הכל הוסר. חשוב כי אתה לא רוצה שאם אתה מעביר את המכשיר למישהו ישמרו שם דברים מסוימים.
בדיקות עדכון
מי שלוגד-אין צריך להישאר מחובר,מידע קיים צריך להישמר,
הסטייט של האפליקציה צריך להישמר,הבדיקות צריכות לסמלץ עדכון מהסטור (יש הסבר על איך לסמלץ את זה).
בדיקות בסיס נתונים
SQLite במקרה זה. כדאי לבדוק אינטגריטי בזמן עריכה, עדכון או מחיקה של מידע. יש לבדוק ולידציה של בסיס הנתונים, אינטגרציה, ביצועים, פונקציונליות של הפרוצדורות, טריגרים, יצירה-קריאה-עדכון-מחיקה, שינוי הנתונים משתקף למשתמש, חיפוש ואינדקסים, סקיוריטי, ובדיקה לצורך מיגרציה של נתונים.
אכסון פנימי של המכשיר
לכל מכשיר יש אכסון פנימי המיועד לאפליקציות, תמונות, מוזיקה ועוד. חלק מהמכשירים תומך באכסון חיצוני.
בדיקות אלה יכללו בדיקה של האפליקציה כאשר: האכסון הפנימי מלא, האכסון הפנימי מלא אך יש מעט מקום בחיצוני ולהפך, שניהם מלאים, האכסון הפנימי כמעט מלא ואנו שומרים מידע באפליקציה עד שהוא מתמלא, הוצאת האכסון החיצוני, האכסון הפנימי ריק (לא חושב שיש מצב כזה ד.ב.).
סקיוריטי
רשימת כלי בדיקה בנושא אפשר למצוא כאן.
עדיף להשתמש במומחים, אך אנו יכולים לבדוק כמה דברים: קאש לא משאיר מידע חשוב כסיסמאות והוא נמחק כל כמה זמן, כנ"ל לגבי מה ששומרים באכסון, שמידע חשוב מוצפן, וידוא הסיסמא נעשה בצד השרת, המידע בין הקליינט לשרת מוצפן, שימוש בהרשאות לא נחוצות של המכשיר.
כדאי להישאר מעודכן על המפורסם באתר ולראות מה קורה היום מבחינת סיכונים.
רזולוציות ו-densities.
רשתות שונות
(LTE, 3G, EDGE, GPRS, WiFi)Airplane mode
סגירת תקשורת בעת תקשורת לשרת, אח"כ פתיחת תקשורת ורפרוש
ספקים שונים
חתימות נכונות
יוריסטיקות למובייל:
SFDEPOT
FCC CUTS VIDS
I SLICED UP FUN
COP FLUNG GUN
מיינדמפ
או
הקישור בספר אינו נכון, אגב.וגם:
עוד על איכות של מובייל:
לגבי הדברים שאינם מיוחדים למובייל (מיקום, סנסורים וכד') כדאי לבדוק כמו בדיקות של PC.
אוטומציה
בדיקות אוטומטיות אינן עובדות לפי הפירמידה כיוון שכאן כאמור יש צורך בהרבה בדיקות ידניות של גיאו וכד'. גם כמות בדיקות היחידה הוא מועט כיוון שיש הרבה גורמים תלויים אחד בשני וקשה לסמלץ אותם.
לכן הפירמידה המפורסמת שונה בבדיקות מובייל מול בדיקות אחרות (למשל ראו כאן):
למרות שהאוטומציה במובייל אינה מושלמת היא מאוד חשובה לפידבק מהיר.לפני שבוחרים כלי כדאי להבין את הצרכים.
יש כלים שמשווים תמונות מסך. זה חוסך זמן בדיקות אך תחזוקת בדיקות כאלה היא יקרה (שינויי מיקום רזולוציה וכד'). שפות שונות לא יעבדו.
כלים להשוואת תמונות:
יש כלים לזיהוי ע"פ קואורדינטות:
זיהוי טקסט:בכדי לוודא שהטקסט זמין על המסך משתמשים בכלי מעין זה ולא משנה לו שינויי UI כמו רזולוציות. אך הם מזהים רק מה שניתן לראות על המסך. לכן למשל רשימות לא ניתן לבדוק. הם גם איטיים.
זיהוי אובייקטי נייטיב - האופציה המומלצת ע"י המחברזיהוי אובייקטי UI דרך עץ האלמנטים של ה-UI דרך XPath CSS או דרך ה-ID של האובייקט. הכי יעיל כיוון שאינו מסתמך על התצוגה.
יש האפשרות של Capture and play עליה הסופר אינו ממליץ אחרי שניסה מספר אפשרויות כיוון שהיא לא אמינה בעליל. סומכת יותר מידי על ה-UI וזקוקה לתחזוק מתמיד.
ניתן להשתמש כנק' פתיחה לזיהוי האובייקטים.
לדעת המחבר ההבטחה שחברות מסוימות נותנות שקוד אחד יכול לרוץ על מספר מערכות הפעלה כמו אנדרויד, OS ווינדואוס פשוט אינו נכון.
מה כדאי להעביר לאוטומציה? (הכוונה כנראה לאחד מהאפשרויות)
חלקים חשובים לביזניס,וורקפלואו וסנריו,רק סנריו מורכבים,
מה שיש לחזור עליו מספר פעמים,רק אקספטנס קריטריה,
רגרסיות,מה שהגיוני כלכלית,קוד שיכול לרוץ על מגוון מכשירים.
סימולטורים / אמולטורים או מכשירים?
סימולטורים / אמולטורים הם חינמיים, פשוטים לשימוש ונותנים כל מיני אפשרויות כמו מערכת הפעלה.
אבל יש אפשרות שבאגים לא יתגלו בסימולטורים / אמולטורים. הם גם לא נותנים גיוון במכשירים, שינויי UI בהתאם להעדפות המשתמש במיוחד באנדרויד.
תקשורת הדטה שלהם לא אמתית ואין מדידת ביצועים אמתית.
כל החסרונות הללו אינם קיימים על מכשיר אמתי. החסרונות הם מחיר, תחזוקת המכשירים.
לכן כדאי שלפחות רוב הבדיקות יהיו על מכשירים אמתיים.
אם רוצים להקים מטריצה של בדיקות אוטומטיות - ראו סרטון זה.
בכדי להתחיל לכתוב אוטומציה באנדרואיד יש לדעת את היררכיית ה-view שלו ואילו קומפוננטות ואלמנטים ואיך האלמנטים מאורגנים על המסך ומה הם מייצגים למבנה הלוגי של האפליקציה. מידע נוסף - כאן.
יש כלי בשם UI Automation Viewer שמזהה את ה-ID של כל אלמנט.
בנוסף יש בספר 28 שאלות שיכוונו אותך לכלי המתאים ומידע על כלים אשר אותם לא אביא כאן (בכ"ז צרי להשאיר לכם איזה "אינסנטיב" לרכוש את הספר). אבל מכל הכלים המומלצים לאנדרואיד הם: רובוטיום, ספון, אפיום וסלנדרויד.
ב-iOS יש הכלים האלה: ios-driver, appium and Keep It Functional.
יש עוד פרקים בספר אבל הם פחות מעניינים.
ביקורת:
יש בספר נקודות מעניינות, כפי שצויין למעלה. אבל לא בטוח שזה מספיק לספר. רואים שהכותב מבין בנושא לפחות עד לנקודה מסוימת, יש נושאים חשובים ויש קישורים טובים. אבל הספר מאוד חוזר על עצמו*, ובנוסף: הספר לא מדייק;הרגשה של חוסר מקצועיות;
ערבוב בין מוצר לבדיקות;דברים לא רלוונטיים כמו ההיסטוריה של המכשיר;
לא תמיד מסביר את עצמו (מתנשא?).
*למשל:
עוד חומר מעניין - ספרים של Eran Kinsbruner מחברת Perfecto
https://www.amazon.com/s/ref=dp_byline_sr_book_1?ie=UTF8&text=Mr+Eran+Kinsbruner&search-alias=books&field-author=Mr+Eran+Kinsbruner&sort=relevancerank
http://continuoustesting.blog
עוד ביקורות קצרות על ספרי בדיקה שקראתי.
אין תגובות:
הוסף רשומת תגובה