TestRail - הגדרות אישיות לפרויקט

מבוא

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

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

תוכנית הצדקה (מה ייושם)

  1. דרישות כלליות

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

    2. מקרים צריכים להישאר רלוונטיים זמן רב ככל האפשר

    3. המקרים צריכים לכסות את הפונקציונליות של האפליקציה לנייד בצורה יסודית ככל האפשר, במידה שזה לא סותר את שתי הנקודות הראשונות

  2. מתחלקים ל-TestCase ול-TestScenario

  3. יצירה מהירה של TestRun מסוגים שונים

    1. עשן

    2. לָסֶגֶת

    3. בדיקות השפעה וכו'.

  4. אופטימיזציה של תמיכת תיקים

    1. נטישת צילומי מסך מקודדים "מתים" ומעבר ל"נתונים ניידים"

דרישות

כדי לערוך שדות תצטרך גישת מנהל

בחירת סוג פרויקט

ישנם שלושה סוגי פרויקטים לבחירה:

TestRail - הגדרות אישיות לפרויקט

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

הוספת שדות לצפייה ברשימה של מקרי בדיקה

בואו נוסיף שדה כדי להציג מקרי בדיקה עדיפות:

TestRail - הגדרות אישיות לפרויקט

אתה יכול גם להוסיף שדות אחרים.

הגדרת שדות ותגים של מקרה מבחן

פתח את תפריט ההגדרות:

TestRail - הגדרות אישיות לפרויקט

נצטרך את השדות הבאים:

שדה "סיכום" (כותרת מקרה מבחן)

TestRail - הגדרות אישיות לפרויקט

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

תרחיש בדיקה:

דוגמה: TestScenario - תרחיש בסיסי לשימוש באפליקציה סלולרית

מקרה בדיקה:

דוגמה: MainScreen - סעיף הרשאות - הזן התחברות

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

תג "StartScreen" (המסך שממנו מתחיל TestScenario; כמו כן, מקרי בדיקה רבים יכולים לגעת במסכים סמוכים)

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

צור שדה חדש:

TestRail - הגדרות אישיות לפרויקט

מלא את מרכיבי השדה החדש:

TestRail - הגדרות אישיות לפרויקט

במקרה זה, אנו יוצרים שדה בחירה מרשימת ערכים. הזן את הערכים של שדה זה:

TestRail - הגדרות אישיות לפרויקט

שים לב שערכי המזהה אינם מתחילים באחד ואינם עוקבים. למה זה נעשה? הנקודה היא שאם יש לנו מקרי בדיקה עם המזהה שהוזן רשום,

TestRail - הגדרות אישיות לפרויקט

ואחרי זה נצטרך ליצור מסך שלישי בין שני הקיימים,

TestRail - הגדרות אישיות לפרויקט

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

תג "מסך" (שם המסך שמשפיע על TestCase)

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

דוגמה: home_screen, MapScreen, PayScreen וכו'.

TestRail - הגדרות אישיות לפרויקט

שדה "MovableData" (קישור למסד נתונים פרוקסי עם נתוני בדיקה הניתנים לשינוי)

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

  1. קישורים לפריסות נוכחיות (זה הרבה יותר טוב מאשר לצלם צילומי מסך מתים)

  2. שלבים אופייניים להגיע למסך עם מצב בדיקה

  3. שאילתות SQL

  4. קישורים לנתונים חיצוניים ונתונים אחרים

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

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

עבור גיליון Google אתה יכול להשתמש בשאילתות SQL. דוגמא:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

עבור Excel אתה יכול להגדיר פקודות מאקרו חיפוש מיידי נוחות. (סינון) דוגמה по ссылке.

למעשה, הרעיון אינו חדש ומתואר בספרו של הבוחן הראשון "Testing dot com". (מחבר Savin Roman) אנחנו רק משלבים את השיטות שהציע רומן Savin לתוך TestRail. לשם כך, צור שדה עם קישור לקובץ שנוצר:

TestRail - הגדרות אישיות לפרויקט

מלא את ערך ברירת המחדל של הקישור כך שלכל מקרה בדיקה חדש כבר יש קישור:

TestRail - הגדרות אישיות לפרויקט

אם המיקום של הקובץ החיצוני משתנה (אנו מספקים כל כוח עליון), אז אתה יכול לשנות בנוחות שדה אחד או יותר בבת אחת בכל מקרי הבדיקה:

TestRail - הגדרות אישיות לפרויקטTestRail - הגדרות אישיות לפרויקט

שדה "תיאורים" (תיאור או רעיון של מקרה מבחן, הוראות סטנדרטיות)

מה ייתכן שתצטרך: בשדה טקסט זה נציב תיאור קצר של מקרה הבדיקה והוראות סטנדרטיות.

לדוגמה: כל נתוני הבדיקה (פריסות נוכחיות, שימוש בכלים ונתונים אחרים) ממקרה בדיקה זה מסומנים בקישורים {...} וממוקמים בקובץ MovableData. קישור ל-MovableData בשדה המתאים בחלק העליון.

TestRail - הגדרות אישיות לפרויקט

תג "רכיב" (רכיב אפליקציה לנייד)

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

רכיבים לדוגמה: GooglePay, הזמנה, משתמשים, מפה, הרשאה וכו'.

TestRail - הגדרות אישיות לפרויקט

תג "TAG" (תגים אחרים לסינון)

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

שימושי מאוד עבור: 

  1. קומפילציה מהירה של TestRun עבור משימות טיפוסיות שונות: עשן, רגרסיה וכו'.

  2. האם הבדיקות יהיו אוטומטיות או כבר אוטומטיות?

  3. כל תגיות אחרות

דוגמה: Smoke, Automated, WhiteLabel, ForDelete וכו'.

TestRail - הגדרות אישיות לפרויקטTestRail - הגדרות אישיות לפרויקט

הגדרת סדר התצוגה של שדות במקרה המבחן

יצרנו הרבה שדות חדשים, הגיע הזמן לסדר אותם בסדר נוח:

TestRail - הגדרות אישיות לפרויקט

יצירת TestRun

כעת ניצור ריצת בדיקה חדשה עם מקרים נוכחיים לביצוע בדיקת עשן בשלוש לחיצות:

TestRail - הגדרות אישיות לפרויקט

עצות מועילות אחרות

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

TestRail - הגדרות אישיות לפרויקט

2. קל יותר להעתיק מקרים עם מספר רב של שדות מסוג קבוצה דומה מאשר ליצור חדשים:

TestRail - הגדרות אישיות לפרויקט

3. ניתן לשתף חשבונות. לדוגמה: מנהל אחד, מספר משתמשים.

מסקנה

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

קישורים:

אתר האינטרנט של ספקי TestRail

סֵפֶר: "Testing .COM" (המחבר רומן סאווין)

תודה רבה על תשומת הלב!

מקור: www.habr.com

הוספת תגובה