اختبار أتمتة تطبيقات الويب الجاهزة ، بدون تسجيل ورسائل نصية قصيرة

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

تحتاج إلى النقر فوق 100500 صفحة والتحقق من جميع الوظائف ... وقبل الإصدار التالي ، تحقق من نفسها مرة أخرى ... ومرة ​​أخرى ... وغدًا مرة أخرى. في مرحلة ما ، يبدأ التحقق يستغرق وقتًا أطول من تطوير وظائف جديدة. "ماذا عن اختبارات e2e؟" - أنت تسأل. ولكن ، أولاً ، ما زالوا بحاجة إلى الكتابة. وثانيًا ، قبل البدء في كتابتها ، تحتاج إلى كتابة حالات الاختبار. الكثير من حالات الاختبار.

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




كتابة حالات الاختبار تلقائيًا


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

وفقًا لذلك ، عند كتابة حالة اختبار ، تحتاج إلى تسجيل جميع الإجراءات:

  • "الضغط على الزر"
  • "أدخلت قيمة XXX"
  • "حددت القيمة YYY في القائمة المنسدلة"

والشيكات:

  • "ظهر النص: XXX"
  • "ظهرت رسالة الخطأ: YYY"
  • "ظهر العنوان: ZZZ"

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

لنبدأ باعتراض الأحداث. لتتبع التفاعل مع عناصر التحكم مثل الأزرار وأزرار الاختيار وخانات الاختيار ، تحتاج إلى الاشتراك في حدث النقر. كل إطار له طرقه الخاصة لهذا الغرض. على سبيل المثال ، fromEvent in Angular و document.addEventListener في JavaScript و React. بالنسبة لعناصر التحكم في الإدخال ، مثل التقويم أو الإدخال ، سيتغير نوع الحدث الذي تريد الاشتراك فيه فقط: بدلاً من النقر ، سيكون التركيز.

fromEvent(this.elementRef.nativeElement, 'click')
.subscribe(tagName => {
 	if (tagName === 'BUTTON') {
   		this.testCaseService.addAction(`   "${action.name}"`);
 	} else if (tagName === 'INPUT-CALENDAR') {
   		this.testCaseService
     			.addAction(`  "${action.name}" "${action.value}"`);
 	}
});

وأخيرًا ، أهم شيء هو التحقق. الطريقة التي يجب أن يتصرف بها الموقع استجابة لأفعال المختبر.

ماذا يفحص المختبر عادة؟ على سبيل المثال ، أدخل قيمة غير صالحة في الإدخال ، ورد الموقع برسالة خطأ. أو لنفترض أننا نقرنا على زر وردًا على ذلك ظهرت شاشة جديدة ، تغير العنوان ، وظهر نص جديد ، وأعيد بناء عناصر التحكم. ترتبط جميع هذه التغييرات بالتغيير في شجرة DOM. هناك العديد من الخيارات لتتبعها. يمكنك ، على سبيل المثال ، استخدام MutationObserver في React و JavaScript أو ngAfterViewInit في Angular (وضع توجيه لعناصر النموذج التي تهمك على الموقع).

ngAfterViewInit() {
    const tagName = this.nativeElement.nodeName;
	const text = this.nativeElement.textContent;
    if (['SPAN', 'P'].includes(tagName)) {
 	 	 this.testCaseService.addContent(`** ** "${text}"\n`);
     } else if (tagName === 'H1') {
 	  	this.testCaseService.addContent(`** ** "${text}"\n`);
     } …	
}

سيعتمد الكود بشكل كبير على التخطيط. دعونا نلقي نظرة على الترميز. هذه الأزرار مأخوذة من مترجم جوجل.


<div class="tlid-input-button input-button header-button tlid-input-button-text text-icon" role="tab" tabindex="-1">
  	<div class="text"></div>
</div>
<div class="tlid-input-button input-button header-button tlid-input-button-docs documents-icon" role="tab" tabindex="-1">
 	 <div class="text"></div>
</div>

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

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

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

كتابة اختبارات e2e تلقائيًا


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

الآن هناك عدد كبير من الأطر المختلفة مع تدوين gherkin استنادًا إلى النصوص السلوكية: SpecFlow ، xBehave.net. ، Cucumber.js ، CodeceptJS ، وما

إلى ذلك. جميع الشيكات ثم و.

احصل على اختبار e2e الذي تم إنشاؤه تلقائيًا:

Feature:   2-
  Background:
 	When  "" ""

  Scenario:
 	When    " - "
 	Then    "  "
 	And   " - "
 	When    "  " ""
 	When    "" "  "
 	When    ""

لتشغيل التشغيل التجريبي ، تكون الميزات التي تم إنشاؤها قليلة - تحتاج إلى كتابة معالج لجميع الإجراءات وعمليات التحقق.

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

When('   {string}', async function (button: string) {
	const xpath = "//button";
	const btn = await getItemByText(xpath, button);
	await waitAndClick(btn);
});
When('  {string} {string}', async function (label: string, text: string) {
	const xpath = "//*[contains(text(),'" + label + "')]/ancestor::outline";
	await inputSendKeys(currentBrowser().element(by.xpath(xpath)), text);
});

الآن ، بفحص المهمة التالية ، يتم كتابة حالة اختبار تلقائيًا للاختبار ويتم تشغيل اختبار e2e الذي تم إنشاؤه تلقائيًا.

باختصار ، تحتاج إلى:

  1. اشترك في أحداث التفاعل مع عناصر التحكم ورد فعل الموقع على هذه الإجراءات (من خلال تتبع إعادة بناء شجرة DOM).
  2. تحويل البيانات من الفقرة 1 إلى اختبارات e2e.
  3. اكتب معالج عام لإجراء اختبارات e2e.

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

لقد تحدثت عن هذا ، بالإضافة إلى الإصدار ، ومجموعة التكنولوجيا ، وحتى عن المشكلات في المرحلة الأولى من التنفيذ وحلها في مؤتمر Heisenbug-2019 في موسكو .

في هذه المقالة ، حاولت نقل الفكرة الرئيسية دون الخوض في التفاصيل.

استنتاج


الآن يستغرق الأمر منا دقيقتين في المتوسط ​​لكتابة حالة اختبار واختبار e2e - وهذا أسرع 60 مرة من الحسابات الأولية ، عندما أردنا كتابة حالات الاختبار واختبارات e2e يدويًا.

لم نغير العمليات في الفريق. لم يعد من الضروري تخصيص سعة الاختبار لكتابة حالات الاختبار وأخذ فريق الأتمتة.

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

عند كتابة اختبارات e2e يدويًا ، من الصعب جدًا موازاة الاختبار. الآن ، تتم كتابة اختبارات e2e تلقائيًا أثناء اختبار المهمة ، ولا يحتاج المختبر إلى التحقق من نفس الوظيفة مرتين.

ونتيجة لذلك ، بدأ فريقنا ، دون تغيير التكوين ، في العمل بكفاءة أكبر.

All Articles