يا هبر!
اسمي مكسيم بونومارينكو وأنا مطور في Sportmaster. لدي 10 سنوات من الخبرة في مجال تكنولوجيا المعلومات. بدأ حياته المهنية في الاختبار اليدوي، ثم تحول إلى تطوير قواعد البيانات. على مدار السنوات الأربع الماضية، ومن خلال تجميع المعرفة المكتسبة في الاختبار والتطوير، قمت بأتمتة الاختبار على مستوى نظام إدارة قواعد البيانات (DBMS).
لقد كنت عضوًا في فريق Sportmaster منذ ما يزيد قليلاً عن عام وأعمل على تطوير اختبار آلي في أحد المشاريع الكبرى. في أبريل، تحدثت أنا ورفاق Sportmaster Lab في مؤتمر في كراسنودار، وكان تقريري يسمى "اختبارات الوحدة في نظام إدارة قواعد البيانات"، والآن أريد مشاركته معك. سيكون هناك الكثير من النص، لذلك قررت تقسيم التقرير إلى منشورين. في الأول، سنتحدث عن الاختبارات التلقائية والاختبار بشكل عام، وفي الثانية، سأتناول المزيد من التفاصيل حول نظام اختبار الوحدة لدينا ونتائج تطبيقه.
أولا، نظرية مملة قليلا. ما هو الاختبار الآلي؟ يتم إجراء هذا الاختبار باستخدام البرامج، وفي تكنولوجيا المعلومات الحديثة يتم استخدامه بشكل متزايد في تطوير البرمجيات. ويرجع ذلك إلى حقيقة أن الشركات تنمو، وأنظمة المعلومات الخاصة بها تنمو، وبالتالي فإن حجم الوظائف التي تحتاج إلى اختبارها آخذ في الازدياد. أصبح إجراء الاختبار اليدوي أكثر تكلفة.
عملت في شركة كبيرة تصدر إصداراتها كل شهرين. وفي الوقت نفسه، تم قضاء شهر كامل في إجراء عشرات الاختبارات يدويًا للتحقق من الوظيفة. بفضل تنفيذ الأتمتة بواسطة فريق صغير من المطورين، تمكنا من تقليل وقت الاختبار إلى أسبوعين خلال عام ونصف. لم نقم بزيادة سرعة الاختبار فحسب، بل قمنا أيضًا بتحسين جودته. يتم إطلاق الاختبارات الآلية بانتظام وتقوم دائمًا بإجراء كامل عمليات الفحص المضمنة فيها، أي أننا نستبعد العامل البشري.
تتميز تكنولوجيا المعلومات الحديثة بحقيقة أنه قد يُطلب من المطور ليس فقط كتابة رمز المنتج، ولكن أيضًا كتابة اختبارات الوحدة التي تتحقق من هذا الرمز.
ولكن ماذا لو كان نظامك يعتمد بشكل أساسي على منطق الخادم؟ لا يوجد حل عالمي أو أفضل الممارسات في السوق. كقاعدة عامة، تحل الشركات هذه المشكلة عن طريق إنشاء نظام اختبار مكتوب ذاتيًا. هذا هو نظام الاختبار الآلي الذي كتبناه ذاتيًا والذي تم إنشاؤه في مشروعنا وسوف أتحدث عنه في تقريري.
اختبار الولاء
أولاً، دعونا نتحدث عن المشروع الذي قمنا فيه بنشر نظام اختبار آلي. مشروعنا هو نظام الولاء Sportmaster (بالمناسبة، لقد كتبنا عنه بالفعل في ).
إذا كانت شركتك كبيرة بما يكفي، فسيكون لنظام الولاء الخاص بك ثلاث خصائص قياسية:
- سيتم تحميل النظام الخاص بك بشكل كبير
- سيحتوي نظامك على عمليات حوسبة معقدة
- سيتم تحسين النظام الخاص بك بنشاط.
هيا بنا بالترتيب... في المجمل، إذا نظرنا إلى جميع العلامات التجارية لـ Sportmaster، فلدينا أكثر من 1000 متجر في روسيا وأوكرانيا والصين وكازاخستان وبيلاروسيا. يتم إجراء حوالي 300 عملية شراء في هذه المتاجر يوميًا. أي أن 000-3 عمليات فحص تدخل إلى نظامنا كل ثانية. وبطبيعة الحال، نظام الولاء لدينا محمل للغاية. وبما أنه يتم استخدامه بشكل نشط، فيجب علينا توفير أعلى معايير الجودة، لأن أي خطأ في البرنامج يعني خسائر مالية كبيرة وخسارة في السمعة وغيرها.
وفي الوقت نفسه، يدير Sportmaster أكثر من مائة عرض ترويجي مختلف. هناك مجموعة متنوعة من العروض الترويجية: هناك عروض ترويجية للمنتجات، وهناك عروض ترويجية مخصصة ليوم الأسبوع، وهناك عروض ترويجية مرتبطة بمتجر معين، وهناك عروض ترويجية لمبلغ الإيصال، وهناك عروض ترويجية لعدد البضائع. بشكل عام، ليس سيئا. يحصل العملاء على مكافآت ورموز ترويجية يتم استخدامها عند إجراء عمليات الشراء. كل هذا يؤدي إلى حقيقة أن حساب أي أمر هو مهمة غير تافهة للغاية.
الخوارزمية التي تنفذ معالجة الطلبات فظيعة ومعقدة حقًا. وأي تغييرات في هذه الخوارزمية تعتبر محفوفة بالمخاطر. يبدو أن التغييرات التي تبدو غير مهمة يمكن أن تؤدي إلى تأثيرات غير متوقعة تمامًا. ولكن عمليات الحوسبة المعقدة هذه على وجه التحديد، وخاصة تلك التي تنفذ الوظائف الحيوية، هي أفضل المرشحين للأتمتة. يستغرق فحص العشرات من الحالات المماثلة يدويًا وقتًا طويلاً. وبما أن نقطة الدخول إلى العملية لم تتغير، بعد وصفها مرة واحدة، يمكنك إنشاء اختبارات تلقائية بسرعة وتكون واثقًا من أن الوظيفة ستعمل.
نظرًا لاستخدام نظامنا بشكل نشط، فإن الشركة سترغب في الحصول على شيء جديد منك، وأن تتعايش مع العصر وتكون موجهة نحو العملاء. في نظام الولاء لدينا، تصدر الإصدارات كل شهرين. هذا يعني أننا نحتاج كل شهرين إلى إجراء انحدار كامل للنظام بأكمله. في الوقت نفسه، بطبيعة الحال، كما هو الحال في أي تكنولوجيا معلومات حديثة، لا ينتقل التطوير على الفور من المطور إلى الإنتاج. ينشأ في دائرة المطور، ثم يمر عبر منصة الاختبار على التوالي، ثم يتم إطلاقه، ثم قبوله، وعندها فقط ينتهي في الإنتاج. على الأقل، في دوائر الاختبار والإصدار، نحتاج إلى إجراء تراجع كامل للنظام بأكمله.
تعد الخصائص الموصوفة قياسية لأي نظام ولاء تقريبًا. دعونا نتحدث عن ميزات مشروعنا.
من الناحية التكنولوجية، يعتمد 90% من منطق نظام الولاء لدينا على الخادم ويتم تنفيذه على Oracle. يوجد عميل مكشوف في دلفي، والذي يؤدي وظيفة مسؤول آلي لمكان العمل. هناك خدمات ويب مكشوفة للتطبيقات الخارجية (على سبيل المثال موقع ويب). لذلك، فمن المنطقي جدًا أنه إذا قمنا بنشر نظام اختبار آلي، فسوف نقوم بذلك على Oracle.
نظام الولاء في Sportmaster موجود منذ أكثر من 7 سنوات وتم إنشاؤه بواسطة مطورين فرديين. كان متوسط عدد المطورين في مشروعنا خلال هذه السنوات السبع 7-3 أشخاص. ولكن خلال العام الماضي، نما فريقنا بشكل ملحوظ، والآن هناك 4 أشخاص يعملون في المشروع. أي أن الأشخاص الذين يأتون إلى المشروع ليسوا على دراية بالمهام والعمليات والهندسة المعمارية النموذجية. وهناك خطر متزايد من أن نفوت الأخطاء.
يتميز المشروع بعدم وجود مختبرين متخصصين كوحدات موظفين. هناك بالطبع اختبار، ولكن يتم إجراء الاختبار من قبل المحللين، بالإضافة إلى مسؤولياتهم الرئيسية الأخرى: التواصل مع العملاء التجاريين والمستخدمين وتطوير متطلبات النظام وما إلى ذلك. الخ... على الرغم من أن الاختبار يتم بجودة عالية جدًا (وهذا أمر مناسب بشكل خاص لذكره، حيث قد يلفت هذا التقرير انتباه بعض المحللين)، إلا أنه لم يتم إلغاء فعالية التخصص والتركيز على شيء واحد .
بالنظر إلى كل ما سبق، لتحسين جودة المنتج المقدم وتقليل وقت التطوير، تبدو فكرة أتمتة الاختبار في المشروع منطقية للغاية. وفي مراحل مختلفة من وجود نظام الولاء، بذل المطورون الأفراد جهودًا لتغطية التعليمات البرمجية الخاصة بهم باختبارات الوحدة. بشكل عام، كانت العملية مفككة إلى حد ما، حيث استخدم الجميع هندستهم وأساليبهم الخاصة. كانت النتائج النهائية شائعة في اختبارات الوحدة: تم تطوير الاختبارات، واستخدامها لبعض الوقت، وتخزينها في مخزن ملفات ذي إصدار، ولكن في مرحلة ما توقفت عن العمل وتم نسيانها. بادئ ذي بدء، كان هذا يرجع إلى حقيقة أن الاختبارات كانت مرتبطة أكثر بأداء معين، وليس بالمشروع.
يأتي utPLSQL للإنقاذ
هل تعرف شيئا عن ستيفن فويرستين؟
هذا رجل ذكي كرّس جزءًا كبيرًا من حياته المهنية للعمل مع Oracle وPL/SQL، وقد كتب عددًا كبيرًا من الأعمال حول هذا الموضوع. أحد كتبه الشهيرة يسمى: “Oracle PL/SQL. للمحترفين." لقد كان ستيفن هو من قام بتطوير حل utPLSQL، أو، كما هو الحال بالنسبة لإطار عمل اختبار الوحدة لـ Oracle PL/SQL. تم إنشاء حل utPLSQL في عام 2016، ولكن لا يزال العمل عليه نشطًا ويتم إصدار إصدارات جديدة. في وقت إعداد هذا التقرير، يعود تاريخ الإصدار الأخير إلى 24 مارس 2019.
ما هذا. هذا مشروع منفصل مفتوح المصدر. يزن بضع ميغابايت، بما في ذلك الأمثلة والوثائق. من الناحية المادية، فهو عبارة عن مخطط منفصل في قاعدة بيانات ORACLE مع مجموعة من الحزم والجداول لتنظيم اختبار الوحدة. التثبيت يستغرق بضع ثوان. السمة المميزة لـ utPLSQL هي سهولة الاستخدام.
على المستوى العالمي، utPLSQL عبارة عن آلية لتشغيل اختبارات الوحدة، حيث يُفهم اختبار الوحدة على أنه إجراءات مجمعة عادية من Oracle، يتبع تنظيمها قواعد معينة. بالإضافة إلى التشغيل، يقوم utPLSQL بتخزين سجل بجميع عمليات التشغيل الاختبارية، كما أنه يحتوي على نظام تقارير داخلي.
دعونا نلقي نظرة على مثال لما يبدو عليه رمز اختبار الوحدة، والذي تم تنفيذه باستخدام هذه التقنية.
لذلك، تعرض الشاشة رمزًا لمواصفات الحزمة النموذجية مع اختبارات الوحدة. ما هي المتطلبات الإلزامية؟ يجب أن تكون الحزمة مسبوقة بـ "utp_". يجب أن تحتوي جميع الإجراءات المتعلقة بالاختبارات على نفس البادئة تمامًا. يجب أن تحتوي الحزمة على إجراءين قياسيين: "utp_setup" و"utp_teardown". يتم استدعاء الإجراء الأول عن طريق إعادة تشغيل كل اختبار للوحدة، والثاني - بعد الإطلاق.
"utp_setup"، كقاعدة عامة، يقوم بإعداد نظامنا لإجراء اختبار الوحدة، على سبيل المثال، إنشاء بيانات الاختبار. "utp_teardown" - على العكس من ذلك، يعود كل شيء إلى الإعدادات الأصلية ويعيد تعيين نتائج الإطلاق.
فيما يلي مثال على أبسط اختبار للوحدة يتحقق من تسوية رقم هاتف العميل الذي تم إدخاله مع النموذج القياسي لنظام الولاء الخاص بنا. لا توجد معايير إلزامية حول كيفية كتابة الإجراءات مع اختبارات الوحدة. كقاعدة عامة، يتم استدعاء طريقة النظام قيد الاختبار، وتتم مقارنة النتيجة التي يتم إرجاعها بواسطة هذه الطريقة مع النتيجة المرجعية. من المهم أن تتم المقارنة بين النتيجة المرجعية والنتيجة التي تم الحصول عليها من خلال أساليب utPLSQL القياسية.
يمكن أن يحتوي اختبار الوحدة على أي عدد من الاختبارات. وكما يتبين من المثال، نقوم بإجراء أربع مكالمات متتالية للطريقة المختبرة لتطبيع رقم الهاتف وتقييم النتيجة بعد كل مكالمة. عند تطوير اختبار الوحدة، يجب أن تأخذ في الاعتبار أن هناك فحوصات لا تؤثر على النظام بأي شكل من الأشكال، وبعد بعضها تحتاج إلى العودة إلى الحالة الأصلية للنظام.
على سبيل المثال، في اختبار الوحدة المقدم، نقوم ببساطة بتنسيق رقم الهاتف المُدخل، والذي لا يؤثر على نظام الولاء بأي شكل من الأشكال.
وإذا كتبنا اختبارات الوحدة باستخدام طريقة إنشاء عميل جديد، فبعد كل اختبار، سيتم إنشاء عميل جديد في النظام، مما قد يؤثر على الإطلاق اللاحق للاختبار.
هذه هي الطريقة التي يتم بها تشغيل اختبارات الوحدة. هناك خياران محتملان للإطلاق: تشغيل كافة اختبارات الوحدات من حزمة معينة أو تشغيل اختبار وحدة معينة في حزمة معينة.
هذا ما يبدو عليه مثال نظام إعداد التقارير الداخلي. بناءً على نتائج اختبار الوحدة، يقوم utPLSQL بإنشاء تقرير صغير. نرى فيه النتيجة لكل فحص محدد والنتيجة الإجمالية لاختبار الوحدة.
6 قواعد للاختبارات التلقائية
قبل البدء في إنشاء نظام جديد للاختبار الآلي لنظام الولاء، قمنا، بالتعاون مع الإدارة، بتحديد المبادئ التي يجب أن تمتثل لها اختباراتنا الآلية المستقبلية.
- يجب أن تكون الاختبارات التلقائية فعالة ويجب أن تكون مفيدة. لدينا مطورون رائعون، ومن المؤكد أنهم بحاجة إلى ذكرهم، لأن بعضهم ربما يرى هذا التقرير، ويكتبون تعليمات برمجية رائعة. ولكن حتى كودهم الرائع ليس مثاليًا ويحتوي على أخطاء وسيظل يحتوي على أخطاء. الاختبارات التلقائية مطلوبة للعثور على هذه الأخطاء. إذا لم يكن الأمر كذلك، فإما أننا نكتب اختبارات تلقائية سيئة، أو وصلنا إلى منطقة ميتة، من حيث المبدأ، لا يتم تطويرها. وفي كلتا الحالتين، نحن نرتكب خطأً ما، ونهجنا ببساطة ليس له أي معنى.
- وينبغي استخدام الاختبارات التلقائية. ليس من المنطقي قضاء الكثير من الوقت والجهد في كتابة منتج برمجي ووضعه في مستودع ثم نسيانه. يجب إجراء الاختبارات وإجرائها بانتظام قدر الإمكان.
- يجب أن تعمل الاختبارات التلقائية بثبات. بغض النظر عن الوقت من اليوم ومنصة الإطلاق وإعدادات النظام الأخرى، يجب أن تؤدي عمليات التشغيل الاختبارية إلى نفس النتيجة. كقاعدة عامة، يتم ضمان ذلك من خلال حقيقة أن الاختبارات التلقائية تعمل مع بيانات اختبار خاصة مع إعدادات النظام الثابتة.
- يجب أن تعمل الاختبارات التلقائية بسرعة مقبولة لمشروعك. يتم تحديد هذه المرة بشكل فردي لكل نظام. يستطيع بعض الأشخاص تحمل تكاليف العمل طوال اليوم، بينما يجد آخرون أنه من الضروري القيام بذلك في ثوانٍ. سأخبركم بعد قليل عن معايير السرعة التي حققناها في مشروعنا.
- يجب أن يكون تطوير الاختبار التلقائي مرنًا. لا يُنصح برفض اختبار أي وظيفة لمجرد أننا لم نقم بذلك من قبل أو لسبب آخر. لا يفرض utPLSQL أي قيود على التطوير، وتسمح لك Oracle، من حيث المبدأ، بتنفيذ مجموعة متنوعة من الأشياء. معظم المشاكل لها حل، إنها مجرد مسألة وقت وجهد.
- قابلية النشر. لدينا العديد من المدرجات حيث نحتاج لإجراء الاختبارات. في كل جناح، يمكن تحديث تفريغ البيانات في أي وقت. من الضروري إجراء مشروع باختبارات تلقائية بحيث يمكنك إجراء التثبيت الكامل أو الجزئي دون ألم.
وفي المنشور الثاني بعد يومين سأخبرك بما فعلناه وما هي النتائج التي حققناها.
المصدر: www.habr.com