الاختبار الوظيفي هو نهج اختبار برمجي يتحقق مما إذا كانت ميزة التطبيق تعمل على النحو المتوقع بناءً على المتطلبات المحددة.
في تطوير البرمجيات، هناك العديد من أنواع اختبارات البرمجيات. وكل نوع يتناول المهمة من منظور مختلف قليلًا. يرتبط الاختبار الوظيفي ارتباطًا وثيقًا بمفهوم تجربة المستخدم، ويركِّز على سؤال أساسي واحد: هل تعمل ميزات البرنامج على النحو المتوقع ووفق المتطلبات المحددة؟
غالبًا ما يتم تقييم جودة البرمجيات من زوايا متعددة كجزء من دورة حياة تطوير البرمجيات. فيما يتعلق بالاختبار الوظيفي، يحتاج المختبِرون إلى التحقق من الوظائف الأساسية والتأكُّد من أن ميزات البرنامج تدعم متطلبات العمل بشكل فعَّال. يُتيح تنفيذ الاختبار لفِرق عمليات التطوير مقارنة النتائج الفعلية للاختبار مع النتائج المتوقعة.
يُعَد الاختبار جزءًا أساسيًا من عملية التطوير، ويسمح الاختبار الوظيفي لفِرق ضمان الجودة بإجراء نوع من ضمان الجودة المسبق، ما يمنحهم رؤية واضحة لكيفية عمل مهام سير العمل المحتمل عند إطلاقها فعليًا.
النشرة الإخبارية الخاصة بالمجال
ابقَ على اطلاع دائم على أبرز الاتجاهات في مجالات الذكاء الاصطناعي، والأتمتة، والبيانات، وغيرها الكثير من خلال رسالة Think الإخبارية. راجع بيان الخصوصية لشركة IBM.
سيصلك محتوى الاشتراك باللغة الإنجليزية. ستجد رابط إلغاء الاشتراك في كل رسالة إخبارية. يمكنك إدارة اشتراكاتك أو إلغاء اشتراكك من هنا. لمزيد من المعلومات، راجع بيان خصوصية IBM.
يتم تسليط الضوء على عناصر تشغيلية مختلفة، اعتمادًا على نوع اختبار البرمجيات الذي يتم استخدامه كجزء من استراتيجية الاختبار الشاملة. يعمل الاختبار الوظيفي على تقييم التوافق الشامل بين وحدات البرامج المختلفة، ما يؤثِّر بشكل مباشر في جوانب أخرى ذات صلة، مثل تفاعلات المستخدم المتوقعة وقابلية استخدام واجهة المستخدم.
تُعَد بيئة الاختبار التي يوفرها الاختبار الوظيفي مثالًا على اختبار الصندوق الأسود، حيث لا يطَّلع المختبِرون على التفاصيل الداخلية للنظام (كما هو الحال في الاختبار الصندوق الأبيض)، بل يحصلون على تقرير "نجاح/فشل" بسيط يوضِّح إذا ما كان النظام ومساراته تعمل بالشكل المطلوب.
عادةً ما يتَّبع الاختبار الوظيفي عملية اختبار تتطلب ست خطوات:
مثلما توجد أنواع مختلفة من نماذج اختبار البرمجيات، هناك أنواع مختلفة من الاختبار الوظيفي. وهي كثيرة، وهذه ليست سوى قائمة جزئية منها. تشتمل أنواع الاختبارات الوظيفية على مجموعة واسعة من الفروق الدقيقة ويتم إدراجها هنا.
في اختبار البرمجيات، غالبًا ما يتَّبع المختبرون عملية الاختبار الرسمية باختبارات مخصصة. هذا الشكل غير الرسمي من الاختبار الاستكشافي يتم توجيهه بالكامل من خلال مهارات المختبرين وحدسهم. لا يوجد هيكل محدد. وبدلًا من ذلك، تعتمد تقنيات الاختبار على خبرة وغريزة المختبرين.
مثال: "اختبار الرفيق"، حيث يتعاون المطور والمختبر معًا لتحسين وحدة أو تطبيق. في هذا النوع من الاختبار المخصص، يكتشف المختبِر عادةً أي أخطاء أو مشكلات تحتاج إلى إصلاح، بينما يركِّز المطور على معالجة هذه المشكلات.
تمكِّن واجهات برمجة التطبيقات (APIs) تطوير البرمجيات وتسمح للتطبيقات أو الأنظمة المختلفة بالاتصال. يضمن اختبار واجهات برمجة التطبيقات أن نقاط الاتصال الخاصة بها تعمل بالشكل المطلوب. كما يوفر إمكانية الإشراف على أذونات المستخدم والطريقة التي تُدار بها البيانات عبر واجهات برمجة التطبيقات.
مثال: الاختبار دون واجهة، ويحدث عندما لا تتوفر واجهة مستخدم أو حقل إدخال بيانات في الواجهة. في مثل هذه الحالات، غالبًا ما يكون اختبار بيانات الإدخال إلى خدمة أو تطبيق متصل أفضل إجراء يمكن تنفيذه من خلال اختبار واجهة برمجة التطبيقات.
يريد العديد من المؤسسات أن تكون عملية الاختبار الخاصة بها انعكاسًا حقيقيًا للتجربة الفعلية للمستخدمين الحقيقيين. بالنسبة إلى هذه الشركات، توفِّر سيناريوهات الاختبار المعقدة المستوى المطلوب من الدقة، مع الإشارة إلى أن التعقيد الأكبر يتطلب جهدًا أكبر في البداية للتنفيذ.
مثل: تبدو معالجة الطلبات عبر الإنترنت وكأنها عملية سلسة فقط. ولكن خلف الكواليس، هناك العديد من العمليات التي يجب اختبارها، مثل سهولة إضافة العناصر إلى سلة المشتريات الإلكترونية، وسرعة دمج وظائف مثل تطبيق الخصومات، وسلاسة إجراء عمليات الشراء.
غالبًا ما يتم تنفيذ اختبار التكامل في وقت اختبار الوحدة نفسه نظرًا لفوائد مثل الكشف المبكر عن المشكلات والنطاق الأوسع لتغطية الاختبار. بالإضافة إلى مساعدة تنسيقات البيانات على التوافق، يوفر اختبار التكامل نظرة ثاقبة حول عمل وأداء الخدمات المصغرة.
مثال: لنفترض أن نظام إدارة الطلبات متكامل مع نوع ما من الوحدات التي تحكم معالجة الدفع. يُظهر اختبار التكامل أين يمكن أن تحدث المشكلات المستقبلية بين الكيانَين ويمنح المطورين مخططًا لإصلاح مشكلات التكامل في وقت مبكر وبتكلفة أقل.
في العالم المثالي، بمجرد اجتياز الاختبار الوظيفي، فإنه سينجح دائمًا. لكن هذا لا يتوافق مع الواقع، حيث غالبًا ما تتأثر البرمجيات بالمطورين الذين قد يتسببون عن غير قصد في حدوث أخطاء عند إدخال تغييرات جديدة في الكود. تضمن اختبارات الانحدار الحفاظ على خط الأساس الثابت.
مثال: في كل مرة يتم فيها إجراء تغييرات على الكود، يتم استخدام شكل من أشكال اختبار الانحدار. ويتضمن ذلك أي تحديثات ذات صلة، كما يتم إجراؤها بعد إصلاح الأخطاء، أو تقديم وظائف جديدة، أو بعد تحديث البرنامج.
يُعَد اختبار الصحة طريقة سريعة ومرنة للتحقق من أن الوظائف الحالية لم تتأثر بسبب إضافة تغييرات بسيطة أو إصلاحات للأخطاء. غالبًا ما يتم استخدام اختبار الصحة كطريقة سريعة للتأكد من أن الوظائف الجديدة لا تؤثِّر سلبًا في بقية وظائف النظام.
مثال: كما هو الحال في اختبار الانحدار، يُتيح اختبار الصحة "إعادة" النظام إلى الوظائف السابقة للتحقق من تحسينات الأداء، وتأكيد العمليات الأساسية، وضمان عمل النظام كما هو متوقع. في أي وقت يتم فيه إجراء تغييرات في الكود، يتم استخدام شكل من أشكال اختبار الانحدار. ويتضمن ذلك أي تحديثات ذات صلة، كما يتم إجراؤها بعد إصلاح الأخطاء، أو تقديم وظائف جديدة، أو بعد تحديث البرنامج.
تقول مقولة قديمة: حيث يوجد دخان، يوجد نار. يبدو أن هذا المثل هو مصدر الإلهام وراء تسمية "اختبار الدخان". يتم إجراء اختبار الدخان في وقت مبكر من عملية التطوير، وعند إجرائه، فإنه يحكم على الوظيفة الشاملة. وفي حالة فشل الوظيفة، تعمل فِرق ضمان الجودة على إجراء التصحيحات اللازمة.
مثال: يمكن استخدام اختبارات الدخان للتحقق من التكامل المستمر والأنابيب المستمرة كفحص نهائي قبل نشر إصدارات البرامج الجديدة (أو التغييرات الرئيسية في الكود).
يُطلق على اختبار النظام أحيانًا اسم الاختبار الشامل، ويعمل على تقييم كيفية عمل برامج نظام برمجي كامل معًا. غالبًا ما يتضمن اختبار النظام تحليل أنظمة برمجية منفصلة متعددة قد تعمل أو لا تعمل في وقت واحد داخل نظام برمجي معين.
مثال: تُتيح السيناريوهات الشاملة للمختبِرين تقييم سير العمل بالكامل. بالنسبة إلى عمليات البيع بالتجزئة عبر الإنترنت، قد يعني هذا تجربة البيع بالتجزئة بأكملها التي يختبرها المستهلك، بدءًا من طلب الشراء الأصلي وحتى عملية التنفيذ بأكملها.
اختبار الوحدة هو شكل من أشكال الاختبار في صورة مصغرة. نحن لا نختبر هنا نظامًا بأكمله، بل جزءًا محدودًا من الكود. يتم تقييم قسم من الكود في بيئة اختبار معزولة، وإذا فشل اختبار الوحدة (بناءً على مقارنة بيانات الاختبار بأهداف الوظائف)، يمكن إجراء المزيد من الاختبارات على مستوى النظام بأكمله.
مثال: يتم اختبار العناصر الحسابية الأساسية بشكل جيد من خلال اختبار الوحدة. تخيَّل دالة بسيطة تعمل على تحويل درجات الحرارة المئوية إلى نظيرتها بالفهرنهايت. تحتوي بيئة الاختبار على الكود المعنيّ وحالات الاختبار المعنية.
كمرحلة متقدمة من اختبار البرمجيات، يسعى اختبار قبول المستخدم إلى دمج نتائج اختبار الأداء والاستفادة منها من قِبل الأشخاص الذين يمثِّلون الفئة المستهدفة للبرمجيات التي يتم تطويرها. يضفي هؤلاء المستخدمون النهائيون مزيدًا من الواقعية على عملية الاختبار.
مثال: يُجري مستخدم خطة برمجية الترقية إلى مستوى الخدمة التالي، ما يمنحه الحق في فتح وظائف جديدة بالكامل. يتحقق اختبار قبول المستخدم من أن المستخدم سيكون قادرًا على رؤية زيادة في وصوله إلى الميزات كما هو متوقع.
كما يوحي اسمه، يعمل الاختبار غير الوظيفي على تقييم سلوكيات التطبيق التي لا تُعَد عادةً حيوية لضمان الوظيفة. ومع ذلك، فإن تقديم تجربة مستخدم جيدة التنظيم وممتعة يُعَد الآن جزءًا أساسيًا من تطوير البرمجيات. يمكن أن يكشف الاختبار غير الوظيفي عن مشكلات محتملة في النظام، خاصةً عند زيادة استخدام البرمجيات لإظهار قدر أكبر من قابلية التوسع.
اختبار التحميل هو شكل رئيسي من أشكال الاختبار غير الوظيفي. نظريًا، يجب أن يكون النظام قادرًا على معالجة آلاف الطلبات بنفس السرعة والجدية التي يتعامل بها مع طلب واحد فقط. ومع ذلك، فإن هذا المنطق لا تدعمه التجربة الواقعية. يعمل اختبار التحميل على معرفة إذا ما كانت الأنظمة قادرة على التعامل مع الأحمال القصوى وكذلك الارتفاعات الشديدة لأعباء العمل.
شكل آخر من الاختبارات غير الوظيفية يركِّز بشكل خاص على الأداء. لضمان الأداء الفعَّال، يجب أن يستجيب النظام للطلبات بطريقة سلسة وسريعة. تعمل خطة الاختبار في اختبار الأداء على تقييم المدة التي يتعين على المستخدمين انتظارها حتى تتم معالجة طلباتهم. عند إنشائها بعناية، يمكن لاختبارات الأداء أن تساعد على تقليل زمن الوصول في وقت مبكر.
نظرًا لأهمية أمن البيانات، ليس من المستغرب أن يكون هناك نوع من الاختبارات مخصص لهذا الهدف الحديث بصورة خاصة. تساعد منهجيات اختبار الأمن مثل اختبار أمن التطبيقات الديناميكي (DAST) واختبار أمن التطبيقات الثابت (SAST) المختبِرين على اكتشاف الثغرات الأمنية. يتم اختيار أساليب اختبار الأمن في الشركة بناءً على التهديدات المحتملة.
نوع اختبار غير وظيفي يركِّز بالكامل على جودة تجربة المستخدم (UX). يُعَد اختبار قابلية الاستخدام عملية اختبار يدوية من الأفضل استخدامها على نطاق صغير. ومع ذلك، ينبغي تطبيقه كلما أمكن ذلك - وخاصةً عند تنفيذ خطوات مثل توطين التطبيقات، والتي يمكن أن تكون محفوفة بالمخاطر عند إدخال التعقيدات التي يمكن أن تؤدي إلى خطأ بشري.
إن الحفاظ على تتبُّع دقيق لجميع أدوات الاختبار الوظيفية المختلفة قد يتطلب بعض العمل نظرًا لأن معظمها يدعم منصات وأنواعًا مختلفة من التطبيقات. وعلى الرغم من عدم وجود طريقة لمواكبة هذا السوق المزدهر -حيث تصل التقديرات بسهولة إلى إنتاج المئات وربما حتى الآلاف من أدوات الاختبار الوظيفي- فإليك مجموعة من الأدوات التي تتميز بشعبيتها المثبتة وفائدتها المُعترف بها.
خدمة مُدارة بالكامل ومستأجر واحد لتطوير تطبيقات Java وتسليمها.
استخدم أدوات وبرمجيات عمليات التطوير لإنشاء تطبيقات السحابة الأصلية ونشرها وإدارتها عبر أجهزة وبيئات متعددة.
إن تطوير تطبيقات السحابة يعني البناء مرة واحدة، والتكرار بسرعة، والنشر في أي مكان.