שילוב יישומי Qt6 ו-Unity באוטומציה של בדיקות

בעולם של ממשקי אדם-מכונה (HMI), שילוב טכנולוגיות מגוונות לחוויית משתמש חלקה מציב אתגרים ייחודיים. הבה נבחן תכנון ובדיקה של יישומים מרובי-טכנולוגיות עם פונקציות נפרדות קריטיות לבטיחות ושאינן קריטיות. באמצעות ניצול כלים ייעודיים כמו Squish for Qt ו-AltTester SDK עבור Unity, אנו מציגים גישה מקיפה לאיחוד אוטומציית בדיקות, המבטיחה פיתוח יעיל והבטחת איכות איתנה. גלו כיצד מתודולוגיות אלו יכולות לייעל את פרויקטי ה-HMI שלכם, להפחית תקורה ולשפר את איכות התוכנה הכוללת.

מבוא ל-HMI לרכב ולהפרדת ממשקים

עיצוב ממשק אדם-מכונה (HMI) כולל יצירת ממשקי משתמש המאפשרים למשתמשים לתקשר ביעילות עם מכונות. ב- בהקשר של תעשיית הרכב, ממשקי HMI הם פתרונות מורכבים במיוחד מכיוון שמשתמשים מקיימים אינטראקציה עם הרכב ברבדים מרובים: נהיגה, שימוש בשירותי בידור, כוונון החימום ועוד.

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

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

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

אתגרים בבדיקות של יישומי HMI מרובי טכנולוגיות

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

שילוב יישומי Qt6 ו-Unity באוטומציה של בדיקות

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

המשימה היא ליצור אוטומציה של בדיקות עבור תצורה כזו. האפליקציות מסופקות בתוך סימולטור וירטואלי – זה יכול להיות QEMU או תמונת Docker. דרישת חובה היא לשלב את אוטומציית הבדיקות למסגרת בדיקות אחת וליצור מקרי בדיקה לבדיקת שתי האפליקציות בבת אחת.

בחירת הכלים הנכונים: Squish for Qt ו-AltTester SDK for Unity

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

לבחירת מסגרת הבדיקות עבור אפליקציית Unity קיימות מספר מגבלות שיש לעמוד בהן:

• האפשרות להתחבר עם Squish,
• מחיר סביר,
• שימוש במצב headless (לצורכי CI).

אחד הכלים שהוערכו באופן ראשוני היה AltTester SDK – מסגרת קוד פתוח המתוחזקת על ידי חברת Alttom. Alttom מספקת גרסה מסחרית של AltTester עם תמיכה מלאה ואפשרויות משופרות.

לצרכים שלנו, ה-AltTester SDK הספיק כדי להתחיל את היישום הראשוני וכיסה את כל הדרישות שלנו.

עיצוב ארכיטקטורת מסגרת בדיקות אחודה

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

הסיבה לכך היא ש-AltTester SDK אינו מסגרת בדיקות פונקציונלית לחלוטין אלא דרייבר, המאפשר להתחבר לאפליקציית Unity מותאמת ולבחון את רכיביה. אין לו אפשרויות דיווח (למעט שיטת צילום המסך), וכדי להריץ בדיקות שנכתבו עבורו, נצטרך להריץ סקריפטים של Python, C# או JAVA או להשתמש במסגרת בדיקות, שתספק את כל הפונקציונליות הקשורה לבדיקות (כמו גישת BDD או דיווח).

להלן תוכלו לראות את הארכיטקטורה הסופית שהחלטנו ליישם.

אפליקציית Unity מתוקננת במהלך תהליך הבנייה עם תוסף AltTester SDK Unity, מריץ הבדיקות Squish, עטיפות Python וכלי עזר שנכתבו כדי לספק את הפונקציונליות הרצויה וקבצים עם מפות אובייקטים עבור שתי האפליקציות.

הראנר מבצע בדיקות על ידי התחברות ליישומי Qt (חיבור מקורי) ו-Unity (דרך AltDriver SDK). הוא מבצע שלבים הכתובים בגישת BDD, אוסף לוגים, צילומי מסך ומוצרי בדיקה אחרים, ולבסוף עוטף הכל בדוח בדיקה.

הפיכת יישומי HMI לניתנים לבדיקה עם Squish ו-AltTester SDK

מסגרת הבדיקות חייבת להתחבר ליישומים הנבדקים כדי לגרום לדברים לקרות.

ניתן לבצע אינסטרומנטציה של Squish בשתי דרכים:

• להתחבר ליישום כאשר הוא עולה,
• הטמעת וו Squish באפליקציה בזמן שהיא נבנית.

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

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

האופן שבו אפליקציית Unity מנוטרת הוא די פשוט: המשתמש צריך לבנות את תוסף AltTester SDK, להוסיף כמה תלויות לפרויקט Unity ולייבא את התוסף לתוכו (תיעוד בנושא ייבוא חבילת AltTester ב-Unity Editor).

כמובן, ייתכן שיידרשו התאמות וכיוונים נוספים, בהתאם למפרט הפרויקט. היינו צריכים לתקן את סקריפט הבנייה של פרויקט Unity כדי שהדברים יעבדו. הנה דוגמה לאינסטרומנטציה בשורת פקודה:

# שלב 1: הגדר את פרויקט Unity עם תלויות. python3 update_for_altester.py # שלב 2: ייבא את תוסף AltTester Unity. ./Unity -quit -batchmode -nographics -disableaudio -importPackage AltTester-1.8.2.unitypackage -projectPath . # שלב 3: בנה את הפרויקט באמצעות שיטת בנייה מותאמת אישית. ./Unity -quit -batchmode -nographics -disableaudio -projectPath . -executeMethod SpyroBuilder.BuildAltTester

יישום מסגרת בדיקות: מפות אובייקטים ועוד

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

מפות אובייקטים

יצרנו מפות אובייקטים עבור שני היישומים לגישה מהירה ופשוטה לאובייקטים.
מפת אובייקטים של Squish יכולה להיווצר באופן אוטומטי באמצעות Squish IDE וכלי בדיקה. האובייקטים הם שמות סמליים, וערכיהם מוגדרים על ידי רשימת פרמטרים, כגון "title", "type" וכו'. זו דוגמה למפת אובייקטים של Squish:

# תצוגת נגן המדיה הראשית media_player_screen_main_view = { "title": "MediaPlayer", "type": "QQuickWindowQmlImpl", "visible": True } # אובייקטי רשימת ההשמעה של נגן המדיה media_player_playlist_view = { "container": media_player_screen_main_view, "type": "ListsScreen", "visible": True } media_player_playlist_text = { "container": media_player_playlist_view, "text": "רשימת השמעה", "type": "Text", "visible": True }

לאחר שהאובייקט מוגדר, Squish יכול להגיע אליו, לבדוק את מאפייניו או לתקשר איתו. הנה דוגמה לשיטת העטיפה לאיתור אובייקטים ב-Squish:

def find_object(obj, timeout=1000, visible_object=True): """מאתר ומחזיר אובייקט. אינו רושם ללוג. ארגומנטים: object_name (str או object): שם האובייקט שיש לאתר timeout (int): פסק זמן לחיפוש במילישניות. ברירת מחדל 1000. visible_object (bool): האם האובייקט גלוי? מגדיר את פונקציית Squish לשימוש. מחזיר: obj: האובייקט שנמצא, או None אם לא נמצא. """ try: if isinstance(obj, str): if visible_object: obj = squish.waitForObject(getattr(names, obj), timeout) else: obj = squish.findObject(getattr(names, obj)) except LookupError as ex: return None except Exception as ex: raise Exception(ex) return obj

ובפנים ה-Squish IDE…

מפות אובייקטים של Unity עם AltTester SDK הן קצת יותר מורכבות. ניתן ליצור אותן באמצעות Unity Editor (הדרך הקלה יותר) או עם AltTester SDK Driver ובדיקה ידנית משורת הפקודה.

AltTester SDK מאפשר זיהוי אובייקטים באמצעים כגון שם, נתיב, טקסט, ID ואחרים. ניתן להשתמש בו בהתאם להגדרת הסצנה או עץ האובייקטים, והוא מעניק גמישות ליישום פונקציות לאיתור אובייקטים. להלן דוגמה למפת האובייקטים שלנו עבור אפליקציית Unity.

charging_toggle = {"by_selector": "NAME", "search_value": "Charging_Toggle"} navigation_toggle = {"by_selector": "NAME", "search_value": "Navigation_Toggle"} vehicle_toggle = {"by_selector": "NAME", "search_value": "Vehicle_Toggle"} engine_economy_button = {"by_selector": "NAME", "search_value": "CarToggleForGroup (1)"} engine_economy_label = {"by_selector": "PATH", "search_value": "//CarToggleForGroup (1)[1]"} engine_balanced_button = {"by_selector": "NAME", "search_value": "CarToggleForGroup (2)"} engine_balanced_label = {"by_selector": "PATH", "search_value": "//CarToggleForGroup (2)[1]"} engine_performance_button = {"by_selector": "NAME", "search_value": "CarToggleForGroup (3)"} engine_performance_label = {"by_selector": "PATH", "search_value": "//CarToggleForGroup (3)[1]"}

הפונקציה לקבלת אובייקטים מהסצנה עשויה להיראות כך:

def get_object(object_name, is_enabled=True, timeout=0): """Finds and returns an object. Does not log. Args: object_name (str): Name of the object to be found. is_enabled (bool): is object active (true by default) Raises: Exception: When exceptions other than 'object not found' are encountered Returns: obj: Found object, or None if not found. """ try: obj_data = getattr(names, object_name) if timeout > 0: return driver.wait_for_object( getattr(alttester.By, obj_data["by_selector"]), obj_data["search_value"], enabled=is_enabled, timeout=timeout, interval=0.2, ) else: return driver.find_object( getattr(alttester.By, obj_data["by_selector"]), obj_data["search_value"], enabled=is_enabled, ) except (alttester.NotFoundException, alttester.WaitTimeOutException) as ex: return None except Exception as ex: logger.info(f"Exception while looking for object: |{object_name}|") raise Exception(ex)

בשורת הפקודה של Python, איתור אובייקטים נראה כך:

ביישום Unity, זהו אובייקט לדוגמה:

כפי שכבר צוין, AltTester SDK מאפשר איתור אובייקטים באמצעות מספר שיטות. בדוגמה זו נעשה שימוש בשיטת By.NAME, אך המשתמש יכול לבחור בין PATH, TEXT, ID ועוד (תיעוד בנושא איתור אובייקטים).

כאשר נמצא אובייקט, הן Squish והן AltTester SDK מאפשרים למשתמש לבדוק את מאפייניו, לקבל את הטקסט של האובייקט, ללחוץ עליו, או לבצע כל פעולה אחרת הנדרשת ליצירת שלב בדיקה.

יכולות API של Squish ו-AltTester SDK

AltTester SDK חושף API כדי לאתר אובייקטים, לתקשר איתם ולבחון את תכונותיהם. כמה תכונות מועילות מאפשרות למשתמשים להעמיק ביישום Unity, כגון קריאה למתודות של רכיבי Unity או אינטראקציה עם מאפייני רכיבים. גם הפונקציות הקשורות לסצנות קיימות, וניתן להשתמש בהן כדי לטעון או לפרוק את הסצנה הרצויה, או להעריך שהסצנה הנוכחית נכונה. שיטה נוספת היא צילום מסך. הפונקציה מצלמת מסך ושומרת אותו כקובץ PNG, שניתן later לצרף לדוחות בדיקות.

Squish API, למעט שיטות הקשורות לבדיקות, מספק את הפונקציונליות הנדרשת לארגון זרימת הבדיקה. לדוגמה, המשתמש יכול לקחת ולעטוף את השיטה test.fail() ולהוסיף דברים אחרים הנדרשים להגדרת הבדיקה. במקרה שלנו, עטפנו את test.fail() כדי לספק פונקציונליות נוספת עם שלב הבדיקה הכושל בעת בדיקת אפליקציית Unity והוספנו את שלב צילום המסך של AltTester SDK:

def screenshot(): """Takes screenshot Args: none Returns: none """ dt = datetime.now() timestamp = dt.strftime("%Y%m%d_%H%M%S") path = Path(f'{os.getcwd()}/screenshots') if not os.path.exists(path): os.makedirs(path) scr_path = Path(f'{path}/screenshot_{timestamp}.png') try: driver.get_png_screenshot(path=scr_path) test.attachFile(str(scr_path), "Alttester screenshot") except: test.xfail("There was a problem while taking the screenshot") def test_fail(fail_message): screenshot() test.fail(fail_message)

טיפול באינטראקציות

שני הכלים מספקים אינטראקציות.

ב-Squish קיימות מספר שיטות, כמו tap או click או אפילו מחלקת Gesture Builder, המאפשרת יצירה של מחוות פשוטות ומורכבות.

AltTester SDK נוקט בגישה דומה, החל משיטות פשוטות של לחיצה או תנועה ועד לאינטראקציות מרובות-נקודות מורכבות. הוא יכול ליצור מגע (BeginTouch(), MoveTouch(), EndTouch()). כך, בשני המקרים, משתמשים יכולים לדמות אינטראקציות ומחוות בקלות ובגמישות.

ההשפעה של אוטומציית בדיקות משולבת על איכות התוכנה

שימוש משולב ב-AltTester SDK וב-Squish אפשר לנו ליצור תרחישי בדיקה שיכלו לבדוק שתי אפליקציות שפותחו בטכנולוגיות שונות. התרחישים יכלו להחליף הקשר בצורה חלקה ולבצע שלבי בדיקה. דוחות הבדיקה מספקים את כל המידע הנדרש במקום אחד, ואין צורך ליצור pipelines נפרדים ב-CI כדי להריץ את כל האוטומציה.

האם אתם מחפשים מומחי HMI?

גלו כיצד אנו יכולים לתמוך במוצר הבא שלכם – עיינו ב הצעת HMI, ואל תהססו ליצור קשר בכל מקרה של שאלות.

שאלות נפוצות

מה מאפשר שילוב Qt6 ו-Unity?

expand_more

שילוב Qt6 ו-Unity מאפשר למפתחים לשלב ממשקי משתמש שנבנו ב-Qt עם סביבות תלת-ממדיות שנוצרו ב-Unity. הדבר מאפשר יישומים מתקדמים יותר, במיוחד בתרחישי סימולציה, HMI או ויזואליזציה.

מדוע להשתמש ב-Qt6 ו-Unity יחד באוטומציה של בדיקות?

expand_more

שימוש ב-Qt6 וב-Unity באוטומציה של בדיקות מאפשר לצוותים לאמת הן את לוגיקת ממשק המשתמש והן אינטראקציות תלת-ממדיות במסגרת תהליך עבודה אחד. הדבר מסייע להבטיח שהתקשורת בין הרכיבים פועלת כראוי across the entire application.

כיצד יישומי Qt6 ו-Unity מתקשרים ביניהם?

expand_more

יישומי Qt6 ו-Unity מתקשרים בדרך כלל דרך ממשקים מוגדרים כגון sockets, APIs או מנגנוני העברת הודעות. הדבר מאפשר להם להחליף נתונים ולסנכרן התנהגות בזמן ריצה ובבדיקות.

מהם האתגרים העיקריים בשילוב Qt6 ו-Unity?

expand_more

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

מתי סוג זה של אינטגרציה שימושי?

expand_more

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