תוצאות הבדיקה של CTS נמצאות בקובץ:
CTS_ROOT/android-cts/results/start_time.zip
אם יצרתם את ה-CTS בעצמכם, הערך של CTS_ROOT דומה ל-out/host/linux-x86/cts, אבל משתנה בהתאם לפלטפורמה. זהו הנתיב שבו דחסת את קובץ ה-CTS הרשמי המובנה שהורדת מהאתר הזה.
בתוך קובץ ה-zip, הקובץ test_result.xml מכיל את התוצאות בפועל.
הצגת תוצאות של Android מגרסה 10 ואילך
קובץ test_result.html קיים בארכיון ה-zip, ניתן לפתוח אותו ישירות בכל דפדפן אינטרנט התואם ל-HTML5
הצגת תוצאות טרום-Android 10
פתחו את הקובץ test_result.xml בכל דפדפן אינטרנט התואם ל-HTML5 כדי להציג את תוצאות הבדיקה
אם בדף הזה מוצג דף ריק כשמשתמשים בדפדפן Chrome, צריך לשנות את הגדרות הדפדפן כדי להפעיל את הדגל --allow-file-access-from-files בשורת הפקודה.
קריאת תוצאות הבדיקה
הפרטים של תוצאות הבדיקה תלויים בגרסת ה-CTS שבה אתם משתמשים:
- CTS v1 ל-Android 6.0 וגרסאות קודמות
- CTS v2 ל-Android 7.0 ואילך
פרטי המכשיר
ב-CTS v1 ובגרסאות קודמות, בוחרים באפשרות 'פרטי המכשיר' (הקישור מופיע מעל 'סיכום הבדיקה') כדי להציג פרטים על המכשיר, על הקושחה (יצרן, דגם, build של הקושחה, פלטפורמה) ועל החומרה של המכשיר (רזולוציית המסך, מקלדת, סוג המסך). CTS v2 לא מציג מידע על המכשיר.
סיכום הבדיקה
בקטע סיכום הבדיקה מוצגים פרטים של תוכנית הבדיקה שבוצעה, כמו שם תוכנית ה-CTS ושעות ההתחלה והסיום של הביצוע. בנוסף, מוצג סיכום מצטבר של מספר הבדיקות שעברו, נכשלו, פג תוקפן או שלא ניתן היה לבצע אותן.
סיכום בדיקות לדוגמה של Android 10 CTS
איור 1: סיכום בדיקה לדוגמה של Android 10 CTS
סיכום של בדיקת דוגמה ל-CTS v2
איור 2: סיכום של בדיקת CTS v2 לדוגמה
סיכום בדיקות לדוגמה של CTS גרסה 1
איור 3: סיכום של בדיקת דוגמה ל-CTS v1
דוח בדיקה
בקטע הבא, דוח הבדיקה של CTS, מוצג סיכום של הבדיקות שעברו בכל חבילה.
לאחר מכן מוצגים פרטים על הבדיקות בפועל שבוצעו. בדוח מפורטים חבילת הבדיקה, חבילת הבדיקות, תרחיש הבדיקה והבדיקות שבוצעו. כאן מוצגת התוצאה של ביצוע הבדיקה – 'הצלחה', 'כישלון', 'התוקף פג' או 'לא בוצע'. במקרה של כשל בבדיקה, מוצגים פרטים שיעזרו לאבחן את הגורם.
כמו כן, דוח הקריסות של הכשל זמין בקובץ ה-XML, אבל הוא לא כלול בדוח כדי לקצר אותו. כדי לצפות בקובץ ה-XML באמצעות עורך טקסט, צריך לספק פרטים על הכשל בבדיקה (מחפשים את התג [Test] בהתאם לבדיקה שנכשלה ומחפשים בו את התג [StackTrace]).
הצגת דוח בדיקה לדוגמה של CTS v2
איור 4: דוח בדיקה לדוגמה של CTS v2
הצגת דוח בדיקה לדוגמה של CTS v1
איור 5: דוח בדיקה לדוגמה של CTS גרסה 1
עיין ב-test_result.xml כדי למצוא מודולים של בדיקה שלא הושלמו
כדי לבדוק את מספר המודולים הלא מושלמים בסשן בדיקה מסוים, מריצים את הפקודה 'list results'. מספר המודולים שהושלמו ומספר המודולים הכולל מפורטים לכל סשן קודם. כדי לקבוע אילו מודולים הושלמו ואילו לא, פותחים את הקובץ test_result.xml וקוראים את הערך של המאפיין done לכל מודול בדוח התוצאות. מודולים שהערך שלהם הוא ="false" לא הופעלו עד לסיום.
כשלים בבדיקת הטריאז'
תוכלו להיעזר בהצעות הבאות כדי לסווג את הכישלונות בבדיקות.
- אם הבדיקה נכשלת בגלל תנאים מוקדמים שגויים, צריך לוודא שסביבת CTS מוגדרת בצורה נכונה. הסביבה הפיזית, ההגדרה של המחשב וההגדרה של מכשיר Android.
- חשוב לוודא את יציבות המכשיר, הגדרות הבדיקה או בעיות בסביבה, אם הבדיקה מופיעה בצורה לא יציבה מדי.
- אם הבדיקה עדיין נכשלת, מנסים אותה שוב בנפרד.
- בודקים אם יש גורמים חיצוניים שגורמים לכשלים בבדיקות, כמו:
- הגדרת הסביבה. לדוגמה, הגדרה שגויה של מחשב שולחני עשויה לגרום לכישלונות בבדיקות בכל המכשירים שנבדקים (DUT) (כולל מכשירי העזר).
- יחסי תלות חיצוניים. לדוגמה, אם בדיקה נכשלת בכל המכשירים בכמה אתרים החל מנקודת זמן מסוימת, יכול להיות שמדובר בכתובת URL שגויה.
- אם ה-DUT לא כולל את תיקון האבטחה, צפוי כי בדיקת האבטחה שלו תיכשל.
- אימות ההבדלים בין מכשירים שעברו את הבדיקה לבין מכשירים שנכשלו בה, וניתוח ההבדלים האלה.
- מנתחים את טענת הנכוֹנוּת (assertion), את היומן, את דוח איתור הבאגים ואת מקור ה-CTS. ב-HostTest, ההצהרה (assertion) והיומן יכולים להיות כלליים מאוד, לכן מומלץ לבדוק ולצרף גם את ה-logcat של המכשיר.
- שולחים תיקון לשיפור הבדיקה כדי לצמצם את מספר הכשלונות בבדיקה.
שמירת תוצאות חלקיות
כשהפעלת הבדיקה נכשלת, מערכת המסחר האלקטרוני לא שומרת תוצאות בדיקה חלקיות.
אם Tradefed לא יוצר תוצאות בדיקה, סימן שהתרחשה בעיה חמורה במהלך הרצת הבדיקה, ולכן אי אפשר לסמוך על תוצאת הבדיקה. התוצאה החלקית נחשבת לא מועילה כי היא לא מספקת ערך כשבודקים את הבעיה במכשיר.