نماذج الاختبار

يتضمّن AOSP نماذج اختبارات لوحدات الاختبار التي لا تستند إلى Python subclass من BaseTest الخاص ببرنامج تشغيل VTS.

الشكل 1: اختبار بنية النموذج

يمكن للمطوّرين استخدام هذه النماذج لتقليل الجهد المبذول في دمج هذه الاختبارات. يتناول هذا القسم إعداد نماذج الاختبار واستخدامها (المتوفّرة في دليل اختبارات الفيديو المباشر testcases/template )، كما يقدّم أمثلة على النماذج المستخدَمة بشكل شائع.

نموذج BinaryTest

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

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

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

اسم الخيار نوع القيمة الوصف
binary-test-source سلاسل مسارات مصدر الاختبار الثنائي بالنسبة إلى دليل حالات اختبار vts على المضيف
مثال: DATA/nativetest/test
binary-test-working-directory سلاسل أدلة العمل (المسار على الجهاز)
مثال: /data/local/tmp/testing/
binary-test-envp سلاسل متغيّرات البيئة للملف الثنائي
مثال: PATH=/new:$PATH
binary-test-args سلاسل اختبار الوسيطات أو العلامات
مثال: --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 مرّتين (كما هو موضّح في مثال 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

في أداة اختبار الفيديو، يكون تنسيق الاختبار التلقائي هو اختبارات Python من جهة المضيف التي تم تمديدها من BaseTest في أداة تشغيل أداة اختبار الفيديو. لدمج الاختبارات على الجانب المستهدَف، عليك أولاً دفع ملفات الاختبار إلى الجهاز وتنفيذ الاختبارات باستخدام أوامر 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: الوضع غير المجمّع:

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

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

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

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

وضع الدفعات

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

عند استخدام output.xml (الإعداد التلقائي):

الشكل 3: وضع الدُفعات، output.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 نموذج BinaryTest، ولكنه يستخدم إعدادات اختبار مشابهة. في المثال أعلاه، يحدِّد الخيار binary-test-source مسارًا نسبيًا من جهة المضيف إلى الملف التنفيذي للاختبار، وbinary-test-type هو host_binary_test. على غرار ملف نموذج BinaryTest، يتم استخدام اسم ملف الثنائي كاسم حالة الاختبار بشكلٍ تلقائي.

توسيع النماذج الحالية

يمكنك استخدام النماذج مباشرةً في إعداد الاختبار لتضمين اختبارات غير مكتوبة بلغة Python أو تمديدها في فئة فرعية للتعامل مع متطلبات اختبار معيّنة. تحتوي النماذج في ملف ترميز VTS على الإضافات التالية:

الشكل 5: توسيع النماذج الحالية في مستودع VTS

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

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

لتسهيل توسيع النماذج الحالية، تحتوي النماذج على طُرق مخصّصة لكل وظيفة. إذا كانت لديك تصاميم محسّنة للنماذج الحالية، ننصحك بالمساهمة في قاعدة رموز VTS البرمجية.