مرحبا عزيزي القراء. اليوم نود أن نتزامن مع إطلاق الدورة التدريبية "Python QA Engineer" . توقعًا للأسئلة المحتملة ، نحذر من عدم وجود كلمة حول Python في المقالة ، ولكن مع ذلك نجد هذه المواد مفيدة للمختبرين ، لذلك قررنا مشاركتها معك.
ليس من الممكن إجراء اختبار لكل أصغر التفاصيل في الكود ، لذلك ، يجب أن يجري اختبار الانحدار عملية تحقق شاملة والتركيز على منطقة معينة بالكامل. الهدف الرئيسي هو التأكد من عدم حدوث خطأ انحدار واحد في الإضرار بعملية تجارية حرجة. هذا الجهد هو الذي يجعل من الممكن الاستفادة من الأتمتة. سيساعد نهج الاختبار التلقائي الذي يهدف إلى الحد من أخطاء الانحدار على تحقيق تقدم كبير صوب بناء علاقات عملاء جيدة وزيادة قيمة العلامة التجارية.
فريقي مسؤول عن اختبار تطبيق محاسبة يستخدم حسابات متطورة وإدخالات دفتر سجلات في نظام المحاسبة. كل هذا هو سير العمل ، وإغلاق الكتب كل شهر فيه هو الأكثر أهمية.
مع كل إصدار ، هناك بعض التغييرات في الحسابات ، على سبيل المثال ، قد يكون من الضروري زيادة الحساب أو الخصم ، أو قد يتم تقسيم القيمة الحالية بين الحسابين. غالبًا ما تؤدي مثل هذه التغييرات في تطبيق معقد يحتوي على العديد من التبعيات الداخلية والخارجية إلى سلوك غير متوقع ، بما في ذلك أخطاء الانحدار ، في أماكن غير متوقعة وغير مترابطة على ما يبدو.
دعونا نتعامل مع خطأ الانحدار ، يطلق عليه أحيانًا مشكلة حرجة أو مشكلة إنتاج. بعد العمل لعدة سنوات في صناعة البرمجيات ، أنت تدرك أن خطأ الانحدار الذي تسرب إلى الإنتاج هو أكثر أهمية بكثير من الميزة الجديدة التي تعمل بشكل غير صحيح. والحقيقة هي أن الوظيفة الجديدة لا تزال مخفية ، وبالتالي ، عند تعطلها ، يكون التأثير على مكون العمل ضئيلًا ، بينما في حالة حدوث خطأ الانحدار ، يعتمد المستخدم على وظيفة العمل وعلى الأرجح ليس لديه نسخة احتياطية من نظام العمل.
تنجم أخطاء الانحدار عن التغييرات التي لم يأخذها مدير المشروع أو مالك المنتج في الاعتبار أثناء اختبارات القبول ؛ مهندس معماري ، مطور أثناء مراجعة الكود في مرحلة التصميم أو التنفيذ ؛ أو من قبل محلل ضمان الجودة واختبار في حالات الاختبار. أخطأت جميع شبكات الأمان ووجد المستخدم ذلك. إذا تم اكتشاف خطأ في أحد التحديثات الحديثة في أي من المراحل المذكورة أعلاه ، أي الفرق أو الأطراف المهتمة أو أي رابط آخر موجود في مؤسستك ، ثم تمت مراجعته قبل الإصدار ، أو على الأقل تم تقييمه من أجل الأهمية.
تنطوي أخطاء الانحدار على عدة تكاليف: تصحيح عاجل ، وفرض عقوبات على الانتهاك المحتمل لاتفاقية مستوى الخدمة ، والأهم من ذلك أنها تلحق الضرر بثقة المستخدمين في منتجك. قد يقررون أن الإصدار الجديد سوف يكسر شيئًا ما يعمل بالفعل.
أصبح من المهم بالنسبة لفريقي التحقق من كل شيء على الإطلاق.
ومع ذلك ، فمن المعروف أن هذا غير ممكن ، أو على الأقل باهظ التكلفة ويستغرق وقتًا طويلاً. لذلك ، ركز "اختبار كل شيء" على الأمرين التاليين: العمليات التجارية الحرجة والاعتقاد بأن السلوك في العمليات التجارية الحرجة الرئيسية سيكون هو نفسه كما في الإصدار الأخير ، قبل التغيير. بشكل عام ، أردنا التأكد من أنه في الإصدار الأخير ، لم يظهر خطأ الانحدار في عملية الأعمال الهامة.
قمنا بتقييم مناهجنا النموذجية للاختبار الآلي للتحقق من الحسابات وللتحقق من أن كل المنطق موصوف في الكود الخاص باختبار التشغيل الآلي. أثار هذا النهج سؤالًا كلاسيكيًا: "من الذي يختبر رمز الاختبار؟" إذا لم تنجح حالة الاختبار ، كانت هناك نفس فرصة حدوث المشكلة في رمز الاختبار. بالإضافة إلى ذلك ، مع كل تغيير في التطبيق ، يجب أيضًا تحديث رمز الاختبار ، وقد حدثت هذه التغييرات بشكل متكرر.
أيضًا ، بفضل الاختبار الآلي ، تأكدنا من وجود مجموعة ثابتة من المدخلات ومجموعة معروفة من المخرجات. نظرًا لتعقيد التطبيق ، كان من المستحيل إرسال جميع مجموعات بيانات الإدخال الممكنة في وقت واحد. هناك حاجة أيضًا إلى مجموعات بيانات مختلفة في نهاية الشهر أو الربع أو السنة. كان الجدول مشكلة خطيرة ، لأنه يستغرق الكثير من الوقت لإنشاء مجموعة ضخمة من بيانات الإدخال والنصوص المقابلة.
كان هناك متغير آخر: بيانات المستخدم. كان لدينا امتياز خاص: لقد تلقينا نسخًا احتياطية من بيانات المستخدم كل شهر. تعتمد جودة الاختبار بشكل مباشر على البيانات المستخدمة للاختبار ، وتكون بيانات الإنتاج دائمًا أفضل من البيانات التي تم إنشاؤها ، لذلك كان امتيازنا ميزة كبيرة لم نرغب في تفويتها.
تحديد وتنفيذ اختبارات الانحدار
كانت فكرتنا هي استخدام الاختبارات الآلية ، والتي تتطلب الحد الأدنى من الصيانة اللازمة ، والتي تقوي ثقة أصحاب المصلحة في أن الإصدار سيكون بجودة مناسبة.
لذلك ، كنا بحاجة إلى استراتيجية اختبار لحالات العمل الحرجة التي من شأنها أن تضمن عدم وجود أخطاء الانحدار ، وبطبيعة الحال ، يمكن أن نضعها موضع التنفيذ بسرعة.
تبدو عملية التحضير لدينا كما يلي:
- النسخ الاحتياطي قاعدة البيانات من الإنتاج ، واستعادة مرتين ؛
- يتم تثبيت نظامي اختبار يعملان بشكل متوازٍ:
- واحد مع رمز الإنتاج ؛
- آخر مع الإصدار الحالي من التطبيق قيد الاختبار.
يوفر هذا النهج نظامين متطابقين مع وجود اختلافات في التعليمات البرمجية في إصدار واحد فقط:
يعد وجود نظامين أمرًا مهمًا جدًا ، حيث يساعد على فهم أن أي مشكلة تنشأ فقط بسبب أحدث تغييرات الرمز.
يتم فصل الاختبارات ، لذلك من العملية القياسية "تنفيذ إجراء والحصول على رد فعل" ، ننتقل إلى حقيقة أن يتم تنفيذ الإجراءات من نقطة إلى أخرى مع الحفاظ على سير العمل ، وبعد ذلك يتم مقارنة تقارير الخطأ. هذا هو المفتاح لاكتشاف الأخطاء غير المتوقعة.
عندما يركز الاختبار على وظيفة جديدة أو نوع من التغيير ، يتبين أن الاختبار يركز بشكل خاص عليها ، أي يتم التحقق من أهمية تغيير معين. يختلف اختبار الانحدار في أنه يجب أن يتحقق من عدم تغير أي شيء آخر. ينعكس هذا الاختلاف في سيناريوهات الأتمتة. فهو يجعل البرامج النصية الخاصة باختبار الوظائف المحددة غير مناسبة للبحث عن أخطاء الانحدار ، لذلك يلزم اتباع نهج مختلف هنا.
على سبيل المثال ، إذا كنت تعمل مع نظام إدارة الطلبات ، فستحتاج إلى برنامج نصي لتقديم الطلبات مع الكثير من بيانات الإدخال لتقديم الطلبات لنظامين اختبارين مثبتين (يفضل العمل بالتوازي) ، ثم تحصل على تقرير حول الطلبات في اليوم السابق ومقارنتها قيمة. ثم يتم تأكيد جميع الطلبات أو الموافقة عليها (هذا الإجراء) ، والتقارير ، مثل الطلبات المؤكدة يوميًا ، وأوامر المخزون ، وتقارير المستودعات ، والأوامر من كل شركة نقل ، ونوع الشحنة ، ونوع الدفع ، إلخ. سيتم مقارنة في نظامين. هذا يستمر طوال سير العمل بأكمله. يمكنك الجمع بين الإجراءات ، مثل وضع الأوامر وتأكيدها ، ثم مقارنة التقارير في مراحل منفصلة.
مثال آخر هو نظام إدارة الفندق ، الذي يتم فيه تعريف الإجراءات الفردية بأنها عمليات تجارية مهمة ، مثل تسجيل الوصول ، وإعداد الفواتير في المطعم ، وتلقي المخزون. سيتم تعيين كل هذه العمليات الخاصة بهم الإجراءات والتقارير. الفرق في هذا النظام مقارنة بالمثال السابق هو أن مجموعات الاختبار يمكن أن تعمل بشكل متوازٍ ، وليست هناك حاجة لإكمال الخطوة قبل بدء الخطوة التالية.
تعتبر المقارنة بين التقريرين لحظة للحقيقة ، ويجب أن لا تشوبها شائبة ، بمعنى أنه لا ينبغي أن يكون لدى أي من الأطراف المعنية شكوك حول صحتها. الفرق في التقارير هو الفرق الحقيقي.
لهذه العملية ، نستخدم واجهة خدمة الويب. يتم إرسال جميع التقارير بالتوازي على نظامين ، ونتيجة لذلك ، تتم مقارنة الاستجابة المتلقاة بتنسيق JSON.
تجري المقارنة على ثلاث جبهات:
- المصدر (الإنتاج) ناقص الهدف (التطبيق قيد الاختبار) ؛
- الهدف ناقص المصدر ؛
- مقارنة القيم للحصول على التقاطع.
ستعمل هذه الطريقة مع عرض XML أو XLS أو CSV أو أي تنسيق آخر. نحتاج إلى التأكد من عدم وجود سجلات غير ضرورية ، وعدم وجود سجلات مفقودة ، وجميع قيم السجلات متطابقة.
هذا هو جوهر النهج الذي نتحدث عنه. كل هذه المعلومات قابلة للقراءة في التطبيق ، والتي يتم إصدارها كتقرير أو ، في بعض الحالات ، تعمل كواجهة للتطبيقات الأخرى.
يكمن نجاح هذا النهج في أداة المقارنة أو الأداة المساعدة التي تعالج الحالات المتعلقة بالتطبيق الخاص بك. يمكنك اعتبار نفسك محظوظًا إذا وجدت شيئًا مناسبًا "خارج الصندوق" ، وإلا ، فمن المهم أن تفهم أن الاستثمار في مثل هذه الأداة يستحق كل هذا العناء لأنه سيحقق نتائج جيدة.
بعد كل الحديث عن الأتمتة ، تحتاج إلى إدراج ملاحظة. نظرًا لوجود بعض الاختلافات في التقارير ، حيث يجب أن تكون هناك كما هو مطلوب ، يجب أيضًا تحليل جميع النتائج يدويًا. يجب أن تكون هناك نتائج ناجحة واضحة لاجتياز حالات الاختبار ، ومع ذلك ، يجب أيضًا تحليل النتائج غير الناجحة وتأكيد صلاحيتها. بما أننا نتحدث عن أخطاء اختبار الانحدار ، فيجب إصلاحها قبل الإصدار. بالطبع ، هناك بعض الاستثناءات التي يتم التعامل معها وفقًا للتطبيق.
إعداد البرنامج
جميع التطبيقات مختلفة ، ويحدث أيضًا تثبيت وتكوينها بطرق مختلفة. لإعداد التطبيق للاختبار ، قد تكون هناك حاجة لبعض الخطوات الإضافية ، لذلك ، يجب أن تؤخذ في الاعتبار في الوقت المناسب وفي المكان المناسب لتشغيل الاختبارات. فيما يلي مجموعة من الخطوات النموذجية:
"إرباك" البيانات من الإنتاج عن طريق حذف معرفات البريد الإلكتروني أو غيرها من المعلومات السرية ، أو استبدالها ببيانات وهمية ؛
الحصول على البيانات في النموذج المناسب لتشغيل الاختبار ؛
تكييف الإعدادات لبيئة ضمان الجودة ، على سبيل المثال ، عن طريق تغيير علاقات التكامل.
الشيء الوحيد الذي يستحق التذكر هو أنه يجب تنفيذ الخطوات المذكورة أعلاه لكلا التثبيتين. تذكر أنه قبل بدء مجموعة الاختبار ، يجب أن تكون الإعدادات متطابقة.
في كثير من الأحيان ، يمكن لإجراءات بخلاف طلب تقرير إرجاع كائن ، على سبيل المثال ، يمكن لأي إجراء ، مثل إنشاء أو تعديل أمر ، أن يعيد كائن طلب جديد. في هذه الحالة ، تحتاج إلى مقارنة كائنين وعدم انتظار مقارنة التقارير. يمكن أن يساعد هذا في تحديد الخطأ في المراحل المبكرة من الجذر.
يوصى أيضًا بتقسيم المجموعة بأكملها إلى مجموعات أصغر ، على سبيل المثال عن طريق تجميع المعاملات والتقارير ذات الصلة معًا. يمكن تشغيل مجموعات بالتوازي لتوفير وقت التشغيل. ومع ذلك ، بالنسبة للتطبيق الذي يحتوي على سير عمل نموذجي ، يعمل هذا فقط إذا كان يمكنك تقسيم الحالات رأسياً وأفقياً ، أو العكس.
يمكن أن تبدأ الاختلافات بالتقنيات - JSON أو XML أو أدوات القياس (int / string / float) ، وتمدد حتى يتفاعل التطبيق قيد الاختبار والإنتاج مع هياكل مختلفة ، ولكن لا يزال يتوافق مع البنية. على سبيل المثال ، قد يستخدم إصدار الإنتاج ملف JAR القديم ، والذي يعمل بتنسيق معين ، وفي الإصدار الجديد تم تحديث ملف JAR والآن تغير تنسيق الاستجابة ، لذلك ستُظهر المقارنة عدم تناسق. لمقارنتها بشكل صحيح ، تحتاج إلى مكون إضافي مؤقت.
ربما سيكون هناك عدد قليل من هذه الحالات. في مثل هذه الحالات ، يكون من السهل أحيانًا تعديل التصميم أو مراعاته في سياق الحل البديل.
هناك العديد من الخيارات للتعامل مع مثل هذه المقارنات:
تجاهل بعض الحقول ، مثل المعرفات والتواريخ ؛
تجاهل الاختلافات العددية أقل من 0.0001 ؛
تجاهل حساسية القضية ؛
هيكل التغييرات في جوابين.
تحسين اختبار الانحدار
يجب أن يكون اختبار الانحدار كليًا ويركز على منطقة كاملة. هذا التوازن سوف يساعد على الاستفادة من الأتمتة. سيساعد نهج الاختبار الآلي في تقليل عدد أخطاء الانحدار وسيساعد في الطريق إلى علاقات جيدة مع العملاء وزيادة قيمة العلامة التجارية.
الآن ، في إيقاع الحركة المستمرة للأمام ، يريد فريقنا محاولة التخلي عن تثبيتات النظام المتطابقة التي نستخدمها الآن وتنفيذ نفس الاستراتيجية على تثبيت واحد. نريد الاحتفاظ بإجابات الإنجازات السابقة واستخدامها للمقارنة. يمكن دائمًا تحسين نهج الاختبار. أتمنى لنا حظا سعيدا!
تم إعداد الترجمة خاصة لطلاب دورة "Python QA Engineer" .