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

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

اختبار الولاء
أولاً ، دعنا نتحدث عن مشروع قمنا بنشر نظام اختبار تلقائي فيه. مشروعنا هو نظام ولاء Sportmaster (بالمناسبة ، لقد كتبنا عنه بالفعل في
هذا المنشور ).
إذا كانت شركتك كبيرة بدرجة كافية ، فسيحتوي نظام الولاء على ثلاث خصائص قياسية:
- سيتم تحميل النظام الخاص بك بشكل كبير.
- سيحتوي نظامك على عمليات حسابية معقدة.
- سيتم تطوير نظامك بنشاط.
دعنا نذهب في النظام. Sportmaster لديها عدد كبير من المتاجر التي تبيع بنشاط. بطبيعة الحال ، فإن نظام الولاء هو نظام محمّل للغاية. ونظرًا لاستخدام المشروع بنشاط ، يجب علينا توفير أعلى معايير الجودة ، لأن أي خطأ في البرنامج هو الكثير من المال والسمعة والخسائر الأخرى.
في الوقت نفسه ، تعمل أكثر من مائة حملة ترويجية مختلفة في Sportmaster. الأسهم مختلفة تمامًا: هناك سلعة ، يوجد توقيتها إلى يوم من أيام الأسبوع ، وهناك مرتبطة بمحل معين ، وهناك أسهم بمبلغ الشيك ، وهناك عدد البضائع. بشكل عام ، ليست ضعيفة. يحصل العملاء على مكافآت ، وهناك رموز ترويجية تُستخدم عند التسوق. كل هذا يؤدي إلى حقيقة أن حساب أي أمر هو مهمة تافهة للغاية.
إن الخوارزمية التي تنفذ معالجة الطلبات أمر فظيع ومعقد حقًا. وأي تغييرات على هذه الخوارزمية هي شيء محفوف بالمخاطر للغاية. يبدو أنه كانت هناك أكثر التغييرات الطفيفة ظاهريًا والتي يمكن أن تؤدي إلى تأثيرات غير متوقعة إلى حد ما. ولكن هذه العمليات الحسابية المعقدة هي بالتحديد ، والأهم من ذلك أن تنفيذ الوظائف الحيوية هو أفضل مرشح للأتمتة. إن التحقق من عشرات الحالات من نفس النوع بأيديكم يستهلك الكثير من الوقت. ونظرًا لأن نقطة الدخول إلى العملية لم تتغير ، بمجرد وصفها ، يمكنك ختم الاختبارات التلقائية بسرعة والتأكد من الوظيفة.
نظرًا لأن نظامنا يستخدم بشكل نشط ، فإن الأعمال التجارية تريد شيئًا جديدًا منك ، وتحديثه ، ويكون موجهًا نحو العملاء. في نظام الولاء لدينا ، يتم إصدار الإصدارات كل شهرين. لذلك ، كل شهرين نحتاج إلى إجراء تراجع كامل للنظام بأكمله. في الوقت نفسه ، بالطبع ، كما هو الحال في أي تكنولوجيا معلومات حديثة ، لا يأتي التطوير فورًا من المطور إلى الإنتاج. ينشأ على دارة المطور ، ثم يجتاز حامل الاختبار ، والإفراج ، والقبول ، وعندئذٍ يتم إنتاجه. على الأقل في دوائر الاختبار والإفراج ، نحتاج إلى إجراء انحدار كامل للنظام بأكمله.
الخصائص الموصوفة هي قياسية لأي نظام ولاء تقريبا. دعونا نتحدث عن ميزات مشروعنا.
من الناحية التكنولوجية ، يعتمد 90٪ من منطق نظام الولاء لدينا على الخادم ويتم تنفيذه على Oracle. هناك عميل مكشوف على دلفي ، والذي يؤدي وظيفة مسؤول AWP. هناك خدمات ويب مكشوفة للتطبيقات الخارجية (مثل موقع الويب). لذلك ، من المنطقي جدًا أننا إذا قمنا بنشر نظام اختبار تلقائي ، فسنفعل ذلك على Oracle.
يوجد نظام الولاء في Sportmaster منذ أكثر من 7 سنوات وتم إنشاؤه بواسطة مطورين فرديين ... كان متوسط عدد المطورين في مشروعنا خلال هذه السنوات السبع هو 3-4 أشخاص. لكن على مدار العام الماضي ، نما فريقنا بشكل ملحوظ ، ويعمل الآن 10 أشخاص في المشروع. أي أن الأشخاص الذين ليسوا على دراية بالمهام والعمليات والهندسة المعمارية النموذجية يأتون إلى المشروع. وهناك خطر متزايد بأن نتخطى الأخطاء.
يتميز المشروع بعدم وجود اختبار مخصص كوحدات للموظفين. الاختبار ، بالطبع ، هو أن المحللين يشاركون في الاختبار ، بالإضافة إلى مسؤولياتهم الرئيسية الأخرى: التواصل مع العملاء من رجال الأعمال والمستخدمين ومتطلبات نظام العمل ، إلخ. الخ ... على الرغم من حقيقة أن الاختبار يتم بكفاءة عالية (هذا مناسب بشكل خاص أن نذكر ، نظرًا لأن أحد المحللين قد يلفت انتباه هذا التقرير) ، لم يلغ أحد فعالية التخصص والتركيز على شيء واحد.
بالنظر إلى كل ما سبق ، لتحسين جودة المنتج المُصدر وتقليل وقت التطوير ، تبدو فكرة أتمتة الاختبار على المشروع منطقية للغاية. وفي المراحل المختلفة من وجود نظام الولاء ، بذل المطورين الأفراد جهودًا لتغطية الشفرة الخاصة بهم من خلال اختبارات الوحدة. كانت بشكل عام عملية متباينة إلى حد ما حيث استخدم الجميع الهندسة المعمارية والأساليب. كانت اختبارات الوحدة شائعة بالنسبة للنتائج النهائية: تم تطوير الاختبارات ، وتستخدم لبعض الوقت ، وهي مكدسة في تخزين ملفات مُصدّر ، لكن في مرحلة ما توقفت عن البدء والنسيان. كان هذا في المقام الأول بسبب حقيقة أن الاختبارات تم ربطها بأداء معين أكثر من ارتباطها بمشروع ما.
UtPLSQL يأتي لانقاذ

هل تعرف أي شيء عن ستيفن فورشتاين؟
هذا رجل ذكي كرس جزءًا كبيرًا من حياته المهنية للعمل مع Oracle ومع PL / SQL ، وكتب عددًا كبيرًا من الأعمال حول هذا الموضوع. يسمى كتاب واحد معروف له: "Oracle PL / SQL. للمحترفين. " ستيفن هو الذي يمتلك تطوير حل utPLSQL ، أو كما هو الحال بالنسبة لإطار اختبار الوحدة لـ Oracle PL / SQL. تم إنشاء حل utPLSQL في عام 2016 ، لكنهم يواصلون العمل بنشاط عليه وإصدار إصدارات جديدة. في وقت التقرير ، أحدث إصدار بتاريخ 24 مارس 2019.
ما هذا. هذا هو مشروع مفتوح المصدر منفصل. يزن بضع ميغابايت ، مع الأخذ بعين الاعتبار الأمثلة والوثائق. ماديًا ، إنه مخطط منفصل في قاعدة بيانات ORACLE مع مجموعة من الحزم والجداول لتنظيم اختبار الوحدة. التثبيت يستغرق بضع ثوان. ميزة مميزة من utPLSQL هي سهولة الاستخدام.
على المستوى العالمي ، utPLSQL هي آلية لتشغيل اختبارات الوحدات ، حيث يشير اختبار الوحدة إلى إجراءات دفعة أوراكل المعتادة ، التي يتبع تنظيمها قواعد معينة. بالإضافة إلى الإطلاق ، تخزن utPLSQL سجلًا لجميع عمليات الاختبار ، وهناك أيضًا نظام إعداد تقارير داخلي.
دعونا نلقي نظرة على مثال لكيفية ظهور رمز اختبار الوحدة المطبق بواسطة هذه التقنية.

لذلك ، تعرض الشاشة رمز المواصفات القياسية لحزمة مع اختبارات وحدة. ما هي المتطلبات المطلوبة؟ يجب أن تحتوي الحزمة على البادئة utp_. جميع الإجراءات مع الاختبارات يجب أن يكون لها نفس البادئة. يجب أن تحتوي الحزمة على إجراءين قياسيين: "utp_setup" و "utp_teardown". يسمى الإجراء الأول بإعادة تشغيل كل اختبار وحدة ، والثاني - بعد البدء.
"Utp_setup" ، كقاعدة عامة ، يعد نظامنا لتشغيل اختبار وحدة ، على سبيل المثال ، يخلق بيانات اختبار. "Utp_teardown" - على العكس من ذلك ، يعود كل شيء إلى إعداداته الأصلية ويعيد تعيين نتائج الإطلاق.
فيما يلي مثال على أبسط اختبار للوحدة ، والذي يتحقق من تطبيع رقم هاتف العميل الذي تم إدخاله إلى الشكل القياسي لنظام الولاء لدينا. لا توجد معايير إلزامية لإجراءات الكتابة مع اختبارات الوحدة. وكقاعدة عامة ، يتم استدعاء طريقة للنظام قيد الاختبار ، وتتم مقارنة النتيجة التي يتم إرجاعها بهذه الطريقة مع الإشارة. من المهم أن تتم مقارنة النتيجة المرجعية والنتيجة من خلال أساليب utPLSQL القياسية.
يمكن أن يحتوي اختبار الوحدة على أي عدد من الفحوصات. كما ترون من المثال ، نقوم بإجراء أربع مكالمات متتالية من الطريقة المختبرة لتطبيع رقم الهاتف وبعد كل مكالمة نقوم بتقييم النتيجة. عند تطوير اختبار وحدة ، يجب على المرء أن يأخذ في الاعتبار أن هناك فحوصات لا تؤثر على النظام بأي شكل من الأشكال ، وبعد البعض ، من الضروري العودة إلى الحالة الأولية للنظام.
على سبيل المثال ، في اختبار الوحدة المقدم ، نقوم ببساطة بتنسيق رقم هاتف الإدخال ، والذي لا يؤثر على نظام الولاء.
وإذا كتبنا اختبارات الوحدة باستخدام طريقة إنشاء عميل جديد ، فبعد كل فحص ، سيتم إنشاء عميل جديد في النظام ، مما قد يؤثر على الإطلاق اللاحق للاختبار.

هذه هي الطريقة التي تعمل بها اختبارات الوحدة. هناك خياران محتملان للتشغيل: بدء جميع اختبارات الوحدة من حزمة معينة أو بدء اختبار وحدة محددة في حزمة محددة.

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

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