اسمي Elena Rastorgueva ، أنا مسؤول عن منتج Factor في
HFLabs . The Factor عبارة عن مؤسسة خوارزمية معقدة للأتربة ؛ حيث تقوم بمعالجة البيانات على نطاق صناعي.
في المقال ، سوف أخبرك كيف بدأنا في اختبار "العامل" ، وكيف طورنا اختبارات تلقائية ولماذا توصلنا إلى أطر العمل المكتوبة ذاتيًا.
ما نوع المنتج هذا - "عامل"
"عامل" ينظف البيانات في قواعد البيانات مع ملايين العملاء: يزيل الأخطاء المطبعية في الاسم والهاتف والبريد الإلكتروني ، ويفحص جوازات السفر ، ويفعل الكثير. أصعب شيء هو تصحيح العناوين البريدية.
تتم كتابة العناوين بمئات الطرق ، لذلك يحتوي Factor على جهاز حسابي قوي أسفل الغطاء"العامل" يعمل كخدمة: إدخال البيانات - بيانات الإخراج.
هذا هو نظام عديمي الجنسية حيث كل مكالمة مستقلة عن سابقاتها. عديمي الجنسية يبسط إلى حد كبير حياة اختبار. من الأصعب بكثير اختبار نظام قائم على الحالة عندما يكون تسلسل الإجراءات مهمًا.
يجب أن يكون المنتج موثوقًا به باعتباره ISS ، لأنه يتم استخدامه من قبل البنوك ومشغلي الهواتف المحمولة والتأمين وتجار التجزئة على مستوى Lenta. نحن نجيب عن الأخطاء برؤوسنا إلى حد أن غياب الأخطاء هو جزء من اتفاقية مستوى الخدمة في العقد المبرم مع العميل.
نظرًا لمتطلبات الموثوقية من autotests ، فقد كتبنا منذ بداية التطوير. أحد معايير جاهزية المهمة هو "الاختبارات التلقائية المضافة".
بدأت مع الشيكات اليدوية و autotests
أطلقنا العامل في عام 2005 واختبرناه لأول مرة بأيدينا. في الصباح ، قام المختبر بإجراء اختبارات تلقائية على ملف به حالات ومقارنة نتيجة معالجة البيانات بنتيجة اليوم السابق: ما الذي تغير بعد التزام رمز الأمس.
قد تستغرق هذه العملية نصف يوم ، ولم تكن هذه المحاذاة جيدة. لذلك ، اتخذنا الحد الأدنى من مجموعة الاختبارات للوظيفة الرئيسية ولفنا في اختبارات الوحدة. هذه الاختبارات سريعة ، وقام المطور نفسه بإدارتها قبل الالتزام.
اختبارات الوحدة مريحة للغاية وسريعة لدرجة أننا أضفنا الآلاف منها. ثم واجهناها: عندما تبدو الاختبارات كصفقة من آلاف الكود ، فليس من السهل التمرير حتى إلى المكان الصحيح. ناهيك عن إضافة أو تحديث.
اختبار وحدة للتحقق من تنسيق SNILSبالإضافة إلى ذلك ، يظهر شيء غير متوقع فجأة في البيانات الصناعية التي لا تغطي اختبارات الوحدة. على سبيل المثال ، أتى عميل جديد بميزات جديدة في العناوين ، ولا تغطي اختبارات الوحدة هذه الميزات. تحتاج إلى الجلوس ومعرفة أي الاختبارات لإضافتها للحصول على بيانات جديدة. ما زلنا نفعل هذا يدويا.
إنشاء الإطار الخاص بك
في اختبارات الوحدة التقليدية ، يتم خلط البيانات والرمز ؛ من الصعب العثور على الأجزاء الصحيحة.
لذلك ، جربنا الاختبارات التلقائية في نموذج
اختبار البيانات (DDT) . DDT هو عندما يتم تخزين بيانات الاختبار بشكل منفصل عن رمز الاختبار.
تم تحميل الحالات من ملف excel ؛ فقد كانت في العمودين "البيانات الأولية" و "النتيجة المتوقعة". كان الـ دي. دي. تي إنجازًا كبيرًا: تحديث الحالات في "exelnik" أبسط بشكل لا يُعبَّر عنه.
شيئا فشيئا ، طورنا نهجا وطورنا إطار الاختبار الخاص بنا. يتلقى الملفات النصية كمدخلات ، داخلها هي البيانات المصدر والنتيجة المتوقعة.
لقد رفضنا من ملفات excel كمخزن: الملفات النصية تفتح بشكل أسرع ، لا تغير المحتويات ، فمن السهل جمع البيانات منهايتم مساعدة الإطار بواسطة أدوات قياسية:
- TeamCity يدير الاختبارات تلقائيا كل ليلة.
- testNG يقارن النتائج المتوقعة والفعلية.
إذا كانت النتيجة مختلفة عما كان متوقعًا ، فسيخفي الاختبار في TeamCity. إذا كان كل شيء كما يجب ، يكون الاختبار أخضرتعديل الإطار لنفسك
لقد مرت 12 سنة منذ ذلك الحين. خلال هذا الوقت ، تخطى الإطار مع إمكانيات غير موجودة في الحلول القياسية.
المحاسبة لحالة المهمة في جيرا. تلتزم HFLabs بالتطوير المبني على
الاختبارات : أولاً نكتب اختبارًا أو نضيف حالات اختبار للسلوك الجديد ، وعندها فقط نغير الوظيفة.
لقد أطفأنا حالات جديدة من خلال التعليق على الخط. خلاف ذلك ، وقعوا أولاً وتداخلوا ، لأن الحالات المضافة ميزات أو إصلاح الأخطاء من قبل.
لكن المهمة قد لا تكون قادرة على إكمال حالة الاختبار المقابلة: سيتحول الخطأ إلى أن يكون نادرًا للغاية أو أن العميل سوف يجلب شيئًا أكثر أهمية. بعض المهام معلقة لعدة أشهر مع أولوية منخفضة ، وتراكمت الحالات المنفصلة. في الوقت نفسه ، ليس من الواضح المهمة التي تنتمي إليها كل حالة ، وما إذا كان يمكن حذف هذه الحالة.
لذلك ، أضفنا رقم مهمة إلى الحالات المنفصلة وقللنا قليلاً من الأتمتة. الآن كل شيء يعمل مثل هذا:
- تم تعطيل حالة الاختبار عن طريق مطابقة مع مهمة مفتوحة في جيرا ؛
لإرفاق حالة بمهمة ، اكتب أمامها # ورقم المهمة
- يعمل إطار الاختبارات حتى في الحالات المعطلة. لكن يتجاهل الأعطال بينما تكون المهمة مفتوحة في جيرا ؛
- بمجرد إغلاق المهمة ، يبدأ الاختبار في الوقوع في الحالات المرتبطة به. هذه إشارة: لقد تجاوزوا المهمة ، لكنهم نسوا تشغيل الحالات ؛
- إذا بدأ اختبار الحالة المنفصلة فجأة بمهمة مفتوحة ، فسيبلغ إطار العمل أيضًا بهذا. ربما حان الوقت لتشغيل القضية أو إغلاق المهمة المرتبطة بها (بالإضافة إلى ملاحظات إصدار التحديث وإبلاغ العملاء).
يقول الإطار إن الحالة المنفصلة تمر. ربما قام شخص ما بتصحيح الكود كجزء من مهمة أخرى ، والآن يعمل كل شيء
لذلك قمنا بحفظ TDD وهزمنا النسيان عند إدارة حالات الاختبار.
لقد وثقنا جميع الخيارات بحالة حالات الاختبار والمهام ذات الصلة ، حتى لا ننسىتحديث حالات الاختبار في الوضع شبه التلقائي. يبدو أنه في حالة تعطل الاختبار ، ابحث عن خطأ في التعليمات البرمجية. ولكن بالنسبة لنا هذا ليس هو الحال دائما. يحدث في بعض الأحيان أن حالات الاختبار تحتاج إلى تحديث ، لأن متطلبات النتيجة قد تغيرت.
على سبيل المثال ، قبل العميل في العنوان الذي تم مسحه أراد "ز. موسكو "في حقل واحد. الآن قام بتغيير بنية قاعدة البيانات ، فهو يريد "المدينة" في حقل واحد ، "موسكو" في حقل آخر. حان الوقت لتغيير حالات الاختبار.
بالنسبة للاختبار الساقط ، يُظهر TeamCity الفرق بين النتائج المتوقعة والنتائج الفعلية. في السابق ، قمنا بنسخ هذا الاختلاف وتحديث حالات الاختبار بأيدينا. لإجراء تغييرات هائلة - حدث مكلف للغاية.
مثال حي: لقد قمنا بتدريس "Factor" لتحديد البلد حسب رقم الهاتف ، سقطت الاختبارات في TeamCity. يمكن أخذ معيار جديد من النتيجة الفعلية ، لكنه يستغرق وقتًا طويلاًلقد جعلنا تحديث الإطار القياسي نفسه. للقيام بذلك ، بعد إجراء الاختبارات ، فإنه يحل محل نتائج التنظيف المتوقعة في المعيار مع النتائج الفعلية التي لا تتطابق معها. يتم حفظ النتيجة في الأعمال الفنية كملف تحديث الحالة.
الملف الأول هو معيار جديد قام فيه الإطار بتحديث النتائج المتوقعة. الملفات المتبقية هي بيانات الإدخال ، المعيار القديم والبيانات الفعلية للحالات التي تم إسقاطها.باستخدام المعيار الجديد ، يقوم المختبر بتحديث الحالات في ثلاث خطوات.
- قم بتنزيل الملف الذي تم إنشاؤه
- يتحقق من خلال أي أداة دمج ما هي التغييرات في المؤشر الجديد. يترك فقط ما هو ضروري.
- ارتكب
يتحقق المختبر مما إذا كانت التحديثات في المعيار الجديد صحيحة وتلتزم بهانعم ، إذا تم تحديثها دون تفكير ، فلن يأتي شيء جيد منها. ولكن هناك خطر التحديث بدون تفكير عند العمل يدويًا.
استقرار بيانات الاختبار مع بذرة. إرجاع "عامل" البيانات التي تمت معالجتها في عشرات الحقول. هناك مجموعة من المكونات في عنوان واحد فقط: الفهرس ، والمنطقة ، ونوع المنطقة ، ونوع المدينة ، والمدينة ، ونوع الشارع ، والمنزل ، والمبنى ، والمبنى ، والشقة. بالنسبة لهم ، "عامل" يمسك IFTS ، OKATO ، OKTMO وحتى الأشياء الصغيرة. لذلك من سطر واحد في المدخلات يتم الحصول على العشرات من القيم.
ليس كل الحقول من النتيجة تحتاج إلى التحقق من حالات الاختبار. على سبيل المثال ، يعتمد التعرف على نفس العنوان مباشرةً على دليل الحالة - FIAS. وفيه تتغير الحقول بانتظام ، لأن مهامنا غريبة تمامًا. تحديث بعض رموز CLADR للمنازل انخفض مئات من حالات الاختبار.
أضفنا بذرة إلى النتيجة المتوقعة عندما أدركنا أننا نضيع وقتنا في تحليل السقوط غير المهم.
عندما لا يحتاج الحقل إلى التحقق على الإطلاق ، يكتب المختبر رمزًا في النتيجة المتوقعة:
$$ DNV $$ . متى يجب ملء الحقل ، لكن القيمة نفسها ليست مهمة:
$$ NE $$ .
معرف FIAS موجود دائمًا في العنوان ، لذلك نتحقق منه في جميع الاختبارات. إذا كان الحقل فارغًا ، فهناك خطأ ما. لكن قد لا يكون الفهرس ، لذلك ، عند التحقق من معرّف FIAS ، فإننا نتجاهل الفهرسيمكنك الذهاب في الاتجاه الآخر وفصل الاختبارات: كل حقل له خاص به. لكنه صعب ، لأنه لا يمكن عزل كل شيء. على سبيل المثال ، "المدينة" و "الشارع" جزءان من عنوان ودون بعضهما البعض لا معنى له.
إطار مكتوب ذاتيا هو أكثر ملاءمة
لذلك ، أنا لا أعتبر إطلاقًا إنشاء إطار عمل خاص بي بمثابة مهمة غبية. إذا لم نقم بإنشاء أداة خاصة بنا ، لما تلقينا الكثير من الفرص الجديدة وهذه المرونة.
إن إيقاف تشغيل حالة النص حسب حالة المهمة ، وإنشاء معيار جديد ، وعبارات تحقيق النتيجة هي الأشياء التي يسألها اختبارنا الآن في أطر عمل أخرى. إذا اتخذنا الحلول القياسية ، فلن نكون قادرين على القيام بذلك.
إذا كنت ترغب في القيام بأشياء معقدة في المؤسسة ، تعال إلينا. الآن نحن نبحث عن مطور جافا ، راتب من 135 000 ₽ دون ضريبة الدخل الشخصي.