openQA للمطورين والمشرفين

يستخدم كيدي لينكس openQA لاختبار كل صورة نظام آليًا قبل نشرها. يُقلع openQA كل صورة في آلة افتراضية ويتحقق من إمكانية تثبيتها وترقيتها واستخدامها بنجاح.

لدى openQA بعض المصطلحات المحددة: الوظيفة هي تنفيذ واحد لمجموعة اختبارات ضد صورة، بينما العامل هو الجهاز أو الحاوية التي تشغّل الوظيفة. تشرح وثائق openQA هذه المفاهيم وغيرها، بما في ذلك وحدات الاختبار ومجموعات الوظائف والأصول وواجهة الويب.

كيف تعمل الاختبارات

يعمل عامل الاختبار جنبًا إلى جنب مع خط أنابيب CI، لذا يمكنه استخدام الصور والأقراص الافتراضية المنتجة من البناء دون رفع تلك الملفات الكبيرة إلى مكان آخر. تُقدَّم الاختبارات إلى الآلة الافتراضية عبر امتداد نظام وتتواصل معها عبر SSH.

تستخدم اختبارات سطح المكتب واجهة برمجة إمكانية الوصول عبر selenium-webdriver-at-spi، مما يسمح لها بالتفاعل مع التطبيقات والتحقق من حالتها دون الاعتماد فقط على مطابقة لقطات الشاشة. تتحقق المجموعة أيضًا من خدمات النظام الفاشلة وعمليات سطح المكتب المنهارة ومشاكل الشبكات والانحدارات في أوامر كيدي لينكس.

خط أنابيب CI وسير عمل المشرف

على الفرع الافتراضي المحمي من مستودع كيدي لينكس الرئيسي، يعمل خط الأنابيب على النحو التالي:

1. تبني وظيفة التصوير الصورة وقناة sysupdate الخاصة بها وتوقّعها وتجهزها على storage.kde.org.
2. تبدأ وظيفة trigger-openqa خط الأنابيب في os-autoinst-distri-kdelinux، وتمرر إليه عنوان URL للصورة المجهزة وعنوان URL لقناة sysupdate.
3. يشغّل خط الأنابيب النهائي التدفق العادي للتثبيت والفحص السليم وتدفق الترقية.
4. تعمل وظيفة النشر الرئيسية فقط بعد نجاح خط أنابيب openQA. ترفّع الصورة المجهزة بالفعل للاستهلاك العام.

يجعل هذا فشل openQA بوابة لنشر الصورة. ابدأ بفتح خط الأنابيب النهائي من وظيفة trigger-openqa، ثم افتح وظيفة openQA الفاشلة من سجل CI الخاص بها. تعرض صفحة الوظيفة وحدات الاختبار بالترتيب وتتيح لك تحديد ما إذا كان الفشل في التثبيت أو اختبارات الفحص السليم للنظام المثبت أو مسار الترقية.

نزّل صورة مجهزة

يفتح الرابط المقدم بعد رسالة السجل “في حالة الفشل، يمكنك فحص وتنزيل صورة .iso وشجرة sysupdate على…” متصفح تخزين للبناء قيد الاختبار. نزّل ملف .iso هناك لتشغيله يدويًا أو أعطه لمكدس openQA محلي. تحتوي شجرة sysupdate على قطع التحديث المجهزة المستخدمة في اختبار الترقية.

حقق في وظيفة فاشلة

افتح الوظيفة في واجهة ويب openQA وحدد الوحدة الفاشلة أولًا. سيظهر رابط واجهة الويب بعد رسالة السجل “وظيفة اختبار تعمل الآن.” تتضمن تفاصيلها نتيجة الوحدة ولقطات الشاشة أو الفيديو حيثما ينطبق ذلك والمخرجات التشخيصية. في تبويب السجلات والأصول، نزّل أو اعرض autoinst-log.txt لعامل openQA وسجل محرك الاختبار. هذا هو السجل الأساسي للوظيفة نفسها.

بالنسبة للاختبارات التي تنفذ أوامر على النظام قيد الاختبار، يشغّلها كيدي لينكس في خدمات systemd عابرة ويسجل دفتر يوميات الخدمة كمخرجات تشخيصية في نتيجة الاختبار. افحص autoinst-log.txt لمخرجات الأوامر ودفتر اليوميات. يمكنك أيضًا تنزيل ملف *kde-linux-collected-logs.tar.zst للسجلات الملتقطة بواسطة أداة collect-logs.

شغّل الاختبارات محليًا

يمكنك استخدام openQA لاختبار صورة مبنية محليًا قبل تقديم تغيير. هذا مطلوب عند العمل من نسخة متفرعة خارج kde-linux/kde-linux - يبني خط أنابيب CI الخاص بها صورة اختبار، لكنه لا يشغّل خط أنابيب openQA. وهو مفيد أيضًا أثناء تطوير اختبارات لتغييراتك الخاصة.

يتضمن مستودع اختبار كيدي لينكس openQA مكدسًا محليًا يحتوي على واجهة ويب openQA وعاملًا. يتطلب Podman وpodman-compose، وهما مضمنان في كيدي لينكس.

استنسخ مستودع الاختبار، ثم ضع صورة كيدي لينكس .iso التي تريد اختبارها في دليله الجذري. إذا لم تكن هناك صورة، ينزّل مشغل الاختبار أحدث صورة متاحة للعموم بدلًا من ذلك.

ابدأ المكدس المحلي.

./mock.sh up

بمجرد أن يصبح جاهزًا، افتح http://localhost:1080 لفحص واجهة ويب openQA. لا تُرسل الوظائف تلقائيًا، لذا افتح صدفة في الحاوية وأرسل التدفق العادي للتثبيت واختبار الفحص السليم.

podman exec -it openqa-single-instance bash
./qa flow

لتشغيل تدفق الترقية بدلًا من ذلك، أضف --upgrade:

./qa flow --upgrade

لتشغيل تدفق اختبار التثبيت بتعمية القرص، أضف --encrypt:

./qa flow --encrypt

يمكنك أيضًا دمج خياري --upgrade و--encrypt:

./qa flow --upgrade --encrypt

تحتاج وظيفة sanity-test إلى تشغيل وظيفة install-system أولًا لأنها تستخدم القرص الافتراضي الذي أنشأه التثبيت. للتركيز على اختبار معين، اضبط الوظائف المرسلة في lib/worker/job_flow.py أو شغّل وظيفة فردية باستخدام ./qa job مع مراعاة هذا الاعتماد. شغّل ./qa job --help لرؤية الخيارات التي يتطلبها.

على سبيل المثال، لتشغيل وظيفة install-system حيث لديك ملف .iso منزّل إلى دليل المستودع:

./qa job \
    --live ./kde-linux_<build-id>.iso \
    --hdd kde-linux_<build-id>.qcow2 \
    --sysext ./openqa-sysext.img \
    --build <build-id> \
    --name install-system \
    --flavor live

عند الانتهاء، أوقف المكدس وأزل وحدات التخزين المحلية الخاصة به.

./mock.sh down -v

اكتب اختبارًا

تعريفات الاختبار ورمز الاختبار موجودة في os-autoinst-distri-kdelinux. أضف الاختبار إلى التدفق المناسب في main.pm - تدفق التثبيت المباشر، أو تدفق فحص سلامة النظام المثبت، أو تدفق الترقية. تتكون الاختبارات عمومًا من غلاف openQA صغير في tests/ واختبار بايثون يعمل على النظام قيد الاختبار من extensions/openqa/usr/lib/kde-linux-openqa/tests/.

اختر نوع الاختبار بناءً على ما تفحصه:

• استخدم unittest بايثون عاديًا لأدوات سطر الأوامر، أو الخدمات، أو حالة نظام الملفات، أو أي سلوك غير رسومي آخر.
• استخدم Selenium عبر selenium-webdriver-at-spi عندما يتطلب السلوك التفاعل مع تطبيق رسومي.

اختبارات بايثون العادية

أنشئ unittest في دليل اختبار امتداد النظام المذكور سابقًا. يجب أن يقدم تأكيدات حول النظام قيد الاختبار ويكتب نتائجه إلى ملف JUnit XML، الذي يُجمع آليًا كأصل openQA وتقرير GitLab CI.

import unittest
from lib.sut import openqa_junit_xml

class ExampleTests(unittest.TestCase):
    def test_expected_behaviour(self):
        self.assertTrue(True)

if __name__ == "__main__":
    openqa_junit_xml.run(ExampleTests, "example")

أنشئ غلافًا مطابقًا تحت tests/ يجعل openQA ينفذ الاختبار على المضيف.

from testapi import *
from lib.test import cli_test

def run(self):
    cli_test.CliTest("example").run_python()

أخيرًا، سجّل الغلاف في التدفق ذي الصلة في main.pm. يجمع الغلاف نتيجة JUnit ومخرجات الأوامر بحيث تظهر الإخفاقات في مهمة openQA وقطع CI الأثرية.

الاختبارات الرسومية مع Selenium

الاختبارات الرسومية هي أيضًا أصناف unittest بايثون، لكنها تستخدم برنامج تشغيل Appium/Selenium للعثور على عناصر واجهة المستخدم القابلة للوصول والتفاعل معها. مفعّل Selenium يشغّل البنية التحتية لإمكانية الوصول ويبدأ برنامج التشغيل نيابةً عنك.

على سبيل المثال، ينشئ اختبار رسومي برنامج تشغيل لتطبيقه، ويتفاعل مع العناصر القابلة للوصول، ويغلق برنامج التشغيل بعد ذلك:

import unittest
from appium import webdriver
from appium.options.common.base import AppiumOptions
from appium.webdriver.common.appiumby import AppiumBy
from lib.test import openqa_junit_xml

class ExampleTests(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        options = AppiumOptions()
        options.set_capability("app", "org.kde.example.desktop")
        cls.driver = webdriver.Remote("http://127.0.0.1:4723", options=options)

    @classmethod
    def tearDownClass(cls):
        cls.driver.quit()

    def test_expected_behaviour(self):
        self.driver.find_element(AppiumBy.ACCESSIBILITY_ID, "example-control").click()

if __name__ == "__main__":
    openqa_junit_xml.run(ExampleTests, "example")

شغّل الغلاف المطابق باستخدام run_selenium() بدلًا من run_python(). مرّر مستخدم الاختبار المثبت لتطبيقات سطح المكتب:

from testapi import *
from lib.test import cli_test
from lib.common import user_manager

def run(self):
    cli_test.CliTest("example").run_selenium(user=user_manager.installed())

على غرار اختبارات بايثون العادية، أضف غلافه إلى main.pm، وشغّله محليًا أثناء تطويره، وأدرجه في تدفق الاختبار الذي يختبر الميزة.

لمزيد من المعلومات حول كتابة اختبارات Selenium، راجع اختبار الأتمتة Appium واختبار الواجهة الرسومية مع selenium-webdriver-at-spi.

تعلّم المزيد

لشرح أكثر تفصيلًا لتدفق الاختبار وتنفيذه، راجع اختبار openQA في كيدي لينكس. تُطوَّر البنية التحتية للاختبار في مستودع os-autoinst-distri-kdelinux.

المقالة مساهمة من Thomas Duckworth تحت ترخيص CC-BY-4.0.