قوالب الاختبار

يتضمن AOSP قوالب اختبار لوحدات الاختبار التي ليست فئة فرعية من Python من جانب المضيف في BaseTest الخاص بمشغل VTS.

يمكن للمطورين استخدام هذه القوالب لتقليل الجهد المبذول في دمج مثل هذه الاختبارات. يغطي هذا القسم تكوين واستخدام قوالب الاختبار (الموجودة في دليل نماذج/ قوالب VTS) ويقدم أمثلة للقوالب شائعة الاستخدام.

قالب اختبار ثنائي

استخدم قالب BinaryTest لدمج الاختبارات التي يتم تنفيذها على الجهاز المستهدف في VTS. تشمل اختبارات الجانب المستهدف ما يلي:

• تم تجميع الاختبارات المستندة إلى C++ ودفعها إلى الجهاز
• تم تجميع اختبارات بايثون من الجانب المستهدف على شكل ثنائيات
• البرامج النصية Shell قابلة للتنفيذ على الأجهزة

يمكن دمج هذه الاختبارات في 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 خيارات التكوين التالية:

بالنسبة للخيارات ذات strings نوع القيمة، يمكنك إضافة قيم متعددة عن طريق تكرار الخيارات الموجودة في التكوين. على سبيل المثال، قم بتعيين binary-test-source مرتين (كما هو موضح في مثال VtsDeviceTreeEarlyMountTest ).

علامات الاختبار

يمكنك إضافة علامات اختبار عن طريق إضافتها إلى الخيارات ذات قيم strings واستخدام :: كمحدد. تعتبر علامات الاختبار مفيدة بشكل خاص عند تضمين المصادر الثنائية بنفس الاسم ولكن مع وحدات بت أو أدلة أصلية مختلفة. على سبيل المثال، لتجنب دفع الملف أو تضارب أسماء النتائج للمصادر التي تحمل الاسم نفسه ولكن من أدلة مصادر مختلفة، يمكنك تحديد علامات مختلفة لهذه المصادر.

كما هو موضح في مثال VtsDeviceTreeEarlyMountTest مع مصدري dt_early_mount_test ، فإن علامات الاختبار هي البادئات _32bit:: و_64 _64bit:: على binary-test-source . العلامات التي تنتهي بـ 32bit أو 64bit تحدد تلقائيًا الاختبارات على أنها متاحة لبت ABI واحد؛ على سبيل المثال، لا يتم تنفيذ الاختبارات ذات العلامة _32bit على واجهة برمجة تطبيقات 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 ثنائيات اختبار GTest، والتي تحتوي كل منها عادةً على حالات اختبار متعددة. يقوم هذا القالب بتوسيع قالب BinaryTest عن طريق تجاوز الإعداد وإنشاء حالة الاختبار وأساليب تحليل النتائج، بحيث يتم توريث جميع تكوينات BinaryTest.

يضيف GtestBinaryTest الخيار gtest-batch-mode :

بشكل عام، يؤدي تعيين gtest-batch-mode إلى true إلى زيادة الأداء مع تقليل الموثوقية قليلاً. في اختبارات الامتثال لـ VTS، تستخدم العديد من الوحدات النمطية الدفعية لتحسين الأداء. ومع ذلك، من أجل الموثوقية، إذا كان الوضع غير محدد، فسيتم تعيينه افتراضيًا على غير دفعة.

الوضع غير الدفعي

يقوم الوضع غير الدفعي بإجراء مكالمات فردية إلى GTest الثنائي لكل حالة اختبار. على سبيل المثال، إذا كان ثنائي GTest يحتوي على 10 حالات اختبار (بعد التصفية حسب تكوين جانب المضيف)، فسيتم استدعاء الثنائي 10 مرات على غلاف الجهاز في كل مرة باستخدام مرشح اختبار مختلف. لكل حالة اختبار، يتم إنشاء ملف XML فريد لنتائج اختبار GTest وتحليله بواسطة القالب.

تشمل مزايا استخدام الوضع غير الدفعي ما يلي:

• عزل حالة الاختبار . لا يؤثر التعطل أو التعليق في حالة اختبار واحدة على حالات الاختبار الأخرى.
• تقسيمات . من الأسهل الحصول على ملفات التعريف/قياس التغطية لكل حالة اختبار، وsystrace، وتقرير الأخطاء، وlogcat، وما إلى ذلك. ويتم استرداد نتائج الاختبار والسجلات فور انتهاء كل حالة اختبار.

تشمل عيوب استخدام الوضع غير الدفعي ما يلي:

• التحميل الزائد . في كل مرة يتم استدعاء GTest ثنائي، فإنه يقوم بتحميل المكتبات ذات الصلة وتنفيذ إعدادات الفئة الأولية.
• النفقات العامة للاتصالات . بعد اكتمال الاختبار، يتواصل المضيف والجهاز المستهدف لتحليل النتائج والأوامر التالية (التحسينات المستقبلية ممكنة).

دفعة واسطة

في الوضع الدفعي GTest، يتم استدعاء ثنائي الاختبار مرة واحدة فقط مع قيمة مرشح اختبار طويل تحتوي على جميع حالات الاختبار التي تمت تصفيتها بواسطة تكوين جانب المضيف (وهذا يتجنب مشكلة التحميل الزائد في الوضع غير الدفعي). يمكنك تحليل نتائج اختبار GTest باستخدام input.xml أو باستخدام الإخراج الطرفي.

عند استخدام input.xml (الافتراضي):

كما هو الحال في الوضع غير الدفعي، يتم تحليل نتيجة الاختبار من خلال ملف XML لإخراج GTest. ومع ذلك، نظرًا لأنه يتم إنشاء ملف XML الناتج بعد اكتمال جميع الاختبارات، إذا تعطلت حالة اختبار في الملف الثنائي أو الجهاز، فلن يتم إنشاء ملف XML الناتج.

عند استخدام الإخراج الطرفي:

أثناء تشغيل GTest، فإنه يطبع سجل الاختبار والتقدم إلى الجهاز بتنسيق يمكن تحليله بواسطة إطار العمل لحالة الاختبار والنتائج والسجلات.

تشمل مزايا استخدام الوضع الدفعي ما يلي:

• عزل حالة الاختبار . يوفر نفس مستوى عزل حالة الاختبار مثل الوضع غير الدفعي إذا قام إطار العمل بإعادة تشغيل الجهاز الثنائي/الجهاز بعد التعطل باستخدام مرشح اختبار مخفض (باستثناء حالات الاختبار المنتهية والمتعطلة).
• تقسيمات . يوفر نفس دقة حالة الاختبار مثل الوضع غير الدفعي.

تشمل عيوب استخدام الوضع الدفعي ما يلي:

• تكلفة الصيانة . إذا تغير تنسيق تسجيل GTest، فسيتم إيقاف جميع الاختبارات.
• ارتباك . يمكن أن تطبع حالة الاختبار شيئًا مشابهًا لتنسيق تقدم GTest، مما قد يؤدي إلى إرباك التنسيق.

وبسبب هذه العيوب، قمنا مؤقتًا بإزالة خيار استخدام إخراج سطر الأوامر. سنعيد النظر في هذا الخيار في المستقبل لتحسين موثوقية هذه الوظيفة.

قالب HostBinaryTest

يتضمن قالب HostBinaryTest ملفات تنفيذية من جانب المضيف غير موجودة في أدلة أخرى أو في برامج Python النصية. تشمل هذه الاختبارات ما يلي:

• ثنائيات الاختبار المجمعة القابلة للتنفيذ على المضيف
• البرامج النصية القابلة للتنفيذ في Shell أو 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، يتم استخدام اسم الملف الثنائي كاسم حالة الاختبار بشكل افتراضي.

توسيع القوالب الموجودة

يمكنك استخدام القوالب مباشرة في تكوين الاختبار لتضمين اختبارات غير بايثون أو توسيعها في فئة فرعية للتعامل مع متطلبات اختبار محددة. تحتوي القوالب الموجودة في مستودع VTS على الامتدادات التالية:

يتم تشجيع المطورين على توسيع أي قالب موجود لأي متطلبات اختبار محددة. تتضمن الأسباب الشائعة لتوسيع القوالب ما يلي:

• إجراءات إعداد الاختبار الخاصة، مثل إعداد جهاز بأوامر خاصة.
• توليد حالات اختبار وأسماء اختبار مختلفة.
• تحليل النتائج من خلال قراءة مخرجات الأمر أو استخدام شروط أخرى.

لتسهيل توسيع القوالب الموجودة، تحتوي القوالب على أساليب مخصصة لكل وظيفة. إذا قمت بتحسين التصاميم للقوالب الموجودة، فإننا نشجعك على المساهمة في قاعدة كود VTS.