بنية اختبار مسارات الفشل باستخدام Application Verifier

نظرة عامة على الحالة

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

الأعراض

• لم تكشف الاختبارات العادية مشكلات مسارات الفشل في وقت مبكر بما فيه الكفاية
• كان من الصعب إعادة إنتاج حالات نقص الموارد والأخطاء المتعلقة بـ handle بأمان
• كانت خطوات التحقيق معرضة لخطر التحول إلى عمل يدوي مفرط ومعتمد على الشخص

القيود

• استنزاف موارد الجهاز الحقيقية مباشرةً مكلف ومحفوف بالمخاطر
• كان لا بد من كشف أعطال حدود native / Win32 قبل وقوع حوادث الإنتاج
• كان يجب أن تظل النتيجة مفيدة للتحقيقات المستقبلية، وليس فقط للتحقيق الحالي

ما لاحظناه

• إعدادات Verifier مثل Handles وHeaps وLow Resource Simulation
• تتبعات من !htrace و page heap ونقاط توقف Verifier
• العلاقة بين سجلات دورة الحياة المخصصة والأدلة من جانب verifier

كيف ضيقنا النطاق

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

كيف حسّنّاه

• بنينا أساسًا قابلاً لإعادة الاستخدام لاختبار مسارات الفشل
• جعلنا شذوذات handle و heap قابلة للملاحظة في حلقات أقصر
• نظمنا نقاط الملاحظة بحيث يمكن لمراجعة التصميم اللاحقة ومنع التكرار البناء عليها

الخدمات التي ترتبط بها هذه الحالة

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

مقالات ذات صلة

تواصل معنا

إذا كان ما تتعامل معه قريبًا من محتوى هذه الصفحة، يُرجى التواصل معنا مع شرح الوضع الحالي ونوع الدعم الذي تحتاجه.