none
טיפים לכתיבת אוטומציה לאפליקציה web בשימוש ב coded ui RRS feed

  • שאלה

  • הי

    אני מקליטה פעולות ואח"כ מוסיפה assert , כדי לבדוק שבאמת הגעתי למסך הנכון

    כמו כן כותבת הודעות האם כל פעולה הצליחה.

    איפה בדיוק יש צורך לשלב קוד יותר מזה?

    האם יש למישהו לינק בו אני יכולה ללמוד יותר ?

    תודה רבה על העזרה

    יום שני 06 אוגוסט 2012 08:43

תשובות

  • שלום,

    השאלה המרכזית שעליך לשאול את עצמך: האם הקוד המג'ונרט אוטומטית של Coded UI Test Builder עונה על הדרישות שלך?

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

    1. במקרה של אפליקציה שהUI שלה לא יציב - נתון לשינויים מינוריים. במקרה כזה יש להבטיח שהפקדים המשמשים את האוטומציה ישמרו במערכת בצורה שלא תיפגע בעקבות השינויים, כלומר: שה Search properties שהוקלטו על ידי המערכת לא משתנים ונשארים יחודיים מספיק על מנת לאפשר למערכת לזהות את הפקדים הנכונים. ויותר מזה, היררכית האובייקטים שנשמרת על ידי המערכת עלולה להשתנות. במקרה הראשון, בענין ה Search properties ניתן לטפל בדבר בהתערבות מינימאלית דרך ה UIMap.xml (הרכיב העליון של הUIMap). כדאי מאוד להתקין לצורך כך את VisualStudio Service Pack 2 שפותח את המסמך בצורת GUI ידידותי למשתמש ומאפשר לערוך כל פקד בפני עצמו, להוסיף או לשנות Search properties . במקרה השני לצערי הGUI עדיין לא תומך ואי אפשר לשנות היררכיה, להוסיף, להסיר, או לאחד פקדים. לכן במקרה הזה, במקום להסתבך עם xml מורכב, עדיף לדעתי להתערב בקוד המג'ונרט (כמובן רק אחרי שהעברנו מהחלק המג'ונרט UIMap.Designer.cs אותו לחלק שלא נדרס ב UIMap.cs).

    2. גנריות. בפרוייקטים גדולים יש סבירות גבוהה לחזרה על פעולות זהות במסכים שונים בעלי עיצוב בסיסי זהה וכן בעוד אפשרויות רבות של Code reuse. כמובן שהקוד כפי שהו מוקלט לא מתחשב בפרמטרים האילה. במקרים כאילה יש צורך לשלוט על כל תהליך האוטומציה ולכן התפקיד של ה Coded UI Test Builder מצטמצם לזיהוי הפקדים הבסיסי ואילו כל שאר הכתיבה נשארת בידי המתכנתים.

    3. פרמטרים ו Data Binding. האפשרות לשלוח פרמטרים לבדיקה מוגבלת מאוד. בחלק מהמקרים המערכת מזהה פוטנציאל לערך משתנה ומכניסה בעצמה אפשרות של SomeTestMethod.Parameters.Keys או משהו בסגנון. אבל בדרך כלל צריך להחדיר את הקוד הזה באופן עצמאי. כמובן שכל הנושא של Data Binding מושפע מהאפשרות לשלוח פרמטרים.

    4. תחזוקה. הקוד כפי שהוא נכתב על ידי המערכת לא כתוב בצורה "נכונה" במונחים של מתכנתים. הוא קשה לקריאה ולא נוח לתחזוקה.

    5. קונפיגורציות. יש הרבה מצבים בהם צריך לשלב קונפיגורציות של Playback.Settings או שרוצים להוסיף תנאים (if, while, wait ext.) במהלך ביצוע של פעולה פשוטה. את זה אי אפשר להקליט.

    6. עוד בעיה נפוצה נוצרת בפקדים מסוימים (בדרך כלל TabPage) שה CodedUITestBuilder לא טורח להוסיף להיררכיה ומשום מה מאוד נחוצים על מנת למצא את הפקדים שתחתיהם (משהו שקשור לVirtualized children). במקרה כזה אין מנוס מהתערבות ידנית.

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

    מקווה שעניתי על השאלה בצורה מלאה

    בהצלחה

    אליצור מאך

    צוות ALM קבוצת סלע


    • נערך על-ידי elizurm יום רביעי 08 אוגוסט 2012 21:53
    • הוצע כתשובה על-ידי elizurm יום ראשון 12 אוגוסט 2012 20:39
    • סומן כתשובה על-ידי Dan MorgensternModerator יום ראשון 23 ספטמבר 2012 08:18
    יום רביעי 08 אוגוסט 2012 19:08

כל התגובות

  • שלום,

    השאלה המרכזית שעליך לשאול את עצמך: האם הקוד המג'ונרט אוטומטית של Coded UI Test Builder עונה על הדרישות שלך?

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

    1. במקרה של אפליקציה שהUI שלה לא יציב - נתון לשינויים מינוריים. במקרה כזה יש להבטיח שהפקדים המשמשים את האוטומציה ישמרו במערכת בצורה שלא תיפגע בעקבות השינויים, כלומר: שה Search properties שהוקלטו על ידי המערכת לא משתנים ונשארים יחודיים מספיק על מנת לאפשר למערכת לזהות את הפקדים הנכונים. ויותר מזה, היררכית האובייקטים שנשמרת על ידי המערכת עלולה להשתנות. במקרה הראשון, בענין ה Search properties ניתן לטפל בדבר בהתערבות מינימאלית דרך ה UIMap.xml (הרכיב העליון של הUIMap). כדאי מאוד להתקין לצורך כך את VisualStudio Service Pack 2 שפותח את המסמך בצורת GUI ידידותי למשתמש ומאפשר לערוך כל פקד בפני עצמו, להוסיף או לשנות Search properties . במקרה השני לצערי הGUI עדיין לא תומך ואי אפשר לשנות היררכיה, להוסיף, להסיר, או לאחד פקדים. לכן במקרה הזה, במקום להסתבך עם xml מורכב, עדיף לדעתי להתערב בקוד המג'ונרט (כמובן רק אחרי שהעברנו מהחלק המג'ונרט UIMap.Designer.cs אותו לחלק שלא נדרס ב UIMap.cs).

    2. גנריות. בפרוייקטים גדולים יש סבירות גבוהה לחזרה על פעולות זהות במסכים שונים בעלי עיצוב בסיסי זהה וכן בעוד אפשרויות רבות של Code reuse. כמובן שהקוד כפי שהו מוקלט לא מתחשב בפרמטרים האילה. במקרים כאילה יש צורך לשלוט על כל תהליך האוטומציה ולכן התפקיד של ה Coded UI Test Builder מצטמצם לזיהוי הפקדים הבסיסי ואילו כל שאר הכתיבה נשארת בידי המתכנתים.

    3. פרמטרים ו Data Binding. האפשרות לשלוח פרמטרים לבדיקה מוגבלת מאוד. בחלק מהמקרים המערכת מזהה פוטנציאל לערך משתנה ומכניסה בעצמה אפשרות של SomeTestMethod.Parameters.Keys או משהו בסגנון. אבל בדרך כלל צריך להחדיר את הקוד הזה באופן עצמאי. כמובן שכל הנושא של Data Binding מושפע מהאפשרות לשלוח פרמטרים.

    4. תחזוקה. הקוד כפי שהוא נכתב על ידי המערכת לא כתוב בצורה "נכונה" במונחים של מתכנתים. הוא קשה לקריאה ולא נוח לתחזוקה.

    5. קונפיגורציות. יש הרבה מצבים בהם צריך לשלב קונפיגורציות של Playback.Settings או שרוצים להוסיף תנאים (if, while, wait ext.) במהלך ביצוע של פעולה פשוטה. את זה אי אפשר להקליט.

    6. עוד בעיה נפוצה נוצרת בפקדים מסוימים (בדרך כלל TabPage) שה CodedUITestBuilder לא טורח להוסיף להיררכיה ומשום מה מאוד נחוצים על מנת למצא את הפקדים שתחתיהם (משהו שקשור לVirtualized children). במקרה כזה אין מנוס מהתערבות ידנית.

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

    מקווה שעניתי על השאלה בצורה מלאה

    בהצלחה

    אליצור מאך

    צוות ALM קבוצת סלע


    • נערך על-ידי elizurm יום רביעי 08 אוגוסט 2012 21:53
    • הוצע כתשובה על-ידי elizurm יום ראשון 12 אוגוסט 2012 20:39
    • סומן כתשובה על-ידי Dan MorgensternModerator יום ראשון 23 ספטמבר 2012 08:18
    יום רביעי 08 אוגוסט 2012 19:08
  • תודה רבה

    :-)

    יום ראשון 12 אוגוסט 2012 09:04