اختبار قواعد البيانات لمهندسي الجودة

ماذا يغطي اختبار قواعد البيانات

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

اختبار قواعد البيانات ليس مستوى اختبار مستقلاً، بل مجموعة فحوص تُطبَّق في مستويات التكامل والنظام والقبول حيثما تُنشأ البيانات أو تتغير. ومرجعه (Test oracle) هو نموذج البيانات نفسه: المخطط (Schema) وقيوده، وقواعد العمل التي تربط جدولاً بآخر، والأرقام التي يجب أن تتطابق.

• الاختبار البنيوي (Schema testing) — الجداول والأعمدة والأنواع والأطوال والقيم الافتراضية والقيود والفهارس مطابقة للتصميم ولسكربتات الترحيل.
• اختبار البيانات الوظيفي — كل إنشاء وقراءة وتحديث وحذف تنفّذه الواجهة أو API يترك بالضبط الصفوف التي ينبغي أن يتركها.
• اختبار السلامة (Integrity) — قواعد المفاتيح والتفرّد وNOT NULL وCHECK والمفتاح الأجنبي ترفض البيانات الخاطئة، وتبقى السجلات المرتبطة متسقة.
• اختبار المنطق — الإجراءات المخزّنة والقوادح (Triggers) والعروض والمهام المجدولة تعطي النتائج الصحيحة للمدخلات العادية والحدّية والخاطئة.
• اختبار المعاملات والتزامن — سلوك «الكل أو لا شيء»، ونتائج صحيحة حين يغيّر مستخدمان البيانات نفسها في اللحظة ذاتها (تتناوله صفحة المعاملات والترحيلات بعمق).
• اختبار الترحيل (Migration) — تغييرات المخطط والبيانات تُنفَّذ بشكل صحيح على أحجام واقعية وتُبقي التطبيق العامل يعمل.
• الاختبار غير الوظيفي — أداء الاستعلامات على الجداول الكبيرة، وضبط الصلاحيات، وحماية البيانات الشخصية.

التحقق من CRUD: نفّذ عبر المنتج وتأكّد في قاعدة البيانات

التقنية الأساسية بسيطة: نفّذ الإجراء كما يفعل المستخدم أو العميل — عبر الواجهة أو API — ثم استعلم قاعدة البيانات لتتأكد من الأثر. إدخال الصفوف مباشرة ثم تسمية ذلك اختباراً للميزة يتجاوز شيفرة التطبيق التي يُفترض أنك تختبرها. الإدخال المباشر لتجهيز الشروط المسبقة، لا لتشغيل السلوك.

افحص في كل عملية الصف المستهدف وما يجاوره. الإنشاء ينبغي أن يكتب صفاً واحداً بكل حقل مربوط بشكل صحيح، مع القيم التي يولّدها الخادم (المعرّفات والطوابع الزمنية والحالة) وإنشاء الصفوف الفرعية. التحديث ينبغي أن يغيّر الأعمدة المقصودة فقط ويحدّث updated_at. الحذف ينبغي أن يزيل أو يحذف منطقياً (Soft delete) ما ينص عليه المتطلب بالضبط ويعامل الصفوف الفرعية كما صُمّم. والقراءة ينبغي أن تعيد المخزَّن كما هو — بما في ذلك النص العربي والرموز التعبيرية والأطوال القصوى والكسور العشرية — دون اقتطاع أو إعادة تقريب.

على سبيل المثال، بعد إنشاء طلب عبر API يضم وحدتين من صنف سعره 75.00 ريالاً ووحدة من صنف سعره 40.00 ريالاً، يتحقق الاستعلام في نهاية هذا القسم من صف الطلب وصفوف أصنافه والقيم التي يضبطها الخادم. ومن عيوب CRUD النموذجية التي يكشفها هذا النوع من الفحص:

• ربط الحقول — تقبل API الحقل delivery_notes لكن العمود يبقى NULL.
• الدقة — مبلغ 19.995 يُخزَّن 19.99 في جدول و20.00 في آخر.
• الترميز — أسماء عربية تُحفظ «????» لأن عموداً أو الاتصال يستخدم مجموعة محارف غير Unicode.
• المناطق الزمنية — تخزّن خدمة created_at بالتوقيت المحلي وتخزّنه أخرى بتوقيت UTC.
• الكتابة الجزئية — صف الطلب موجود وأصنافه غير موجودة بعد خطأ تحقق في الصنف الثالث.

-- After POST /api/orders returned order_id 1042 for customer 317
SELECT order_id, customer_id, status, total_amount, created_at, updated_at
FROM orders
WHERE order_id = 1042;

SELECT product_sku, quantity, unit_price
FROM order_items
WHERE order_id = 1042
ORDER BY order_item_id;

-- Expected: customer_id = 317, status = 'PENDING',
-- total_amount = 2 x 75.00 + 1 x 40.00 = 190.00,
-- exactly two item rows, created_at set by the server (UTC)

جرّبها: منسّق SQL جرّبها: مدقّق استعلامات SQL

القيود: القواعد التي تفرضها قاعدة البيانات

القيود (Constraints) خط الدفاع الأخير لقاعدة البيانات: حتى لو كان في تحقق التطبيق خلل، يرفض المخطط الجيد البيانات التي تكسر النموذج. لاختبارها وجهان. أولاً، تأكد أن القيد موجود — اقرأ المخطط أو ملف الترحيل، لا وثيقة التصميم وحدها. ثانياً، تأكد أن التطبيق يتعامل مع الرفض بلباقة: رسالة تحقق واضحة أو استجابة API من فئة 4xx، لا 500 تحمل خطأ قاعدة البيانات الخام.

المحركات تختلف، فافحص المحرك الذي تشحن عليه. لا يفرض MySQL قيود CHECK إلا بدءاً من الإصدار 8.0.16 (كانت الإصدارات الأقدم تحللها وتتجاهلها)، ولا يفرض SQLite المفاتيح الأجنبية إلا إذا فعّلها الاتصال بـ PRAGMA foreign_keys = ON. القيد الموجود في ملف الترحيل وغير المفروض وقت التشغيل ملاحظة تستحق التسجيل.

• المفتاح الأساسي (Primary key) — كل صف معرَّف بشكل فريد. يجب ألا ينشئ الطلب المُعاد صفاً ثانياً بمعرّف جديد لحدث العمل نفسه؛ فتلك مشكلة عدم تكرار الأثر (Idempotency) لا يحلها المفتاح وحده.
• UNIQUE — سجّل البريد نفسه مرتين، بما في ذلك باختلاف حالة الأحرف وبمسافات في البداية أو النهاية. اتفق مع الفريق هل Layla.H@example.com وlayla.h@example.com عميل واحد، ثم تأكد أن قاعدة البيانات توافق.
• NOT NULL — أرسل الحقل غائباً وفارغاً ومسافات فقط. النص الفارغ ليس NULL في PostgreSQL ولا MySQL، لذا لا يمنع NOT NULL وحده الأسماء الفارغة.
• CHECK — الكمية أكبر من صفر، والمبالغ غير سالبة، والحالة ضمن مجموعة مسموح بها. اختبر الحدود (0 و1 والحد الأقصى) وخطوة واحدة خارجها.
• المفتاح الأجنبي (Foreign key) — أنشئ طلباً لمعرّف عميل غير موجود. يجب أن يفشل الإدخال وأن تعيد API خطأً ذا معنى.
• القيم الافتراضية والأنواع والأطوال — الحقول المحذوفة تأخذ القيمة الافتراضية الموثقة، وكل عمود يتسع لأطول مدخل صالح. عمود بطول 50 حرفاً خلف حقل تسمح الواجهة فيه بـ 100 حرف خلل اقتطاع ينتظر الظهور.

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

العلاقات والسلامة المرجعية والحذف المتتالي

السلامة المرجعية (Referential integrity) تعني أن كل مرجع يشير إلى شيء موجود: كل صنف طلب ينتمي إلى طلب موجود، وكل دفعة إلى طلب موجود، وكل طلب إلى عميل موجود. عند التصريح بالمفاتيح الأجنبية تفرض قاعدة البيانات ذلك. وحين لا يُصرَّح بها — وهو شائع بين الخدمات المصغّرة، وفي المخططات المجزأة أو القديمة، وفي الجداول التي تحمّلها مهام دفعية — يجب أن يفرضه التطبيق، وتصبح الصفوف اليتيمة (Orphan rows) من أكثر عيوب البيانات التي يجدها المختبِر.

قواعد التتالي (Cascade) تحدد ما يحدث للصفوف الفرعية حين يُحذف الأب أو يتغير مفتاحه. ON DELETE CASCADE يحذف الأبناء مع الأب؛ وRESTRICT أو NO ACTION يرفض الحذف ما دام للأب أبناء؛ وSET NULL يُبقي الابن ويفرغ المرجع. كل منها صحيح لعلاقة وخطِر لأخرى: تتالي حذف العميل إلى الفواتير قد يدمّر سجلات يلزم العمل الاحتفاظ بها. اختبر كل علاقة مقابل المتطلب، لا مقابل ما يفعله المخطط مصادفة.

• احذف أباً عبر المنتج، ثم استعلم كل جدول فرعي عن صفوف ما زالت تشير إليه.
• افحص الحذف المنطقي: العميل الموسوم بالحذف ينبغي أن يختفي من القوائم، بينما قد يلزم أن تبقى طلباته السابقة قابلة للقراءة.
• شغّل استعلامات كشف الأيتام بعد الاستيراد الدفعي وترحيل البيانات والمهام الفاشلة — تعرض صفحة SQL نمط LEFT JOIN … IS NULL.

الإجراءات المخزّنة والقوادح وقواعد الخلفية

حين يعيش منطق العمل في قاعدة البيانات — إجراء مخزّن (Stored procedure) يغلق شهراً، أو قادح يكتب صف تدقيق، أو عرض يغذّي تقريراً — عامله كأي شيفرة أخرى: حدّد المدخلات والمخرجات المتوقعة، واختر الحالات بتقسيم التكافؤ وتحليل القيم الحدّية. استدعِ الإجراءات مباشرة في قاعدة اختبار ببيانات مجهّزة، وشغّلها كذلك عبر مسار التطبيق الذي يستخدمها.

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

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

اتساق البيانات بين الخدمات والذاكرة المؤقتة وفهارس البحث

تحتفظ الأنظمة الحديثة بنسخ من البيانات: نسخة قراءة متماثلة، وذاكرة مؤقتة (Cache)، وفهرس بحث، ومستودع تقارير، وقاعدة بيانات خدمة مصغّرة أخرى. كل نسخة قد تنحرف عن مصدر الحقيقة. سعر حُدّث في قاعدة البيانات وما زال مخزّناً مؤقتاً، أو طلب ظاهر في خدمة الطلبات ومفقود من الفوترة، أو عميل محذوف ما زال يظهر في البحث — هذه عيوب اتساق، وتجدها بمقارنة النسخ.

المطابقة (Reconciliation) هي التقنية: عُدّ واجمع المجموعة نفسها في مكانين وقارن. الأعداد حسب الحالة واليوم، ومجاميع المبالغ، وقوائم المعرّفات الموجودة في جهة دون الأخرى تكشف معظم الانحراف. وحيث يكون النسخ غير متزامن، اتفق مع الفريق على التأخير المقبول — فالاتساق النهائي (Eventual consistency) قرار تصميم لا عيب — واختبر أن النسخ تتقارب خلاله، بما في ذلك بعد الأعطال وإعادة المحاولة وإعادة التشغيل.

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

جرّبها: مولّد عبارات SQL IN جرّبها: مولّد قوائم SQL VALUES

بيانات الاختبار: اصطناعية ومزروعة وقابلة لإعادة الضبط

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

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

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

جرّبها: مولّد مجموعات بيانات SQL جرّبها: مولّد جمل SQL INSERT جرّبها: محوّل CSV إلى SQL جرّبها: محوّل JSON إلى SQL

الأداء على مستوى المختبِر: الفهارس وخطط الاستعلام وN+1

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

يعرض EXPLAIN كيف تنوي قاعدة البيانات تنفيذ الاستعلام — هل تستخدم فهرساً أم تمسح الجدول كله، وبأي ترتيب تربط الجداول. يوفّر PostgreSQL وMySQL كلاً من EXPLAIN وEXPLAIN ANALYZE، ويوفّر SQLite الأمر EXPLAIN QUERY PLAN. ينفّذ EXPLAIN ANALYZE العبارة فعلاً، فلا تشغّله على UPDATE أو DELETE خارج معاملة ستتراجع عنها. ولا يلزمك قراءة كل سطر في الخطة: مسح كامل لجدول كبير في استعلام يُفترض أن يعيد بضعة صفوف يستحق تقرير خطأ.

• استعلامات N+1 — صفحة قائمة تحمّل 50 طلباً باستعلام واحد، ثم تنفّذ استعلاماً إضافياً لكل طلب لجلب عميله: 51 رحلة بدل واحدة أو اثنتين. تظهر في سجل الاستعلامات أو تتبّع APM دفعةً من عبارات شبه متطابقة.
• الترقيم العميق — الترقيم المعتمد على OFFSET يبطؤ في الصفحات المتأخرة من الجداول الكبيرة؛ اختبر الصفحة 1 والصفحة 5,000.
• الاستعلامات غير المحدودة — تصديرات وتقارير بلا حدود تحمّل جدولاً كاملاً في الذاكرة.
• فهارس مفقودة على المفاتيح الأجنبية وعلى الأعمدة المستخدمة في WHERE وJOIN وORDER BY للاستعلامات المتكررة.

الأمن: الحقن والصلاحيات والبيانات الشخصية

يحدث حقن SQL (SQL injection) حين تُلصق مدخلات المستخدم في نص SQL. ودفاع OWASP هو الاستعلامات المُعامَلة (Parameterised queries / Prepared statements) في كل مكان، مع تحقق بقائمة مسموح بها للأجزاء التي لا يمكن أن تكون معاملات، مثل اسم عمود الترتيب. كمختبِر، تحقق من التوقع بدل كتابة هجمات: أدخل في كل حقل قيماً تحوي علامات اقتباس وفواصل منقوطة وعلامات تعليق ومحارف SQL خاصة أخرى، وتوقّع أن تُخزَّن وتُعرض حرفياً دون خطأ قاعدة بيانات أو تتبّع مكدس أو تغيّر في السلوك. ظهور رسالة خطأ من قاعدة البيانات في أي استجابة ملاحظة بحد ذاته. أما اختبار الحقن المعمّق فمكانه تقييم أمني مصرّح به.

مبدأ أقل الصلاحيات (Least privilege) يحدّ من الضرر حين يقع خطأ. ينبغي أن يملك حساب التطبيق ما يحتاجه فقط — عادةً القراءة والكتابة على جداوله، بلا تغيير للمخطط وبلا صلاحيات إدارية — وأن تعمل الترحيلات بحساب منفصل. وينبغي أن يستخدم المختبِرون وأدوات التقارير حسابات للقراءة فقط.

• اعرف الحساب الذي يتصل به التطبيق وما يُسمح له به؛ تطبيق إنتاجي يعمل بحساب مالك قاعدة البيانات ملاحظة.
• ابحث عن البيانات الشخصية حيث لا ينبغي أن تكون: سجلات التطبيق، ورسائل الخطأ، وأحداث التحليلات، وتصديرات CSV، والنسخ الاحتياطية على الأقراص المشتركة، وبيئات الاختبار.
• تأكد أن كلمات المرور مخزّنة بخوارزمية مخصّصة لتجزئة كلمات المرور (مثل Argon2id أو bcrypt أو scrypt أو PBKDF2، وهي تملّح كل كلمة مرور) لا بتجزئة عامة سريعة، وأن الرموز والأسرار الأخرى مجزّأة أو مشفّرة كما صُمّم، ولا تُخزَّن نصاً صريحاً أبداً.
• أعمدة التدقيق — created_at وupdated_at وcreated_by وupdated_by — يضبطها الخادم ولا تُقبل من العميل؛ يتغير updated_at وupdated_by كلما تغيّر السجل، بينما لا يتغير created_at وcreated_by أبداً بعد الإدراج.

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

العيوب النموذجية والأتمتة وCI

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

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

• «إجمالي الطلب يختلف عن مجموع أسطر الأصناف عند تطبيق خصم على الصنف الأخير»
• «حذف العميل يترك صفوف دفعات يتيمة (لا مفتاح أجنبي على payments.order_id)»
• «إنشاء عميل مكرر عند النقر المزدوج على زر التسجيل»
• «أسماء المنتجات العربية مقتطعة في order_items.product_name»
• «البحث ما زال يعيد منتجات حُذفت قبل أكثر من 24 ساعة»
• «صفحة سجل الطلبات تنفّذ استعلاماً لكل طلب (N+1): 4 ثوانٍ مع 200 طلب»
• «API تعيد 500 مع خطأ قاعدة البيانات الخام عندما يكون البريد موجوداً مسبقاً»

الأسئلة الشائعة

المراجع

• Constraints — PostgreSQL DocumentationPostgreSQL Global Development Groupقيود التحقق وعدم القيمة الفارغة والتفرّد والمفتاح الأساسي والمفتاح الأجنبي والإقصاء — القواعد التي تفرضها قاعدة البيانات ويتحقق منها المختبِر.
• Transactions — PostgreSQL DocumentationPostgreSQL Global Development Groupما المعاملة: عدة خطوات تُطبَّق كلها أو لا شيء عبر BEGIN وCOMMIT وROLLBACK، ولا يراها الآخرون قبل التثبيت.
• Transaction Isolation Levels — MySQL 8.4 Reference ManualOracle (MySQL)مستويات العزل الأربعة في SQL كما ينفّذها InnoDB، ومستوى REPEATABLE READ هو الافتراضي فيه.
• OWASP Cheat Sheet Series: SQL Injection PreventionOWASP Foundationالاستعلامات ذات المعاملات، والإجراءات المخزنة المستخدمة بأمان، والتحقق بقائمة السماح، وأقل الصلاحيات — الدفاعات التي ينبغي أن يؤكدها اختبار قاعدة البيانات.
• SQL InjectionOWASP Foundationكيف يعمل حقن SQL ولماذا الاستعلامات المُعامَلة، لا بناء النصوص، هي الدفاع.
• Personal Data Protection Law (English translation)الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا) · 2023النظام السعودي لحماية البيانات الشخصية — ولماذا ينبغي أن تستخدم بيئات الاختبار بيانات اصطناعية بدلاً من نسخ سجلات العملاء الحقيقية.
• ISO/IEC 9075-1:2023 — Information technology — Database languages SQL — Part 1: Framework (SQL/Framework)ISO/IEC · 2023الجزء الإطاري من معيار SQL الدولي، الذي تنفّذه لهجات PostgreSQL وMySQL وSQLite وغيرها بدرجات متفاوتة.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.