ทดสอบเทมเพลต

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

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

นักพัฒนาซอฟต์แวร์สามารถใช้เทมเพลตเหล่านี้เพื่อลดความพยายามในการผสานรวมการทดสอบดังกล่าว ส่วนนี้จะกล่าวถึงการกำหนดค่าและการใช้เทมเพลตการทดสอบ (อยู่ในไดเรกทอรี testcases/template ของ VTS) และแสดงตัวอย่างเทมเพลตที่ใช้กันโดยทั่วไป

เทมเพลต BinaryTest

ใช้เทมเพลต BinaryTest เพื่อผสานรวมการทดสอบที่ดำเนินการในอุปกรณ์เป้าหมายใน VTS การทดสอบฝั่งเป้าหมาย ได้แก่

  • การทดสอบที่ใช้ C++ คอมไพล์และพุชไปยังอุปกรณ์
  • การทดสอบ Python ฝั่งเป้าหมายที่คอมไพล์เป็นไบนารี
  • สคริปต์ Shell ที่เรียกใช้ได้ในอุปกรณ์

การทดสอบเหล่านี้ผสานรวมเข้ากับ VTS ได้โดยมีหรือไม่มีเทมเพลต BinaryTest ก็ได้

ผสานรวมการทดสอบฝั่งเป้าหมายกับเทมเพลต BinaryTest

เทมเพลต BinaryTest ออกแบบมาเพื่อช่วยนักพัฒนาซอฟต์แวร์ผสานรวมการทดสอบฝั่งเป้าหมายได้อย่างง่ายดาย ในกรณีส่วนใหญ่ คุณสามารถเพิ่มการกําหนดค่า 2-3 บรรทัดง่ายๆ ใน 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 จะใช้ได้กับเทมเพลตเท่านั้น
  • การระบุเส้นทางโฮสต์แบบสัมพัทธ์ของแหล่งที่มาของไฟล์ไบนารีทดสอบช่วยให้เทมเพลตจัดการการเตรียม การพุชไฟล์ การดำเนินการทดสอบ การแยกวิเคราะห์ผลลัพธ์ และการล้างข้อมูลได้
  • เทมเพลตมีเมธอดที่เกี่ยวข้องกับการสร้างชุดทดสอบเพื่อให้คลาสย่อยลบล้าง
  • เทมเพลตจะถือว่าแต่ละโมดูลไบนารีทดสอบมีเฟรมเวิร์กการทดสอบ 1 รายการ และระบบจะใช้ชื่อไฟล์ต้นทางไบนารีเป็นชื่อเฟรมเวิร์กการทดสอบโดยค่าเริ่มต้น

ตัวเลือกการกําหนดค่า

เทมเพลต BinaryTest รองรับตัวเลือกการกําหนดค่าต่อไปนี้

ชื่อตัวเลือก ประเภทค่า คำอธิบาย
binary-test-source สตริง เส้นทางแหล่งที่มาของการทดสอบแบบไบนารีซึ่งสัมพันธ์กับไดเรกทอรี Test Case ของ vts ในโฮสต์
ตัวอย่าง: DATA/nativetest/test
binary-test-working-directory สตริง ไดเรกทอรีที่ทำงาน (เส้นทางฝั่งอุปกรณ์)
ตัวอย่าง: /data/local/tmp/testing/
binary-test-envp สตริง ตัวแปรสภาพแวดล้อมสําหรับไบนารี
ตัวอย่าง: PATH=/new:$PATH
binary-test-args สตริง ทดสอบอาร์กิวเมนต์หรือ Flag
ตัวอย่าง: --gtest_filter=test1
binary-test-ld-library-path สตริง ตัวแปรสภาพแวดล้อม LD_LIBRARY_PATH
ตัวอย่าง: /data/local/tmp/lib
binary-test-disable-framework บูลีน เรียกใช้ adb stop เพื่อปิดเฟรมเวิร์ก Android ก่อนการทดสอบ ตัวอย่าง: true
binary-test-stop-native-servers บูลีน หยุดเซิร์ฟเวอร์เนทีฟที่กําหนดค่าอย่างถูกต้องทั้งหมดระหว่างการทดสอบ ตัวอย่าง: true
binary-test-type สตริง ประเภทเทมเพลต เทมเพลตประเภทอื่นๆ จะขยายมาจากเทมเพลตนี้ แต่คุณไม่จำเป็นต้องระบุตัวเลือกนี้สำหรับเทมเพลตนี้เนื่องจากคุณได้ระบุ binary-test-source ไว้แล้ว

สําหรับตัวเลือกที่มีประเภทค่าเป็น strings คุณสามารถเพิ่มค่าหลายค่าได้ด้วยการระบุตัวเลือกซ้ำในการกําหนดค่า เช่น ตั้งค่า binary-test-source 2 ครั้ง (ดังที่แสดงในตัวอย่าง VtsDeviceTreeEarlyMountTest)

แท็กทดสอบ

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

ดังที่แสดงในตัวอย่าง VtsDeviceTreeEarlyMountTest ที่มีแหล่งที่มา dt_early_mount_test 2 แหล่ง แท็กทดสอบคือส่วนหน้า _32bit:: และ _64bit:: ใน binary-test-source แท็กที่ลงท้ายด้วย 32bit หรือ 64bit จะทําเครื่องหมายการทดสอบว่าพร้อมใช้งานสำหรับ ABI แบบ 1 บิตโดยอัตโนมัติ กล่าวคือ การทดสอบที่มีแท็ก _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 หากต้องการผสานรวมการทดสอบฝั่งเป้าหมาย คุณต้องพุชไฟล์ทดสอบไปยังอุปกรณ์ก่อน จากนั้นเรียกใช้การทดสอบโดยใช้คําสั่ง Shell แล้วแยกวิเคราะห์ผลลัพธ์โดยใช้สคริปต์ 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 ฝั่งโฮสต์ซึ่งทําตามขั้นตอนที่คล้ายกันก็ได้

เรียกใช้การทดสอบ

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

ชื่อตัวเลือก ประเภทค่า คำอธิบาย
binary-test-type สตริง ประเภทเทมเพลต ใช้ค่า gtest
gtest-batch-mode บูลีน เรียกใช้ไบนารี 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 การทดสอบด้านโฮสต์ของนโยบาย 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 หรือขยายเทมเพลตในคลาสย่อยเพื่อจัดการข้อกําหนดการทดสอบที่เฉพาะเจาะจง เทมเพลตในรีโป VTS จะมีนามสกุลต่อไปนี้

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

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

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

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