تجارب مع أتمتة واجهة المستخدم وWPF [مغلق]

Question

نحن نعمل على تطوير تطبيق كبير إلى حد ما يعتمد على WPF ونرغب في تضمين بعض اختبارات واجهة المستخدم الآلية في مجموعة الاختبار الخاصة بنا (والتي تحتوي بالفعل على عدد من اختبارات الوحدات).

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

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

لا تتردد في نشر تجاربك هنا أو الارتباط ببعض المراجع الجيدة التي ربما فاتني

Answer 1

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

ما حاولنا القيام وإقامتها لتبدو وكأنها وحدة الاختبارات أي [TestFixture] [Test] الخ ثم كنا قادرين على تشغيلها من خلال nunit في نفس الوقت على وحدة الاختبارات.

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

إذا كنت لا مانع من دفع ثمن البرنامج ثم أنصح TestComplete .

Answer 2

وأنا في منتصف القيام أتمتة UI من التطبيق WPF في العمل. أنا باستخدام الأبيض وآيرن روبي ويعمل كبيرة. لقد كتبت عن مدى لقد فعلت ذلك هنا: <لأ href = "http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby- والأبيض / "يختلط =" noreferrer "> http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/

Answer 3

لقد ذهبنا في البداية إلى اللون الأبيض، ثم ابتعدنا عنه.يحاول أن يكون عامًا ومجردًا عبر Win32 API وWinforms وتطبيقات Java وواجهة برمجة التطبيقات لأتمتة MS UI.تحاول واجهة برمجة تطبيقات أتمتة MS UI أيضًا أن تكون عامة ومجردة عبر Win32 API وWinforms وWPF، لذلك ينتهي بك الأمر في سيناريو "القاسم المشترك الأدنى للقاسم المشترك الأدنى".

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

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

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