يتضمّن AOSP نماذج اختبار لوحدات الاختبار التي ليست بلغة Python من جهة المضيف. فئة فرعية من BaseTest لعدّاء VTS.
يمكن للمطوّرين استخدام هذه النماذج لتقليل الجهد المبذول في دمج هذه الاختبارات. يتناول هذا القسم إعداد الاختبار واستخدامه. النماذج (الموجودة في VTS testcases/template ) وتقدم أمثلة للقوالب شائعة الاستخدام.
نموذج الاختبار الثنائي
يمكنك استخدام الاختبار الثنائي لدمج الاختبارات التي يتم تنفيذها على الجهاز المستهدف في VTS. تشمل الاختبارات الجانبية ما يلي:
- الاختبارات المستندة إلى C++ التي يتم تجميعها وإرسالها إلى الجهاز
- اختبارات Python من جهة الهدف مجمّعة كبرامج ثنائية
- النصوص البرمجية لـ Shell القابلة للتنفيذ على الأجهزة
يمكن دمج هذه الاختبارات في VTS مع الاختبار الثنائي أو بدونه القالب.
ادمج الاختبارات الجانبية مع نموذج الاختبار الثنائي
صُمِّم نموذج 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/ |
بيئة-اختبار-ثنائي | السلاسل | متغيّرات البيئة للبرامج الثنائية. مثال: PATH=/new:$PATH |
وسيطات-الاختبار-الثنائي | السلاسل | اختبِر الوسيطات أو العلامات. مثال: --gtest_filter=test1 |
مسار ثنائية-test-ld-library-path | السلاسل | متغيّر بيئة واحد (LD_LIBRARY_PATH )مثال: /data/local/tmp/lib |
إطار عمل إيقاف الاختبار الثنائي | منطقية | عليك تشغيل "adb stop " لإيقاف إطار عمل Android قبل الاختبار.
مثلاً: 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
في تقرير النتائج.
دمج الاختبارات الجانبية بدون نموذج الاختبار الثنائي
في VTS، تنسيق الاختبار الافتراضي هو اختبارات Python من جهة المضيف التي تم تمديدها من BaseTest في أداة تشغيل VTS لدمج اختبارات الجانب المستهدف، يجب أولاً دفع اختبار الملفات إلى الجهاز وتنفيذ الاختبارات باستخدام أوامر واجهة الأوامر، ثم تحليل باستخدام نصوص برمجية من جانب المضيف بلغة بايثون.
برامج ثنائية تجريبية للدفع
ننصحك بإرسال الملفات باستخدام أداة إعداد الهدف "VtsFilePusher
".
مثال:
<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher"> <option name="push" value="DATA/test->/data/local/tmp/test"/> </target_preparer>
تنفِّذ ميزة VtsFilePusher
ما يلي:
- يتحقق من اتصال الجهاز.
- يحدِّد المسار المطلق لملف المصدر.
- لإرسال الملفات باستخدام الأمر
adb push
. - يتم حذف الملفات بعد اكتمال الاختبارات.
يمكنك بدلاً من ذلك إرسال الملفات يدويًا باستخدام اختبار 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 بتجاوز الإعداد، وإنشاء حالة الاختبار، وطرق تحليل النتائج، بحيث يتم إجراء جميع مكتسَبة من الإعدادات.
يضيف GtestBinaryTest الخيار gtest-batch-mode
:
اسم الخيار | نوع القيمة | الوصف |
---|---|---|
نوع الاختبار الثنائي | سلسلة | نوع النموذج. لاستخدام القيمة gtest . |
وضع الدفعة gtest | منطقية | قم بتشغيل برامج Gtest الثنائية في الوضع المجمّع. مثال: true |
بشكل عام، يؤدي ضبط السمة gtest-batch-mode
على true
.
زيادة الأداء مع تقليل الموثوقية قليلاً. الامتثال إلى اختبار VTS
اختبارات، تستخدم العديد من الوحدات الوضع المجمّع لتحسين الأداء. للموثوقية
ومع ذلك، إذا لم يتم تحديد الوضع، فيتم ضبطه افتراضيًا على "غير دفعة".
وضع عدم الدفعة
يعمل الوضع غير المجمّع على إجراء استدعاءات فردية لبرنامج ثنائي GTest لكل حالة اختبار. بالنسبة على سبيل المثال، إذا كان البرنامج الثنائي GTest يحتوي على 10 حالات اختبار (بعد التصفية حسب المضيف) الإعداد الجانبي)، يتم استدعاء البرنامج الثنائي 10 مرات على هيكل الجهاز في كل مرة باستخدام فلتر اختبار مختلف. لكل حالة اختبار، يتم إخراج نتيجة فريدة لاختبار GTest يتم إنشاء XML وتحليله بواسطة النموذج.
تشمل مزايا استخدام وضع عدم الدفعة ما يلي:
- عزل حالة الاختبار: حادث أو تعليق في حالة اختبار واحدة لا تؤثر في حالات الاختبار الأخرى.
- درجة الدقة: سهولة الحصول على الملفات الشخصية/التغطية لكل حالة اختبار قياس، systrace، تقرير الأخطاء، Logcat، إلخ. نتائج الاختبار والسجلات استرجاعها فور انتهاء كل حالة اختبار.
تشمل عيوب استخدام وضع عدم الدفعة ما يلي:
- التحميل المكرَّر في كل مرة يتم فيها استدعاء برنامج GTest الثنائي، فإنها تحمّل المكتبات ذات الصلة وتُنفذ عمليات الإعداد الأولية للفئة.
- أعباء التواصل: بعد اكتمال الاختبار، يقدّم المضيف والاتصال بين الجهاز المستهدف لتحليل النتائج والأوامر التالية (مستقبل التحسينات الممكنة).
وضع الدفعة
في وضع GTest المجمَّع، لا يستدعي البرنامج الثنائي الاختبار سوى مرة واحدة فقط باستخدام اختبار طويل تتضمن قيمة الفلتر جميع حالات الاختبار التي تمت تصفيتها حسب التهيئة من جانب المضيف (هذه مشكلة التحميل الزائد في وضع عدم الدفعة). يمكنك تحليل الاختبار نتائج لـ GTest باستخدام exit.xml أو باستخدام المخرجات الطرفية.
عند استخدام asset.xml (الإعداد التلقائي):
وكما هو الحال في الوضع غير المجمّع، يتم تحليل نتيجة الاختبار من خلال GTest audio xml. الملف. مع ذلك، بما أنّه يتم إنشاء ملف XML بعد إجراء جميع الاختبارات مكتملة، إذا تعطّلت حالة اختبار على البرنامج الثنائي أو لم يتم عرض ملف XML للنتائج التي تم إنشاؤها.
عند استخدام الإخراج الطرفي:
أثناء تشغيل GTest، يطبع سجل الاختبار ومستوى التقدم إلى الوحدة الطرفية. بتنسيق يمكن تحليله من خلال إطار العمل لحالة الاختبار والنتائج والسجلات.
تشمل مزايا استخدام الوضع المجمّع ما يلي:
- عزل حالة الاختبار: تقديم مستوى الاختبار نفسه عزل الحالة كوضع غير مجمّع إذا أعاد إطار العمل تشغيل البرنامج الثنائي/الجهاز بعد وقوع حادث سير مع تقليل فلتر الاختبار (باستثناء الاختبار المكتمل والمتعطل) الحالات).
- درجة الدقة: يوفر درجة الدقة نفسها في حالة الاختبار كما وضع عدم الدفعة.
ومن عيوب استخدام الوضع المجمّع ما يلي:
- تكلفة الصيانة. إذا تغيّر تنسيق تسجيل GTest، فستتعطل جميع الاختبارات.
- الالتباس: يمكن لحالة الاختبار طباعة شيء يشبه GTest تنسيق التقدم، مما قد يربك التنسيق.
ونظرًا لهذه العيوب، أزلنا مؤقتًا خيار استخدام مخرجات سطر الأوامر. وسنعيد النظر في هذا الخيار في المستقبل لتحسين موثوقية هذه الدالة.
نموذج HostBinaryTest
يتضمن نموذج HostBinaryTest ملفات تنفيذية من جانب المضيف وغير موجودة في أدلة أخرى أو في نصوص بايثون تشمل هذه الاختبارات ما يلي:
- برامج ثنائية تجريبية مجمّعة وقابلة للتنفيذ على المضيف
- النصوص البرمجية القابلة للتنفيذ في واجهة الأوامر أو 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 الإضافات التالية:
ننصح المطوّرين بتوسيع أي نموذج حالي لأي نموذج متطلبات الاختبار. تتضمّن الأسباب الشائعة لتوسيع نطاق النماذج ما يلي:
- إجراءات خاصة لإعداد الاختبار، مثل إعداد جهاز يتضمن الأوامر.
- إنشاء حالات اختبار وأسماء اختبارات مختلفة
- تحليل النتائج من خلال قراءة مخرجات الأمر أو استخدام شروط أخرى
لتسهيل توسيع النماذج الحالية، تحتوي النماذج على طرق. المخصصة لكل وظيفة. إذا قمتَ بتحسين التصميمات الحالية نشجعك على المساهمة في قاعدة رموز VTS.