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

لماذا يهم

البيانات تحدد ما يستطيع الاختبار اكتشافه. فالاختبارات التي تعمل بسجلات مرتبة فقط — «Test User» وطلب واحد وعنوان قصير — تثبت المسار السعيد (Happy Path) ولا تكاد تثبت غيره؛ أما العيوب فتنتظر في الحقل الفارغ، والاسم الذي فيه فاصلة عليا (Apostrophe)، والطلب الذي سُلِّم قبل ⁦14⁩ يوماً بالضبط. والبيانات تحدد كذلك هل يمكن الوثوق بالنتيجة: فالاختبار الذي يفشل لأن زميلاً عدّل حساباً مشتركاً، أو ينجح بسبب سجل متبقٍّ، يضيّع الوقت ويخفي مشكلات حقيقية.

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

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

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

• الصالحة (Valid): بيانات يجب أن يقبلها النظام ويعالجها — عميل مسجَّل، ومنتج متوفر، وبريد إلكتروني مثل sara.k@example.com.
• غير الصالحة (Invalid): بيانات يجب أن يرفضها النظام بأمان — حقل إلزامي فارغ، وصيغة خاطئة، وبطاقة منتهية الصلاحية، أو سجل في حالة خاطئة مثل طلب أُلغي من قبل.
• الحدّية (Boundary): قيم على أطراف المسموح به — أطول اسم، والصفر، وآخر يوم في الفترة. ويختارها بدقة تحليلُ القيم الحدّية (Boundary Value Analysis) الذي تشرحه وحدة تصميم الاختبار.
• الشبيهة بالإنتاج (Production-like): بيانات تشبه الاستخدام الحقيقي في شكلها وحجمها — أسماء مكتوبة بالعربية وبالخط الديفاناغاري، وعناوين طويلة، وعميل لديه مئات الطلبات — من دون أن تعود إلى شخص حقيقي.

جرّبها: مولّد مجموعات الأحرف الخاصة جرّبها: مولّد مجموعات بيانات Unicode

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

المصدران الأولان أدناه اصطناعيان (Synthetic): بيانات مُنشأة خصيصاً للاختبار لا تصف أي شخص حقيقي. والبيانات الاصطناعية هي الخيار الافتراضي لأنك تتحكم في كل قيمة، بما فيها الحدود والقيم غير الصالحة والحالات النادرة.

• مصنوعة يدوياً: يكتب المختبِر السجلات القليلة الدقيقة التي يحتاجها الاختبار في جدول بيانات أو ملف تجهيز (Fixture) أو سكربت تعبئة بيانات (Seed Script). دقيقة، لكنها بطيئة حين يلزم حجم كبير.
• مولَّدة: تُنشئ أداة أو سكربت السجلات من قواعد، أو يُنشئها الاختبار عبر الواجهة البرمجية (API) للمنتج فتلتزم بقواعد العمل. قابلة للتكرار، من عشرة صفوف إلى مليون.
• بيانات إنتاج مقنّعة (Masked): نسخة من الإنتاج استُبدلت فيها الأسماء والمعرّفات وأرقام الهواتف وعناوين البريد الإلكتروني والعناوين أو خُلطت أو حُذفت، مع إبقاء الروابط بين الجداول. واقعية — ومفيدة في تجربة مسبقة لترحيل البيانات (Migration) مثلاً — لكنها تحتاج إلى عملية معتمدة.
• بيانات الإنتاج كما هي: سجلات حقيقية، لا مكان لها في بيئات الاختبار من دون أساس نظامي وموافقة وحماية بمستوى الإنتاج.

جرّبها: مصنع بيانات الاختبار جرّبها: مولّد مستخدمين وهميين جرّبها: مولّد عملاء وهميين

البيانات الشخصية: أبقِ الأشخاص الحقيقيين خارج أنظمة الاختبار

يعرّف نظام حماية البيانات الشخصية (PDPL)، الذي تشرف عليه الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا SDAIA)، البيانات الشخصية تعريفاً واسعاً: كل بيانات يمكن أن تؤدي إلى معرفة الفرد بصورة مباشرة أو غير مباشرة، مثل الاسم ورقم الهوية والعنوان ورقم الهاتف. والبيانات الصحية من الفئات المصنّفة بيانات حساسة.

التقنيع (Masking) لا يجعل البيانات مجهولة الهوية تلقائياً. فإن استبدلت الأسماء وأبقيت تاريخ الميلاد والحي وجهة العمل، فقد يظل السجل يشير إلى شخص واحد. وتقرير ما إذا كانت مجموعة مقنّعة ما زالت بيانات شخصية يعود إلى مسؤول حماية البيانات أو فريق الخصوصية؛ وإلى أن يقرروا، عاملها على أنها بيانات شخصية.

• استخدم النطاقات التي تحجزها RFC 2606، مثل example.com، لبريد الاختبار، حتى لا تصل أي رسالة إلى صندوق بريد حقيقي.
• ادفع فقط ببطاقات الاختبار التي ينشرها مزوّد الدفع في بيئته التجريبية (Sandbox).
• أبقِ البيانات الشخصية الحقيقية خارج تقارير الأخطاء ولقطات الشاشة والسجلات (Logs) وأدوات الذكاء الاصطناعي؛ وإن وجدت شيئاً منها في نظام اختبار فأبلغ عنه ولا تنسخه.

جرّبها: مولّد عناوين بريد إلكتروني وهمية جرّبها: بيانات اختبار العناوين السعودية

إدارة بيانات الاختبار

إدارة بيانات الاختبار (Test Data Management – TDM) هي الطريقة التي يخطط بها الفريق لبيانات الاختبار ويوفّرها ويحميها ويحافظ عليها كي تبقى الاختبارات قابلة للتكرار. قد يكون لها في المؤسسة الكبيرة دور مخصص، وهي في الفريق الصغير بضع عادات:

• التخطيط: اكتب بيانات كل حالة اختبار في صورة حالة محددة. فعبارة «عميل صالح» ليست بيانات اختبار، أما «العميل C-101 الذي لديه طلب واحد مدفوع بالبطاقة سُلِّم قبل ثلاثة أيام» فهي كذلك.
• التوفير: أنشئ البيانات بسكربتات أو مولّدات محفوظة في نظام إدارة الإصدارات (Version Control) بجوار الاختبارات، لا يدوياً يوم التنفيذ.
• العزل: امنح كل مختبِر أو تشغيل متوازٍ سجلاته الخاصة بمعرّفات فريدة، حتى لا تغيّر الاختبارات بيانات بعضها.
• إبقاؤها حديثة: اكتب التواريخ نسبةً إلى يوم التشغيل («سُلِّم اليوم ناقص ⁦14⁩ يوماً»)؛ فالتاريخ الثابت يتوقف عن اختبار القاعدة بعد أسابيع.
• إعادة الضبط والإزالة: استعِد خط أساس (Baseline) معروفاً بين التشغيلات، واحذف الملفات المصدَّرة والنسخ التي لم تعد تحتاجها.

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

مثال تطبيقي: بيانات الاختبار لقاعدة الاسترداد

المتطلب: «يستطيع العملاء طلب استرداد المبلغ خلال ⁦14⁩ يوماً من التسليم. ويُعاد مبلغ الدفع بالبطاقة إلى البطاقة، ومبلغ طلبات الدفع عند الاستلام إلى محفظة العميل».

قبل كتابة الخطوات، يُعدّ المختبِر قائمة البيانات: صفوفاً صالحة لمسارَي الاسترداد، وصفوفاً حدّية على جانبي اليوم ⁦14⁩ بتواريخ نسبية، وصفوفاً غير صالحة لحالة خاطئة ومالك خاطئ، وصفاً واحداً شبيهاً بالإنتاج. ويسأل مالك المنتج أولاً: هل تشمل عبارة «خلال ⁦14⁩ يوماً» اليوم الرابع عشر؟ والجدول يفترض أنها تشمله.

ID     Kind             Record (all synthetic)                      Expected
TD-01  valid            card order, delivered today-3, 240.00 SAR   refund to card
TD-02  valid            cash-on-delivery order, delivered today-5   refund to wallet
TD-03  boundary         card order, delivered today-14              refund accepted
TD-04  boundary         card order, delivered today-15              refund refused
TD-05  invalid state    order shipped, not yet delivered            no refund option
TD-06  invalid state    order already refunded                      refund refused
TD-07  invalid owner    order of C-102, opened by its id            access denied
TD-08  production-like  customer with 350 orders, Arabic full name  history pages load

Log in as C-101 for TD-01 to TD-07; TD-08 logs in as C-103.
All emails end in @example.com. Dates are relative to the run date.
Restore baseline "refunds-v3" before each run.

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

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Personal Data Protection Law (English translation)الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا) · 2023النظام السعودي لحماية البيانات الشخصية — ولماذا ينبغي أن تستخدم بيئات الاختبار بيانات اصطناعية بدلاً من نسخ سجلات العملاء الحقيقية.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
• RFC 2606: Reserved Top Level DNS NamesIETF · 1999يحجز example.com وexample.net وexample.org و.test/.example للتوثيق والاختبار — النطاقات التي تُستخدم في البيانات الوهمية.