AOSP มีเทมเพลตการทดสอบสำหรับโมดูลทดสอบที่ไม่ใช่คลาสย่อย Python ฝั่งโฮสต์ของ BaseTest ของ VTS runner
นักพัฒนาสามารถใช้เทมเพลตเหล่านี้เพื่อลดความพยายามในการบูรณาการการทดสอบดังกล่าว ส่วนนี้ครอบคลุมถึงการกำหนดค่าและการใช้เทมเพลตการทดสอบ (อยู่ในไดเร็กทอรี VTS testcases/template ) และให้ตัวอย่างสำหรับเทมเพลตที่ใช้ทั่วไป
เทมเพลตการทดสอบไบนารี่
ใช้ เทมเพลต BinaryTest เพื่อรวมการทดสอบที่ดำเนินการบนอุปกรณ์เป้าหมายใน VTS การทดสอบด้านเป้าหมาย ได้แก่ :
- การทดสอบที่ใช้ C++ รวบรวมและส่งไปยังอุปกรณ์
- การทดสอบ Python ฝั่งเป้าหมายรวบรวมเป็นไบนารี
- เชลล์สคริปต์ ปฏิบัติการได้บนอุปกรณ์
การทดสอบเหล่านี้สามารถรวมเข้ากับ VTS โดยมีหรือไม่มีเทมเพลต BinaryTest
รวมการทดสอบฝั่งเป้าหมายเข้ากับเทมเพลต BinaryTest
เทมเพลต BinaryTest ได้รับการออกแบบมาเพื่อช่วยให้นักพัฒนาสามารถรวมการทดสอบฝั่งเป้าหมายได้อย่างง่ายดาย ในกรณีส่วนใหญ่ คุณสามารถเพิ่มการกำหนดค่าง่ายๆ สองสามบรรทัดใน AndroidTest.xml
ตัวอย่างการกำหนดค่าจาก VtsDeviceTreeEarlyMountTest :
<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest."> ... <test class="com.android.tradefed.testtype.VtsMultiDeviceTest"> <option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/> <option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" /> <option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" /> <option name="test-timeout" value="5m"/> </test> </configuration>
ในการกำหนดค่านี้:
-
binary-test-source
และbinary-test-type
เป็นเทมเพลตเฉพาะ - การระบุเส้นทางโฮสต์สัมพัทธ์ของแหล่งไบนารีการทดสอบทำให้เทมเพลตสามารถจัดการการเตรียมการ การพุชไฟล์ การดำเนินการทดสอบ การแยกวิเคราะห์ผลลัพธ์ และการล้างข้อมูล
- เทมเพลตประกอบด้วยวิธีการที่เกี่ยวข้องกับการสร้างกรณีทดสอบสำหรับคลาสย่อยที่จะแทนที่
- เทมเพลตจะถือว่าหนึ่งกรณีทดสอบต่อโมดูลไบนารี่การทดสอบ และชื่อไฟล์ต้นฉบับไบนารีจะถูกใช้เป็นชื่อกรณีทดสอบตามค่าเริ่มต้น
ตัวเลือกการกำหนดค่า
เทมเพลต BinaryTest รองรับตัวเลือกการกำหนดค่าต่อไปนี้:
ชื่อตัวเลือก | ประเภทค่า | คำอธิบาย |
---|---|---|
แหล่งทดสอบไบนารี | สตริง | พาธต้นทางการทดสอบไบนารีสัมพันธ์กับไดเร็กทอรีกรณีทดสอบ vts บนโฮสต์ ตัวอย่าง: DATA/nativetest/test |
ไดเรกทอรีทดสอบการทำงานแบบไบนารี | สตริง | ไดเร็กทอรีการทำงาน (เส้นทางฝั่งอุปกรณ์) ตัวอย่าง: /data/local/tmp/testing/ |
ไบนารีทดสอบ envp | สตริง | ตัวแปรสภาพแวดล้อมสำหรับไบนารี ตัวอย่าง: PATH=/new:$PATH |
ไบนารีทดสอบ args | สตริง | ทดสอบข้อโต้แย้งหรือแฟล็ก ตัวอย่าง: --gtest_filter=test1 |
binary-test-ld-library-path | สตริง | ตัวแปรสภาพแวดล้อม LD_LIBRARY_PATH ตัวอย่าง: /data/local/tmp/lib |
ไบนารีทดสอบปิดการใช้งานกรอบ | บูลีน | เรียกใช้ adb stop เพื่อปิด Android Framework ก่อนการทดสอบ ตัวอย่าง: true |
ไบนารีทดสอบหยุดเนทีฟเซิร์ฟเวอร์ | บูลีน | หยุดเซิร์ฟเวอร์เนทิฟที่กำหนดค่าอย่างถูกต้องทั้งหมดในระหว่างการทดสอบ ตัวอย่าง: true |
ประเภทการทดสอบไบนารี | เชือก | ประเภทเทมเพลต เทมเพลตประเภทอื่นๆ ขยายจากเทมเพลตนี้ แต่คุณไม่จำเป็นต้องระบุตัวเลือกนี้สำหรับเทมเพลตนี้ เนื่องจากคุณได้ระบุ binary-test-source แล้ว |
สำหรับตัวเลือกที่มีประเภทค่า strings
คุณสามารถเพิ่มค่าหลายค่าได้โดยการทำซ้ำตัวเลือกในการกำหนดค่า ตัวอย่างเช่น ตั้งค่า binary-test-source
สองครั้ง (ดังแสดงในตัวอย่าง VtsDeviceTreeEarlyMountTest
)
ทดสอบแท็ก
คุณสามารถเพิ่มแท็กทดสอบได้โดยนำหน้าตัวเลือกด้วยค่า strings
และใช้ ::
เป็นตัวคั่น แท็กทดสอบมีประโยชน์อย่างยิ่งเมื่อรวมแหล่งไบนารีที่มีชื่อเดียวกัน แต่มีบิตเนสต่างกันหรือไดเร็กทอรีพาเรนต์ ตัวอย่างเช่น เพื่อหลีกเลี่ยงการพุชไฟล์หรือชื่อผลลัพธ์ขัดแย้งกันสำหรับแหล่งที่มาที่มีชื่อเดียวกันแต่มาจากไดเร็กทอรีแหล่งที่มาต่างกัน คุณสามารถระบุแท็กที่แตกต่างกันสำหรับแหล่งที่มาเหล่านี้ได้
ดังที่แสดงในตัวอย่าง VtsDeviceTreeEarlyMountTest
ที่มี dt_early_mount_test
แหล่งที่มาสองรายการ แท็กทดสอบคือคำนำหน้า _32bit::
และ _64bit::
บน binary-test-source
แท็กที่ลงท้ายด้วย 32bit
หรือ 64bit
จะทำเครื่องหมายการทดสอบว่าพร้อมใช้งานสำหรับ ABI หนึ่งบิตโดยอัตโนมัติ เช่น การทดสอบด้วยแท็ก _32bit
จะไม่ถูกดำเนินการบน ABI 64 บิต การไม่ระบุแท็กจะเท่ากับการใช้แท็กที่มีสตริงว่าง
ตัวเลือกที่มีแท็กเดียวกันจะถูกจัดกลุ่มและแยกออกจากแท็กอื่นๆ ตัวอย่างเช่น binary-test-args
ที่มีแท็ก _32bit
จะใช้กับ binary-test-source
ที่มีแท็กเดียวกันเท่านั้น และดำเนินการใน binary-test-working-directory
ด้วยแท็กเดียวกัน ตัวเลือก binary-test-working-directory
เป็นทางเลือกสำหรับการทดสอบไบนารี่ ซึ่งช่วยให้คุณสามารถระบุไดเร็กทอรีการทำงานเดียวสำหรับแท็กได้ เมื่อตัวเลือก binary-test-working-directory
ไม่ได้ระบุ จะมีการใช้ไดเร็กทอรีเริ่มต้นสำหรับแต่ละแท็ก
ชื่อแท็กจะถูกผนวกเข้ากับชื่อกรณีทดสอบในรายงานผลลัพธ์โดยตรง ตัวอย่างเช่น กรณีทดสอบ testcase1
ที่มีแท็ก _32bit
จะปรากฏเป็น testcase1_32bit
ในรายงานผลลัพธ์
รวมการทดสอบฝั่งเป้าหมายโดยไม่มีเทมเพลต BinaryTest
ใน VTS รูปแบบการทดสอบเริ่มต้นคือการทดสอบ Python ฝั่งโฮสต์ที่ขยายจาก BaseTest ใน VTS runner หากต้องการรวมการทดสอบฝั่งเป้าหมาย คุณต้องส่งไฟล์ทดสอบไปยังอุปกรณ์ก่อน ดำเนินการทดสอบโดยใช้คำสั่งเชลล์ จากนั้นแยกวิเคราะห์ผลลัพธ์โดยใช้สคริปต์ Python ฝั่งโฮสต์
ผลักดันไบนารีทดสอบ
เราขอแนะนำให้ส่งไฟล์โดยใช้ตัวจัดเตรียมเป้าหมาย VtsFilePusher
ตัวอย่าง:
<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher"> <option name="push" value="DATA/test->/data/local/tmp/test"/> </target_preparer>
VtsFilePusher
ทำสิ่งต่อไปนี้:
- ตรวจสอบการเชื่อมต่ออุปกรณ์
- กำหนดเส้นทางไฟล์ต้นทางที่แน่นอน
- พุชไฟล์โดยใช้คำสั่ง
adb push
- ลบไฟล์หลังจากการทดสอบเสร็จสิ้น
หรือคุณสามารถพุชไฟล์ด้วยตนเองโดยใช้สคริปต์ทดสอบ Python ฝั่งโฮสต์ที่ทำตามขั้นตอนที่คล้ายกัน
ทำการทดสอบ
หลังจากพุชไฟล์ไปยังอุปกรณ์แล้ว ให้รันการทดสอบโดยใช้คำสั่งเชลล์ในสคริปต์ทดสอบ Python ฝั่งโฮสต์ ตัวอย่าง:
device = self.android_devices[0] res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"]) asserts.AssertFalse(any(res[return_codes]))
เทมเพลต GtestBinaryTest
เทมเพลต GtestBinaryTest โฮสต์ไบนารีการทดสอบ Gtest ซึ่งแต่ละไบนารีมักจะมีกรณีทดสอบหลายกรณี เทมเพลตนี้จะขยายเทมเพลต BinaryTest โดยการแทนที่การตั้งค่า การสร้างกรณีทดสอบ และวิธีการแยกวิเคราะห์ผลลัพธ์ ดังนั้นการกำหนดค่า BinaryTest ทั้งหมดจึงสืบทอดมา
GtestBinaryTest เพิ่มตัวเลือก gtest-batch-mode
:
ชื่อตัวเลือก | ประเภทค่า | คำอธิบาย |
---|---|---|
ประเภทการทดสอบไบนารี | เชือก | ประเภทเทมเพลต ใช้ค่า gtest |
gtest-แบทช์โหมด | บูลีน | เรียกใช้ไบนารี Gtest ในโหมดแบตช์ ตัวอย่าง: true |
โดยทั่วไป การตั้งค่า gtest-batch-mode
เป็น true
จะเพิ่มประสิทธิภาพการทำงานในขณะที่ความน่าเชื่อถือลดลงเล็กน้อย ในการทดสอบการปฏิบัติตาม VTS โมดูลจำนวนมากใช้โหมดแบตช์เพื่อปรับปรุงประสิทธิภาพ อย่างไรก็ตาม เพื่อความน่าเชื่อถือ หากไม่ได้ระบุโหมด โหมดจะใช้ค่าเริ่มต้นเป็นแบบไม่แบตช์
โหมดที่ไม่ใช่แบตช์
โหมดที่ไม่ใช่แบตช์ทำการเรียกแต่ละรายการไปยังไบนารี Gtest สำหรับแต่ละกรณีทดสอบ ตัวอย่างเช่น หากไบนารี Gtest มีกรณีการทดสอบ 10 กรณี (หลังจากกรองตามการกำหนดค่าฝั่งโฮสต์) ไบนารีจะถูกเรียก 10 ครั้งบนเชลล์อุปกรณ์ในแต่ละครั้งด้วยตัวกรองการทดสอบที่แตกต่างกัน สำหรับแต่ละกรณีทดสอบ XML เอาต์พุตผลลัพธ์ Gtest ที่ไม่ซ้ำกันจะถูกสร้างขึ้นและแยกวิเคราะห์โดยเทมเพลต
ข้อดีของการใช้โหมดที่ไม่ใช่แบตช์ ได้แก่:
- การแยกกรณีทดสอบ การหยุดทำงานหรือค้างในกรณีทดสอบหนึ่งจะไม่ส่งผลกระทบต่อกรณีทดสอบอื่นๆ
- รายละเอียด ง่ายต่อการรับโปรไฟล์ต่อกรณีทดสอบ/การวัดความครอบคลุม, ระบบ, รายงานจุดบกพร่อง, Logcat ฯลฯ ผลการทดสอบและบันทึกจะถูกดึงข้อมูลทันทีหลังจากแต่ละกรณีทดสอบเสร็จสิ้น
ข้อเสียของการใช้โหมดที่ไม่ใช่แบตช์ ได้แก่:
- การโหลดซ้ำซ้อน แต่ละครั้งที่มีการเรียกไบนารี Gtest จะโหลดไลบรารีที่เกี่ยวข้องและดำเนินการตั้งค่าคลาสเริ่มต้น
- ค่าใช้จ่ายในการสื่อสาร หลังจากการทดสอบเสร็จสิ้น โฮสต์และอุปกรณ์เป้าหมายจะสื่อสารกันเพื่อแยกวิเคราะห์ผลลัพธ์และคำสั่งถัดไป (สามารถเพิ่มประสิทธิภาพในอนาคตได้)
โหมดแบตช์
ในโหมดแบตช์ Gtest ไบนารีการทดสอบจะถูกเรียกเพียงครั้งเดียวโดยมีค่าตัวกรองการทดสอบแบบยาวซึ่งประกอบด้วยกรณีการทดสอบทั้งหมดที่กรองโดยการกำหนดค่าฝั่งโฮสต์ (ซึ่งจะช่วยหลีกเลี่ยงปัญหาการโหลดซ้ำซ้อนในโหมดที่ไม่ใช่แบตช์) คุณสามารถแยกวิเคราะห์ผลการทดสอบสำหรับ Gtest ได้โดยใช้ output.xml หรือใช้เอาต์พุตเทอร์มินัล
เมื่อใช้ output.xml (ค่าเริ่มต้น):
เช่นเดียวกับในโหมดที่ไม่ใช่แบตช์ ผลการทดสอบจะถูกแยกวิเคราะห์ผ่านไฟล์ xml เอาต์พุต GTest อย่างไรก็ตาม เนื่องจากเอาต์พุต xml ถูกสร้างขึ้นหลังจากการทดสอบทั้งหมดเสร็จสิ้น หากกรณีทดสอบทำให้ไบนารีหรืออุปกรณ์เสียหาย ไฟล์ xml ผลลัพธ์จะไม่ถูกสร้างขึ้น
เมื่อใช้เอาต์พุตเทอร์มินัล:
ในขณะที่ Gtest กำลังทำงานอยู่ ระบบจะพิมพ์บันทึกการทดสอบและความคืบหน้าไปยังเทอร์มินัลในรูปแบบที่สามารถแยกวิเคราะห์โดยเฟรมเวิร์กสำหรับสถานะการทดสอบ ผลลัพธ์ และบันทึก
ข้อดีของการใช้โหมดแบตช์ ได้แก่:
- การแยกกรณีทดสอบ ให้การแยกกรณีการทดสอบในระดับเดียวกันกับโหมดที่ไม่ใช่แบตช์ หากเฟรมเวิร์กรีสตาร์ทไบนารี/อุปกรณ์หลังจากเกิดข้อขัดข้องด้วยตัวกรองการทดสอบที่ลดลง (ไม่รวมกรณีทดสอบที่เสร็จสิ้นและขัดข้อง)
- รายละเอียด ให้รายละเอียดกรณีทดสอบเดียวกันกับโหมดที่ไม่ใช่แบตช์
ข้อเสียของการใช้โหมดแบตช์ ได้แก่:
- ค่าบำรุงรักษา . หากรูปแบบการบันทึก Gtest เปลี่ยนแปลง การทดสอบทั้งหมดจะล้มเหลว
- ความสับสน . กรณีทดสอบสามารถพิมพ์สิ่งที่คล้ายกับรูปแบบความคืบหน้าของ Gtest ซึ่งอาจทำให้รูปแบบสับสนได้
เนื่องจากข้อเสียเหล่านี้ เราจึงได้ลบตัวเลือกในการใช้เอาต์พุตบรรทัดคำสั่งออกชั่วคราว เราจะกลับมาทบทวนตัวเลือกนี้อีกครั้งในอนาคตเพื่อปรับปรุงความน่าเชื่อถือของฟังก์ชันนี้
เทมเพลต HostBinaryTest
เทมเพลต HostBinaryTest ประกอบด้วยไฟล์ปฏิบัติการฝั่งโฮสต์ที่ไม่มีอยู่ในไดเร็กทอรีอื่นหรือในสคริปต์ Python การทดสอบเหล่านี้รวมถึง:
- ไบนารีทดสอบที่คอมไพล์แล้วสามารถเรียกใช้งานได้บนโฮสต์
- สคริปต์ปฏิบัติการในเชลล์, Python หรือภาษาอื่นๆ
ตัวอย่างหนึ่งคือ การทดสอบฝั่งโฮสต์ของนโยบาย VTS Security SELinux :
<configuration description="Config for VTS Security SELinux policy host-side test cases"> ... <test class="com.android.tradefed.testtype.VtsMultiDeviceTest"> <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/> <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" /> <option name="binary-test-type" value="host_binary_test"/> </test> </configuration>
HostBinaryTest ไม่ขยายเทมเพลต BinaryTest แต่ใช้การกำหนดค่าการทดสอบที่คล้ายกัน ในตัวอย่างข้างต้น ตัวเลือก binary-test-source
ระบุพาธสัมพันธ์ฝั่งโฮสต์กับการทดสอบที่ปฏิบัติการได้ และ binary-test-type
คือ host_binary_test
คล้ายกับเทมเพลต BinaryTest ชื่อไฟล์ไบนารี่จะถูกใช้เป็นชื่อกรณีทดสอบตามค่าเริ่มต้น
ขยายเทมเพลตที่มีอยู่
คุณสามารถใช้เทมเพลตได้โดยตรงในการกำหนดค่าการทดสอบเพื่อรวมการทดสอบที่ไม่ใช่ Python หรือขยายการทดสอบเหล่านั้นในคลาสย่อยเพื่อรองรับข้อกำหนดการทดสอบเฉพาะ เทมเพลตใน repo VTS มีส่วนขยายดังต่อไปนี้:
เราสนับสนุนให้นักพัฒนาขยายเทมเพลตที่มีอยู่สำหรับข้อกำหนดการทดสอบเฉพาะใดๆ สาเหตุทั่วไปในการขยายเทมเพลตได้แก่:
- ขั้นตอนการตั้งค่าการทดสอบพิเศษ เช่น การเตรียมอุปกรณ์ด้วยคำสั่งพิเศษ
- การสร้างกรณีทดสอบและชื่อการทดสอบที่แตกต่างกัน
- แยกวิเคราะห์ผลลัพธ์โดยการอ่านเอาต์พุตคำสั่งหรือใช้เงื่อนไขอื่น
เพื่อให้ง่ายต่อการขยายเทมเพลตที่มีอยู่ เทมเพลตจึงมีวิธีการเฉพาะสำหรับแต่ละฟังก์ชัน หากคุณได้ปรับปรุงการออกแบบสำหรับเทมเพลตที่มีอยู่แล้ว เราขอแนะนำให้คุณมีส่วนร่วมในฐานโค้ด VTS