في بعض الحالات تكون تقارير التغطية الحديثة عديمة الفائدة إلى حد ما ، وطرق قياسها مناسبة بشكل أساسي للمطورين فقط. يمكنك دائمًا معرفة النسبة المئوية للتغطية أو عرض الرمز الذي لم يتم استخدامه أثناء الاختبارات ، ولكن ماذا لو كنت تريد الرؤية والبساطة والأتمتة؟
تحت المقطع - فيديو ونسخة من تقرير أعده Artem Eroshenko من برنامج Qameta Software من مؤتمر Heisenbug . قدم العديد من الحلول البسيطة والأنيقة المتقدمة التي تساعد فريق Yandex.Verticals على تقييم تغطية الاختبارات التي كتبها مهندسو أتمتة الاختبار. سيخبرك Artem بكيفية اكتشاف ما يتم تغطيته بسرعة ، وكيف يتم تغطيته ، وما هي الاختبارات التي مرت ، والاطلاع على التقارير المرئية على الفور.اسمي أرتيوم إروشينكو eroshenkoam، كنت أقوم بأتمتة الاختبار لأكثر من 10 سنوات. كنت مديرًا لأتمتة الاختبار ، ومديرًا لفريق تطوير الأدوات ، ومطورًا للأدوات.في الوقت الحالي أنا مستشار في مجال اختبار الأتمتة ، أعمل مع العديد من الشركات التي نبني معها العمليات.أنا أيضًا المطور والمدير السري لـ Allure Report. لقد أصلحنا مؤخرًا شيئًا رائعًا : الآن في JUnit 5 هناك تركيبات.إطار أطلس
تطوري هو إطار أطلس . إذا بدأ شخص ما في الأتمتة في عام 2012 ، عندما كانت برامج تشغيل ويب Java في طريقها للتو ، في تلك اللحظة قمت بإنشاء مكتبة مفتوحة المصدر تسمى HTML Elements .Html Elements لها استمرارية وإعادة التفكير في مكتبة Atlas ، والتي بنيت على واجهات: لا توجد فئات على هذا النحو ، لا توجد حقول ، مكتبة مريحة للغاية وخفيفة الوزن وقابلة للتوسيع بسهولة. إذا كنت ترغب في فهمه ، يمكنك قراءة المقالة أو الاطلاع على التقرير .تقريري مخصص لمشكلة أتمتة الاختبار وبشكل رئيسي للطلاء. كخلفية ، أود أن أشير إلى كيفية تنظيم عمليات الاختبار في Yandex.كيف تعمل الأتمتة في القطاعات؟
لا يوجد سوى أربعة أشخاص في فريق Yandex.Verticals لاختبار الأتمتة الذين يقومون بأتمتة أربع خدمات: Yandex.Avto و Work و Real Estate و Parts. أي أن هذا فريق صغير من الأوتوماتيكيين الذين يقومون بالكثير. نقوم بأتمتة واجهة برمجة التطبيقات وواجهة الويب وتطبيقات الجوال وما إلى ذلك. في المجموع ، لدينا ما يقرب من 15.5 ألف اختبار يتم إجراؤه على مستويات مختلفة.تبلغ نسبة استقرار الاختبارات في الفريق حوالي 97٪ ، على الرغم من أن بعض زملائي يقولون حوالي 99٪. يتم تحقيق هذا الاستقرار العالي على وجه التحديد بفضل الاختبارات القصيرة على التقنيات المحلية للغاية. كقاعدة ، تستغرق اختباراتنا حوالي 15 دقيقة ، وهي قوية للغاية ، ونجريها في حوالي 800 خيط. وهذا يعني أن لدينا 800 متصفحًا تبدأ في نفس الوقت - مثل اختبار الضغط في اختبارنا. كحديد نستخدم الملف اللولبي (Aerokube). يمكنك معرفة المزيد حول اختبار الأتمتة في Yandex.Verticals من خلال مشاهدة تقريري لعام 2017 ، والذي لا يزال ملائمًا.ميزة أخرى لفريقنا هي أننا نقوم بأتمتة كل شيء ، بما في ذلك المختبرات اليدوية ، الذين يقدمون مساهمة كبيرة في تطوير أتمتة الاختبار. بالنسبة لهم ، ننظم المدارس ، ونعلمهم الاختبارات ، ونعلمهم كيفية كتابة الاختبارات لواجهة برمجة التطبيقات ، وواجهة الويب ، وغالبًا ما تساعد في مرافقة الاختبارات. وبالتالي ، يمكن للأشخاص المسؤولين عن الإصدار أنفسهم تصحيح الاختبار على الفور ، إذا لزم الأمر.في Verticals ، يكتب مطورو الاختبارات الاختبارات ، وهم حريصون جدًا على تطوير الاختبار بحيث يتنافسون معنا. يمكنك معرفة المزيد عن هذه العملية من تقرير "الدورة الكاملة لاختبار تطبيقات التفاعل"، حيث يتحدث Alexei Androsov و Natalya Stus حول كيفية كتابة اختبارات الوحدة على Puppeteer بالتوازي مع اختبارات Java من طرف إلى طرف.يكتب مهندسو أتمتة الاختبار أيضًا الاختبارات في فريقنا. ولكن غالبًا ما نقوم بتطوير بعض الأساليب الجديدة لتحسينها. على سبيل المثال ، قمنا بتنفيذ اختبار لقطة الشاشة ، الاختبار من خلال moki ، تقليل الاختبار. بشكل عام ، فإن منطقتنا هي في الأساس مطور برامج قيد الاختبار (SDET) ، نحن أكثر حول كيفية كتابة الاختبارات ، ويتم ملء قاعدة الاختبار جزئيًا من قبلنا ويدعمها المختبرون اليدويون.يساعدنا المطورون أيضًا ، وهذا أمر رائع.
المشكلة التي تنشأ في هذه العمليات هي أننا لا نفهم دائمًا ما تم تغطيته بالفعل وما هو غير مغطى. بالنظر إلى 15 ألف اختبار ، ليس من الواضح دائمًا ما نتحقق منه بالضبط. هذا صحيح بشكل خاص في سياق التواصل مع المديرين ، الذين بالطبع لا يختبرون ، ولكن يراقبون ويطرحون الأسئلة. على وجه الخصوص ، إذا طرح السؤال ما إذا كان زر معين قد تم اختباره في الواجهة أو التدفق ، فمن الصعب الإجابة ، لأنك تحتاج إلى الانتقال إلى رمز الاختبار والنظر في هذه المعلومات.ما الذي تم اختباره وما هو غير ذلك؟
إذا كان لديك العديد من الاختبارات بلغات مختلفة وكتبها أشخاص بدرجات متفاوتة من التدريب ، فعندئذٍ يطرح السؤال عاجلاً أم آجلاً ، هل هذه الاختبارات غير متقاطعة على الإطلاق؟ في سياق هذه المشكلة ، أصبحت قضية التغطية ذات أهمية خاصة. سأوضح ثلاثة مواضيع رئيسية:- طرق قياس التغطية بفعالية.
- تغطية اختبارات API.
- تغطية اختبارات الويب.
بادئ ذي بدء ، دعنا نحدد أن هناك طريقتان للتغطية: تغطية المتطلبات وتغطية رمز المنتج.كيف يتم قياس متطلبات التغطية
خذ بعين الاعتبار تغطية المتطلبات باستخدام auto.ru كمثال. بدلاً من اختبار auto.ru ، سأفعل ما يلي. أولاً ، أود أن أجد جوجل وأجد على الفور جدول متطلبات خاصة. هذا هو أساس تغطية المتطلبات.
في هذا الجدول ، تتم كتابة أسماء المتطلبات على اليسار. في هذه الحالة: الحساب والإعلانات والتحقق والدفع ، أي التحقق من الإعلان. بشكل عام ، هذه هي التغطية. تعتمد تفاصيل الجزء الأيسر على مستوى المختبر. على سبيل المثال ، لدى المهندسين من Google 49 نوعًا من الطلاء التي يتم اختبارها على مستويات مختلفة.الجانب الأيمن من الجدول هو سمات المتطلبات. يمكننا استخدام أي شيء على شكل سمات ، على سبيل المثال: الأولوية والتغطية والدولة. قد يكون هذا هو تاريخ الإصدار الأخير.
وبالتالي ، تظهر بعض البيانات في الجدول. يمكنك استخدام أدوات احترافية للحفاظ على جدول المتطلبات ، على سبيل المثال ، TestRail.هناك معلومات حول الشجرة على اليمين: تشير المجلدات إلى المتطلبات التي لدينا ، وكيف يمكن تغطيتها. هناك حالات اختبار وهلم جرا.
في العمودي ، تبدو هذه العملية كما يلي: يصف المختبر اليدوي المتطلبات وحالات الاختبار ، ثم يمررها إلى أتمتة الاختبار ، وتكتب الأداة التلقائية رمزًا لهذه الاختبارات. علاوة على ذلك ، في وقت سابق تم إعطاؤنا حالات اختبار تفصيلية وصف فيها المختبر اليدوي الهيكل بأكمله. ثم ارتكب شخص ما على github ، وبدأ الاختبار مفيدًا.ما هي إيجابيات وسلبيات هذا النهج؟ زائد هو أن هذا النهج يجيب على أسئلتنا. إذا سأل المدير ما قمنا بتغطيته ، سأفتح الجهاز اللوحي وأعرض الميزات التي يتم تغطيتها. من ناحية أخرى ، يجب أن تبقى هذه المتطلبات محدثة دائمًا ، وتصبح متقادمة بسرعة كبيرة.عندما يكون لديك 15 ألف اختبار ، فإن النظر إلى TestRail يشبه النظر إلى نجم في الفضاء: لقد انفجر لفترة طويلة ، ووصل الضوء إليك الآن. أنت تنظر إلى حالة الاختبار الحالية ، وقد عفا عليها الزمن بالفعل لفترة طويلة ولا رجعة فيها.من الصعب حل هذه المشكلة. بالنسبة لنا ، فإن هذين العالمين عمومًا مختلفان: هناك عالم من الأتمتة يدور وفقًا لقوانينه الخاصة ، حيث يتم إصلاح كل اختبار يفشل على الفور ، وهناك عالم من الاختبارات اليدوية ومتطلبات البطاقات. الجدار بينهما لا يمكن اختراقه ، ما لم تستخدم خادم Allure. نحن الآن فقط حل هذه المشكلة لهم.النقطة الثالثة من "الإيجابيات والسلبيات" هي الحاجة إلى العمل اليدوي. في مشروع جديد ، تحتاج إلى إعادة إنشاء خريطة متطلبات وكتابة جميع حالات الاختبار وما إلى ذلك. إنه يتطلب دائمًا العمل اليدوي ، وهو في الواقع أمر محزن للغاية.كيف يتم قياس تغطية الكود
بديل لهذا النهج هو تغطية التعليمات البرمجية. يبدو أن هذا هو الحل لمشكلتنا. هذه هي الطريقة التي تبدو بها تغطية رمز المنتج:
فهي تعكس تغطية الحزمة ، أو بالأحرى جزءًا صغيرًا مما هو موجود بالفعل في المنتج. الحزمة مكتوبة على اليسار ، كما تم كتابة الميزات من قبل. أي أن طلاءنا مرتبط أخيرًا ببعض الأشياء الملموسة ، في هذه الحالة - العبوة. يتم كتابة السمات على اليمين: التغطية حسب الفصل ، والتغطية بالطرق ، والتغطية بواسطة كتل التعليمات البرمجية والتغطية بخطوط التعليمات البرمجية.تتمثل عملية جمع التغطية في فهم سطر التعليمات البرمجية الذي اجتازه الاختبار وأيها لم ينجح. هذه مهمة بسيطة إلى حد ما ، ولكنها ذات صلة جدًا مؤخرًا.كان أول ذكر لتغطية الكود في عام 1963 ، ولكن التقدم الجاد في هذا الاتجاه يظهر الآن فقط.
لذا ، لدينا اختبار يتفاعل مع النظام. لا يهم كيف يتفاعل معها: من خلال الواجهة الأمامية أو واجهة برمجة التطبيقات أو التسلل مباشرةً إلى الواجهة الخلفية - سنفترض فقط أننا نمتلكها.ثم ينبغي إجراء الأجهزة. هذه بعض العمليات التي تسمح لك بفهم أسطر التعليمات البرمجية التي تم التحقق منها وأيها لم يتم التحقق منها. لا تحتاج إلى دراسته بالتفصيل ، ما عليك سوى البحث عن اسم إطار العمل الذي تكتب عليه ، على سبيل المثال ، الربيع ، ثم الأجهزة ، والتغطية - ستساعدك هذه الكلمات الثلاث على فهم كيفية القيام بذلك.عندما تتحقق اختباراتك من سطر الشفرة الذي ضربه الاختبار والخط الذي لم يصل إليه ، فإنها تحفظ الملفات التي تحتوي على معلومات حول الخطوط المغطاة. بناءً على هذه المعلومات ، لديك بيانات.ما هي إيجابيات وسلبيات تغطية الكود؟
تغطية الرمز سأدعو على الفور ناقص . لن تأتي إلى المدير ، ولن تعرض هذه اللوحة ولن تقول إن الجميع قد أتمت ، لأنه لا يمكن قراءة هذه البيانات ، سيطلب منك إرجاع بيانات واضحة يمكنك الاطلاع عليها وفهمها بسرعة.تقرير تغطية الكود أقرب إلى التنمية. لا يمكن استخدامه كنهج عادي لتوفير جميع البيانات لفريق إذا أردنا أن يتمكن الفريق بأكمله من المشاهدة.
ميزة هذا النهج هو أنه يوفر دائمًا البيانات ذات الصلة. ليس عليك القيام بالكثير من العمل ، فكل شيء مؤتمت لك. فقط قم بتوصيل المكتبة ، تبدأ أغطيةك في الإقلاع - وهذا رائع حقًا.ميزة أخرى لهذا النهج هو أنه يتطلب التخصيص فقط. لا يوجد شيء خاص للقيام به هناك - ما عليك سوى أن تأتي مع تعليمات محددة ، وتعديل التغطية ، وتعمل تلقائيًا.تسمح لك تغطية المتطلبات بتحديد المتطلبات التي لم يتم الوفاء بها ، ولكنها لا تسمح بتقييم مدى الاكتمال فيما يتعلق بالشفرة. على سبيل المثال ، بدأت في كتابة ميزة جديدة "تفويض" ، فقط أدخل "ميزة التفويض" ، وتبدأ في رمي حالات الاختبار عليها. لا يمكنك رؤية هذه التغطية على الفور في الكود ، حتى إذا كتبت فئة جديدة ، فلن تكون هناك معلومات - هناك فجوة. من ناحية أخرى ، يعد هذا أحد متطلبات التفويض ، حتى عندما يتم تنفيذه بالفعل ، عندما تحسب التغطية عليه ، لا يمكن أن يكون هذا الجزء ذا صلة ، يجب أن يتم تحديثه يدويًا.لذلك كانت لدينا فكرة: ماذا لو أخذنا الأفضل من الجميع؟ بحيث أجابت التغطية على أسئلتنا ، كانت دائمًا ذات صلة وتتطلب التخصيص فقط. نحتاج فقط إلى النظر إلى الطلاء من زاوية مختلفة ، أي أخذ نظام آخر كأساس للطلاء. في الوقت نفسه ، تأكد من أنه يتم جمعه تلقائيًا بالكامل وأن يجلب مجموعة من الفوائد. ولهذا سوف ندخل في تغطية اختبارات API.اختبار واجهة برمجة تطبيقات التغطية
ما هو أساس التغطية؟ للقيام بذلك ، نستخدم Swagger - هذه هي واجهة برمجة التطبيقات للوثائق. الآن لا أستطيع أن أتخيل عملي بدون Swagger ، إنها أداة أستخدمها باستمرار للاختبار. إذا كنت لا تستخدم Swagger ، أوصي بشدة بزيارة الموقع والتعرف على نفسك. هناك سترى على الفور مثالًا بديهيًا ومفهومًا للغاية للاستخدام.في الواقع ، Swagger هو الوثائق التي يتم إنشاؤها بواسطة الخدمة الخاصة بك. أنه يحتوي على:- قائمة الطلبات.
- طلب المعلمات: ليست هناك حاجة لسحب المطور والسؤال عن المعلمات.
- رموز الإجابة
مبدأ تشغيل Swagger هو الجيل. لا يهم إطار العمل الذي تستخدمه. وتقول دعونا الربيع أو العودة Server، يمكنك استخدام التبختر Codegen عنصر وتوليد swagger.json . هذه بعض المواصفات التي يتم على أساسها رسم واجهة مستخدم جميلة.من المهم بالنسبة لنا استخدام swagger.json : يتوفر دعمه لجميع اللغات المستخدمة على نطاق واسع.لدينا مواصفات Open API swagger.json . يبدو الأمر كما يلي:
تبدو الطلبات على النحو التالي: الملخص والوصف ورموز الاستجابة و "المقبض" (المسار: / المستخدمون). هناك أيضًا معلومات حول معلمة الاستعلام: كل شيء منظم ، هناك معلمة معرف مستخدم ، وهي في المسار حيث يوجد مطلوب ، مثل الوصف والنوع - عدد صحيح.
هناك رموز استجابة ، كما أنها موثقة:
وذهلت الفكرة إلى أذهاننا: لدينا خدمة تولدها Swagger ، وأردنا الاحتفاظ بنفس Swagger في الاختبارات ، حتى نتمكن من مقارنتها لاحقًا. وبعبارة أخرى ، عندما يتم تشغيل الاختبارات ، فإنها تولد نفس Swagger بالضبط ، ونلقيها على Swagger Diff ، ونفهم ما هي المعلمات ، والمقابض ، ورموز الحالة التي قمنا بفحصها ، وما إلى ذلك. هذا هو نفس الأجهزة ، نفس التغطية ، فقط في النهاية في المتطلبات التي نفهمها.ولكن ماذا لو قمت ببناء فرق؟
لجأنا إلى
مكتبة فرق Swagger ، وهو ما نحتاجه لذلك. مبدأ التشغيل هو شيء من هذا القبيل: لديك الإصدار 1.0 ، مع الإصدار 1.1 من API ، كلاهما يولد swagger.json ، ثم يرميه على Swagger diff ويرى النتيجة.تبدو النتيجة شيئًا مثل هذا:
لديك معلومات تفيد ، على سبيل المثال ، بقلم جديد. لديك أيضًا معلومات حول ما تم حذفه. هذا يعني أنه حان الوقت لإزالة الاختبارات ، لم تعد ذات صلة. مع ظهور معلومات حول التغييرات ، تتغير المعلمات أيضًا ، لذلك من الواضح أن اختباراتك ستنخفض في تلك اللحظة.لقد أحببنا هذه الفكرة ، وبدأنا في تنفيذها. كما قررنا القيام بذلك: لدينا Swagger "المرجعي" الذي يتم إنشاؤه من كود المطور ، لدينا أيضًا اختبارات API التي ستولد Swagger الخاص بنا ، وسوف نختلف بينهما.لذا ، نجري اختبارات للخدمة: لدينا Rest Assured ، الذي يصل في حد ذاته إلى الخدمات على API. ونحن صكها. هناك نهج: يمكنك عمل فلاتر ، يذهب الطلب إليه - ويحفظ المعلومات حول الطلب في شكل swagger.json مباشرة لنفسه.هنا هو الرمز الكامل الذي كنا بحاجة إلى كتابته ، كان هناك 69-70 سطرًا - هذا رمز بسيط جدًا.
الشيء المضحك هو أننا استخدمنا العميل الأصلي لـ Swagger ، كتب هناك. لم نكن بحاجة إلى إنشاء ثنائياتنا ، لقد ملأنا للتو مواصفات Swagger.
حصلنا على الكثير من ملفات .json التي كان علينا أن نفعل بها شيئًا - لقد كتبوا مُجمع Swagger. هذا برنامج بسيط للغاية يعمل وفقًا للمبدأ التالي:- تضيف طلبًا جديدًا ، إذا لم يكن موجودًا في قاعدة بياناتنا.
- تلبي الطلب ، لديه معلمة جديدة - يضيف.
- نفس الشيء مع رموز الحالة.
وبالتالي ، نحصل على معلومات حول جميع الأقلام والمعلمات ورموز الحالة التي استخدمناها. بالإضافة إلى ذلك ، يمكنك هنا جمع البيانات التي تم بها تنفيذ هذه الطلبات: اسم المستخدم وتسجيلات الدخول وما إلى ذلك. لم نتوصل بعد إلى كيفية استخدام هذه المعلومات ، لأن كل شيء يتم إنشاؤه معنا ، ولكن يمكنك فهم المعلمات التي تم استدعاء بعض الطلبات لها.لذا ، كنا تقريبًا على مرمى حجر من النصر ، ولكن نتيجة لذلك رفضنا Swagger Diff ، لأنه يعمل بمفهوم مختلف قليلاً - في مفهوم التفاضلية.
يقول Swagger Diff ما تغير ، وليس ما يتم تغطيته ، لكننا أردنا عرض نتيجة التغطية. هناك الكثير من البيانات الإضافية ، فهي تخزن معلومات حول الوصف والملخص والمعلومات الوصفية الأخرى ، ولكن ليس لدينا هذه المعلومات. وعندما نصنع Diff ، يكتبون لنا أن "هذا القلم ليس له وصف" ، لكنه غير موجود.تقرير خاص
لقد قمنا بتنفيذنا ، وهو يعمل على النحو التالي: لدينا العديد من الملفات التي تم الحصول عليها من الاختبارات التلقائية ، ولدينا واجهة برمجة تطبيقات Swagger Service ، وننشئ تقريرًا بناءً على ذلك.يبدو تقرير بسيط كالتالي: في الأعلى ، يمكنك الاطلاع على معلومات حول عدد الأقلام (349) في الإجمالي ، والمعلومات التي يتم تغطيتها بالكامل (كل معلمة ، ورمز الحالة ، وما إلى ذلك). يمكنك اختيار المعايير الخاصة بك ، على سبيل المثال ، تغطية العديد من المعلمات.هناك أيضًا معلومات هنا تفيد بأن 40 ٪ مغطاة جزئيًا - وهذا يعني أن لدينا بالفعل اختبارات لهذه الأقلام ، ولكن بعض الأشياء لم يتم تغطيتها بعد ، وتحتاج إلى النظر بعناية هناك. تنعكس التغطية الفارغة أيضا.
دعنا نذهب من خلال علامات التبويب. هذه تغطية كاملة ، ونرى جميع المعلمات التي لدينا ، والتي يتم تغطيتها ، ورموز الحالة وما إلى ذلك.
ثم لدينا تغطية جزئية . نرى أنه في مقبض تسجيل الدخول-الاجتماعي يتم تغطية معلمة واحدة ، واثنتين غير مغطيتين. ويمكننا توسيعها ومعرفة المعلمات ورموز الحالة المحددة التي يتم تغطيتها. وفي هذه اللحظة يصبح الأمر مناسبًا جدًا للمطور: يتم تشغيل إصدارات التطبيق بسرعة كبيرة ، وغالبًا ما ننسى بعض المعلمات.
تتيح لك هذه الأداة أن تكون دائمًا في حالة جيدة وأن تفهم ما قمنا بتغطيته جزئيًا ، والمعلمات التي تم نسيانها ، وما إلى ذلك.أخيرًا - مجد العار ، لا يزال يتعين علينا القيام بذلك. عندما تنظر إلى هذه الصفحة وترى إفراغ هناك: 172 - تنخفض يديك ، ثم تبدأ في تعليم مختبري الأيدي كيفية كتابة الاختبارات التلقائية ، هذه هي النقطة.
ما الفائدة التي حصلنا عليها عند طرح حلنا؟
أولاً ، بدأنا في كتابة الاختبارات بشكل أكثر معنى. نحن نتفهم أننا نجري اختبارًا ، وفي الوقت نفسه لدينا استراتيجيتان. أولاً ، نقوم بأتمتة شيء غير موجود عندما يأتي المختبرون اليدويون ويقولون أنه بالنسبة لخدمة معينة ، من المهم تنفيذ طلب واحد مرة واحدة على الأقل ، ونفتح Empty.الخيار الثاني - لا ننسى ذيول. كما قلت ، سيتم إصدار واجهات برمجة التطبيقات بسرعة كبيرة ، قد يكون هناك بعض الإصدارات مرتين أو ثلاث مرات في اليوم. يتم إضافة بعض المعلمات باستمرار هناك: في خمسة آلاف اختبار ، من المستحيل فهم ما يتم فحصه وما لا يتم فحصه. لذلك ، هذه هي الطريقة الوحيدة لاختيار استراتيجية اختبار بوعي والقيام بشيء على الأقل.الربح الثالث هو عملية تلقائية بالكامل. لقد اقترضنا النهج ، وأتمتة: لسنا بحاجة إلى القيام بأي شيء ، يتم جمع كل شيء تلقائيًا.أفكار التنمية
أولاً ، لا أريد حقًا الاحتفاظ بالتقرير الثاني ، لكني أرغب في دمجه في واجهة مستخدم Swagger. هذا هو "تقرير Photoshop Edition" المفضل لدي: شريحة كنت أقوم بتطويرها مؤخرًا. هنا على الفور هناك معلومات حول المعلمات التي قمنا باختبارها والتي ليست كذلك. وسيكون من الرائع إعطاء هذه المعلومات على الفور مع Swagger.
على سبيل المثال ، يمكن للواجهة الأمامية أن ترى بنفسها ما هي المعلمات التي لم يتم اختبارها ، وترتيب الأولويات ، وتقرر أنه في حين أنها لا تحتاج إلى أن تؤخذ في التطوير ، فمن غير المعروف مدى جودة عملها. أو تكتب الخلفية قلمًا جديدًا ، وترى الأحمر ومختبرة الركلات حتى يكون كل شيء أخضر. هذا سهل للغاية ، نحن نسير في هذا الاتجاه.والفكرة الثانية هي دعم أدوات أخرى. في الواقع ، لا أريد كتابة عوامل تصفية لعمليات تنفيذ محددة: لـ Java و Python وما إلى ذلك. هناك فكرة لإنشاء نوع من الوكيل الذي سيمرر جميع الطلبات من خلاله ، ويحفظ معلومات Swagger لنفسه. وبالتالي ، سيكون لدينا مكتبة عالمية يمكن استخدامها بغض النظر عن اللغة التي لديك.فكرة التطوير الثالثة هي التكامل مع Allure Report. أراها على هذا
النحو : كقاعدة عامة ، عندما يتم اختبار المعلمة ، لا يخبرنا ذلك دائمًا عن كيفية اختبارها. وأريد أن أشير إلى هذه المعلمة وأرى خطوات الاختبار المحددة.تغطية اختبار الويب
النقطة التالية التي أريد التحدث عنها هي تغطية اختبارات الويب. تعتمد التغطية على الموقع الذي تختبره ، وكتابة الاختبارات على الموقع. ولكن يمكنك جعلها واجهة ويب للتغطية الخاصة بك. على سبيل المثال ، ستبدو كما يلي:
إذا نظرت إلى موقعك - فهذه مجموعة من العناصر وطرق التفاعل معها. هذا وصف كامل: "العنصر هو وسيلة للتفاعل معه". يمكنك النقر على الرابط ، يمكنك نسخ النص ، يمكنك دفع شيء ما إلى الإدخال. يتكون الموقع ككل من عناصر وطرق تفاعلهم:
كيفية تشغيل الاختبارات: تبدأ من نقطة ما ، ثم ، على سبيل المثال ، ملء نموذج ، على سبيل المثال ، نموذج تفويض ، ثم مبعثر إلى صفحات أخرى ، ثم آخر إلى آخر ونهاية .إذا سأل المدير إذا كان هناك زر معين قيد الاختبار ، ولكن من الصعب الإجابة على هذا السؤال: تحتاج إلى فتح الكود أو الانتقال إلى TestRail ، فأنا أريد رؤية هذا الحل للمشكلة:
أريد أن أشير إلى هذا العنصر وأرى جميع الاختبارات التي لدينا على هذا البند. إذا كان هناك مثل هذا الصك ، سأكون سعيدًا. عندما بدأنا التفكير في هذه الفكرة ، نظرنا أولاً إلى Yandex.Metrica. لديهم في الواقع تقريبا نفس وظيفة خريطة الارتباط. فكرة جيدة.خلاصة القول هي أنه تم إبرازها تمامًا كما لو أنها أعطت بالفعل المعلومات التي نحتاجها. يقولون: "لقد تجاوزنا هذا الرابط 14 مرة" ، وهو ما يعني في الترجمة إلى لغة الاختبار: "تم اختبار 14 اختبارًا في هذا الرابط" وتم تمريره بطريقة أو بأخرى. لكن هذا الرابط الأحمر استغرق ما يصل إلى 120 اختبارًا ، يا لها من اختبارات مثيرة للاهتمام!يمكنك رسم جميع أنواع الاتجاهات وإضافة المعلومات الوصفية ، ولكن ماذا يحدث إذا أخذناها كلها ورسمنا من وجهة نظر الاختبار؟ لذلك ، لدينا مهمة: للإشارة إلى بعض العناصر والحصول على ملاحظة بقائمة من الاختبارات.
من أجل تنفيذ ذلك ، تحتاج إلى النقر على الرمز ، ثم كتابة ملاحظة ، وهذا هو اختبارنا بالكامل. نحن نستخدم أطلس في مكاننا ، والتكامل حتى الآن هو فقط معه.يبدو Atlas مثل هذا:SearchPage.open ();
SearchPage.offersList().should(hasSizeGreaterThan(0));
نريد عرض نتيجة واحدة على الأقل ، وإلا فلن نختبرها. ثم ننقل المؤشر إلى العنصر ، ثم نضغط عليه.searchPage.offer(FIRST).moveCursor();
searchPage.offer(FIRST).actionBar().note().click();
ثم نقوم بحفظ إدخال User_Text وإرساله.searchPage.offer(FIRST).addNoteInput().sendKeys(USER_TEXT);
searchPage.offer(FIRST).saveNote().click();
بعد ذلك ، نتحقق من أن النص هو بالضبط ما كان يجب أن يكون. searchPage.offer(FIRST).addNoteInput().should(hasValue(USER_TEXT));
يتم تشغيل الاختبارات في متصفح ، Atlas هو وكيل لهذا الاختبار ، نطبق نفس النهج هنا الذي يستخدمه الجميع عند جمع التغطية: سنقوم بعمل محدد باستخدام .json. سنحفظ هناك معلومات حول جميع فتحات الصفحة ، وكل التكرارات التي تحتوي على عناصر ، والذين أرسلوا ، والذين أرسلوا مفتاحًا ، والذين ينقرون ، والمعرفات وما إلى ذلك - سنحتفظ بسجل كامل.ثم نعلق هذا السجل إلى الجاذبية في شكل كل اختبار، وعندما يكون لدينا الكثير من locators.json ، فإننا توليد meta.json . المخطط هو نفسه لجميع العناصر.لدينا مكون إضافي لمتصفح Google Chrome. أردنا اتخاذ قرار في شكل مكون إضافي. لقد صنعت بشكل خاص لقطة شاشة منحنية بحيث تظهر تفاصيل مهمة واحدة على الشريحة - المسار إلى locators.json .
إذا قمت بإنشاء تقرير الآن ، فهناك خريطة تغطية لهذا اليوم. إذا أخذت التقرير للأسبوعين السابقين وقمت بلصقه هنا ، فستظهر خريطة تغطية للفترة قبل أسبوعين. لديك آلة الزمن!ومع ذلك ، عند توصيل هذا البرنامج المساعد ، فإنه يرسم واجهة غير ودية.
يحتوي كل عنصر على عدد من الاختبارات التي يمر بها: من الواضح أن 40 اختبارًا تمر عبر "شراء شقة" ، ويتم اختبار الرأس اختبارًا واحدًا في كل مرة ، إنه رائع ، ويتم عرض خيار "الشقة" أيضًا. تحصل على خريطة تغطية كاملة.إذا مررت مؤشر الماوس فوق عنصر ما ، فسيتم أخذ البيانات وطباعة اختباراتك الحقيقية من tms و Allure Board وما إلى ذلك. والنتيجة هي معلومات كاملة حول ما يتم اختباره وكيف.يرجى ملاحظة أنه من كل اختبار يمكنك الفشل مباشرة في تقرير Allure.
عندما تفتح أي شيء ، يتم تحميل محددات جديدة: إذا كان لديك أي اختبارات تمر بهذه المحددات وقمت بعمل شيء مع الموقع ، فستتم معالجة الصورة بأكملها وإظهارها.ما هو الربح؟
بمجرد تنفيذ هذا النهج البسيط ، بدأنا بشكل أساسي في فهم ما اختبرناه في الاختبارات.
الآن يمكن لأي شخص الدخول والعثور على أي "موضوع" يؤدي إلى البرنامج النصي. على سبيل المثال ، تفترض أنك بحاجة إلى اختبار الدفع. من الواضح أن الدفع يؤدي من خلال زر الدفع: انقر - تظهر جميع الاختبارات التي تمر عبر زر الدفع. هذا جيد! تذهب إلى أي منهم وعرض البرنامج النصي.علاوة على ذلك ، أنت تفهم ما تم اختباره من قبل. نقوم بإنشاء ملف ثابت ، يمكنك تحديد المسار إليه وتحديد الاختبارات التي كانت قبل أسبوعين. إذا قال المدير أن هناك خطأ في الإنتاج وسألنا إذا اختبرنا هذه الوظيفة أو تلك الوظيفة قبل أسبوعين ، فأنت تأخذ تقرير Allure ، على سبيل المثال ، أنك لم تختبره.ربح آخر هو المراجعة بعد اختبار الأتمتة. قبل ذلك ، أجرينا مراجعة قبل اختبار الأتمتة ، الآن يمكنك إجراء اختباراتك تمامًا كما تراها. إذا كنت ترغب في إجراء اختبار - تم القيام به ، فخذ فرعًا ، وأطلق Allure ، وأسقط الرابط إلى المكون الإضافي إلى جهاز اختبار يدوي وطلب رؤية الاختبارات. هذه هي العملية التي ستسمح لك بتقوية إستراتيجية Agile: يقوم قائد الفريق بمراجعة الشفرة ، ويقوم المختبرون اليدويون بالاختبارات (البرامج النصية).ميزة أخرى لهذا النهج هي العناصر المستخدمة بشكل متكرر. إذا تجاوزنا هذه الكتلة ، حيث يوجد 87 اختبارًا ، فسوف تسقط جميعها. تبدأ في فهم مدى فوضى اختباراتك.
وإذا تم إلغاء الكتلة "السعر من" ، فلا بأس ، فسوف ينخفض اختبار واحد ، وسيصححها الشخص. إذا قمت بتغيير الكتلة باستخدام 87 اختبارًا ، فستتراجع التغطية إلى حد كبير ، لأن 87 اختبارًا لن تنجح ولن تتحقق من أي نتيجة. تحتاج هذه الكتلة إلى اهتمام متزايد. ثم تحتاج إلى إخبار المطور أن هذه الكتلة يجب أن تكون بمعرف ، لأنه إذا غادر ، فسوف ينهار كل شيء.كيف يمكنك تطوير أكثر؟
على سبيل المثال ، يمكنك اتباع مسار تطوير الدعم للأدوات الأخرى ، على سبيل المثال ، لـ Selenide. لا أرغب حتى في دعم Selenide محدد ، ولكن تنفيذ برنامج تشغيل يسمح لك بجمع محددات المواقع ، بغض النظر عن الأداة التي تستخدمها. سيقوم هذا الوكيل بتفريغ المعلومات ثم عرضها.فكرة أخرى هي عرض نتيجة الاختبار الحالية. على سبيل المثال ، من الملائم إلقاء هذه الصورة على الفور على جهاز اختبار يدوي:
لست بحاجة إلى التفكير في الاختبارات التي تم كسرها ، لأنه يمكنك الانتقال إلى الموقع ، والنقر على الاختبار ومراجعته دون التحقق من الاختبارات الأخرى. هذا سهل ، يمكنك التقاط هذه المعلومات من Allure ورسمها هنا.يمكنك أيضًا إضافة إجمالي النقاط ، لأن الجميع يحب الرسومات ، لأنني أريد التعامل مع اختبارات مكررة متشابهة جدًا مع بعضها البعض ، حيث يكون الجزء المركزي هو نفسه ، وقد تغيرت البداية والذيل قليلاً.
أود أيضًا أن أرى على الفور عدد المحددات المكررة. إذا كانت عالية ، في هذه الصفحة ، تحتاج إلى إجراء إعادة بناء وإجراء اختبارات ، وإلا فسوف تقع في حزمة كبيرة جدًا. وينطبق الشيء نفسه على عدد العناصر التي تفاعلنا معها. هذه بعض الأعراض الشائعة. ومع ذلك ، بمجرد أن تتفاعل مع الصفحة ، سيتخطى الرقم بسبب العناصر الجديدة والعدد الإجمالي لحالات الاختبار ، لذلك تحتاج إلى إضافة نوع من التحليلات ، فلن يكون غير ضروري.يمكنك أيضًا إضافة توزيع الاختبارات حسب الطبقات ، لأنك لا تريد أن ترى فقط أن لدينا هذه الاختبارات ، ولكن جميع أنواع الاختبارات الموجودة في هذه الصفحة ، وربما حتى الاختبارات اليدوية.وبالتالي ، إذا كانت هناك اختبارات Java واختبارات على Puppeteer يكتبها فريق آخر ، فيمكننا إلقاء نظرة على صفحة معينة وتحديد مكان تقاطع اختباراتنا على الفور. أي أننا سنتحدث معهم اللغة نفسها ، ولن نحتاج إلى جمع هذه المعلومات شيئًا فشيئًا. إذا كانت لدينا أداة تعرض كل شيء في واجهة الويب ، فإن مهمة مقارنة الاختبارات في Java و Puppeteer لم تعد غير قابلة للحل.أخيرًا ، لنتحدث عن الاستراتيجية العامة. لقد تحدثنا بالفعل عن أنواع التغطية ، واسمها اثنان ، توصلنا إلى نوع ثالث من الطلاء ، والذي استخدمناه نتيجة لذلك. لذا أخذنا هذه المشكلة ونظرنا إليها من زاوية مختلفة.من ناحية ، هناك تغطية تم ركلها منذ عام 1963 ، من ناحية أخرى ، هناك أجهزة اختبار يدوية معتادة على العيش في عالم أكثر واقعية من التعليمات البرمجية. يبقى فقط لدمج هذين النهجين.
يمكن للمهتمين الانضمام دائمًا إلى مجتمعنا. فيما يلي مستودعين لشبابنا يتعاملون مع مشكلة التغطية: