اختبار الدخان تطبيق الويب .NET

Question

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

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

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

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

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

أصبح المطورون الآن أفضل في توثيق إرشادات أجهزة الكمبيوتر أكثر من الأشخاص ، لذلك يبدو أن الحل الواضح هو استخدام مجموعة من NUNIT (أعرف أن هذه ليست اختبارات الوحدة في حد ذاتها ، ولكنها اختبار مبني للأغراض Runner) و APIs Watin أو Selenium للركض من خلال خطوات المتصفح الواضحة والاتصال بخدمة الويب وشرح للعمليات كيفية إجراء اختبارات الوحدة هذه. أستطيع فعل ذلك؛ لقد فعلت ذلك بالفعل بالفعل.

لكن ألا يكون من الجيد أن أجعل هذه العملية أكثر بساطة؟

في هذه المرحلة ، سيتعين على شباب العمليات والكمبيوتر معرفة مجموعة الاختبارات المتعلقة بإصدار التطبيق وإخبار Nunit Runner أي عنوان URL الأساسي الذي يجب أن يشير إليه (على سبيل المثال ، www.example.com = v3. 2 أو test.example.com = v3.3).

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

هل هناك تطبيق مفتوح المصدر من شأنه أن يفعل ذلك؟ هل هناك حاجة لواحد؟ هل هناك حل باستخدام شيء آخر غير Nunit ، ربما Fitnesse؟

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

Answer 1

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

Answer 2

عملت في كاتب اختبار الدخان لتطبيق ASP.NET. كنا Quicktest Pro, ، تم إجراء أتمتة عمليات الاختبار مع مركز الجودة (كان يسمى مدير الاختبار.). وشمل ذلك كتابة مئات من البرامج النصية للاختبار التي تتم أتمتة متصفح الويب الذي يتفاعل مع تطبيق الويب. هذه الاختبارات حيث تستخدم التحقق من صحة البناء قبل طرحها على خوادم الإنتاج لدينا. يتيح لك مركز الجودة تحديد "تجمع" من آلات الاختبار للسماح لك بتشغيل قائمة كبيرة من البرامج النصية للاختبار بطريقة متعددة الخيوط.

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

Answer 3

لقد استخدمت السيلينيوم في الماضي للقيام بهذا النوع من اختبارات الدخان لنشر الويب. يمكنك كتابة مجموعة من البرامج النصية للاختبار ثم تشغيلها ثم ضد نفس الموقع في بيئات مختلفة.

Answer 4

لقد وضعت أيضًا بعض التفكير في هذا التسلسل واقترحت اتباع نهج إعلاني للنشر والتحقق ، انظر هنا للحصول على أفكاري ،

http://jimblogdog.blogspot.co.uk/2010/10/introducingDeclarative-Deployment.html

لقد قمت أيضًا بإنشاء بعض الإضافات إلى مشروع Open Source Project Wolfpack لأتمتة هذه العملية بأكملها. تقوم بشكل أساسي بتعبئة "اختبارات دخان النشر" كحزمة Nuget ونشرها إلى خلاصة Nuget الخاصة بك. سيقوم Wolfpack تلقائيًا باكتشاف الإصدار الجديد من الحزمة وتنزيله ، إلى جانب حزمة NUNIT.Runner Nuget وتفريغ جميع الملفات. سيتم بعد ذلك تشغيل اختباراتك بصمت باستخدام Nunit Console Runner وتحليل النتائج في تنبيه يمكنك تلقيه إما عن طريق البريد الإلكتروني ، الهدير ، Hipchat إلخ.

http://wolfpack.codeplex.com/

http://wolfpackcontrib.codeplex.com/wikipage؟title=nunitDeploymentPublisher

Answer 5

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

Answer 6

لا أعرف أي VCs التي تستخدمها ، ولكن يمكنك كتابة حل يسحب ملف تكوين خاص بالنسخة من VCS من خلال خدمة وسيطة.

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

Answer 7

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