בדיקות עומסים ויתירות בפיתוח אפליקציה לניידים
דבר חשוב שנזנח או נדחה כל הזמן הוא ההתייחסות לצד השרת בפרויקטים כאלו בהסתמך על רישום הדרגתי לשירות המוצע או על ספק האחסון אך לא כך הדבר במציאות. קמפיין טוב ייצור תעבורה גדולה להתקנה ומשתמשים ינסו את האפליקציה שלכם ומאחר שמדובר בקמפיינים ממוקדים לרב התעבורה תהיה בגלים אחידים ובפיקים של הרשמות מה שלרב יעמיד את השרת בעומס גדול ולכן הבעיות הצפויות לכם עלולות להיות: פיקים גדולים מאוד ואיטיות תגובתיות השרת, קריסות אפליקציה באנדרויד בגלל ברירת מחדל של 2.5 שניות (Timeout) זמני תגובת שרת, נפילות כלליות של שרת עקב אי יכולת להתמודד עם הפניות.
אז מה אני ממליץ לא לזנוח באסטרטגיית הבדיקות;
- תדרשו גישה ללוגים של השרת, בתחילת העבודה תלמדו את הלוגים והקריאות לשרת תוך עבודה על האפליקציה (client), תבחנו האם יש קריאות מיותרות לשרת היוצרות עומס מיותר ואם ניתן להגדיל את מרווחי 'אימות זמינות משתמשים' מומלץ לעשות זאת במידה (לדוגמא: כשמשתמש מתחיל לרשום ומוחק ושומר פרופיל ללא שינויים, במקרה זה רישום לשרת מחדש הוא מיותר וייצור בזמני ריבוי משתמשים עומס מיותר).
- תדרשו לנסות להריץ כלי אוטומטי שיבצע קריאות שרת מרובות במטרה ליצור עומס כדי לבחון מכמה משתמשים נרשמים ,בו זמנית, יוכל השרת לעמוד.
- בזמן שאתם מריצים בדיקות עומס כל שהן נסו לעבוד עם האפליציה לנסות לבחון את אופי השימוש והאם השרת לא יוצר תגובות איטיות למי שכבר רשום לשירות ועובד עם האפליקציה. חוויית שימוש איטית תגרור איבוד משתמשים.
- תדרשו לפני השחרור להקים סביבת Pre-Release, סביבה זו תאפשר לכם להעלות לבדיקה דברים לפני שחרורם על סביבת שרת זהה לזו שבמציאות ולא על שרת מקומי. הרבה מאוד בעיות קיימות בחילופי סביבות.
- כשמדובר באפליקציות המאפשרות העברת קבצים, וידאו ומדיה הדבר הופך מורכב יותר ומכדאי לבחון בדיקות עומס מורכבות מרישום משתמשים ומשתמשים שמעלים/מורידים קבצים במקביל.
זהו בנתיים, בטח אזכר בדברים נוספים בהמשך אז אעדכן.
תיהנו..
תגובות