นี่คือการแนะนำโดยย่อเกี่ยวกับการแมปการทดสอบและคำอธิบายวิธีเริ่มต้นการกำหนดค่าการทดสอบอย่างง่ายดายใน Android Open Source Project (AOSP)
เกี่ยวกับการทำแผนที่ทดสอบ
การทำแผนที่ทดสอบเป็นแนวทางที่ใช้ Gerrit ซึ่งช่วยให้นักพัฒนาสามารถสร้างกฎการทดสอบก่อนและหลังส่งได้โดยตรงในแผนผังต้นทางของ Android และปล่อยให้การตัดสินใจของสาขาและอุปกรณ์ทดสอบกับโครงสร้างพื้นฐานการทดสอบเอง คำจำกัดความของการแมปทดสอบคือไฟล์ JSON ชื่อ TEST_MAPPING ซึ่งสามารถวางไว้ในไดเร็กทอรีต้นทางใดก็ได้
Atest สามารถใช้ไฟล์ TEST_MAPPING เพื่อเรียกใช้การทดสอบล่วงหน้าในไดเรกทอรีที่เกี่ยวข้อง ด้วยการแมปการทดสอบ คุณสามารถเพิ่มชุดการทดสอบเดียวกันเพื่อส่งการตรวจสอบล่วงหน้าด้วยการเปลี่ยนแปลงง่ายๆ ภายในแผนผังต้นทางของ Android
ดูตัวอย่างเหล่านี้:
เพิ่มการทดสอบล่วงหน้าส่งไปที่ TEST_MAPPING สำหรับ services.core
เพิ่มการทดสอบล่วงหน้าส่งไปที่ TEST_MAPPING สำหรับเครื่องมือ/เด็กซ์เตอร์โดยใช้การนำเข้า
การทำแผนที่การทดสอบอาศัย ชุดทดสอบของสหพันธ์การค้า (TF) สำหรับการดำเนินการทดสอบและการรายงานผลลัพธ์
กำหนดกลุ่มทดสอบ
ทดสอบกลุ่มการแมป ทดสอบผ่าน กลุ่มทดสอบ ชื่อของกลุ่มทดสอบอาจเป็นสตริงใดก็ได้ ตัวอย่างเช่น การส่งล่วงหน้า อาจเป็นเพื่อให้กลุ่มการทดสอบทำงานเมื่อตรวจสอบความถูกต้องของการเปลี่ยนแปลง และการทดสอบ ภายหลังการส่ง สามารถใช้เพื่อตรวจสอบความถูกต้องของบิลด์หลังจากรวมการเปลี่ยนแปลงเข้าด้วยกัน
กฎสคริปต์การสร้างแพ็กเกจ
เพื่อให้ Trade Federation Test Harness รันโมดูลทดสอบของการแม็ปทดสอบสำหรับบิลด์ที่กำหนด โมดูลเหล่านี้ต้องมีชุด test_suite สำหรับ Soong หรือชุด LOCAL_COMPATIBILITY_SUITE สำหรับ Make เป็นหนึ่งในสองชุดนี้:
- การทดสอบทั่วไป - การทดสอบที่ไม่ขึ้นอยู่กับฟังก์ชันการทำงานเฉพาะอุปกรณ์ (เช่น ฮาร์ดแวร์เฉพาะผู้จำหน่ายที่อุปกรณ์ส่วนใหญ่ไม่มี) การทดสอบส่วนใหญ่ควรอยู่ในชุดการทดสอบทั่วไป แม้ว่าการทดสอบจะเจาะจงกับ ABI หนึ่งรายการหรือ bitness หรือฟีเจอร์ฮาร์ดแวร์ เช่น HWASan (มีเป้าหมาย test_suites แยกต่างหากสำหรับ ABI แต่ละรายการ) และแม้ว่าการทดสอบเหล่านั้นจะต้องทำงานบนอุปกรณ์ก็ตาม
- การทดสอบอุปกรณ์ - การทดสอบที่ขึ้นอยู่กับฟังก์ชันการทำงานเฉพาะของอุปกรณ์ โดยปกติแล้วการทดสอบเหล่านี้จะอยู่ภายใต้
vendor/
เนื่องจาก "อุปกรณ์เฉพาะ" ไม่ได้อ้างถึงฟังก์ชัน ABI หรือ SoC ที่อุปกรณ์อื่นอาจมีหรือไม่มี แต่เฉพาะฟังก์ชันการทำงานที่เป็นเอกลักษณ์เฉพาะของ อุปกรณ์ เท่านั้น สิ่งนี้จึงใช้กับการทดสอบ JUnit ทุกบิตมากเท่ากับการทดสอบเนทิฟของ Gtest (ซึ่งโดยปกติควร เป็นการgeneral-tests
แม้ว่าจะเป็นการทดสอบเฉพาะของ ABI ก็ตาม)
ตัวอย่าง:
Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests
กำหนดค่าการทดสอบให้ทำงานในชุดการทดสอบ
หากต้องการให้การทดสอบทำงานภายในชุดการทดสอบ การทดสอบ:
- ต้องไม่มีผู้ให้บริการบิลด์ใดๆ
- ต้องล้างข้อมูลหลังจากเสร็จสิ้น เช่น ด้วยการลบไฟล์ชั่วคราวใดๆ ที่สร้างขึ้นระหว่างการทดสอบ
- เปลี่ยนการตั้งค่าระบบเป็นค่าเริ่มต้นหรือค่าดั้งเดิม
- ไม่ควรถือว่าอุปกรณ์อยู่ในสถานะใดสถานะหนึ่ง เช่น พร้อมรูทแล้ว การทดสอบส่วนใหญ่ไม่ต้องการสิทธิ์รูทในการทำงาน หากการทดสอบต้องใช้ root ก็ควรระบุด้วย
RootTargetPreparer
ในAndroidTest.xml
ดังตัวอย่างต่อไปนี้:
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
สร้างไฟล์การแมปทดสอบ
สำหรับไดเร็กทอรีที่ต้องการความครอบคลุมการทดสอบ เพียงเพิ่มไฟล์ TEST_MAPPING JSON ที่คล้ายกับตัวอย่างด้านล่าง กฎเหล่านี้จะรับประกันว่าการทดสอบจะดำเนินการในการตรวจสอบล่วงหน้าเมื่อมีการแตะไฟล์ใดๆ ในไดเร็กทอรีนั้นหรือในไดเร็กทอรีย่อยใดๆ
ทำตามตัวอย่าง
นี่คือตัวอย่างไฟล์ TEST_MAPPING
(อยู่ในรูปแบบ JSON แต่รองรับความคิดเห็น):
{
"presubmit": [
// JUnit test with options and file patterns.
{
"name": "CtsWindowManagerDeviceTestCases",
"options": [
{
"include-annotation": "android.platform.test.annotations.RequiresDevice"
}
],
"file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
},
// Device-side GTest with options.
{
"name" : "hello_world_test",
"options": [
{
"native-test-flag": "\"servicename1 servicename2\""
},
{
"native-test-timeout": "6000"
}
]
}
// Host-side GTest.
{
"name" : "net_test_avrcp",
"host" : true
}
],
"postsubmit": [
{
"name": "CtsWindowManagerDeviceTestCases"
}
],
"imports": [
{
"path": "frameworks/base/services/core/java/com/android/server/am"
}
]
}
ตั้งค่าคุณสมบัติ
ในตัวอย่างข้างต้น presubmit
และ postsubmit
เป็นชื่อของแต่ละ กลุ่มการทดสอบ ดู การกำหนดกลุ่มการทดสอบ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับกลุ่มการทดสอบ
ชื่อ ของ โมดูลการทดสอบ หรือ ชื่อการทดสอบการรวมสหพันธ์การค้า (เส้นทางทรัพยากรไปยังไฟล์ XML ทดสอบ เช่น uiautomator/uiautomator-demo ) สามารถตั้งค่าในค่าของแอตทริบิวต์ name
ได้ หมายเหตุฟิลด์ ชื่อ ไม่สามารถใช้ name
คลาสหรือ name
วิธีทดสอบ หากต้องการจำกัดการทดสอบให้แคบลง คุณสามารถใช้ตัวเลือกต่างๆ เช่น include-filter
ที่นี่ ดู ( การใช้ตัวอย่างรวมตัวกรอง )
การตั้งค่า โฮสต์ ของการทดสอบจะระบุว่าการทดสอบนั้นเป็นการทดสอบแบบไร้อุปกรณ์ที่ทำงานบนโฮสต์หรือไม่ ค่าเริ่มต้นคือ false ซึ่งหมายความว่าการทดสอบต้องใช้อุปกรณ์ในการทำงาน ประเภทการทดสอบที่รองรับ ได้แก่ HostGTest สำหรับไบนารี Gtest และ HostTest สำหรับการทดสอบ JUnit
แอตทริบิวต์ file_patterns ช่วยให้คุณสามารถตั้งค่ารายการสตริง regex สำหรับการจับคู่เส้นทางสัมพัทธ์ของไฟล์ซอร์สโค้ดใดๆ (สัมพันธ์กับไดเร็กทอรีที่มีไฟล์ TEST_MAPPING) ในตัวอย่างข้างต้น การทดสอบ CtsWindowManagerDeviceTestCases
จะทำงานในการส่งล่วงหน้าเฉพาะเมื่อไฟล์ java ใดๆ เริ่มต้นด้วย Window หรือ Activity ซึ่งมีอยู่ในไดเร็กทอรีเดียวกันของไฟล์ TEST_MAPPING หรือไดเร็กทอรีย่อยใดๆ ของไฟล์นั้น มีการเปลี่ยนแปลง แบ็กสแลช \ จำเป็นต้องหลีกหนีเนื่องจากอยู่ในไฟล์ JSON
แอตทริบิวต์ การนำเข้า ช่วยให้คุณสามารถรวมการทดสอบในไฟล์ TEST_MAPPING อื่น ๆ โดยไม่ต้องคัดลอกเนื้อหา โปรดทราบว่าไฟล์ TEST_MAPPING ในไดเรกทอรีหลักของเส้นทางที่นำเข้าจะถูกรวมไว้ด้วย การทดสอบการแมปช่วยให้สามารถนำเข้าแบบซ้อนกันได้ ซึ่งหมายความว่าไฟล์ TEST_MAPPING สองไฟล์สามารถนำเข้าซึ่งกันและกันได้ และการทำแผนที่ทดสอบสามารถรวมการทดสอบที่รวมไว้ได้อย่างถูกต้อง
แอตทริบิวต์ options มีตัวเลือกบรรทัดคำสั่ง TradeFed เพิ่มเติม
หากต้องการดูรายการตัวเลือกทั้งหมดสำหรับการทดสอบที่กำหนด ให้รัน:
tradefed.sh run commandAndExit [test_module] --help
โปรดดู การจัดการออปชั่นของ TradeFed สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับวิธีการทำงานของออปชั่น
ทำการทดสอบด้วย Atest
หากต้องการดำเนินการกฎการทดสอบล่วงหน้าส่งภายในเครื่อง:
- ไปที่ไดเร็กทอรีที่มีไฟล์ TEST_MAPPING
- รันคำสั่ง:
atest
การทดสอบก่อนส่งทั้งหมดที่กำหนดค่าไว้ในไฟล์ TEST_MAPPING ของไดเร็กทอรีปัจจุบันและไดเร็กทอรีพาเรนต์จะถูกรัน Atest จะค้นหาและดำเนินการการทดสอบสองครั้งสำหรับการส่งล่วงหน้า (A และ B)
นี่เป็นวิธีที่ง่ายที่สุดในการรันการทดสอบก่อนส่งในไฟล์ TEST_MAPPING ในไดเร็กทอรีการทำงานปัจจุบัน (CWD) และไดเร็กทอรีหลัก Atest จะค้นหาและใช้ไฟล์ TEST_MAPPING ใน CWD และไดเรกทอรีหลักทั้งหมด
ซอร์สโค้ดโครงสร้าง
ตัวอย่างต่อไปนี้แสดงวิธีกำหนดค่าไฟล์ TEST_MAPPING ในแผนผังต้นทาง
src
├── project_1
│ └── TEST_MAPPING
├── project_2
│ └── TEST_MAPPING
└── TEST_MAPPING
เนื้อหาของ src/TEST_MAPPING
:
{
"presubmit": [
{
"name": "A"
}
]
}
เนื้อหาของ src/project_1/TEST_MAPPING
:
{
"presubmit": [
{
"name": "B"
}
],
"postsubmit": [
{
"name": "C"
}
],
"other_group": [
{
"name": "X"
}
]}
เนื้อหาของ src/project_2/TEST_MAPPING
:
{
"presubmit": [
{
"name": "D"
}
],
"import": [
{
"path": "src/project_1"
}
]}
ระบุไดเรกทอรีเป้าหมาย
คุณสามารถระบุไดเร็กทอรีเป้าหมายเพื่อรันการทดสอบในไฟล์ TEST_MAPPING ในไดเร็กทอรีนั้น คำสั่งต่อไปนี้จะทำการทดสอบสองครั้ง (A, B)
atest --test-mapping src/project_1
เรียกใช้กฎการทดสอบหลังส่ง
คุณยังสามารถใช้คำสั่งนี้เพื่อรันกฎการทดสอบภายหลังการส่งที่กำหนดใน TEST_MAPPING ใน src_path
(ค่าเริ่มต้นคือ CWD) และไดเร็กทอรีพาเรนต์:
atest [--test-mapping] [src_path]:postsubmit
รันการทดสอบที่ไม่ต้องใช้อุปกรณ์เท่านั้น
คุณสามารถใช้ตัวเลือก --host สำหรับ Atest เพื่อรันการทดสอบที่กำหนดค่ากับโฮสต์ที่ไม่ต้องใช้อุปกรณ์เท่านั้น หากไม่มีตัวเลือกนี้ Atest จะทำการทดสอบทั้งสองแบบ การทดสอบที่ต้องใช้อุปกรณ์และการทดสอบที่ทำงานบนโฮสต์และไม่ต้องใช้อุปกรณ์ การทดสอบจะดำเนินการในสองชุดแยกกัน
atest [--test-mapping] --host
ระบุกลุ่มทดสอบ
คุณสามารถระบุกลุ่มการทดสอบในคำสั่ง Atest คำสั่งต่อไปนี้จะเรียกใช้การทดสอบ หลังส่ง ทั้งหมดที่เกี่ยวข้องกับไฟล์ในไดเร็กทอรี src/project_1 ซึ่งมีการทดสอบเดียว (C)
หรือคุณสามารถใช้ :all เพื่อทำการทดสอบทั้งหมดโดยไม่คำนึงถึงกลุ่ม คำสั่งต่อไปนี้รันการทดสอบสี่ครั้ง (A, B, C, X):
atest --test-mapping src/project_1:all
รวมไดเรกทอรีย่อย
ตามค่าเริ่มต้น การรันการทดสอบใน TEST_MAPPING ด้วย Atest จะรันเฉพาะการทดสอบก่อนส่งที่กำหนดค่าไว้ในไฟล์ TEST_MAPPING ใน CWD (หรือไดเร็กทอรีที่กำหนด) และไดเร็กทอรีพาเรนต์ หากคุณต้องการรันการทดสอบในไฟล์ TEST_MAPPING ทั้งหมดในไดเรกทอรีย่อย ให้ใช้ตัวเลือก --include-subdir
เพื่อบังคับให้ Atest รวมการทดสอบเหล่านั้นด้วย
atest --include-subdir
หากไม่มีตัวเลือก --include-subdir
Atest จะดำเนินการเฉพาะการทดสอบ A เท่านั้น ด้วยตัวเลือก --include-subdir
Atest จะทำการทดสอบสองครั้ง (A, B)
รองรับความคิดเห็นระดับบรรทัด
คุณสามารถเพิ่มความคิดเห็นระดับบรรทัด //
-format เพื่อขยายไฟล์ TEST_MAPPING พร้อมคำอธิบายการตั้งค่าที่ตามมา ATest และสหพันธ์การค้าจะประมวลผล TEST_MAPPING ล่วงหน้าเป็นรูปแบบ JSON ที่ถูกต้องโดยไม่มีความคิดเห็น เพื่อให้ไฟล์ JSON สะอาดและอ่านง่าย รองรับเฉพาะความคิดเห็นระดับบรรทัด //
-format เท่านั้น
ตัวอย่าง:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}