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

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

• התקנה של חבילות APK אחרות (בנוסף לחבילת ה-APK לבדיקה)
• לדחוף קבצים מסוימים למכשיר
• להריץ פקודות (למשל adb Shell pm ...)

בעבר, צוותי הרכיבים נאלצו בדרך כלל לכתוב בדיקה בצד המארח כדי לבצע משימות כאלה. לשם כך, הם נדרשו להבין את רתמת Trade Federation, והבדיקה הזו בדרך כלל הגדילה את המורכבות של מודול הבדיקה.

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

קובץ תצורה של מודול בדיקה הוא קובץ XML נדרש שמתווסף לתיקיית המקור של המודול ברמה העליונה, בשם AndroidTest.xml. קובץ ה-XML עומד בפורמט של קובץ תצורה שמשמש את ערכת הכלים של אוטומציית הבדיקה של Trade Federation. נכון לעכשיו, התגים הראשיים שמטופלים דרך הגדרות מודול הבדיקה הם התגים target_preparer ו-test.

גורמים שתצטרכו לטרגט

תג "target_preparer", כפי שהשם מרמז, מגדיר כלי להכנת יעד (ראו ITargetPreparer) שמציע שיטת הגדרה, שנשלחת לפני הרצת מודול הבדיקה לצורך בדיקה. אם המחלקה שאליה מפנה התג target_preparer כוללת גם את ITargetCleaner, שיטת הבדיקה תופעל אחרי שמודול הבדיקה יסתיים.

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

<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>

לדוגמה, אנחנו יכולים להוסיף את תגי האפשרויות הבאים (בתגובה "insert" למעלה):

    <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
        <option name="run-command" value="settings put secure accessibility_enabled 1" />
        <option name="teardown-command" value="settings put secure accessibility_enabled 0" />
    </target_preparer>

האפשרויות יגדירו את מסגרת הבדיקה כך:

1. לפני שמודול הבדיקה מופעל, מריצים את פקודת המעטפת "הגדרות לשים את מאובטח accessibility_enabled 1" במכשיר
2. אחרי סיום מודול הבדיקה, מריצים את פקודת המעטפת "settings put secure accessibility_enabled 0"

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

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

• שם הכיתה: PushFilePreparer

  • short name: Push-file
  • function: דחיפה של קבצים שרירותיים מתיקיית מקרה הבדיקה ליעד במכשיר
  • notes:
    • ה-Maker הזה יכול לדחוף מתיקייה לתיקייה, או מקובץ לקובץ. כלומר, אי אפשר לדחוף קובץ לתיקייה במכשיר: צריך לציין גם את שם קובץ היעד באותה תיקייה.
  • options:
    • push-file: מפרט push שמציין את הקובץ המקומי לנתיב שבו צריך לדחוף אותו במכשיר. יכול להיות שהם יתרחשו שוב. אם מספר קבצים מוגדרים לדחוף לאותו נתיב מרוחק, הקובץ האחרון יידחה.
    • push: (לא מומלץ) מפרט push, בפורמט /path/to/srcfile.txt->/path/to/destfile.txt או /path/to/srcfile.txt->/path/to/destdir/. אפשר לחזור עליו. הנתיב הזה יכול להיות יחסי לספריית מודול הבדיקה או לספריית out עצמה.
    • post-push: פקודה להרצה במכשיר (עם adb shell <your command>) אחרי שכל הניסיונות להעברה (push) בוצעו. תרחיש לדוגמה: שימוש ב-chmod להרשאות

• שם הכיתה: InstallApkSetup

  • שם מקוצר:install-apk
  • function: דוחפת קובצי APK שרירותיים ליעד במכשיר.
  • options:
    • test-file-name: השם של קובץ ה-APK שרוצים להתקין במכשיר.
    • install-arg: ארגומנטים נוספים שיועברו לפקודה pm Install, כולל מקף בהתחלה, למשל '-d'. ניתן לחזור על הפעולה

• שם המחלקה: RunCommandTargetPreparer

  • שם מקוצר: run-command
  • function: הרצת פקודות מעטפת שרירותיות לפני או אחרי הפעלת המודול
  • options:
    • run-command:פקודת shell של adb להרצה. יכול להיות שיתבצעו חזרות
    • teardown-command: פקודה של מעטפת adb שצריך להריץ במהלך שלב הפירוק. יכול להיות שיתבצעו חזרות

מחלקת בדיקה

כיתה לבדיקה היא הכיתה של Trade Federation שבה משתמשים כדי להריץ את הבדיקה.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

ריכזנו כאן שלוש כיתות בדיקה נפוצות:

• שם מחלקה: GTest

  • שם קצר: gtest
  • function: בדיקה שמריצה חבילת בדיקה מובנית במכשיר נתון.
  • אפשרויות:
    • native-test-device-path:הנתיב במכשיר שבו נמצאים הבדיקות המקומיות.

• שם הכיתה: InstrumentationTest

  • שם מקוצר: אינסטרומנטציה
  • function: בדיקה שמריצה חבילת בדיקות של מכשירי מדידה במכשיר נתון
  • אפשרויות:
    • package:שם החבילה של המניפסט של אפליקציית הבדיקה ל-Android שרוצים להריץ.
    • class:שם מחלקת הבדיקה שרוצים להריץ.
    • method: שם שיטת הבדיקה שרוצים להריץ.

• שם מחלקה: AndroidJUnitTest

  • function: בדיקה שמריצה חבילת בדיקת מכשור במכשיר נתון באמצעות android.support.test.runner.AndroidJUnitRunner. זוהי הדרך העיקרית להריץ בדיקת מכשור.