أدلة الاختبار

أدلة الاختبار (Test Evidence) هي سجل ما اختبرته، وعلى أي بناء وأي بيئة، ومتى، وما الذي حدث فعلاً: لقطات الشاشة وتسجيلات الشاشة والسجلات وملاحظة قصيرة بالسياق. وهي تحوّل عبارة «فشل طلب الإجازة» إلى شيء يستطيع المطور التحقق منه: الخطأ على الشاشة عند الساعة ⁦10:15⁩، والطلب الذي أعاد رمز الحالة ⁦504⁩، ومعرّف الطلب (request id) الذي يدل على الأسطر المطابقة في سجل الخادم.

والأدلة هي ما ترفقه بالنتائج المسجلة في تشغيل الاختبار (Test Run)، وبالنتائج الفاشلة قبل غيرها.

لماذا يهم

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

وللأدلة خطرها أيضاً. فلقطة الشاشة قد تُظهر رقم هاتف عميل، وملف الشبكة المصدَّر قد يحتوي ملف تعريف ارتباط الجلسة (Session Cookie) الذي يتيح لكل من يملك الملف أن يتصرف بصفة ذلك المستخدم. وجمع ما يلزم فقط يحمي الأشخاص الذين يحتفظ النظام ببياناتهم.

ما الذي يُعدّ دليلاً، وكم تحتاج منه

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

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

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

لقطات الشاشة وتسجيلات الشاشة

لقطة الشاشة أسرع دليل على ما رآه المستخدم. التقط النافذة كاملة مع ظهور عنوان الصفحة (URL) والحساب المسجَّل دخوله، لا قصاصة ضيقة حول الخطأ؛ وإذا كان الإخفاق تغيّراً، فالتقط لقطة قبله وأخرى بعده. وحدّد المشكلة على نسخة من الصورة، واحتفظ بالأصل.

أما التسجيل فيُظهر ما لا تستطيعه اللقطة: الترتيب والتوقيت. استخدمه للتدفقات متعددة الخطوات والوميض والاستجابات البطيئة والإخفاقات المتقطعة؛ واجعله قصيراً، ودوّن الثانية التي يظهر فيها الإخفاق.

  • انسخ رسائل الخطأ نصاً أيضاً ليمكن البحث فيها؛ واستخراج النص من لقطة الشاشة بالتعرف الضوئي على الحروف (OCR) حلّ احتياطي.

جرّبها: تحويل الصورة إلى نص

السجلات: وحدة التحكم والشبكة والخادم

السجلات تُظهر ما حدث تحت الشاشة. في تطبيقات الويب تغطي ثلاثة سجلات معظم الإخفاقات، وأول اثنين منها في أدوات المطور (DevTools) في المتصفح، وتفتحها بالمفتاح F12 أو Ctrl+Shift+I (أو Cmd+Option+I على Mac).

وتتناول وحدة اختبار تطبيقات الويب أدوات المطور، وتتناول وحدة HTTP الطلبات والترويسات ورموز الحالة، وكلتاهما بالتفصيل. ويكفيك الآن أن تعرف أن الصفحة كلما تواصلت مع الخادم أرسل المتصفح طلباً (Request) وتلقّى استجابة (Response) تحمل رمز حالة من ثلاثة أرقام (2xx نجاح، و4xx مشكلة في الطلب، و5xx إخفاق في جهة الخادم) وترويسات (Headers)، وهي أسطر معلومات إضافية لكل منها اسم، مثل ملف تعريف الارتباط (Cookie) الذي يُبقي المستخدم مسجَّل الدخول.

  • وحدة التحكم (Console): أخطاء JavaScript وحالات تعذّر تحميل الموارد والتحذيرات. انسخ الخطأ نصاً مع اسم الملف ورقم السطر ووقته؛ وفعّل إظهار الطوابع الزمنية (Timestamps) في إعدادات وحدة التحكم إن كانت مخفية.
  • لوحة الشبكة (Network): كل طلب مع طريقته وعنوانه ورمز حالته وتوقيته وترويساته وأجسامه. افتحها قبل الخطوة الأولى وفعّل «Preserve log» (وفي Firefox: «Persist Logs») حتى لا يمسحها الانتقال إلى صفحة أخرى. صدّر ملف HAR (أرشيف HTTP، بصيغة JSON) أو انسخ الطلب الفاشل وحده.
  • سجلات الخادم: غالباً خارج متناول المختبِر. أعطِ المطور الوقت الدقيق مع منطقته الزمنية، لأن كثيراً من الخوادم يسجّل بتوقيت UTC (فالساعة ⁦10:14⁩ في الرياض، بتوقيت ⁦UTC+3⁩، هي ⁦07:14⁩ بتوقيت UTC)، وأي معرّف طلب أعادته الاستجابة، مثلاً في ترويسة مثل X-Request-Id (تختلف الأسماء). وأرفق الأسطر التي يجدها، لا الملف كله.

جرّبها: عارض شجرة JSON جرّبها: محوّل المناطق الزمنية

الخصوصية والأمان عند جمع الأدلة

تنسخ الأدلة البيانات إلى أماكن يصل إليها عدد أكبر من الناس: أدوات تتبع العيوب والمحادثات والبريد الإلكتروني وتذاكر الموردين. وقد يحمل ملف HAR كل ترويسة وكل جسم في الجلسة، بما فيها ملفات تعريف الارتباط والرموز (Tokens) التي تتيح لكل من يملك الملف أن يتصرف بصفة ذلك المستخدم ما دامت صالحة. والبيانات الشخصية داخل الأدلة تبقى بيانات شخصية، تنطبق عليها أنظمة مثل نظام حماية البيانات الشخصية في المملكة العربية السعودية (PDPL)، وسياسات جهتك.

ووجود كلمة مرور أو رمز أو بيانات شخصية في سجلٍّ ملاحظةٌ بحد ذاته (فورقة OWASP الإرشادية للتسجيل، Logging Cheat Sheet، تنص على ألا تُسجَّل كلمات المرور ومعرّفات الجلسات ورموز الوصول والبيانات الشخصية الحساسة في السجلات مباشرة): أبلغ عنه دون أن تلصق القيمة.

  • استخدم حسابات الاختبار والبيانات المولَّدة، والتقط نافذة المتصفح لا سطح المكتب كله، وأسكت الإشعارات قبل التسجيل.
  • غطِّ البيانات بمستطيل مصمت معتم، لا بتمويه خفيف. وفي ملف PDF يبقى النص تحت المستطيل المرسوم فوقه؛ فاستخدم الحجب (Redaction) الحقيقي.
  • في ملف HAR (يظهر أدناه إدخال منه قبل التنظيف)، احذف قيم Cookie وSet-Cookie وAuthorization، ومصفوفات cookies التي تكررها، وكلمات المرور والبيانات الشخصية في الأجسام. ومتصفح Chrome بدءاً من الإصدار ⁦130⁩ يستبعد هذه الترويسات الثلاث افتراضياً (التصدير «sanitized»)، لكن الأجسام تبقى، وقد تحتفظ متصفحات أخرى بكل شيء، فافحص كل ملف. تسجيل الخروج يُنهي كثيراً من الجلسات، لكن بعض الرموز تبقى صالحة حتى تنتهي مدتها.
  • احفظ الأدلة في أدوات الفريق ذات الصلاحيات المضبوطة، لا في القنوات العامة، واحذفها عند انتهاء مدة الاحتفاظ المتفق عليها.
{
  "startedDateTime": "2026-09-30T07:14:52.118Z",
  "request": {
    "method": "POST",
    "url": "https://staging.example.test/api/leave-requests",
    "headers": [
      { "name": "Authorization", "value": "Bearer eyJhbGciOi..." },
      { "name": "Cookie", "value": "sid=4f9c..." }
    ],
    "cookies": [{ "name": "sid", "value": "4f9c..." }],
    "postData": {
      "mimeType": "application/json",
      "text": "{\"type\":\"annual\",\"days\":3}"
    }
  },
  "response": {
    "status": 504,
    "headers": [{ "name": "X-Request-Id", "value": "8b1f0c2e" }]
  }
}

جرّبها: تنقيح PDF (حجب المعلومات) جرّبها: مولّد مستخدمين وهميين

مثال تطبيقي: أدلة طلب إجازة فاشل

يشغّل مختبِر حالة الاختبار TC-LV-009 «تقديم طلب إجازة سنوية لمدة ⁦3⁩ أيام» ضمن تشغيل انحدار السبرنت ⁦42⁩ لبوابة الموارد البشرية على بيئة Staging، وأدوات المطور مفتوحة و«Preserve log» مفعّل. يملأ المختبِر النموذج ويلتقط لقطة شاشة، ثم يبدأ تسجيل نافذة المتصفح وينقر «Submit». يدور مؤشر التحميل ⁦30⁩ ثانية، ثم تظهر «Request failed. Try again.». يلتقط المختبِر لقطة شاشة ويفتح «My requests»، فيجد الطلب مدرجاً بحالة «Pending»؛ فالمستخدم الذي يصدّق الرسالة سيقدّم طلباً مكرراً.

يصدّر المختبِر ملف HAR ويحذف قيم الجلسة، وينسخ خطأ وحدة التحكم، ويدوّن معرّف الطلب. وبهذا المعرّف يجد المطور أسطر سجل الخادم: حُفظ الطلب، ثم انتظرت خدمة الإجازات ردّ خدمة الموافقات، وبعد ⁦30⁩ ثانية توقفت البوابة (Gateway) التي تسبقها عن الانتظار وأعادت الرمز ⁦504⁩ (Gateway Timeout). وهذه الحزمة المرفقة بنتيجة التشغيل وبالعيب DEF-1874:

حزمة أدلة لطلب إجازة فاشل: السياق، وثلاث لقطات شاشة، وخطأ وحدة التحكم، وملف HAR حُذفت منه قيم الجلسة، وأسطر سجل الخادم التي وُجدت بمعرّف الطلب، وتسجيل مدته ⁦41⁩ ثانية.

الحزمة المرفقة بنتيجة التشغيل وبالعيب DEF-1874

الجزء 1:DEF-1874-evidence/   TC-LV-009 · run "Sprint 42 regression" · HR portal
  00-context.txt    build 5.2.0-rc1 · staging · Chrome 129 / Windows 11
                    account qa.employee07 (employee role) · 30 Sep 10:14:52 UTC+3
  الجزء 2:01-form.png       the filled form before Submit: annual leave, 12-14 Oct, 3 days
  02-error.png      after 30 s: "Request failed. Try again." (boxed in red)
  03-list.png       My requests: the same request is listed as Pending
  الجزء 3:04-console.txt    10:15:22 Failed to load resource: the server responded
                    with a status of 504 (Gateway Timeout)
  الجزء 4:05-network.har    POST /api/leave-requests -> 504 after 30.0 s
                    X-Request-Id: 8b1f0c2e · Cookie, Authorization values removed
  الجزء 5:06-server.txt     log lines for 8b1f0c2e, provided by the developer
  الجزء 6:07-steps.mp4      41 s: Submit, spinner, error at 0:31, open My requests
  1. 1السياق: ماذا وأين ومتىحالة الاختبار والتشغيل والبناء والبيئة والمتصفح ودور الحساب والوقت مع منطقته الزمنية. ومن دونه ما كان أحد ليطابق الملفات الأخرى بسجل الخادم.30 Sep 10:14:52 UTC+3
  2. 2لقطات الشاشة: قبل الخطأ وعنده وبعدهالنافذة كاملة، والمشكلة محددة بمستطيل على نسخة. والثالثة تُظهر أن الطلب حُفظ رغم رسالة الخطأ.غطِّ البيانات الشخصية
  3. 3وحدة التحكم في المتصفحالخطأ منسوخاً نصاً مع وقته، ليمكن البحث فيه ومطابقته بطلب الشبكة.504 (Gateway Timeout)
  4. 4الشبكة: ملف HARيثبت الطلب ورمز الحالة وانتظار الثواني الثلاثين؛ ومعرّف الطلب يربطه بسجل الخادم.POST /api/leave-requests -> 504احذف ملفات تعريف الارتباط والرموز
  5. 5مقتطف من سجل الخادموجده المطور بمعرّف الطلب: حُفظ الطلب، ثم تجاوز انتظار ردّ خدمة الموافقات مهلة البوابة البالغة ⁦30⁩ ثانية. ولا تُرفق إلا الأسطر ذات الصلة.X-Request-Id: 8b1f0c2e
  6. 6تسجيل الشاشةيُظهر الترتيب والتوقيت: مؤشر التحميل طوال ⁦30⁩ ثانية كما عاشه المستخدم، وهذا ما لا تُظهره لقطة الشاشة.أسكت الإشعارات

أسماء الملفات وترقيمها عُرف فريق واحد؛ المهم أن يكون كل ملف مرتباً ومسمّى ومرفقاً بالنتيجة.

  • ما استُبعد من الحزمة: سطح المكتب، وقيم الجلسة، وطلب تسجيل الدخول السابق في ملف HAR، الذي كان جسمه يحمل كلمة مرور حساب الاختبار.
النسخة النصية
DEF-1874-evidence/   TC-LV-009 · run "Sprint 42 regression" · HR portal
  00-context.txt    build 5.2.0-rc1 · staging · Chrome 129 / Windows 11
                    account qa.employee07 (employee role) · 30 Sep 10:14:52 UTC+3
  01-form.png       the filled form before Submit: annual leave, 12-14 Oct, 3 days
  02-error.png      after 30 s: "Request failed. Try again." (boxed in red)
  03-list.png       My requests: the same request is listed as Pending
  04-console.txt    10:15:22 Failed to load resource: the server responded
                    with a status of 504 (Gateway Timeout)
  05-network.har    POST /api/leave-requests -> 504 after 30.0 s
                    X-Request-Id: 8b1f0c2e · Cookie, Authorization values removed
  06-server.txt     log lines for 8b1f0c2e, provided by the developer
  07-steps.mp4      41 s: Submit, spinner, error at 0:31, open My requests

أخطاء شائعة

  • قصّ لقطة الشاشة حتى لا يبقى إلا رسالة الخطأ، فلا يعرف أحد من أي صفحة أو حساب أو بيانات جاءت.
  • إرفاق أدلة بلا سياق: بلا بناء أو بيئة أو منطقة زمنية أو بيانات اختبار.
  • فتح أدوات المطور بعد الإخفاق فقط، أو دون «Preserve log»، فلا يُسجَّل الطلب الفاشل أصلاً.
  • مشاركة ملف HAR أو لقطة شاشة أو تسجيل ما زال يحتوي رموزاً أو ملفات تعريف ارتباط أو بيانات شخصية، في قناة أو تذكرة يراها أشخاص من خارج الفريق.
  • جمع أدلة لكل خطوة ناجحة «احتياطاً»: يبطئ التنفيذ، ويزيد البيانات التي تجب حمايتها، ولا يقرؤها أحد.

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

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

وأثناء التنفيذ افتح أدوات المطور وفعّل «Preserve log» قبل الخطوات التي تحفظ بيانات. وقبل إرفاق أي شيء، انظر إليه كما ينظر شخص من خارج الفريق: هل يُظهر الإخفاق؟ وهل يُظهر ما لا ينبغي أن يُظهره؟

تمرين عملي

جهّز حزمة أدلة آمنة لتسريب بيانات

المطلوب

تشغّل حالة الاختبار TC-PAY-012 على بوابة الموارد البشرية في بيئة Staging، فيُظهر كشف الراتب الذي نزّلته اسم موظف آخر ورقمه الوظيفي وراتبه بدلاً من بيانات حساب الاختبار الخاص بك. تبدو الأسماء حقيقية، فيبدو أن بيئة Staging تحتوي بيانات منسوخة من الإنتاج.

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

المادة
TC-PAY-012  تنزيل كشف راتب سبتمبر بصيغة PDF
التشغيل:    Sprint 42 regression · staging · build 5.2.0-rc1 · Chrome 129
الحساب:     qa.employee07 (دور موظف)
الوقت:      30 Sep 11:02 UTC+3
المتوقع:    يعرض ملف PDF اسم qa.employee07 ورقمه الوظيفي وراتبه
الفعلي:     يعرض ملف PDF اسم موظف آخر ورقمه الوظيفي وراتبه
الطلب:      GET /api/payslips/2026-09/pdf -> 200, Content-Type: application/pdf
الاستجابة:  X-Request-Id: 51d7a0c3
الخطوات
  1. قرّر ما الذي يثبت الإخفاق دون نسخ بيانات الشخص الآخر.
  2. اكتب ملفات حزمتك، وما يُظهره كل منها، وما ستغطيه أو تحذفه فيه.
  3. اذكر ما ستفعله بملف PDF الذي نزّلته، ومن ستُبلغ.
إظهار الإجابة النموذجية
الإجابة النموذجية

00-context.txt: حالة الاختبار والتشغيل والبناء والبيئة والمتصفح ودور الحساب، والوقت مع منطقته الزمنية، ومعرّف الطلب 51d7a0c3.

01-payslip.png: كشف الراتب بجانب ترويسة البوابة التي تُظهر حساب الاختبار المسجَّل دخوله، مع تغطية اسم الشخص الآخر ورقمه الوظيفي وراتبه بمستطيلات مصمتة. فعدم التطابق هو الإثبات، ويمكنك ذكره دون إظهار البيانات، ويستطيع المطور أن يتحقق بمعرّف الطلب من كشف الراتب الذي أُرسل فعلاً.

02-request.txt: GET /api/payslips/2026-09/pdf ورمز الحالة ⁦200⁩ ومعرّف الطلب، دون قيم ملفات تعريف الارتباط والتفويض ودون جسم الاستجابة، لأنه ملف PDF المسرَّب. وأسطر سجل الخادم فقط إذا خلت من البيانات الشخصية.

لا تسجيل ولا ملف PDF الأصلي: لا ترفق الملف في أي مكان. اسأل فريق الأمن أو مسؤول حماية البيانات هل يحتاجون إليه، واحتفظ به فقط وفق تعليماتهم، ثم احذف نسختك.

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

أسئلة شائعة

هل أحتاج إلى لقطة شاشة لكل خطوة اختبار ناجحة؟

غالباً لا. فلدى معظم الفرق تكون النتيجة المسجلة في تشغيل الاختبار هي دليل النجاح. أما المجالات الخاضعة للتنظيم والقبول التعاقدي وبعض اعتمادات اختبار قبول المستخدم فتتطلب إثبات النجاح، وعندها تحدد خطة الاختبار أي الاختبارات تحتاجه وبأي شكل. والاختبارات المؤتمتة تُنتج أدلتها بنفسها: التقرير والسجلات، ولقطات الشاشة أو التتبعات (Traces) التي تحفظها أدوات كثيرة عند فشل الاختبار.

ما ملف HAR، وهل مشاركته آمنة؟

ملف HAR (أرشيف HTTP) ملف JSON يُصدَّر من لوحة الشبكة (Network) في المتصفح. ويحتوي كل طلب واستجابة مسجّلين: العناوين والترويسات وملفات تعريف الارتباط والتوقيتات، وكثيراً ما يحتوي الأجسام أيضاً. ومشاركته كما صُدّر غير آمنة، لأنه قد يحمل ملفات تعريف ارتباط الجلسة ورموز الوصول وكلمة مرور من طلب تسجيل الدخول وبيانات شخصية؛ ومتصفح Chrome بدءاً من الإصدار ⁦130⁩ يستبعد ترويسات ملفات تعريف الارتباط والتفويض افتراضياً، لكنه لا يستبعد الأجسام. احذف القيم الحساسة أولاً، وشاركه عبر أداة تتبع الفريق فقط، وأرسل الطلب الفاشل وحده إن كان يكفي.

هل أسجّل فيديو أم ألتقط لقطة شاشة؟

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

المراجع

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
  • What are browser developer tools? — MDNMDN Web Docs (Mozilla)مقدمة لأدوات المطوّرين المدمجة في المتصفحات — المفتّش ووحدة تحكم JavaScript ومصحّح الأخطاء — لفحص الصفحة أثناء اختبارها.
  • OWASP Cheat Sheet Series: LoggingOWASP Foundationما يُسجَّل وما لا يُسجَّل أبداً (كلمات المرور والرموز والبيانات الشخصية)، وكيف تُبقى السجلات قابلة لكشف العبث.
  • Personal Data Protection Law (English translation)الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا) · 2023النظام السعودي لحماية البيانات الشخصية — ولماذا ينبغي أن تستخدم بيئات الاختبار بيانات اصطناعية بدلاً من نسخ سجلات العملاء الحقيقية.

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

استخرج النص من الصور ولقطات الشاشة (JPG وPNG وWebP) بالتعرف الضوئي في متصفحك — بالعربية والإنجليزية والهندية؛ عدة صور دفعة واحدة.

التعرف الضوئي على النصوص

استكشاف JSON كشجرة قابلة للطي مع المسارات والأنواع وعدد القيم.

JSON والبيانات

حوّل التاريخ والوقت بين المناطق الزمنية (الرياض، عمّان، دلهي، UTC، نيويورك، لندن…).

أدوات مساعدة

أزل النص والصور من ملف PDF نهائيًا — ارسم مربعات سوداء فيُعاد تصيير الصفحات المنقَّحة بدون المحتوى الذي تحتها.

حماية PDF والخصوصية

ولّد سجلات مستخدمين وهمية (الاسم واسم المستخدم والبريد الإلكتروني وكلمة المرور وبذرة الصورة الرمزية والدور) لحسابات الاختبار.

بيانات الاختبار

للتعمّق أكثر

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

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