רשומות

סימולציה למיקום בבדיקות אפליקציית IOS באמצעות xcode

תמונה
כמה פעמים נאלצתם לבצע בדיקות מבוססות שינוי מיקום, נכון שבאנדרויד זה קצת יותר קל באמצעות אפליצקיה של FakeGPS אך באייפון זה קצת יותר מסובך ולעיתים למפתח לא יהיה זמן לפתח לכם כלי בדיקה אז מה לעשות?! אחת היתרונות בבדיקות IOS זו העבודה במערכת הפעלה של Mac ואם אין לכם בטוח שבפרוייקט שלכם תקבלו רישיון לVMware ותוכלו להתקין Mac וירטואלי (אנסה לכתוב מאמר העוסק בהתקנת  Mac וירטואלי בהמשך יש מתעניינים). עבודה על Mac או יותר מדוייק עם Xcode שזו תוכנת הפיתוח של מפתחי אפליקציות IOS היא מאפשרת הרבה דברים כמו קריאת לוגים ומתן אפשרות לפתוח נקודות עצירה בקריסות דבר שיעזור מאוד למפתח שלכם אך בין השאר גם האפשרות לשנות ולקבוע מיקום. Apple נתנו בסביבת הפיתוח יכולת

כלי בדיקה וניתור לעבודה עם אפליקציות ניידיות - TestFairy

תמונה
עבודה בבדיקות כוללת ניסיון, התנסות ולמידה מתמשכת ובלתי נפסקת ופיתוח אינטואיציה לרגישיות במערכת הנבחנת. יחד עם זאת, אחד הדברים שתמיד מטריד ונראה לנו כבודקים מתסכל הינה קריסה. מה כבר ניתן לעשות מלבד להחזיר למפתח עם סנריו או במקרה הרע לא להחזיר אם אין סנריו ולהתחיל להריץ בדיקות אינספור פעמים במטרה למצוא את הקריסה או להתחיל את אותו סבב הבדיקות מחדש. בפוסט זה אני מביא לכם שירות חדש חינמי ברובו (נכון ליום כתיבת פוסט זה) שעוזר רבות בניהול קריסות ושחזור מידע מבאגים בזמן בדיקות ותורם גם למפתחים בהשבת מידע סנריו ומידע רחב יותר במקרים מתסכלים אלו. שם השירות/המערכת -  TestFairy. השירות הזה מאפשר התקנה והפצה של גרסאת בטא לקבוצת

כלי קטן חוסך זמן - Mobizen Screen Recorder

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

עבודה עם מסד נתונים MongoDB

תמונה
אז הכרנו את מסד נתונים MongoDB והצלחנו בפוסט הקודם לבצע שאילתות בסיסיות. מסד נתונים נוח ואנו בפרוייקט המובייל שלנו אפילו מצליחים להפיק ממנו המון ובעלויות נמוכות מאוד. כעת אנו כבודקים רוצים להריץ בדיקות קצת יותר עמוקות ואין לנו את הפנאי בפרוייקט להתחיל להתעסק עם כתיבת שאלתות מורכבות והזמן יקר (למרות שאני מוצא זאת מאוד פשוט כששומרים קובץ של כל השאילתות שלנו). בואו ונכיר כלי חדש, נוח, ידידותי ופותח אפשרויות רחבות ונוחות: MongoChef  של  3T Software Labs. מה שונה תוכנה זו מאחרות או מהקודמת שהצגתי? בראשית יש פה ממשק משתמש עם בונה שאילתות (Query builder). ושנית יש פה ממשק חכם ונוח שתומך בגרירת אובייקטים, צביעה וסימון אובייקטים, השוואת טבלאות ועוד....

האם אדם אחד יכול לבצע בדיקות איכות?

תמונה
פרוייקטים רבים ממהרים לגייס מס' מפתחים אך מסתפקים באיש בדיקות יחיד. אז נכון ש בדיקה של דפי נחיתה, אפליקציות פשוטות (2-3 מסכים ומעט פונקציות) בהחלט יכולות לספק איכות טובה תוך עבודה של איש בדיקות אחד בעל ניסיון באותו תחום, אך האם פרוייקטים מורכבים באמת יכולים להסתפק באיש בדיקות יחיד גם אם מאפשרים לו זמני בדיקות מעט ממושכים יותר (דגש על המעט בקורח המציאות) ?

הדמייה של סוג ואיכות רשת בבדיקות IOS

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

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

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