4.5الاختبارات التلقائية والجودة
الأساسي في 30 ثانية
- ثلاثة مستويات للتحقق: اختبارات الوحدة (هل يعطي إجراء أو صنف النتيجة الصحيحة؟ — الأكثر مردودية لأنه يستهدف قاعدة تجارية)، واختبارات الواجهة (إعادة تشغيل سيناريو مسجّل: فتح، إدخال، حفظ، تحقق) وتدقيق المشروع.
- الفائدة الرئيسية للاختبارات التلقائية ليست اكتشاف أخطاء اليوم بل كشف الانحدارات غدًا: إعادة اختبار التطبيق كله يدويًا مستحيلة، لذا لا نفعلها — والانحدارات تصل إلى الإنتاج.
- ممارسات جيدة: البدء بالقلب التجاري (الحسابات، القواعد الحرجة)، واختبار الحالات الحدية (صفر، قيم فارغة، تغيّر السنة)، وكتابة اختبار عند كل خطأ يُصحّح — والحفاظ على تحديث الاختبارات، لأن اختبارات مهملة قديمة أسوأ من عدم وجود اختبارات.
حالة مصغّرة متسلسلة — ياسين يؤمّن حسابات تجارته
ياسين، مطوّر WinDev في شركة صغيرة لتجارة المعدات الكهربائية في وهران، صحّح للتو خطأً في حساب الخصومات: لاحظه عميل بعد ثلاثة أشهر في فواتيره. قرر ألا يكتفي أبدًا بعد اليوم بـ«يبدو أنها تعمل». يكتب أولًا اختبارات وحدة على القلب التجاري: حساب الضريبة على الكتالوج الكهربائي، والخصومات، والاستحقاقات. يختبر منهجيًا الحالات الحدية — نسبة صفر، مبلغ سالب، تاريخ تغيّر السنة — لأن الأخطاء تختبئ هناك. ثم يسجّل بعض سيناريوهات الواجهة على المسار الحرج (إدخال طلب من البداية إلى النهاية) لكشف الانحدارات. ويفرض على نفسه قاعدة: عند كل خطأ يُصحّح، يكتب اختبارًا يعيد إنتاجه، كي لا يعود أبدًا. ويسجّل الفائدة الحقيقية الأكثر استهانًا بها: الثقة في تعديل الكود دون خوف. ويكمل بمراجعة الكود وملاحظات المستخدمين: الجودة تتجاوز الاختبارات.
حالة مستقلة لهذا القسم: تعود في الدرس والمخطط والسكريبت وتحدي 48 ساعة للقسم 4.5.
1. ثلاثة مستويات للتحقق
جودة التطبيق لا تُفرض بقرار: تُبنى وتُتحقق. يميّز WinDev عدة مقاربات. (1) اختبارات الوحدة: التحقق من أن إجراء أو صنفًا يعطي النتيجة الصحيحة لمدخلات معينة (هل يعيد حساب الضريبة القيمة الصحيحة؟ ومع نسبة صفر؟ ومع مبلغ سالب؟). هذا الاختبار الأكثر مردودية، لأنه يستهدف قاعدة تجارية بدقة. (2) اختبارات الواجهة (IHM): إعادة تشغيل سيناريو استخدام تلقائيًا (فتح نافذة، إدخال، حفظ، تحقق من النتيجة) — ويتيح WinDev تسجيل هذه السيناريوهات. (3) التدقيق وأدوات تحليل المشروع، التي تشير إلى الشذوذات ونقاط التحسين.
2. الاختبارات التلقائية تغيّر كل شيء
لماذا تغيّر الاختبارات التلقائية كل شيء؟ لأنها قابلة لإعادة التشغيل بلا حدود. فائدتها الرئيسية ليست اكتشاف أخطاء اليوم، بل كشف الانحدارات غدًا: عندما نعدّل قاعدة أو نصحّح عيبًا، كيف نعرف أننا لم نكسر شيئًا في مكان آخر؟ إعادة اختبار التطبيق كله يدويًا مستحيلة عمليًا — لذا لا نفعلها، والانحدارات تصل إلى الإنتاج. الاختبارات التلقائية تقوم بهذا العمل في دقائق. وهي أيضًا، وكثيرًا ما يُستهان بذلك، الثقة في تعديل الكود: بلا اختبارات نكدّس الترقيعات، ومع اختبارات نعيد الهيكلة باطمئنان.
3. ممارسات جيدة وجودة بالمعنى الواسع
بعض الممارسات الجيدة. (1) ابدأ بالقلب التجاري (الحسابات، القواعد الحرجة) بدلًا من استهداف تغطية كاملة. (2) اختبر الحالات الحدية (صفر، قيم فارغة، قيم قصوى، تواريخ تغيّر السنة): هناك تختبئ الأخطاء. (3) اكتب اختبارًا عند كل خطأ يُصحّح لضمان عدم عودته. (4) أبقِ الاختبارات محدّثة: اختبارات قديمة نتجاهلها أسوأ من عدم وجود اختبارات. وأخيرًا، الجودة تتجاوز الاختبارات: مراجعة الكود، والتوثيق، والاصطلاحات وملاحظات المستخدمين جزء منها أيضًا.
🔎 مثال ملموس — 🔎 مثال ملموس — اختبار وحدة وحالاته الحدية
استهداف قاعدة تجارية، كما يفعل ياسين:
// Test unitaire du calcul de TVA du catalogue electrique
PROCEDURE Test_TVA()
sTTC est un numerique = CalculeTTC(1000, 19)
SI sTTC <> 1190 ALORS
Erreur("TVA attendue 1190, obtenue : " + sTTC)
FIN
// Cas limites : taux a zero et montant negatif
SI CalculeTTC(0, 19) <> 0 ALORS
Erreur("Cas limite zero non gere")
FINالقراءة: اختبار الوحدة يتحقق من إجراء لمدخلات معينة، بما في ذلك الحالات الحدية التي تختبئ فيها الأخطاء.
الدرس: يصبح هذا الاختبار الحارس الذي يكشف انحدارًا إذا عُدّلت القاعدة لاحقًا.
مفردات القسم
- اختبار الوحدة
- التحقق من أن إجراء أو صنفًا يعطي النتيجة الصحيحة لمدخلات معينة — الاختبار الأكثر مردودية، لأنه يستهدف قاعدة تجارية.
مثال بسيط: ياسين يختبر حساب الضريبة في الكتالوج الكهربائي.
ما ليس كذلك: النقر يدويًا في الواجهة «لرؤية إن كانت تعمل».
رد فعل: التحقق من قاعدة → اختبار الوحدة.
- اختبار الواجهة (IHM)
- إعادة تشغيل سيناريو استخدام تلقائيًا (فتح، إدخال، حفظ، تحقق)؛ ويتيح WinDev تسجيل هذه السيناريوهات.
مثال بسيط: ياسين يسجّل إدخال طلب من البداية إلى النهاية.
ما ليس كذلك: اختبار يتحقق فقط من حسابات معزولة.
رد فعل: إعادة تشغيل مسار → سيناريو الواجهة.
- الانحدار
- عيب أدخله تعديل في جزء كان يعمل — الخطر الرئيسي في الصيانة، وسبب وجود الاختبارات التلقائية.
مثال بسيط: تصحيح الخصومات عند ياسين يجب ألا يكسر الإجماليات.
ما ليس كذلك: خطأ موجود منذ الإصدار الأول.
رد فعل: حماية الموجود → ضد الانحدارات.
- الحالات الحدية
- الصفر، القيم الفارغة، القيم القصوى، تغيّر السنة، النصوص الطويلة جدًا، الأحرف الخاصة: حيث تختبئ معظم الأخطاء.
مثال بسيط: ياسين يختبر خصمًا بنسبة 0% ومبلغًا سالبًا.
ما ليس كذلك: اختبار القيم «العادية» المستديرة فقط.
رد فعل: إيجاد الأخطاء → اختبار الحالات الحدية.
- الجودة بالمعنى الواسع
- إلى جانب الاختبارات: مراجعة الكود، والتوثيق، واصطلاحات الفريق وملاحظات المستخدمين جزء من نهج الجودة.
مثال بسيط: ياسين يجعل كوده يُراجَع ويسجّل ملاحظات المندوبين.
ما ليس كذلك: الاعتقاد بأن الاختبارات وحدها تكفي للجودة.
رد فعل: نهج كامل → الجودة بالمعنى الواسع.
في التطبيق — تطبيقيًا — إعداد الاختبارات
- ابدأ باختبارات وحدة على القلب التجاري: الحسابات والقواعد الحرجة (الضريبة، الخصومات، الاستحقاقات) — أفضل نسبة جهد/فائدة، كما فعل ياسين.
- اختبر منهجيًا الحالات الحدية: الصفر، القيم الفارغة، المبالغ السالبة، تواريخ تغيّر السنة، النصوص الطويلة جدًا.
- سجّل بعض سيناريوهات الواجهة على المسارات الأكثر حرجًا (إدخال طلب من البداية إلى النهاية) لكشف الانحدارات.
- عند كل خطأ يُصحّح، اكتب اختبارًا يعيد إنتاجه: تضمن ألا يعود أبدًا. وأبقِ اختباراتك محدّثة.
سكريبت خطوة بخطوة — الاختبار كما فعل ياسين (5 دقائق)
1) حدّد القلب التجاري لتطبيقك (حسابات، قواعد حرجة). 2) اكتب اختبار وحدة لكل قاعدة (الضريبة، الخصومات، الاستحقاقات) يتحقق من نتيجة معروفة. 3) أضف الحالات الحدية: صفر، قيم فارغة، مبلغ سالب، تغيّر السنة. 4) سجّل سيناريو واجهة على مسار إدخال الطلب. 5) عند كل خطأ يُصحّح، أضف اختبارًا يعيد إنتاجه. 6) شغّل مجموعة الاختبارات بعد كل تعديل وأبقها محدّثة.
كن موجَّهًا: القلب التجاري والحالات الحدية يعطيان الأكثر؛ وأبقِ الاختبارات محدّثة، وإلا منحت شعورًا زائفًا بالأمان.
نموذج للنسخ واللصق — بطاقة الاختبارات الخاصة بي
Unitaires : une procedure/classe -> bon resultat (coeur metier)
Interface : rejouer un scenario enregistre (ouvrir, saisir, valider)
Regressions: LE risque en maintenance -> detectees en minutes
Cas limites: zero, vide, negatif, changement d'annee
Regle d'or : un test a CHAQUE bug corrige
Tenue : tests obsoletes ignores = pires que pas de tests
Au-dela : revue de code, documentation, conventions, retours usersاختبار وحدة للضريبة
ياسين يتحقق من أن CalculeTTC(1000, 19) يعيد 1190.
حالة حدية
ياسين يختبر خصمًا بنسبة 0%، ومبلغًا سالبًا، وتغيّر السنة.
سيناريو واجهة
ياسين يسجّل الإدخال الكامل لطلب لإعادة تشغيله.
اختبار بعد التصحيح
ياسين يكتب اختبارًا يعيد إنتاج خطأ الخصم كي لا يعود أبدًا.
✓ ممارسات جيدة
- البدء بـالقلب التجاري، لا بتغطية كاملة.
- اختبار الحالات الحدية وكتابة اختبار عند كل خطأ يُصحّح.
- إبقاء الاختبارات محدّثة وإكمالها بمراجعة الكود.
✗ أخطاء شائعة
- استهداف تغطية 100% في تطبيق صغير.
- ترك اختبارات قديمة يتجاهلها الجميع.
- الاعتقاد بأن اختبار العرض يتحقق من الحسابات.
النقاط الأساسية
- ثلاثة مستويات: اختبارات وحدة (مردودية)، سيناريوهات واجهة، تدقيق المشروع.
- هدف الاختبارات التلقائية كشف الانحدارات، لا أخطاء اليوم فقط.
- ممارسات جيدة: القلب التجاري، الحالات الحدية، اختبار واحد لكل خطأ يُصحّح.
- ⚠️ إبقاء الاختبارات محدّثة؛ والجودة تشمل مراجعة الكود والتوثيق وملاحظات المستخدمين.
تحدي 48 ساعة — طبّقه غدًا
كما فعل ياسين، اختر قاعدة تجارية في تطبيقك (حساب ضريبة أو خصم أو استحقاق) واكتب ثلاثة اختبارات وحدة على الأقل: حالة «عادية» وحالتان حديتان (صفر، قيمة سالبة، تغيّر السنة). ثم سجّل سيناريو واجهة على مسار حرج. خذ آخر خطأ صُحّح واكتب الاختبار الذي يعيد إنتاجه. شغّل المجموعة وسجّل الوقت المكسب: هذه الدقائق القليلة تحل محل مراجعة يدوية مستحيلة.
- أكتب اختبارات وحدة موجّهة إلى القلب التجاري.
- أختبر الحالات الحدية وأسجّل سيناريوهات واجهة.
- أضيف اختبارًا عند كل خطأ يُصحّح وأبقي اختباراتي محدّثة.
أسئلة شائعة
هل تستحق الاختبارات التلقائية الاستثمار في مشروع صغير؟
نعم، لكن بطريقة موجّهة: لا تحاول اختبار كل شيء، ركّز على القلب التجاري (الحسابات والقواعد الحرجة) وعلى الأخطاء التي حدثت فعلًا. بضعة اختبارات مختارة بعناية تعطي الكثير؛ والتغطية الشاملة تكلف أكثر مما تعطي في مشروع صغير. تطبيق الإدارة يعيش طويلًا ويتطور: التكلفة الحقيقية ليست كتابة الاختبار، بل غيابه عندما يكسر تعديلٌ حسابًا بصمت ويكتشف عميل ذلك بعد ثلاثة أشهر. الاختبارات تمنح أيضًا الثقة للتعديل وتعمل كتوثيق.
كيف أعرف أن تطبيقي ذو جودة جيدة؟
بالنظر إلى أبعاد موضوعية عدة: يفعل ما يجب (الصحة)، ويقاوم الطوارئ (المتانة)، وقابل للاستخدام بفعالية (سهولة الاستخدام)، ويبقى سريعًا على أحجام حقيقية (الأداء)، ويمكن أن يتطور دون معاناة (قابلية الصيانة) — وكل ذلك يتحقق منه المستخدمون الحقيقيون. الصحة هي الأهم: في الإدارة، الإجمالي الخاطئ أو المخزون غير المتسق عيبان خطيران، وأخطر لأنهما لا يسببان أي خطأ ظاهر. أكمل بالأمان وقابلية النشر، واستمع إلى إشارات الإنذار (الخوف من التعديل، الأخطاء المتكررة، الانحدارات).
ما الفائدة الرئيسية للاختبارات التلقائية؟