איכות האפליקציה העיקרית

עודכן לאחרונה: 17 במאי 2021

דרך יעילה להעריך את איכות האפליקציה היא לבדוק את תהליכי העבודה באפליקציה ולהעריך את רמת הבטיחות והנוחות של חוויית השימוש באפליקציה.

רשימת המשימות הזו מגדירה קבוצה של קריטריוני איכות בסיסיים ובדיקות שקשורות אליהם, כדי לעזור לכם להעריך את איכות האפליקציה. יכול להיות שיהיה לכם קשה לזכור את כל הקריטריונים האלה, והבדיקות יעזרו לכם לזכור לכלול אותם בתוכניות הבדיקה שלכם.

ברשימת המשימות מודגשת האיכות המינימלית שכל האפליקציות צריכות לעמוד בה. הבדיקות שלכם כנראה יהיו מורכבות יותר ממה שמתואר כאן.

לכל פריט ברשימת המשימות לבדיקת איכות יש מזהה ייחודי, שיכול להיות שימושי כשמתקשרים עם הצוות. אפשר גם לראות את הגרסה הקודמת של ההנחיות האלה.

חוויה חזותית

האפליקציה צריכה לספק עיצוב חזותי ודפוסי אינטראקציה סטנדרטיים של Android, במקומות המתאימים, כדי להבטיח חוויית משתמש עקבית ואינטואיטיבית.

אזור מזהה בדיקות תיאור
ניווט VX-N1 CR-3 האפליקציה תומכת בניווט באמצעות לחצן חזרה רגיל, ולא נעשה בה שימוש בהנחיות מותאמות אישית של לחצן חזרה במסך.
VX-N2 CR-3 האפליקציה תומכת בניווט באמצעות תנועות כדי לחזור או לעבור למסך הבית.
VX-N3 CR-1
CR-3
CR-5

האפליקציה שומרת את מצב המשתמש או האפליקציה ומחזירה אותו בצורה תקינה.

האפליקציה שומרת את מצב המשתמש או האפליקציה כשהיא לא בחזית ולא מונעת אובדן מקרי של נתונים בגלל ניווט חזרה ושינויים אחרים במצב שלה.

כשחוזרים לקדמה, האפליקציה צריכה לשחזר את המצב שנשמר ואת כל העסקאות המשמעותיות שהיו בהמתנה. לדוגמה: שינויים בשדות שניתנים לעריכה, התקדמות במשחק, תפריטים, סרטונים וקטעים אחרים באפליקציה או במשחק.

  1. כשממשיכים את הפעלת האפליקציה מהחלפת האפליקציות האחרונות, האפליקציה מחזירה את המשתמש למצב המדויק שבו היא הייתה בשימוש האחרון.
  2. כשממשיכים את הפעלת האפליקציה אחרי שהמכשיר יוצא ממצב שינה (נעול), האפליקציה מחזירה את המשתמש למצב המדויק שבו היא הייתה בשימוש האחרון.
  3. כשמפעילים מחדש את האפליקציה ממסך הבית או מ'כל האפליקציות', האפליקציה צריכה לבצע אחת מהפעולות הבאות, בהתאם לזמן שעבר מאז השימוש האחרון בה:
    • אם נעשה שימוש באפליקציה לפני זמן קצר (דקות), המערכת משחזרת את מצב האפליקציה למצב שקרוב ככל האפשר למצב שהיא הייתה בו לפני כן.
    • אם עבר יותר זמן מאז השימוש האחרון באפליקציה, צריך לנסות לשחזר את האפליקציה למצב שקרוב ככל האפשר למצב הקודם שלה; או להפעיל אותה ממסך הבית או ממצב ברירת מחדל אחר.
התראות VX-S1 CR-9

ההתראות עומדות בהנחיות העיצוב. ובפרט:

  1. אסור להשתמש בהתראות לקידום צולב או לפרסום מוצר אחר, כי זה אסור בתכלית האיסור בחנות Play.
  2. ערוצי התראות מוגדרים בהתאם לשיטות המומלצות, במקום להציג את כל ההתראות מערוץ אחד.
  3. בחירת העדיפות הנכונה להתראות.
  4. כשאפשר, כמה התראות נערמות לקבוצת התראות אחת.
  5. הגדרת פסק זמן להתראות במקרים המתאימים.
  6. ההתראות נשארות רק אם הן קשורות לאירועים שמתרחשים כרגע, כמו השמעת מוזיקה או שיחת טלפון. מידע נוסף זמין בקטע בנושא פונקציונליות.
VX-S2 CR-9

באפליקציות לשליחת הודעות, באפליקציות חברתיות ובשיחות:

  1. להשתמש בהתראות של MessagingStyle לגבי שיחות.
  2. תמיכה בפעולת תשובה ישירה.
  3. תמיכה בקיצורי דרך לשיחות, ויישום שיטות מומלצות כדי לקבל את הדירוג הכי טוב לשיתוף ישיר.
  4. תמיכה בבועות.
ממשק משתמש וגרפיקה VX-U1 CR-5

האפליקציה תומכת בכיוונים לרוחב ולאורך, ובמצבי מכשיר מקופל ופתוח.

ההגדרות של כיווני המסך ומצבי הקיפול חושפות למעשה את אותן תכונות ופעולות, ושומרות על שוויון פונקציונלי.
VX-U2 CR-5

האפליקציה ממלאת את חלון האפליקציה בשני הכיוונים ולא מופיעה עם פסים שחורים בצדדים, בגלל שינויים בהגדרות, כולל קיפול ופתיחה של המכשיר.

מותר להוסיף מסגרת שחורה קלה כדי לפצות על שינויים קלים בגיאומטריית המסך.

VX-U3 CR-5 האפליקציה מטפלת בצורה נכונה במעברים מהירים בין כיווני התצוגה ובין מצב מקופל למצב פתוח של המכשיר, בלי בעיות בעיבוד התצוגה ובלי אובדן של מצב.
איכות חזותית VX-V1 CR-all

האפליקציה מציגה גרפיקה, טקסט, תמונות ואלמנטים אחרים בממשק המשתמש ללא עיוות, טשטוש או פיקסול בולטים.

  1. האפליקציה צריכה להשתמש בנכסי וקטורים במידת האפשר.
  2. האפליקציה מספקת גרפיקה באיכות גבוהה לכל גדלי המסכים וגורמי הצורה שמטרגטים.
  3. לא רואים החלקה של הקצוות בתפריטים, בכפתורים ובאלמנטים אחרים בממשק המשתמש.
VX-V2 CR-all

האפליקציה מציגה טקסט ובלוקים של טקסט בצורה מקובלת בכל אחת מהשפות שהאפליקציה תומכת בהן.

  1. האפשרות 'הוספת מוזיקה' מקובלת בכל גורמי הצורה הנתמכים.
  2. לא רואים אותיות או מילים חתוכות.
  3. אין גלישת מילים לא תקינה בתוך לחצנים או סמלים.
  4. יש מספיק רווח בין הטקסט לבין האלמנטים שמסביב.
VX-V3 CR-all התוכן של האפליקציה וכל תוכן האינטרנט שהאפליקציה מפנה אליו תומכים בעיצוב כהה.
נגישות VX-A1 CR-all

גודל משטחי המגע צריך להיות לפחות 48dp. מידע נוסף
VX-A2 CR-all

הטקסט ותוכן החזית באפליקציה צריכים לשמור על יחס ניגודיות גבוה מספיק בין הצבעים לבין הרקע:

  • ‫3.0:1 לטקסט או לגרפיקה גדולים
  • ‫4.5:1 לטקסט קטן (טקסט בגודל קטן מ-18 נקודות, או אם הטקסט מודגש וקטן מ-14 נקודות)

מידע נוסף על צבע וניגודיות
VX-A3 CR-all לתאר כל רכיב בממשק המשתמש, חוץ מ-TextView, באמצעות contentDescription.

הפונקציונליות

האפליקציה צריכה לספק את ההתנהגות הפונקציונלית שצפויה ממנה.

אזור מזהה בדיקות תיאור
אודיו FN-A1 CR-1
CR-8		 ההפעלה של האודיו מתחדשת כשהאפליקציה חוזרת לחזית, או שהמשתמש מקבל אינדיקציה שההפעלה מושהית.
FN-A2 CR-1
CR-2
CR-8		 אם הפעלת אודיו היא תכונה מרכזית, האפליקציה צריכה לתמוך בהפעלה ברקע.
FN-A3 CR-0

כשהמשתמש מפעיל השמעה של אודיו, האפליקציה צריכה לבצע אחת מהפעולות הבאות תוך שנייה אחת:

  1. מפעילים את האודיו.
  2. צריך לספק אינדיקטור חזותי לכך שנתוני האודיו נמצאים בהכנה.
FN-A4 CR-0 האפליקציה צריכה לשלוח בקשה למיקוד אודיו כשהפעלת האודיו מתחילה, ולבטל את מיקוד האודיו כשההפעלה נפסקת.
FN-A5 CR-0 האפליקציה צריכה לטפל בבקשות של אפליקציות אחרות להתמקדות באודיו. לדוגמה, אפליקציה עשויה להנמיך את עוצמת הקול של ההפעלה כשבאפליקציה אחרת מושמע דיבור.
מדיה FN-M1 CR-0
CR-6
CR-8		 אם האפליקציה מפעילה אודיו ברקע, היא צריכה ליצור התראה עם סגנון MediaStyle.
FN-M2 CR-0 אם אפשר להפעיל סרטון באפליקציה, היא אמורה לתמוך בהפעלה של תמונה בתוך תמונה.
FN-M3 CR-0 אם האפליקציה מקודדת סרטון, היא צריכה לעשות זאת באמצעות תקן דחיסת הווידאו HEVC.
שיתוף FN-S1 CR-0 האפליקציה צריכה להשתמש בקובץ לשיתוף ב-Android כשמשתפים תוכן. הוא יכול להציע יעדים שלא זמינים לפתרונות מותאמים אישית.
שירות הפועל ברקע FN-B1 CR-6 האפליקציה לא מפעילה שירותים ארוכים מדי ברקע שלא לצורך. כדי להבטיח שהמכשיר של המשתמש יפעל בצורה חלקה, המערכת מחילה הגבלות שונות על שירותים שפועלים ברקע. הדוגמאות הבאות לא נחשבות לשימוש טוב בשירותי רקע:
  • שמירה על חיבור לרשת כדי לקבל התראות
  • שמירה על חיבור Bluetooth
  • השארת ה-GPS מופעל

כך בוחרים את הפתרון המתאים לעבודה שלכם.

ביצועים ויציבות

האפליקציה צריכה לספק את הביצועים, היציבות, התאימות והרספונסיביות שצפויים מהמשתמשים.

אזור מזהה בדיקות תיאור
יציבות PS-S1 CR-all
SD-1		 האפליקציה לא קורסת או חוסמת את שרשור ה-UI וגורמת לשגיאות ANR (האפליקציה לא מגיבה) ב-Android. כדאי להשתמש בדוח טרום-השקה של Google Play כדי לזהות בעיות פוטנציאליות ביציבות. אחרי הפריסה, כדאי לעיין בדף Android Vitals ב-Google Play Console.
ביצועים PS-P1 CR-all
SD-1		 האפליקציה נטענת במהירות או מספקת למשתמש משוב במסך (אינדיקטור התקדמות או רמז דומה) אם טעינת האפליקציה נמשכת יותר משתי שניות.
PS-P2 CR-all
SD-1		 האפליקציות צריכות לבצע רינדור של פריימים כל 16 אלפיות השנייה כדי להגיע ל-60 פריימים לשנייה. מפתחים יכולים להשתמש באפשרות עיבוד פרופיל ב-HWUI בבדיקות. אם יש בעיות, יש כלים שיעזרו לכם לאבחן עיבוד איטי.
PS-P3 PM-1 כשהאפשרות StrictMode מופעלת (ראו בדיקות StrictMode בהמשך), לא רואים הבהובים אדומים (אזהרות ביצועים מ-StrictMode) כשבודקים את האפליקציה. הבהובים אדומים מצביעים על התנהגויות לא תקינות שקשורות לאחסון, לגישה לרשת או לדליפות זיכרון.
SDK PS-T1 CR-0 האפליקציה פועלת בגרסה הציבורית העדכנית של פלטפורמת Android בלי לקרוס או להשפיע באופן משמעותי על הפונקציונליות העיקרית.
PS-T2 SP-1 האפליקציה מטרגטת את Android SDK העדכני ביותר שנדרש כדי לעמוד בדרישות של Google Play על ידי הגדרת הערך targetSdk.
PS-T3 SP-1 האפליקציה נוצרה באמצעות Android SDK העדכני ביותר על ידי הגדרת הערך compileSdk.
PS-T4 ‫SP-2
SP-3		 כל ערכות ה-SDK של Google או של צד שלישי שבהן נעשה שימוש מעודכנות. כל שיפור בערכות ה-SDK האלה, כמו שיפורים ביציבות, בתאימות או באבטחה, צריך להיות זמין למשתמשים בהקדם האפשרי.

במקרה של ערכות SDK של Google, מומלץ להשתמש בערכות SDK שמבוססות על Google Play Services, אם הן זמינות. ערכות ה-SDK האלה תואמות לאחור, מקבלות עדכונים אוטומטיים, מקטינות את גודל חבילת האפליקציה ומאפשרות שימוש יעיל במשאבים במכשיר.

המפתחים אחראים לכל בסיס הקוד של האפליקציה, כולל ערכות SDK של צד שלישי שנעשה בהן שימוש.
PS-T5 SP-3 האפליקציה לא משתמשת בממשקים שאינם SDK.
PS-T6 SP-2 לא נכללות ספריות לניפוי באגים באפליקציה בייצור. מצב כזה עלול לגרום לבעיות בביצועים ובאבטחה.
סוללה PS-B1 BA-1 האפליקציה תומכת כראוי בתכונות לניהול צריכת החשמל שהוצגו ב-Android 6.0 (מצב שינה ומצב המתנה של האפליקציה). אם ניהול צריכת החשמל משבש את הפונקציונליות העיקרית של האפליקציה, רק אפליקציות שעומדות בדרישות יכולות לבקש פטור. אפשר לעיין בקטע תמיכה בתרחישי שימוש אחרים במצב שינה ובמצב המתנה של אפליקציות.

במהלך הפיתוח, מפתחים יכולים לבדוק את התנהגות האפליקציה במצב המתנה ובמצב שינה באמצעות פקודות ה-ADB האלה.

מפתחים יכולים להשתמש בפרופיל צריכת החשמל של Android Studio או בכלי Battery Historian, בשילוב עם עבודה מתוכננת ברקע, כדי לאבחן שימוש לא צפוי בסוללה.

פרטיות ואבטחה

האפליקציה שלך צריכה לטפל בנתוני משתמשים ובמידע אישי באופן בטוח, עם רמת ההרשאה המתאימה.

בנוסף לרשימת המשימות הזו, אפליקציות שמתפרסמות בחנות Google Play צריכות לעמוד גם בדרישות של המדיניות בנושא נתוני משתמשים כדי להגן על הפרטיות של המשתמשים.

אזור מזהה בדיקות תיאור
הרשאות SC-P1 SC-4 האפליקציה מבקשת רק את מספר ההרשאות המינימלי ביותר שנדרש כדי לתמוך בתרחיש השימוש הרלוונטי. לגבי הרשאות מסוימות, כמו מיקום, כדאי להשתמש במיקום משוער במקום במיקום מדויק, אם אפשר.
SC-P2

האפליקציה מבקשת הרשאה לגשת לנתונים רגישים (כמו SMS, יומן שיחות או מיקום) או לשירותים שעולים כסף (כמו חייגן או SMS) רק כשהגישה הזו קשורה ישירות לתרחישי השימוש העיקריים של האפליקציות. צריך להציג למשתמשים במקום בולט את ההשלכות שקשורות להרשאות האלה.

בהתאם לאופן השימוש בהרשאות, יכול להיות שיש דרך חלופית להשיג את המטרה של האפליקציה בלי להסתמך על גישה למידע רגיש. לדוגמה, במקום לבקש הרשאות שקשורות לאנשי הקשר של המשתמש, יכול להיות שיהיה נכון יותר לבקש גישה באמצעות intent משתמע.

SC-P3 CR-0 האפליקציה מבקשת הרשאות בזמן ריצה בהקשר, כשהפונקציונליות מתבקשת, ולא מראש במהלך הפעלת האפליקציה.
SC-P4 CR-0

האפליקציה מסבירה בבירור למה נדרשות הרשאות מסוימות, או שהיא פועלת לפי התהליך המומלץ להסבר למה נדרשת הרשאה.
SC-P5 CR-0 האפליקציה צריכה להיסגר בצורה מסודרת כשמשתמשים דוחים או מבטלים הרשאה. האפליקציה לא צריכה למנוע מהמשתמש גישה לאפליקציה בכלל.
נתונים וקבצים SC-DF1 SC-1 כל הנתונים הרגישים מאוחסנים באחסון הפנימי של האפליקציה.
SC-DF2 SC-10 לא מתבצעת רישום ביומן של נתונים אישיים או רגישים של משתמשים ביומן המערכת או ביומן ספציפי לאפליקציה.
SC-DF3 האפליקציה לא משתמשת במזהי חומרה שלא ניתן לאפס, כמו IMEI, למטרות זיהוי.
זהות SC-ID1 CR-0 האפליקציה מספקת הצעות למילוי אוטומטי של פרטי כניסה לחשבון ומידע רגיש אחר, כמו פרטי כרטיס אשראי, כתובת ומספר טלפון.
SC-ID2 CR-0 כדאי לשלב את המרכז לניהול פרטי כניסה ל-Android כדי ליהנות מחוויית כניסה חלקה שמאחדת את התמיכה במפתחות גישה, באיחוד זהויות ובסיסמאות רגילות.
SC-ID3 CR-0 האפליקציה תומכת באימות ביומטרי כדי להגן על טרנזקציות פיננסיות או על מידע רגיש, כמו מסמכים חשובים של המשתמש.
רכיבים של אפליקציה SC-AC1 SC-5

האפליקציה מגדירה את המאפיין android:exported באופן מפורש לכל הפעילויות, השירותים, מקלט השידורים,ובמיוחד ספקי התוכן.

רק רכיבי אפליקציה שמשתפים נתונים עם אפליקציות אחרות או רכיבים שצריכים להיות מופעלים על ידי אפליקציות אחרות מיוצאים.

SC-AC2 CR-0
SC-4

כל הכוונות והשידורים פועלים לפי השיטות המומלצות:

  1. שימוש ב-explicit intents אם אפליקציית היעד מוגדרת היטב.
  2. שימוש ב-Intents כדי לדחות את ההרשאות לאפליקציה אחרת שכבר יש לה את ההרשאה.
  3. שיתוף נתונים בצורה מאובטחת בין אפליקציות.
  4. לפני שמשתמשים בכוונות שמכילות מטען ייעודי (payload), המערכת מאמתת אותן.
  5. אם אתם צריכים להעביר Intent לאפליקציה אחרת, כדי שהאפליקציה המקבלת תוכל להפעיל ולצפות לקריאה חוזרת באפליקציה שקוראת, אל תכללו Intent מוטבע בתוספות. משתמשים ב-PendingIntent.
  6. כשמגדירים PendingIntents, צריך להגדיר במפורש את הדגל immutable, במקרים הרלוונטיים.
SC-AC3 SC-3 כל הרכיבים שמשתפים תוכן בין האפליקציות משתמשים ב-android:protectionLevel="signature" להרשאות מותאמות אישית. הם כוללים פעילויות, שירותים, מקלט שידורים, ובמיוחד ספקי תוכן.

אפליקציות לא צריכות להסתמך על גישה לרשימה של חבילות מותקנות. הגישה הוגבלה החל מ-Android 11.
רשתות SC-N1 SC-9 כל התעבורה ברשת נשלחת באמצעות SSL.
SC-N2 SC-6 האפליקציה מצהירה על תצורה של אבטחת רשת.
SC-N3 אם האפליקציה משתמשת ב-Google Play Services, ספק האבטחה מאותחל בהפעלת האפליקציה.
רכיבי WebView SC-W1 SC-6 אין להשתמש בפונקציה setAllowUniversalAccessFromFileURLs()‎ כדי לגשת לתוכן מקומי. במקומו, צריך להשתמש ב-WebViewAssetLoader.
SC-W2 SC-7 אסור להשתמש ב-addJavaScriptInterface() עם תוכן לא מהימן ב-WebViews.

ב-Android מגרסה 6.0 ואילך, צריך להשתמש בערוצי הודעות HTML.

ביצוע SC-E1 האפליקציה לא טוענת באופן דינמי קוד ממקור חיצוני לחבילת ה-APK של האפליקציה. מפתחים צריכים להשתמש ב-Android App Bundles, שכולל את Play Feature Delivery ואת Play Asset Delivery.

החל מאוגוסט 2021, חובה להשתמש ב-Android App Bundle לכל האפליקציות החדשות בחנות Google Play.

קריפטוגרפיה SC-C1 האפליקציה משתמשת באלגוריתמים קריפטוגרפיים חזקים שסופקו על ידי הפלטפורמה ובמחולל מספרים אקראיים. בנוסף, האפליקציה לא מטמיעה אלגוריתמים בהתאמה אישית.

Google Play

חשוב לוודא שאפשר לפרסם את האפליקציות שלכם ב-Google Play.

אזור מזהה בדיקות תיאור
מדיניות GP-P1 GP-all האפליקציה עומדת בדרישות של מדיניות התוכן למפתחים של Google Play, לא מוצע בה תוכן בלתי הולם, לא נעשה בה שימוש בקניין רוחני או במותג של אחרים וכו'.
GP-P2 GP-1 רמת הבגרות של האפליקציה מוגדרת בצורה מתאימה, על סמך ההנחיות לסיווג תוכן.
דף פרטי האפליקציה GP-D1 GP-1
GP-2

התמונה הגרפית של האפליקציה עומדת בהנחיות שמפורטות במאמר התמיכה הזה. מוודאים שהתנאים הבאים מתקיימים:

  1. דף האפליקציה כולל תמונה גרפית של תכונה באיכות גבוהה.
  2. הפיצ'ר הגרפי לא מכיל תמונות של מכשירים, צילומי מסך או טקסט קטן שלא יהיה קריא כשמקטינים אותו ומציגים אותו בגודל המסך הקטן ביותר שהאפליקציה מיועדת לו.
  3. התמונה המרכזית לא דומה למודעה.
GP-D2 GP-1 צילומי המסך והסרטונים של האפליקציה לא מציגים מכשירים שאינם מכשירי Android ולא מתייחסים אליהם.
GP-D3 GP-1 צילומי המסך או הסרטונים של האפליקציה לא מציגים את התוכן וחוויית המשתמש באפליקציה בצורה מטעה.
תמיכה למשתמשים GP-X1 GP-1 אם באג שדווח על ידי משתמשים בכרטיסייה 'ביקורות' בדף Google Play ניתן לשחזור ומתרחש במכשירים שונים רבים, אנחנו מטפלים בו. אם באג מתרחש רק בכמה מכשירים, עדיין כדאי לטפל בו אם המכשירים האלה פופולריים במיוחד או חדשים.

הגדרת סביבת בדיקה

כדי להגדיר סביבת בדיקה לרשימת המשימות הזו, מומלץ:

  • התמקדות בבדיקות אמולטור – אמולטור Android הוא דרך מצוינת לבדוק את האפליקציה בגרסאות שונות של Android וברזולוציות מסך שונות. מומלץ להגדיר מכשירים מדומיים (AVD) כדי לייצג את גורמי הצורה הנפוצים ביותר ואת שילובי החומרה והתוכנה של בסיס המשתמשים שלכם. בנוסף לבדיקה בטלפונים, מומלץ גם לבדוק גורמי צורה אחרים באמצעות האמולטורים הבאים לפחות:
    • מכשירים מתקפלים – 7.6 אינץ' מתקפל פנימה עם מסך חיצוני (מופיע בקטע 'טלפונים' בכלי AVD Manager).
    • טאבלט – Pixel C‏ 9.94 אינץ' (2,560px x 1,800px).
    • כדי לבדוק התראות באפליקציה לנייד, צריך להתאים מכשיר נייד או אמולטור לאמולטור Wear OS – Wear OS Round 1.84”.
  • מכשירי חומרה – סביבת הבדיקה צריכה לכלול מספר קטן של מכשירי חומרה אמיתיים שמייצגים את גורמי הצורה העיקריים ואת השילובים של חומרה ותוכנה שזמינים כרגע לצרכנים. אין צורך לבצע בדיקה בכל מכשיר שקיים בשוק. עדיף להתמקד במספר קטן של מכשירים מייצגים, ואפשר אפילו להשתמש במכשיר אחד או שניים לכל גורם צורה.
  • מעבדות לבדיקת מכשירים – אפשר גם להשתמש בשירותים של צד שלישי, כמו Firebase Test Lab, כדי לבדוק את האפליקציה במגוון רחב יותר של מכשירים.
  • בדיקה עם הגרסה העדכנית ביותר של Android – בנוסף לבדיקה עם גרסאות מייצגות של Android עבור בסיס המשתמשים שלכם, תמיד כדאי לבדוק עם הגרסה העדכנית ביותר של Android (נכון לעכשיו, Android 14). כך תוכלו לוודא שהשינויים האחרונים בהתנהגות לא ישפיעו לרעה על חוויית המשתמש.

לקבלת הנחיות מקיפות יותר לגבי בדיקות, כולל בדיקות יחידה, בדיקות שילוב ובדיקות ממשק משתמש, אפשר לעיין במאמר יסודות הבדיקות ב-Android.

הליכי בדיקה

הבדיקות האלה עוזרות לכם לגלות סוגים שונים של בעיות איכות באפליקציה. אתם יכולים לשלב בין הבדיקות או לשלב קבוצות של בדיקות בתוכניות הבדיקה שלכם. בחלקים הקודמים מופיעים קישורים למאמרים שבהם מוסבר איך הקריטריונים קשורים לבדיקות האלה.

סוג בדיקה תיאור
חבילת ליבה CR-0

עוברים לכל החלקים באפליקציה – כל המסכים, תיבות הדו-שיח, ההגדרות וכל תהליכי המשתמש.

  1. אם האפליקציה מאפשרת עריכה או יצירת תוכן, משחק או הפעלת מדיה, חשוב לבדוק את התהליכים האלה.
  2. במהלך בדיקת האפליקציה, כדאי ליצור הפרעות מאפליקציות אחרות, כמו קבלת התראה או שיחת טלפון, ולבצע שינויים זמניים במאפייני המכשיר, כמו קישוריות לרשת, פעולת הסוללה, זמינות GPS ועומס המערכת.
  3. הזנה ובדיקה של כל תהליכי הרכישה מתוך האפליקציה
CR-1 מכל מסך אפליקציה, לוחצים על מקש הבית של המכשיר או מחליקים למעלה בניווט באמצעות מחוות, ואז מפעילים מחדש את האפליקציה מהמסך 'כל האפליקציות'.
CR-2 מכל מסך של אפליקציה, עוברים לאפליקציה אחרת שפועלת, ואז חוזרים לאפליקציה שנבדקת באמצעות הממשק למעבר בין אפליקציות שהיו בשימוש לאחרונה.
CR-3 בכל מסך של אפליקציה (ובתיבות דו-שיח), לוחצים על לחצן 'הקודם' או משתמשים בתנועת החלקה לחזרה.
CR-5 בכל מסך של האפליקציה, מסובבים את המכשיר בין מצב אופקי למצב אנכי, ובין מצב מקופל למצב פתוח, לפחות שלוש פעמים.
CR-6 עוברים לאפליקציה אחרת כדי להעביר את אפליקציית הבדיקה לרקע. עוברים אל ההגדרות ובודקים אם אפליקציית הבדיקה מפעילה שירותים כלשהם ברקע. ב-Android 4.0 ומעלה, עוברים למסך האפליקציות ומחפשים את האפליקציה בכרטיסייה 'פועלות'.
CR-7 לוחצים על לחצן ההפעלה כדי להעביר את המכשיר למצב שינה, ואז לוחצים שוב על לחצן ההפעלה כדי להוציא את המסך ממצב שינה.
CR-8 מגדירים נעילת מסך במכשיר. לוחצים על לחצן ההפעלה כדי להעביר את המכשיר למצב שינה (שנועל את המכשיר). אחר כך לוחצים שוב על לחצן ההפעלה כדי להוציא את המסך ממצב שינה ולבטל את נעילת המכשיר.
CR-9 מפעילים את האפליקציה וצופים בכל סוגי ההתראות שהיא יכולה להציג במגירת ההתראות. מרחיבים את ההתראות כשזה רלוונטי (Android 4.1 ואילך), ומקישים על כל הפעולות הזמינות.
CR-10 אפשר לעיין בתמיכה בתרחישי שימוש אחרים במצב שינה עמוקה (Doze) ובהמתנה של אפליקציות.
התקנה בכרטיס SD SD-1 חוזרים על השלבים של Core Suite עם האפליקציה שהותקנה בכרטיס ה-SD של המכשיר (אם האפליקציה תומכת בשיטת ההתקנה הזו).

כדי להעביר את האפליקציה לכרטיס SD, אפשר להשתמש באפשרות 'הגדרות' > 'פרטי האפליקציה' > 'העברה לכרטיס SD'.

ביצועים ויציבות SP-1 בודקים את קובץ המניפסט של Android ואת הגדרות ה-build כדי לוודא שהאפליקציה נוצרה על בסיס הגרסה הזמינה העדכנית ביותר של ה-SDK (targetSdk ו-compileSdk).
SP-2 בודקים אם יש תלות מיושנת בקובץ build.gradle.
SP-3 כדי לזהות שימוש בממשק שאינו SDK, אפשר להשתמש בכלי ה-lint של Android Studio. קיימות גם שיטות בדיקה חלופיות אחרות.
מעקב אחר ביצועים PM-1 חוזרים על Core Suite עם StrictMode profiling enabled.

חשוב לשים לב במיוחד לאיסוף האשפה ולהשפעה שלו על חוויית המשתמש.

סוללה BA-1 חוזרים על Core Suite בכל המחזורים של Doze ושל App Standby.

חשוב לשים לב לשעונים מעוררים, לטיימרים, להתראות, לסנכרון וכו'. מידע נוסף על הדרישות וההנחיות זמין במאמר בדיקה באמצעות מצב שינה עמוקה והמתנה של אפליקציות.

אבטחה SC-1 בודקים את כל הנתונים שמאוחסנים באחסון חיצוני.
SC-2 בודקים איך המערכת מטפלת בנתונים שנטענים מאחסון חיצוני ומעבדת אותם.
SC-3 בודקים את כל ספקי התוכן שמוגדרים בקובץ המניפסט של Android. מוודאים שלכל ספק יש protectionLevel מתאים.
SC-4 בודקים את כל ההרשאות שהאפליקציה דורשת בקובץ המניפסט, בזמן הריצה ובמסך ההגדרות של האפליקציה (הגדרות > פרטי האפליקציה) במכשיר.
SC-5 בודקים את כל רכיבי האפליקציה שמוגדרים בקובץ המניפסט של Android כדי לוודא שהם מוגדרים למצב הייצוא המתאים. צריך להגדיר במפורש את הנכס המיוצא לכל הרכיבים.
SC-6 בודקים את הגדרות אבטחת הרשת של האפליקציה ומוודאים שכל בדיקות ה-lint של ההגדרות עוברות בהצלחה.
SC-7 לכל WebView, עוברים לדף שנדרש בו JavaScript.
SC-8 בכל WebView, מנסים לנווט לאתרים ולתוכן שלא נטענים ישירות על ידי האפליקציה.
SC-9 מצהירים על תצורה של אבטחת רשת שמשביתה תנועה שאינה מוצפנת, ואז בודקים את האפליקציה.
SC-10 מריצים את האפליקציה ומפעילים את כל הפונקציונליות העיקרית שלה, תוך התבוננות ביומן המכשיר. אין לרשום ביומן מידע פרטי של משתמשים.
Google Play GP-1 נכנסים אל Google Play Console כדי לבדוק את פרופיל המפתח, תיאור האפליקציה, צילומי המסך, הגרפיקה של האפליקציה, סיווג התוכן ומשוב המשתמשים.
GP-2 מורידים את הגרפיקה של התכונה ואת צילומי המסך, ומקטינים אותם כך שיתאימו לגדלי המסכים במכשירים ובגורמי הצורה שמטרגטים.
GP-3 בודקים את כל הנכסים הגרפיים, המדיה, הטקסט, ספריות הקוד ותוכן אחר שנכללים בחבילת האפליקציה או בהורדה של קובץ ההרחבה.

בדיקה באמצעות StrictMode

לצורך בדיקת הביצועים, מומלץ להפעיל את StrictMode באפליקציה ולהשתמש בו כדי לזהות פעולות שעלולות להשפיע על הביצועים, על גישה לרשת, על קריאה/כתיבה של קבצים וכו'. כדאי לחפש פעולות בעייתיות פוטנציאליות גם בשרשור הראשי וגם בשרשורים אחרים.

אפשר להגדיר מדיניות מעקב לכל שרשור באמצעות StrictMode.ThreadPolicy.Builder ולהפעיל את כל אפשרויות המעקב הנתמכות בThreadPolicy באמצעות detectAll().

חשוב להפעיל התראה חזותית על הפרות מדיניות עבור ThreadPolicy באמצעות penaltyFlashScreen().