اختبار أتمتة واجهة المستخدم الرسومية - أسئلة حول مقبض النافذة

Question

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

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

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

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

هل هناك أي طريقة أخرى (أبسط) للقيام بمثل هذه الأشياء (على سبيل المثال، قائمة انتظار الرسائل أو أي شيء آخر)؟

Answer 1

إذا كانت أداة اختبار واجهة المستخدم الرسومية الآلية لديها معرفة بإطار العمل الذي تم كتابة التطبيق فيه، فيمكنها استخدام تلك المعلومات لإنشاء نصوص برمجية أفضل أو أكثر تقدمًا. اكتمل الاختبار على سبيل المثال يعرف عن VCL وWinForms من بورلاند.إذا قمت باختبار إنشاء التطبيقات باستخدام Windows Presentation Foundation فلها دعم متقدم لذلك بناء في.

Answer 2

مشكلة مثيرة للاهتمام!لم أقم بأي برمجة Windows منخفضة المستوى (فكر في Win32) منذ فترة، ولكن إليك ما سأفعله.

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

من المحتمل أن تكون هناك طرق أكثر أناقة وروعة لتنفيذ ذلك، ولكن هذا ما أتذكره من أعلى رأسي، باستخدام استدعاءات Win32 API البسيطة فقط.

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

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

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

حظ سعيد!

كارل

Answer 3

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

فيما يلي بعض المنشورات حول NUnitForms التي تستحق القراءة

NUnitForms وفشل تسجيل DragDrop - مشكلة MTA مقابل STA

تطبيق تم تجميعه مع اختبار واجهة المستخدم الرسومية NUnitForms

Answer 4

لقد وجدت أخيرًا حلاً للتواصل بين تطبيق الاختبار والتطبيق قيد الاختبار: الجاسوس المدار.إنه في الأساس تطبيق .NET مبني على ManagedSpyLib.

يسمح ManagedSpyLib بالوصول البرمجي إلى عناصر تحكم Windows Forms الخاصة بعملية أخرى.ولهذا يستخدم Window Hooks وملفات تعيين الذاكرة.

شكرا لكل من ساعدني للوصول إلى هذا الحل!

Answer 5

لا يوفر Managed Spy حلاً لتطبيقات إطار العمل المضغوط.

تستوفي شركة Jamo Solutions (www.jamosolutions.com) متطلبات اختبار الأتمتة على الأجهزة المحمولة، بما في ذلك تطبيقات إطار العمل المضغوط ‎.net.