الفرق الرئيسي بين التحقق و الصحة في الاختبار: دليل شامل

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

يحدد هذا الدليل كلا المصطلحين، ويوضح الفروق بينهما، ويُظهر مكان كل منهما في سير عمل اختبار واجهة برمجة التطبيقات (API) باستخدام Apidog.

ما هو التحقق (Verification)؟

يسأل التحقق: هل نبني المنتج بشكل صحيح؟

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

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

• مراجعات الكود والمراجعات التفصيلية (walkthroughs)
• التحليل الساكن (Static analysis) والتدقيق اللغوي للكود (linting)
• مراجعات التصميم والهندسة المعمارية
• فحوصات المخطط (Schema) والعقد (Contract)
• اختبارات الوحدة التي تؤكد أن الوظيفة تؤدي ما توعد به من خلال توقيعها (signature)

السمة الرئيسية هي أن التحقق داخلي في الغالب. إنه يقارن قطعة أثرية بأخرى: الكود مقابل التصميم، الاستجابة مقابل المخطط، التنفيذ مقابل المواصفات. لا يلزم وجود مستخدم حقيقي. إذا كانت المواصفات تقول أن نقطة النهاية (endpoint) تُرجع `201` مع رأس `Location`، فإن التحقق يؤكد أنها تفعل ذلك بالضبط.

ما هي المصادقة (Validation)؟

تسأل المصادقة: هل نبني المنتج الصحيح؟

تتأكد من أن البرنامج يلبي بالفعل احتياجات المستخدم ويحل المشكلة الحقيقية، بغض النظر عما ذكرته المواصفات. تقارن المصادقة العمل بالواقع ونية الاستخدام، وليس بوثيقة.

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

• اختبار قبول المستخدم (User acceptance testing)
• برامج البيتا (Beta programs) واختبار قابلية الاستخدام (usability testing)
• الاختبار الشامل (End-to-end testing) لسير العمل الكاملة
• عروض أصحاب المصلحة (Stakeholder demos) والموافقة النهائية (sign-off)

السمة الرئيسية هي أن المصادقة موجهة للخارج. تسأل عما إذا كان المنتج النهائي مفيدًا وصحيحًا في السياق. يمكن لواجهة برمجة التطبيقات (API) أن تجتاز كل فحص تحقق، وتتوافق تمامًا مع مواصفات OpenAPI الخاصة بها، ومع ذلك تفشل المصادقة لأن المواصفات نفسها حلت المشكلة الخاطئة؛ نموذج ترقيم الصفحات (pagination model) غير قابل للاستخدام، أو تدفق المصادقة (auth flow) لا يتناسب مع كيفية دمج العملاء فعليًا.

المصادقة مقابل التحقق: الفروقات

المصطلحان غير قابلين للتبديل، ولا يحل أحدهما محل الآخر. التحقق القوي مع المصادقة الضعيفة يمنحك منتجًا خاليًا من العيوب لا يرغب فيه أحد. المصادقة القوية مع التحقق الضعيف تمنحك الفكرة الصحيحة المطبقة على كود غير مستقر. أنت بحاجة إلى كليهما، مطبقين في الوقت المناسب.

مساعد ذاكرة بسيط: التحقق هو الاختبار مقابل الوثيقة، والمصادقة هي الاختبار مقابل الغرض.

كيف يتجلى هذا في اختبار واجهة برمجة التطبيقات (API)

تجعل واجهات برمجة التطبيقات (APIs) التمييز ملموسًا، لأن واجهة برمجة التطبيقات لها مواصفات صريحة وقابلة للقراءة آليًا: تعريفها OpenAPI أو المخطط. تلك المواصفات هي الأساس للتحقق.

التحقق لواجهة برمجة التطبيقات (API) يعني فحص التنفيذ مقابل هذا العقد:

• هل تُرجع كل نقطة نهاية (endpoint) رموز الحالة (status codes) الموثقة؟ الحفاظ على هذه الرموز متسقة هو انضباط بحد ذاته؛ انظر ما هي رموز حالة HTTP التي يجب أن تستخدمها واجهات برمجة تطبيقات REST.
• هل تتطابق كل استجابة مع المخطط الموثق، مع أسماء الحقول والأنواع الصحيحة؟
• هل يتم فرض المعلمات المطلوبة تمامًا كما هو محدد؟
• هل يتطابق تنسيق الخطأ مع شكل الخطأ الموثق؟

هذا هو أيضًا المكان الذي يوجد فيه اختبار عقد واجهة برمجة التطبيقات (API). اختبار العقد هو تحقق محض: يؤكد أن المنتج لا يزال يلتزم بالاتفاق الذي يعتمد عليه المستهلكون. تأكيدات واجهة برمجة التطبيقات (API) على الحالة، والمخطط، والرؤوس هي وحدة عمل التحقق.

المصادقة لواجهة برمجة التطبيقات (API) تعني فحص ما إذا كانت واجهة برمجة التطبيقات تخدم مستهلكيها حقًا:

• هل يمكن للعميل إكمال سير عمل حقيقي وشامل، تسجيل الدخول، إنشاء، تحديث، حذف، بدون حلول بديلة محرجة؟
• هل البيانات التي تُرجعها واجهة برمجة التطبيقات تجيب بالفعل على الأسئلة التي يطرحها مطورو العميل؟
• هل نموذج المصادقة (auth model) عملي للتكاملات الموجودة؟
• هل تعكس الأمثلة الموثقة كيفية استخدام واجهة برمجة التطبيقات فعليًا؟

سيناريو اختبار واجهة برمجة التطبيقات الذي يربط عدة طلبات في رحلة مستخدم كاملة أقرب إلى المصادقة؛ بينما فحص مخطط نقطة نهاية واحدة هو تحقق. كلاهما ينتمي إلى مجموعة الاختبار. يساعد فهم سيناريوهات الاختبار مقابل حالات الاختبار على رؤية الطبقة التي تعمل عليها.

أين يتناسب Apidog

يدعم Apidog كلا جانبي التمييز لأنه يحتفظ بتصميم واجهة برمجة التطبيقات واختبارها وتوثيقها في مساحة عمل واحدة.

بالنسبة للتحقق، تصميم واجهة برمجة التطبيقات هو المواصفات. عندما تبني اختبارًا، فإنك تؤكد الاستجابات مقابل نفس المخطط الذي يحدد واجهة برمجة التطبيقات، لذلك لا يوجد للتحقق نسخة ثانية من العقد للانحراف عنها. يتم تشغيل تأكيدات المخطط، وتأكيدات الحالة، وفحوصات العقد كلها مقابل مصدر الحقيقة. قم بتشغيلها في كل عملية commit عبر CI؛ أتمتة اختبارات واجهة برمجة التطبيقات (API) في CI/CD تجعل التحقق مستمرًا، وهذا هو بالضبط متى يجب أن يحدث.

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

تقارير الأداء تُكمل الدائرة. يولد Apidog نتائج لكل خطوة، لذا فإن فحص التحقق الفاشل (عدم تطابق المخطط) وفحص المصادقة الفاشل (سير عمل متعدد الخطوات معطل) يكونان كلاهما مرئيين ومميزين وقابلين للتتبع.

حمل Apidog لإعداد كل من التحقق على مستوى العقد والمصادقة على مستوى سير العمل لواجهة برمجة التطبيقات الخاصة بك.

مثال من العالم الحقيقي

تخيل فريقًا يبني واجهة برمجة تطبيقات للمدفوعات. تقول المواصفات إن `POST /payments` يقبل مبلغًا وعملة، ويعيد `201` مع `payment_id`، ويرفض العملات غير الصالحة برمز `400`.

يتم التحقق من واجهة برمجة التطبيقات هذه بسلاسة. تؤكد مراجعة الكود أن المعالج يتطابق مع التصميم. تؤكد تأكيدات المخطط أن كل استجابة تحتوي على الحقول والأنواع الموثقة. تؤكد اختبارات العقد أن شكل خطأ `400` مطابق تمامًا للمواصفات. تجتاز فحوصات رموز الحالة كل الاختبارات. بكل مقياس للتحقق، تم بناء واجهة برمجة التطبيقات بشكل صحيح.

ثم يتكامل أول عميل حقيقي. يكتشفون أن واجهة برمجة التطبيقات تقبل المبلغ كعدد عشري (floating-point)، لذلك `0.1 + 0.2` يتم تقريبه إلى قيمة لا تتطابق مع فاتورة العميل. قالت المواصفات "amount: number". احترم التنفيذ ذلك تمامًا. كانت المواصفات خاطئة؛ يجب ألا يكون المال أبدًا عددًا عشريًا. لم يكن من الممكن للتحقق أن يكتشف هذا، لأن التحقق يفحص فقط التنفيذ مقابل المواصفات، وكلاهما اتفق.

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

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

قائمة تحقق عملية

لأي إصدار من واجهة برمجة التطبيقات (API)، قم بتشغيل كلا العمودين:

التحقق (مقابل المواصفات):

• كل نقطة نهاية تُرجع رموز الحالة الموثقة
• كل استجابة تتوافق مع مخططها
• يتم فرض المعلمات المطلوبة
• استجابات الخطأ تتطابق مع الشكل الموثق
• تنجح اختبارات العقد لجميع نقاط النهاية التي يواجهها المستهلكون

المصادقة (مقابل الغرض):

• يمكن لعميل جديد إكمال سير العمل الأساسي من البداية إلى النهاية
• البيانات المعادة تجيب على أسئلة العميل الحقيقية
• تدفق المصادقة يعمل لأنماط التكامل الفعلية
• الأمثلة الموثقة تتطابق مع الاستخدام الحقيقي
• يؤكد أصحاب المصلحة أن واجهة برمجة التطبيقات تحل المشكلة المقصودة

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

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

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

هل الاختبار هو نفسه المصادقة؟ لا. الاختبار يشمل كليهما. اختبارات الوحدة وفحوصات المخطط هي تحقق؛ اختبارات القبول والاختبارات الشاملة هي مصادقة. مصطلح "الاختبار" يغطي النطاق بأكمله.

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

كيف ينطبق هذا على اختبار عقد واجهة برمجة التطبيقات (API)؟ اختبار العقد هو تحقق. يؤكد أن واجهة برمجة التطبيقات لا تزال تلتزم باتفاقها الموثق مع المستهلكين. لا يؤكد أن هذا الاتفاق كان هو الصحيح؛ هذه مهمة المصادقة.

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

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