مرحبا يا هبر!
اسمي Vitaliy Kotov ، أعمل في Badoo ومعظم الوقت أتعامل مع مشكلات التشغيل الآلي للاختبار. أريد أن أشارك حل واحد من هذه الأسئلة في هذه المقالة.
سيكون حول كيفية تنظيم عملية إجراء اختبارات واجهة المستخدم باستخدام اختبارات A / B ، والتي لدينا الكثير منها. سأتحدث عن المشكلات التي واجهناها والفيضانات التي وصلنا إليها في النهاية. مرحبا بكم في القط!
حتى بدأنا ...
اختبار الكلمة شائع جدًا في هذه المقالة. ذلك لأننا نتحدث عن اختبارات واجهة المستخدم واختبارات A / B في نفس الوقت. لقد حاولت دائمًا فصل هذين المفهومين وصياغة الأفكار بحيث كان النص سهل القراءة. إذا افتقدت في مكان ما الجزء الأول من الكلمة وكتبت ببساطة "اختبار" ، فهذا يعني اختبار واجهة المستخدم.
هل لديك قراءة لطيفة!
ما هي اختبارات A / B
لذلك ، أولاً وقبل كل شيء ، دعونا نحدد مفهوم اختبار A / B. هنا اقتباس من ويكيبيديا:
"إن اختبار A / B (اختبار A / B (اختبار A / B) ، Split Split) هو طريقة من طرق البحث التسويقي ، وجوهرها هو أن مجموعة عناصر التحكم تتم مقارنتها بمجموعة من مجموعات الاختبار التي تم فيها تغيير مؤشر واحد أو أكثر ، من أجل: لمعرفة أي من التغييرات يحسن الهدف " رابط .
فيما يتعلق بمشروعنا ، يعني وجود اختبار A / B أن بعض الوظائف مختلفة للمستخدمين المختلفين. أود تسليط الضوء على العديد من الخيارات:
- الميزة متوفرة لمجموعة مستخدمين واحدة ، ولكنها غير متوفرة لمجموعة أخرى ؛
- الميزة متاحة لجميع المستخدمين ، لكنها تعمل بطرق مختلفة ؛
- الميزة متاحة لجميع المستخدمين ، وتعمل بنفس الطريقة ، لكنها تبدو مختلفة ؛
- أي مزيج من الخيارات الثلاثة السابقة.
لكي يعمل كل هذا المنطق ، لدينا أداة في شركتنا تسمى
UserSplit Tool ، وتحدث مطورنا Rinat Akhmadeev عن ذلك بالتفصيل في هذه
المقالة .
سنتحدث الآن عن معنى اختبار A / B لقسم الاختبار والأتمتة على وجه الخصوص.
تغطية اختبار واجهة المستخدم
عندما نتحدث عن تغطية واجهة المستخدم ، لا نتحدث عن عدد سطور التعليمات البرمجية التي اختبرناها. هذا أمر مفهوم ، لأنه حتى مجرد فتح صفحة يمكن أن يشمل العديد من المكونات ، في حين أننا لم نختبر أي شيء حتى الآن.
على مدار سنوات العمل في مجال أتمتة الاختبار ، رأيت العديد من الطرق لقياس تغطية اختبارات واجهة المستخدم. لن أدرجها جميعًا ، سأقول فقط أننا نفضل تقييم هذا المؤشر بعدد الميزات التي تغطيها اختبارات واجهة المستخدم. هذه ليست طريقة مثالية (أنا شخصياً لا أعرف الطريقة المثالية) ، لكنها تعمل في حالتنا.
وهنا نعود مباشرة إلى موضوع المقال. كيفية قياس والحفاظ على مستوى جيد من تغطية اختبارات واجهة المستخدم ، عندما يمكن أن تتصرف كل ميزة بشكل مختلف حسب المستخدم الذي يستخدمها؟
كيف تمت تغطية الميزات بواسطة اختبارات واجهة المستخدم في البداية
حتى قبل ظهور أداة UserSplit في الشركة وكان هناك بالفعل العديد من اختبارات A / B ، فقد التزمنا بالإستراتيجية التالية لتغطية الميزات باختبارات واجهة المستخدم: تغطي فقط تلك الميزات التي كانت قيد الإنتاج لبعض الوقت واستقرت.
وكل ذلك لأنه في وقت سابق ، عندما بدأت الميزة في الإنتاج فقط ، فإنها لا تزال "مضبوطة" لبعض الوقت - قد يتغير سلوكها وظهورها. كما أنها لم تستطع إثبات نفسها على الإطلاق وتختفي بسرعة من أعين المستخدمين. تعد كتابة اختبارات واجهة المستخدم للميزات غير المستقرة باهظة الثمن ولم تتم ممارستها معنا.
مع إدخال اختبارات A / B في عملية التطوير ، لم يتغير شيء في البداية. كان لكل اختبار A / B ما يسمى "مجموعة التحكم" ، أي المجموعة التي شهدت بعض السلوك الافتراضي لهذه الميزة. كان عليه أن اختبارات واجهة المستخدم كانت مكتوبة. كل ما كان يجب القيام به عند كتابة اختبارات واجهة المستخدم لمثل هذه الميزة هو أن نتذكر لتمكين المستخدم من السلوك الافتراضي. نسمي هذه العملية قوة مجموعة A / B (من القوة الإنجليزية).
سوف
أتطرق إلى وصف
القوة بمزيد من التفصيل ، لأنها ستظل تلعب دورًا في قصتي.
فرض اختبارات A / B و QaAPI
لقد تحدثنا مرارًا وتكرارًا عن QaAPI في مقالاتنا وتقاريرنا. ومع ذلك ، من الغريب أننا لم نكتب حتى الآن مقالة كاملة حول هذه الأداة. ربما في يوم من الأيام سيتم سد هذه الفجوة. في غضون ذلك ، يمكنك مشاهدة مقطع فيديو لخطاب زميلي ديمتري ماروشينكو: "
4. مفهوم QaAPI: نظرة على الاختبار من الجانب الآخر من المتاريس ".
باختصار ، يسمح لك QaAPI بتقديم طلبات من الاختبار إلى خادم التطبيق من خلال مستتر خاص من أجل معالجة أي بيانات. باستخدام هذه الأداة ، على سبيل المثال ، نقوم بإعداد المستخدمين لحالات اختبار محددة ، وإرسال رسائل لهم ، وتحميل الصور ، وما إلى ذلك.
باستخدام نفس QaAPI ، يمكننا فرض مجموعة اختبار A / B ؛ يكفي الإشارة إلى اسم الاختبار واسم المجموعة المرغوبة. تبدو المكالمة الاختبارية مثل هذا:
QaApi::forceSpliTest(“Test name”, “Test group name”, {USER_ID or DEVICE_ID});
المعلمة الأخيرة التي نحددها هي user_id أو device_id ، والتي يجب أن تبدأ هذه القوة عملها. نحدد المعلمة device_id في حالة مستخدم غير مصرح به ، لأن المعلمة user_id ليست موجودة بعد. هذا صحيح ، بالنسبة للصفحات غير المصرح بها ، لدينا أيضًا اختبارات A / B.
بعد استدعاء طريقة QaAPI هذه ، يضمن لمستخدم مرخص له أو مالك الجهاز رؤية إصدار الميزة التي أنشأناها. هذه هي التحديات التي كتبناها في اختبارات واجهة المستخدم ، والتي غطت الميزات التي تخضع لاختبار A / B.
وهكذا عشنا لفترة طويلة. غطت اختبارات واجهة المستخدم مجموعات التحكم فقط من اختبارات A / B. ثم لم يكن هناك الكثير ، وأنها عملت. لكن مر الوقت بدأ عدد اختبارات A / B في الزيادة ، وبدأت جميع الميزات الجديدة تقريبًا في العمل وفقًا لاختبارات A / B. لقد توقف النهج المتبع في تغطية إصدارات التحكم فقط من الميزات عن إرضائنا. وهذا هو السبب ...
لماذا تغطية اختبارات A / B
مشكلة واحدة - التغطيةكما كتبت أعلاه ، مع مرور الوقت ، بدأت جميع الميزات الجديدة تقريبًا في الظهور تحت اختبارات A / B. بالإضافة إلى عنصر التحكم ، كل ميزة لديها خيار واحد أو أكثر أو ثلاثة خيارات أخرى. اتضح أنه بالنسبة لهذه الميزة ، لن تتجاوز التغطية في أفضل الحالات 50٪ ، وفي أسوأ الأحوال ستكون حوالي 25٪. في السابق ، عندما كان هناك عدد قليل من هذه الميزات ، لم يكن لهذا تأثير كبير على معدل التغطية الإجمالي. الآن - بدأ العرض.
المشكلة الثانية - اختبارات A / B الطويلةتستغرق بعض اختبارات A / B الآن بعض الوقت. ونستمر في إطلاق سراحنا مرتين في اليوم (يمكن العثور على هذا في المقال من قبل مهندس ضمان الجودة لدينا إيليا كودينوف "
كيف ظللنا على قيد الحياة لمدة
عامين في ظل ظروف إصدارين في اليوم ").
وبالتالي ، فإن احتمال كسر بعض نسخة من اختبار A / B خلال هذا الوقت مرتفع بشكل لا يصدق. وسيؤثر هذا بالتأكيد على تجربة المستخدم وينفي كامل نقطة اختبار A / B للميزة: بعد كل شيء ، قد تظهر الميزة نتائج سيئة في بعض الإصدارات ، ليس لأن المستخدمين لا يحبونها ، ولكن لأنها لا تعمل كما هو متوقع.
إذا كنا نريد أن نتأكد من نتيجة اختبار A / B ، يجب ألا نسمح لأي إصدار من الميزة بالعمل بشكل مختلف عن المتوقع منه.
المشكلة الثالثة هي أهمية اختبارات واجهة المستخدمهناك شيء مثل إصدار اختبار A / B. هذا يعني أن اختبار A / B قد جمع إحصائيات كافية وأن مدير المنتج جاهز لفتح خيار الفوز لجميع المستخدمين. يحدث إصدار اختبار A / B بشكل غير متزامن مع إصدار التعليمات البرمجية ، لأنه يعتمد على تكوين التكوين ، وليس على الرمز.
لنفترض أن البديل غير الخاضع للتحكم فاز وأصبح أفضل. ماذا سيحدث لاختبارات واجهة المستخدم التي غطتها فقط؟ هذا صحيح: سوف يكسرون. ولكن ماذا لو كسروا قبل ساعة من إطلاق المبنى؟ يمكننا إجراء اختبار الانحدار من هذا البناء؟ رقم كما تعلم ، مع الاختبارات المكسورة ، لن تذهب بعيدًا.
لذلك ، يجب أن تكون مستعدًا لإغلاق أي اختبار A / B مقدمًا حتى لا يتعارض مع أداء اختبارات واجهة المستخدم ونتيجة لذلك ، الإصدار التالي من البنية.
الخاتمةالاستنتاج مما سبق واضح: نحن بحاجة إلى تغطية اختبارات A / B باختبارات واجهة المستخدم بالكامل ، كل الخيارات. هل هو منطقي؟ نعم شكرا لكم جميعا ، تباعد!
... نكتة! ليس بهذه البساطة.
واجهة لاختبارات A / B
أول شيء بدا غير مريح هو التحكم في اختبارات A / B والميزات التي تمت تغطيتها بالفعل ، والتي لم يتم بعد. تاريخيا ، نحن ندعو اختبارات واجهة المستخدم وفقا للمبدأ التالي:
- اسم الميزة أو الصفحة ؛
- وصف الحالة
- اختبار
على سبيل المثال ، ChatBlockedUserTest و RegistrationViaFacebookTest وما إلى ذلك. بدافع هنا أيضا اسم اختبار الانقسام بدا غير مريح. أولاً ، ستصبح الأسماء طويلة بشكل لا يصدق. ثانياً ، يجب إعادة تسمية الاختبارات في نهاية اختبار A / B ، وسيكون لذلك تأثير سيئ على مجموعة الإحصائيات التي تأخذ في الاعتبار اسم اختبار واجهة المستخدم.
لا يزال الحصول على الكود لاستدعاء طريقة QaAPI طوال الوقت من دواعي سروري.
لذلك قررنا إزالة جميع المكالمات إلى QaApi :: forceSplitTest () من رمز اختبارات واجهة المستخدم ونقل البيانات المتعلقة بالمكان المطلوب للقوات إلى جدول MySQL. بالنسبة لها ، قدمنا عرضًا تقديميًا عن واجهة المستخدم على مدير السيلينيوم (تحدثت عن ذلك
هنا ).
يبدو شيء مثل هذا:
في الجدول ، يمكنك الإشارة إلى اختبار واجهة المستخدم لمعرفة قوة اختبار A / B وأي مجموعة نريد تطبيقها. يمكنك تحديد اسم اختبار واجهة المستخدم نفسه أو فئة الاختبار أو الكل.
بالإضافة إلى ذلك ، يمكننا الإشارة إلى ما إذا كانت هذه القوة تنطبق على المستخدمين المصرح لهم أو غير المصرح لهم.
بعد ذلك ، قمنا بتدريس اختبارات واجهة المستخدم عند بدء التشغيل للحصول على البيانات من هذا الجدول وإجبار تلك الاختبارات التي ترتبط مباشرة باختبار التشغيل أو بجميع الاختبارات (الكل).
وبالتالي ، تمكنا من جمع كل التلاعب في اختبارات A / B في مكان واحد. من السهل الآن الاطلاع على قائمة اختبارات A / B المغطاة.
هناك قمنا بإنشاء نموذج لإضافة اختبارات A / B جديدة:
كل هذا يتيح لك إضافة وإزالة القوة اللازمة بسهولة وبسرعة دون إنشاء التزام ، في انتظار أن تتحلل إلى كل السحب حيث يتم تشغيل اختبارات واجهة المستخدم ، إلخ.
اختبار واجهة المستخدم العمارة
الشيء الثاني الذي قررنا الانتباه إليه هو مراجعة النهج لكتابة اختبارات واجهة المستخدم لاختبارات A / B.
باختصار ، سوف أخبرك كيف نكتب اختبارات UI منتظمة. الهيكل بسيط ومألوف:
- فصول الاختبار - يصف المنطق التجاري للميزة المغطاة (في الواقع ، هذه هي نصوص اختباراتنا: هل فعلت ذلك ، شاهدت هذا) ؛
- فئات PageObject - يتم وصف جميع التفاعلات مع واجهة المستخدم وتحديد المواقع هناك ؛
- فئات TestCase - هناك طرق شائعة لا تتعلق مباشرة بـ UI ، ولكنها يمكن أن تكون مفيدة في العديد من فئات الاختبار (على سبيل المثال ، التفاعل مع QaAPI) ؛
- الطبقات الأساسية - هناك منطق رفع الجلسة وتسجيل الأشياء وغيرها من الأشياء التي لا تحتاج إلى لمسها عند كتابة اختبار منتظم.
بشكل عام ، هذه العمارة تناسبنا تمامًا. نحن نعلم أنه في حالة تغيير واجهة المستخدم ، يجب تغيير فئات PageObject فقط (في حين يجب ألا تتأثر الاختبارات نفسها). إذا تم تغيير منطق العمل الخاص بميزة ما ، فسنغير السيناريو.
كما كتبت في
مقالة سابقة ، يعمل الجميع مع اختبارات واجهة المستخدم: كل من اللاعبين من قسم الاختبار اليدوي والمطورين. كلما كانت هذه العملية أبسط وأكثر قابلية للفهم ، زاد عدد الأشخاص الذين لا يرتبطون بهم بشكل مباشر في الاختبارات.
ولكن ، كما كتبت أعلاه ، على عكس الميزات الراسخة ، اختبارات A / B إما تأتي أو تذهب. إذا كتبناها بنفس التنسيق مثل اختبارات واجهة المستخدم العادية ، فسيتعين علينا إزالة الشفرة نهائيًا من العديد من الأماكن المختلفة بعد الانتهاء من اختبارات A / B. أنت تفهم أنه بالنسبة لإعادة البناء ، خاصة عندما يعمل كل شيء بدونه ، لا يمكن دائمًا تخصيص الوقت.
ومع ذلك ، لا نريد السماح لفئاتنا بالنمو بطرق غير محددة والمحددات ، مما سيجعل من الصعب استخدام نفس ميزات PageObjects. كيف تجعل حياتك أسهل؟
ثم جاء PhpStorm لإنقاذنا (بفضل اللاعبين من JetBrains لمعرف IDE المريح) ، وهي هذه
الميزة .
باختصار ، يسمح باستخدام علامات خاصة لتقسيم الشفرة إلى المناطق المسماة. حاولنا - وأحببنا ذلك. بدأنا في كتابة اختبارات واجهة المستخدم المؤقتة لاختبارات A / B النشطة في ملف واحد ، مع تقسيم مناطق التعليمات البرمجية إلى مناطق تشير إلى الفئة التي يجب وضع هذا الرمز في المستقبل.
نتيجة لذلك ، بدا رمز الاختبار كالتالي:
يوجد في كل منطقة رمز ينتمي إلى فئة معينة. بالتأكيد في IDEs الأخرى هناك شيء مماثل.
وبالتالي ، قمنا بتغطية جميع المتغيرات لاختبار A / B بفئة اختبار واحدة ، ووضع كل من أساليب PageObject والمواقع هناك. وبعد الانتهاء ، قمنا أولاً بإزالة الخيارات الخاسرة من الفصل ، ثم قمنا بسهولة بتوزيع الكود المتبقي في الفئات المطلوبة وفقًا لما هو موضح في المنطقة.
كيف يمكننا الآن إغلاق اختبارات A / B
لا يمكنك فقط أخذ وتغطية جميع اختبارات A / B باختبارات واجهة المستخدم في وقت واحد. من ناحية أخرى ، لا توجد مثل هذه المهمة. يكمن التحدي فيما يتعلق بالأتمتة في تغطية الاختبارات المهمة وطويلة الأمد بسرعة.
ومع ذلك ، قبل إصدار أي اختبار ، حتى أصغر اختبار A / B ، أريد أن أكون قادرًا على تشغيل جميع اختبارات واجهة المستخدم على الإصدار الفائز والتأكد من أن كل شيء يعمل كما ينبغي ، ونقوم بتكرار وظائف العمل عالية الجودة لـ 100٪ من المستخدمين.
الحل المذكور أعلاه مع جدول MySQL غير مناسب لهذا الغرض. الحقيقة هي أنه إذا أضفت قوة هناك ، فستبدأ على الفور في تشغيل جميع اختبارات واجهة المستخدم. بالإضافة إلى التدريج (بيئة ما قبل الإنتاج الخاصة بنا ، حيث نقوم بتشغيل مجموعة كاملة من الاختبارات) ، سيؤثر هذا أيضًا على اختبارات واجهة المستخدم التي تم إطلاقها مقابل فروع المهام الفردية. سيعمل الزملاء من قسم الاختبار اليدوي على نتائج عمليات الإطلاق هذه. وإذا كان اختبار A / B الفاشل يحتوي على خطأ ، فسوف تسقط اختبارات مهامهم أيضًا ويمكن للاعبين أن يقرروا أن المشكلة في مهمتهم وليس في اختبار A / B. لهذا السبب ، قد يستغرق الاختبار والتجربة الكثير من الوقت (لن يكون هناك أحد راضٍ).
لقد نجحنا في إجراء تغييرات طفيفة حتى الآن ، مضيفًا القدرة على تحديد البيئة المستهدفة إلى الجدول:
يمكن تغيير هذه البيئة أثناء الطيران في سجل حالي. وبالتالي ، لا يمكننا إضافة القوة إلا للمرحلة ، دون التأثير على نتائج اجتياز الاختبارات على المهام الفردية.
لتلخيص
لذلك ، قبل بدء هذه القصة ، غطت اختبارات واجهة المستخدم لدينا فقط المجموعات (التحكم) الرئيسية من اختبارات A / B. لكننا أدركنا أننا نريد المزيد ، وتوصلنا إلى استنتاج أنه من الضروري أيضًا تغطية الإصدارات الأخرى من اختبارات A / B.
باختصار:
- أنشأنا واجهة للتحكم المريح في تغطية اختبارات A / B ؛ نتيجة لذلك ، لدينا الآن جميع المعلومات حول تشغيل اختبارات واجهة المستخدم باستخدام اختبارات A / B ؛
- لقد طورنا لأنفسنا طريقة لكتابة اختبارات واجهة المستخدم المؤقتة مع تدفق بسيط وفعال لإزالتها أو نقلها إلى صفوف الدائمين ؛
- لقد تعلمنا كيفية اختبار إصدارات اختبارات A / B بسهولة ودون ألم ، دون التدخل في اختبارات واجهة المستخدم الأخرى قيد التشغيل ، ودون التزامات غير ضرورية في Git.
كل هذا جعل من الممكن تكييف التشغيل الآلي للاختبار مع الميزات المتغيرة باستمرار ، والتحكم بسهولة وزيادة مستوى التغطية ، وليس الاكتظاظ برمز قديم.
هل لديك أي خبرة في إلقاء نظرة فوضوية للوهلة الأولى على أمر خاضع للرقابة وتبسيط حياتك لنفسك وزملائك؟ شاركه في التعليقات. :)
شكرا لاهتمامكم! وسنة جديدة سعيدة!