اختبارات واجهة المستخدم المؤتمتة هي موضوع يخشى حتى المطورين ذوي الخبرة. علاوة على ذلك ، فإن تقنية مثل هذا الاختبار ليست شيئًا غير عادي ، وفي حالة Visual Studio Coded UI Tests هي امتداد لنظام اختبار الوحدة المضمنة Visual Studio Team Test. في هذه المقالة ، أود أن أتطرق إلى موضوع اختبار واجهة المستخدم بشكل عام ، وكذلك عن تجربتنا الشخصية في استخدام اختبارات واجهة المستخدم المرئية Visual Studio في العمل على محلل ثابت PVS-Studio.
الأساسيات
أولاً ، دعنا نحاول معرفة سبب عدم شهرة اختبارات واجهة المستخدم بين المطورين مثل اختبارات الوحدة الكلاسيكية.
هناك العديد مما يسمى "أهرام الاختبار" على الشبكة والتي توضح التوزيع الأمثل الموصى به لعدد الاختبارات عبر طبقات التطبيق. جميع الأهرامات متشابهة وتحتوي على فكرة عامة: يجب أن تكون أكبر عدد ممكن من الاختبارات أقرب ما يمكن من الشفرة. والعكس صحيح. سأعطي مثالاً على أحد هذه الأهرامات ، والذي يحتوي على توصيات إضافية حول نسبة عدد الاختبارات في المئة.
تقع اختبارات الوحدة عند قاعدة الهرم. في الواقع ، هذه الاختبارات أسهل في مرحلة التطوير ، وسيتم تنفيذها بسرعة كبيرة. في الجزء العلوي من الهرم ، من ناحية أخرى ، هي اختبارات واجهة تلقائية. لا ينبغي أن تكون هذه الاختبارات كثيرة ، لأن تعقيد إنشائها ، وكذلك وقت التنفيذ ، كبيران جدًا. بالإضافة إلى ذلك ، ليس من الواضح إلى من يعهد إلى إنشاء اختبارات واجهة المستخدم. في الواقع ، نحن نتحدث في جوهره عن محاكاة إجراءات المستخدم. كل هذا بعيد جدًا عن رمز التطبيق ، لذلك يتردد المطورون في القيام بهذا النوع من العمل. ولإجراء اختبارات تلقائية عالية الجودة للواجهات دون مشاركة المبرمجين (أو بأقل مشاركة) ، يلزم استخدام الأدوات المدفوعة. غالبًا ما يؤدي الجمع بين جميع هذه العوامل إلى حقيقة أن اختبارات واجهة المستخدم لا تفعل ذلك على الإطلاق ، وتقتصر على الاختبار اليدوي الفردي للوظائف الجديدة. بالإضافة إلى ذلك ، تعد اختبارات الواجهة باهظة الثمن ليس فقط في مرحلة التطوير ، ولكن أيضًا خلال دورة حياة التطبيق الإضافية. حتى التغيير الطفيف في واجهة المستخدم يمكن أن يؤدي إلى أخطاء في تنفيذ العديد من الاختبارات والحاجة إلى تعديلها.
ألاحظ أنه في الوقت الحاضر ، يتوافق نظام الاختبار بشكل عام مع التوصيات. يبلغ عدد اختبارات واجهة المستخدم الرسومية (45) عُشر العدد الإجمالي لاختبارات PVS-Studio. في الوقت نفسه ، عدد اختبارات الوحدة ليس كبيرًا جدًا ، ولكن يتم استكمالها بمجموعة من أنظمة الاختبار الأخرى:
- اختبارات أداء المحللون (C / C ++ / C # / Java) ، حيث يقومون بفحص مجموعة كبيرة من مشاريع الاختبار على أنظمة التشغيل المختلفة (Windows و Linux و macOS) ويقارنون سجلات التحذيرات الجديدة مع التحذيرات المرجعية ؛
- اختبارات ميزات محددة (تتبع إطلاق المترجمات ، وما إلى ذلك) ؛
- الاختبارات الخارجية لتطبيقات سطر الأوامر ؛
- اختبارات التجميع والتركيب والنشر الصحيحة ؛
- اختبارات التوثيق.
في المرحلة الأولى من تطويره ، كان محلل PVS-Studio تطبيقًا للعثور على الأخطاء عند نقل كود C / C ++ إلى نظام أساسي 64 بت. نعم ، وقد تم استدعاؤه في ذلك الوقت بطريقة مختلفة ، "Viva64". يمكن العثور على تاريخ المنتج في مقالة "
كيف بدأ مشروع PVS-Studio منذ 10 سنوات ". بعد الاندماج في Visual Studio 2005 ، اكتسب المحلل واجهة مستخدم رسومية ، بشكل أساسي واجهة IDE Visual Studio نفسها ، والتي ظهرت فيها بعد تثبيت المكون الإضافي قائمة إضافية للوصول إلى وظيفة المحلل. كانت القائمة عنصرين أو ثلاثة عناصر ، لذلك لم يكن هناك شيء للاختبار هناك. ولم يكن Visual Studio في ذلك الوقت يحتوي على أي أدوات مضمنة لاختبار واجهات المستخدم الرسومية.
الاختبارات البصرية والبدائل لواجهة برمجة التطبيقات المرئية
تغير كل شيء مع إصدار Visual Studio 2010 ، الذي قدم نظامًا متكاملًا لإنشاء اختبارات واجهة المستخدم: Visual Studio Coded UI Tests (CUIT). استنادًا إلى نظام اختبار وحدة اختبار Visual Studio Team ، استخدمت CUIT في البداية تقنية Microsoft Active Accessibility (MSAA) للوصول إلى عناصر الواجهة المرئية. في المستقبل ، تم تحسين التقنية وهي في الوقت الحاضر نموذج مطور لأتمتة واجهة المستخدم لاختبار رمز UIA (أتمتة واجهة المستخدم). يسمح لنظام الاختبار بالوصول إلى الحقول المفتوحة (اسم الكائن ، واسم الفئة الداخلية للكائن ، والحالة الحالية للكائن ، ومكانه في الهيكل الهرمي للواجهة ، وما إلى ذلك) لعناصر COM و .NET UI ، ويسمح لك النظام بمحاكاة التأثيرات على هذه العناصر من خلال أجهزة الإدخال القياسية (الماوس ولوحة المفاتيح). مباشرة خارج الصندوق ، يتم دعم أوضاع تسجيل إجراءات المستخدم عند التفاعل مع الواجهة (على غرار وحدات الماكرو Visual Studio) ، وأتمتة بناء "خريطة واجهة" (خصائص عناصر التحكم ومعلمات البحث والوصول إليها) ، إلى جانب الإنشاء التلقائي لرمز التحكم. في المستقبل ، من السهل تعديل جميع المعلومات المتراكمة والحفاظ عليها حتى الآن ، بالإضافة إلى تخصيص تسلسلات الاختبار كما تشاء ، مع الحد الأدنى من مهارات البرمجة.
علاوة على ذلك ، كما قلت سابقًا ، الآن عند إنشاء اختبارات واجهة مستخدم ذكية معقدة ، يمكنك الاستغناء عن أي مهارات برمجة على الإطلاق ، شريطة أن تستخدم أدوات متخصصة مدفوعة. حسنًا ، إذا لم تكن هناك رغبة أو قدرة على استخدام بيئات اختبار الملكية ، فهناك الكثير من المنتجات والأطر المجانية. نظام Visual Studio Coded UI Tests هو حل وسيط يسمح ليس فقط بأتمتة عملية إنشاء اختبارات واجهة المستخدم قدر الإمكان. بمساعدتها ، من السهل إنشاء تسلسل اختبار عشوائي في لغات البرمجة C # أو VB.
كل هذا يمكن أن يقلل بشكل كبير من تكلفة إنشاء والحفاظ على أهمية اختبارات واجهة المستخدم الرسومية. الإطار المستخدم سهل الفهم ويمكن بشكل عام تمثيله في شكل رسم بياني.
من بين العناصر الرئيسية ، يجب ملاحظة ما يسمى "محولات الواجهة" ، والتي هي في أدنى مستوى من التجريد. تتفاعل هذه الطبقة مع العناصر المحدودة لواجهة المستخدم ، ويمكن توسيع قدراتها باستخدام محولات إضافية. أعلاه هي طبقة تخفي تقنيات الوصول إلى واجهة المستخدم الرسومية عن بقية الكود ، بما في ذلك واجهات الوصول إلى البرنامج ورمز تطبيق الاختبار الفعلي ، والذي يتضمن جميع العناصر اللازمة لاختبار الأتمتة. التكنولوجيا قابلة للتوسعة ، يمكن استكمال كل مستوى بالعناصر الضرورية في إطار الإطار.
تتضمن الميزات الرئيسية لـ CUIT من Microsoft:
- الاختبار الوظيفي لواجهات المستخدم. يتم دعم التطبيقات الكلاسيكية المستندة إلى Windows وتطبيقات الويب والخدمات ، WPF
- توليد الكود (بما في ذلك التلقائي) في VB / C #
- القدرة على الاندماج في عملية التجميع
- تطلق المحلية أو عن بعد ، وجمع التقارير
- توافر تسجيل وتكرار تسلسل الاختبار
- التمدد الجيد
على الرغم من عدد من الصعوبات المرتبطة بـ CUIT ، يُفضل استخدام تقنية الاختبار هذه لعدد من الأسباب:
- التفاعل الفعال للمطورين والمختبرين ضمن أداة واحدة ولغة برمجة
- ميزات إضافية للعمل مع "بطاقة الواجهة" ، مما يسمح بتحديد عناصر التحكم "بسرعة" ، ومزامنة العناصر وإكمال تسلسل الاختبار
- الضبط الدقيق لآلية التشغيل ، والتي تسمح جنبًا إلى جنب مع الإعدادات الأساسية ، مثل التأخير بين العمليات ، ومهلة البحث عن عنصر ، وما إلى ذلك ، لاستخدام آليات متخصصة في التعليمات البرمجية. على سبيل المثال ، تأمين مؤشر الترابط الحالي حتى يتم تنشيط عنصر التحكم (تصور) باستخدام أساليب WaitForControlExist أو WaitForReady مع تعداد WaitForReadyLevel ، إلخ.
- القدرة على برمجة اختبارات معقدة بشكل غير محدود
لن أخوض في الجوانب النظرية لتقنية اختبارات واجهة المستخدم المرمزة في Visual Studio ، حيث يتم تفصيلها جميعًا في الوثائق ذات الصلة. هناك يمكنك العثور على تعليمات تفصيلية خطوة بخطوة لإنشاء أبسط اختبار لواجهة المستخدم بناءً على هذا النظام. ونعم ، النظام ليس مجانيًا ، ستحتاج إلى Visual Studio Enterprise للعمل معه.
التكنولوجيا الموصوفة ليست الوحيدة في السوق. هناك العديد من الحلول الأخرى. يمكن تقسيم جميع أنظمة اختبار واجهة المستخدم البديلة إلى مدفوعة ومجانية. علاوة على ذلك ، لن يعتمد اختيار نظام معين دائمًا على سعره. على سبيل المثال ، يمكن أن تكون القدرة على إنشاء اختبارات دون الحاجة إلى البرمجة عاملاً مهمًا ، ولكن في الوقت نفسه ، قد لا تكون الاختبارات مرنة بما فيه الكفاية. من المهم أيضًا دعم بيئة الاختبار الضرورية - أنظمة التشغيل والتطبيقات. أخيرًا ، يمكن أن تؤثر الميزات المحددة البحتة للتطبيق وواجهة البرنامج على الاختيار. فيما يلي بعض الأنظمة والتقنيات الشائعة لاختبار واجهات المستخدم الرسومية.
مدفوع :
TestComplete (SmartBear) ،
الاختبار الوظيفي الموحد (Micro Focus) ، Squish (froglogic) ،
أدوات الاختبار الآلي (Ranorex) ،
وظيفة الباذنجان (الباذنجان) ، إلخ.
مجاني :
AutoIt (windows) ،
Selenium (الويب) ،
Katalon Studio (الويب ، الجوال) ،
Sahi (الويب) ،
Robot Framework (الويب) ،
LDTP (مشروع اختبار سطح المكتب Linux) ، أطر مفتوحة المصدر:
TestStack.White +
UIAutomationVerify ،. مكتبة أتمتة NET Windows ، إلخ.
بالطبع هذه القائمة ليست كاملة. ومع ذلك ، من الواضح أن الأنظمة المجانية عادة ما تركز على نظام تشغيل معين أو تقنية اختبار. القاعدة العامة هي أنه من بين الأنظمة المدفوعة ، ستجد شيئًا أسرع بكثير مناسبًا خصيصًا لاحتياجاتك ، وسيكون تطوير وصيانة الاختبارات أسهل ، وقائمة بيئات الاختبار المدعومة شاملة.
في حالتنا ، لم تكن هناك مشكلة في الاختيار: مع إصدار Visual Studio 2010 مع إضافة اختبارات واجهة المستخدم المشفرة ، أصبح من الممكن بسهولة إضافة مجموعة من الاختبارات الوظيفية إلى بيئة الاختبار لدينا لاختبار واجهة المستخدم الخاصة بالمكون الإضافي PVS-Studio لبرنامج Visual Studio.
اختبارات PVS-Studio UI
لذلك ، تم استخدام اختبارات واجهة المستخدم الرسومية في شركتنا لأكثر من 6 سنوات. استندت مجموعة اختبارات واجهة المستخدم الأولية لـ Visual Studio 2010 على تقنية MSAA (Microsoft Active Accessibility) الوحيدة المتاحة في ذلك الوقت. مع إصدار Visual Studio 2012 ، تطورت تقنية MSAA بشكل كبير وتسمى الآن UIA (أتمتة واجهة المستخدم). تقرر الاستمرار في استخدام UIA ، وترك الاختبارات المستندة إلى MSAA لاختبار المكون الإضافي لـ Visual Studio 2010 (نحن ندعم ونختبر المكونات الإضافية لجميع إصدارات Visual Studio ، بدءًا من Visual Studio 2010).
نتيجة لذلك ، قمنا بتشكيل "فرعين" لاختبارات واجهة المستخدم. علاوة على ذلك ، في المشروع التجريبي ، استخدم كلا الفرعين خريطة واجهة مشتركة ورمز مشترك. في الكود ، بدا الأمر مثل هذا (طريقة لإعادة تعيين إعدادات Visual Studio إلى المعيار قبل تشغيل الاختبار):
public void ResetVSSettings(TestingMode mode) { .... #region MSAA Mode if (mode == TestingMode.MSAA) { .... return; } #endregion
عند إجراء تغييرات على واجهة المكون الإضافي ، كان من الضروري إجراء تغييرات على فرعي اختبارات واجهة المستخدم ، وإضافة وظيفة جديدة جعلت من الضروري تكرار عنصر الواجهة في الخريطة: أي إنشاء عنصرين مختلفين لكل من تقنيات MSAA و UIA. كل هذا يتطلب الكثير من الجهد ليس فقط لإنشاء الاختبارات أو تعديلها ، ولكن أيضًا للحفاظ على بيئة الاختبار في حالة مستقرة. سوف أسهب في الحديث عن هذا الجانب بمزيد من التفصيل.
وفقًا لملاحظاتي ، يعد استقرار بيئة الاختبار عند اختبار واجهة المستخدم الرسومية مشكلة كبيرة. ويرجع ذلك بشكل رئيسي إلى الاعتماد القوي لمثل هذا الاختبار على العديد من العوامل الخارجية. في الواقع ، يتم محاكاة إجراءات المستخدم: الضغط على المفاتيح ، وتحريك مؤشر الماوس ، ونقرات الماوس ، وما إلى ذلك. هناك العديد من الأشياء التي يمكن أن "تسوء". على سبيل المثال ، إذا تفاعل شخص ما أثناء الاختبار مع لوحة مفاتيح متصلة بخادم الاختبار. أيضًا ، بشكل غير متوقع ، قد لا تكون دقة الشاشة كافية لعرض أي عنصر تحكم ، ولن يتم العثور عليها بواسطة بيئة الاختبار.
الانتظار:
الواقع:
عنصر مخطط واجهة تم ضبطه بإهمال (ولم يتم العثور عليه لاحقًا) هو عمليا قائد السلوك المشكل. على سبيل المثال ، عند إنشاء عنصر تحكم جديد ، يستخدم معالج خرائط واجهة Visual Coded UI Tests معايير البحث الافتراضية لـ Equals. وهذا يعني أن المطابقة التامة لأسماء الخصائص مع القيم المحددة مطلوبة. يعمل هذا عادةً ، ولكن في بعض الأحيان يمكن تحسين استقرار تنفيذ الاختبار بشكل ملحوظ باستخدام معايير البحث الأقل صرامة "يحتوي" بدلاً من "يساوي". هذا مجرد مثال واحد على "التعديل" الذي قد تواجهه عند العمل على اختبارات واجهة المستخدم.
أخيرًا ، قد تتكون بعض الاختبارات الخاصة بك من تنفيذ إجراء وانتظار نتيجة أخرى ، والتي ، على سبيل المثال ، ترتبط بعرض نافذة. في هذه الحالة ، إلى مشكلة البحث عن عنصر ، ستتم إضافة أسئلة تحديد مهلة التشغيل حتى تظهر النافذة ثم مزامنة العمل. يمكن حل بعض هذه المشكلات من خلال طرق الإطار القياسية (
WaitForControlExist ، وما إلى ذلك) ، بينما بالنسبة للآخرين سيكون من الضروري اختراع خوارزميات بارعة.
واجهنا مشكلة مماثلة أثناء العمل على أحد اختبارات البرنامج الإضافي لدينا. في هذا الاختبار ، يتم فتح بيئة Visual Studio فارغة أولاً ، ثم يتم تحميل حل اختبار معين هناك ، والذي يتم اختباره بالكامل باستخدام PVS-Studio (القائمة "PVS-Studio" -> "Check" -> "Solution"). كانت المشكلة تحديد متى سيتم الانتهاء من التحقق. وفقًا لعدد من الشروط ، قد لا يستغرق الشيك نفس الوقت دائمًا ، لذلك لا تعمل المهلات البسيطة هنا. أيضًا ، لا يمكنك استخدام الآليات القياسية لتعليق تدفق الاختبار وانتظار ظهور (أو إخفاء) أي عنصر تحكم ، حيث لا يوجد شيء يمكن إرفاقه. أثناء الفحص ، تظهر نافذة بحالة العمل ، ولكن يمكن إخفاء هذه النافذة ، وسيستمر الفحص. على سبيل المثال لا يمكن توجيه هذه النافذة (بالإضافة إلى ذلك ، تحتوي على الإعداد "لا تغلق بعد اكتمال التحليل"). وأردت أن أجعل الخوارزمية أكثر عمومية من أجل استخدامها في الاختبارات المختلفة المتعلقة بفحص المشاريع وانتظار اكتمال هذه العملية. تم العثور على حل. بعد بدء الاختبار وحتى اكتماله ، يكون عنصر القائمة "PVS-Studio" -> "تحقق" -> "الحل" غير نشط. كان علينا فقط التحقق من الخاصية "ممكّنة" لعنصر القائمة هذا في فترة زمنية معينة (من خلال كائن خريطة الواجهة) ، وإذا تبين أن العنصر قد أصبح نشطًا ، ففكر في أن عملية التحقق من القرار قد اكتملت.
وبالتالي ، في حالة اختبار واجهة المستخدم ، لا يكفي إنشاء اختبارات ببساطة. يلزم ضبط دقيق ودقيق في كل حالة. من الضروري فهم ومزامنة تسلسل الإجراءات المنفذة بالكامل. على سبيل المثال ، لن يتم العثور على عنصر قائمة السياق حتى يتم عرض هذه القائمة على الشاشة ، إلخ. مطلوب إعداد دقيق لبيئة الاختبار. في هذه الحالة ، يمكنك الاعتماد على التشغيل المستقر للاختبارات والنتائج المناسبة.
اسمحوا لي أن أذكركم بأن نظام اختبارات واجهة المستخدم في شركتنا يتطور منذ عام 2010. خلال هذا الوقت ، تم إنشاء العديد من تسلسلات الاختبار وكتابة الكثير من التعليمات البرمجية المساعدة. تمت إضافة اختبارات التطبيقات المستقلة إلى اختبارات المكونات الإضافية بمرور الوقت. عند هذه النقطة ، فقد فرع اختبار المكونات الإضافية القديم لـ Visual Studio 2010 أهميته وتم التخلي عنه ، ولكن كان من المستحيل ببساطة قطع هذا الرمز "المعطل" من المشروع. أولاً ، كما أوضحت سابقًا ، تم دمج الرمز تمامًا في طرق الاختبار. وثانيًا ، ينتمي أكثر من نصف عناصر بطاقة الواجهة الحالية إلى تقنية MSAA القديمة ، ولكن تم إعادة استخدامها (بدلاً من التكرار) في العديد من الاختبارات الجديدة إلى جانب عناصر UIA (هذا ممكن بسبب استمرارية التكنولوجيا). في الوقت نفسه ، تم ربط كتلة كل من التعليمات البرمجية التي تم إنشاؤها تلقائيًا ومحتويات طرق الاختبار بالعناصر "القديمة".
بحلول خريف عام 2017 ، كانت هناك حاجة لتحسين نظام اختبارات واجهة المستخدم. بشكل عام ، كانت الاختبارات تعمل بشكل جيد ، ولكن من وقت لآخر "تعطل" اختبار لأسباب غير معروفة. بتعبير أدق ، كان السبب عادة هو العثور على عنصر تحكم. في كل حالة ، كان علي أن أذهب عبر شجرة خريطة الواجهة إلى عنصر معين والتحقق من معايير البحث والإعدادات الأخرى. في بعض الأحيان ساعدت إعادة تعيين برنامج لهذه الإعدادات قبل تشغيل الاختبار. بالنظر إلى خريطة الواجهة التي نمت (وفي كثير من النواحي ، من نواح عديدة) بواسطة بطاقة الواجهة ، بالإضافة إلى وجود رمز "ميت" ، تتطلب هذه العملية جهدًا كبيرًا.
لبعض الوقت ، كانت المهمة "تنتظر بطلها" ، حتى وصلتني أخيرًا.
لن أتحمل وصفًا للفروق الدقيقة. لا يسعني إلا أن أقول إن العمل لم يكن صعبًا ، ولكنه يتطلب الكثير من المثابرة والاهتمام. استغرق كل شيء عن كل شيء حوالي أسبوعين. قضيت نصف هذا الوقت في إعادة بناء الكود وبطاقات الواجهة. في الوقت المتبقي ، كان منخرطًا في تثبيت تنفيذ الاختبار ، الذي تم اختصاره بشكل أساسي لتحسين معايير البحث للعناصر المرئية (تحرير خريطة الواجهة) ، بالإضافة إلى بعض التحسين للشفرة.
ونتيجة لذلك ، تمكنا من تقليل حجم الكود لطرق الاختبار بنحو 30٪ ، وانخفض عدد عناصر التحكم في شجرة خريطة الواجهة إلى النصف. ولكن الأهم من ذلك ، بدأت اختبارات واجهة المستخدم في إظهار أداء أكثر استقرارًا وتتطلب القليل من الاهتمام. وبدأ السقوط في الظهور في كثير من الأحيان لأسباب لإجراء تغييرات على وظيفة المحلل أو عند الكشف عن التناقضات (الأخطاء). في الواقع ، لهذه الأغراض ، نحتاج إلى نظام اختبارات واجهة المستخدم.
وهكذا ، في الوقت الحاضر ، يتميز نظام الاختبارات التلقائية لواجهة PVS-Studio بالخصائص الأساسية التالية:
- اختبار واجهة المستخدم المرمزة من Visual Studio
- 45 سيناريو
- 4095 سطرًا من طرق الاختبار
- 19،889 سطرًا من التعليمات البرمجية التي تم إنشاؤها تلقائيًا (باستثناء حجم ملف xml لتخزين إعدادات خريطة واجهة المستخدم)
- ساعة واحدة و 34 دقيقة من التنفيذ (متوسط القيمة وفقًا لنتائج آخر 30 عملية بداية)
- العمل على خادم مخصص (تشغيل الأداة المساعدة MSTest.exe)
- مراقبة الأداء وتحليل تقرير الأداء (جينكينز)
الخلاصة
في الختام ، أريد أن أعطي قائمة بمعايير النجاح لاختبارات واجهة المستخدم الرسومية التلقائية ، والتي تستند إلى تحليل تجربتنا مع هذه التكنولوجيا (تنطبق بعض المعايير على تقنيات الاختبار الأخرى ، على سبيل المثال ، اختبارات الوحدة).
أدوات مناسبة . اختر البيئة لإنشاء وتنفيذ CUIT وفقًا لميزات التطبيق الخاص بك ، وكذلك بيئة الاختبار. الحلول المدفوعة ليست منطقية دائمًا ، ولكنها عادة ما تساعد في حل مشكلة بشكل فعال للغاية.
إعداد البنية التحتية عالية الجودة . لا تقم بحفظ عند تطوير بطاقة واجهة. تبسيط عمل الإطار عند البحث عن العناصر من خلال وصف كل خصائصها بعناية ووضع معايير بحث ذكية. انتبه إلى إمكانيات التعديل الإضافي.
التقليل من العمل اليدوي . حيثما أمكن ، تأكد من استخدام وسائل تلقائية لإنشاء التعليمات البرمجية وتسلسل التسجيل. لذلك سوف تسرع بشكل كبير في التطوير وتقليل احتمالية حدوث أخطاء (ليس من السهل دائمًا العثور على سبب تعطل اختبار واجهة المستخدم ، خاصة إذا تم ارتكاب خطأ في التعليمات البرمجية للعمل مع الإطار).
اختبارات ذكية بسيطة ومستقلة . كلما كانت اختباراتك أبسط ، كان ذلك أفضل. حاول إجراء اختبار منفصل لاختبار تحكم معين أو موقف محاكاة. تأكد أيضًا من أن الاختبارات مستقلة عن بعضها البعض. يجب ألا يؤثر سقوط أحد الاختبارات على العملية برمتها.
أسماء ودية . استخدم البادئات في أسماء الاختبارات المماثلة. تتيح لك العديد من البيئات تشغيل الاختبارات عن طريق التصفية حسب الاسم. استخدم أيضًا التجميع الاختباري كلما أمكن ذلك.
وقت التشغيل المعزول . تأكد من تشغيل الاختبارات على خادم مخصص بأقل تأثير خارجي. افصل جميع أجهزة إدخال المستخدم الخارجية ، أو وفر دقة الشاشة اللازمة للتطبيق الخاص بك ، أو استخدم دمية الأجهزة التي تحاكي اتصال الشاشة عالي الدقة. تأكد من عدم تشغيل التطبيقات الأخرى التي تتفاعل ، على سبيل المثال ، مع سطح المكتب ورسائل العرض أثناء الاختبار. من الضروري أيضًا التخطيط لوقت البدء والنظر في المدة القصوى للاختبارات.
تحليل التقارير الصادرة . تقديم نموذج بسيط وواضح للإبلاغ عن التقدم المحرز. استخدم أنظمة التكامل المستمر لإرسال الاختبارات ، وكذلك الحصول على نتائج الاختبار وتحليلها بسرعة.
إذا كنت تريد مشاركة هذه المقالة مع جمهور ناطق باللغة الإنجليزية ، فيرجى استخدام رابط الترجمة: سيرجي خرينوف.
اختبارات واجهة المستخدم المرئية في Visual Studio: النظرية وتجربة مستخدم شركتنا