החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release
במקום ב-aosp-main
כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
המבנה של מפעיל בדיקות
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
מנהל הבדיקה הוא יחידת הביצוע של תהליך ההפעלה. כאן מתבצעות הבדיקות בפועל.
ממשקים
מפעילי הבדיקות מוגדרים באמצעות ממשק IRemoteTest, שמספק שיטה פשוטה ל-run
שאפשר להטמיע, ותתבצע קריאה אליה כשהבדיקה תופעל.
כך אפשר להגדיר את הרצת הבדיקה בצורה הפשוטה ביותר. אבל בפועל, לכותבי הבדיקות יהיה צורך במידע נוסף כדי לכתוב את הבדיקות בצורה נכונה, בדרך כלל מידע על ה-build והמכשיר. כאן נכנסים לתמונה הממשקים הבאים.
בסיס
שני הממשקים האלה הם הנפוצים ביותר כיום, כי הם מייצגים את הצרכים הבסיסיים של רוב הבדיקות.
- IBuildReceiver מאפשר לבדיקה לקבל את האובייקט
IBuildInfo
שנוצר בשלב build provider, שמכיל את כל המידע והפריטים הקשורים להגדרת הבדיקה.
- IDeviceTest מאפשר ל-TF לקבל את האובייקט
ITestDevice
שמייצג את המכשיר שנמצא בבדיקה, ומספק ממשק API ליצירת אינטראקציה איתו.
הגדרות מתקדמות
יש ממשקים נוספים שמאפשרים אינטראקציה מורכבת יותר בין ערכת הבדיקות לבין מפעיל הבדיקות:
- ITestFilterReceiver, שמאפשרת לבדיקה לקבל קבוצת מסננים להרצת בדיקות מסוימות בלבד. האפשרות הזו שימושית להרצה של קבוצת משנה של הבדיקות.
- ITestCollector, שמאפשר למפעיל בדיקות להריץ את הבדיקות רק לצורך בדיקה ולא לבצע אותן בפועל. האפשרות הזו שימושית לאיסוף רשימה של כל תרחישי הבדיקה.
כלי בדיקה קיימים
כבר יש מגוון של מפעילי בדיקות, חלקם לסוגים עיקריים של בדיקות:
יש מספר גדול של מפעילי בדיקות בהתאמה אישית מלבד אלה שצוינו למעלה. הם משמשים למטרות מיוחדות לבדיקות פונקציונליות מסוימות, למשל בדיקת אתחול.
כתיבת מפעיל בדיקות חדש
הנחיות נוספות לכתיבת מפעיל בדיקות חדש מפורטות בקטע 'כתיבת בדיקות'.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2025-07-27 (שעון UTC)."],[],[],null,["# Structure of a test runner\n\nThe test runner is the execution unit of the invocation flow. This is where\ntests actually run.\n\nInterfaces\n----------\n\nTest runners are defined via the [IRemoteTest\ninterface](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/invocation_interfaces/com/android/tradefed/testtype/IRemoteTest.java),\nwhich provides a simple `run` method to implement that will be called when the\ntests is to run.\n\nThis allows the simplest definition of a test run to occur. But in practice,\ntest writers will need more information to properly write their tests, typically\nbuild and device information. This is where the following interfaces come handy.\n\n### Basic\n\nThese two interfaces are the most widely used today, as they represent the basic\nneeds of most tests.\n\n- [IBuildReceiver](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/IBuildReceiver.java) allows the test to get the `IBuildInfo` object created at the [build\n provider](/docs/core/tests/tradefed/architecture/build-provider) step containing all the information and artifacts related to the test setup.\n- [IDeviceTest](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/IDeviceTest.java) allows TF to receive the `ITestDevice` object that represents the device under test and provides an API to interact with it.\n\n### Advanced\n\nThere are additional interfaces that allow more complex interaction between the\ntest harness and the test runner:\n\n- [ITestFilterReceiver](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/ITestFilterReceiver.java), which allows the test to receive a set of filters for running certain tests only. This is useful in running a subset of the tests.\n- [ITestCollector](https://android.googlesource.com/platform/tools/tradefederation/+/refs/heads/android16-release/src/com/android/tradefed/testtype/ITestCollector.java), which allows a test runner to only dry-run the tests instead of actually executing them. This is useful in collecting the list of all test cases.\n\nExisting test runners\n---------------------\n\nA variety of test runners already exists, some for major test types:\n\n- [AndroidJUnitTest / InstrumentationTest](/reference/tradefed/com/android/tradefed/testtype/AndroidJUnitTest) (associated with AJUR on the device side)\n- [GTest](/reference/tradefed/com/android/tradefed/testtype/GTest) (device and host side) with [googletest library](https://github.com/google/googletest)\n- [Host-driven\n tests](/reference/tradefed/com/android/tradefed/testtype/HostTest) (Java tests that execute on the host and call the device from there)\n- [Pure Java unit\n tests](/reference/tradefed/com/android/tradefed/testtype/HostTest) (our runner does both)\n- [Python tests](/reference/tradefed/com/android/tradefed/testtype/python/PythonBinaryHostTest)\n- [Google Benchmark\n tests](/reference/tradefed/com/android/tradefed/testtype/GoogleBenchmarkTest) with [benchmark library](https://github.com/google/benchmark)\n\nA large number of custom test runners exist besides the above; they serve\nspecialized purposes for some functional testing, for example Boot Test.\n\nWrite a new test runner\n-----------------------\n\nMore guidance of writing a new test runner is available in the [writing tests\nsection](/docs/core/tests/tradefed/testing/through-tf/new-test-runner)."]]