แบบทดสอบ

AOSP มีเทมเพลตการทดสอบสำหรับโมดูลทดสอบที่ไม่ใช่คลาสย่อย Python ฝั่งโฮสต์ของ BaseTest ของ VTS runner

รูปที่ 1. ทดสอบสถาปัตยกรรมเทมเพลต

นักพัฒนาสามารถใช้เทมเพลตเหล่านี้เพื่อลดความพยายามในการบูรณาการการทดสอบดังกล่าว ส่วนนี้ครอบคลุมถึงการกำหนดค่าและการใช้เทมเพลตการทดสอบ (อยู่ในไดเร็กทอรี 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 ทำสิ่งต่อไปนี้:

  1. ตรวจสอบการเชื่อมต่ออุปกรณ์
  2. กำหนดเส้นทางไฟล์ต้นทางที่แน่นอน
  3. พุชไฟล์โดยใช้คำสั่ง adb push
  4. ลบไฟล์หลังจากการทดสอบเสร็จสิ้น

หรือคุณสามารถพุชไฟล์ด้วยตนเองโดยใช้สคริปต์ทดสอบ 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 ที่ไม่ซ้ำกันจะถูกสร้างขึ้นและแยกวิเคราะห์โดยเทมเพลต

รูปที่ 2. โหมดที่ไม่ใช่แบตช์

ข้อดีของการใช้โหมดที่ไม่ใช่แบตช์ ได้แก่:

  • การแยกกรณีทดสอบ การหยุดทำงานหรือค้างในกรณีทดสอบหนึ่งจะไม่ส่งผลกระทบต่อกรณีทดสอบอื่นๆ
  • รายละเอียด ง่ายต่อการรับโปรไฟล์ต่อกรณีทดสอบ/การวัดความครอบคลุม, ระบบ, รายงานจุดบกพร่อง, Logcat ฯลฯ ผลการทดสอบและบันทึกจะถูกดึงข้อมูลทันทีหลังจากแต่ละกรณีทดสอบเสร็จสิ้น

ข้อเสียของการใช้โหมดที่ไม่ใช่แบตช์ ได้แก่:

  • การโหลดซ้ำซ้อน แต่ละครั้งที่มีการเรียกไบนารี Gtest จะโหลดไลบรารีที่เกี่ยวข้องและดำเนินการตั้งค่าคลาสเริ่มต้น
  • ค่าใช้จ่ายในการสื่อสาร หลังจากการทดสอบเสร็จสิ้น โฮสต์และอุปกรณ์เป้าหมายจะสื่อสารกันเพื่อแยกวิเคราะห์ผลลัพธ์และคำสั่งถัดไป (สามารถเพิ่มประสิทธิภาพในอนาคตได้)

โหมดแบตช์

ในโหมดแบตช์ Gtest ไบนารีการทดสอบจะถูกเรียกเพียงครั้งเดียวโดยมีค่าตัวกรองการทดสอบแบบยาวซึ่งประกอบด้วยกรณีการทดสอบทั้งหมดที่กรองโดยการกำหนดค่าฝั่งโฮสต์ (ซึ่งจะช่วยหลีกเลี่ยงปัญหาการโหลดซ้ำซ้อนในโหมดที่ไม่ใช่แบตช์) คุณสามารถแยกวิเคราะห์ผลการทดสอบสำหรับ Gtest ได้โดยใช้ output.xml หรือใช้เอาต์พุตเทอร์มินัล

เมื่อใช้ output.xml (ค่าเริ่มต้น):

รูปที่ 3 โหมดแบตช์, output.xml

เช่นเดียวกับในโหมดที่ไม่ใช่แบตช์ ผลการทดสอบจะถูกแยกวิเคราะห์ผ่านไฟล์ xml เอาต์พุต GTest อย่างไรก็ตาม เนื่องจากเอาต์พุต xml ถูกสร้างขึ้นหลังจากการทดสอบทั้งหมดเสร็จสิ้น หากกรณีทดสอบทำให้ไบนารีหรืออุปกรณ์เสียหาย ไฟล์ xml ผลลัพธ์จะไม่ถูกสร้างขึ้น

เมื่อใช้เอาต์พุตเทอร์มินัล:

รูปที่ 4 โหมดแบทช์ เอาต์พุตเทอร์มินัล

ในขณะที่ 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 มีส่วนขยายดังต่อไปนี้:

รูปที่ 5 การขยายเทมเพลตที่มีอยู่ใน repo VTS

เราสนับสนุนให้นักพัฒนาขยายเทมเพลตที่มีอยู่สำหรับข้อกำหนดการทดสอบเฉพาะใดๆ สาเหตุทั่วไปในการขยายเทมเพลตได้แก่:

  • ขั้นตอนการตั้งค่าการทดสอบพิเศษ เช่น การเตรียมอุปกรณ์ด้วยคำสั่งพิเศษ
  • การสร้างกรณีทดสอบและชื่อการทดสอบที่แตกต่างกัน
  • แยกวิเคราะห์ผลลัพธ์โดยการอ่านเอาต์พุตคำสั่งหรือใช้เงื่อนไขอื่น

เพื่อให้ง่ายต่อการขยายเทมเพลตที่มีอยู่ เทมเพลตจึงมีวิธีการเฉพาะสำหรับแต่ละฟังก์ชัน หากคุณได้ปรับปรุงการออกแบบสำหรับเทมเพลตที่มีอยู่แล้ว เราขอแนะนำให้คุณมีส่วนร่วมในฐานโค้ด VTS