اختبارات الوحدة في DBMS - كيف نقوم بذلك في Sportmaster ، الجزء الثاني

الجزء الاول - هنا.

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

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

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

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

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

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

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

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

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

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

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

لذا ، لنتحدث عن نتائج تطبيق نظام اختبار الوحدة الخاص بنا.

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

ما هي الخطوة التالية

لنتحدث عن خطط تطوير مشروع الاختبار الآلي.

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

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

لكن هذه طرق واضحة للتنمية. إذا تحدثنا عن شيء غير تافه ، فإننا نسلط الضوء على ما يلي:

1. تتم الآن إدارة الاختبارات التلقائية على مستوى DBMS ، أي مطلوب معرفة PL / SQL للعمل الناجح. إذا لزم الأمر ، يمكن إزالة إدارة النظام (على سبيل المثال ، بدء تشغيل أو إنشاء بيانات وصفية) بواسطة نوع من لوحة الإدارة باستخدام Jenkins أو شيء مشابه.
2. الجميع يحب المؤشرات الكمية والنوعية. للاختبار التلقائي ، مثل هذا المؤشر العالمي هو تغطية الكود أو مقياس تغطية الكود. باستخدام هذا المؤشر ، يمكننا تحديد النسبة المئوية لرمز نظامنا قيد الاختبار الذي يتم تغطيته بواسطة الاختبارات التلقائية. بدءًا من الإصدار 12.2 ، توفر Oracle القدرة على حساب هذا المقياس وتقترح استخدام حزمة DBMS_PLSQL_CODE_COVERAGE القياسية.

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

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

النتائج

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

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

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

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

هل نكتب المزيد عن هذا؟

• نعم بالطبع

• لا شكرا

صوت 12 مستخدمًا. امتنع 4 مستخدما عن التصويت.

المصدر: www.habr.com