PyUseCase هو واجهة المستخدم الرسومية اختبار البرمجيات لباي جتك.
تستعصي على اختبار واجهة المستخدم الرسومية مع حالة استخدام مسجل
تسجيل القصد بدلا من ميكانيكا
وأكثر الطرق الطبيعية لخلق الاختبارات عبر واجهة المستخدم هو القيام ببساطة الإجراءات التي ترغب في أداء ويكون أداة التي يمكن أن تسجل لهم ومن ثم إعادة إنتاجها في وقت لاحق. هذا هو وسيلة بسيطة وسريعة لخلق التجارب واجهة المستخدم الرسومية وهناك وجود العديد من الأدوات التي لا تفعل ذلك.
معظم الأدوات زوجين الاختبارات بإحكام على واجهة المستخدم الرسومية
المشاكل تبدأ عندما يكون لديك عدد قليل من التجارب والتغييرات واجهة المستخدم الرسومية الخاصة بك. تسجيل قد يكون وسيلة رائعة لخلق تجارب بل انها طريقة رهيبة للحفاظ على أعداد كبيرة منهم. هو، محبط للغاية وتستغرق وقتا طويلا عرضة للخطأ مرة واحدة لديك عدد قليل من الاختبارات. الجيل الأول من الأدوات سجلت مواقف بكسل وكسر في أقرب وقت قمت بتغيير دقة الشاشة. أدوات صفقة اليوم من حيث الميكانيكا واجهة المستخدم الرسومية: العثور على الجدول مع اسم معين وانقر في العمود الثالث من الصف الرابع. يمكنهم البقاء على قيد الحياة التغييرات الشاشة وإعادة ترتيبات بسيطة من واجهة المستخدم الرسومية ولكن ليس أي شيء آخر. النصوص المسجلة كثيفة ولا ينقل الغرض من الاختبار، وهي كتاب مغلق لجميع الناس غير التقنيين (وأحيانا على الجميع باستثناء مؤلف من الأداة).
المشكلة هي في الأساس واحدة من اقتران. تقترن الاختبارات واجهة المستخدم الرسومية بإحكام مع بعضها البعض ولا يمكن أن تختلف بشكل مريح بشكل مستقل عن بعضها البعض. يرصد هذه النقطة بشكل جيد من قبل روبرت مارتن في بلوق هنا واستنتاجه هو أن الاختبار GUI هو هش أصلا ويجب عليك القيام به لأقل من ذلك كما يمكنك أن تفلت من العقاب.
هذا يبدو الانهزامية بدلا بالرغم من ذلك. هناك قيمة كبيرة في أن تكون قادرة على إثبات ما تفعله الاختبارات الخاصة بك لمستخدم النظام. إذا كانت الاختبارات تجاوز واجهة المستخدم ثم تلك العملية تتطلب قدرا كبيرا من المهارة الفنية والكثير من الثقة من جانب المستخدم الخاص بك. وعلى أي حال، ومطوري البرمجيات حل المشاكل اقتران كل وقت. الجواب هو، كالعادة، لتقديم مستوى آخر من المراوغة.
كسر اقتران مع خريطة UI
رجال الأعمال والمستخدمين يعمل عادة في حالات الاستخدام. هذه هي الأوصاف رفيع المستوى من سلسلة من الإجراءات بلغة يفهمونها: أي أن المجال. وبالتالي فإن فكرة "استخدام مسجل القضية" هو الأداة التي يمكن أن تسجل واعادتها مثل هذه النتائج، وبالتالي التقاط نية للمستخدم. هذا وسوف تسمح ثم زيادة التفاهم وتقليل الاعتماد على النموذج المحدد من واجهة المستخدم الرسومية وأسهل تعديل الاختبارات الحالية دون اللجوء إلى الضغط على جميع الأزرار مرة أخرى.
الآلية الأساسية هي أن نحافظ على تعيين بين الإجراءات التي يمكن أن يؤديها حاليا مع شركائنا في واجهة المستخدم الرسومية والبيانات في هذه اللغة المجال. التغييرات GUI ثم يعني أن هذا التعيين واحد يحتاج إلى تحديث، ولكن الاختبارات يمكن أن تبقى على حالها، والاستمرار في وصف ما يجب القيام به على المستوى المفاهيمي. هذا التعيين يأخذ شكل ملف خارجي في PyUseCase 3.0 وشيكة JUseCase 3.0، بينما في الإصدارات القديمة فإنه يأخذ شكل الأجهزة في التعليمات البرمجية للتطبيق.
التحقق من سلوك طريق السجلات وTextTest
لذلك لدينا مسجل استخدام الحالة يمكن تسجيل وإعادة usecases بالنسبة لنا. ولكن كيف يمكننا التأكد من أن ما نراه على الشاشة هو الصحيح؟ معظم الأدوات الرسومية تفعل ذلك عن طريق السماح للنصي اختبار لاحتواء "التأكيدات"، والتي تبدو بعض القطعة والتأكد من أن بعض الممتلكات منه تساوي قيمة ضمنية. وهذا يخلق مزيدا من الاعتماد على تخطيط واجهة المستخدم الرسومية الحالي ولا يمكن "سجلت" بأي شكل من الأشكال الطبيعية، ولكن لابد من المبرمج في بعد وقوعها. لا "usecase" سيتضمن بطبيعة الحال هذه المعلومات: إذا فعلت ذلك سوف تتحول إلى برنامج نصي اختبار.
هذه المناقشة ليست في موقع TextTest من أجل لا شيء. إذا نحن يمكن فقط الحصول على تطبيقنا لإنتاج سجل ما يبدو واجهة المستخدم الرسومية مثل نتمكن من التحقق ما تقوم به من خلال مراقبة محتويات هذا السجل باستخدام TextTest. PyUseCase 3.0 يفعل ذلك بالنسبة لك: فهو يولد نوع سجل ASCII الفن مظهر واجهة المستخدم الرسومية الحالي وتراقب تغييرات عليه. التطبيق يمكن أن تكمل مع تسجيل خاص به كما تشاء. مع غيرها من مسجلات استخدام حالة التطبيق يحتاج إلى بناء سجل خاص بها لهذا الغرض حاليا.
تزامن الاختبارات التي كتبها رمز الأجهزة
وتعاني معظم جهود الفحص واجهة المستخدم الرسومية التي كتبها مشاكل مع التأكد من النصي ينتظر لفترة كافية قبل المتابعة عندما يحدث شيء في الخلفية. وتتراوح الحلول من طرق غامضة إلى الانتظار لبعض القطعة ليكون له مظهر معين (بعد مزيد من الاعتماد على واجهة المستخدم الرسومية الميكانيك) على تصريحات "النوم" متناثرة متحررا حولها. التي تفشل عندما يتم تحميل النظام وتسبب الاختبارات لتشغيل ببطء أكثر بكثير مما لو كانوا على خلاف ذلك. أي شخص من دون معرفة وثيقة من رمز غير مجهز لحل مثل هذه المشاكل، ولكن ذلك هو جزء حيوي من كتابة الاختبارات.
مسجلات استخدام حالة إدخال مفهوم "حدث التطبيق". وهذا هو الأساس بعض الأجهزة في التعليمات البرمجية التي تشير إلى استخدام مسجل الحالة أن شيئا ما قد حدث لا بد من انتظر، مما يسمح للمسجل لتسجيل وإعادة ينتظر كذلك من النقرات. يتم وصف هذه بمزيد من التفصيل هنا.
تسجيل وحدات الماكرو وكذلك الاختبارات
على مستوى عال، "usecases" التلاعب بها بسهولة هي مفيدة لأمور أخرى من الاختبار. كما أنها مفيدة للغاية لمستخدمي النظام الذين يمكن إنشاء وحدات الماكرو الخاصة لتسلسل الإجراءات التي تؤدي في كثير من الأحيان.
هذه هي المعروفة باسم "اختصارات واجهة المستخدم الرسومية" هنا. وهناك مسجل استخدام الحالات عادة ما يسمح تطبيق لطلب "شريط الأدوات" منه الذي يحتوي على عناصر تحكم لتسجيل وتعيد لهم والتي يمكن إدراجها في واجهة المستخدم الرسومية تطبيق كما تريد. إلى جانب السماح للمستخدمين إنشاء وحدات الماكرو، فإنها يمكن أن تستخدم أيضا لإنشاء تجريدات مستوى أعلى ل "اختبار اللغة" هو موضح أعلاه، والمساعدة في اختبار أداء الأعمال المتكررة للوصول إلى شاشة معينة للاختبار. يتم وصف هذه بمزيد من التفصيل هنا.
ويمكن الاطلاع على مزيد من المعلومات على الصفحة الرئيسية لمشروع
ما هو الجديد في هذا الإصدار:.
وأضيف الدعم الأساسي جدا لكسبيثون.
هناك أيضا عدد من التحسينات وبوجفيكسيس لباي جتك. والجدير بالذكر أن يدعم gtk.Dialog.run الآن دون الحاجة إلى تغييرات شفرة المصدر.
بيثون 2.6 و باي جتك 2.12 أو في وقت لاحق والآن المطلوبة.
تمت إزالة واجهة مقرها الأجهزة قديمة.
المتطلبات:
بيثون
باي جتك
TextTest
لم يتم العثور على التعليقات