מה יכול להיות יותר מעצבן מאפליקציה שמגיבה לאט ופועלת בצורה גרועה? אמנם יש לא מעט דברים מעצבנים, אבל פיתוח אפליקציות אינו בחירה בין רעים אלא יצירת חוויית משתמש מיטבית. אם משתמשים לא אוהבים את האפליקציה שלכם, הם פשוט יסירו אותה וימצאו חלופה שנטענת מהר יותר ועובדת חלק. עבורכם כמפתחים וכבעלי מוצר זו עלולה להיות מכה קשה – הרבה יותר קשה למשוך משתמשים חדשים כאשר הדירוגים רעים. לכן, הרצת בדיקות ביצועים לפני השקה היא חובה לכל מי שרוצה ליצור מוצר באמת מהנה. במאמר זה נציג לכם במהירות איך בודקים ביצועים ומה בודקים.
1) ביצועי מכשיר
ראשית, עליכם לוודא שהאפליקציה אינה "מפרקת" את המכשיר. היא לא אמורה לקרוס מכשירים או לצרוך בצורה מופרזת את המשאבים שלהם כמו זיכרון, מעבד או סוללה. מכיוון שלכל מכשיר יש תכונות שונות, כדאי לבדוק על מספר דגמים ומערכות הפעלה – כך תאתרו בעיות שעלולות להופיע בפלטפורמות מסוימות.
להלן כמה היבטים שנבדקים במסגרת בדיקות מסוג זה:
- זמן הפעלה – זהו הרושם הראשוני של האפליקציה. כדי להשאיר תחושה טובה, מסך הפתיחה צריך להיטען תוך שנייה־שתיים מהרגע שהמשתמש נוגע בסמל.
- זמן סוללה – יש אפליקציות ש"שואבות" את חיי הסוללה. הן גורמות לעומס יתר על המעבד ומחממות את המכשיר, מה שפוגע בחוויה ואף עלול להזיק לגאדג'ט. חשוב לוודא שהאפליקציה אינה צורכת יותר משאבים ממה שהמכשיר יכול לספק ללא עומס יתר.
- צריכת זיכרון – כמו מחשבים, גם לסמארטפונים יש זיכרון מובנה, אולם הוא מוגבל בהרבה. תכונות מסוימות כמו הודעות פוש באנדרואיד עשויות לצרוך ממנו לא מעט. במהלך הבדיקה מהנדס/ת QA בודק/ת כמה זיכרון נצרך כשהאפליקציה פועלת וכשהיא כבויה. אם צריכת הזיכרון כמעט כמו זו של מערכת ההפעלה עצמה, צריך לאופטם את הקוד במהירות.
- שימוש מקבילי – האפליקציה לא צריכה להתנגש עם תוכנות אחרות כשהמשתמש מפעיל אותן במקביל. הדרך הטובה ביותר לבדוק זאת היא לדמות פעולות משתמש: לעבור בין אפליקציות במהלך השימוש.
- פעילות ברקע – כאשר מעבירים את האפליקציה לרקע, היא צריכה לשמור את אותו מצב עד שמחזירים אותה למסך. אחרת, המשתמש עלול לאבד נתונים חשובים או להחמיץ דברים.
2) ביצועי שרת / API
אם האפליקציה שלכם מתקשרת עם שרת באמצעות API, זמן התגובה קריטי במיוחד לחוויית המשתמש הכוללת. להלן שלושה גורמים מרכזיים שאנשי QA בודקים:
- עיבוד נתונים – טעינת הנתונים ובניית המסך לא צריכים לקחת זמן רב. אם הם מגיעים בפורמט שונה מזה שבו האפליקציה משתמשת, ההמרה צריכה להתבצע מהר וביעילות. בשלב זה מהנדס/ת QA דואג/ת שזמן התגובה תקין ושהמידע מגיע נכון.
- מספר קריאות API – כל קריאה נוספת ל־API מפחיתה את הביצועים, ולכן עדיף לצמצם את המספר הכולל. לדוגמה, אם מספר קריאות מבצעות למעשה את אותה פעולה, המפתח/ת יצטרך/תצטרך לכתוב את הקוד מחדש כך שיבצע את אותה משימה עם פחות קריאות.
- זמני השבתה של השרת – האפליקציה צריכה לעבוד גם כשיש בעיות בשרת. לדוגמה, אם השרת נופל, הנתונים צריכים להיות זמינים דרך בסיס נתונים מקומי על המכשיר. דרך אחרת היא לעבור לשרת גיבוי כשהשרת הראשי כושל. כדי להבטיח מעבר חלק, השרת הגיבוי חייב להיות מסונכרן עם העיקרי.
3) ביצועי רשת
האפליקציה צריכה לעבוד בצורה חלקה בכל תנאי רשת. כדי להבטיח ביצועים מרביים, הבודקים בוחנים את הנקודות הבאות:
- ג'יטר – ג'יטר הוא השינוי בזמן העיכוב בין חבילות נתונים במהלך העברתם ברשת. בדרך כלל הוא עומד על כ־10 מילישניות. עיכובים ארוכים יותר עלולים ליצור בעיות בקבלת ועיבוד נתונים עבור אפליקציות רגישות ל־Latency. האפליקציה צריכה לדעת להתמודד עם תנודות אלו; אחרת, המידע יגיע משובש.
- אובדן חבילות – אם חבילה שלמה הולכת לאיבוד, על האפליקציה לדעת לשלוח מחדש את הבקשה או להציג למשתמש התראה מתאימה. במקרה כזה המידע מגיע חסר, ולכן האפליקציה לא צריכה לנסות להציגו אלא ליידע את המשתמש.
- מהירות רשת – חשוב לבדוק את האפליקציה על רשתות 2.5G, 3G ו־4G, הן על Wi‑Fi והן על נתונים סלולריים. בנוסף, מהנדסי QA בודקים את התנהגות האפליקציה כשיש מספר רשתות זמינות, במיוחד במעבר ביניהן. לעיתים בעיות צצות בעת מעבר מאינטרנט סלולרי ל־Wi‑Fi – האפליקציה עלולה להפסיק להגיב וצריך להפעילה מחדש.
מחפשים מומחה QA לביצוע בדיקות ביצועים עבור האפליקציה שלכם? Intersog תשמח לספק לכם את האנשים הנכונים ואת הידע המתאים. צרו קשר לקבלת הצעת מחיר חינם ולמידע נוסף על שירותי QA ובדיקות שלנו.
להגיב