هل هناك طريقة صحيحة لتنفيذ عملية تحسنة مستمرة (AKA تصلب البرامج)؟

Question

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

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

هل هناك خدعة لهذا النوع من الاختبار؟ هل أحتاج إلى استهداف ميزة واحدة محددة في وقت واحد؟

Answer 1

عند تطوير إجراءات الاختبار الخاصة بك، قد ترغب في تنفيذ هذا النوع من الاختبارات:

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

• اختبار الانحدار، الذي ذكرته

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

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

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

اعتمادا على بيئتك، يمكن ربط هذه الاختبارات بعملية التطوير.

في بيئتي، نستخدم SVN للنسخة، يقوم BOT بتشغيل الاختبارات الموجودة ضد كل مراجعة وإرجاع الاختبارات الفاشلة والرسائل باسم المراجعة التي كسرها والمساهم (تسجيل الدخول الخاص به).

تعديل:

في بيئتي، نستخدم مزيجا من C ++ و C # لتسليم التحليلات المستخدمة في التمويل، وكان الرمز C ++ وهو قديم جدا بينما نحاول ترحيل الواجهات باتجاه C # والحفاظ على جوهر التحليلات في C ++ (أساسا بسبب متطلبات السرعة)

معظم اختبارات C ++ هي اختبارات وحدة مكتوبة يدوية وإجراء اختبارات الانحدار.

على الجانب C # نحن نستخدم nunit للاختبار الوحدة. لدينا اثنين من الاختبارات العامة.

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

يعد وضع الاتفاقيات الصارمة وأفضل الممارسات طريقة أخرى لتحسين جودة التعليمات البرمجية الخاصة بك.

Answer 2

هل هناك خدعة لهذا النوع من الاختبار؟

قلت، "لدينا اختبار يقوم بعدة ساعات من اختبار الانحدار الشهري في تطبيق واحد كل شهر في محاولة للبقاء قبل القضايا الصغيرة".

أعتقد أنه من خلال "اختبار الانحدار" تقصد "ممارسة ميزات قديمة يدويا".

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

"اختبار الانحدار" يعني لي أنك تفعل هذا الأخير.

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

هل أحتاج إلى استهداف ميزة واحدة محددة في وقت واحد؟

ماذا تحاول ان تفعل بالضبط:

• العثور على الأخطاء قبل أن يجدها العملاء؟
• إقناع العملاء بأنه هناك خطأ قليل في الجديد تطوير؟
• قضاء القليل من الوقت ممكن في الاختبار؟

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

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

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

يبدو وكأنه عملية نسبة شائكة للغاية لأن هناك رمز جديد دائما للكتابة

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

---

يحرر: تجدر الإشارة إلى أن الاختبار ليس هو السبيل الوحيد للعثور على الأخطاء. هناك ايضا:

• مراجعات تصميم غير رسمي (35٪)
• عمليات التفتيش الرسمية للتصميم (55٪)
• استعراض الرمز غير الرسمي (25٪)
• تفتيش الرمز الرسمي (60٪)
• فحص مكتبي من التعليمات البرمجية (40٪)
• اختبار الوحدة (30٪)
• اختبار مكون (30٪)
• اختبار التكامل (35٪)
• اختبار الانحدار (25٪)
• اختبار النظام (40٪)
• اختبار بيتا منخفض الحجم (<10 مواقع) (35٪)
• اختبار بيتا عالية الحجم (> 1000 موقع) (70٪)

النسبة المئوية التي وضعتها بجانب كل هي مقياس لسعر إزالة العيوب لكل تقنية (مأخوذة من صفحة 243 من McConnel تقدير البرمجيات كتاب). يبدو أن أكثر التقنيتين فعالتين تفتيشا رسميا من التعليمات البرمجية، واختبارات بيتا عالية الحجم.

لذلك قد يكون من الجيد إدخال رمز رسمي مراجعات: قد يكون ذلك أفضل في الكشف عن العيوب من اختبار الصندوق الأسود هو.

Answer 3

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

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

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

Answer 4

هناك الكثير من الحديث هنا عن اختبار الوحدة ولم أستطع الاتفاق أكثر. آمل أن يفهم Josh أن اختبار الوحدة عملية ميكانيكية. لا أتفق مع PJ في هذه الاختبارات هذه يجب أن تكون مكتوبة قبل ترميز التطبيق وليس بعد. وهذا ما يسمى TDD أو التطوير مدفوعة.

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

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

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

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

لم تذكر ما هي بيئة تطويرك. إذا كان لك متجر J2EE، فأنا أقترح عليك أن تنظر إلى ما يلي.

• كرونسكونترول للتكامل المستمر
• تخريب عن التحكم في إصدار التعليمات البرمجية المصدر لأنه يتكامل جيدا مع CruiseControl
• الربيع لأن di يجعل من السهل إياجي اختبار الوحدة لأغراض التكامل المستمر
• جاريت للوحدة اختبار الطبقة الوسطى
• httpunit للوحدة اختبار واجهة المستخدم الرسومية
• Apache JMeter للاختبار الإجهاد

Answer 5

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

بمجرد تحديدها، اكتب اختبار يذهب أحمر. وبعد الآن. ثم إصلاح الخطأ. تأكيد أنه ثابت. تأكيد أن الاختبار هو الآن لون أخضر. وبعد كرر كما تأتي الأخطاء الجديدة.

Answer 6

آسف أن أقول ذلك ولكن ربما لا يمكنك اختبار ما يكفي أو متأخرا جدا أو كليهما.