בדיקת ממשק המשתמש של האפליקציה

OpenFactory יכול להריץ זרימות עבודה של דפדפן לשימוש חוזר ב-VMs מנוהלים של בודקים שולחניים. האפליקציה עשויה להיפרס על ידי OpenFactory או להתארח בכל מקום בודק VM יכול להגיע.

תרחישים משלבים פעולות סמנטיות כמו פתיחה, לחיצה, הקלדה, מקש, המתן ו טענה עם צילומי מסך, אבחון דפדפן ופסק דין מוקלט. הם כן הטוב ביותר עבור זרימת משתמשים ידועה; השתמש ב-ההליכון האוטונומי עבור גילוי מוגבל.

צור והרץ תרחיש

קבל את VM הבוחן של האפליקציה:

ensure_tester_vm(app="my-app", app_url="https://staging.example.com")

לאחר מכן שמור תרחיש ששלביו משתמשים בתוויות משמעותיות על המסך:

[
  { "action": "open_url", "value": "${APP_URL}" },
  { "action": "type", "target": "email field", "value": "${EMAIL}" },
  { "action": "type", "target": "password field", "value": "${PASSWORD}" },
  { "action": "click", "target": "Sign in" },
  { "action": "assert_text", "expect": "Dashboard" },
  { "action": "assert_no_error" }
]

השתמש ב- create_app_scenario ולאחר מכן הפעל את מזהה התרחיש המוחזר עם run_app_scenario. הריצה הראשונה פותרת אלמנטים דרך OmniParser. מאוחר יותר ריצות יכולות לעשות שימוש חוזר במטמון האלמנטים המוקשה ולפתור מחדש רק שלבים שהשתנו. בדוק אם כל שלב נשמר במטמון או מנותח בעת אבחון תוצאה.

המשמעות של ריצה חולפת

דוח נחשב כאימות רק כאשר:

• מעמדו הוא passed;
• הוא מכוון לסביבה המיועדת ולעדכון;
• הושלמו כל הגנה על הבמה והתחברות לאפליקציה; ו
• הצהרות רצו בתוך המוצר, לא בדף התחברות או הגנה.

תרחיש חולף מדגים רק את הזרימה וההצהרות המוצהרות. זה כן לא לבסס תקינות מלאה של היישום, נגישות, אבטחה, או התנהגות חוצה דפדפנים.

משתנים וסודות

ערכי התייחסות שלבים כ- ${VAR} וזרעי TOTP כ-${totp:VAR}. לא סודי ברירת המחדל עשויה לחיות עם התרחיש. ניתן לאחסן סודות אצל הבעלים מאגר מפתחות מוצפן כאשר התרחיש נוצר; חלפו דרישות ריצה בודדת עד run_app_scenario ממוזגים עבור אותה ריצה ואינם נמשכים.

אל תציב סיסמאות מילוליות, אסימונים או זרעי TOTP בתרחיש של טקסט שלב תיאורים, צילומי מסך או ייצוא בעיות. עבור קודים חד-פעמיים שנשלחו בדוא”ל, ה פעולה email_otp מחייבת שילוב פעיל של Gmail מחובר במפורש עבור בעל התרחיש.

קביעות שימושיות

• assert_text מאמת טקסט גלוי צפוי.
• assert_no_error בודק ביטויי שגיאה מובנים או שסופקו.
• assert_visual משווה גיבוב תפיסתי עם קו בסיס מאוחסן.
• assert_stable דוגמת אזור עבור הבהוב/היעלמות בלתי צפוי.
• assert_progress מאמת שאזור סטרימינג ממשיך להשתנות למשך א תקופה מינימלית.
• network יכול להפריע ולשחזר את רשת ה-VM של הבוחן לצורך בדיקות שחזור.

קביעות חזותיות וזמניות הן היוריסטיות. כוונון ספי נגד יציב בדוק נתונים ובדוק פריימים שנתפסו לפני התייחסות לסחף כאל פגם במוצר.

בדיקה ישירה ומוקלטת

לעבודות חקירה, נהג ב-VM עם desktop_open_url, desktop_screenshot, desktop_click, desktop_type ושולחן עבודה קשור כלים. השתמש ב- start_app_test, record_app_test_step וfinish_app_test כאשר הרצף הידני הזה צריך להפוך לריצה הניתנת לביקורת.

annotate_screenshot יכול להוסיף תיבות מסומנות לראיות. ביאור מסביר מה על סוקר לבדוק; זה בעצמו לא מוכיח שהאלמנט עבד.

הערות תפעוליות

• נעשה שימוש חוזר ב-VMs של בודקים לכל אפליקציה/מארח. קנה קנה מידה של מאגר הבודקים לעבודה מקבילה במקום ליצור כפילויות שרירותיות.
• לבודק ברירת המחדל אין דיסק התמדה נוסף. בקש התמדה בלבד כאשר המדינה חייבת לשרוד אתחול מחדש ולקבל את האתחול הראשון הארוך יותר.
• פסק זמן של לקוח לא בהכרח מבטל את עבודת הקצה האחורי; לבדוק את הריצה לפני ניסיון חוזר.
• שמור דיווחים פרטיים אלא אם כן צילומי המסך והאבחון שלהם היו נבדק לאיתור נתונים רגישים.

קשור

• פריסת אפליקציה
• הולך אפליקציה אוטונומי
• קוים בסיסיים והבדלים של Walker