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

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

המשמעות היא שמבחן מכשור אינו יכול להזריק את עצמו למסגרת אנדרואיד, שנקראת שרת המערכת, לביצוע. על מנת לבחון את מסגרת אנדרואיד, קוד הבדיקה יכול להפעיל משטחי API ציבוריים בלבד, או כאלה שנחשפו באמצעות הגדרה של ממשק אנדרואיד השפה AIDL הזמין בעץ מקור פלטפורמה. עבור קטגוריית בדיקות זו, אין משמעות למקד חבילה מסוימת. לכן, נהוג של אותו כלי מדידה כגון שיוכרז למקד חבילת יישום מבחן משלה, כהגדרתו משלה <manifest> תג של AndroidManifest.xml .

בהתאם לדרישות, חבילות יישומי בדיקה בקטגוריה זו עשויות גם:

  • יש צורך בפעילויות צרור לצורך בדיקות.
  • שתף את מזהה המשתמש עם המערכת.
  • להיות חתום באמצעות מפתח הפלטפורמה.
  • הידור מול מקור המסגרת ולא ה- SDK הציבורי.

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

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

מומלץ לדפדף קודם בקוד כדי לקבל רושם גס לפני שתמשיך.

החלטה על מיקום המקור

בדרך כלל לצוות שלך יהיה כבר תבנית מבוססת של מקומות לבדוק קוד, ומקומות להוסיף בדיקות. רוב הצוות מחזיק במאגר git יחיד, או משתף אותו עם צוותים אחרים אך יש לו ספריית משנה ייעודית המכילה קוד מקור של רכיב.

בהנחה במיקום הבסיס עבור מקור הרכיב שלך נמצאת <component source root> , ולרובם יש רכיבים src ו tests תיקיות מתחתיה, וכמה קבצים נוספים כגון Android.mk (או התפרק נוספים .mk קבצים), בקובץ מניפסט AndroidManifest.xml , ואת קובץ התצורה מבחן "AndroidTest.xml".

מאז אתה מוסיף מבחן חדש, אתה בטח צריך ליצור את tests בספרייה ליד הרכיב שלך src , ולאכלס אותו התוכן.

בחלק ממקרים, צוות שלך שאולי יש מבני מדריך נוספים תחת tests בשל הצורך לארוז חבילות שונות של בדיקות אל apks פרט. וגם במקרה הזה, תצטרך ליצור ספריית משנה חדשה תחת tests .

לא משנה את המבנה, תקבלו בסופו של דבר אכלוס tests ספרייה או תת ספרייה החדשה שנוצרה עם קבצים בדומה למה שנמצא instrumentation ספריית שינוי גריט המדגם. הפרקים שלהלן יסבירו בפרטים נוספים של כל קובץ.

קובץ מניפסט

בדיוק כמו יישום רגיל, כל מודול בדיקת מכשור זקוק לקובץ מניפסט. אם אתה שם את הקובץ בשם AndroidManifest.xml ולספק אותו ליד Android.mk עבור מודול הבדיקה שלך, היא תקבל נכלל אוטומטית ע"י BUILD_PACKAGE makefile הליבה.

לפני שתמשיך, זה מומלץ מאוד לעבור את סקירת מניפסט היישום הראשון.

זה נותן סקירה של המרכיבים הבסיסיים של קובץ מניפסט והפונקציות שלהם. ראו את הדוגמא platform_testing / בדיקות / example / מכשור / AndroidManifest.xml .

תמונת מצב כלולה כאן לנוחות:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

    <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="21" />

    <application>
        <uses-library android:name="android.test.runner" />
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
                     android:targetPackage="android.test.example.helloworld"
                     android:label="Hello World Test"/>

</manifest>

כמה הערות נבחרות בקובץ המניפסט:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

package התכונה היא שם חבילת יישום: זהו מזהה ייחודי השימושים במסגרת יישום אנדרואיד לזהות יישום (או בהקשר הזה: יישום המבחן שלך). כל משתמש במערכת יכול להתקין יישום אחד בלבד בשם החבילה הזה.

יתר על כן, זו package תכונה זהה מה ComponentName#getPackageName() מחזירה, וגם אותו אתה מעוניין להשתמש בו כדי אינטראקציה עם שונות pm פקודות תת באמצעות adb shell .

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

android:sharedUserId="android.uid.system"

זה מצהיר שבזמן ההתקנה יש לתת ל- apk הזה אותו מזהה משתמש, כלומר זהות זמן ריצה, כמו פלטפורמת הליבה. הערה כי זה תלוי APK להיות חתום עם אותם תעודה כפלטפורמת הליבה (ראה LOCAL_CERTIFICATE בסעיף לעיל), אך הם מושגים שונים:

  • חלק מההרשאות או ממשקי ה- API מוגנים בחתימה, הדורשים אותה תעודת חתימה
  • כמה הרשאות או ממשקי API דורשת system זהות המשתמש של המתקשר, אשר דורש את החבילה מתקשרת זיהוי משתמש חלק עם system , אם זה חבילה נפרדת מפלטפורמת ליבה עצם
<uses-library android:name="android.test.runner" />

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

android:targetPackage="android.test.example.helloworld"

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

קובץ תצורה פשוט

לכל מודול בדיקה חדש חייב להיות קובץ תצורה לניהול מערכת הבנייה עם מטא נתונים של מודולים, תלות בזמן הידור והוראות אריזה. ברוב המקרים, האפשרות קובץ Blueprint מבוסס Soong מספיקה. לפרטים ראה תצורת בדיקה פשוטה .

קובץ תצורה מורכב

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

תצורת הבדיקה יכולה לציין אפשרויות התקנה מיוחדות של התקנים וטענות ברירת מחדל לאספקת מחלקת הבדיקה. ראו את הדוגמא /platform_testing/tests/example/instrumentation/AndroidTest.xml .

תמונת מצב כלולה כאן לנוחות:

<configuration description="Runs sample instrumentation test.">
  <target_preparer class="com.android.tradefed.targetprep.TestFilePushSetup"/>
  <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
    <option name="test-file-name" value="HelloWorldTests.apk"/>
  </target_preparer>
  <target_preparer class="com.android.tradefed.targetprep.PushFilePreparer"/>
  <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer"/>
  <option name="test-suite-tag" value="apct"/>
  <option name="test-tag" value="SampleInstrumentationTest"/>

  <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>
</configuration>

כמה הערות נבחרות בקובץ תצורת הבדיקה:

<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="HelloWorldTests.apk"/>
</target_preparer>

זה אומר ל- Trade Federation להתקין את ה- HelloWorldTests.apk על מכשיר היעד באמצעות target_preparer שצוין. ישנם מכיני מטרה רבים הזמינים למפתחים באיגוד הסחר וניתן להשתמש בהם בכדי להבטיח שהמכשיר יותקן כראוי לפני ביצוע הבדיקה.

<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>

זה מציין את מחלקת הבדיקות של הפדרציה המסחרית לשימוש לביצוע הבדיקה ומעבירה בחבילה במכשיר לביצוע ואת מסגרת הרצה לבדיקה שהיא JUnit במקרה זה.

לקבלת מידע נוסף, ראה מבחן מודול configs .

תכונות JUnit4

באמצעות android-support-test ספרייה כפי מריץ בדיקה מאפשר אימוץ כיתות מבחן בסגנון JUnit4 חדשים, ושינוי גריט המדגם מכיל כמה שימוש מאוד בסיסי של התכונות שלו. ראו את הדוגמא /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java .

בעוד שדפוסי הבדיקה בדרך כלל ספציפיים לצוותי רכיבים, ישנם כמה דפוסי שימוש שימושיים בדרך כלל.

@RunWith(JUnit4.class)
public class HelloWorldTest {

הבדל משמעותי ב- JUnit4 הוא שהבדיקות אינן נדרשות עוד לרשת ממחלקת בדיקות בסיס נפוצה; במקום זאת, אתה כותב בדיקות בשיעורי Java רגילים ומשתמש בהערה כדי לציין התקנת בדיקות ואילוצים מסוימים. בדוגמה זו, אנו מורים כי יש להריץ מחלקה זו כמבחן JUnit4.

    @BeforeClass
    public static void beforeClass() {
    ...
    @AfterClass
    public static void afterClass() {
    ...
    @Before
    public void before() {
    ...
    @After
    public void after() {
    ...
    @Test
    @SmallTest
    public void testHelloWorld() {
    ...

@Before ו @After ההסברים משמשים על שיטות ידי JUnit4 לבצע התקנת בדיקה מראש ולפירוק שלאחר הבדיקה. באופן דומה, @BeforeClass ו @AfterClass ההסברים משמשים על שיטות ידי JUnit4 לבצע התקנה לפני ביצוע כל הבדיקות בכיתה מבחן, ולפירוק לאחר מכן. שים לב כי שיטות ההתקנה והניתוק של כיתת המעמד חייבות להיות סטטיות. באשר לשיטות הבדיקה, בניגוד לגרסה הקודמת של JUnit, הם כבר לא צריכים להתחיל את שם השיטה עם test , במקום, כול אחד מהם חייב להיות מבואר עם @Test . כרגיל, שיטות הבדיקה חייבות להיות פומביות, לא להכריז על ערך החזרה, לא לקחת פרמטרים ועלולות לזרוק חריגים.

חשוב: שיטות הבדיקה עצמם המסומנים @Test ביאור; ושים לב לבדיקות שתבוצענה באמצעות APCT, הם חייבים להיות מבוארים עם גדלי מבחן: השיטה מבוארת למשל testHelloWorld כמו @SmallTest . ניתן ליישם את הביאור בהיקף השיטות או בהיקף המחלקה.

גישת instrumentation

למרות שאינו מכוסה בדוגמה בעולם שלום הבסיסית, שזה די נפוץ עבור בדיקת Android לדרוש גישת Instrumentation למשל: זהו ממשק API הליבה המספק גישה בהקשרי יישום, APIs מבחן הקשורים מחזור חיים פעילות ועוד.

מכיוון JUnit4 בדיקות כבר לא דורש מחלקה בסיס משותפת, זה כבר לא נחוץ כדי להשיג Instrumentation למשל באמצעות InstrumentationTestCase#getInstrumentation() , במקום, רץ הבדיקה החדש ומנהל אותו באמצעות InstrumentationRegistry שבו התקנת קשר והסביבתית נוצרה על ידי מסגרת מכשור מאוחסנת.

כדי לגשת מופע של Instrumentation בכיתה, פשוט להתקשר שיטה סטטית getInstrumentation() על InstrumentationRegistry בכיתה:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

לבנות ולבדוק מקומית

עבור המקרים רוב השימוש הנפוץ, להעסיק atest .

במקרים מורכבים יותר הדורשים התאמה אישית כבדה, בצע את הוראות המכשור .