ما هو الاختبار الوظيفي؟
في هذا القسم، يمكنك الانضمام إلى فريق Tailspin أثناء تحديد الاختبارات الوظيفية للبنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بهم. تتحقق الاختبارات الوظيفية مما إذا كانت كل وظيفة من وظائف البرنامج تقوم بما ينبغي لها القيام به.
يحدد الفريق أولا ما يغطيه الاختبار الوظيفي. يستكشفون بعض أنواع الاختبارات الوظيفية. ثم يقررون في الاختبار الأول لإضافته إلى البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بهم.
اجتماع أسبوعي
ويعقد الفريق اجتماعه الأسبوعي. يظهر أندي البنية الأساسية لبرنامج ربط العمليات التجارية للإصدار. يشاهد الفريق حركة بناء ناجحة عبر البنية الأساسية لبرنامج ربط العمليات التجارية، من مرحلة إلى أخرى. وأخيرا، يتم ترقية تطبيق الويب إلى التقسيم المرحلي.
أميتا: أنا سعيد جدا بالبنية الأساسية لبرنامج ربط العمليات التجارية. هذا يجعل حياتي أسهل بكثير لشيء واحد، أحصل تلقائيا على إصدار تم نشره في بيئة الاختبار . وهذا يعني أنني لست مضطرا إلى تنزيل وتثبيت البيانات الاصطناعية للبناء يدويا على خوادم الاختبار الخاصة بي. هذا توفير كبير للوقت.
أيضا، اختبارات الوحدة التي كتبها مارا وأندي تقضي على جميع أخطاء الانحدار قبل أن أحصل على الإصدار. وهذا يزيل مصدرا رئيسيا للاحباط. لا أقضي وقتا في العثور على أخطاء التراجع وتوثيقها.
لكنني قلقة من أن كل اختباراتي لا تزال يدوية. العملية بطيئة، ولا يمكننا إظهار أي شيء للإدارة حتى أنتهي. من الصعب أن يكون الاختبار مهما. يضمن الاختبار حصول المستخدمين على التجربة الصحيحة. ولكن الضغط مستمر للتسليم بشكل أسرع.
أندي: أنا متأكد من أننا نستطيع مساعدتك. ما نوع الاختبارات التي تستغرق معظم وقتك؟
أميتا: أعتقد أن اختبارات واجهة المستخدم تفعل ذلك. يجب أن أنقر خلال كل خطوة للتأكد من الحصول على النتيجة الصحيحة، ويتعين علي القيام بذلك لكل متصفح ندعمه. انها تستغرق وقتا طويلا جدا. ومع تزايد تعقيد موقع الويب، لن يكون اختبار واجهة المستخدم عمليا على المدى الطويل.
مارا: تعتبر اختبارات واجهة المستخدم اختبارات وظيفية .
تيم: على عكس ماذا، الاختبارات غير الوظيفية ؟
مارا: بالضبط. والاختبارات غير الوظيفية هي شيء تهتم به على وجه الخصوص.
تيم: حسنا، أنا مرتبك.
ما هي الاختبارات الوظيفية وغير الوظيفية؟
Mara:Functional tests تتحقق من أن كل وظيفة من وظائف البرنامج تقوم بما ينبغي لها القيام به. كيف ينفذ البرنامج كل وظيفة ليست مهمة في هذه الاختبارات. المهم هو أن البرنامج يتصرف بشكل صحيح. يمكنك توفير الإدخال والتحقق من أن الإخراج هو ما تتوقعه. هذه هي الطريقة التي تختبر بها أميتا واجهة المستخدم. على سبيل المثال، إذا حددت اللاعب الأعلى في لوحة المتصدرين، فإنها تتوقع رؤية ملف تعريف هذا اللاعب.
تتحقق الاختبارات غير الوظيفية من خصائص مثل الأداء والموثوقية. مثال على الاختبار غير الوظيفي هو التحقق من عدد الأشخاص الذين يمكنهم تسجيل الدخول إلى التطبيق في وقت واحد. اختبار التحميل هو مثال آخر على اختبار غير وظيفي. مخاوف الأداء والموثوقية هذه هي الأشياء التي تهتم بها، تيم.
تيم: إنهم بالفعل. يجب أن أفكر في هذا قليلا. قد أرغب في إضافة بعض الأتمتة إلى البنية الأساسية لبرنامج ربط العمليات التجارية أيضا، لكنني لست متأكدا مما أريد القيام به. ما أنواع الاختبارات التلقائية التي يمكنني تشغيلها؟
مارا: في الوقت الحالي، دعونا نركز على الاختبار الوظيفي. إنه نوع الاختبار الذي تقوم به أميتا. وهو يبدو كمنطقة نريد أن نتحسن فيها.
ما هي أنواع الاختبارات الوظيفية التي يمكنني تشغيلها؟
هناك العديد من أنواع الاختبارات الوظيفية. وهي تختلف حسب الوظيفة التي تحتاج إلى اختبارها والوقت أو الجهد الذي تتطلبه عادة للتشغيل.
تقدم الأقسام التالية بعض الاختبارات الوظيفية شائعة الاستخدام.
اختبار الدخان
يتحقق اختبار الدخان من الوظائف الأساسية للتطبيق أو الخدمة. غالبا ما يتم تشغيل هذه الاختبارات قبل اختبارات أكثر اكتمالا وشمولا. يجب إجراء اختبارات الدخان بسرعة.
على سبيل المثال، لنفترض أنك تقوم بتطوير موقع ويب. قد يستخدم curl اختبار الدخان للتحقق من إمكانية الوصول إلى الموقع ومن أن إحضار الصفحة الرئيسية ينتج حالة HTTP 200 (OK). إذا كان إحضار الصفحة الرئيسية ينتج عنه رمز حالة آخر، مثل 404 (غير موجود) أو 500 (خطأ داخلي في الخادم)، فأنت تعلم أن موقع الويب لا يعمل. أنت تعرف أيضا أنه لا يوجد سبب لإجراء اختبارات أخرى. بدلا من ذلك، تقوم بتشخيص الخطأ وإصلاحه وإعادة تشغيل الاختبارات.
اختبار الوحدة
لقد عملت مع اختبارات الوحدة في الوحدة النمطية تشغيل اختبارات الجودة في البنية الأساسية لبرنامج ربط العمليات التجارية للبناء باستخدام Azure Pipelines .
باختصار، يتحقق اختبار الوحدة من المكونات الأساسية لبرنامجك أو مكتبتك، مثل وظيفة فردية أو أسلوب. يمكنك تحديد إدخال واحد أو أكثر مع النتائج المتوقعة. يقوم مشغل الاختبار بإجراء كل اختبار ويتحقق لمعرفة ما إذا كانت النتائج الفعلية تطابق النتائج المتوقعة.
على سبيل المثال، لنفترض أن لديك دالة تقوم بإجراء عملية حسابية تتضمن القسمة. قد تحدد بعض القيم التي تتوقع من المستخدمين إدخالها. يمكنك أيضا تحديد قيم حالة الحافة مثل 0 و-1. إذا كنت تتوقع إدخالا معينا لإنتاج خطأ أو استثناء، يمكنك التحقق من أن الدالة تنتج هذا الخطأ.
اختبارات واجهة المستخدم التي ستقوم بتشغيلها لاحقا في هذه الوحدة النمطية هي اختبارات الوحدة.
اختبارات التكامل
يتحقق اختبار التكامل من أن مكونات برامج متعددة تعمل معا لتشكيل نظام كامل. على سبيل المثال، قد يتضمن نظام التجارة الإلكترونية موقع ويب وقاعدة بيانات للمنتجات ونظام دفع. يمكنك كتابة اختبار تكامل يضيف عناصر إلى عربة التسوق ثم يشتري العناصر. يتحقق الاختبار من أن تطبيق الويب يمكنه الاتصال بقاعدة بيانات المنتجات ثم تنفيذ الطلب.
يمكنك الجمع بين اختبارات الوحدة واختبارات التكامل لإنشاء استراتيجية اختبار الطبقات. على سبيل المثال، قد تقوم بتشغيل اختبارات الوحدة على كل مكون من مكوناتك قبل تشغيل اختبارات التكامل. إذا اجتزت جميع اختبارات الوحدة، يمكنك الانتقال إلى اختبارات التكامل بثقة أكبر.
اختبار التراجع
يحدث الانحدار عندما يتغير السلوك الحالي أو ينقطع بعد إضافة ميزة أو تغييرها. يساعد اختبار الانحدار في تحديد ما إذا كانت التعليمات البرمجية أو التكوين أو التغييرات الأخرى تؤثر على السلوك العام للبرنامج.
يعد اختبار الانحدار مهما لأن التغيير في أحد المكونات يمكن أن يؤثر على سلوك مكون آخر. على سبيل المثال، لنفترض أنك قمت بتحسين قاعدة بيانات لأداء الكتابة. قد ينخفض أداء القراءة لقاعدة البيانات هذه، التي تتم معالجتها بواسطة مكون آخر، بشكل غير متوقع. الانخفاض في أداء القراءة هو تراجع.
يمكنك استخدام استراتيجيات مختلفة لاختبار التراجع. تختلف هذه الاستراتيجيات عادة حسب عدد الاختبارات التي تقوم بتشغيلها للتحقق من أن ميزة جديدة أو إصلاح الأخطاء لا يكسر الوظائف الموجودة. ومع ذلك، عند أتمتة الاختبارات، قد يتضمن اختبار الانحدار تشغيل جميع اختبارات الوحدة واختبارات التكامل في كل مرة يتغير فيها البرنامج.
اختبار السلامة
يتضمن اختبار السلامة اختبار كل مكون رئيسي من جزء من البرنامج للتحقق من أن البرنامج يبدو أنه يعمل ويمكن أن يخضع لاختبار أكثر شمولا. يمكنك التفكير في اختبارات السلامة على أنها أقل دقة من اختبارات الانحدار أو اختبارات الوحدة، ولكن اختبارات السلامة أوسع من اختبارات الدخان.
على الرغم من أن اختبار السلامة يمكن أن يكون تلقائيا، فإنه غالبا ما يتم يدويا استجابة لتغيير الميزة أو إصلاح الأخطاء. على سبيل المثال، قد يتحقق مختبر البرامج الذي يتحقق من صحة إصلاح الأخطاء أيضا من أن الميزات الأخرى تعمل عن طريق إدخال بعض القيم النموذجية. إذا بدا أن البرنامج يعمل كما هو متوقع، فيمكنه بعد ذلك المرور بتمرير اختبار أكثر شمولا.
اختبار واجهة المستخدم
يتحقق اختبار واجهة المستخدم (UI) من سلوك واجهة مستخدم التطبيق. تساعد اختبارات واجهة المستخدم في التحقق من أن تسلسل تفاعلات المستخدم أو ترتيبها يؤدي إلى النتيجة المتوقعة. تساعد هذه الاختبارات أيضا في التحقق من أن أجهزة الإدخال، مثل لوحة المفاتيح أو الماوس، تؤثر على واجهة المستخدم بشكل صحيح. يمكنك تشغيل اختبارات واجهة المستخدم للتحقق من سلوك تطبيق Windows أو macOS أو Linux الأصلي. أو يمكنك استخدام اختبارات واجهة المستخدم للتحقق من أن واجهة المستخدم تتصرف كما هو متوقع عبر مستعرضات الويب.
قد يتحقق اختبار الوحدة أو اختبار التكامل من أن واجهة المستخدم تتلقى البيانات بشكل صحيح. ولكن يساعد اختبار واجهة المستخدم في التحقق من أن واجهة المستخدم تظهر بشكل صحيح وأن النتيجة تعمل كما هو متوقع للمستخدم.
على سبيل المثال، قد يتحقق اختبار واجهة المستخدم من ظهور الحركة الصحيحة استجابة لنقرة زر. قد يتحقق الاختبار الثاني من ظهور نفس الحركة بشكل صحيح عند تغيير حجم النافذة.
في هذه الوحدة النمطية، يمكنك العمل مع اختبارات واجهة المستخدم التي يتم ترميزها يدويا. ولكن يمكنك أيضا استخدام نظام الالتقاط وإعادة التشغيل لإنشاء اختبارات واجهة المستخدم تلقائيا.
اختبار قابلية الاستخدام
اختبار قابلية الاستخدام هو شكل من أشكال الاختبار اليدوي الذي يتحقق من سلوك التطبيق من منظور المستخدم. عادة ما يتم اختبار قابلية الاستخدام من قبل الفريق الذي يبني البرنامج.
بينما يركز اختبار واجهة المستخدم على ما إذا كانت الميزة تتصرف كما هو متوقع، يساعد اختبار قابلية الاستخدام على التحقق من أن البرنامج بديهي ويلبي احتياجات المستخدم. وبعبارة أخرى، يساعد اختبار قابلية الاستخدام على التحقق مما إذا كان البرنامج "قابلا للاستخدام".
على سبيل المثال، لنفترض أن لديك موقع ويب يتضمن ارتباطا إلى ملف تعريف المستخدم. يمكن لاختبار واجهة المستخدم التحقق من وجود الارتباط وأنه يعرض ملف تعريف المستخدم عند النقر فوق الارتباط. ومع ذلك، إذا لم يتمكن البشر من تحديد موقع هذا الارتباط بسهولة، فقد يشعرون بالإحباط عندما يحاولون الوصول إلى ملف التعريف الخاص بهم.
اختبار قبول المستخدم
يركز اختبار قبول المستخدم (UAT)، مثل اختبار قابلية الاستخدام، على سلوك التطبيق من منظور المستخدم. على عكس اختبار قابلية الاستخدام، عادة ما يتم إجراء UAT من قبل المستخدمين النهائيين الحقيقيين.
اعتمادا على البرنامج، قد يطلب من المستخدمين إكمال مهام محددة. أو قد يسمح لهم باستكشاف البرنامج دون اتباع إرشادات محددة. بالنسبة للبرامج المخصصة، يحدث UAT عادة مباشرة مع العميل. لمزيد من البرامج ذات الأغراض العامة، قد تقوم الفرق بإجراء اختبارات بيتا . في اختبارات بيتا، يحصل المستخدمون من مناطق جغرافية مختلفة أو أولئك الذين لديهم اهتمامات خاصة على إمكانية الوصول المبكر إلى البرنامج.
يمكن أن تكون الملاحظات من المختبرين مباشرة أو غير مباشرة. قد تأتي التعليقات المباشرة في شكل تعليقات شفهية. يمكن أن تأتي التعليقات غير المباشرة في شكل قياس لغة جسم المختبرين أو حركات العين أو الوقت الذي يستغرقونه لإكمال مهام معينة.
لقد قمنا بالفعل بتغطية أهمية كتابة الاختبارات. ولكن فقط للتأكيد على ذلك، إليك مقطع فيديو قصير يشرح فيه هابيل وانغ، مساعد السحابة لدى Microsoft، كيفية المساعدة في ضمان الجودة في خطة DevOps الخاصة بك.
اسأل هابيل
ما الذي يختاره الفريق؟
تيم: تبدو كل هذه الاختبارات مهمة. ما الذي يجب أن نعالجه أولا؟
أندي: لدينا بالفعل اختبارات وحدة العمل. لسنا مستعدين بعد لإجراء اختبار قبول المستخدم. بناء على ما أسمعه، أعتقد أنه يجب علينا التركيز على اختبار واجهة المستخدم. الآن، إنه أبطأ جزء من عمليتنا. أميتا، هل توافق؟
أميتا: نعم، أنا أوافق. لا يزال لدينا بعض الوقت المتبقي في هذا الاجتماع. أندي أو مارا، هل تريد مساعدتي في التخطيط لاختبار واجهة مستخدم تلقائي؟
مارا: بالتأكيد. لكن لنخرج بعض التصفيات من الطريق أود مناقشة الأداة التي يجب أن نستخدمها وكيف سنجري الاختبارات.
ما هي الأدوات التي يمكنني استخدامها لكتابة اختبارات واجهة المستخدم؟
مارا: عندما يتعلق الأمر بكتابة اختبارات واجهة المستخدم، ما هي خياراتنا؟ أعرف أن هناك الكثير. بعض الأدوات مصدر مفتوح. ويقدم آخرون دعما تجاريا مدفوعا. فيما يلي بعض الخيارات التي تتبادر إلى الذهن:
- برنامج تشغيل تطبيق Windows (WinAppDriver): يساعدك WinAppDriver على أتمتة اختبارات واجهة المستخدم على تطبيقات Windows. يمكن كتابة هذه التطبيقات في النظام الأساسي العام لـ Windows (UWP) أو Windows Forms (WinForms). نحن بحاجة إلى حل يعمل في المتصفح.
- Selenium: Selenium هو إطار عمل محمول لاختبار البرامج مفتوح المصدر لتطبيقات الويب. يعمل على معظم أنظمة التشغيل، ويدعم جميع المتصفحات الحديثة. يمكنك كتابة اختبارات Selenium بعدة لغات برمجة، بما في ذلك C#. في الواقع، يمكنك استخدام حزم NuGet التي تسهل تشغيل Selenium كاختبارات NUnit. نحن نستخدم NUnit بالفعل لاختبارات الوحدة الخاصة بنا.
- SpecFlow: SpecFlow هو لمشاريع .NET. وهو مستوحى من أداة تسمى Cucumber. يدعم كل من SpecFlow والخيار التطوير المستند إلى السلوك (BDD). يستخدم BDD محللا للغة الطبيعية يسمى Gherkin لمساعدة كل من الفرق التقنية والفرق غير التقنية على تحديد قواعد ومتطلبات الأعمال. يمكنك الجمع بين SpecFlow أو Cucumber مع Selenium لإنشاء اختبارات واجهة المستخدم.
أندي ينظر إلى أميتا.
أندي: أعرف أن هذه الخيارات جديدة عليك، لذا هل تمانع إذا اخترنا سيلينيوم؟ لدي بعض الخبرة في ذلك، وهو يدعم اللغات التي أعرفها بالفعل. سيعطينا Selenium أيضا دعما تلقائيا لمتصفحات متعددة.
أميتا: بالتأكيد. من الأفضل أن يكون لدى أحدنا بعض الخبرة.
كيف أعمل تشغيل الاختبارات الوظيفية في البنية الأساسية لبرنامج ربط العمليات التجارية؟
في Azure Pipelines، تقوم بإجراء اختبارات وظيفية تماما كما تقوم بتشغيل أي عملية أو اختبار آخر. سأل نفسك:
- في أي مرحلة سيتم تشغيل الاختبارات؟
- على أي نظام سيتم تشغيل الاختبارات؟ هل سيتم تشغيلها على العامل أو على البنية الأساسية التي تستضيف التطبيق؟
دعونا ننضم إلى الفريق وهم يجيبون على هذه الأسئلة.
مارا: الشيء الوحيد الذي أتحمس له هو أنه يمكننا الآن الاختبار في بيئة تشبه الإنتاج، حيث يتم تشغيل التطبيق بالفعل. الاختبارات الوظيفية مثل اختبارات واجهة المستخدم منطقية في هذا السياق. يمكننا تشغيلها في مرحلة الاختبار للبنية الأساسية لبرنامج ربط العمليات التجارية لدينا.
أميتا: أوافق. يمكننا الحفاظ على نفس سير العمل إذا قمنا بإجراء اختبارات واجهة المستخدم التلقائية في نفس المرحلة التي أقوم فيها بإجراء الاختبارات اليدوية. ستوفر لنا الاختبارات التلقائية الوقت وتمكنني من التركيز على قابلية الاستخدام.
تيم: تختبر أميتا موقع الويب من كمبيوترها المحمول الذي يعمل بنظام Windows لأن هذه هي الطريقة التي يزور بها معظم مستخدمينا الموقع. ولكننا نبني على Linux ثم نشر Azure App Service على Linux. كيف نتعامل مع ذلك؟
مارا: سؤال رائع. لدينا أيضا خيار حول مكان إجراء الاختبارات. يمكننا تشغيلها:
- على العامل: إما عامل Microsoft أو وكيل نستضيفه
- على البنية الأساسية للاختبار: إما في الموقع أو في السحابة
تتضمن مرحلة الاختبار الحالية وظيفة واحدة. تنشر هذه المهمة موقع الويب إلى App Service من وكيل Linux. يمكننا إضافة مهمة ثانية تقوم بتشغيل اختبارات واجهة المستخدم من عامل Windows. تم إعداد عامل Windows الذي تستضيفه Microsoft بالفعل لتشغيل اختبارات Selenium.
أندي: مرة أخرى، دعونا نتمسك بما نعرفه. لنستخدم عامل Windows المستضاف من Microsoft. في وقت لاحق، يمكننا إجراء نفس الاختبارات من العوامل التي تقوم بتشغيل macOS وLinux إذا كنا بحاجة إلى تغطية اختبار إضافية.
الخطة
مارا: موافق. إليك ما سنفعله:
- تشغيل اختبارات Selenium UI من عامل Windows مستضاف من Microsoft
- اجلب الاختبارات محتوى الويب من التطبيق الذي يعمل على App Service، في مرحلة الاختبار
- تشغيل الاختبارات على جميع المتصفحات التي ندعمها
أندي: سأعمل مع أميتا على هذا. أميتا، دعونا نلتقي صباح الغد. أود إجراء القليل من البحث قبل أن نلتقي.
أميتا: رائع! أراك بعد ذلك.
إنشاء خطة اختبار وظيفية
لقد رأينا الفريق يقرر كيفية تنفيذ اختباراته الوظيفية الأولى. إذا بدأ فريقك للتو في دمج الاختبارات الوظيفية في البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بهم (أو حتى إذا كنت تفعل ذلك بالفعل)، فتذكر أنك تحتاج دائما إلى خطة.
في كثير من الأحيان، عندما يسأل شخص ما أعضاء الفريق عن خطة اختبار الأداء الخاصة بهم، فمن الشائع بالنسبة لهم الاستجابة بقائمة من الأدوات التي سيستخدمونها. ومع ذلك، فإن قائمة الأدوات ليست خطة. يجب عليك أيضا معرفة كيفية تكوين بيئات الاختبار. تحتاج إلى تحديد العمليات التي يجب استخدامها، وتحديد شكل النجاح أو الفشل.
تأكد من أن خطتك:
- يأخذ توقعات العمل في الاعتبار.
- يأخذ توقعات المستخدمين المستهدفين في الاعتبار.
- يحدد المقاييس التي ستستخدمها.
- تعريف مؤشرات الأداء الرئيسية التي ستستخدمها.
يجب أن يكون اختبار الأداء جزءا من التخطيط الخاص بك، مباشرة من البداية. إذا كنت تستخدم قصة أو لوحة كانبان، فقد تفكر في وجود منطقة قريبة منها حيث يمكنك التخطيط لاستراتيجية الاختبار الخاصة بك. وكجزء من تخطيط التكرار، ينبغي إبراز الثغرات في استراتيجية الاختبار. من المهم أيضا معرفة كيفية مراقبة الأداء بمجرد نشر التطبيق، وليس فقط قياس الأداء قبل إصداره.