مرحبا بالجميع ، اسمي سيرجي. أقوم باختبار الواجهة الأمامية لـ Yandex.Market. أعلم أنه من بين قراء هبر ، يوجد العديد من المتخصصين في تكنولوجيا المعلومات الذين يرتبطون بطريقة أو بأخرى بعملية الإصدار والاختبار. لدي سؤال لك. هل حدث في ممارستك أن الميزات لا تدوم لفترة طويلة في الإنتاج؟ هل أنت على علم بالإصدارات المتضخمة والشيكات الحجمية؟
أعتقد أن الجميع كان هذا. جئت إلى ياندكس قبل 3 سنوات ، كان فريقنا شابًا جدًا ، ولم يتم تأسيس العمليات بالكامل. لقد واجهت هذه المشاكل وجهاً لوجه.
كما كان
في ذلك الوقت ، لم يكن لفرق منتجاتنا منطقة مسؤولية محددة ولم يشاركوا إلا في المشروع الذي تم إنشاؤه من أجله. ثم انهاروا. كان الاختبار أيضًا غير مرتبط بفرق التطوير. كانت موجودة كخدمة ومتصلة بالمشروع حسب الحاجة.
تم فحص المهام فقط عن طريق اليدين ، وكانت اختبارات الاندماج غير مستقرة ، وكانت النسبة المئوية للتغطية مع الاختبارات الذاتية صغيرة. استمر الفحص لفترة طويلة جدًا. مجموعة المهام الجاهزة للحساب كانت تنمو باستمرار ويمكن أن تصل إلى أحجام هائلة.
أما بالنسبة للإصدارات ، فقد شارك أحد المديرين في التجميع والحساب. لقد عقدنا اجتماعات مع جميع المديرين وقررنا ما الذي سيأتي في الإصدار التالي وما الذي يمكن تأجيله.
قاموا بفحص النشرات عشوائياً: من كان لديه الوقت للتحقق منها ، فتحقق. كان التركيز على اختبار الانحدار اليدوي ، والذي قد يستمر عدة أيام. وهذا على الرغم من حقيقة أن الإصدار كان يدير حزمة من الاختبارات الذاتية وكان هناك قسم كتب ودعمها.
لذلك ، تكمن المشكلة التي تم حلها في الاختبار ويمكن اختبارها حتى يومين. ثم حصلت على الإصدار ، تم فحصه لمدة 4 أيام أخرى. في همز ، تحولت المهمة في أحسن الأحوال في غضون أسبوع. عدد قليل من الناس أعجبهم ، كان من الضروري تغيير شيء ما. والشيء الأكثر أهمية للتغيير هو العمليات.
كفاف
أول ما فعلناه هو إدخال تقسيم إلى معالم - فرق من المتخصصين من مختلف المجالات. على عكس الفرق السابقة ، لا تنفصل الخطوط بعد نهاية المشروع. يواصلون توليد مشاريع وأفكار جديدة ضمن مجال مسؤوليتهم.
من 1 إلى 3 اختبار هي المسؤولة عن الاختبار في كل دائرة. كل اختبار الدوائر المسؤولة موجود في جميع مراحل تطوير المنتج من فكرة إلى استخلاص المعلومات.
في الخدمة
لهيكلة عمل الإصدارات ، قدمنا دورين في فريق الاختبار لدينا: معالج الإصدار واختبار الإصدار. بصفتك سيد الإصدار ، لدينا 4 اختبار في الخدمة في وقت واحد ، والجميع يشاركون في مهمة الإصدار. لكل من هذه الأدوار ، قمنا بتنظيم جدول واجب.
المهام التي تنشأ أثناء الخدمة لها الأولوية على اختبار ميزات المنتج داخل الدوائر. بحيث لا يتعين على المختبرين الانتظار لفترة طويلة دون انقطاع ، يتم ترتيب واجب الإفراج على النحو التالي: نوبة واحدة في الخدمة من الاثنين إلى الأربعاء ، والثانية - من الأربعاء إلى نهاية الجمعة. في كل وردية - 4 أشخاص ، 2 أشخاص لكل منصة.
الوثائق
وماذا عن الوثائق؟ ليس لدينا الكثير ، لكنه كذلك. على سبيل المثال ، عند طرح الميزات ، نحدد مع المطورين والمدير العدد الأمثل للاختبارات التلقائية. إذا لم نتمكن من أتمتة شيء ما ، أو إذا كانت إحدى الميزات تتطلب النشر الفوري دون اختبارات تلقائية ، فإننا نكتب حالة في مجموعة الاختبارات لجميع حالات التحقق من السوق ، وإذا لزم الأمر ، فقم بإدراجه في مجموعة اختبار إصدار اختبار الانحدار.
إذا تحققنا من إصلاحات الأخطاء ورأينا أن الاختبار التلقائي لم يكن مكتوبًا على هذا الخطأ ، فسنقوم أيضًا بتعيين مهمة تطويره ، وقوائم التحرير على الفور مع الاختبار المكتوب عليها.
عند وضع كل تجربة ، لدينا قائمة تدقيق ، حيث أننا لا نعرف مقدمًا ما إذا كانت التجربة ستنجح أم لا.
قائمة التحقق هي مجموعة من الاختبارات الإيجابية على ميزات التجربة. يستخدمه اختبار الإصدار مع كل إصدار أثناء عمل التجربة. يمكن أن تكون قائمة المراجعة هذه فارغة لمهام الأتمتة المستقبلية إذا نجحت التجربة وقمنا بتوزيعها على 100٪ من المستخدمين.
عند فحص الإصدارات ، نستخدم مجموعات اختبار مختلفة بناءً على مدى تعقيد الإصدار وكامله. لدينا أجنحة وأجنحة اختبار صغيرة مع أقصى عدد من حالات الاختبار. أي مجموعة اختبار للاستخدام ، يقرر اختبار الإصدار.
في بعض المناطق ، نستخدم أيضًا قائمة التحقق من الاختبارات الإيجابية للمطورين. مع ذلك ، يمكن للمطور التحقق من المهمة بنفسه ويتوقع الاختناقات في تطوير الميزات. إذا تغير المختبر في المشروع ، فسيساعد هذا الاختصاص الجديد في الانضمام سريعًا إلى المشروع. تتم كتابة قوائم المراجعة قبل بدء التطوير ، فور جدولة المهمة.
هذا كل شيء للأرصفة.
كيف نختبر المهام
نحن نستخدم تقنيات تصميم الاختبار المختلفة: فئات التكافؤ ، والقيم الحدودية ، والاختبار الزوجي ، وسيناريوهات المستخدم. خبرة المختبر هي أيضا مهمة جدا. السوق عبارة عن آلة كبيرة ، وتحتاج إلى معرفة كيفية عمل جميع أجزائه من أجل إصلاح أو تحسين شيء ما. على سبيل المثال ، لدينا 4 أنواع من بطاقات السلع و 6 أنواع من مشكلات السلع. دون معرفة ذلك ، من المستحيل اختبار مهمة تغيير هذه الصفحات نوعيًا.
لعبت دورا هاما في فحص المهام التي كتبها autotests. نحن ندير اختبارات تلقائية وظيفية لكل مهمة ننفذها ، ونقوم بتحليل الأعطال والإبلاغ عن الأخطاء.
في الحالات الخاصة ، عندما تؤثر المهمة على العديد من مكونات السوق ، نقوم أيضًا بإجراء اختبارات الشاشة - فهي تساعدنا على اكتشاف الأخطاء.
عند اكتمال التحقق من المهمة ، نترك تعليقًا مفاده أن كل شيء على ما يرام وأنه يمكن تنفيذ المهمة. في التعليق ، نشير إلى عدد الاختبارات التي تمت كتابتها ، أو نقول أن الاختبارات ليست ضرورية ، ونقوم بترجمة المهمة إلى الحالة "في انتظار الإصدار".
بعد ذلك ، يتم التقاط المهمة من قِبل معالج الإصدار ، ويتم إرسالها إلى الإصدار مع مهام أخرى مثبتة. نحاول تعبئة الإصدارات مع المهام من أجل التحقق منها في 8 ساعات بأيدي 4 اختبارين: 2 للإصدار touch من السوق و 2 لإصدار سطح المكتب. هدفنا هو طرح ما لا يقل عن 5 إصدارات. وهذا هو ، وسرعة تسليم المهمة إلى همز مقارنة بما كانت عليه ، وزيادة 5 مرات.
كيف نتحقق من النشرات؟
نبدأ في التحقق من الإصدار عن طريق التحقق من اختبارات السيارات واختبارات الشاشة. بعد النظر في التقارير ، يمكننا على الفور الحصول على ما يصل إلى 90 ٪ من المشاكل. نحن نحلل تعطل الاختبارات: إذا كانت مرتبطة بأخطاء أو تم كسرها بواسطة تذكرة في الإصدار ، فنحن نبحث عن مهمة يتم فيها إعادة إنتاج هذا التعطل ، ونطلب إصلاحه. إذا لم يتم ذلك ، فلن تقع المهمة في الإصدار.
يمكن أن تموت الاختبارات أيضًا من تلقاء نفسها. في هذه الحالة ، نقوم بإيقاف تشغيل الاختبار من تشغيل الاختبار التلقائي وبدء مهمة إصلاحه وإنشاء mox إذا لزم الأمر.
اعتمادًا على المهام في الإصدار ، يمكننا استخدام مجموعة أدوات اختبار الإصدار الكامل ، أو يمكننا رفض الانحدار اليدوي تمامًا. يتم اتخاذ القرار من قبل اختبار الإفراج.
إذا كان الإصدار يحتوي على عدة تعديلات صغيرة ، فسيتم إجراء فحص المهام محليًا ، ويتم استبدال الانحدار اليدوي بالتحقق من تقارير الاختبار التلقائي.
بغض النظر عن اكتمال الإصدار والمهام ، يقوم فريق اختبار الإصدار بفحص التجارب التي يتم عرضها حاليًا على نسب مئوية مختلفة من المستخدمين في الإنتاج. يتم استخدام قائمة مرجعية مكتوبة بواسطة اختبار التجربة.
عند الانتهاء من جميع عمليات الفحص ، يترك اختبار الإصدار تعليقًا حيث يسرد جميع أنشطة الإصدار ، وإذا لزم الأمر ، يكتب المهام لإصلاح الاختبارات المعطلة.
يقوم مدير الإصدار بتحليل تقارير إطلاق النار (اختبار الحمل) ، وإذا رأى زيادة في الأخطاء ، فقم بإعادة تشغيلها. إذا لم ينجح ذلك ، فهو يبحث عن الجاني أو يطلب المساعدة من مطور الخدمة.
إذا كان كل شيء على ما يرام مع نتائج التصوير ، فإن معالج الإصدار يفتح مخططات السوق ويبدأ في طرح الإصدار في الإنتاج. تحتاج الرسوم البيانية إلى مراقبتها حتى لا تفوت نمو الأخطاء.
إذا كان الإصدار هو السبب في نمو الأخطاء ، فسوف يتراجع الإصدار الرئيسي ويفهم الأسباب. إذا كانت الجداول الزمنية طبيعية ، فإنه يكمل الإصدار ويبدأ في جمع نسخة جديدة من المهام الجاهزة.
السعي نحو الأفضل
على الرغم من حقيقة أن كل شيء يعمل بشكل جيد ، يجب أن تسعى دائمًا نحو الأفضل. نحن على وشك تسليم مستمر في المستقبل أكثر إشراقًا ، حيث سيتم اختبار المهام وتنفيذها في الإنتاج بالتوازي مع بعضها البعض ، دون مرحلة وسيطة في شكل إصدار. سيسمح لك ذلك بعدم تشتيت انتباهك عند مشاهدة الإصدارات والإسراع بشكل كبير في تقديم الوظائف للمستخدمين.
قررنا التبديل إلى CD على مراحل. كانت الخطوة الأولى هي إدخال monorepository ، والذي يجمع بين طرح الوظيفة على كلتا المنصتين - اللمس وسطح المكتب - في إصدار واحد. هذا النهج له مزايا لكل من التطوير والاختبار. نقضي وقتًا أقل بكثير في اختبار المكون. المهام الآن في مكان واحد ، مما يجعل التنقل أسهل. من الأسهل بالنسبة للمدير التنقل ، لأنه يعرف التوقيت الدقيق لبدء تنفيذ مهمة الإصدار في المنتج ، وليس هناك رد فعل عكسي بين طرح المنصات.
ستكون الخطوة التالية على القرص المضغوط هي إدخال "الجرح الأخضر". لكل تذكرة يتم فحصها بواسطة المختبر ، سيتم إطلاق نوعين من الاختبارات لكلتا المنصتين: الاختبارات الوظيفية واختبارات الشاشة. جميع الاختبارات سوف تحتاج إلى moki. إذا فشلت اختبارات أحد المنصات ، فلن يتم التحقق من المهمة. إذا تعطل الاختبار ، فستحتاج إلى فهم سبب حدوث ذلك. فقط في حالة عدم وجود اختبارات السقوط والإكمال الناجح لجميع الشيكات ، سيتم إرسال المهمة إلى المنتج.
شكرا لاهتمامكم آمل أن تكون تجربتنا مفيدة لك ، أنا أنتظرك في التعليقات.