تقارير الأتمتة وتصحيح الأخطاء

لماذا يهم

تُقاس فائدة حزمة الاختبارات الآلية بسرعة التصرف حين تظهر نتيجة حمراء. فإذا لم يترك الفشل سوى expected true, received false، اضطر أحدهم إلى إعادة تشغيل الاختبار وتخمين ظروف CI؛ ثم يعيد الفريق التشغيل حتى يخضرّ البناء، وتمرّ حالات الانحدار الحقيقية وسط الضجيج.

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

التقارير: تشغيل واحد وقرّاء متعددون

للتشغيل الواحد عدة قرّاء. فمن بدأه يقرأ الطرفية. ومن يحقق في فشل يحتاج إلى تقرير HTML يُفتح فيه كل اختبار على خطواته وخطئه ومحاولات إعادته ومرفقاته. وخادم CI يحتاج إلى ملف تقرؤه الآلة، وهو عادةً JUnit XML، ليعرض النتائج لكل اختبار ويحتفظ بتاريخها. وفي Playwright تُدرج الصيغ التي تحتاجها تحت reporter.

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

• سياق التشغيل: البناء أو الإيداع، والمتصفح، والعنوان الأساسي (base URL)، ووقت البدء، لربط الفشل بعمليات النشر وسجلات الخادم.
• الاختبارات المتذبذبة (Flaky، أي فشلت ثم نجحت عند إعادة المحاولة) تُعدّ منفصلة عن الناجحة؛ وإلا أخفاها التقرير.

// playwright.config.ts (excerpt): one run, three readers
import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['list'],                                        // the terminal
    ['html', { open: 'never' }],                     // people: playwright-report/
    ['junit', { outputFile: 'results/junit.xml' }],  // the CI server
  ],
});

// checkout.spec.ts: steps and attachments make the report read like a test case
import { test, expect } from '@playwright/test';

test('VAT is added to the order total', async ({ page }, testInfo) => {
  const cart = await test.step('Create a cart with one 150.00 SAR book', () =>
    createCart(page, { sku: 'BOOK-01', qty: 1 }));     // createCart: a project helper
  await testInfo.attach('cart', {
    body: JSON.stringify(cart), contentType: 'application/json',
  });
  await test.step('Open checkout and check the total', async () => {
    await page.goto('/checkout/' + cart.id);
    await expect(page.getByTestId('order-total')).toHaveText('172.50 SAR');
  });
});

جرّبها: منسّق XML

لقطات الشاشة والفيديو وملفات الأثر: ماذا يُظهر كلٌّ منها

احتفظ بالأدلة للاختبارات الفاشلة فقط: فكل نوع منها يجيب عن سؤال مختلف ويكلّف وقتاً في التشغيل ومساحة في التخزين.

• لقطة الشاشة (Screenshot): الصفحة لحظة الفشل، وتجيب عن سؤال «ماذا رأى المستخدم؟»: شريط خطأ، أو مؤشر تحميل، أو نافذة فوق الزر. في Playwright: screenshot: 'only-on-failure'؛ ويلتقط Cypress لقطة تلقائياً حين يفشل اختبار في cypress run؛ ومع Selenium استدعِ takeScreenshot() ‏(JavaScript) أو getScreenshotAs ‏(Java) في خطاف الفشل (hook) لدى المشغّل.
• الفيديو: الاختبار كاملاً، يُظهر الترتيب والحركة كنافذة ظهرت واختفت، لكن دون بيانات DOM أو الشبكة أو وحدة التحكم. وملفاته كبيرة: في Playwright استخدم video: 'retain-on-failure'؛ ولا يسجّل Cypress إلا إذا فُعّل خياره video (وهو معطّل افتراضياً).
• ملف الأثر (Trace): تسجيل تتنقّل فيه خطوة خطوة. يضم أثر Playwright كل إجراء مع لقطات DOM قبله وبعده، وسجل الاستدعاء (call log)، ووحدة التحكم، وطلبات الشبكة واستجاباتها، وسطر الشيفرة. افتحه بـnpx playwright show-trace، أو من تقرير HTML، أو في trace.playwright.dev الذي يحمّله في متصفحك دون رفعه إلى أي مكان.
• السجلات: مخرجات المشغّل، ووحدة تحكم المتصفح، وسجلات الخادم للنافذة الزمنية نفسها، تُربط بالطابع الزمني أو بمعرّف الطلب.
• الأدلة بيانات أيضاً: قد يحمل ملف الأثر ترويسات الطلبات وملفات تعريف الارتباط (cookies) وكل ما كتبه الاختبار، فاستخدم بيانات اصطناعية واجعل للمخرجات (artifacts) مدة صلاحية.

// playwright.config.ts (excerpt): keep evidence for failures only
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 1 : 0,
  use: {
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: 'on-first-retry',   // needs retries; with none, use 'retain-on-failure'
  },
});

// Then, in a terminal, open a trace downloaded from a CI run:
//   npx playwright show-trace trace.zip

تصحيح اختبار فاشل: من الخطأ الأول إلى السبب

يفصل ISTQB بين الاختبار، الذي يُظهر الإخفاقات، وتصحيح الأخطاء، الذي يجد أسبابها ويحللها ويزيلها. وفي الاختبار الآلي الفاشل يتولى المختبِر تحليل الإخفاق: هل العيب في المنتج أم في شيفرة الاختبار أم في البيئة؟ ويصحّح المختبِر شيفرة الاختبار، ويصحّح المطور المنتج انطلاقاً من الأدلة.

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

• أعد إنتاج الإخفاق محلياً: npx playwright test --debug يمشي بك في الاختبار خطوة خطوة داخل Playwright Inspector، و--ui يفتح وضع الواجهة (UI mode) مع عرض لكل تشغيل تتنقّل فيه عبر الزمن، وawait page.pause() يوقف الاختبار عند سطر تختاره في تشغيل بواجهة مرئية (headed). وغيّر شيئاً واحداً في كل مرة، كما في درس إعادة إنتاج الإخفاقات.
• لا ترفع المهلة قبل أن تعرف لماذا نفد الوقت: فالاستجابة الأبطأ قد تكون هي العيب نفسه.

جرّبها: مقارنة النصوص (Diff) جرّبها: محوّل الطوابع الزمنية

مثال تطبيقي: إجمالي طلب خاطئ في التشغيل الليلي

يُبلغ تشغيل الواجهة الليلي على بيئة staging، في البناء ⁦512⁩، عن فشل واحد؛ وقد فشلت إعادة المحاولة أيضاً، فهو فاشل لا متذبذب. وفيما يلي مقتطفات مختصرة من التقرير وملف الأثر.

الخطأ الأول فشلُ تأكيد: وُجد العنصر لكنه أظهر قيمة خاطئة. وتُظهر لقطة الشاشة ضريبة قدرها ⁦0.00⁩ في السلة، أي أن الاختبار قرأ ما عرضته الصفحة. وفي ملف الأثر تحتوي استجابة GET /api/cart/8812 أصلاً على "vatRate": 0: فقد عرض المتصفح ما أرسله الخادم. ولم يحتفظ آخر تشغيل ناجح، البناء ⁦509⁩، بملف أثر، لكن تقريره ما زال يضم بيانات cart بصيغة JSON التي يرفقها الاختبار في كل تشغيل، وفيها "vatRate": 0.15؛ ومقارنة الاستجابة بهذه البيانات بأداة مقارنة JSON تُظهر أن vatRate وtotal وحدهما تغيّرا.

إذن السبب تغيير في الواجهة الخلفية (back end) بين البناءين ⁦509⁩ و⁦512⁩ أو إعداد ضريبي تغيّر في بيئة staging؛ وسؤال واحد للمطور أو لمالك البيئة يحسم أيهما. الاختبار صحيح ويبقى كما هو. ويحمل التقرير «واجهة السلة البرمجية تعيد vatRate بقيمة 0 لسلة سعودية منذ البناء ⁦512⁩» الاستجابتين وملف الأثر ونطاق البناءات.

✘ checkout.spec.ts:42 › checkout › VAT is added to the order total
  failed (retry #1 failed too) · chromium · staging · build 512

  Error: expect(locator).toHaveText(expected)
  Locator:  getByTestId('order-total')
  Expected: "172.50 SAR"
  Received: "150.00 SAR"
    at checkout.spec.ts:51

  Attachments: cart · screenshot · video · trace

Build 512 › trace › Network › GET /api/cart/8812 → 200
  { "subtotal": 150.00, "vatRate": 0,    "total": 150.00 }

Build 509 (last green run, no trace kept) › HTML report › attachment "cart"
  { "subtotal": 150.00, "vatRate": 0.15, "total": 172.50 }

جرّبها: مقارنة JSON

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024منهج ISTQB المتقدم لتصميم حلول أتمتة الاختبار وتنفيذها وصيانتها وبنيتها.
• Trace viewer — PlaywrightMicrosoft (Playwright)تسجيل تشغيل الاختبار وإعادة عرضه خطوة بخطوة — لقطات DOM والشبكة ووحدة التحكم — لتشخيص الإخفاقات، خصوصاً القادمة من CI.
• Cypress DocumentationCypress.ioالتوثيق الرسمي لاختبار الويب الشامل واختبار المكونات في المتصفح باستخدام Cypress.