😰 ↖️ ❣️ لماذا وكيف نختبر التحديث ⏭️ 🚬 👩🏾‍🍳

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

ما الذي لا يشعر المستخدمون عادة بالرضا عنه؟

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

كل هذه المشاكل ذات صلة بتطبيق الهاتف المحمول ونظام DLP الذي نختبره في المنزل. كذلك حول ما نتعامل معه.

ما نطلقه وما يجب تحديثه

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

يتكون المنتج من عدة أجزاء ، في هذه المقالة سننظر في تحليل الحوادث المرورية في InfoWatch Traffic Monitor وخادم التخزين. يعمل المنتج على نظام تشغيل لينكس ، ولديه قاعدة بيانات خاصة به. يستخدم ضابط الأمن وحدة تحكم الويب للعمل. يتم حاليًا دعم توزيعات Linux مختلفة وقواعد بيانات. يمكن تثبيت النظام بعدة طرق: الكل في واحد ، عندما تكون جميع المكونات على جهاز واحد ؛ والتوزيع الموزع عند وجود مكونات النظام على الأجهزة المادية المختلفة.

بالإضافة إلى الوظائف المعلنة للنظام ، يجب أن نضمن تحديثًا من الإصدارات الرئيسية N-1 و N-2 إلى N ، بالإضافة إلى تحديث من جميع الإصدارات الثانوية - التصحيحات والإصلاحات العاجلة لكل إصدار. ويرجع ذلك إلى حقيقة أن عملاءنا غالبًا ما يكون لديهم بنية تحتية معقدة لتكنولوجيا المعلومات ، ويمكن أن يستغرق التحديث وقتًا طويلاً ، لذلك من المهم تحديد عدد التحديثات ، وليس تنفيذها كثيرًا ، وتجنب وقت التوقف.

توفر كل هذه الشروط مجموعة كبيرة بما يكفي من تكوينات منتجنا ، والتي يجب أن نضمن تحديثًا ناجحًا لكل منها. وهذا يعني تحديثًا ، ونتيجة لذلك:

لا تضيع بيانات المستخدم
لا يتم كسر الميزات القديمة
ميزات جديدة متاحة للاستخدام

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

خذ بعين الاعتبار المثال مع جدول التحديث الخاص بنا عند إصدار الإصدار الرئيسي 3. بالنسبة للإصدار 1.0.0 ، تم إصدار تصحيحتين وثلاث إصلاحات عاجلة ، وللإصدار 2.0.0 تم إصدار إصلاحين عاجلين.

1.0.0	2.0.0	3.0.0
1.0.1	2.0.1
1.0.2	2.0.2
1.1.0
1.1.1
1.2.0

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

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

تاريخيا ...

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

يعد تخطيط اختبار البحث دون معرفة جيدة بالمنتج مهمة لا شكر لها ، فقد كانت محفوفة بعواقب مثل:

تحديثات الاختبار في كل مرة تستغرق وقتًا مختلفًا. في كثير من الأحيان ، تم تخصيص الوقت وفقًا للمبدأ المتبقي ، حيث تم اختبار التحديث عندما يكون المنتج مثبتًا بالفعل وتبقى اللمسات النهائية قبل الإصدار.
في بعض الأحيان تم نسيان بعض البيئات.
, , . , , , «» - .

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

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

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

ومع ذلك ، لبعض الوقت كنا راضين عن نتائج اختبار البحث: لم يكن هناك الكثير من العيوب العسكرية للتحديث ، ولم تكن هناك موارد للتغييرات من أجل الميزة النظرية.

هناك خطأ ما

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

في هذه الحالة ، لم تعد العملية الحالية ترضينا. يجب تغيير شيء ما.
بدأنا بصياغة المشاكل التي برأينا منعتنا من اختبار التحديث بشكل أفضل. بعد المناقشة ، تم تشكيل قائمة المشاكل التالية:

;
, ;
, , , , ;
, ;
;
. ? ? ? ?

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

يجب أن تكون العملية أكثر انفتاحًا وشفافية ، لذلك نتخلى تمامًا عن اختبار البحث لصالح حالات الاختبار.

لإنشاء حالات الاختبار اللازمة ، نحتاج إلى معلومات حول التغييرات بين الإصدارات. يجب طلب هذه المعلومات من مطوري المنتجات والمحللين.

في النهج الجديد ، نستخدم مجموعة من الفحوصات على كائنات النظام (دون تغيير وتغيير أثناء التحديث) + فحوصات دخان للوظيفة (القديمة والجديدة أو القديمة المتغيرة).

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

سيتيح لنا هذا المزيج من الفحوصات فرصة اختبار مكونات النظام التالية:

DB
الويب (الواجهة الأمامية والخلفية) ؛
مكونات لينكس

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

تتحول تحديثات الاختبار إلى انحدار. يتم إجراء الاختبار الوظيفي ، وليس كائنات النظام والعمليات عليها. سنقوم باختبار التحديث على حالات الاختبار في شكل اختبارات الدخان للتحقق الوظيفي + البيانات.

تقارير غير مفهومة. يمكن أخذ التغطية والنتائج من حالات الاختبار.

العملية غير شفافة. بعد حل كل مشكلة فردية ، تم تشكيل عملية جديدة تبررها احتياجاتنا وتم إصلاحها أيضًا بطريقة تمكن كل عضو في الفريق الآن من التعرف على مبادئه.

عملية جديدة

ونتيجة لذلك ، قمنا ببناء عملية فعالة إلى حد ما.

قمنا بتقسيم الاختبار إلى عدة مراحل ، والتي أعطت مكافآت غير مخطط لها ، وهي موصوفة أدناه:

تدريب.
- نقوم بتحليل التغييرات في النظام ، أعدت بالاشتراك مع المحللين والمطورين لتغيير المجالات.
- وفقًا لنتائج التحليل ، نقوم بتجميع قائمة بكائنات النظام المعدة لاختبار التحديثات.
- لكل كائن نظام ، يتم تحديد مجموعة الحالات والحالات والمعلمات الضرورية.
- نقوم بإنشاء حوامل مع الإصدار الضروري (المحدث) من المنتج.
- , .
- ( ).
- smoke- , .
:
- ;
- (, , , );
- , .
- .
- -, .
- .
- , .
- التحقق من العمليات على الكائنات (الإنشاء والتحرير والحذف).
- التحقق من تفاعل الأشياء مع الأشياء الأخرى (الكشف).

إيجابيات وسلبيات النهج

لقد حققنا هدفنا وهو:

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

ولكن بالتجول حول استراتيجية اختبار جديدة ، لا يمكننا أن نفشل في مواجهة ناقص واضح للنهج الجديد - زيادة كبيرة في وقت الاختبار.

بدأنا في قضاء الوقت ليس فقط في الاختبار المباشر ، كما كان الحال مع اختبار البحث. ارتبطت تكاليف الوقت الجديد بشكل أساسي بالتحضير للاختبار ، وهي:

تحليل التغيير ؛
إنشاء وتعبئة وصيانة منصات للتحديث ؛
تحديث مجموعات الاختبار القديمة وإنشاء مجموعات جديدة.

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

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

في المجموع ، وفقًا لنتائج المرحلة الأولى من التحسينات ، تلقينا ما يلي: بدأنا في قضاء المزيد من الوقت في الاختبار ، ولكن في الوقت نفسه لدينا عملية شفافة ، وعرض واضح للنتائج والمزيد من التغطية ، مما يتيح لنا:

الكشف عن المزيد من العيوب نتيجة فحص تحديثات المنتج في قسمك ؛
تقليل عدد العيوب عند تحديث عملائنا من قبل مهندسي التنفيذ ؛
تقليل عدد العيوب المتلقاة من الدعم الفني.

ماذا بعد؟ - حول التحسين

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

ذهبنا بطريقتين:

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

سأتحدث أكثر قليلا عن كل مسار.

الطريقة الأولى: التحسين بناءً على تحليل اختبارات التشغيل.

وبهذه الطريقة اخترنا تحسين اختبار التحديث بين الإصدارات الرئيسية ، أي بين تلك التي كان هناك تغيير كبير في الوظائف.

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

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

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

الطريقة الثانية: اختبار الأتمتة

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

في هذه المرحلة ، يتم اختبار التحديثات تلقائيًا عند إصدار التصحيحات والإصلاحات بشكل كامل تقريبًا.

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

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

ملخص

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

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

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

حاولنا أن نصف هنا بكل صراحة جميع الإيجابيات والسلبيات ، بالإضافة إلى مخاطر قراراتنا ، بحيث لا تبدو القصة حصريًا مثل قصة نجاح "كانت سيئة - لقد أصبحت جيدة".

نأمل أن تجد تجربتنا مفيدة.

المؤلف المادي:tryzhova (ريجوفا تاتيانا).

لماذا وكيف نختبر التحديث