معمارية أتمتة الاختبار

بقلم فريق ضمان الجودة في متقن سوفت · آخر تحديث 6 أكتوبر 2026 · 19 دقيقة · متوسط

معمارية أتمتة الاختبار (Test Automation Architecture) هي التصميم التقني الذي تقوم عليه اختباراتك الآلية: ما الأجزاء الموجودة، وما مسؤولية كل جزء، وكيف تتصل الأجزاء ببعضها وبالنظام قيد الاختبار (SUT). ويميّز منهج ISTQB للمستوى المتقدم في هندسة أتمتة الاختبار (CTAL-TAE) بين المعمارية (أي التصميم)، وإطار أتمتة الاختبار (Test Automation Framework)، أي الشيفرة التي تنفّذ التصميم: مشغّل اختبارات ومكتبات وسكربتات اختبار وحزم، وحلّ أتمتة الاختبار (Test Automation Solution)، أي الإطار مع الأدوات والمحوّلات (Adapters) التي يحتاجها لنظام بعينه.

يظهر التصميم الجيد في ثلاث إجابات يومية. تغيّرت صفحة تسجيل الدخول: كم ملفاً تعدّل؟ ملفاً واحداً. يجب أن تعمل الحزمة على بيئة staging: ما الذي يتغيّر؟ إعداد واحد. فشل اختبار ليلاً: هل يقول السجل لماذا؟ نعم، من دون إعادة التشغيل. وينتقل هذا الدرس من كائنات الصفحات (Page Objects) في الدرس السابق إلى الإطار كله.

لماذا يهم

من دون تصميم، تنسخ الحزمة المتنامية المحددات (Locators) وعناوين URL وأوامر الانتظار وخطوات تسجيل الدخول نفسها في كل ملف، فيتضاعف أثر كل تغيير في المنتج بعدد النسخ. عندها تستهلك الصيانة الوقت المخصص لاختبارات جديدة، وتتأخر الحزمة عن المنتج، ويتوقف الفريق عن الثقة بها.

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

ثلاث طبقات وقاعدة واحدة

يصف منهج CTAL-TAE إطار الأتمتة في ثلاث طبقات، لكل منها سببها الخاص للتغيّر، وينصح بإبقاء عدد الطبقات قليلاً، لأن تخصيص طبقة لكل غرض يجعل التصميم أصعب فهماً.

تربط الطبقات قاعدة واحدة: الاستدعاءات تنزل إلى الأسفل فقط. ينص المنهج على أن سكربتات الاختبار لا ينبغي أن تستدعي المكتبات الأساسية مباشرةً، فلا يقود الاختبار المتصفح بنفسه، ولا يبني عنوان URL، ولا يقرأ متغير بيئة. وتحت المكتبات الأساسية تتصل الأداة المختارة، مثل Playwright أو Selenium WebDriver أو مكتبة HTTP، بالنظام قيد الاختبار؛ ويسمّي المنهج ذلك تكييف الاختبار (Test Adaptation).

سكربتات الاختبار (Test Scripts): حالات الاختبار وحزمها بلغة العمل، مثل checkout.payWithSavedCard() يليه تأكيد على الإجمالي. تتغير حين يتغير المتطلب.
منطق العمل (Business Logic): كل ما يعرف هذا النظام بعينه، مثل كائنات الصفحات والتدفقات وعملاء API ومُنشئات بيانات الاختبار والكلمات المفتاحية. وتُصلَح هنا الشاشة أو نقطة النهاية المتغيرة، مرة واحدة.
المكتبات الأساسية (Core Libraries): كل ما لا يعتمد على النظام قيد الاختبار، مثل تهيئة المتصفح وHTTP، ومحمّل الإعدادات، والسجل (Logger)، ومساعدات إعادة المحاولة. يمكن لأي مشروع على المجموعة التقنية نفسها إعادة استخدامها، وتتغير حين تتغير الأدوات.

إطار أتمتة الاختبار في ثلاث طبقات فوق الأداة والنظام قيد الاختبار: الاستدعاءات تنزل إلى الأسفل فقط، فتُصلَح الشاشة المتغيرة في منطق العمل، وترقية الأداة في المكتبات الأساسية.

الاستدعاءات تنزل إلى الأسفل فقط

1سكربتات الاختبارtests/حالات الاختبار وحزمها بلغة العمل، مع تأكيداتها
تتغير حين يتغير المتطلب
2منطق العملbusiness/كائنات الصفحات والتدفقات وعملاء API ومُنشئات البيانات والكلمات المفتاحية: كل ما يعرف هذا النظام
تتغير حين تتغير شاشة أو نقطة نهاية
3المكتبات الأساسيةcore/محمّل الإعدادات والسجل وتهيئة المتصفح وHTTP وإعادة المحاولة: لا شيء خاص بالنظام
تتغير حين تتغير الأدوات؛ ويُعاد استخدامها على المجموعة التقنية نفسها
4الأداة والنظام قيد الاختبارتقود Playwright أو Selenium WebDriver أو مكتبة HTTP النظامَ في بيئة واحدة (تكييف الاختبار)

من سكربتات الاختبار إلى المكتبات الأساسية:غير مسموح: اختبار يستدعي برنامج التشغيل أو السجل أو الإعدادات مباشرةً

أسماء الطبقات من منهج ISTQB CTAL-TAE، الذي ينصح بإبقاء عدد الطبقات قليلاً. وتقرأ الطبقة الأساسية ملفات config/، وتأتي الأسرار من مخزن الأسرار في CI.

shop-e2e/
  tests/                    test scripts: business terms and assertions
    delivery-fee.spec.ts
    refunds.spec.ts
  business/                 knows this SUT; calls core/, never tests/
    pages/                  page and component objects
    flows/                  user tasks across pages: signIn, placeOrder
    api/                    API clients for set-up and clean-up
    data/                   test data builders
  core/                     knows no SUT; reusable on the same stack
    config.ts               loads and validates configuration
    logger.ts               levels, redaction, run header
    browser.ts  http.ts     tool set-up, retries
  config/                   one file per environment, no secrets
    test.json  staging.json

المكوّنات القابلة لإعادة الاستخدام، ومتى لا تشاركها

يسمّي منهج CTAL-TAE الاختبارات المبنية من مكتبة خطوات وتدفقات مستخدم قابلة لإعادة الاستخدام بالسكربتات المهيكلة (Structured Scripting). استخرج مكوّناً حين تظهر الخطوات نفسها في عدة اختبارات وتتغير للسبب نفسه:

التدفقات (Flows): مهمة مستخدم واحدة عبر عدة صفحات، مثل signIn(user) أو placeOrder(cart). ويسمّي المنهج ذلك نموذج التدفق (Flow Model): واجهة (Facade) ثانية، أي واجهة مبسّطة تخفي التفاصيل، فوق كائنات الصفحات، تُعاد بها الخطوات في اختبارات كثيرة.
مساعدات التهيئة عبر API ومُنشئات بيانات الاختبار التي تُنشئ العميل أو المنتج الذي يحتاجه اختبار الواجهة، بسرعة وموثوقية أكبر من النقر عبر الشاشات.
ما لا يستحق البناء: دالة مساعدة بعشرة خيارات اختيارية، أو صنف أساسي بمئات الدوال ترثه كل صفحة، أو غلاف سميك يخفي الأداة ويُبطل فائدة توثيقها. استخرج المكوّن عند النسخة الثانية أو الثالثة، لا قبل الأولى.

الإعدادات والسجلات

الإعدادات (Configuration) هي كل ما يختلف بين مرات التشغيل لا بين الاختبارات: عناوين URL الأساسية والمتصفح والمهل وحسابات الاختبار وأعلام الميزات (Feature Toggles). خصّص ملفاً لكل بيئة يختاره متغير واحد مثل TEST_ENV=staging، وخذ الأسرار من مخزن الأسرار في نظام CI، الذي يمرّرها عادةً إلى التشغيل على شكل متغيرات بيئة، لا من ملف محفوظ في المستودع. وتحقق من الإعدادات مرة واحدة عند بدء التشغيل في مكتبة أساسية، حتى توقف القيمة الناقصة التشغيل برسالة واضحة واحدة بدلاً من إفشال ⁦200⁩ اختبار واحداً تلو الآخر.

السجلات (Logging) هي الطريقة التي يشرح بها التشغيل الفاشل نفسه. يصف منهج CTAL-TAE ستة مستويات: fatal للأخطاء التي قد توقف التشغيل، وerror حين يفشل شرط أو تفاعل فيفشل معه الاختبار، وwarn لأمر غير متوقع لا يوقف الاختبار، وinfo لما يفعله الاختبار، وdebug للتفاصيل التي تفيد في تحليل الإخفاق، وtrace لتفاصيل أكثر منها. ويسرد المنهج أيضاً ما ينبغي أن يسجله الإطار، وهذا يعني عملياً:

ترويسة التشغيل: البيئة، وإصدار بناء النظام قيد الاختبار، والمتصفح، والإعدادات الفعلية مع إخفاء الأسرار.
لكل اختبار: الاسم، ووقت البدء والانتهاء، والخطوات الرئيسية بمستوى info، والحالة: ناجح، أو فاشل، أو إخفاق في الأتمتة نفسها لا في النظام قيد الاختبار.
لإعادة إنتاج الإخفاق: معرّفات العناصر التي أنشأها الاختبار وأي قيمة عشوائية أو بذرة (Seed) استخدمها؛ ومحتوى الطلبات والاستجابات بمستوى debug.
الإخفاء (Redaction): حجب رموز الوصول وكلمات المرور والبيانات الشخصية، مثلاً بنمط يُطبَّق قبل كتابة كل سطر.

// config/staging.json: committed, contains no secrets
{
  "baseUrl": "https://staging.shop.example",
  "browser": "chromium",
  "timeoutMs": 10000
}
// SHOP_API_TOKEN comes from the CI secret store; TEST_ENV=staging selects this file

// test log, info level
03:00:04 INFO  run env=staging build=4.18.2 browser=chromium token=***
03:02:11 INFO  [delivery-fee] orders of 300.00 SAR ship free: start
03:02:12 INFO  created customer C-58213 and product P-7781 via API
03:02:15 INFO  step: add P-7781 to cart, open checkout
03:02:18 ERROR delivery fee: expected 0.00, actual 7.50
03:02:18 INFO  saved screenshot and trace in results/delivery-fee/
03:02:18 INFO  [delivery-fee] end: failed after 7 s

جرّبها: مدقّق JSON جرّبها: مدقّق JSON Schema جرّبها: أداة اختبار Regex

أساليب كتابة السكربتات وكلفة صيانتها

يسرد منهج CTAL-TAE عدة طرق لكتابة الاختبارات نفسها، مع مزاياها وعيوبها؛ والطرق الخمس أدناه مرتبة تقريباً من الأقل استثماراً مبدئياً إلى الأكثر. ويتناول المنهج أيضاً التطوير الموجَّه بالاختبار (TDD) والتطوير الموجَّه بالسلوك (BDD)؛ ولـBDD درس خاص لاحقاً في هذه الوحدة.

التسجيل وإعادة التشغيل (Capture/Playback): تسجّل أداةٌ الإجراءات اليدوية على النظام وتولّد سكربتاً. البدء سريع، لكن لا شيء يُعاد استخدامه، ويعتمد التسجيل على إصدار النظام الذي التُقط منه، وتغيّر الشاشة يعني التسجيل من جديد. يناسب نطاقاً صغيراً على نظام نادر التغيّر.
السكربتات الخطية (Linear Scripting): سكربت لكل اختبار، خطواته من الأعلى إلى الأسفل، بلا مكتبات مشتركة. تعديله أسهل من التسجيل، لكن كل تغيير يتكرر في كل نسخة. يناسب تجربة تقنية (Spike) أو عدداً قليلاً من الاختبارات.
السكربتات المهيكلة (Structured Scripting): تستدعي الاختبارات خطوات وتدفقات قابلة لإعادة الاستخدام من طبقة منطق العمل. تحتاج إلى مهارات برمجية واستثمار مبدئي، وبعد ذلك يُصلَح التغيير في مكان واحد.
الاختبار المعتمد على البيانات (Data-driven): سكربتات مهيكلة تغذيها صفوف من ملفات CSV أو جداول بيانات أو JSON. الحالة الجديدة تكلّف صفاً واحداً، ويستطيع محللو الاختبار إضافة حالات دون شيفرة؛ وتنتقل الكلفة إلى إدارة البيانات.
الاختبار المعتمد على الكلمات المفتاحية (Keyword-driven): الاختبار جدول من كلمات مفتاحية مسمّاة من وجهة نظر المستخدم، مثل Add Product To Cart، مع بياناتها. وكثيراً ما يُبنى على الاختبار المعتمد على البيانات، والجزء ISO/IEC/IEEE ⁦29119-5⁩ من معيار اختبار البرمجيات مخصص له. يستطيع من لا يبرمجون تركيب الاختبارات، لكن تصميم مكتبة الكلمات المفتاحية وصيانتها يزدادان صعوبة كلما اتسع النطاق، وهما جهد كبير لنظام صغير.

خمسة أساليب لكتابة السكربتات جنباً إلى جنب: مِمّ يتكوّن الاختبار، وكم يكلّف تغيير المنتج في الصيانة، ومتى يناسب كل أسلوب.

الأسلوب	الاختبار هو	حين يتغير المنتج	يناسب حين
التسجيل وإعادة التشغيل	تسجيل لإجراءات يدوية	أعد تسجيل الاختبارات المتأثرة	نطاق صغير على نظام نادر التغيّر
السكربتات الخطية	سكربت من الأعلى إلى الأسفل بلا شيفرة مشتركة	عدّل كل نسخة من الخطوات المتغيرة	تجربة تقنية أو اختبارات قليلة
السكربتات المهيكلة	استدعاءات لخطوات وتدفقات قابلة لإعادة الاستخدام	عدّل مكوّناً واحداً	حزمة يُراد لها أن تدوم ويصونها مبرمجون
المعتمد على البيانات	سكربت مهيكل مع صفوف بيانات	عدّل مكوّناً واحداً؛ والحالة الجديدة صف واحد	الخطوات نفسها مع تركيبات مدخلات كثيرة
المعتمد على الكلمات المفتاحية	جدول كلمات مفتاحية وبياناتها	عدّل الكلمة المفتاحية؛ ومكتبة الكلمات تحتاج إلى مالك	كثيرون ممن لا يبرمجون يكتبون اختبارات في مجال مستقر

مبني على المزايا والعيوب الواردة في منهج ISTQB CTAL-TAE. والحزم الحقيقية تمزج الأساليب، مثل اختبارات بالكلمات المفتاحية فوق شيفرة مهيكلة معتمدة على البيانات.

جرّبها: مولّد مجموعات بيانات CSV

مثال تطبيقي: حزمة اختبارات لإتمام الشراء بالكلمات المفتاحية

لدى متجر إلكتروني مهندسا أتمتة وخمسة مختبِرين يعرفون قواعد العمل لكنهم لا يكتبون الشيفرة. تتغير قواعد رسوم التوصيل كل ربع سنة، ويجب أن يضيف المختبِرون الحالات بأنفسهم، فيختار الفريق إطاراً معتمداً على الكلمات المفتاحية. وRobot Framework، وهو إطار مفتوح المصدر مكتوب بلغة Python، مثال واحد على هذا الأسلوب؛ ولا شيء هنا يعتمد عليه.

يكتب المختبِرون جداول مثل الجدول أدناه، بالقيم الحدّية لقاعدة «الطلبات بقيمة ⁦300.00⁩ ريال فأكثر توصيلها مجاني». ويملك المهندسون الكلمات المفتاحية، وهي منطق عمل مبني على عميل API وكائنات صفحات. ويناسب الأسلوب هذا الفريق لأن كثيرين ممن لا يبرمجون يكتبون اختبارات بمفردات مجال مستقرة، ولأن مهندساً مكلّف بالكلمات المفتاحية. أما مطوّران يكتبان الاختبارات بالشيفرة أصلاً، فلن تضيف لهما الكلمات المفتاحية إلا طبقة أخرى يقرآنها حين يفشل اختبار.

# tests/delivery_fee.robot, written by the testers
*** Settings ***
Resource    ../keywords/checkout.resource

*** Test Cases ***
Orders of 300.00 SAR ship free
    Sign In As New Customer
    Add Test Product To Cart    price=300.00
    Delivery Fee Should Be    0.00

Orders of 299.99 SAR pay 7.50 SAR
    Sign In As New Customer
    Add Test Product To Cart    price=299.99
    Delivery Fee Should Be    7.50

# keywords/checkout.resource (excerpt), maintained by the automation engineers
*** Keywords ***
Add Test Product To Cart
    [Arguments]    ${price}    ${quantity}=1
    ${sku}=    Create Product Via API    price=${price}
    Open Product Page    ${sku}
    Add To Cart    quantity=${quantity}

أخطاء شائعة

السماح للاختبارات باستدعاء برنامج التشغيل (Driver) أو بناء عناوين URL أو قراءة متغيرات البيئة، فيعني التغيير الواحد تعديل كل اختبار.
بناء طبقات وأغلفة وكلمات مفتاحية قبل أن تكشف الاختبارات العشرة الأولى ما يتكرر فعلاً.
تغليف الأداة بغلاف سميك إلى حدّ لا ينطبق معه توثيقها.
كتابة قيم البيئة داخل الشيفرة وحفظ الأسرار في المستودع.
سجلات أفقر من أن تشخّص الإخفاق، أو مزدحمة بمستوى info حتى يُدفن السبب، أو تحتوي على رموز وصول وبيانات شخصية.
اختيار الاختبار المعتمد على الكلمات المفتاحية دون تكليف أحد بتصميم الكلمات المفتاحية وصيانتها.

من منظور ضمان الجودة

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

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

تمرين عملي

صمّم المعمارية لحزمة سكربتات خطية

المطلوب

يطلب منك فريق مراجعة حزمة اختبارات الواجهة لموقع حجز الفنادق الخاص به، الموصوفة أدناه. اقترح معمارية مستهدفة: ما الذي يوضع في كل طبقة، وكيف تعمل الإعدادات والسجلات، وأي أسلوب لكتابة السكربتات يناسب كل حاجة. ولكل قرار، سمِّ كلفة الصيانة التي يزيلها.

المادة

الحزمة: 85 اختبار واجهة خطياً، ملف لكل اختبار، بلا شيفرة مشتركة.
يبدأ كل اختبار بهذه الأسطر:

  await page.goto('https://test.booking.example/login');
  await page.fill('#email', 'qa.team@booking.example');
  await page.fill('#password', 'Booking-2026');
  await page.click('#login-btn');
  await page.waitForTimeout(3000);

حقائق:
- 60 اختباراً تكرر أسطر البحث الستة نفسها؛ و25 منها تدفع بعد ذلك ببطاقة اختبار.
- يجب أن تعمل الحزمة ليلاً على بيئة "test"، وعلى "staging" قبل كل إصدار.
- لا تُظهر حالات الفشل في CI إلا "Timeout 30000ms exceeded" وتتبع المكدس.
- يريد محلّلا أعمال إضافة حالات لأسعار الحجز دون كتابة شيفرة.

الخطوات

ضع كل خطوة مكررة في طبقة.
قرّر ما الذي ينتقل إلى الإعدادات ومن أين تأتي الأسرار.
اكتب ما يجب أن يحتويه السجل لتشخيص الإخفاق التالي في CI دون إعادة التشغيل.
اختر أسلوب كتابة السكربتات للاختبارات الحالية ولحالات المحلّلين.

إظهار الإجابة النموذجية

الإجابة النموذجية

الطبقات: يحتفظ tests/ بالاختبارات الـ⁦85⁩، وقد اختُصر كل منها إلى خطواته وتأكيداته. ويحصل business/ على كائنات صفحات لصفحات تسجيل الدخول والبحث والنتائج والدفع، والتدفقات signIn وsearchHotel وpayByTestCard، وعميل API يُنشئ حساب اختبار جديداً لكل تشغيل. ويحصل core/ على محمّل الإعدادات والسجل وتهيئة المتصفح. فينخفض تغيير تسجيل الدخول من ⁦85⁩ تعديلاً إلى تعديل واحد، وتغيير البحث من ⁦60⁩ إلى واحد.

الإعدادات: عنوان URL الأساسي والمتصفح والمهل في config/test.json وconfig/staging.json، ويختار بينهما TEST_ENV؛ ويخرج البريد الإلكتروني وكلمة المرور المكتوبان في الشيفرة منها، ويأتي الحساب من عميل API أو من مخزن الأسرار في CI، والقيمة الناقصة توقف التشغيل. فيصبح التشغيل على staging تغيير متغير واحد بدلاً من تعديل ⁦85⁩ عنوان URL. ويُحذف الانتظار الثابت لثلاث ثوانٍ: فالتدفقات تنتظر شروطاً، كما في درس الانتظار والتزامن.

السجلات: ترويسة تشغيل مع إخفاء الأسرار؛ ولكل اختبار الاسم والأوقات والحالة والخطوة الجارية ومعرّفات العناصر التي أنشأها؛ وعند الإخفاق عنوان URL ولقطة شاشة وأثر (Trace). فتصبح رسالة انتهاء المهلة المجردة step: pay by test card; Pay button not visible on /checkout/payment after 30 s، ويُعرف السبب دون إعادة التشغيل.

الأسلوب: السكربتات المهيكلة للحزمة الحالية. وللمحلّلين، الخطوة الأولى الأرخص ملف CSV معتمد على البيانات فيه عدد الليالي والضيوف والموسم والسعر المتوقع، يغذي اختباراً مهيكلاً واحداً، إذ تكلّف كل حالة سعر جديدة صفاً واحداً؛ ولا تستحق الكلمات المفتاحية الإضافة إلا إذا احتاجا إلى تركيب تدفقات جديدة بأنفسهما وكان هناك مهندس سيصونها.

أسئلة شائعة

هل Playwright أو Selenium إطار أتمتة اختبار؟

بمصطلحات CTAL-TAE هي أدوات ومكتبات يُبنى عليها الإطار. أما إطارك فهو الشيفرة التي يكتبها فريقك حولها: سكربتات الاختبار ومنطق العمل والمكتبات الأساسية، مع المشغّل وإعداداته. وتوفّر مشغّلات مثل Playwright Test جزءاً من الطبقة الأساسية، منها التجهيزات (Fixtures) وملفات الإعداد ومولّدات التقارير (Reporters)، وهذا سبب وجيه لعدم إعادة بناء هذه الأجزاء.

هل يحتاج مشروع صغير إلى الطبقات الثلاث كلها؟

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

هل الاختبار المعتمد على الكلمات المفتاحية هو نفسه BDD؟

لا، وإن كان كلاهما يسمح لمن لا يبرمجون بقراءة الاختبارات. فاختبارات الكلمات المفتاحية جداول أفعال مع بيانات، أما سيناريوهات BDD فجمل Given/When/Then يتفق عليها ممثلو العمل والمطورون والمختبِرون، وBDD ممارسة تطوير تعاونية بقدر ما هو صيغة اختبار. ويتناوله درس «التطوير الموجَّه بالسلوك وGherkin».

ما الفرق بين السجل وتقرير الاختبار؟

السجل هو التدوين المفصّل المرتب زمنياً لما فعله الإطار والنظام قيد الاختبار أثناء التشغيل، ويُكتب لتشخيص الإخفاقات. أما التقرير فيلخّص النتائج لمن يتخذ قراراً: ما الذي نجح، وما الذي فشل، والاتجاه العام. والتقرير الجيد يربط كل اختبار فاشل بسجله وأدلته؛ ويتناول درس «تقارير الأتمتة وتصحيح الأخطاء» التقاريرَ.

المراجع

Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024منهج ISTQB المتقدم لتصميم حلول أتمتة الاختبار وتنفيذها وصيانتها وبنيتها.
ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
Playwright DocumentationMicrosoft (Playwright)التوثيق الرسمي لـ Playwright، إطار الاختبار الشامل الذي يشغّل Chromium وWebKit وFirefox.

معمارية أتمتة الاختبار

لماذا يهم

ثلاث طبقات وقاعدة واحدة

المكوّنات القابلة لإعادة الاستخدام، ومتى لا تشاركها

الإعدادات والسجلات

أساليب كتابة السكربتات وكلفة صيانتها

مثال تطبيقي: حزمة اختبارات لإتمام الشراء بالكلمات المفتاحية

أخطاء شائعة

من منظور ضمان الجودة

تمرين عملي

صمّم المعمارية لحزمة سكربتات خطية

أسئلة شائعة

المراجع

تدرّب بأدوات متقن

مدقّق JSON

مدقّق JSON Schema

أداة اختبار Regex

مولّد مجموعات بيانات CSV

للتعمّق أكثر

تقدّمك في هذا الموضوع

قبل هذا الموضوع

الموضوعات التالية

موضوعات أخرى في هذه الوحدة

لماذا يهم

ثلاث طبقات وقاعدة واحدة

المكوّنات القابلة لإعادة الاستخدام، ومتى لا تشاركها

الإعدادات والسجلات

أساليب كتابة السكربتات وكلفة صيانتها

مثال تطبيقي: حزمة اختبارات لإتمام الشراء بالكلمات المفتاحية

أخطاء شائعة

من منظور ضمان الجودة

تمرين عملي

صمّم المعمارية لحزمة سكربتات خطية

أسئلة شائعة

المراجع

تدرّب بأدوات متقن

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة

قبل هذا الموضوع

الموضوعات التالية

موضوعات أخرى في هذه الوحدة