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

Question

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

شكرا ، جيف

Answer 1

لديك مشكلتان (على الأقل) - تعقيد البيئة (الخادم) وتعقيد واجهة المستخدم الرسومية.

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

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

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

فكرة أخيرة - حظا سعيدا!

Answer 2

أدوات اختبار واجهة المستخدم الرسومية الأخرى التي يمكنني تقديمها هي:أفكار بيضاء, PyWinAuto, AutoIt, AutoHotKey.

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

Answer 3

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

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

"يتضمن اختبار واجهة المستخدم الرسومية بشكل متكرر إرسال رسالة إلى الخادم ثم مراقبة الاستجابة على واجهة المستخدم الرسومية" هذا البيان يقلقني.

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

إذا كنت بحاجة إلى اختبارات وظيفية آلية للخادم، فلا أرى ضرورة لمشاركة واجهة المستخدم الرسومية في تلك الاختبارات.

Answer 4

تعد Mercury QuickTest Pro وBorland SilkTest وRanorex Recorder من بعض أدوات اختبار واجهة المستخدم الرسومية.

Answer 5

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

إذا كان التطبيق الخاص بك يستند إلى Windows .NET، فيمكنك المحاولة أبيض.

Answer 6

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

الاتجاه الجديد هو تجاهل اختبارات واجهة المستخدم الرسومية.راجع نمط ModelViewPresenter من Fowler كمبدأ توجيهي نص الرابط

Answer 7

أوضح طريقة يمكنني أن أقول بها هذا هي:

لا تضيع وقتك في كتابة اختبارات واجهة المستخدم الرسومية الآلية.

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

Answer 8

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

هذا يعني لا منطق في فئات واجهة المستخدم الرسومية.افصل هذا في نماذج العرض التقديمي المسؤولة عن التحقق من صحة المدخلات وما إلى ذلك.

للاختبار على جهاز Unix، نستخدم خادم Xvfb كشاشة العرض عند إجراء الاختبارات.

Answer 9

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

Answer 10

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

Answer 11

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

Answer 12

لا تفوت حرف "U" في "واجهة المستخدم الرسومية"
أعني:إذا كان ما تحاول اختباره يعمل بشكل صحيح ويعمل كما هو مخطط له، فيمكنك المتابعة إجابة سيب روز.

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

Answer 13

لتجربة اختبار واجهة المستخدم الرسومية البسيطة المستندة إلى الويب iMacros (مكون إضافي Firefox بسيط ، يحتوي على ميزة رائعة لإرسال الاختبار بأكمله إلى شخص آخر) لاحظ أنه تم تهجئة البسيط بالأحرف الأولى ...