«الاختبار الوظيفي مقابل الاختبار المؤتمت» هي إحدى المقارنات الأكثر شيوعًا في ضمان الجودة (QA)، وهي مبنية على خطأ. المصطلحان ليسا متضادين. إنهما يصفان أشياء مختلفة تمامًا، ويمكن أن يكون لديك أحدهما دون الآخر أو كلاهما في نفس الوقت. معاملتهما كخيار، وظيفي أو مؤتمت، يقود الفرق إلى بناء استراتيجية اختبار خاطئة.
يوضح هذا الدليل المصطلحين، ويشرح المحورين المنفصلين اللذين ينتميان إليهما، ويُظهر مكان كل منهما في سير عمل اختبار واجهة برمجة التطبيقات (API) الحقيقي.
خطأ الفئة
ينشأ الارتباك من مقارنة الإجابات على سؤالين مختلفين.
يجيب الاختبار الوظيفي على السؤال: ماذا نختبر؟ إنه يختبر ما إذا كان البرنامج يؤدي ما هو مفترض أن يفعله، الميزات، السلوك، المخرجات.
يجيب الاختبار المؤتمت على السؤال: كيف نجري الاختبار؟ إنه يجري الاختبارات باستخدام أدوات برمجية بدلاً من أن يقوم إنسان بتنفيذ الخطوات يدويًا.
هذان مستقلان. «ما تختبره» و«كيف تجريه» هما محوران منفصلان. يمكن إجراء الاختبار الوظيفي يدويًا أو تلقائيًا. يمكن للاختبار المؤتمت التحقق من السلوك الوظيفي أو السلوك غير الوظيفي مثل الأداء. لذا، المقارنة الحقيقية ليست وظيفية مقابل مؤتمتة؛ إنها بُعدان مختلفان يُذكران معًا بالصدفة.
بمجرد أن تدرك ذلك، يتوقف السؤال «هل يجب أن نقوم باختبار وظيفي أم اختبار مؤتمت؟» عن أن يكون منطقيًا. الأسئلة الصحيحة هي: ماذا يجب أن نختبر، وأي من تلك الاختبارات يجب أن نؤتمتها؟
ما هو الاختبار الوظيفي
يتحقق الاختبار الوظيفي من أن كل ميزة من ميزات التطبيق تتصرف وفقًا لمتطلباتها. عادة ما يكون اختبار الصندوق الأسود: حيث يقوم المختبر بفحص المدخلات والمخرجات دون النظر إلى الكود الداخلي. امنح الميزة مدخلاً، ولاحظ المخرج، وقارنه بما يجب أن يحدث وفقًا للمتطلبات.
بالنسبة لواجهة برمجة التطبيقات (API)، يعني الاختبار الوظيفي التأكد من أن نقطة النهاية (endpoint) تُرجع البيانات الصحيحة، ورمز الحالة الصحيح، واستجابات الخطأ الصحيحة. هل يقوم POST /orders بإنشاء طلب؟ هل يرفض حمولة غير صالحة برمز 400؟ هل تتطابق الاستجابة مع المخطط الموثق؟ هذه هي الفحوصات الوظيفية، وهي تعتمد على تأكيدات واجهة برمجة التطبيقات (API) التي تقارن الاستجابة الفعلية بالمتوقعة.
تكمن قوة الاختبار الوظيفي في صلته المباشرة: فهو يتحقق مما يهتم به المستخدمون فعليًا، وهو ما إذا كانت الميزة تعمل أم لا. حدوده تكمن في النطاق. الاختبار الوظيفي وحده لا يقول شيئًا عن السرعة، أو الاستقرار تحت الضغط، أو الأمان. يمكن أن تكون نقطة النهاية مثالية من الناحية الوظيفية ومع ذلك تنهار تحت حركة المرور؛ هذه الفجوة هي ما يغطيه اختبار الأداء. الاختبار الوظيفي ضروري، لكنه ليس الصورة الكاملة.
عكس الاختبار الوظيفي هو الاختبار غير الوظيفي، مثل الأداء، التحميل، الأمان، وسهولة الاستخدام، وهو النظير الصحيح للمصطلح، وليس «الاختبار المؤتمت».
ما هو الاختبار المؤتمت
يستخدم الاختبار المؤتمت الأدوات والسكربتات لتنفيذ الاختبارات والتحقق من النتائج، بدلاً من أن يقوم شخص بالنقر على الخطوات يدويًا. تقوم بتعريف الاختبار مرة واحدة، مع مدخلاته ونتائجه المتوقعة، وتقوم الأداة بتشغيله عند الطلب، أو بجدول زمني، أو عند كل تغيير في الكود.
عكس الاختبار المؤتمت هو الاختبار اليدوي، حيث يقوم إنسان بتنفيذ كل خطوة. هذا هو النظير الصحيح للمصطلح.
قيمة الأتمتة تكمن في الاتساق والنطاق. تقوم الآلة بتشغيل الاختبار الألف تمامًا مثل الأول ولا تتعب أبدًا. إنها تجعل اختبار الانحدار رخيصًا بما يكفي لتشغيله عند كل التزام (commit). تكلفتها هي أن الاختبارات المؤتمتة يجب أن تُكتب وتُصان، ولا يمكنها ممارسة الحكم، بل تتحقق فقط مما أخبرتها بتوقعه. توجد معالجة أعمق في ما هو الاختبار المؤتمت.
الأهم من ذلك، الأتمتة هي آلية تنفيذ، وليست نوعًا من الاختبار. أنت تؤتمت نوعًا معينًا من الاختبارات، سواء كانت وظيفية أو أداء أو أمنية. «الاختبار المؤتمت» بحد ذاته لا يوضح ما يتم التحقق منه.
كيف تتحد المحاور الاثنان
ضع المحورين معًا وستحصل على أربع فئات حقيقية، وكلها موجودة في الممارسة العملية.
| وظيفي | غير وظيفي | |
|---|---|---|
| يدوي | يقوم المختبر بالنقر على تدفق الدفع للتأكد من عمله | يقوم المختبر بالحكم على ما إذا كانت واجهة المستخدم تستجيب بشكل جيد |
| مؤتمت | سكربت يستدعي نقطة نهاية ويتأكد من صحة الاستجابة | اختبار تحميل يحاكي 500 مستخدم افتراضي ويقيس زمن الاستجابة |
كل خلية تمثل نوعًا مشروعًا وشائعًا من الاختبار. الخلية العلوية اليسرى، الاختبار الوظيفي اليدوي، هي ما يتخيله معظم الناس عندما يسمعون كلمة «اختبار». الخلية السفلية اليسرى، الاختبار الوظيفي المؤتمت، هي ما تتكون منه معظم مجموعات اختبار واجهة برمجة التطبيقات (API) الحديثة: سكربتات أو سيناريوهات تتحقق من الميزات تلقائيًا. العمود الأيمن هو عمل غير وظيفي، ويتم إجراؤه بالطريقتين أيضًا.
لذا، القرارات الهامة ليست «وظيفية أم مؤتمتة». بل هي:
- ما هي السلوكيات التي يجب اختبارها: يحتاج كل من الاختبار الوظيفي وغير الوظيفي إلى تغطية.
- ما هي الاختبارات التي يجب أتمتتها: الاختبارات المستقرة والمتكررة وذات القيمة العالية؛ اترك الفحوصات الاستكشافية وتلك التي تتطلب حكمًا يدويًا.
يمكن أن يقع الاختبار في أي خلية، وتستخدم الاستراتيجية السليمة جميع الفئات الأربع.
أين ينطبق هذا في اختبار واجهة برمجة التطبيقات (API)
اختبار واجهة برمجة التطبيقات (API) هو المكان الذي تتوافق فيه المحاوران بأكثر الطرق وضوحًا، لأن واجهات برمجة التطبيقات مناسبة تمامًا للاختبار الوظيفي المؤتمت.
تمتلك واجهة برمجة التطبيقات (API) عقدًا واضحًا، وطلبات واستجابات منظمة، ولا توجد واجهة مستخدم لعرضها. وهذا يجعل سلوكها الوظيفي سهل الفحص بواسطة سكربت وسهل التأكيد بدقة. لذلك، بالنسبة لواجهات برمجة التطبيقات، يجب أن يتم أتمتة الجزء الأكبر من الاختبار الوظيفي. لا يوجد سبب يذكر لإعادة إرسال نفس الطلب يدويًا ومراقبة الاستجابة مائة مرة بينما يمكن للأداة القيام بذلك عند كل التزام (commit).
يبدو نهج اختبار واجهة برمجة التطبيقات العملي على هذا النحو. يتم كتابة الفحوصات الوظيفية، مثل رموز الحالة، وهياكل الاستجابة، وتوافق المخطط، وأشكال الأخطاء، كـ حالات اختبار وتجميعها في سيناريوهات اختبار. تُشغل هذه تلقائيًا، عند كل تغيير، عبر CI/CD. تُشغل الفحوصات غير الوظيفية، مثل التحميل والأداء، تلقائيًا أيضًا، بجدول زمني. يذهب الجهد اليدوي إلى الاختبار الاستكشافي والتحقق من أن واجهة برمجة التطبيقات تحل المشكلة بصدق، وهو عمل التحقق الذي يتطلب الحكم، وليس السكربتات.
ماذا يجب أتمتته وماذا يجب الاحتفاظ به يدويًا
رؤية المحورين بوضوح تؤدي إلى السؤال الذي يهم حقًا: من بين جميع الاختبارات الوظيفية التي يمكنك تشغيلها، أيها يستحق الأتمتة؟ أتمتة كل شيء مضيعة، وأتمتة الأشياء الخاطئة ينتج عنه مجموعة اختبار بطيئة وهشة. تساعد بعض القواعد.
أتمتت المتكرر والمستقر. فحص وظيفي ستُشغله عند كل التزام (commit) خلال العامين القادمين هو مرشح مثالي للأتمتة. يتم استرداد تكلفة كتابته مئات المرات. اختبارات الانحدار، وهي الفحوصات التي تؤكد أن الميزات القديمة لا تزال تعمل، هي أوضح مثال.
أتمتت المسارات ذات القيمة العالية أولاً. يجب أتمتة تدفق تسجيل الدخول، وعملية الدفع، ونقاط نهاية واجهة برمجة التطبيقات (API) الأساسية، وأي شيء يمكن أن يؤدي فشله إلى حادث خطير، في وقت مبكر. هذه هي الاختبارات التي لا يمكنك تحمل تخطيها تحت ضغط المواعيد النهائية، والأتمتة تزيل هذا الإغراء.
لا تؤتمت النادر أو غير المستقر. فحص ستُشغله مرتين لا يستحق كتابة سكربت له. ميزة لا تزال تتغير يوميًا ستكسر اختباراتها يوميًا؛ انتظر حتى تستقر. الأتمتة المبكرة لهدف متحرك تخلق فقط ضوضاء صيانة.
حافظ على الاختبار الاستكشافي يدويًا. الاختبارات المؤتمتة لا تجد إلا ما أخبرتها بالبحث عنه. إنسان يبحث في البرنامج بطرق غير مكتوبة يجد الأخطاء التي لم يتوقعها أحد. هذا العمل هو اختبار وظيفي أيضًا، ويجب أن يبقى يدويًا عن قصد.
احتفظ بالفحوصات القائمة على الحكم يدويًا. ما إذا كانت رسالة الخطأ مفيدة حقًا، أو ما إذا كان سير العمل متسقًا، أو ما إذا كانت واجهة برمجة التطبيقات تحل مشكلة المستخدم بالفعل، كل هذا يتطلب شخصًا. لا يمكن لأي تأكيد أن يلتقطها.
النتيجة هي تقسيم مقصود: مجموعة وظيفية مؤتمتة كبيرة تغطي المسارات المستقرة، الحرجة، والمتكررة، وجهد يدوي أصغر ومستمر يركز على الاستكشاف والحكم. الفرق التي تؤتمت بعناية تحصل على ملاحظات سريعة دون مجموعة اختبار هشة؛ الفرق التي تؤتمت كل شيء ينتهي بها الأمر بصيانة الاختبارات بدلاً من تقديم المنتج.
بناء اختبارات واجهة برمجة تطبيقات وظيفية مؤتمتة في Apidog
صُممت Apidog لاختبار واجهات برمجة التطبيقات الوظيفية المؤتمتة دون الحاجة إلى كتابة سكربتات. تقوم بتعريف نقطة نهاية، وتضيف تأكيدات بصرية للحالة، وحقول الجسم، والمخطط، ووقت الاستجابة، ثم تجمع الطلبات في سيناريوهات اختبار. تُشغل هذه السيناريوهات عند الطلب أو ضمن خط أنابيب CI، وتقوم بتنفيذ الفحوصات الوظيفية تلقائيًا والإبلاغ بدقة عن التأكيد الذي فشل.
نظرًا لأن نفس مساحة العمل تقوم أيضًا بتشغيل اختبارات التحميل، فإنك تغطي كلا المحورين، الوظيفي وغير الوظيفي، المؤتمت، في مكان واحد. يصبح السيناريو الوظيفي الذي تبنيه للتأكد من الصحة هو اختبار التحميل الذي تشغله للأداء. قم بتنزيل Apidog لبناء مجموعة اختبار وظيفية مؤتمتة لواجهة برمجة تطبيقات لديك بالفعل.
الأسئلة الشائعة
هل الاختبار المؤتمت نوع من الاختبار الوظيفي؟ لا. الاختبار المؤتمت هو طريقة لتشغيل الاختبارات. الاختبار الوظيفي هو فئة لما تختبره. يمكن أن يكون الاختبار المؤتمت وظيفيًا أو غير وظيفي؛ ويمكن أن يكون الاختبار الوظيفي يدويًا أو مؤتمتًا.
هل يمكن أتمتة الاختبار الوظيفي؟ نعم، وبالنسبة لواجهات برمجة التطبيقات (APIs) يجب أن يكون كذلك عادةً. الاختبار الوظيفي المؤتمت، أو السكربتات أو السيناريوهات التي تتحقق من الميزات عند كل تغيير، هو جوهر مجموعة اختبار واجهة برمجة التطبيقات الحديثة.
ما هو العكس الحقيقي للاختبار الوظيفي؟ الاختبار غير الوظيفي: الأداء، التحميل، الأمان، وسهولة الاستخدام. تتحقق هذه من صفات أخرى غير ما إذا كانت الميزة تنتج المخرجات الصحيحة.
هل يجب أتمتة كل اختبار وظيفي؟ لا. قم بأتمتة الفحوصات المستقرة، المتكررة، وذات القيمة العالية. احتفظ بالاختبار الاستكشافي والتحقق القائم على الحكم يدويًا، نظرًا لأن الأتمتة لا تستطيع تحديد ما إذا كان الشيء جيدًا حقًا، بل فقط ما إذا كان يطابق توقعًا.
من أين يجب أن يبدأ الفريق؟ باختبارات واجهة برمجة التطبيقات الوظيفية المؤتمتة. إنها سريعة، مستقرة، وتغطي المنطق الأساسي. أضف اختبارات غير وظيفية مؤتمتة واختبارات استكشافية يدوية من هناك.
هل يحل الاختبار المؤتمت محل المختبرين اليدويين؟ لا. إنه يحل محل الجزء المتكرر من عملهم، وهو إعادة تشغيل نفس الفحوصات، بحيث يمكن للمختبرين التركيز على الاختبار الاستكشافي، والحالات الهامشية، والحكم على ما إذا كان البرنامج جيدًا حقًا. تتطلب تلك المهام أشخاصًا، وهي ذات قيمة أعلى من النقر يدويًا على قائمة مراجعة الانحدار.
هل يمكن أن يكون نفس الاختبار وظيفيًا ومؤتمتًا في آن واحد؟ نعم، ومعظم اختبارات واجهات برمجة التطبيقات (API) هي كذلك تمامًا: اختبارات وظيفية مؤتمتة. سكربت يستدعي نقطة نهاية ويتأكد من صحة الاستجابة يتحقق من الوظيفة ويُشغل تلقائيًا. يصف الملصقان جانبين مختلفين لنفس الاختبار، وليس تناقضًا.