นี่คือข้อมูลเบื้องต้นเกี่ยวกับการจับคู่การทดสอบและคำอธิบายเกี่ยวกับวิธีเริ่มต้นกำหนดค่าการทดสอบในโครงการโอเพนซอร์ส Android (AOSP)
เกี่ยวกับการจับคู่การทดสอบ
การจับคู่การทดสอบเป็นแนวทางที่อิงตาม Gerrit ซึ่งช่วยให้นักพัฒนาซอฟต์แวร์สร้างกฎการทดสอบก่อนส่งและหลังส่งได้โดยตรงในโครงสร้างซอร์สของ Android และปล่อยให้โครงสร้างพื้นฐานการทดสอบเป็นผู้พิจารณาสาขาและอุปกรณ์ที่จะทดสอบ
คำจำกัดความของการจับคู่การทดสอบคือไฟล์ JSON ที่ชื่อ TEST_MAPPING ซึ่งคุณวางไว้ในไดเรกทอรีต้นทางใดก็ได้
Atest สามารถใช้ไฟล์ TEST_MAPPING เพื่อเรียกใช้การทดสอบก่อนส่งในไดเรกทอรีที่เชื่อมโยง
การจับคู่การทดสอบช่วยให้คุณเพิ่มชุดการทดสอบชุดเดียวกันลงในการตรวจสอบก่อนส่งได้โดยมีการเปลี่ยนแปลงน้อยที่สุดภายในโครงสร้างซอร์สของ Android
ดูตัวอย่างต่อไปนี้
การจับคู่การทดสอบอาศัยชุดทดสอบ Trade Federation (TF) ในการดำเนินการทดสอบและการรายงานผลลัพธ์
กำหนดกลุ่มทดสอบ
การจับคู่การทดสอบจะจัดกลุ่มการทดสอบด้วย กลุ่มทดสอบ ชื่อของกลุ่มทดสอบจะเป็นสตริงใดก็ได้ เช่น presubmit อาจเป็นชื่อของกลุ่มการทดสอบที่จะเรียกใช้เมื่อตรวจสอบการเปลี่ยนแปลง และ postsubmit อาจเป็นการทดสอบที่ใช้ตรวจสอบบิลด์หลังจากผสานการเปลี่ยนแปลงแล้ว
กฎสคริปต์บิลด์แพ็กเกจ
ชุดทดสอบ Trade Federation
จะเรียกใช้โมดูลการทดสอบสำหรับบิลด์ที่กำหนดได้ก็ต่อเมื่อโมดูลเหล่านี้มี
test_suites ที่ตั้งค่าไว้สำหรับ Soong หรือ LOCAL_COMPATIBILITY_SUITE ที่ตั้งค่า
ไว้สำหรับ Make เป็น 1 ใน 2 ชุดทดสอบต่อไปนี้
general-testsใช้สำหรับการทดสอบที่ไม่ขึ้นอยู่กับความสามารถเฉพาะของอุปกรณ์ (เช่น ฮาร์ดแวร์เฉพาะของผู้ให้บริการที่อุปกรณ์ส่วนใหญ่ไม่มี) การทดสอบส่วนใหญ่ควรอยู่ในชุดทดสอบgeneral-testsแม้ว่าจะเป็นการทดสอบที่เฉพาะเจาะจงกับ ABI, บิตเนส หรือฟีเจอร์ฮาร์ดแวร์อย่าง HWASan (มีเป้าหมายtest_suitesแยกต่างหากสำหรับแต่ละ ABI) และแม้ว่าการทดสอบจะต้องทำงานบนอุปกรณ์device-testsใช้สำหรับการทดสอบที่ขึ้นอยู่กับความสามารถเฉพาะของอุปกรณ์ โดยปกติแล้วการทดสอบเหล่านี้จะอยู่ในvendor/เฉพาะอุปกรณ์ หมายถึงความสามารถที่เฉพาะเจาะจงกับอุปกรณ์ หนึ่ง เท่านั้น ดังนั้นจึงใช้ได้กับการทดสอบ JUnit รวมถึงการทดสอบ GTest (ซึ่งโดยปกติแล้วควรทำเครื่องหมายเป็นgeneral-testsแม้ว่าจะเป็นการทดสอบที่เฉพาะเจาะจงกับ ABI)
ตัวอย่าง
Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests
กำหนดค่าการทดสอบให้ทำงานในชุดโปรแกรมทดสอบ
การทดสอบจะทำงานภายในชุดโปรแกรมทดสอบได้ก็ต่อเมื่อการทดสอบมีลักษณะดังนี้
- ต้องไม่มีผู้ให้บริการบิลด์
- ต้องล้างข้อมูลหลังจากเสร็จสิ้น เช่น ลบไฟล์ชั่วคราวที่สร้างขึ้นระหว่างการทดสอบ
- ต้องเปลี่ยนการตั้งค่าระบบเป็นค่าเริ่มต้นหรือค่าเดิม
ไม่ควรสันนิษฐานว่าอุปกรณ์อยู่ในสถานะใดสถานะหนึ่ง เช่น รูทพร้อม การทดสอบส่วนใหญ่ไม่จำเป็นต้องมีสิทธิ์รูทในการเรียกใช้ หากการทดสอบต้องใช้ รูท ก็ควรระบุด้วย
RootTargetPreparerในAndroidTest.xmlดังตัวอย่างต่อไปนี้<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
สร้างไฟล์การจับคู่การทดสอบ
สำหรับไดเรกทอรีที่ต้องมีการครอบคลุมการทดสอบ ให้เพิ่มไฟล์ JSON TEST_MAPPING ที่คล้ายกับ ตัวอย่าง
กฎเหล่านี้จะช่วยให้การทดสอบทำงานในการตรวจสอบก่อนส่งเมื่อมีการแตะไฟล์ในไดเรกทอรีนั้นหรือไดเรกทอรีย่อยใดๆ
ทำตามตัวอย่าง
นี่คือไฟล์ 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": "CtsDeqpTestCases",
"options": [
{
// Use regex in include-filter which is supported in AndroidJUnitTest
"include-filter": "dEQP-EGL.functional.color_clears.*"
}
]
}
],
"imports": [
{
"path": "frameworks/base/services/core/java/com/android/server/am"
}
]
}
ตั้งค่าแอตทริบิวต์
ใน ตัวอย่าง, presubmit และ postsubmit คือชื่อของกลุ่มทดสอบแต่ละกลุ่ม
ดูข้อมูลเพิ่มเติมเกี่ยวกับกลุ่มทดสอบได้ที่กำหนดกลุ่มทดสอบ
คุณสามารถตั้งค่าชื่อโมดูลการทดสอบหรือชื่อการทดสอบการผสานรวม Trade Federation (เส้นทางทรัพยากรไปยังไฟล์ XML การทดสอบ เช่น
uiautomator/uiautomator-demo)
ในค่าของแอตทริบิวต์ name โปรดทราบว่าช่อง name จะใช้ name ของคลาสหรือ name ของเมธอดการทดสอบไม่ได้ หากต้องการจำกัดการทดสอบที่จะเรียกใช้ ให้ใช้ตัวเลือกต่างๆ เช่น include-filter ดูการใช้งานตัวอย่าง
include-filter
การตั้งค่า host ของการทดสอบจะระบุว่าการทดสอบเป็นการทดสอบแบบไม่มีอุปกรณ์ที่ทำงานบนโฮสต์หรือไม่ ค่าเริ่มต้นคือ false ซึ่งหมายความว่าการทดสอบต้องใช้อุปกรณ์ในการเรียกใช้ ประเภทการทดสอบที่รองรับคือ
HostGTest สำหรับ
ไบนารี GTest และ HostTest สำหรับการทดสอบ JUnit
แอตทริบิวต์ file_patterns ช่วยให้คุณตั้งค่ารายการสตริงนิพจน์ทั่วไปสำหรับการจับคู่เส้นทางแบบสัมพัทธ์ของไฟล์ซอร์สโค้ด (เทียบกับไดเรกทอรีที่มีไฟล์ TEST_MAPPING) ในตัวอย่าง,
การทดสอบ CtsWindowManagerDeviceTestCases จะทำงานในการทดสอบก่อนส่งก็ต่อเมื่อไฟล์ Java
ขึ้นต้นด้วย Window หรือ Activity ซึ่งอยู่ในไดเรกทอรีเดียวกับ
TEST_MAPPING ไฟล์ หรือไดเรกทอรีย่อยใดๆ ต้องหลีกเลี่ยงการใช้แบ็กสแลช (\) เนื่องจากอยู่ในไฟล์ JSON
แอตทริบิวต์ imports ช่วยให้คุณรวมการทดสอบในไฟล์ TEST_MAPPING อื่นๆ ได้โดยไม่ต้องคัดลอกเนื้อหา ระบบจะรวมไฟล์ TEST_MAPPING ในไดเรกทอรีระดับบนของเส้นทางที่นำเข้าด้วย การจับคู่การทดสอบอนุญาตการนำเข้าแบบซ้อน ซึ่งหมายความว่าไฟล์ TEST_MAPPING 2 ไฟล์สามารถนำเข้าซึ่งกันและกันได้ และการจับคู่การทดสอบสามารถผสานการทดสอบที่รวมไว้ได้
แอตทริบิวต์ options มีตัวเลือกบรรทัดคำสั่ง Tradefed เพิ่มเติม
หากต้องการดูรายการตัวเลือกทั้งหมดที่ใช้ได้สำหรับการทดสอบที่กำหนด ให้เรียกใช้คำสั่งต่อไปนี้
tradefed.sh run commandAndExit [test_module] --help
ดูรายละเอียดเพิ่มเติมเกี่ยวกับวิธีทำงานของตัวเลือกได้ที่ การจัดการตัวเลือกใน Tradefed
เรียกใช้การทดสอบด้วย Atest
วิธีเรียกใช้กฎการทดสอบก่อนส่งในเครื่อง
- ไปที่ไดเรกทอรีที่มีไฟล์
TEST_MAPPING เรียกใช้คำสั่งต่อไปนี้
atest
ระบบจะเรียกใช้การทดสอบก่อนส่งทั้งหมดที่กำหนดค่าไว้ในไฟล์ TEST_MAPPING ของไดเรกทอรีปัจจุบันและไดเรกทอรีระดับบน Atest จะค้นหาและเรียกใช้การทดสอบ 2 รายการสำหรับการทดสอบก่อนส่ง (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 ในไดเรกทอรีนั้นได้ คำสั่งต่อไปนี้จะเรียกใช้การทดสอบ 2 รายการ (A, B)
atest --test-mapping src/project_1
เรียกใช้กฎการทดสอบหลังส่ง
นอกจากนี้ คุณยังใช้คำสั่งนี้เพื่อเรียกใช้กฎการทดสอบหลังส่งที่กำหนดไว้ใน TEST_MAPPING ใน src_path (ค่าเริ่มต้นคือ CWD) และไดเรกทอรีระดับบนได้ด้วย
atest [--test-mapping] [src_path]:postsubmit
เรียกใช้เฉพาะการทดสอบที่ไม่ต้องใช้อุปกรณ์
คุณสามารถใช้ตัวเลือก --host สำหรับ Atest เพื่อเรียกใช้เฉพาะการทดสอบที่กำหนดค่ากับโฮสต์ที่ไม่ต้องใช้อุปกรณ์ หากไม่มีตัวเลือกนี้ Atest จะเรียกใช้ทั้งการทดสอบที่ต้องใช้อุปกรณ์และการทดสอบที่ทำงานบนโฮสต์ที่ไม่ต้องใช้อุปกรณ์ ระบบจะเรียกใช้การทดสอบในชุดทดสอบ 2 ชุดแยกกัน ดังนี้
atest [--test-mapping] --host
ระบุกลุ่มทดสอบ
คุณสามารถระบุกลุ่มทดสอบในคำสั่ง Atest ได้ คำสั่งต่อไปนี้จะเรียกใช้การทดสอบ postsubmit ทั้งหมดที่เกี่ยวข้องกับไฟล์ในไดเรกทอรี src/project_1 ซึ่งมีการทดสอบเพียงรายการเดียว (C)
หรือคุณจะใช้ :all เพื่อเรียกใช้การทดสอบทั้งหมดโดยไม่คำนึงถึงกลุ่มก็ได้ คำสั่งต่อไปนี้จะเรียกใช้การทดสอบ 4 รายการ (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 จะเรียกใช้การทดสอบ 2 รายการ (A, B)
รองรับความคิดเห็นระดับบรรทัด
คุณสามารถเพิ่มความคิดเห็นรูปแบบ // ระดับบรรทัดเพื่อเพิ่มรายละเอียดไฟล์ TEST_MAPPING ด้วยคำอธิบายของการตั้งค่าที่ตามมา
ATest และ Trade Federation
จะประมวลผลล่วงหน้า TEST_MAPPING เป็นรูปแบบ JSON ที่ถูกต้องโดยไม่มีความคิดเห็น ระบบรองรับเฉพาะความคิดเห็นรูปแบบ // ระดับบรรทัดเพื่อให้ไฟล์ JSON เป็นระเบียบ
ตัวอย่าง
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}