Atest เป็นเครื่องมือบรรทัดคำสั่งที่อนุญาตให้ผู้ใช้สร้าง ติดตั้ง และเรียกใช้การทดสอบ Android ในเครื่อง เร่งการรันการทดสอบซ้ำได้อย่างมากโดยไม่ต้องมีความรู้เกี่ยวกับตัวเลือกบรรทัดคำสั่ง ชุดทดสอบของ Trade Federation หน้านี้อธิบายวิธีใช้ Atest เพื่อเรียกใช้การทดสอบ Android
สำหรับข้อมูลทั่วไปเกี่ยวกับการทดสอบการเขียนสำหรับ Android โปรดดูที่ การทดสอบแพลตฟอร์ม Android
สำหรับข้อมูลเกี่ยวกับโครงสร้างโดยรวมของ Atest โปรดดูที่ คู่มือนักพัฒนา Atest
สำหรับข้อมูลเกี่ยวกับการเรียกใช้การทดสอบในไฟล์ TEST_MAPPING ผ่าน Atest โปรดดูที่ การเรียกใช้การทดสอบในไฟล์ TEST_MAPPING
ในการเพิ่มคุณสมบัติให้กับ Atest ให้ทำตาม Atest Developer Workflow
การตั้งค่าสภาพแวดล้อมของคุณ
ทำตามขั้นตอนในหัวข้อต่อไปนี้เพื่อตั้งค่าสภาพแวดล้อม Atest ของคุณ
ตั้งค่าตัวแปรสภาพแวดล้อม
ตั้งค่า test_suite
สำหรับ Soong หรือ LOCAL_COMPATIBILITY_SUITE
สำหรับ Make กฎสคริปต์ build build ต่อไป
เรียกใช้ envsetup.sh
จากรูทของการชำระเงินต้นทาง Android ให้เรียกใช้:
source build/envsetup.sh
วิ่ง lunch
เรียกใช้คำสั่ง lunch
เพื่อเปิดเมนูของอุปกรณ์ที่รองรับ ค้นหาอุปกรณ์และเรียกใช้คำสั่งนั้น
ตัวอย่างเช่น หากคุณมีอุปกรณ์ ARM เชื่อมต่ออยู่ ให้รันคำสั่งต่อไปนี้:
lunch aosp_arm64-eng
สิ่งนี้จะตั้งค่าตัวแปรสภาพแวดล้อมต่างๆ ที่จำเป็นสำหรับการรัน Atest และเพิ่มคำสั่ง Atest ให้กับ $PATH
ของคุณ
การใช้งานพื้นฐาน
คำสั่ง Atest มีรูปแบบดังต่อไปนี้:
atest test-to-run [optional-arguments]
อาร์กิวเมนต์ทางเลือก
ตารางต่อไปนี้แสดงรายการอาร์กิวเมนต์ที่ใช้บ่อยที่สุด รายการทั้งหมดมีอยู่ atest --help
ตัวเลือก | ตัวเลือกยาว | คำอธิบาย |
---|---|---|
-b | --build | สร้างเป้าหมายการทดสอบ (ค่าเริ่มต้น) |
-i | --install | ติดตั้งสิ่งประดิษฐ์ทดสอบ (APK) บนอุปกรณ์ (ค่าเริ่มต้น) |
-t | --test | ดำเนินการทดสอบ (ค่าเริ่มต้น) |
-s | --serial | รันการทดสอบบนอุปกรณ์ที่ระบุ สามารถทดสอบอุปกรณ์ได้ครั้งละหนึ่งเครื่อง |
-d | --disable-teardown | ปิดใช้งานการทดสอบการฉีกขาดและการล้างข้อมูล |
<c> | --info | แสดงข้อมูลที่เกี่ยวข้องเกี่ยวกับเป้าหมายที่ระบุ จากนั้นออก |
<c> | --dry-run | Atest แบบแห้งโดยไม่ต้องสร้าง ติดตั้ง หรือรันการทดสอบจริงๆ |
-m | --rebuild-module-info | บังคับให้สร้างไฟล์ module-info.json ขึ้นใหม่ |
-w | --wait-for-debugger | รอให้ดีบักเกอร์เสร็จสิ้นก่อนที่จะดำเนินการ |
-v | --verbose | แสดงการบันทึกระดับ DEBUG |
<c> | --iterations | การทดสอบแบบวนซ้ำจนกว่าจะถึงการวนซ้ำสูงสุด (10 โดยค่าเริ่มต้น) |
<c> | --rerun-until-failure [COUNT=10] | รันการทดสอบทั้งหมดซ้ำจนกว่าจะเกิดความล้มเหลวหรือถึงการวนซ้ำสูงสุด (10 โดยค่าเริ่มต้น) |
<c> | --retry-any-failure [COUNT=10] | เรียกใช้การทดสอบที่ล้มเหลวซ้ำจนกว่าจะผ่านหรือถึงการวนซ้ำสูงสุด (10 โดยค่าเริ่มต้น) |
<c> | --start-avd | สร้าง AVD โดยอัตโนมัติและเรียกใช้การทดสอบบนอุปกรณ์เสมือน |
<c> | --acloud-create | สร้าง AVD โดยใช้คำสั่ง acloud |
<c> | --[CUSTOM_ARGS] | ระบุอาร์กิวเมนต์ที่กำหนดเองสำหรับนักวิ่งทดสอบ |
-a | --all-abi | เรียกใช้การทดสอบสถาปัตยกรรมอุปกรณ์ที่มีอยู่ทั้งหมด |
<c> | --host | รันการทดสอบอย่างสมบูรณ์บนโฮสต์โดยไม่ต้องใช้อุปกรณ์ หมายเหตุ: การรันการทดสอบโฮสต์ที่ต้องใช้อุปกรณ์ที่มี --host จะล้มเหลว |
<c> | --flakes-info | แสดงผลการทดสอบพร้อมข้อมูลเกล็ด |
<c> | --history | แสดงผลการทดสอบตามลำดับเวลา |
<c> | --latest-result | พิมพ์ผลการทดสอบล่าสุด |
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ -b
, -i
และ -t
โปรดดูส่วน ระบุขั้นตอน: สร้าง ติดตั้ง หรือรัน
ระบุการทดสอบ
ในการรันการทดสอบ ให้ระบุการทดสอบอย่างน้อยหนึ่งรายการโดยใช้ตัวระบุต่อไปนี้:
- ชื่อโมดูล
- โมดูล:คลาส
- ชื่อคลาส
- การทดสอบการรวม Tradefed
- เส้นทางของไฟล์
- ชื่อแพ็คเกจ
แยกการอ้างอิงถึงการทดสอบหลายรายการด้วยการเว้นวรรคดังนี้:
atest test-identifier-1 test-identifier-2
ชื่อโมดูล
หากต้องการเรียกใช้โมดูลทดสอบทั้งหมด ให้ใช้ชื่อโมดูล ป้อนชื่อตามที่ปรากฏในตัวแปร LOCAL_MODULE
หรือ LOCAL_PACKAGE_NAME
ในไฟล์ Android.bp
หรือ Android.mk
ของการทดสอบนั้น
ตัวอย่าง:
atest FrameworksServicesTests
atest CtsVideoTestCases
โมดูล:คลาส
ในการรันคลาสเดียวภายในโมดูล ให้ใช้ Module:Class โมดูล จะเหมือนกับที่อธิบายไว้ใน ชื่อโมดูล คลาส คือชื่อของคลาสทดสอบในไฟล์ . .java
และสามารถเป็นชื่อคลาสแบบเต็มหรือชื่อพื้นฐานได้
ตัวอย่าง:
atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
ชื่อคลาส
ในการรันคลาสเดียวโดยไม่ระบุชื่อโมดูลอย่างชัดเจน ให้ใช้ชื่อคลาส
ตัวอย่าง:
atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest
การทดสอบการรวม Tradefed
ในการรันการทดสอบที่รวมเข้ากับ TradeFed โดยตรง (ไม่ใช่โมดูล) ให้ป้อนชื่อตามที่ปรากฏในเอาต์พุตของคำสั่ง tradefed.sh list configs
ตัวอย่างเช่น:
ในการรันการ ทดสอบ reboot.xml
:
atest example/reboot
ในการรันการ ทดสอบ native-benchmark.xml
:
atest native-benchmark
เส้นทางของไฟล์
Atest รองรับการรันทั้งการทดสอบแบบโมดูลและการทดสอบแบบรวมโดยป้อนพาธไปยังไฟล์ทดสอบหรือไดเร็กทอรีตามความเหมาะสม นอกจากนี้ยังรองรับการรันคลาสเดียวโดยระบุพาธไปยังไฟล์ Java ของคลาส รองรับทั้งเส้นทางแบบสัมพัทธ์และแบบสัมบูรณ์
เรียกใช้โมดูล
ตัวอย่างต่อไปนี้แสดงสองวิธีในการรันโมดูล CtsVideoTestCases
โดยใช้พาธไฟล์
เรียกใช้จาก Android repo-root
:
atest cts/tests/video
เรียกใช้จาก Android repo-root/cts/tests/video
:
atest .
เปิดคลาสทดสอบ
ตัวอย่างต่อไปนี้แสดงวิธีการรันคลาสเฉพาะภายในโมดูล CtsVideoTestCases
โดยใช้พาธไฟล์
จาก Android repo-root
:
atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java
เรียกใช้การทดสอบการรวม
ตัวอย่างต่อไปนี้แสดงวิธีรันการทดสอบการรวมโดยใช้เส้นทางไฟล์จาก Android repo-root
:
atest tools/tradefederation/contrib/res/config/example/reboot.xml
ชื่อแพ็คเกจ
Atest รองรับการค้นหาการทดสอบตามชื่อแพ็คเกจ
ตัวอย่าง:
atest com.android.server.wm
atest com.android.uibench.janktests
ระบุขั้นตอน: สร้าง ติดตั้ง หรือเรียกใช้
ใช้อ็อพชัน -b
, -i
และ -t
เพื่อระบุขั้นตอนที่จะรัน หากคุณไม่ระบุตัวเลือก ขั้นตอนทั้งหมดจะทำงาน
- สร้างเป้าหมายเท่านั้น:
atest -b test-to-run
- เรียกใช้การทดสอบเท่านั้น:
atest -t test-to-run
- ติดตั้ง apk และเรียกใช้การทดสอบ:
atest -it test-to-run
- สร้างและรัน แต่อย่าติดตั้ง:
atest -bt test-to-run
Atest สามารถบังคับให้การทดสอบข้ามขั้นตอนการล้างข้อมูลหรือการแยกส่วน การทดสอบหลายอย่าง เช่น CTS จะล้างข้อมูลอุปกรณ์หลังจากเรียกใช้การทดสอบ ดังนั้นการพยายามเรียกใช้การทดสอบอีกครั้งด้วย -t
จะล้มเหลวหากไม่มีพารามิเตอร์ --disable-teardown
ใช้ -d
ก่อน -t
เพื่อข้ามขั้นตอนการล้างข้อมูลการทดสอบและทดสอบซ้ำ
atest -d test-to-run
atest -t test-to-run
ใช้วิธีการเฉพาะ
Atest รองรับการรันเมธอดเฉพาะภายในคลาสการทดสอบ แม้ว่าจะต้องสร้างโมดูลทั้งหมด แต่ก็ช่วยลดเวลาที่ต้องใช้ในการทำการทดสอบ ในการรันเมธอดเฉพาะ ให้ระบุคลาสโดยใช้วิธีใดวิธีหนึ่งที่รองรับเพื่อระบุคลาส (Module:Class, file path ฯลฯ) และต่อท้ายชื่อของเมธอด:
atest reference-to-class#method1
เมื่อระบุวิธีการหลายวิธี ให้คั่นด้วยเครื่องหมายจุลภาค:
atest reference-to-class#method1,method2,method3
ตัวอย่าง:
atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval
สองตัวอย่างต่อไปนี้แสดงวิธีที่ต้องการในการรันเมธอดเดียว testFlagChange
ตัวอย่างเหล่านี้เป็นที่ต้องการมากกว่าการใช้ชื่อคลาสเท่านั้น เนื่องจากการระบุโมดูลหรือตำแหน่งไฟล์ Java ช่วยให้ Atest ค้นหาการทดสอบได้รวดเร็วยิ่งขึ้น
ใช้โมดูล:คลาส:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
จาก Android repo-root :
atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange
สามารถรันได้หลายวิธีจากคลาสและโมดูลต่างๆ:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors
เรียกใช้หลายคลาส
ในการรันหลายคลาส ให้คั่นด้วยช่องว่างในลักษณะเดียวกับการรันการทดสอบหลาย ๆ Atest สร้างและรันคลาสได้อย่างมีประสิทธิภาพ ดังนั้นการระบุชุดย่อยของคลาสในโมดูลจะช่วยเพิ่มประสิทธิภาพในการรันทั้งโมดูล
ในการรันสองคลาสในโมดูลเดียวกัน:
atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
ในการรันสองคลาสในโมดูลที่ต่างกัน:
atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
เรียกใช้ GTest ไบนารี
Atest สามารถเรียกใช้ไบนารีของ GTest ได้ ใช้ -a
เพื่อรันการทดสอบเหล่านี้สำหรับสถาปัตยกรรมอุปกรณ์ที่มีอยู่ทั้งหมด ซึ่งในตัวอย่างนี้คือ armeabi-v7a
(ARM 32 บิต) และ arm64-v8a
(ARM 64 บิต)
ตัวอย่างการทดสอบอินพุต:
atest -a libinput_tests inputflinger_tests
ในการเลือกไบนารี GTest ที่เฉพาะเจาะจงเพื่อเรียกใช้ ให้ใช้โคลอน (:) เพื่อระบุชื่อการทดสอบ และใช้แฮชแท็ก (#) เพื่อระบุวิธีการเพิ่มเติม
ตัวอย่างเช่น สำหรับคำจำกัดความการทดสอบต่อไปนี้:
TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)
เรียกใช้สิ่งต่อไปนี้เพื่อระบุการทดสอบทั้งหมด:
atest inputflinger_tests:InputDispatcherTest
หรือทำการทดสอบรายบุคคลโดยใช้สิ่งต่อไปนี้:
atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents
ทำการทดสอบใน TEST_MAPPING
Atest สามารถเรียกใช้การทดสอบในไฟล์ TEST_MAPPING
เรียกใช้การทดสอบล่วงหน้าโดยปริยาย
เรียกใช้การทดสอบล่วงหน้าในไฟล์ TEST_MAPPING
ในไดเรกทอรีปัจจุบันและไดเรกทอรีหลัก:
atest
เรียกใช้การทดสอบล่วงหน้าในไฟล์ TEST_MAPPING
ใน /path/to/project และไดเรกทอรีหลัก:
atest --test-mapping /path/to/project
เรียกใช้กลุ่มการทดสอบที่ระบุ
กลุ่มการทดสอบที่มี ได้แก่ presubmit
(default), postsubmit
, mainline-presubmit
และ all
เรียกใช้การทดสอบ postsubmit ในไฟล์ TEST_MAPPING ในไดเรกทอรีปัจจุบันและไดเรกทอรีหลัก:
<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>
เรียกใช้การทดสอบจากทุกกลุ่มในไฟล์ TEST_MAPPING:
<pre>
<code class="devsite-terminal">atest :all</code>
</pre>
เรียกใช้การทดสอบ postsubmit ในไฟล์ TEST_MAPPING ใน /path/to/project และไดเรกทอรีหลัก:
<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>
เรียกใช้การทดสอบหลักในไฟล์ TEST_MAPPING ใน /path/to/project และไดเรกทอรีหลัก:
atest --test-mapping /path/to/project:mainline-presubmit
รันการทดสอบในไดเร็กทอรีย่อย
โดยค่าเริ่มต้น Atest จะค้นหาเฉพาะการทดสอบในไฟล์ TEST_MAPPING ขึ้นไป (จากไดเร็กทอรีปัจจุบันหรือไดเร็กทอรีที่กำหนดไปยังไดเร็กทอรีหลัก) หากคุณต้องการรันการทดสอบในไฟล์ TEST_MAPPING ในไดเร็กทอรีย่อย ให้ใช้ --include-subdirs
เพื่อบังคับให้ Atest รวมการทดสอบเหล่านั้นด้วย:
atest --include-subdirs /path/to/project
เรียกใช้การทดสอบในการวนซ้ำ
รันการทดสอบในการวนซ้ำโดยส่งผ่านอาร์กิวเมนต์ --iterations
ไม่ว่าจะผ่านหรือล้มเหลว Atest จะทำการทดสอบซ้ำจนกว่าจะถึงการวนซ้ำสูงสุด
ตัวอย่าง:
โดยค่าเริ่มต้น Atest จะวนซ้ำ 10 ครั้ง จำนวนการวนซ้ำต้องเป็นจำนวนเต็มบวก
atest test-to-run --iterations
atest test-to-run --iterations 5
วิธีการต่อไปนี้ช่วยให้ตรวจหาการทดสอบที่ไม่สม่ำเสมอได้ง่ายขึ้น:
วิธีที่ 1: เรียกใช้การทดสอบทั้งหมดจนกว่าจะเกิดความล้มเหลวหรือถึงการวนซ้ำสูงสุด
- หยุดเมื่อเกิดความล้มเหลวหรือการวนซ้ำถึงรอบที่ 10 (โดยค่าเริ่มต้น)
atest test-to-run --rerun-until-failure
- หยุดเมื่อเกิดความล้มเหลวหรือการวนซ้ำถึงรอบที่ 100
atest test-to-run --rerun-until-failure 100
วิธีที่ 2: เรียกใช้การทดสอบที่ล้มเหลวเท่านั้นจนกว่าจะผ่านหรือถึงการวนซ้ำสูงสุด
- สมมติว่า
test-to-run
มีกรณีทดสอบหลายกรณีและหนึ่งในการทดสอบล้มเหลว เรียกใช้เฉพาะการทดสอบที่ล้มเหลว 10 ครั้ง (โดยค่าเริ่มต้น) หรือจนกว่าการทดสอบจะผ่านatest test-to-run --retry-any-failure
- หยุดทำการทดสอบที่ล้มเหลวเมื่อผ่านหรือถึงรอบที่ 100
atest test-to-run --retry-any-failure 100
ทำการทดสอบกับ AVDs
Atest สามารถเรียกใช้การทดสอบกับ AVD ที่สร้างขึ้นใหม่ได้ เรียกใช้ acloud create
เพื่อสร้าง AVD และสร้างอาร์ติแฟกต์ จากนั้นใช้ตัวอย่างต่อไปนี้เพื่อรันการทดสอบของคุณ
เริ่ม AVD และเรียกใช้การทดสอบ:
acloud create --local-instance --local-image && atest test-to-run
เริ่ม AVD โดยเป็นส่วนหนึ่งของการทดสอบ:
atest test-to-run --acloud-create "--local-instance --local-image"
สำหรับข้อมูลเพิ่มเติม เรียกใช้ acloud create --help
ผ่านตัวเลือกไปยังโมดูล
Atest สามารถผ่านตัวเลือกเพื่อทดสอบโมดูลได้ ในการเพิ่มตัวเลือกบรรทัดคำสั่ง TradeFed ในการรันการทดสอบของคุณ ให้ใช้โครงสร้างต่อไปนี้ และตรวจสอบให้แน่ใจว่าอาร์กิวเมนต์ที่กำหนดเองของคุณเป็นไปตามรูปแบบตัวเลือกบรรทัดคำสั่ง Tradefed
atest test-to-run -- [CUSTOM_ARGS]
ผ่านตัวเลือกโมดูลการทดสอบไปยังผู้จัดเตรียมเป้าหมายหรือผู้ดำเนินการทดสอบที่กำหนดไว้ในไฟล์กำหนดค่าการทดสอบ:
atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true
ส่งตัวเลือกไปยังประเภทนักวิ่งหรือคลาส:
atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับตัวเลือกการทดสอบเท่านั้น โปรดดูที่ ส่งตัวเลือกไปยังโมดูล
,Atest เป็นเครื่องมือบรรทัดคำสั่งที่อนุญาตให้ผู้ใช้สร้าง ติดตั้ง และเรียกใช้การทดสอบ Android ในเครื่อง เร่งการรันการทดสอบซ้ำได้อย่างมากโดยไม่ต้องมีความรู้เกี่ยวกับตัวเลือกบรรทัดคำสั่ง ชุดทดสอบของ Trade Federation หน้านี้อธิบายวิธีใช้ Atest เพื่อเรียกใช้การทดสอบ Android
สำหรับข้อมูลทั่วไปเกี่ยวกับการทดสอบการเขียนสำหรับ Android โปรดดูที่ การทดสอบแพลตฟอร์ม Android
สำหรับข้อมูลเกี่ยวกับโครงสร้างโดยรวมของ Atest โปรดดูที่ คู่มือนักพัฒนา Atest
สำหรับข้อมูลเกี่ยวกับการเรียกใช้การทดสอบในไฟล์ TEST_MAPPING ผ่าน Atest โปรดดูที่ การเรียกใช้การทดสอบในไฟล์ TEST_MAPPING
ในการเพิ่มคุณสมบัติให้กับ Atest ให้ทำตาม Atest Developer Workflow
การตั้งค่าสภาพแวดล้อมของคุณ
ทำตามขั้นตอนในหัวข้อต่อไปนี้เพื่อตั้งค่าสภาพแวดล้อม Atest ของคุณ
ตั้งค่าตัวแปรสภาพแวดล้อม
ตั้งค่า test_suite
สำหรับ Soong หรือ LOCAL_COMPATIBILITY_SUITE
สำหรับ Make กฎสคริปต์ build build ต่อไป
เรียกใช้ envsetup.sh
จากรูทของการชำระเงินต้นทาง Android ให้เรียกใช้:
source build/envsetup.sh
วิ่ง lunch
เรียกใช้คำสั่ง lunch
เพื่อเปิดเมนูของอุปกรณ์ที่รองรับ ค้นหาอุปกรณ์และเรียกใช้คำสั่งนั้น
ตัวอย่างเช่น หากคุณมีอุปกรณ์ ARM เชื่อมต่ออยู่ ให้รันคำสั่งต่อไปนี้:
lunch aosp_arm64-eng
สิ่งนี้จะตั้งค่าตัวแปรสภาพแวดล้อมต่างๆ ที่จำเป็นสำหรับการรัน Atest และเพิ่มคำสั่ง Atest ให้กับ $PATH
ของคุณ
การใช้งานพื้นฐาน
คำสั่ง Atest มีรูปแบบดังต่อไปนี้:
atest test-to-run [optional-arguments]
อาร์กิวเมนต์ทางเลือก
ตารางต่อไปนี้แสดงรายการอาร์กิวเมนต์ที่ใช้บ่อยที่สุด รายการทั้งหมดมีอยู่ atest --help
ตัวเลือก | ตัวเลือกยาว | คำอธิบาย |
---|---|---|
-b | --build | สร้างเป้าหมายการทดสอบ (ค่าเริ่มต้น) |
-i | --install | ติดตั้งสิ่งประดิษฐ์ทดสอบ (APK) บนอุปกรณ์ (ค่าเริ่มต้น) |
-t | --test | ดำเนินการทดสอบ (ค่าเริ่มต้น) |
-s | --serial | รันการทดสอบบนอุปกรณ์ที่ระบุ สามารถทดสอบอุปกรณ์ได้ครั้งละหนึ่งเครื่อง |
-d | --disable-teardown | ปิดใช้งานการทดสอบการฉีกขาดและการล้างข้อมูล |
<c> | --info | แสดงข้อมูลที่เกี่ยวข้องเกี่ยวกับเป้าหมายที่ระบุ จากนั้นออก |
<c> | --dry-run | Atest แบบแห้งโดยไม่ต้องสร้าง ติดตั้ง หรือรันการทดสอบจริงๆ |
-m | --rebuild-module-info | บังคับให้สร้างไฟล์ module-info.json ขึ้นใหม่ |
-w | --wait-for-debugger | รอให้ดีบักเกอร์เสร็จสิ้นก่อนที่จะดำเนินการ |
-v | --verbose | แสดงการบันทึกระดับ DEBUG |
<c> | --iterations | การทดสอบแบบวนซ้ำจนกว่าจะถึงการวนซ้ำสูงสุด (10 โดยค่าเริ่มต้น) |
<c> | --rerun-until-failure [COUNT=10] | รันการทดสอบทั้งหมดซ้ำจนกว่าจะเกิดความล้มเหลวหรือถึงการวนซ้ำสูงสุด (10 โดยค่าเริ่มต้น) |
<c> | --retry-any-failure [COUNT=10] | เรียกใช้การทดสอบที่ล้มเหลวซ้ำจนกว่าจะผ่านหรือถึงการวนซ้ำสูงสุด (10 โดยค่าเริ่มต้น) |
<c> | --start-avd | สร้าง AVD โดยอัตโนมัติและเรียกใช้การทดสอบบนอุปกรณ์เสมือน |
<c> | --acloud-create | สร้าง AVD โดยใช้คำสั่ง acloud |
<c> | --[CUSTOM_ARGS] | ระบุอาร์กิวเมนต์ที่กำหนดเองสำหรับนักวิ่งทดสอบ |
-a | --all-abi | เรียกใช้การทดสอบสถาปัตยกรรมอุปกรณ์ที่มีอยู่ทั้งหมด |
<c> | --host | รันการทดสอบอย่างสมบูรณ์บนโฮสต์โดยไม่ต้องใช้อุปกรณ์ หมายเหตุ: การรันการทดสอบโฮสต์ที่ต้องใช้อุปกรณ์ที่มี --host จะล้มเหลว |
<c> | --flakes-info | แสดงผลการทดสอบพร้อมข้อมูลเกล็ด |
<c> | --history | แสดงผลการทดสอบตามลำดับเวลา |
<c> | --latest-result | พิมพ์ผลการทดสอบล่าสุด |
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ -b
, -i
และ -t
โปรดดูส่วน ระบุขั้นตอน: สร้าง ติดตั้ง หรือรัน
ระบุการทดสอบ
ในการรันการทดสอบ ให้ระบุการทดสอบอย่างน้อยหนึ่งรายการโดยใช้ตัวระบุต่อไปนี้:
- ชื่อโมดูล
- โมดูล:คลาส
- ชื่อคลาส
- การทดสอบการรวม Tradefed
- เส้นทางของไฟล์
- ชื่อแพ็คเกจ
แยกการอ้างอิงถึงการทดสอบหลายรายการด้วยการเว้นวรรคดังนี้:
atest test-identifier-1 test-identifier-2
ชื่อโมดูล
หากต้องการเรียกใช้โมดูลทดสอบทั้งหมด ให้ใช้ชื่อโมดูล ป้อนชื่อตามที่ปรากฏในตัวแปร LOCAL_MODULE
หรือ LOCAL_PACKAGE_NAME
ในไฟล์ Android.bp
หรือ Android.mk
ของการทดสอบนั้น
ตัวอย่าง:
atest FrameworksServicesTests
atest CtsVideoTestCases
โมดูล:คลาส
ในการรันคลาสเดียวภายในโมดูล ให้ใช้ Module:Class โมดูล จะเหมือนกับที่อธิบายไว้ใน ชื่อโมดูล คลาส คือชื่อของคลาสทดสอบในไฟล์ . .java
และสามารถเป็นชื่อคลาสแบบเต็มหรือชื่อพื้นฐานได้
ตัวอย่าง:
atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests
ชื่อคลาส
ในการรันคลาสเดียวโดยไม่ระบุชื่อโมดูลอย่างชัดเจน ให้ใช้ชื่อคลาส
ตัวอย่าง:
atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest
การทดสอบการรวม Tradefed
ในการรันการทดสอบที่รวมเข้ากับ TradeFed โดยตรง (ไม่ใช่โมดูล) ให้ป้อนชื่อตามที่ปรากฏในเอาต์พุตของคำสั่ง tradefed.sh list configs
ตัวอย่างเช่น:
ในการรันการ ทดสอบ reboot.xml
:
atest example/reboot
ในการรันการ ทดสอบ native-benchmark.xml
:
atest native-benchmark
เส้นทางของไฟล์
Atest รองรับการรันทั้งการทดสอบแบบโมดูลและการทดสอบแบบรวมโดยป้อนพาธไปยังไฟล์ทดสอบหรือไดเร็กทอรีตามความเหมาะสม นอกจากนี้ยังรองรับการรันคลาสเดียวโดยระบุพาธไปยังไฟล์ Java ของคลาส รองรับทั้งเส้นทางแบบสัมพัทธ์และแบบสัมบูรณ์
เรียกใช้โมดูล
ตัวอย่างต่อไปนี้แสดงสองวิธีในการรันโมดูล CtsVideoTestCases
โดยใช้พาธไฟล์
เรียกใช้จาก Android repo-root
:
atest cts/tests/video
เรียกใช้จาก Android repo-root/cts/tests/video
:
atest .
เปิดคลาสทดสอบ
ตัวอย่างต่อไปนี้แสดงวิธีการรันคลาสเฉพาะภายในโมดูล CtsVideoTestCases
โดยใช้พาธไฟล์
จาก Android repo-root
:
atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java
เรียกใช้การทดสอบการรวม
ตัวอย่างต่อไปนี้แสดงวิธีรันการทดสอบการรวมโดยใช้เส้นทางไฟล์จาก Android repo-root
:
atest tools/tradefederation/contrib/res/config/example/reboot.xml
ชื่อแพ็คเกจ
Atest รองรับการค้นหาการทดสอบตามชื่อแพ็คเกจ
ตัวอย่าง:
atest com.android.server.wm
atest com.android.uibench.janktests
ระบุขั้นตอน: สร้าง ติดตั้ง หรือเรียกใช้
ใช้อ็อพชัน -b
, -i
และ -t
เพื่อระบุขั้นตอนที่จะรัน หากคุณไม่ระบุตัวเลือก ขั้นตอนทั้งหมดจะทำงาน
- สร้างเป้าหมายเท่านั้น:
atest -b test-to-run
- เรียกใช้การทดสอบเท่านั้น:
atest -t test-to-run
- ติดตั้ง apk และเรียกใช้การทดสอบ:
atest -it test-to-run
- สร้างและรัน แต่อย่าติดตั้ง:
atest -bt test-to-run
Atest สามารถบังคับให้การทดสอบข้ามขั้นตอนการล้างข้อมูลหรือการแยกส่วน การทดสอบหลายอย่าง เช่น CTS จะล้างข้อมูลอุปกรณ์หลังจากเรียกใช้การทดสอบ ดังนั้นการพยายามเรียกใช้การทดสอบอีกครั้งด้วย -t
จะล้มเหลวหากไม่มีพารามิเตอร์ --disable-teardown
ใช้ -d
ก่อน -t
เพื่อข้ามขั้นตอนการล้างข้อมูลการทดสอบและทดสอบซ้ำ
atest -d test-to-run
atest -t test-to-run
ใช้วิธีการเฉพาะ
Atest รองรับการรันเมธอดเฉพาะภายในคลาสการทดสอบ แม้ว่าจะต้องสร้างโมดูลทั้งหมด แต่ก็ช่วยลดเวลาที่ต้องใช้ในการทำการทดสอบ ในการรันเมธอดเฉพาะ ให้ระบุคลาสโดยใช้วิธีใดวิธีหนึ่งที่รองรับเพื่อระบุคลาส (Module:Class, file path ฯลฯ) และต่อท้ายชื่อของเมธอด:
atest reference-to-class#method1
เมื่อระบุวิธีการหลายวิธี ให้คั่นด้วยเครื่องหมายจุลภาค:
atest reference-to-class#method1,method2,method3
ตัวอย่าง:
atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval
สองตัวอย่างต่อไปนี้แสดงวิธีที่ต้องการในการรันเมธอดเดียว testFlagChange
ตัวอย่างเหล่านี้เป็นที่ต้องการมากกว่าการใช้ชื่อคลาสเท่านั้น เนื่องจากการระบุโมดูลหรือตำแหน่งไฟล์ Java ช่วยให้ Atest ค้นหาการทดสอบได้รวดเร็วยิ่งขึ้น
ใช้โมดูล:คลาส:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
จาก Android repo-root :
atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange
สามารถรันได้หลายวิธีจากคลาสและโมดูลต่างๆ:
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors
เรียกใช้หลายคลาส
ในการรันหลายคลาส ให้คั่นด้วยช่องว่างในลักษณะเดียวกับการรันการทดสอบหลาย ๆ Atest สร้างและรันคลาสได้อย่างมีประสิทธิภาพ ดังนั้นการระบุชุดย่อยของคลาสในโมดูลจะช่วยเพิ่มประสิทธิภาพในการรันทั้งโมดูล
ในการรันสองคลาสในโมดูลเดียวกัน:
atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests
ในการรันสองคลาสในโมดูลที่ต่างกัน:
atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest
เรียกใช้ GTest ไบนารี
Atest สามารถเรียกใช้ไบนารีของ GTest ได้ ใช้ -a
เพื่อรันการทดสอบเหล่านี้สำหรับสถาปัตยกรรมอุปกรณ์ที่มีอยู่ทั้งหมด ซึ่งในตัวอย่างนี้คือ armeabi-v7a
(ARM 32 บิต) และ arm64-v8a
(ARM 64 บิต)
ตัวอย่างการทดสอบอินพุต:
atest -a libinput_tests inputflinger_tests
ในการเลือกไบนารี GTest ที่เฉพาะเจาะจงเพื่อเรียกใช้ ให้ใช้โคลอน (:) เพื่อระบุชื่อการทดสอบ และใช้แฮชแท็ก (#) เพื่อระบุวิธีการเพิ่มเติม
ตัวอย่างเช่น สำหรับคำจำกัดความการทดสอบต่อไปนี้:
TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)
เรียกใช้สิ่งต่อไปนี้เพื่อระบุการทดสอบทั้งหมด:
atest inputflinger_tests:InputDispatcherTest
หรือทำการทดสอบรายบุคคลโดยใช้สิ่งต่อไปนี้:
atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents
ทำการทดสอบใน TEST_MAPPING
Atest สามารถเรียกใช้การทดสอบในไฟล์ TEST_MAPPING
เรียกใช้การทดสอบล่วงหน้าโดยปริยาย
เรียกใช้การทดสอบล่วงหน้าในไฟล์ TEST_MAPPING
ในไดเรกทอรีปัจจุบันและไดเรกทอรีหลัก:
atest
เรียกใช้การทดสอบล่วงหน้าในไฟล์ TEST_MAPPING
ใน /path/to/project และไดเรกทอรีหลัก:
atest --test-mapping /path/to/project
เรียกใช้กลุ่มการทดสอบที่ระบุ
กลุ่มการทดสอบที่มี ได้แก่ presubmit
(default), postsubmit
, mainline-presubmit
และ all
เรียกใช้การทดสอบ postsubmit ในไฟล์ TEST_MAPPING ในไดเรกทอรีปัจจุบันและไดเรกทอรีหลัก:
<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>
เรียกใช้การทดสอบจากทุกกลุ่มในไฟล์ TEST_MAPPING:
<pre>
<code class="devsite-terminal">atest :all</code>
</pre>
เรียกใช้การทดสอบ postsubmit ในไฟล์ TEST_MAPPING ใน /path/to/project และไดเรกทอรีหลัก:
<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>
เรียกใช้การทดสอบหลักในไฟล์ TEST_MAPPING ใน /path/to/project และไดเรกทอรีหลัก:
atest --test-mapping /path/to/project:mainline-presubmit
รันการทดสอบในไดเร็กทอรีย่อย
โดยค่าเริ่มต้น Atest จะค้นหาเฉพาะการทดสอบในไฟล์ TEST_MAPPING ขึ้นไป (จากไดเร็กทอรีปัจจุบันหรือไดเร็กทอรีที่กำหนดไปยังไดเร็กทอรีหลัก) หากคุณต้องการรันการทดสอบในไฟล์ TEST_MAPPING ในไดเร็กทอรีย่อย ให้ใช้ --include-subdirs
เพื่อบังคับให้ Atest รวมการทดสอบเหล่านั้นด้วย:
atest --include-subdirs /path/to/project
เรียกใช้การทดสอบในการวนซ้ำ
รันการทดสอบในการวนซ้ำโดยส่งผ่านอาร์กิวเมนต์ --iterations
ไม่ว่าจะผ่านหรือล้มเหลว Atest จะทำการทดสอบซ้ำจนกว่าจะถึงการวนซ้ำสูงสุด
ตัวอย่าง:
โดยค่าเริ่มต้น Atest จะวนซ้ำ 10 ครั้ง จำนวนการวนซ้ำต้องเป็นจำนวนเต็มบวก
atest test-to-run --iterations
atest test-to-run --iterations 5
วิธีการต่อไปนี้ช่วยให้ตรวจหาการทดสอบที่ไม่สม่ำเสมอได้ง่ายขึ้น:
วิธีที่ 1: เรียกใช้การทดสอบทั้งหมดจนกว่าจะเกิดความล้มเหลวหรือถึงการวนซ้ำสูงสุด
- หยุดเมื่อเกิดความล้มเหลวหรือการวนซ้ำถึงรอบที่ 10 (โดยค่าเริ่มต้น)
atest test-to-run --rerun-until-failure
- หยุดเมื่อเกิดความล้มเหลวหรือการวนซ้ำถึงรอบที่ 100
atest test-to-run --rerun-until-failure 100
วิธีที่ 2: เรียกใช้การทดสอบที่ล้มเหลวเท่านั้นจนกว่าจะผ่านหรือถึงการวนซ้ำสูงสุด
- สมมติว่า
test-to-run
มีกรณีทดสอบหลายกรณีและหนึ่งในการทดสอบล้มเหลว เรียกใช้เฉพาะการทดสอบที่ล้มเหลว 10 ครั้ง (โดยค่าเริ่มต้น) หรือจนกว่าการทดสอบจะผ่านatest test-to-run --retry-any-failure
- หยุดทำการทดสอบที่ล้มเหลวเมื่อผ่านหรือถึงรอบที่ 100
atest test-to-run --retry-any-failure 100
ทำการทดสอบกับ AVDs
Atest สามารถเรียกใช้การทดสอบกับ AVD ที่สร้างขึ้นใหม่ได้ เรียกใช้ acloud create
เพื่อสร้าง AVD และสร้างอาร์ติแฟกต์ จากนั้นใช้ตัวอย่างต่อไปนี้เพื่อรันการทดสอบของคุณ
เริ่ม AVD และเรียกใช้การทดสอบ:
acloud create --local-instance --local-image && atest test-to-run
เริ่ม AVD โดยเป็นส่วนหนึ่งของการทดสอบ:
atest test-to-run --acloud-create "--local-instance --local-image"
สำหรับข้อมูลเพิ่มเติม เรียกใช้ acloud create --help
ผ่านตัวเลือกไปยังโมดูล
Atest สามารถผ่านตัวเลือกเพื่อทดสอบโมดูลได้ ในการเพิ่มตัวเลือกบรรทัดคำสั่ง TradeFed ในการรันการทดสอบของคุณ ให้ใช้โครงสร้างต่อไปนี้ และตรวจสอบให้แน่ใจว่าอาร์กิวเมนต์ที่กำหนดเองของคุณเป็นไปตามรูปแบบตัวเลือกบรรทัดคำสั่ง Tradefed
atest test-to-run -- [CUSTOM_ARGS]
ผ่านตัวเลือกโมดูลการทดสอบไปยังผู้จัดเตรียมเป้าหมายหรือผู้ดำเนินการทดสอบที่กำหนดไว้ในไฟล์กำหนดค่าการทดสอบ:
atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true
ส่งตัวเลือกไปยังประเภทนักวิ่งหรือคลาส:
atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับตัวเลือกการทดสอบเท่านั้น โปรดดูที่ ส่งตัวเลือกไปยังโมดูล