مع هذه المقالة ، نفتح سلسلة من المنشورات حول كيفية أتمتة عملية الاختبار اليدوي لنظام معلومات كبير في أحد المشاريع الرئيسية لـ LANIT وماذا جاء منها.

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

مصدر

الجزء 1 - التنظيمية والإدارية. لماذا نحتاج الأتمتة. تنظيم عملية التطوير والإدارة. تنظيم الاستخدام

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

في لحظة معينة ، عندما أصبح النقر فوق الماوس في الوضع اليدوي أمرًا لا يطاق تمامًا ، قررنا تشغيله تلقائيًا. هذا ما فعلوه من خلال تطوير خدمة منفصلة تعتمد على java + selenium + selenide + selenoid ، والذي يُطلق عليه أيضًا "إطار الاختبار" أو ببساطة "Autotests" .

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

أنا فريق وقائد فريق الفريق الثاني ، الذي اعتمد إطار النموذج الأولي للتحجيم (في مايو 2018).

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

يؤدي

تم تشغيل حوالي 1500 سيناريو اختبار: في كل اختبار ، من 200 إلى 2000 من عمليات المستخدم.

تبلغ السعة الإجمالية للخدمة ما يصل إلى 60 متصفحا يعمل في وقت واحد ، وهذا ليس الحد الأقصى (يمكن زيادة العدد بمقدار 5 مرات بسبب الأجهزة الافتراضية).
المدة الكلية للانحدار الكامل لا تزيد عن 3 ساعات ، واختبار PreQA أقل من ساعة.

تم تنفيذ مجموعة واسعة من الميزات:

• الاستخدام المحلي (التنفيذ في الوقت الحقيقي) والبعيدة (عبر خطط الخيزران) ؛
• الحد من تكوين اختبارات التشغيل عن طريق التصفية ؛
• تقرير مفصل بنتائج كل خطوة من سيناريو الاختبار (من خلال إطار ألور) ؛
• تنزيل الملفات وتحميلها من / إلى المتصفح ، يليها التحقق من نتائج معالجتها من حيث شكل ومحتويات الملفات ؛
• المحاسبة والسيطرة على الطبيعة غير المتزامنة للواجهة الزاوي. بما في ذلك التحكم في الطلبات المعلقة (طلب معلق) بين الخدمات الزاوية و REST ؛
• السيطرة على سجلات المتصفح ؛
• تسجيل اختبار الفيديو ؛
• إزالة لقطة الصفحة عند نقطة "السقوط" للاختبار ؛
• نقل الحدث في ELK ؛
• أكثر من ذلك بكثير على الأشياء الصغيرة ...

لماذا كل هذا مطلوب؟

في البداية ، كان الغرض من النظام بسيطًا وواضحًا.

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

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

في عملية الأتمتة ، تم الكشف عن الفروق الدقيقة المختلفة التي تتطلب استخدام الحلول المختلفة.

على سبيل المثال ، يمكن أن يحتوي البرنامج النصي على ما يصل إلى مئات العمليات المنفصلة ، بما في ذلك العمليات المثيرة للاهتمام مثل: "تنزيل ملف EXCEL بالبيانات والتحقق من أن النظام يعالج كل سجل من الملف" (لحل هذه المشكلة ، استغرق الأمر عدة خطوات لإعداد البيانات ثم تحقق من نتيجة التحميل إلى النظام). والآن نضيف قيودًا على إعادة استخدام بيانات الاختبار: يجب أن تكون بيانات الاختبار الخاصة بالإنجاز الناجح لمعظم سيناريوهات الاختبار "جديدة" ولا يتم استخدامها مسبقًا في سيناريوهات مماثلة (أثناء الاختبارات ، تتغير حالة البيانات في النظام ، لذلك لا يمكن إعادة استخدامها من أجل الشيكات نفسها).

مصدر

في مرحلة ما ، لم يعد الاختبار اليدوي للنظام كجزء من الانحدار فعالًا من حيث التكلفة وسريعًا بدرجة كافية ، وقرروا تشغيله تلقائيًا من خلال واجهة مستخدم الويب.

بمعنى آخر ، تفتح مجموعة الاختبار الوظيفية "الصفحة" ، وتختار "مجموعة الاختبار" ، وتضغط على الزر "تنفيذ" (استخدمنا الخيزران). ثم يقوم Autotests (المشار إليها فيما يلي باسم Autotests. حدد المنتج الذي تم إنشاؤه للاختبار بشكل عام) بمحاكاة تصرفات المستخدمين في النظام تلقائيًا من خلال المستعرض ("اضغط" على الأزرار اللازمة ، وأدخل القيم في الحقول ، وما إلى ذلك) ، عند الانتهاء ، قم بعرض تقرير مفصل عن جميع الخطوات والإجراءات المكتملة ونتائج التحقق (مراسلات رد الفعل المتوقع للنظام على سلوكه الفعلي).

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

أهداف

كان من الضروري تخفيض تكاليف العمالة بشكل كبير لإجراء اختبارات نهاية - 2 وزيادة سرعة الانحدار الكامل والمخفض من حيث الحجم.

المهام

تمت صياغة المهمة الرئيسية للتطوير بكل بساطة - للتشغيل الآلي على مدار 6 أشهر 1000 سيناريوهات اختبار ذات أولوية قصوى.

تراوح العدد المتوقع لإجراءات الاختبار الأساسية من 100 إلى 300 ، مما أعطانا حوالي 200 ألف طريقة اختبار مع 10-20 سطرًا من التعليمات البرمجية ، دون مراعاة الفئات العامة والمساعِدة للمساعدين ومقدمي البيانات ونماذج البيانات.

وبالتالي ، تبين أنه مع مراعاة القيود الزمنية (130 يوم عمل) ، كان من الضروري إجراء 10 اختبارات على الأقل يوميًا وفي الوقت نفسه ضمان أهمية الاختبارات الذاتية المنفذة مع مراعاة التغييرات في النظام (النظام قيد التطوير بنشاط).

وفقًا لتقديرات الخبراء ، كانت العمالة المطلوبة لتطوير اختبار ذاتي واحد 4-8 ساعات. لذلك لدينا فريق من 5 أشخاص على الأقل (في الواقع ، في ذروة تطوير الاختبارات الذاتية ، كان لدى الفريق أكثر من 10 مهندسين للأتمتة).

المهام التي تحتاج إلى حل كانت مفهومة أيضا.

• تكوين العمليات والأمر:
• تحديد عملية التفاعل مع العميل (مجموعة الاختبارات الوظيفية) ، وإصلاح تنسيق وصف حالة الاختبار كمدخلات لفريق الأتمتة ؛
• تنظيم عملية التطوير والصيانة ؛
• تشكيل فريق.
  
• تطوير الاختبارات التلقائية باستخدام الميزات التالية:
• انقر تلقائيًا على الأزرار الموجودة في المتصفح مع إجراء فحص أولي لوجود العناصر والمعلومات اللازمة على الصفحة ؛
• توفير العمل مع عناصر معقدة مثل Yandex.Map ؛
• لضمان تحميل الملفات التي تم إنشاؤها تلقائيًا إلى النظام ، لضمان تنزيل الملفات من النظام مع التحقق من تنسيقها ومحتواها.
• توفير سجل من لقطات المتصفح ، وأشرطة الفيديو والسجلات الداخلية.
• لتوفير القدرة على الاندماج مع الأنظمة الخارجية مثل خادم البريد ، ونظام تتبع المهام (JIRA) للتحقق من عمليات التكامل بين النظام المختبر والأنظمة الخارجية.
• تقديم تقرير موثق عن جميع الإجراءات المتخذة ، بما في ذلك عرض القيم التي تم إدخالها والتحقق منها ، وكذلك جميع الاستثمارات اللازمة.
• إجراء اختبارات في وحدة التخزين المطلوبة في الوضع الموازي.
• نشر autotests في البنية التحتية الحالية.
• قم بتحسين نصوص الاختبار المؤتمتة بالفعل لمفهوم الهدف الثابت (سرعة التنقيح - حوالي 50 اختبارًا في الأسبوع).

كما ذكرت في المقدمة ، في البداية ، كان لدينا نموذج أولي للعمل MVP تم تنفيذه من قبل فريق آخر ، والذي كان يجب زيادته من 20 اختبارًا إلى 1000 ، وإضافة ميزات جديدة على طول الطريق ، وضمان قابلية التوسع والمرونة المقبولة لإجراء التغييرات.

إن وجود نموذج أولي عامل بالإضافة إلى المدخلات قد أعطانا كومة تكنولوجية ، والتي تشمل: Java SE8 و JUnit4 و Selenium + Selenide + Selenoid و Bamboo كـ "عداء" للاختبارات و "منشئ" لتقارير Allure. نظرًا لأن النموذج الأولي يعمل بشكل جيد ويوفر الوظيفة الأساسية اللازمة ، فقد قررنا عدم تغيير المكدس التكنولوجي ، ولكن التركيز على تطوير قابلية تطوير الحل وزيادة الاستقرار وتطوير الميزات المطلوبة المفقودة.

في الأساس ، بدا كل شيء ممكنًا ومتفائلًا. علاوة على ذلك ، تعاملنا تمامًا مع المهام في وقت معين.

فيما يلي وصف الجوانب التكنولوجية وعملية تطوير الاختبارات التلقائية.

وصف Autotests. قصص المستخدم والميزات

مصدر

تنفذ Autotests المجموعة التالية من قصص المستخدمين في سياق استخدامها من قبل مجموعة الاختبار:

• التشغيل الآلي للاختبار اليدوي.
• الانحدار الكامل التلقائي.
• مراقبة الجودة للتجمعات في سلسلة CI \ CD.

ستتم مناقشة تفاصيل التنفيذ والقرارات المعمارية في الجزء 2 - الفني. الهندسة المعمارية والمكدس الفني. تفاصيل التنفيذ والمفاجآت الفنية .

الاختبار التلقائي واليدوي (قصص المستخدم)

كاختبار ، أرغب في إجراء اختبار E2E المستهدف ، والذي سيتم إجراؤه دون مشاركتي المباشرة (في الوضع التلقائي) وسأزودني بتقرير مفصل في سياق الخطوات المتخذة ، بما في ذلك البيانات المدخلة والنتائج التي تم الحصول عليها ، وكذلك:

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

الانحدار الكامل التلقائي

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

مراقبة جودة التجميع في سلسلة CI \ CD

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

نفذت الميزات الأساسية

مصدر

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

استخدام المحلية والبعيدة

عرضت وظيفة خيارين لتشغيل Autotests - المحلية والبعيدة.

في الوضع المحلي ، قام المختبر بإجراء الاختبار التلقائي المطلوب في مكان عمله ، وفي الوقت نفسه يمكنه ملاحظة ما يحدث في المتصفح. تم الإطلاق من خلال "المثلث الأخضر" في IntelliJ IIDEA -). كانت الوظيفة مفيدة للغاية في بداية المشروع للتصحيح والعروض التوضيحية ، ولكن الآن يتم استخدامها فقط من قبل مطوري الاختبارات التلقائية.

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

تم تنفيذ الوظيفة باستخدام متغير البيئة MODE = REMOTE | LOCAL ، بناءً على تهيئة مستعرض ويب محلي أو بعيد في سحابة Selenoid .

الحد من تكوين اختبارات التشغيل عن طريق التصفية

تتيح هذه الوظيفة الحد من تركيبة الاختبارات الجارية في وضع الاستخدام عن بُعد لراحة المستخدمين وتقليل وقت الاختبار. يستخدم الترشيح على مرحلتين. تقوم الخطوة الأولى بحظر تنفيذ الاختبارات استنادًا إلى متغير FILTER_BLOCK ويتم استخدامها أساسًا لاستبعاد مجموعات كبيرة من الاختبارات من التشغيل. الخطوة الثانية "يتخطى" فقط الاختبارات التي تطابق المتغير FILTER.

يتم تحديد قيمة عوامل التصفية كمجموعة من التعبيرات العادية REGEXP1 ، ... ، REGEXPN ، والتي يتم تطبيقها بواسطة مبدأ "OR".

عند البدء في الوضع اليدوي ، طُلب من المختبر تعيين متغير بيئة خاص كقائمة من التعبيرات العادية التي تنطبق على التعليقات التوضيحية الخاصة @ Filter (قيمة السلسلة) ، والتي شرحت جميع طرق الاختبار في فئات الاختبار. لكل اختبار ، هذا التعليق التوضيحي فريد من نوعه ويتم إنشاؤه على أساس مجموعة من العلامات مفصولة بشرطة سفلية. نستخدم القالب الأدنى التالي SUBSYSTEM_FUNCTION_TEST-ID_ {DEFAULT} ، حيث تكون علامة DEFAULT للاختبارات المضمنة في الانحدار الليلي التلقائي.

يتم تنفيذ الوظيفة من خلال ملحق مخصص لفئة org.junit.runners.BlockJUnit4ClassRunner (سيتم تقديم التفاصيل في الجزء 2-1 من متابعة هذه المقالة)

توثيق التقرير بالنتائج لجميع الخطوات

يتم عرض نتائج الاختبار لجميع إجراءات الاختبار (الخطوات) مع جميع المعلومات المطلوبة المتوفرة في Allure Framework. لإدراجها لا معنى له. هناك معلومات كافية على الموقع الرسمي وعلى شبكة الإنترنت ككل. لم تكن هناك مفاجآت باستخدام Allure Framework ، وبصفة عامة أوصي به للاستخدام.

الوظائف الرئيسية المستخدمة هي:

• عرض كل خطوة اختبار (اسم الخطوة يتوافق مع اسمها في مواصفات الاختبار - اختبار البرنامج النصي) ؛
• عرض معلمات الخطوة في نموذج قابل للقراءة من قبل الإنسان (من خلال التنفيذ المطلوب لأسلوب toString لجميع القيم المرسلة) ؛
• إرفاق لقطات ومقاطع فيديو وملفات إضافية مختلفة بالتقرير ؛
• تصنيف الاختبارات حسب الأنواع والأنظمة الفرعية ، بالإضافة إلى ربط الاختبار التلقائي بمواصفات الاختبار في نظام إدارة حالة اختبار Test Link من خلال استخدام التعليقات التوضيحية المتخصصة.

قم بتنزيل وتحميل الملفات من / إلى المتصفح مع التحقق والتحليل اللاحقين

يعد العمل مع الملفات جانبًا مهمًا للغاية في البرامج النصية للاختبار. كان من الضروري توفير كل من تحميل الملفات المختلفة ، والتنزيل.

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

تحميل الملفات يعني تنزيل الملفات بالضغط على "الزر" في المستعرض إلى دليل محلي مع "نقل" هذا الملف اللاحق إلى الخادم حيث تم تشغيل الاختبارات التلقائية (الخادم الذي تم تثبيت وكيل Bamboo البعيد عليه). علاوة على ذلك ، تم تحليل هذا الملف وتحليله من حيث الشكل والمحتوى. كانت أنواع الملفات الرئيسية هي ملفات EXCEL و PDF.

تبين أن تنفيذ هذه الوظيفة ليس مهمة تافهة ، ويعزى ذلك في المقام الأول إلى الافتقار إلى إمكانيات معالجة الملفات القياسية: في الوقت الحالي ، يتم تنفيذ الوظيفة فقط لمتصفح Chrome من خلال صفحة خدمة "chrome: // Downloads /".

سأخبرك بالتفصيل عن تفاصيل التنفيذ في الجزء الثاني.

المحاسبة والتحكم في الطبيعة غير المتزامنة للواجهة الزاوي. في انتظار التحكم في الطلب بين الخدمات الزاوية و REST

نظرًا لأن هدف الاختبار الخاص بنا كان مبنيًا على Angular ، كان علينا أن نتعلم "القتال" مع الطبيعة غير المتزامنة للواجهة الأمامية والمهلة الزمنية.

بشكل عام ، بالإضافة إلى org.openqa.selenium.support.ui.FluentWait ، نستخدم طريقة انتظار مصممة خصيصًا للتحقق من خلال Javascript للتفاعلات "غير المكتملة" مع خدمات REST الأمامية ، وبناءً على هذه المهلة الديناميكية ، تحصل الاختبارات على معلومات حول ما إذا كان يجب متابعتها ثم انتظر لفترة أطول قليلا.

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

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

التحكم في سجل المتصفح

تمت إضافة وظيفة التحكم في سجل المتصفح للتحكم في الأخطاء في صفحات مستوى SEVERE لتلقي معلومات إضافية للاختبارات التي تم إسقاطها ، على سبيل المثال ، لمراقبة أخطاء مثل "... فشل تحميل المورد: استجاب الخادم بحالة 500 (خطأ خادم داخلي)".

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

تسجيل فيديو للاختبار وإزالة لقطة الصفحة عند نقطة "السقوط" للاختبار

يتم تنفيذ الوظائف لراحة تشخيص الاختبارات التي تم إسقاطها وتحليلها.

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

تمرير الأحداث إلى ELK

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

منظمة التنمية

مصدر

فريق التطوير

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

وبالتالي ، كان من الضروري اتخاذ 6 مطوري جافا (في الواقع ، في ذروة تطوير الاختبارات الذاتية ، تجاوز الفريق 10 مهندسين التشغيل الآلي).

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

يتطلب الاعتماد على المبتدئين الصغار إدخال آليات التعويض في شكل عرض وظيفي محدد ، وجدول عمل واضح وتقسيم التطبيق إلى مجالات وظيفية منفصلة (المزيد حول هذا في الجزء 2 - الهندسة المعمارية التقنية والمكدس التقني. تفاصيل التنفيذ والمفاجآت التقنية ).

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

عملية التنمية

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

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

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

تنقضي مراجعة الكود بالضرورة خطوة ، وإذا كانت النتائج (الكود) في هذه الخطوة لا تتوافق مع اصطلاحات الكود والمتطلبات المعمارية ، تُرجع المهمة للمراجعة. مراجعة الكود تجعل قيادة الفريق.

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

نقطة مثيرة للاهتمام: في عملية التطوير ، تبيّن غالبًا أنه لا يمكن اجتياز الاختبار التلقائي بنجاح ، لأن البرنامج النصي للاختبار قديم أو أن النظام الفرعي قيد الاختبار يحتوي على خطأ تم التغلب عليه من خلال الحلول البديلة أثناء الاختبار اليدوي. في مثل هذه الحالات ، توقف تطوير الاختبار التلقائي حتى اللحظة التي تفهم فيها مجموعة الاختبارات الوظيفية ما إذا كان هذا خطأ أو ميزة ، وتصحيح المواصفات و / أو النظام.

تم إجراء تقييم مدى تعقيد التنفيذ في "خطوات الاختبار" ، والتي تم تحديدها بالفعل بواسطة سيناريو الاختبار الآلي عن طريق الجمع البسيط للخطوات. في الممارسة العملية ، كان هذا هو مجموع كل الفقرات في حالة الاختبار.

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

مواصفات مهام التطوير

جاءت مهام التطوير الأولية في الأعمال المتأخرة كمواصفات اختبار (نصوص اختبار) من مجموعة الاختبارات الوظيفية ، والتي كانت بمثابة مستخدم داخلي وأصحاب مصلحة في الاختبارات التلقائية.

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

من الضروري استخدام الضرورة في وصف خطوات حالات الاختبار (افتح الصفحة ، وأدخل القيم في الحقول ، وما إلى ذلك) ، والتي هي في جوهرها متطلبات للتحقق من وظائف النظام. إذا كنت بحاجة إلى تحديد معلومات إضافية (مساعدة) ، فيجب عليك وضع علامة صريحة عليها على أنها "معلومات إضافية" / "ملاحظة" (من المهم ألا يكون لدى الفريق أي لبس فيما إذا كانت هذه المعلومات هي دليل للعمل أو يتم توفيرها كمرجع فقط).

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

لتفادي تكرار مجموعات الخطوات في حالات الاختبار ، من الممكن إعادة استخدام خطوات حالة الاختبار (حالة المانح) بالكامل كجزء من خطوات حالة اختبار أخرى (الحالة "الرئيسية"). وبالتالي ، في مواصفات حالة الاختبار "الرئيسية" ، سُمح لها ، كإحدى الخطوات ، بالحاجة إلى إكمال حالة الجهة المانحة كـ "إكمال جميع الخطوات من الحالة X" (في هذه الحالة ، لا يُسمح بالتنفيذ الجزئي للخطوات من حالة الجهة المانحة).

مستودع المستودع

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

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

الميزات:

(+) عملية بسيطة للتسليم المستمر للوظائف للفرق الصغيرة ؛
(+) يسمح لك بنشر وظائف أثناء تطويرها دون الحاجة إلى تخطيط الإصدار على مستوى الرمز ؛
(+) يتيح لك "اللحاق" بالتطور الحقيقي دون تقديم تأخير الإصدار ؛
(-)يتم دعم إصدار واحد فقط من الإطار (الحالي) ؛
(-) في الإصدارات السابقة من AutoTests ، يتم دعم أخطاء الإصلاح فقط.

نتيجة لذلك ، توصلنا إلى القواعد التالية.

المطور

• خذ الفرع من النوع المطلوب من MASTER.
• تشغيل التنمية.
• إجراء الاختبار على حامل فرع ميزة المطلوبة.
• إذا كانت أداة الأتمتة تعمل على الفرع بشكل مستقل وكان لها تاريخ خطي ، فيجب عليك إجراء "ضغط لسجل التعليقات الخطية" عبر rebase.
• انشر الالتزام النهائي بـ Gitlab وقم بإنشاء طلب دمج لقائد الفريق أو الشخص المسؤول. في طلب الدمج ، حدد:
• الاسم - رمز المهمة في نظام جيرا لتتبع الأخطاء ؛
• وصف - رابط لنتائج اختبار فرع في الخيزران.

حارس البوابة (يديره فريق الرصاص)

• Bamboo.
• .
• (merge) FEATURE DEVELOP, .
• .

---

kotalesssk .

1, , . 2.

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