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

بادئ ذي بدء ، دعونا نقسم جميع الاختبارات حسب درجة الأتمتة من أجل مزيد من فحص كل نوع بمزيد من التفاصيل.

وفقًا لدرجة الأتمتة ، تنقسم الاختبارات إلى:

1. ترويض.
2. مؤتمتة.
3. تلقائي (بدون تدخل بشري ، في الوقت الحالي - بدلاً من أسطورة عن الواقع).

يعتمد نهج تحسين الاختبارات بشكل مباشر على درجة الأتمتة.

التحسينات المطبقة على جميع أنواع الاختبارات

يشمل الاختبار خطوات:

• إعداد نظام الاختبار
• إعداد بيانات المدخلات
• الاختبار (يدويًا أو تلقائيًا ، سننظر أدناه) ،
• جمع وتحليل النتائج.

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

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

المشاكل:

1. التحضير الطويل لنظام الاختبار

الأسئلة المهمة التي يجب طرحها قبل تنفيذ التحسينات:

• طويلة بشأن ماذا؟
• من يشارك في هذا التدريب (المختبرون ، المبرمجون ...)؟
• كم مرة يمكنك إعداد نظام اختبار خلال يوم عمل؟ هل هذا الرقم مناسب لاحتياجات الاختبار؟
• ما هي أطول مرحلة في التحضير ولماذا؟

للعثور على سبب هذه المشكلة ، من المهم طرح السؤال الصحيح.
خذ بعين الاعتبار الأمثلة التالية:

تجميع طويل لجميع وحدات النظام
السؤال الصحيح هو : هل جميع الوحدات تحتاج إلى تجميع؟
الحل : تجميع ليس جميع وحدات النظام ، ولكن فقط تلك التي تأثرت في المهمة ، والتي ستشارك في الإصدار.

العملية اليدوية الطويلة لتحديث النظام بأكمله لـ "أجهزة افتراضية" مختلفة على منصة الاختبار
السؤال الصحيح هو : في أي نقطة في التحديث مطلوب مشاركة الإنسان ، وفي أي نقطة؟
الحل : أتمتة عملية الحساب ، واستخدام أدوات النشر والتدوير الخاصة بالخدمة أو آليات التحرير المصححة "للقتال" ، ولكن استخدمها فقط للنشر في اختبار واحد.

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

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

2. جمع وتحليل النتائج الطويلة

الأسئلة المهمة التي يجب طرحها قبل تنفيذ التحسينات:

• طويلة بشأن ماذا؟
• ما هي مراحل عملية جمع النتائج وتحليلها؟ ما هي المرحلة الأطول ولماذا؟
• من يحلل النتائج؟
• من يقرر الإفراج وعلى أي أساس؟ كم من الوقت يستغرق لاتخاذ قرار؟

على سبيل المثال :
يتم إصدار نتائج الاختبار وفقًا للقالب ، ويستغرق التسجيل وفقًا للقالب معظم الوقت أثناء الاختبار.

الحل (شكرا ، Cap!) : رفض ملء نتائج القالب أو إنشاء قالب أسهل لملئه. سيكون من الضروري التوصل إلى اتفاق مع الفريق ومعرفة من يقرأ هذه النتائج (وهل يقرؤها؟) ، هل هناك حاجة فعلاً لمثل هذا النموذج (الخطر هو كتابة نتائج الاختبار "على الطاولة").

التحسينات المطبقة على الاختبارات اليدوية

يمكن تقسيم هذه الاختبارات إلى فئتين كبيرتين:

1. تجرى بانتظام ، على سبيل المثال ، قبل الإصدار (خذ بعين الاعتبار اختبار الانحدار) ،
2. أجريت نادرا وفقط لاختبار وظائف جديدة.

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

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

للاختبار اليدوي ، أولاً وقبل كل شيء ، تحتاج إلى البحث عن المهام الروتينية (المهام ، وليس الاختبارات!) ، وتحسينها بالفعل (باستخدام الأتمتة أو إعادة توزيع الموارد البشرية).

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

1. يدويًا من خلال واجهة المستخدم ،
2. يدويًا من خلال واجهة برمجة التطبيقات ،
3. من خلال تشغيل الاختبارات التلقائية ، ستكون البيانات أثرًا جانبيًا لهذه الاختبارات ،
4. مؤتمتة من خلال البرامج النصية / المرافق / أدوات مخصصة عبر واجهة برمجة التطبيقات أو واجهة المستخدم.

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

التحسينات المطبقة على الاختبارات الآلية

مشكلة إعداد بيانات الاختبار هنا أكثر حدة من الاختبار اليدوي. يجب أن يكون إعداد بيانات الاختبار:

1. سريع
2. مقاومة لتغييرات التصميم / التخطيط ،
3. مقاومة لعمليات الاختبار المتوازية المحتملة ،
4. مقاومة للتغيرات في البنية الداخلية للنظام.

من المستحسن أن إعداد البيانات لا يتطلب مهارات ووقتًا إضافيًا في تنفيذ الحل.

يمكن تحضير بيانات الاختبار تلقائيًا:

1. من خلال واجهة المستخدم ،
2. عبر طلبات API أو HTTP ،
3. من خلال استعلامات قاعدة البيانات.

فكر في إيجابيات وسلبيات هذه الأساليب بمزيد من التفصيل في الجدول:

يعد إعداد بيانات الاختبار عبر طلبات API أو HTTP لمجموعة من الإيجابيات والسلبيات هو الأمثل.

هناك عدد من التحسينات الأكثر شيوعًا التي تنطبق على الاختبارات التلقائية:

اختبار التوازي

إذا كانت إحدى مشكلات الاختبارات هي بالضبط وقت اجتيازها ، بينما توجد موارد حسابية ، يمكنك موازنتها وتنفيذها في أحد الأوضاع الثلاثة المتوازية:

1. التوازي على جهاز كمبيوتر واحد ، والتوازي على خيوط المعالج.
2. التوازي على أجهزة الكمبيوتر المختلفة.
3. مزيج من الطريقتين الأولى والثانية ، أي إذا كان هناك العديد من أجهزة الكمبيوتر ، فإن الاختبارات تمر بالتوازي على طول التدفقات على كل جهاز وبالتوازي بين جميع الآلات.

إزالة الاختبارات القديمة

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

استخدام تقنيات تصميم الاختبار لتحسين مجموعات حالات الاختبار

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

نقل الاختبارات والتحقق الحالية إلى مستوى آخر

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

التحلل الصحيح للاختبارات على مستويات "نمطي - تكامل - نظام"

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

سيكون من الصحيح في هذه الحالة تقسيم الاختبار أولاً إلى ثلاثة سيناريوهات فرعية: اختيار منتج وإضافة منتج إلى السلة وتقديم طلب. سنقسم كل سيناريو إلى فحوص ذرية أكثر.
على سبيل المثال: "فتح متجر - عرض فئات مختلفة من السلع للاختيار" - اختبار واحد ؛ اختبار آخر "اختيار فئة من فئات المنتجات المختلفة". نحن نفحص كل اختبار بمزيد من التفصيل ونحدد مستوى الاختبارات اللازمة له ، يمكن للمثال السابق معرفة أي نوع من الاختبارات من الأفضل تصميمه فورًا على أنه اختبارات وحدة.

مخطط اتصال شائع لأنظمة الاختبار والاختبار للاختبار الآلي لتطبيقات الويب:

لتحسين الاختبار الآلي لتطبيق ويب ، يُنصح بالنظر في تحسين كل تفاعل في المخطط الموصوف.

من أجل البساطة ، فكر في تحسين بعض التفاعلات:

1) التفاعل "حالات الاختبار - المتصفح - قاعدة البيانات"
استخدام API ليس فقط لإعداد البيانات للاختبار ، ولكن أيضًا لاتخاذ عدد من الخطوات في الاختبار.

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

2) التفاعل "حالات الاختبار - SeleniumWebDriver - المتصفح".

• إغلاق علامات التبويب الإضافية عند الانتهاء من الاختبار ، بدلاً من إغلاق المتصفح.
  في مشروعي ، ساعد هذا التحسين على توفير 10 دقائق في تشغيل اختبارات واجهة المستخدم (بدلاً من ساعة واحدة و 10 دقائق ، بدأت الاختبارات تمر خلال ساعة واحدة). يرتبط هذا التحسين بمنطق SeleniumWebDriver ، المستخدم في المشروع - لديه إعداد طويل جدًا لفتح متصفح ، ولكن إغلاق علامات التبويب يحدث على الفور تقريبًا.
• تحسين ذاكرة التخزين المؤقت للتطبيق للنظام قيد الاختبار ، بحيث تمر الاختبارات بشكل أسرع.
• استخدام متصفحات بدون رأس بحيث لا تكون هناك تكلفة في عرض عناصر صفحة الويب.

في الختام

لأي تحسين ، تحتاج إلى تحديد المشاكل الحالية في عملية الاختبار بوضوح ، والتوسع في النقاط الموجودة فيها ، وتقديم الخيارات الممكنة (العديد من أفضل!) لحلها. بعد ذلك ، يُطلب منهم التعبير عنهم في فريق ، و "بيع" أفكارهم واقتراحاتهم للحل ، وفقط بعد الموافقة العالمية على توزيع الجهود وحل المهام. سيساعد التقييم الأولي لـ "قبل" وتقييم "بعد" على النظر في جميع المكاسب الناتجة عن تحسين العمليات.

ومرة أخرى ، أود أن أكرر: لا تبحث عن الاختبارات الروتينية ، ابحث عن المهام الروتينية ، وأتمتتها تلقائيًا!

قائمة مقالات التقويم:
جرب طريقة مختلفة
اختبار زوج معقول
ملاحظات: كيف يحدث ذلك
تحسين الاختبارات
اقرأ كتابًا
اختبار التحليلات
يجب على المختبر الإمساك بالخلل وقراءة Caner وتنظيم الحركة.
خدمة التحميل
مقاييس خدمة ضمان الجودة
اختبار الأمان
تعرف على عميلك
خذ تراكم