Share via

שלב הבדיקה

  • מאמר

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

סוגים של בדיקות

בדיקות יחידה

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

בדיקות מקצה לקצה

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

בדיקות קבלת משתמש

בדיקת קבלת משתמש (UAT)‎ מתבצעת על-ידי משתמש היישום במקום היוצר. בדיקה זו נועדה לוודא שמה שנבנה על-ידי היוצרים תואם לדרישות שביקש המשתמש בתחילה.

להלן מספר עצות לקבלת תוצאות טובות מבדיקות UAT:

  • בדוק עם המשתמשים האמיתיים.

  • נסה לבחור משתמשים מגוונים מבחינת רמות מיומנות ה- IT. כך תוכל לקבל מגוון סוגי משוב.

  • אל תיתן למשתמש הוראות; בדוק אם הוא יכול להבין את היישום באופן אינטואיטיבי.

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

  • כאשר המשתמש תקוע במסך, בקש ממנו להסביר מה הייתה הציפייה שלו.

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

  • באופן אידיאלי, בדוק את היישום בסביבה הממשית של המשתמש או במיקום אם היישום משתמש ביכולות לא מקוונות.

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

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

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

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

יצירת מקרי מבחן ותרחישים

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

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

מס' מקרה מבחן תיאור הבדיקה פריטי קלט שיש לבדוק בעזרתם תוצאה צפויה תוצאה
1-1 שלח פרטי הזמנה מטופס מס' הזמנה 16516 ההזמנה נשלחה בהצלחה
1-2 ודא שנוצר PDF ושהוא מצורף לרשומה לא זמין קובץ PDF מצורף לרשומה
1-3 ודא שהודעת דוא"ל נשלחת אל המשתמש test@contoso.com הדוא"ל מתקבל על-ידי הנמען שצוין

כלים שיעזרו לך לבדוק יישומי בד ציור

Power Apps Test Studio (ניסויי)

לצורך בדיקה בתוך יישומי בד ציור, באפשרותך להשתמש בכלי מוכלל בשם Power Apps Test Studio כדי לכתוב, לארגן ולהפוך בדיקות לאוטומטיות עבור יישומי בד ציור. מידע נוסף: Test Studio (ניסויי)

Azure Monitor (ניסויי)

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

כלים שיעזרו לך לבדוק יישומים מונחי דגמים

EasyRepro

EasyRepro הוא הכלי המסופק עבור Dynamics 365 ויישומים מונחי דגמים של Power Apps. הוא לא כולל רק כלי בדיקות, אלא גם כולל יותר מ- 200 מקרי מבחן לדוגמה שיעזרו לך להאיץ את תהליך הבדיקות. לקבלת מידע נוסף, עיין בפרסום בבלוג מסגרת בדיקות אוטומטית של EasyRepro, וקבל גישה אליו דרך מאגר EasyRepro GitHub.

בודק הפתרונות

בודק הפתרונות הוא כלי שבודק אם הפתרון שיצרת תקין. באפשרותך לסקור במהירות בעיות ולראות תיקונים מומלצים. מידע נוסף: ‏‫שימוש בבודק הפתרונות‬ לאימות היישומים מונחי הדגמים שלך ב- Power Apps

השלב הבא: פרסום ושיתוף של היישום