الجزء الأول هنا .
تخيل الموقف. تواجه مهمة تطوير وظائف جديدة. لديك تطورات من أسلافك. على افتراض أنك لا تتحمل أي التزامات أخلاقية ، ماذا ستفعل؟
في معظم الأحيان ، يتم نسيان جميع الإنجازات القديمة ويبدأ كل شيء من جديد. لا أحد يحب الحفر في كود شخص آخر ، وإذا كان لديك الوقت فلماذا لا تبدأ في إنشاء نظامك الخاص؟ هذا هو النهج المعتاد ، وهذا صحيح إلى حد كبير. ولكن في مشروعنا فعلنا خطأ. لقد وضعنا الأساس لنظام الاختبار الآلي المستقبلي استنادًا إلى اختبارات الوحدة على utPLSQL من أسلافنا ، ثم انتقلنا إلى العمل في عدة اتجاهات متوازية.
- استعادة اختبارات الوحدة القديمة. يشير الاسترداد إلى تكييف الاختبارات مع الحالة الحالية لنظام الولاء وتكييف الاختبارات وفقًا لمعايير utPLSQL.
- الحل لمشكلة مع الفهم ، وما هي بالضبط ، ما هي الأساليب والعمليات ، ونحن مغطاة autotests. يجب عليك إما وضع هذه المعلومات في الاعتبار أو استخلاص النتائج بناءً على كود الاختبار التلقائي نفسه. لذلك ، قررنا إنشاء كتالوج. لقد خصصنا رمزًا تذكريًا فريدًا لكل اختبار تلقائي ، وشكلنا وصفًا وقمنا بإصلاح الإعدادات (على سبيل المثال ، في ظل أي ظروف يجب أن تبدأ ، أو ما يجب أن يحدث في حالة فشل الاختبار). في الأساس ، قمنا بملء البيانات الوصفية حول الاختبارات الذاتية ووضعها في جداول مخطط utPLSQL القياسية.
- تحديد استراتيجية التوسع ، أي اختيار وظيفة لفحصها من قبل autotests. قررنا الانتباه إلى ثلاثة أشياء: تحسينات النظام الجديدة وحوادث الإنتاج وعمليات النظام الرئيسية. وبالتالي ، نحن نعمل على تطوير بالتوازي مع الإصدار ، وتوفير جودة عالية ، في وقت واحد توسيع حجم الانحدار وضمان موثوقية النظام في الأماكن الحرجة. أول عنق الزجاجة كان عملية توزيع الخصومات والمكافآت على الشيكات.
- بطبيعة الحال ، بدأنا تطوير autotests جديدة. كانت إحدى مهام الإصدار الأول هي تقييم أداء العينات المحددة مسبقًا لنظام الولاء. في مشروعنا ، هناك مجموعة من استعلامات SQL الثابتة بشكل صارم التي تحدد العملاء وفقًا للشروط. على سبيل المثال ، احصل على قائمة بجميع العملاء الذين كانت آخر عملية شراء لهم في مدينة معينة ، أو قائمة بالعملاء الذين يزيد متوسط سعر الشراء عن قيمة معينة. بعد إجراء اختبارات تلقائية مكتوبة ، فحصنا العينات المحددة مسبقًا ، وحددنا معايير الأداء المرجعية ، بالإضافة إلى أننا أجرينا اختبارات الحمل.
- العمل مع autotests يجب أن تكون مريحة . في معظم الأحيان ، يتم تنفيذ إجراءين: تشغيل الاختبارات التلقائية وإنشاء بيانات الاختبار. إذن في نظامنا ، ظهرت وحدتان مساعدتان: وحدة الإطلاق ووحدة توليد البيانات.
يتم تقديم المشغل كإجراء عالمي واحد مع معلمة نص إدخال واحد. كمعلمة ، يمكنك اجتياز الكود الذري في autotest أو اسم الحزمة أو اسم الاختبار أو إعداد autotest أو كلمة رئيسية محجوزة. يحدد الإجراء ويدير جميع الاختبارات التلقائية التي تفي بالشروط.
يتم تقديم وحدة توليد البيانات في شكل حزمة يتم فيها إنشاء إجراء خاص يدرج البيانات هناك لكل كائن في النظام قيد الاختبار (جدول في قاعدة البيانات). في هذا الإجراء ، يتم ملء القيم الافتراضية بأكبر قدر ممكن ، مما يضمن إنشاء كائنات بنقرة إصبع. وللسهولة في الاستخدام ، تم إنشاء قوالب للبيانات التي تم إنشاؤها. على سبيل المثال ، قم بإنشاء عميل في سن معينة باستخدام هاتف اختبار وشراء مثالي. - يجب تشغيل Autotests وتشغيلها في وقت مقبول لنظامك. لذلك ، تم تنظيم إطلاق يومي ليلي ، تُنشئ نتائجه تقريرًا عن النتائج وإرساله إلى فريق التطوير بأكمله عن طريق البريد الإلكتروني للشركة. بعد استعادة الاختبارات الذاتية القديمة وإنشاء أخرى جديدة ، كان إجمالي وقت التشغيل 30 دقيقة. مثل هذا الأداء يناسب الجميع ، منذ إطلاق حدث بعد ساعات.
لكن كان علي العمل على تحسين سرعة العمل. يتم تحديث نظام الولاء على الإنتاج في الليل. كجزء من أحد الإصدارات ، اضطررت إلى إجراء تغييرات عاجلة في الليل. لم يجعل نصف ساعة انتظار نتائج الاختبارات الذاتية في الساعة الثالثة صباحًا الشخص المسؤول عن الإفراج سعيدًا (تحية نارية إلى Alexei Vasyukov!) ، وفي صباح اليوم التالي قيل الكثير من الكلمات الطيبة تجاه نظامنا. ولكن بناءً على النتائج ، تم وضع معيار عمل مدته 5 دقائق.
لتسريع الأداء ، استخدمنا طريقتين: بدأت الاختبارات التلقائية في العمل بثلاثة خيوط متوازية ، وهي مريحة للغاية بسبب بنية نظام الولاء لدينا. لقد تخلينا عن النهج عندما لا يقوم الاختبار التلقائي بإنشاء بيانات اختبار لنفسه ، ولكن يحاول إيجاد شيء مناسب في النظام. بعد إجراء التغييرات ، تم تخفيض إجمالي وقت التشغيل إلى 3-4 دقائق. - يجب أن يكون المشروع مع الاختبارات التلقائية قادراً على الانتشار في مختلف المواقف. في بداية الرحلة ، كانت هناك محاولات لكتابة ملفات الدُفعات الخاصة بك ، ولكن أصبح من الواضح أن التثبيت الآلي المكتوب ذاتيًا كان رعبًا كاملاً ، وانتقلنا إلى الحلول الصناعية. نظرًا لحقيقة أن المشروع يحتوي على الكثير من التعليمات البرمجية المباشرة (أولاً وقبل كل شيء ، نقوم بتخزين الكود للاختبارات التلقائية) والقليل جدًا من البيانات (البيانات الرئيسية هي البيانات الأولية حول الاختبارات الذاتية) ، فقد أصبح من السهل جدًا إدخال Liquibase في المشروع.
إنها مكتبة مفتوحة المصدر مستقلة عن قاعدة البيانات لتتبع وإدارة وتطبيق تغييرات قاعدة البيانات. تتم إدارتها عبر سطر الأوامر أو الأطر مثل Apache Maven. مبدأ تشغيل Liquibase بسيط للغاية. لدينا مشروع منظم بطريقة معينة ، والذي يتألف من تغييرات أو نصوص برمجية تحتاج إلى التراجع إلى الخادم الهدف ، والتحكم في الملفات التي تحدد التسلسل ومع أي معلمات يجب تثبيتها.
على مستوى نظم إدارة قواعد البيانات ، يتم إنشاء جدول خاص تخزن فيه Liquibase سجل التشغيل. يحتوي كل تغيير على تجزئة محسوبة ، تتم مقارنتها في كل مرة بين المشروع والحالة في قاعدة البيانات. بفضل Liquibase ، يمكننا بسهولة تغيير تغييرات نظامنا على أي دائرة. تعمل الاختبارات التلقائية الآن على حلقات اختبار وإصدار ، وكذلك على حاويات (حلقات شخصية للمطورين).
لذلك ، دعونا نتحدث عن نتائج تطبيق نظام اختبار الوحدة لدينا.
- بالطبع ، قبل كل شيء ، نحن مقتنعون بأننا بدأنا في تطوير برامج أفضل. تعمل الاختبارات التلقائية يوميًا وتجد العشرات من الأخطاء كل عام. علاوة على ذلك ، ترتبط بعض هذه الأخطاء بشكل غير مباشر بالوظيفة التي أردنا تغييرها حقًا. هناك شكوك كبيرة في العثور على هذه الأخطاء عن طريق الاختبار اليدوي.
- اكتسب الفريق الثقة في أن الوظيفة المحددة تعمل بشكل صحيح ... أولاً وقبل كل شيء ، يتعلق الأمر بعملياتنا الهامة. على سبيل المثال ، خلال الأشهر الستة الماضية ، لم نواجه أي مشكلة في توزيع الخصومات والمكافآت على الشيك ، على الرغم من التغييرات في الإصدارات ، على الرغم من حدوث أخطاء في الفترات السابقة في بعض الفواصل الزمنية
- تمكنا من تقليل عدد مرات اختبار التكرار. نظرًا لحقيقة أن الاختبارات الذاتية تتم كتابتها للحصول على وظائف جديدة ، فإن التحليلات واختبار الدوام الجزئي يحصلون على رمز عالي الجودة ، لأن لقد تم التحقق منه بالفعل.
- جزء من تطورات الاختبار الآلي يستخدم من قبل المطورين. على سبيل المثال ، يتم إنشاء بيانات الاختبار على الحاويات باستخدام وحدة إنشاء الكائن.
- من المهم أن قمنا بتطوير "اعتماد" نظام للاختبار الآلي من قبل المطورين. هناك فهم أن هذا مهم ومفيد. ومن تجربتي الخاصة أستطيع أن أقول إن هذا أبعد ما يكون عن القضية. يجب كتابة الاختبارات التلقائية ، ويجب الحفاظ عليها وتطويرها ، ويجب تحليل النتائج ، وغالبًا ما لا تكون هذه التكاليف الزمنية تستحق ذلك. من الأسهل بكثير الذهاب إلى الإنتاج والتعامل مع المشاكل هناك. في مكاننا ، يصطف المطورون ويطلبون تغطية وظائفهم باختبارات تلقائية.
ما التالي
دعونا نتحدث عن خطط التطوير لمشروع الاختبار الآلي.
بالطبع ، في حين أن نظام ولاء Sportmaster لا يزال حاضرًا ومستمرًا في التطور ، فمن الممكن أيضًا تطوير اختبارات ذاتية إلى ما لا نهاية تقريبًا. لذلك ، فإن الاتجاه الرئيسي للتنمية هو توسيع منطقة التغطية.
مع زيادة عدد الاختبارات التلقائية ، سينمو إجمالي الوقت في عملهم بشكل مطرد ، وسيتعين علينا مرة أخرى العودة إلى مسألة الإنتاجية. على الأرجح ، سيكون الحل هو زيادة عدد مؤشرات الترابط المتوازية.
ولكن هذه هي مسارات التنمية واضحة. إذا تحدثنا عن شيء أكثر تافهة ، فإننا نسلط الضوء على ما يلي:
- حاليًا ، تتم إدارة الاختبارات التلقائية على مستوى نظم إدارة قواعد البيانات ، أي تحتاج إلى معرفة PL / SQL للعمل بنجاح. إذا لزم الأمر ، يمكنك التحكم في النظام (على سبيل المثال ، تشغيل أو إنشاء بيانات التعريف) ، يمكنك إنشاء نوع من لوحة الإدارة باستخدام Jenkins أو شيء مشابه.
- الجميع يحب المؤشرات الكمية والنوعية. للاختبار الآلي ، مثل هذا المقياس العالمي هو مقاييس تغطية الكود أو تغطية الكود. باستخدام هذا المؤشر ، يمكننا تحديد النسبة المئوية لرمز نظام الاختبار الخاص بنا التي تغطيها الاختبارات التلقائية. بدءًا من الإصدار 12.2 ، توفر Oracle القدرة على حساب هذا المقياس وتقترح استخدام الحزمة القياسية DBMS_PLSQL_CODE_COVERAGE.
يبلغ عمر نظام الاختبار التلقائي لدينا أكثر من عام ، وربما حان الوقت لتقييم التغطية. في مشروعي السابق (مشروع ليس من Sportmaster) حدث ما حدث. بعد مرور عام على العمل في الاختبارات الذاتية ، حددت الإدارة هدفًا لتقييم النسبة المئوية للشفرة التي نغطيها. مع تغطية أكثر من 1 ٪ ، ستكون الإدارة سعيدة. نحن ، المطورين ، نتوقع نتيجة حوالي 10 ٪. تلقى تغطية رمز ثمل ، تقاس ، 20 ٪. للاحتفال ، ذهبنا للحصول على جائزة ، لكن كيف ذهبنا إليها وأين ذهبنا لاحقًا هي قصة مختلفة تمامًا. - يمكن للاختبارات التلقائية التحقق من خدمات الويب المكشوفة. يتيح لك Oracle القيام بذلك ، ولن نواجه عددًا من المشكلات بعد الآن.
- وبالطبع ، يمكن تطبيق نظام الاختبار الآلي الخاص بنا على مشروع آخر. حلنا عالمي ويتطلب فقط استخدام Oracle. سمعت أن هناك اهتمامًا بمشاريع Sportmaster الأخرى في الاختبار التلقائي ، وربما سنذهب إليها.
النتائج
لنلخص. في المشروع ، نظام الولاء في Sportmaster تمكنا من تنفيذ نظام الاختبار الآلي. أساسها هو الحل utPLSQL من ستيفن فيورستين. حول utPLSQL هو رمز autotest والوحدات الإضافية المكتوبة ذاتيا: وحدة الإطلاق ، وحدة توليد البيانات ، وغيرها. تعمل الاختبارات التلقائية يوميًا ، والأهم من ذلك أنها تعمل وتحقق فوائد. نحن مقتنعون بأننا بدأنا في إصدار برامج ذات جودة أعلى. في نفس الوقت ، فإن الحل الناتج عالمي ويمكن تطبيقه بحرية على أي مشروع حيث يكون من الضروري تنظيم الاختبارات الآلية على Oracle DBMS.
ملحوظة: هذه المقالة ليست محددة للغاية: هناك الكثير من النص وتقريبا لا توجد أمثلة تقنية. إذا كان الموضوع مثيرًا للاهتمام على مستوى العالم ، فنحن على استعداد لمواصلة ذلك والعودة باستمرار ، حيث سنخبرك بما حدث خلال الأشهر الستة الماضية ونقدم أمثلة على الكود.
اكتب تعليقات إذا كانت هناك نقاط تستحق التركيز عليها في المستقبل ، أو أسئلة تتطلب الكشف عنها.