اختبار واجهة المستخدم الرسومية

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

في ^{[ 1 ]،} استخدم المؤلفون مخطط IPP ^{[ 6 ]} لتوضيح هذه التقنية. يتم أولاً تحليل واجهة المستخدم للنظام لتحديد العمليات الممكنة، والتي تُصبح بدورها عوامل التشغيل المستخدمة في مسألة التخطيط. بعد ذلك، يتم تحديد حالة النظام الأولية، وتحديد حالة الهدف التي يرى المختبِر أنها ستسمح باختبار النظام. يحدد نظام التخطيط مسارًا من الحالة الأولية إلى حالة الهدف، والذي يُصبح خطة الاختبار.

يُوفر استخدام مُخطط لإنشاء حالات الاختبار مزايا مُحددة مُقارنةً بالإنشاء اليدوي. فنظام التخطيط، بطبيعته، يُولد حلولاً لمشاكل التخطيط بطريقة تُفيد المُختبِر بشكل كبير.

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

عند إنشاء مجموعة اختبار يدويًا، يركز المختبِر بشكل أكبر على كيفية اختبار وظيفة معينة (أي  المسار المحدد عبر واجهة المستخدم الرسومية). باستخدام نظام تخطيط، يُعتنى بالمسار، ويمكن للمختبِر التركيز على الوظيفة المراد اختبارها. ومن المزايا الإضافية لذلك أن نظام التخطيط غير مقيد بأي شكل من الأشكال عند إنشاء المسار، وقد يجد في كثير من الأحيان مسارًا لم يتوقعه المختبِر. تُعد هذه المشكلة بالغة الأهمية ويجب معالجتها. ^{[ 7 ]}

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

تكمن الصعوبة في إنشاء مجموعات اختبار تحاكي استخدام النظام من قِبل مستخدم مبتدئ. وقد اقتُرح استخدام الخوارزميات الجينية لحل هذه المشكلة. ^{[ 7 ]} إن مسارات المستخدم المبتدئ في النظام ليست عشوائية. أولًا، سيتعلم المستخدم المبتدئ مع مرور الوقت، ولن يكرر الأخطاء نفسها عادةً، وثانيًا، يتبع المستخدم المبتدئ خطةً ما، وربما يمتلك بعض المعرفة بالمجال أو النظام.

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

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

قدّم كاسيك وجورج نظامًا لإجراء اختبارات واجهة المستخدم الرسومية لنظام X Window، قابلًا للتوسيع ليشمل أي نظام نوافذ. ^{[ 7 ]} يوفر نظام X Window وظائف (عبر XServer وبروتوكوله) لإرسال مدخلات واجهة المستخدم الرسومية ديناميكيًا إلى البرنامج واستقبال مخرجاتها منه دون استخدام واجهة المستخدم الرسومية مباشرةً. على سبيل المثال، يمكن استدعاء XSendEvent() لمحاكاة النقر على قائمة منسدلة، وهكذا. يتيح هذا النظام للباحثين أتمتة إنشاء حالات الاختبار واختبارها لأي تطبيق قيد الاختبار، بحيث يمكن إنشاء مجموعة من حالات اختبار المستخدمين المبتدئين.

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

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

لمعالجة هذه المشكلة وغيرها، قام المختبرون بتحليل النظام الداخلي وجمع بيانات تفاعل واجهة المستخدم الرسومية من نظام النوافذ الأساسي. ^{[ 9 ]} من خلال تسجيل أحداث النوافذ في سجلات، أصبح التفاعل مع النظام الآن بتنسيق منفصل عن مظهر واجهة المستخدم الرسومية. الآن، يتم تسجيل تدفقات الأحداث فقط. هناك حاجة إلى بعض التصفية لتدفقات الأحداث نظرًا لأنها عادةً ما تكون مفصلة للغاية، ومعظم الأحداث غير مرتبطة مباشرةً بالمشكلة. يمكن تبسيط هذا النهج باستخدام بنية MVC ، على سبيل المثال، وجعل العرض (أي واجهة المستخدم الرسومية هنا) بسيطًا قدر الإمكان، بينما يحتوي النموذج ووحدة التحكم على جميع العمليات المنطقية. هناك نهج آخر يتمثل في استخدام تقنية المساعدة المدمجة في  البرنامج ، أو استخدام واجهة HTML ، أو بنية ثلاثية الطبقات تُتيح أيضًا فصل واجهة المستخدم بشكل أفضل عن بقية التطبيق.

هناك طريقة أخرى لإجراء الاختبارات على واجهة المستخدم الرسومية، وهي دمج برنامج تشغيل ضمن واجهة المستخدم الرسومية، بحيث يمكن إرسال الأوامر أو الأحداث إلى البرنامج من برنامج آخر. ^{[ 7 ]} تُعد هذه الطريقة، التي تعتمد على إرسال الأحداث واستقبالها مباشرةً من النظام، مرغوبة للغاية عند الاختبار، إذ يمكن أتمتة اختبار الإدخال والإخراج بالكامل، مما يُلغي أخطاء المستخدم.