เทมเพลตการทดสอบ

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

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

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

เทมเพลต BinaryTest

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

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

การทดสอบเหล่านี้สามารถนำไปผสานรวมใน VTS ได้โดยมีหรือไม่มี BranchTest เทมเพลต

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

เทมเพลต BumbleTest ได้รับการออกแบบมาเพื่อช่วยให้นักพัฒนาซอฟต์แวร์สามารถผสานรวม การทดสอบฝั่งเป้าหมาย ในกรณีส่วนใหญ่ คุณสามารถเพิ่มบรรทัดง่ายๆ ไม่กี่บรรทัด การกำหนดค่าใน 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 สนับสนุนตัวเลือกการกำหนดค่าต่อไปนี้

ชื่อตัวเลือก ประเภทค่า คำอธิบาย
การทดสอบไบนารีต้นฉบับ สตริง เส้นทางแหล่งที่มาการทดสอบไบนารีที่สัมพันธ์กับไดเรกทอรีกรณีการทดสอบ vts เปิดอยู่ เป็นโฮสต์
ตัวอย่าง: DATA/nativetest/test
ไดเรกทอรีการทดสอบไบนารี สตริง ไดเรกทอรีที่ใช้งานอยู่ (เส้นทางฝั่งเซิร์ฟเวอร์)
ตัวอย่าง: /data/local/tmp/testing/
การทดสอบไบนารีด้วยการเข้ารหัส สตริง ตัวแปรสภาพแวดล้อมสำหรับไบนารี
ตัวอย่าง: PATH=/new:$PATH
การทดสอบไบนารี สตริง ทดสอบอาร์กิวเมนต์หรือแฟล็ก
ตัวอย่าง: --gtest_filter=test1
ไบนารี-ทดสอบ-ld-library-path สตริง ตัวแปรสภาพแวดล้อม LD_LIBRARY_PATH
ตัวอย่าง: /data/local/tmp/lib
การทดสอบไบนารีในการปิดใช้เฟรมเวิร์ก บูลีน เรียกใช้ adb stop เพื่อปิด Android Framework ก่อนทดสอบ ตัวอย่าง: true
เซิร์ฟเวอร์ไบนารีทดสอบและหยุดแบบดั้งเดิม บูลีน หยุดเซิร์ฟเวอร์เนทีฟที่กำหนดค่าอย่างถูกต้องทั้งหมดในระหว่างการทดสอบ ตัวอย่าง true
ประเภทการทดสอบไบนารี สตริง ประเภทเทมเพลต เทมเพลตประเภทอื่นๆ ขยายจากเทมเพลตนี้ แต่ ไม่จำเป็นต้องระบุตัวเลือกนี้ สำหรับเทมเพลตนี้เนื่องจากคุณ ระบุ 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

GtestBranchTest template โฮสต์ไบนารีการทดสอบ GTest ซึ่งแต่ละเทมเพลตจะมี กรอบการทดสอบหลายรายการ เทมเพลตนี้จะขยายเทมเพลต BranchTest โดยการลบล้าง การตั้งค่า การสร้างกรอบการทดสอบ และวิธีการแยกวิเคราะห์ผลลัพธ์ ดังนั้น BinaryTest ทั้งหมด รับช่วงการกำหนดค่าต่อ

GtestBinaryTest เพิ่มตัวเลือก gtest-batch-mode:

ชื่อตัวเลือก ประเภทค่า คำอธิบาย
ประเภทการทดสอบไบนารี สตริง ประเภทเทมเพลต ใช้ค่า gtest
โหมดกลุ่ม Gtest บูลีน เรียกใช้ไบนารี Gtest ในโหมดแบบกลุ่ม ตัวอย่าง: true

โดยทั่วไป การตั้งค่า gtest-batch-mode เป็น true จะช่วยเพิ่มประสิทธิภาพและลดความน่าเชื่อถือลงเล็กน้อย เป็นไปตามข้อกำหนดของ VTS โมดูลจำนวนมากใช้โหมดกลุ่มเพื่อปรับปรุงประสิทธิภาพการทำงาน เพื่อความน่าเชื่อถือ แต่หากไม่ระบุโหมด ค่าเริ่มต้นจะเป็นแบบไม่เป็นกลุ่ม

โหมดไม่ใช่แบบกลุ่ม

โหมดไม่ใช่แบบกลุ่มจะเรียกใช้ไบนารี GTest ทีละรายการสำหรับแต่ละกรอบการทดสอบ สำหรับ เช่น ถ้าไบนารี GTest มี 10 กรอบการทดสอบ (หลังจากกรองตามโฮสต์ การกำหนดค่าด้านข้าง) การเรียกไบนารี 10 ครั้งบน Device Shell ในแต่ละครั้ง โดยใช้ตัวกรองการทดสอบอื่น ผลลัพธ์ของ GTest ที่ไม่ซ้ำกันสำหรับกรอบการทดสอบแต่ละรายการ เทมเพลตจะสร้างและแยกวิเคราะห์ XML

รูปที่ 2 โหมดไม่ใช่แบบกลุ่ม

ข้อดีของการใช้โหมดที่ไม่ใช่แบบกลุ่มมีดังนี้

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

ข้อเสียของการใช้โหมดที่ไม่ใช่แบบกลุ่มมีดังนี้

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

โหมดกลุ่ม

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

เมื่อใช้เอาต์พุต.xml (ค่าเริ่มต้น) ให้ทำดังนี้

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

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

เมื่อใช้เอาต์พุตเทอร์มินัล ให้ทำดังนี้

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

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

ข้อดีของการใช้โหมดแบบกลุ่มมีดังนี้

  • การแยกเคสทดสอบ ให้การทดสอบในระดับเดียวกัน การแยกเคสเป็นโหมดแบบไม่เป็นกลุ่มหากเฟรมเวิร์กรีสตาร์ทไบนารี/อุปกรณ์ หลังการขัดข้องโดยใช้ตัวกรองการทดสอบที่ลดลง (ไม่รวมการทดสอบที่เสร็จสิ้นและการทดสอบที่ขัดข้อง กรณี)
  • รายละเอียด ให้รายละเอียดของกรอบการทดสอบเดียวกันกับ โหมดไม่ใช่แบบกลุ่ม

ข้อเสียของการใช้โหมดกลุ่มมีดังนี้

  • ค่าบำรุงรักษา หากรูปแบบการบันทึก GTest มีการเปลี่ยนแปลง การทดสอบทั้งหมดจะขัดข้อง
  • ความสับสน กรอบการทดสอบสามารถพิมพ์สิ่งที่คล้ายกับ GTest ได้ รูปแบบความคืบหน้า ซึ่งอาจทำให้รูปแบบดังกล่าวสับสนได้

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

เทมเพลต HostBinaryTest

เทมเพลต HostBinaryTest มีไฟล์ปฏิบัติการฝั่งโฮสต์ที่ไม่มีอยู่ ในไดเรกทอรีอื่นๆ หรือในสคริปต์ Python การทดสอบเหล่านี้รวมถึง

  • คอมไพล์ไบนารีทดสอบที่ปฏิบัติการได้ในโฮสต์
  • สคริปต์สั่งการใน Shell, 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 ไม่ได้ขยายเทมเพลต BaryTest แต่จะใช้เทมเพลต การกำหนดค่าการทดสอบ ในตัวอย่างข้างต้น binary-test-source จะระบุเส้นทางสัมพัทธ์ฝั่งโฮสต์ไปยังไฟล์ปฏิบัติการทดสอบ และ binary-test-type คือhost_binary_test คล้ายกับ เทมเพลต BinaryTest จะใช้ชื่อไฟล์ไบนารีเป็นชื่อกรอบการทดสอบโดยใช้ "ค่าเริ่มต้น"

ขยายเทมเพลตที่มีอยู่

คุณใช้เทมเพลตได้โดยตรงในการกำหนดค่าการทดสอบเพื่อรวมการทดสอบที่ไม่ใช่ Python หรือขยายไว้ในคลาสย่อยเพื่อจัดการกับข้อกำหนดการทดสอบที่เฉพาะเจาะจง เทมเพลตใน ที่เก็บ VTS จะมีส่วนขยายต่อไปนี้

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

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

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

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