PyUseCase היא תוכנת בדיקות GUI עבור PyGtk.
בדיקות לתחזוקה GUI עם שימוש מקרה מקליט
הקלטת הכוונה ולא את המכניקה
הדרך הטבעית ביותר ליצירת בדיקות באמצעות ממשק משתמש היא פשוט לבצע את הפעולות שברצונך לבצע ויש לי כלי שיכול להקליט אותם ולאחר מכן לשחזר אותם מאוחר יותר. זוהי דרך פשוטה ומהירה ליצירת בדיקות GUI וקיימים כלים רבים שעושים את זה.
זוג רוב הכלים הבדיקות בחוזקה לGUI
הבעיות מתחילות כאשר יש לך כמה בדיקות ושינויי GUI שלך. הקלטה יכולה להיות דרך מצוינת ליצירת בדיקות אבל זה דרך נוראה לשמור על מספרים גדולים שלהם. זה מועדת לטעויות, מתסכלות ומאוד זמן רב ברגע שיש לך כמה בדיקות. הדור הראשון של כלים נרשם עמדות פיקסל ושברה ברגע שאתה שינית את רזולוציית המסך שלך. עסקת הכלים של היום במונחים של מכניקת GUI: למצוא שולחן עם שם מסוים ולחץ בטור השלישי של השורה הרביעית. הם יכולים לשרוד שינויי מסך מחדש הסדרי קטין של GUI, אבל לא הרבה יותר מזה. התסריטים שנרשמו הם צפופים ולא להעביר את מטרת הבדיקה, והם ספר סגור לכל אנשים שאינם טכניים (ולפעמים לכולם חוץ מחברו של הכלי).
הבעיה היא בעצם אחד מהצימוד. הבדיקות וGUI בחוזקה בשילוב זה לזה ולא יכולים להשתנות באופן עצמאי בנוחות של אחד אחרת. נקודה זו עשויה היטב על ידי רוברט ג מרטין בבלוג שלו כאן ומסקנתו היא שבדיקות GUI היא מטבעו שבירה ואתה צריך לעשות קצת כמו של זה כמו שאתה יכול לברוח עם.
זה נראה די תבוסתני אף. יש ערך עצום ביכולת להפגין את מה שהבדיקות שלך לעשות למשתמש של המערכת. אם הבדיקות לעקוף את ממשק המשתמש ולאחר מכן תהליך שדורש כמות נכבדה של מיומנות טכנית והרבה אמון מהחלק מהמשתמשים שלך. ובכל מקרה, מפתחי תוכנה לפתור בעיות צימוד כל הזמן. התשובה היא, כרגיל, להציג רמה אחרת של דרכים עוקפות.
שוברי הצימוד עם מפת UI
אנשי עסקים ומשתמשים באופן כללי לעבוד במקרי שימוש. אלה הם תיאורים ברמה גבוהה של רצף של פעולות בשפה שהם מבינים: כלומר זה של תחום. הרעיון של "Use Case מקליט" לכן כלי שיכול להקליט ולהשמיע רצפים כאלה ובכך ללכוד את כוונתו של המשתמש. אז זה יאפשר הבנה מוגברת, פחות תלות בצורה המדויקת של התאמת GUI וקל יותר של בדיקות קיימות מבלי להזדקק ללחיצה כל הכפתורים שוב.
המנגנון הבסיסי הוא שאנחנו שומרים על מיפוי בין הפעולות שכיום ניתן לבצע עם GUI שלנו וההצהרות בשפת תחום זה. שינויי GUI אז אומר שמיפוי יחיד זה צריך להיות מעודכן, אבל הבדיקות יכולות להישאר ללא שינוי, ממשיכים לתאר את מה שצריך לעשות ברמה הרעיונית. מיפוי זה לובש צורה של קובץ חיצוני בPyUseCase 3.0 והקרוב 3.0 JUseCase, ואילו בגרסות ישנות יותר זה לוקח את הטופס של מכשור בקוד היישום.
בדיקת ההתנהגות באמצעות יומנים וTextTest
אז שימוש במקרה שלנו המקליט יכול להקליט ולהשמיע usecases עבורנו. אבל איך אנחנו יכולים לבדוק כי מה שאנחנו רואים על המסך הוא נכון? הכלים GUI ביותר לעשות זאת על ידי מתן אפשרות לתסריט המבחן להכיל "טענות", שנראים עד כמה יישומון ולבדוק כי חלק הרכוש שלו שווה לערך hardcoded. זה יוצר עוד יותר את תלות בפריסת GUI הנוכחית ולא ניתן "נרשם" בכל דרך טבעית, אבל יש ללתכנת בלאחר מעשה. לא "usecase" באופן טבעי מכיל המידע הזה: אם הוא עשה את זה היה הופך לתסריט בדיקה.
הדיון הזה הוא לא על אתר TextTest לשום דבר. אם אנחנו יכולים רק לקבל את הבקשה שלנו כדי לייצר יומן של מה GUI נראה כמו שאנחנו יכולים לבדוק מה זה עושה על ידי ניטור התוכן של יומן שבאמצעות TextTest. PyUseCase 3.0 עושה את זה בשבילך: הוא מייצר יומן סוג ASCII-אמנות של ההופעה הנוכחית GUI ומפקח עליה שינויים. היישום יכול להשלים אותו עם רישומה כרצונה. עם מקליטי שימוש במקרה אחרים היישום צריך לבנות היומן שלו למטרה זו כיום.
בדיקות סנכרון על ידי מכשור קוד
כמעט כל מאמצי בדיקות GUI הם סובלים מבעיות עם מוודא את התסריט מחכה מספיק זמן לפני שימשיך, כאשר קורה משהו ברקע. הפתרונות נעים בין דרכים מסתוריות לחכות כמה יישומון יש מראה מסוים (עדיין יותר תלות בGUI-מכניקה) לדוחות "שינה" בנדיבות פזורות. שייכשל כאשר המערכת טעונה ולגרום הבדיקות לרוץ הרבה יותר לאט ממה שהם הייתם בדרך אחרת. כל אחד ללא ידע אינטימי של הקוד הוא מוכשר כדי לפתור בעיות כאלה, עדיין עושה זאת היא חלק חיוני של בדיקות כתיבה.
שימוש במקרה הקלטה להציג את הרעיון של "יישום אירוע". זה בעצם כמה מכשור בקוד שמציין לשימוש במקרה המקליט שמשהו קרה שצריכה חיכו, ובכך מאפשר ההקלטה כדי להקליט ושידור חוזר מחכה כמו גם קליקים. אלה מתוארים בפירוט רב יותר כאן.
פקודות מאקרו הקלטה, כמו גם בדיקות
ברמה גבוהה, "usecases" מניפולציות בקלות שימושית לדברים אחרים מאשר בדיקה. הם גם מאוד שימושיים עבור משתמשים במערכת שיכול ליצור פקודות מאקרו לרצפים של פעולות שהם מבצעים בתדירות גבוהה.
אלה ידועים כמו "קיצורי דרך GUI" כאן. שימוש במקרה מקליט בדרך כלל יאפשר יישום לבקש "סרגל כלים" מזה שכולל שליטה על הקלטה ומשחזר אותם שיכולים להיות מוכנסת לתוך GUI היישום כרצוי. חוץ מזה המאפשר למשתמשים ליצור פקודות מאקרו, הם יכולים לשמש גם כדי ליצור הפשטות רמה גבוהות אף יותר ל" שפת המבחן "שתוארה לעיל, בסיוע בודקים בביצוע פעולות חוזרות ונשנות להגיע למסך מסוים לבדיקה. אלה מתוארים בפירוט רב יותר כאן.
ניתן למצוא מידע נוסף בדף הבית של פרויקט
מה חדש בהודעה זו:.
- תמיכה מאוד בסיסית לwxPython הייתה הוסיף.
- יש גם מספר השיפורים ותיקוני באגים לPyGtk. יש לציין, gtk.Dialog.run נתמך כעת ללא צורך בשינויי קוד המקור.
- פייתון 2.6 וPyGtk 2.12 או מאוחר יותר כיום נדרשים.
- הממשק מבוסס מכשור המורשה הוסר.
דרישות :
- פייתון
- PyGtk
- TextTest
תגובות לא נמצא