اختبار الأتمتة من الصفر. الجزء الأول

مساء الخير أيها القراء الأعزاء.

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

آمل أن تكون المقالة مفيدة للمبتدئين autotests.

• في الجزء الأول ، نفضل النهج العام.
• في الجزء الثاني ( الجزء الأول ) مع أمثلة سنقوم بعمل مشروع اختبارات ذاتية على JAVA + لتعليم كيفية اختبار API بسرعة.
• في الجزء الثالث ، سنكمل مشروع اختبار واجهة المستخدم ، وسنقوم باختبارات متوازية.

متى تفعل الاختبارات الذاتية؟

الجواب القصير في أقرب وقت ممكن.

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

لماذا؟

لأن autotets:

1. تراكم سيناريوهات الانحدار
2. غير متحيز
3. سريع

السيناريوهات المتراكمة

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

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

الحياد

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

السرعة

إذا استوفى كل اختبار الشروط المملة:

الشرط المسبق - الاختبار - الحالة اللاحقة
من السهل أتمتة هذه الاختبارات.

ثم من السهل موازاة ذلك. لأنهم مستقلون.

عدد سلاسل العمليات - عدد خوادم الاختبار التي يمكن أن تتحملها حتى لا تزعج الآخرين.

النقطة الثانية هي السرعة نفسها. في الوضع اليدوي ، انقر على إنشاء المنتج ، والبحث عنه وشرائه في المتجر عبر الإنترنت هو 5 دقائق. 4 متصفحات. المجموع 20 دقيقة. في سيناريو صغير واحد فقط.

يستغرق الاختبار التلقائي في هذا السيناريو 1.5 دقيقة. ولكن في 8 متصفحات. (أحدث الإصدارات وما قبل الأخيرة من كل متصفح).

من أين تبدأ؟

مع البرمجة النصية المخصصة.

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

يجب أن يعمل ضمان الجودة من قصة المستخدم. لأن المبرمج عادة لا يعرفها ولا يريد أن يعرفها.

وبناء على ذلك ، فإن اختبار المنطق 1 - حالة المستخدم 1 (سيناريو الأعمال) هو الأقرب إلى الواقع.

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

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

ما البرامج النصية لأتمتة

أقل عرضة للتغيير على المدى القصير. لأتمتة على الأقل عاش البعض.

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

ماذا تفعل بالضبط؟

عادة في المشاريع هناك

• الخلفية
• الواجهة الأمامية
• تطبيقات الموبايل
• الغدد

والنقطتان الأخيرتان - عادةً ما تعيشان بشكل منفصل. يتم اختبار الهواتف المحمولة على نصوصها الخاصة ، والقليلون قادرون على الاقتراب من تصحيح الحديد وفقًا لـ JTAG دون إعداد.

لذلك ، أقترح التعامل مع الخلفية والجبهة.

اختر سيناريو

لنفترض أن لدينا متجرًا عبر الإنترنت.
هناك لوحة إدارة ، وهناك واجهة العميل والمشرف.
هناك API يخدم كل هذا.

من أين تبدأ الأتمتة؟

دعونا مشاهدة.

هناك عملاء ، هناك موظفين.

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

ما الحالة التي سيتم تشغيلها تلقائيًا أولاً؟ وكيف؟

أهم شيء للمخزن هو المبيعات.

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

بواسطة API. لكن بدون جبهة. هنا يمكنك أن تجادل ، ولكن على الأرجح سيتغير التصميم 2-3 مرات أكثر ، ولكن الخلفية غير مرجحة. لذا في المرحلة 1 ، عليك التحقق من الواجهة يدويًا.

بعد ذلك ، تحقق من واجهة برمجة التطبيقات التي تعدل بطاقة المنتج وواجهتها.

والعودة إلى العميل. في هذه المرحلة ، ستكون هناك إحصاءات بالفعل حول إجراءات المستخدم الأكثر تكرارًا ، ومسارات العميل الأكثر تكرارًا. نعم ، يساعد Yandex Metric و Webvisor أيضًا المختبرين.

ليس من المنطقي في المرحلة الأولى التحقق مما إذا كانت وظيفة الدفع لحساب الشركة من خلال نظام الدفع الذي تم إنشاؤه تعمل إذا كان 0.5 ٪ من الزوار يستخدمون هذه الوظيفة. بالطبع ، يمكنك أن تسأل المدير سؤالاً لماذا هذا مطلوب هنا ، ولكن هذا ليس حول ذلك.

لنفترض أن لدينا 40٪ من الأشخاص يدفعون على الموقع ببطاقة و 30٪ نقدًا و 20٪ نقدًا عند التسليم و 10٪ جميع الطرق الأخرى.

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

أي أنه يجب علينا أن نفهم بوضوح أي سيناريو هو الأكثر أهمية للأعمال في الوقت الحالي. ونوعيته في المقام الأول.

الشروط اللاحقة

لقد صنعنا كل شيء ، كل شيء في الاختبارات. القمامة. سيكون من الضروري التنظيف بعد نفسك. من الضروري أن نتنبأ مقدمًا بالاختبارات التي سننظفها بعدنا ، والتي - لا.

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

الشذوذ

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

أي أنه لم يتم تحديث BIC الجديد. لكن البنك الجديد بدأ بشكل طبيعي.

هل يعقل لأتمتة هذا السيناريو؟ إذا تغير المقاولون كل يوم - ربما. ثم كان هناك خلل في التخطيط.

إذا تم ذلك 5-6 مرات في السنة ، فهل من الأفضل القيام بمهمة ذات أولوية أعلى؟

ماذا سيحدث بعد ذلك؟

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

دعني أذكرك بتأثير المبيدات الحشرية وكيفية تلميعها إلى الحد الأدنى.

التقنيات: Java + maven + testng + allure + RestAssured + Pict.