בדיקות לא פונקציונליות מתייחסות לבדיקות תוכנה המבוצעות כדי לבדוק את ההיבטים הלא פונקציונליים של יישום תוכנה.
ישנם המון סוגים שונים של בדיקות לא פונקציונליות, וסוגים מסוימים של בדיקות תוכנה יכולים להיחשב גם לבדיקות פונקציונליות וגם לא פונקציונליות בו זמנית.
בדיקה לא פונקציונלית נחוצה מכיוון שהיא מעריכה קריטריונים חיוניים של משתמש כגון ביצועים ושימושיות ומוודאת אם התוכנה פועלת כמצופה מחוץ לפונקציונליות הבסיסית שלה.
במאמר זה, אנו בוחנים את ההגדרה והמאפיינים של בדיקות לא פונקציונליות לצד סוגי בדיקות לא פונקציונליות, גישות לבדיקות לא פונקציונליות וכלי בדיקה שיכולים לעזור לייעל ולשפר את תהליכי הבדיקה הלא פונקציונלית שלך.
מהי בדיקה לא פונקציונלית?
בדיקה לא פונקציונלית היא כל סוג של בדיקות תוכנה שבהן נבדקים היבטים לא פונקציונליים של בניית התוכנה.
דוגמאות לבדיקות לא פונקציונליות כוללות בדיקות שנועדו להעריך קיבולת, ביצועים, שימושיות, שחזור וניידות.
אימות האיכות והסטטוס של כל אחד מהקריטריונים הלא-פונקציונליים הללו חשוב לא פחות מאימות הפונקציות של תוכנה, אך פרמטרים אלו אינם נבדקים בבדיקות פונקציונליות סטנדרטיות.
בעיקרו של דבר, בדיקה לא פונקציונלית פירושה בדיקת ‘איך’ פונקציות תוכנה פועלות במקום בדיקה ‘אם’ הן פועלות.
1. מתי צריך בדיקה לא פונקציונלית?
בדיקות לא פונקציונליות מתבצעות בשלב בדיקת המערכת של בדיקות תוכנה לאחר ביצוע בדיקות יחידות ובדיקות אינטגרציה .
במהלך בדיקות המערכת, הבודקים יבצעו בדיקות פונקציונליות ולא פונקציונליות, החל מבדיקות פונקציונליות.
לאחר שהבודקים קבעו שהתוכנה פועלת כמצופה, הם מבצעים בדיקות לא פונקציונליות כדי להעריך האם היא עומדת גם בפרמטרים לא פונקציונליים.
בדרך כלל יש צורך לבצע בדיקות פונקציונליות לפני בדיקות שאינן פונקציונליות מכיוון שאי אפשר לבדוק את המהימנות או הביצועים של פונקציות שאינן עובדות כלל. בדיקות לא פונקציונליות הן אחד השלבים האחרונים של בדיקות תוכנה לפני בדיקת קבלת המשתמש ושחרור המוצר הסופי.
2. כשלא צריך בדיקות לא תפקודיות
תמיד חשוב לבדוק היבטים לא פונקציונליים של תוכנה אלא אם כן הם כבר נבדקו ונמצאו מתאימים.
גם אם ביצעת בעבר בדיקות לא פונקציונליות על תוכנה, ייתכן שיהיה צורך לבדוק שוב פרמטרים לא פונקציונליים, לדוגמה, אם נוספו תכונות חדשות לתוכנה או אם בוצעו שינויים בקוד שיכולים להשפיע על הביצועים והאמינות.
המטרות של בדיקות לא פונקציונליות
המטרות של בדיקות לא פונקציונליות הן לבדוק שהמוצר עומד בציפיות המשתמש ולבצע אופטימיזציה של המוצר לפני השחרור.
זה גם יכול לעזור למפתחים ולבודקים להבין את התוכנה טוב יותר ולהשתמש בידע הזה באופטימיזציות עתידיות.
1. בקרת איכות
בדיקות לא פונקציונליות מטרתן לבדוק גורמים המשפיעים על השימושיות, המהימנות, התחזוקה, הניידות והיעילות של המוצר.
בדיקת רכיבים אלו מבטיחה שהמוצר ששוחרר לשוק הוא באיכות גבוהה ועונה על ציפיות המשתמש בכל הנוגע לביצועים, זמני טעינה וקיבולת משתמש.
2. ניהול סיכונים
בדיקות לא פונקציונליות גם מפחיתות את הסיכון והעלות הכרוכים בשחרור מוצר לשוק על ידי מקסום הסיכוי שהצוות ישחרר מוצר משביע רצון.
על ידי בדיקת הפרמטרים הלא פונקציונליים של בניית התוכנה, ניתן להוזיל את העלויות של שחרור המוצר מכיוון שהצורך בפיתוח נוסף ושינויי תוכנה מאוחר יותר מצטמצם.
3. אופטימיזציה
בדיקות לא פונקציונליות עוזרות לבודקים ולמפתחים לייעל את בניית התוכנה ולמטב את הביצועים במהלך התקנה, הגדרה, ביצוע ושימוש.
אתה יכול גם להשתמש בבדיקות לא פונקציונליות כדי לייעל את האופן שבו אתה מנהל ומנטר את בניית התוכנה.
4. איסוף נתונים
בדיקות לא פונקציונליות מאפשרות לבודקים לאסוף ולייצר מדידות ומדדים שניתן להשתמש בהם על ידי צוותי בדיקה למחקר ופיתוח פנימיים.
אתה יכול להשתמש בנתונים שאתה אוסף מבדיקות לא פונקציונליות כדי להבין איך המוצר שלך עובד וכיצד אתה יכול לייעל אותו בצורה יעילה יותר עבור המשתמשים.
5. שיפור הידע
בדיקות לא פונקציונליות משפרות ומעצימות את הידע של צוות הבדיקות לגבי התנהגות המוצר והטכנולוגיות שבהן הוא משתמש.
זה לא רק עוזר לצוותי בדיקה להבין טוב יותר את התוכנה שהם עובדים עליה, אלא שזה גם עשוי לספק ידע שימושי שעוזר לבודקים להבין טוב יותר את הבנייה העתידית.
מי מעורב בבדיקות לא תפקודיות?
בדיקות לא פונקציונליות מבוצעות בדרך כלל על ידי בודקים בסביבת QA, אך לפעמים מפתחים עשויים לבצע בדיקות לא פונקציונליות במהלך הפיתוח.
בדיקות מערכות מבוצעות כמעט תמיד על ידי בודקים, וזהו שלב הבדיקה שבו מתרחשות רוב הבדיקות הלא פונקציונליות.
אם בדיקות לא פונקציונליות נכשלות, הבודקים ישלחו את התוכנה חזרה למפתחים כדי לתקן את השגיאות בביצועים לפני בדיקה חוזרת.
היתרונות של בדיקות לא פונקציונליות
ישנם יתרונות רבים לביצוע בדיקות לא פונקציונליות, ובדיקות לא פונקציונליות הן שלב חיוני בבדיקות המערכת.
ללא בדיקות לא פונקציונליות, צוותי בדיקה לא יוכלו לוודא שהתוכנה אכן עומדת בדרישות הלקוח או שהיא עומדת בדרישות שנקבעו בתוכנית פיתוח התוכנה.
1. שפר את ביצועי התוכנה
בדיקות לא פונקציונליות יכולות לעזור לבודקים ולמפתחים לשפר את הביצועים הכוללים של יישומי תוכנה. בדיקות לא פונקציונליות מזהות אזורים שבהם ביצועי תוכנה לוקים בחסר, למשל מבחינת מהירות טעינה או יכולת עיבוד, ומבקשות צוותי תוכנה לבצע שינויים כדי לתקן את הליקויים הללו.
זה מבטיח שצוותי תוכנה משחררים תוכנה לציבור רק כשהיא מוכנה וכשהביצועים שלה מספיק טובים.
2. שמור על אבטחת התוכנה
בדיקות לא פונקציונליות כוללות בדיקות אבטחה, שהן קריטיות כדי להבטיח שבניית תוכנה מאובטחת ומוגנת מפני איומים והתקפות חיצוניות.
בדיקות אבטחה מאפשרות לבודקים ולמפתחים לבדוק שהתוכנה מגנה כראוי על נתונים סודיים ויש לה אבטחה מספקת כדי להגן מפני התקפות סייבר עכשוויות.
3. הגבר את הידידותיות למשתמש של התוכנה
בדיקות לא פונקציונליות הן הדרך הטובה ביותר להפוך את התוכנה שלך לידידותית יותר למשתמש, במיוחד על ידי ביצוע בדיקות שמישות שמעריכות כמה קל למשתמשים ללמוד כיצד להשתמש ולתפעל את התוכנה שלך.
ידידותיות למשתמש חשובה מאוד מכיוון שהיא קובעת עד כמה המשתמשים מרוצים מהתוכנה שלך ומבטיחה שהמשתמשים מסוגלים לנצל את מלוא היתרונות של כל מה שהתוכנה שלך מציעה.
4. ודא שהתוכנה עונה על צרכי המשתמש
הבטחת התוכנה עונה על צרכי המשתמשים צריכה להיות אחד מהעדיפויות העליונות של כל צוותי פיתוח ובדיקות תוכנה. בנוסף לציפייה שהתוכנה תהיה פונקציונלית, המשתמשים מצפים שהתוכנה תפעל היטב, תפעל בצורה חלקה ושומרת על נתונים סודיים.
בדיקה לא פונקציונלית היא אחת הדרכים היחידות להבטיח שהתוכנה שלך עומדת בדרישות אלו.
האתגרים של בדיקות לא פונקציונליות
ישנם כמה חסרונות לביצוע בדיקות לא פונקציונליות. בעוד שבדיקות לא פונקציונליות חיוניות בשלב בדיקות המערכת של בדיקות תוכנה, תהליך הבדיקה הלא פונקציונלית יכול להציב אתגרים בפני צוותי תוכנה שאין להם משאבים וכלים רבים.
1. חזרה
בדיקות לא פונקציונליות בבדיקות תוכנה חייבות להתבצע בכל פעם שהתוכנה מתעדכנת על ידי מפתחים או בכל פעם שקוד משתנה. המשמעות היא שבדיקות לא פונקציונליות יכולות להיות חוזרות על עצמן מאוד, מה שלא רק לוקח זמן, אלא גם מוציא את בודקי הצמיגים.
בודקים עייפים שמבצעים משימות שחוזרות על עצמן נוטים גם יותר להסיח את דעתם ולעשות טעויות.
2. עלות
מכיוון שבדיקות לא פונקציונליות כל כך חוזרות על עצמן, הן עשויות להיות גם יקרות למדי, במיוחד עבור צוותי בדיקה המסתמכים על בדיקות ידניות שאינן פונקציונליות.
צוותי תוכנה חייבים להקצות זמן ותקציב לבדיקות תכופות שאינן פונקציונליות, ומפתחי תוכנה יצטרכו לשלם תוספת עבור בדיקה נוספת זו.
מה אנחנו בודקים בבדיקות לא פונקציונליות?
ניתן להשתמש בבדיקות לא פונקציונליות לבדיקת פרמטרים רבים ושונים שאינם פונקציונליים, שכל אחד מהם משפיע על איכות ושימושיות המערכת. כל אחד מהפרמטרים הללו נבדק במהלך בדיקת המערכת מול קריטריונים שנקבעו בתוכנית הבדיקה.
1. אבטחה
בדיקות אבטחה הן סוג של בדיקות לא פונקציונליות המודדות עד כמה המערכת מוגנת מפני איומים והתקפות חיצוניות. אלה כוללים הפרות אבטחה מכוונות כמו גם דליפות נתונים והפרות נפוצות אחרות.
בדיקות אבטחה הן שלב חשוב בבדיקות לא פונקציונליות מכיוון שהיא מספקת למשתמשי קצה וללקוחות את הביטחון שהנתונים שלהם מאובטחים.
2. אמינות
בודקים משתמשים בבדיקות לא פונקציונליות כדי להעריך את מהימנות התוכנה ולהבטיח שהתוכנה תוכל לבצע ללא הרף את הפונקציות שצוינו ללא תקלות.
בעוד שבדיקות פונקציונליות מבטיחות שהתוכנה מבצעת את הפונקציות העיקריות שלה, רק בדיקות לא פונקציונליות בודקות בפועל את המהימנות והחזרה של תוצאות אלו.
3. שרידות
שרידות מתארת כיצד מערכת תוכנה מגיבה במקרה של כשל בתפקוד, ובדיקת שרידות מבטיחה שאם אכן מתרחשות שגיאות וכשלים המערכת יכולה לשחזר את עצמה.
בדיקת שרידות עשויה לבדוק אם התוכנה מסוגלת לשמור נתונים כדי למזער אובדן נתונים במקרה של כשל פתאומי, למשל.
4. זמינות
זמינות התוכנה מתייחסת למידת התלות של המשתמש במערכת במהלך פעולתה. זה נקרא גם יציבות, וזה נבדק על ידי בדיקת יציבות.
בדיקות היציבות דומות במידה מסוימת לבדיקות מהימנות מכיוון שהן בודקות אם המערכת יכולה לבצע את הסטנדרטים הצפויים באופן עקבי.
5. שימושיות
בדיקות שמישות הן סוג חשוב נוסף של בדיקות לא פונקציונליות בבדיקות תוכנה. סוג זה של בדיקה מעריך עד כמה המשתמש יכול ללמוד, לתפעל ולהשתמש במערכת התוכנה על ידי ביצוע ההוראות המסופקות על המסך ומדריכים בסיסיים אחרים.
בדיקת שמישות חשובה מכיוון שאם התוכנה אינה שמישה במיוחד, רוב המשתמשים פשוט ינטשו אותה או יבחרו להשתמש במשהו אחר.
6. מדרגיות
בדיקות מדרגיות בודקות באיזו מידה יישום תוכנה יכול להרחיב את יכולת העיבוד שלו כדי לענות על הביקוש הגובר.
לדוגמה, אם התוכנה מיועדת לשימוש על ידי מספר משתמשים ברשת אחת בו-זמנית, איך זה עובד כשעשרה משתמשים נכנסים בו זמנית? האם ספירת משתמשים גבוהה יותר משפיעה באופן משמעותי על הביצועים או זמני הטעינה?
7. יכולת פעולה הדדית
בדיקת יכולת פעולה הדדית היא סוג של בדיקה לא פונקציונלית הבודקת עד כמה מערכת תוכנה מתממשקת עם מערכות תוכנה אחרות.
זה חשוב במיוחד כאשר תוכנה מתוכננת כחלק מחבילת מוצרים שכולם משתלבים זה עם זה.
8. יעילות
יעילות בבדיקות תוכנה מתייחסת למידה שבה מערכת תוכנה יכולה להתמודד עם קיבולת, כמות וזמן תגובה.
לדוגמה, בודקים עשויים להעריך כמה משתמשים יכולים להיכנס למערכת בבת אחת, כמה זמן לוקח לאחזר נתונים ממסד הנתונים, או באיזו מהירות התוכנה יכולה לבצע משימות בסיסיות.
9. גמישות
גמישות מודדת את המידה שבה מערכת תוכנה יכולה לעבוד עם סוגים שונים של חומרה וציוד היקפי.
לדוגמה, כמה RAM דורשת התוכנה או האם היא דורשת כמות מסוימת של CPU. ככל שהדרישות ליישום התוכנה נמוכות יותר, כך התוכנה גמישה יותר.
10. ניידות
בדיקת ניידות משמשת כדי לבדוק באיזו צורה גמישה ניתן להעביר את התוכנה מסביבת החומרה או התוכנה הנוכחית שלה, וכמה קל לעשות זאת.
ניידות חשובה מכיוון שהיא משפיעה על מידת הקלות של משתמשי קצה לנהל תוכנה ולהעביר אותה בין מערכות שונות.
11. שימוש חוזר
בדיקת שימוש חוזר היא סוג של בדיקה לא פונקציונלית הבודקת האם ניתן להמיר חלקים ממערכת התוכנה לשימוש חוזר בתוך אפליקציה אחרת.
בעוד שבדיקות שימוש חוזר אינן משפיעות בדרך כלל על לקוחות ומשתמשי קצה, היא משקפת היטב את מידת היעילות של מפתחים שיוצרים רכיבים שניתן לעשות בהם שימוש חוזר בעתיד.
המאפיינים של בדיקות לא פונקציונליות
הבנה מה הם מבחנים לא פונקציונליים כרוכה בהבנת המאפיינים של מבחנים לא פונקציונליים. מאפיינים אלו מגדירים בדיקות לא פונקציונליות בבדיקות תוכנה.
1. ניתן למדידה
בדיקה לא פונקציונלית היא תמיד כמותית וניתנת למדידה, מה שאומר שהבודקים לא משתמשים בביטויים סובייקטיביים כמו ‘נחמד’ או ‘טוב’, אלא משתמשים במספרים ועובדות כדי לתאר את התפוקות של בדיקות לא פונקציונליות.
לדוגמה, במקום לתאר את זמני הטעינה כ’מהירים’ או ‘איטיים’, בדיקות לא פונקציונליות אמורות להביא למספרים ספציפיים המציגים את מספר הפעמים.
2. ספציפי
בעת ביצוע בדיקות לא פונקציונליות, מטרת הבדיקות צריכה להיות ספציפית למפרטי התכנון של התוכנה.
לדוגמה, אם תוכנית פרויקט התוכנה מתייחסת למספר המשתמשים שאמורים להיות מסוגלים להיכנס בו-זמנית, יש לתעדף זאת כאשר בדיקות לא פונקציונליות.
3. לא ידוע
בעוד שבדיקות לא פונקציונליות יכולות להיות מתוכננות במיוחד כדי למדוד תכונות שנקבעו בתוכניות הפרויקט, במקרים רבים תכונות אלו לא יצוינו מראש.
במקרה זה, בודקים צריכים פשוט לבצע בדיקות לא פונקציונליות כדי להעריך את התוכנה בהתבסס על כל פרמטר, ובהמשך להשוות אותם עם הציפיות.
מחזור החיים של בדיקות לא פונקציונליות
מכיוון שבדיקות לא פונקציונליות אינן מתייחסות לשלב ספציפי במחזור החיים של בדיקות התוכנה אלא פשוט לסוג של בדיקות המתרחשות בדרך כלל בשלב בדיקות המערכת של בדיקות התוכנה, מחזור החיים של בדיקות לא פונקציונליות יכול להשתנות במידה רבה בין פרויקטים.
באופן כללי, הוא עוקב אחר מחזור חיים דומה לסוגים אחרים של בדיקות תוכנה שמתחיל בניתוח דרישות הפרויקט ומסתיים בביצוע בדיקות ומימוש מחזור.
1. ניתוח דרישות תוכנה
השלב הראשון של מחזור החיים של בדיקות לא פונקציונליות הוא ניתוח דרישות התוכנה. צוותי תוכנה עובדים לקראת קריטריונים ספציפיים כאשר הם בונים ובודקים יישומים, וקריטריונים אלה צריכים להכתיב איזה סוג של בדיקות יש לבצע.
2. תכנון מבחן
השלב הבא של מחזור החיים הוא תכנון מבחן. בשלב תכנון הבדיקה, מוביל ה-QA ירכיב תכנית בדיקה מפורטת המפרטת מה ייבדק, מי יבצע את הבדיקה, ובאילו גישות, שיטות וכלים בדיקה ישמשו.
תוכנית הבדיקה צריכה לכלול את כל הפרטים הדרושים שהבודקים צריכים כדי ליצור ולבצע מקרי בדיקה.
3. יצירת מקרה מבחן
יצירת מקרה מבחן הוא השלב הבא של בדיקה לא פונקציונלית. שלב זה כולל פיתוח מקרי בדיקה לא פונקציונליים שהבודקים יבצעו בשלב מאוחר יותר כדי לבדוק את הדרישות הלא פונקציונליות של המערכת.
מקרי מבחן מתארים מה ייבדק, כיצד ייבדק ומהי התוצאה הצפויה של המבחן.
4. בדיקת הגדרת הסביבה
השלב הבא במחזור החיים של הבדיקות הלא-פונקציונליות הוא הגדרת סביבת הבדיקה לפני תחילת הבדיקה.
סביבת הבדיקה היא המקום שבו מתרחשות כל הבדיקות, והיא מהווה בית למשאבים וכלים שבהם תשתמש כדי לבצע בדיקות לא פונקציונליות.
צוות הבדיקות מכין את סביבת הבדיקה שהוגדרה לפני ביצוע הבדיקה.
5. ביצוע בדיקה
ביצוע בדיקה הוא השלב הבא של מחזור החיים של הבדיקות הלא תפקודיות. זה כרוך בביצוע מקרי הבדיקה שנוצרו בעבר כדי לבדוק היבטים שונים של יישומי תוכנה כולל אבטחה, זמני טעינה, קיבולת וניידות.
צוות הבדיקה מבצע כל מקרה לגופו ובודק את התוצאה של כל בדיקה מול התוצאה הצפויה.
6. מחזור חוזר
השלב האחרון של מחזור החיים של הבדיקות הלא-פונקציונליות הוא מילוי מחזור וחזרה. לאחר ביצוע כל מקרי הבדיקה, הבוחנים בודקים אילו בדיקות עברו ואילו בדיקות נכשלו.
בדיקות שנכשלות מצביעות בדרך כלל על ליקוי שיש לתקן על ידי המפתחים. לאחר שהמפתחים תיקנו או ערכו את הקוד, מחזור בדיקת התוכנה חוזר שוב עד שלא נמצאו פגמים.
מנקה קצת בלבול:
בדיקה לא פונקציונלית לעומת בדיקה פונקציונלית
בדיקות פונקציונליות ובדיקות לא פונקציונליות הן שני סוגים שונים אך חשובים לא פחות של בדיקות תוכנה, המשמשות יחדיו כדי להעריך האם יישום תוכנה עומד בדרישות המשתמשים כפי שנקבעו בתקציר הפרויקט.
בעוד ששניהם סוגים הכרחיים של בדיקות המאפשרים לצוותי תוכנה לזהות פגמים בתוך בניית תוכנה, בדיקות פונקציונליות ולא פונקציונליות שונות לחלוטין זו מזו.
1. מה ההבדל בין בדיקה תפקודית ללא תפקודי?
ההבדל בין בדיקה פונקציונלית ללא פונקציונלית הוא במה שהם בודקים. בדיקה פונקציונלית בודקת את פונקציות האפליקציה ובודקת האם הן פועלות כמצופה. בדיקות לא פונקציונליות בודקות היבטים אחרים של האפליקציה המשפיעים על שביעות רצון המשתמש ואיכות האפליקציה.
בדיקות פונקציונליות ולא פונקציונליות מתרחשות בשלבים שונים של בדיקות תוכנה, אך שני סוגי הבדיקות מבוצעים בדרך כלל בשלב בדיקות המערכת.
גם בדיקות פונקציונליות וגם בדיקות לא פונקציונליות יכולות לעזור לנו להבין עד כמה אפליקציה עובדת והאם היא מבצעת את תפקידה כראוי.
לדוגמה, אם אתה בודק אפליקציה לנייד המאפשרת למשתמשים לשמור רשימות מטלות ורשימות קניות, בדיקות פונקציונליות עשויות לבדוק פונקציות כמו יצירת רשימה חדשה, שמירת רשימה וביצוע עריכות ברשימות קיימות.
בדיקות לא פונקציונליות עשויות להעריך עד כמה האפליקציה פועלת במכשירים ניידים שונים, באיזו מהירות רשימות נטענות וכמה ביצועי האפליקציה מושפעים כאשר אפליקציות אחרות פועלות ברקע.
2. מסקנה: בדיקה לא פונקציונלית לעומת בדיקה פונקציונלית
הן בדיקות פונקציונליות והן בדיקות שאינן פונקציונליות הן סוגים חשובים של בדיקות תוכנה שיכולות לעזור לבודקים ולצוותי QA להעריך אם אפליקציה עומדת בדרישות הנוכחיות שלה.
בעוד שבדיקות פונקציונליות בודקות את פונקציות התוכנה, בדיקות לא פונקציונליות בודקות היבטים אחרים שעשויים להשפיע על הביצועים, היעילות והאבטחה.
בדיקות יחידות , בדיקות אינטגרציה ובדיקות API הן כולן צורות של בדיקות פונקציונליות. בכל אחד משלבי בדיקות התוכנה הללו, בודקים מעריכים עד כמה פונקציות ותכונות פועלות בנפרד או ביחד ומזהים באגים ופגמים שמונעים מהפונקציות לפעול כצפוי.
בדיקות אבטחה, בדיקות שמישות, בדיקות ניידות ובדיקות עומס הן כולן צורות של בדיקות לא פונקציונליות המאפשרות לבודקים להעריך עד כמה אפליקציה מבצעת את הפונקציות שלה ותומכת בצרכי המשתמשים.
סוגי בדיקות לא פונקציונליות
יש המון סוגים שונים של בדיקות לא פונקציונליות, שכל אחת מהן בודקת היבט לא פונקציונלי שונה של ביצועים או יעילות של יישום תוכנה.
כל אחד מסוגי הבדיקות הללו יבדוק פרמטרים שונים, וחלק מהבדיקות עשויות לבדוק את אותם פרמטרים בדרכים שונות.
1. מבחני ביצועים
מבחני ביצועים הם סוג של בדיקה לא פונקציונלית הבודקת עד כמה רכיבי תוכנה שונים עובדים. במקום לבדוק את הפונקציונליות שלהם, וזה מה שעושה בדיקות פונקציונליות, מבחני ביצועים עשויים לבדוק זמני תגובה, צווארי בקבוק ונקודות כשל. בדיקות ביצועים עוזרות לבודקים להבטיח שתוכנה איכותית ושהיא מהירה, יציבה ואמינה.
2. מבחני מאמץ
בדיקת מאמץ היא סוג של בדיקות לא פונקציונליות הבודקות את ביצועי התוכנה כאשר היא נתונה בכמויות חריגות של לחץ. זה יכול להיות בדיקה של ביצועי התוכנה כאשר מישהו מנסה להשתמש בהרבה תכונות שונות בו-זמנית, או תוך כדי הפעלת יישומים רבים אחרים בו-זמנית.
בדיקות מאמץ מבקשות לזהות את הגבול שבו התוכנה מפסיקה לפעול כראוי ומה קורה כאשר המערכת נמצאת בלחץ. זה מאפשר לבודקים להבין האם המערכת יכולה לשחזר את עצמה והאם היא מודיעה למשתמשים בהודעות שגיאה מתאימות.
3. בדיקות עומס
בדיקת עומסים היא סוג של בדיקה שמעריכה עד כמה התוכנה מתנהגת הן בתנאים רגילים והן בעת התמודדות עם עומסים כבדים יותר. הוא משמש כדי לקבוע כמה התוכנה יכולה להתמודד בו זמנית מבלי שהביצועים יושפעו לרעה.
ניתן להשתמש בבדיקת עומס כדי לבדוק כיצד יישומים פועלים כאשר משתמשים רבים משתמשים בהם בבת אחת או כאשר משתמשים מנסים להוריד הרבה נתונים בו-זמנית.
בדיקת עומס חשובה אם אתה רוצה לבדוק אם התוכנה שלך ניתנת להרחבה.
4. בדיקות אבטחה
מבחני אבטחה מעריכים יישומי תוכנה ומחפשים נקודות תורפה באבטחת התוכנה. אלה כוללים סיכוני אבטחה פוטנציאליים שעלולים לגרום לאובדן נתונים או הפרות החושפות נתונים סודיים.
בדיקות אבטחה חשובות מכיוון שהן מבטיחות שהמוצר מוגן כראוי מפני פריצה, פרצות מידע ואיומי אבטחה חיצוניים אחרים.
כמה דוגמאות לבדיקות אבטחה שבודקים עשויים לבצע כוללות ביקורת אבטחה, פריצה אתית, בדיקות חדירה, סריקות אבטחה והערכות יציבה.
5. בדיקות שדרוג והתקנה
בדיקת שדרוג והתקנה היא סוג של בדיקות תוכנה שאינן פונקציונליות המוודאות עד כמה התוכנה עובדת במכונות שונות.
מטרת בדיקות מסוג זה היא לוודא שמשתמשים חדשים יכולים להתקין בקלות את התוכנה על המחשבים שלהם ומשתמשים קיימים יכולים לשדרג אותה כאשר ישוחררו שדרוגים חדשים.
שדרוג ובדיקות התקנה חשובות מכיוון שמשתמשי קצה חייבים להיות מסוגלים להתקין בקלות את המוצר שלך בתנאי שהם עובדים עם מכונה שתואמת לו.
6. בדיקות נפח
בדיקת נפח היא סוג של בדיקה שקיימת כדי לוודא מה קורה כאשר כמויות גדולות של נתונים מתווספות למסד הנתונים בבת אחת. זה מזהה אם האפליקציה יכולה להתמודד עם כמויות גדולות של נתונים ומה קורה למערכת אם היא לא יכולה.
בדיקת נפח ידועה גם כבדיקת הצפה, ואתה יכול להשתמש בה כדי להעריך אובדן נתונים והודעות שגיאה המתרחשות בעת הוספת כמויות משמעותיות של נתונים למערכת.
בדיקת נפח היא הדרך היחידה להבטיח שתוכנה תוכל להתמודד עם כמויות הנתונים שהמשתמשים מצפים ממנה.
7. מבחני החלמה
בדיקות שחזור כוללות אילוץ של מערכת התוכנה להיכשל בבדיקת עד כמה המערכת משחזרת את עצמה לאחר קריסה.
בדיקות שחזור יכולות לעזור לבודקים להבין כיצד תוכנה משחזרת נתונים ומונעת אובדן אם החומרה מנותקת במהלך השימוש, אם התוכנה מנותקת מהרשת במהלך העברת נתונים, או אם אתה מפעיל מחדש את המערכת באופן בלתי צפוי.
סוג זה של בדיקות חשוב מכיוון שמערכות ללא פרוטוקולי שחזור נאותים עלולות לסבול מאובדן נתונים חמור כאשר מתרחשות תאונות כמו זו.
מה אתה צריך כדי להתחיל בדיקות לא פונקציונליות
לפני שתתחיל בבדיקות לא פונקציונליות, תצטרך לוודא שהכנת את סביבת הבדיקה ואספת את הכלים והנתונים הדרושים לך.
1. תוכנית בדיקה
לפני שתתחיל בבדיקות לא פונקציונליות, ודא שיש לך תוכנית בדיקה גמורה שנחתמה על ידי האנשים המתאימים.
תוכנית הבדיקה שלך צריכה לכלול את כל הפרטים הרלוונטיים של מה אתה הולך לבדוק וכיצד. זה אמור להסביר מתי אתה הולך להשתמש בבדיקות ידניות ומתי אתה הולך להשתמש בבדיקות אוטומטיות, כמו גם לשרטט את התפקידים והאחריות של כל מי שמעורב בתהליך הבדיקה.
2. מקרי מבחן
לפני שתוכל לבצע בדיקות לא פונקציונליות, תצטרך ליצור מקרי בדיקה. כל מקרה מבחן מתאר דבר ספציפי שאתה הולך לבדוק, מסביר כיצד אתה הולך לבדוק אותו, ומתאר את התוצאה הצפויה של הבדיקה.
לדוגמה, אם אתה מבצע בדיקות עומס, מקרה מבחן לדוגמה עשוי להיות בדיקה כיצד התוכנה מתנהגת כאשר עשרה משתמשים משתמשים באותו מודול בו-זמנית.
3. אימות פונקציונלי
לא ניתן לבצע בדיקות לא פונקציונליות על רכיבי תוכנה אם הם לא פונקציונליים.
לדוגמה, אם ברצונך לבדוק כמה משתמשים התוכנה יכולה להתמודד עם כניסה בו-זמנית, חשוב תחילה לוודא שמשתמשים בודדים באמת יכולים להיכנס לתוכנה.
לפני שתתחיל בבדיקות לא פונקציונליות, ודא שכל הבדיקות הפונקציונליות שלך עברו ושהתוכנה שלך פועלת כפי שאתה מצפה ממנה.
זה בדרך כלל אומר שבדיקות עשן , בדיקות שפיות , בדיקות יחידות, אינטגרציה ובדיקות מערכת פונקציונלית כבר בוצעו.
4. כלי בדיקה
לפני שתתחיל בבדיקות לא פונקציונליות, אסוף את כל כלי הבדיקה שבהם תרצה להשתמש כדי לבצע את הבדיקות שלך.
בין אם אתה משתמש בכלי אוטומציה באופן חלקי להפוך חלק מהבדיקות שלך לאוטומטיות או כלי תיעוד שיעזרו לך לנהל ולאחסן דוחות בדיקה לשימוש מאוחר יותר, וודא שהכלים שבהם אתה רוצה להשתמש זמינים ומוכנים לשימוש, ושכולם בצוות הבדיקות יודעים כיצד להשתמש בכל כלי כראוי.
5. סביבת בדיקה
הגדר את סביבת הבדיקה לפני שתתחיל בבדיקות לא פונקציונליות. ייתכן שכבר יש לך סביבת בדיקה מתאימה, במיוחד אם אתה יכול להשתמש באותה סביבה עבור בדיקות מערכות לא פונקציונליות ובדיקות מערכות פונקציונליות.
סביבת הבדיקה האידיאלית מאפשרת לך לבדוק כל אלמנט שאתה צריך במכשירים הנכונים.
לדוגמה, אם אתה בודק טיפול בנפח במכשירי סמארטפון, עדיף לבדוק זאת במכשיר סמארטפון אמיתי מאשר לנסות ולדמות סביבה ניידת במחשב שולחני.
תהליך הבדיקה הלא תפקודי
בדיקת היבטים לא פונקציונליים של בניית תוכנה היא תהליך רב-שלבי הכולל הכנת סביבת הבדיקה, יצירת מקרי בדיקה, איסוף נתוני בדיקה וביצוע בדיקות לא פונקציונליות.
אפשר לפרק את תהליך הבדיקה לחלקים קטנים כדי להקל על המעקב למתחילים בבדיקות לא פונקציונליות.
1. בדיקות מוכנות לבדיקות לא פונקציונליות
לפני שתוכל להתחיל בבדיקות לא פונקציונליות, חשוב לוודא שאתה מוכן לשלב זה של הבדיקה.
המשמעות עשויה להיות הערכת קריטריוני היציאה לשלב האחרון של הבדיקה כדי לוודא שהתוכנה עברה אותו ולוודא שהתוכנה עברה את כל הבדיקות הפונקציונליות הנדרשות לפני שמתקיימות בדיקות לא פונקציונליות.
צוותים מסוימים עשויים ליצור קריטריוני כניסה לבדיקות לא פונקציונליות, הכוללות את כל התנאים שחייבים להתקיים לפני תחילת בדיקות לא פונקציונליות.
2. צור תוכנית בדיקה
ייתכן שכבר ביצעת את השלב הזה קודם לכן אם אתה מבצע בדיקות לא פונקציונליות כחלק מבדיקות המערכת ועוקב אחר תוכנית בדיקת המערכת שלך. תוכנית בדיקה מתארת את כל הבדיקות שאתה צריך לבצע וכיצד אתה מתכוון לבצע אותן.
ללא תוכנית בדיקה ברורה, קל לאבד את הטווח והמטרות של הבדיקות שאתה מבצע.
3. צור מקרי בדיקה
השלב הבא של בדיקות לא פונקציונליות הוא יצירת מקרי בדיקה שנועדו לבדוק כל פרמטר לא פונקציונלי של התוכנה.
לכל מקרה מבחן צריך להיות מזהה מקרה מבחן, שם מקרה מבחן, תיאור ופרטים של התוצאה הצפויה של המבחן וכן כל קריטריון לעבור או להיכשל שנקבע מראש. זה עוזר לבודקים להבין כיצד לבצע כל בדיקה ואיזה תוצאות לחפש.
4. איסוף נתוני בדיקה
לפני שתוכל לבצע כל מקרה בדיקה, תצטרך לאסוף את נתוני הבדיקה שבהם תשתמש עבור כל מקרה בדיקה.
זה בדרך כלל אומר איסוף קוד ונתונים ממודולים ורכיבים שונים המרכיבים את הפונקציות והאזורים שאתה הולך לבדוק. אם אתה ממקסם את כיסוי הבדיקה, אמור להיות לך הרבה נתוני בדיקה לעבוד איתם.
5. הכינו את סביבת הבדיקה
השלב הבא של בדיקות לא פונקציונליות הוא הכנת סביבת הבדיקה. סביבת הבדיקה היא שרת בדיקה שתשתמש בו כדי לבצע בדיקות תוכנה מסוגים רבים ושונים.
זה מאפשר לך ליצור תנאים זהים שבהם תוכל לבדוק את התוכנה שלך ולהגדיר את התוכנה שלך עם תצורות שונות לבדיקת תצורה, בדיקות אבטחה וסוגים אחרים של בדיקות לא פונקציונליות.
6. בצע בדיקות לא פונקציונליות
לאחר שסביבת הבדיקה מוכנה, הגיע הזמן לבצע בדיקות לא פונקציונליות. אתה יכול להחליט לבצע בדיקות לפי סדר הסוג, למשל להתחיל בבדיקות ביצועים לפני מעבר לבדיקות אבטחה וסוגים אחרים של בדיקות לא פונקציונליות.
בעת ביצוע כל בדיקה, רשום את התוצאות בדוח הבדיקה שלך. אם אתה עושה בדיקות אוטומטיות , לכלי האוטומציה שלך תהיה דרך סטנדרטית לדווח על תוצאות בצורה ברורה וחד משמעית גם כן.
7. דווח על תוצאות הבדיקה
לאחר ביצוע כל מקרה בדיקה, אסוף את תוצאות הבדיקות הלא פונקציונליות שלך לדוח יחיד.
דוח זה צריך להיות ברור לגבי התוצאות של כל מבחן וחד משמעי לגבי האם כל מבחן עבר או נכשל.
עקוב אחר מבנה סטנדרטי עבור דוח הבדיקה שלך כדי לוודא שכל המידע שתצטרך להעביר כלול.
8. תקן ליקויים
לאחר תוצאות הבדיקה, החזירו את התוכנה למפתחים אם הבדיקות נכשלו או אם זיהית באגים שאינם פונקציונליים הדורשים תיקון.
לדוגמה, אם התוכנה לא מטפלת במספר מתאים של משתמשים בו-זמנית או אם הביצועים מואטים מדי כאשר מספר תוכניות פועלות בו-זמנית, סביר להניח שבעיות אלו יצטרכו לתקן בתוך הקוד כדי להבטיח שהמשתמשים שמח עם המוצר.
9. חזור על מחזור הבדיקה
לאחר שהמפתחים תיקנו את כל הפגמים שנמצאו בשלב הבדיקה הראשונית הלא-פונקציונלית, מחזור הבדיקה יכול להתחיל מחדש.
מפתחים יבדקו את השינויים שהם עושים ויעבירו את המבנה החדש לבודקי QA, אשר לאחר מכן יבצעו את חבילת הבדיקות המלאה, החל מבדיקות עשן, בדיקות יחידות, בדיקות אינטגרציה ולבסוף בדיקות מערכת.
מחזור הבדיקה חוזר על עצמו עד שלא מתרחשים באגים או פגמים בשום שלב, ולאחר מכן ה-build יכול להיכנס לשלב הסופי של הבדיקה: בדיקת קבלת המשתמשים .
מקרי בדיקה לבדיקות לא פונקציונליות
מקרי בדיקה הם היבט חשוב בכל בדיקות תוכנה, וכאשר אתה מבצע בדיקות פונקציונליות ולא פונקציונליות, תשתמש במקרי בדיקה כדי להגדיר מה אתה הולך לבדוק וכיצד אתה הולך לבדוק זאת.
ניתן לראות בכל מקרה מבחן כמיני מבחן, ולכל מקרה מבחן יהיו תפוקות ותוצאות מוגדרות משלו.
1. מהם מקרי בדיקה לבדיקה לא פונקציונלית?
מקרה בדיקה הוא קבוצה של פעולות המבוצעות על בניית תוכנה כדי לבדוק אם היא עומדת בתנאים שהוגדרו בתוכנית התוכנה. כל מקרה בדיקה אומר למעשה לבודקים מה לבדוק וכיצד, והוא נועד לבדוק פונקציה ספציפית או תכונה לא פונקציונלית של יישום התוכנה.
מקרי בדיקה לא פונקציונליים עשויים לכלול בדיקה מה קורה כאשר מישהו מנסה לגשת לנתונים מאובטחים בתוך המערכת או בדיקה באיזו מהירות התוכנה נטענת בעת ההפעלה.
2. כיצד לתכנן מקרי בדיקה לא פונקציונליים?
כאשר אתה מעצב מקרי בדיקה לבדיקות לא פונקציונליות, חשוב לעקוב אחר נהלי מקרי בדיקה סטנדרטיים תוך שמירה על המטרות של הבדיקות הלא פונקציונליות שלך.
בצע את השלבים הבאים כדי לכתוב מקרי בדיקה לבדיקות לא פונקציונליות המתארות בבירור מה הבודקים שלך צריכים לעשות כדי לבצע כל בדיקה.
1. הגדר את האזור שאתה רוצה לכסות
עבור כל מקרה בדיקה, שקול באיזה תחום בתוכנה שלך מקרה בדיקה זה הולך לכסות.
לדוגמה, אם אתה כותב מקרי בדיקה לבדיקת התקנה ושדרוג, אתה עשוי לכלול מקרי בדיקה שמעריכים עד כמה קלה האפליקציה להתקין במכשירים שונים וכמה זמן לוקח לשדרג את התוכנה באמצעות תיקון חדש.
2. צור מזהה מקרה בדיקה ייחודי
לכל מקרה בדיקה צריך להיות מזהה מקרה בדיקה ייחודי. זה מקל על מציאת תיאור מקרה הבדיקה והתוצאות מאוחר יותר ומנקה כל בלבול לגבי מקרה המבחן אליו אתה מתייחס אם לשני מקרי בדיקה יש שמות או תיאורים דומים.
3. שם ותאר כל מבחן
בעוד שמזהה מקרה הבדיקה מזהה את הבדיקה, תרצה גם לספק שם ותיאור עבור כל מקרה בדיקה שאתה כותב.
זה צריך להיות שם פשוט שמסכם את מה שאתה בודק, בעוד שהתיאור הוא משפט בודד שמרחיב על כך בפירוט מעט יותר.
התיאור צריך להיות ברור מספיק כדי שהבודקים ידעו מה לבדוק ואיך לבדוק זאת, כמו גם כל תנאי מסוים שצריך לעמוד בהם בבדיקה.
4. ציין את התוצאה הצפויה
עבור כל מקרה בדיקה, תאר את התוצאה שאמורה להתרחש אם התוכנה פועלת כמצופה.
בבדיקות לא פונקציונליות כמו בדיקות ביצועים ובדיקות עומס, זה עשוי לומר במקרים רבים שהתוכנה פשוט ממשיכה לפעול כרגיל מבלי להאט, לפגר או לקרוס.
במקרים אחרים, פירוש הדבר עשוי להופיע הודעות שגיאה מסוימות כדי להודיע למשתמש על הבעיה ולהמליץ על פתרון.
5. המלץ על טכניקות בדיקה
עבור כל מקרה בדיקה, המלץ על סוג טכניקות הבדיקה וכלי הבדיקה הלא פונקציונליים שאתה חושב שהבודק צריך להשתמש במהלך הבדיקה.
בבדיקות לא פונקציונליות, בודקים עשויים להשתמש בגישות שונות מאוד עבור סוגים שונים של בדיקות.
לדוגמה, בדיקות עומס ובדיקות מאמץ עשויות לדרוש אוטומציה מכיוון שזה לא מעשי לדמות תנועה כבדה במיוחד באופן ידני, בעוד שסוגי בדיקות אחרים עשויים להיות קלים יותר לביצוע ללא כלים או טכנולוגיות ספציפיות.
6. בדוק כל מקרה מבחן עמית
לפני שאתה חותם על כל מקרה מבחן, קבל כל מקרה לביקורת עמיתים על ידי מישהו שאתה עובד איתו. זה עשוי להיות בודק אחר או מוביל QA.
מקרי בדיקה של בדיקת עמיתים מבטיחים שהם ברורים מספיק כדי שיעקוב אחריהם על ידי בודק צד שלישי ואינם כוללים אי בהירות או טעויות שעלולות להוביל לבדיקה לא נכונה.
3. דוגמאות למקרי מבחן שאינם פונקציונליים
אם אתה כותב מקרי בדיקה לבדיקות לא פונקציונליות, הם עשויים להיראות כמו דוגמאות הבדיקות הלא פונקציונליות למטה.
דוגמה לבדיקת מדרגיות
מזהה מקרה בדיקה: 6671
שם מקרה הבדיקה: בדיקת התחברות מרובה משתמשים
תיאור: חיקוי 20+ משתמשים המתחברים לתוכנה בו זמנית באמצעות כלי אוטומציה.
התוצאות הצפויות: התוכנה אמורה לפעול כרגיל עבור כל משתמש, ולאפשר לכל משתמש להיכנס בהצלחה תוך פחות מ-5 שניות.
דוגמה לבדיקת תאימות
מזהה מקרה בדיקה: 5214
שם מקרה מבחן: טעינת האפליקציה בדפדפן Opera
תיאור: טען את האפליקציה בדפדפן האינטרנט של Opera.
התוצאות הצפויות: היישום נטען כרגיל בדפדפן האינטרנט של Opera עם רזולוציית תצוגה ופריסה סטנדרטיים.
בדיקות ידניות או אוטומטיות שאינן מתפקדות?
כאשר אתה בוחר בין טכניקות בדיקה לא פונקציונליות שונות, תצטרך להחליט אם ברצונך לבצע בדיקות ידניות או אוטומטיות שאינן פונקציונליות.
בדיקות ידניות מבוצעות על ידי בודקים אנושיים, מה שאומר שלרוב הם גוזלים יותר זמן לביצוע, אבל הם גם מציעים הזדמנויות לבדיקות חקרניות.
בדיקות אוטומטיות שאינן פונקציונליות הן מהירות יותר, ובמובנים מסוימים, אמינות יותר, אך הן גם דורשות יותר משאבים או כלים. אוטומציה והיפר -אוטומציה הופכות יותר ויותר פופולריות בבדיקות, במיוחד כשמדובר בבדיקות לא פונקציונליות.
בדיקה ידנית לא פונקציונלית: יתרונות, אתגרים ותהליכים
בדיקה ידנית שאינה פונקציונלית מתבצעת אך ורק על ידי בודקים, אשר יבדקו כל אלמנט שאינו פונקציונלי אינדיבידואלי באופן עצמאי.
בעת ביצוע בדיקות ידניות שאינן פונקציונליות, על הבודקים לאסוף מידע על התוכנה, ליצור מקרי בדיקה בודדים התואמים את תוכנית הבדיקה ולבצע את מקרי הבדיקה הללו באופן ידני.
זה לוקח זמן רב, אבל זה גם אומר שלבודקי QA יש את החופש לקבוע מה נבדק וכיצד.
1. חלק מהיתרונות של בדיקה ידנית כוללים:
● בדיקה ידנית עשויה להיות זולה יותר מבדיקה אוטומטית מכיוון שאינה דורשת טכנולוגיות ספציפיות או ידע טכני.
● בדיקה ידנית מאפשרת לבודקים להציע תובנה וסובייקטיביות אנושית לגבי אופן פעולת התוכנה והאם היא פועלת בצורה משביעת רצון.
● ניתן להשתמש בבדיקות ידניות לביצוע בדיקות מערכת בתרחישים שבהם אי אפשר לבצע אוטומציה.
● בדיקה ידנית מאפשרת לבודקים להעריך את ההיבטים הוויזואליים של המערכת כגון הממשק הגרפי וגורמים אחרים שעשויים להשפיע על השימושיות.
● בדיקה ידנית מציעה לבודקים פרספקטיבה רחבה יותר של המערכת כולה וכיצד מודולים ורכיבים שונים עובדים יחד
עם זאת, ישנם גם חסרונות לבדיקה ידנית.
2. חלק מהאתגרים של בדיקה ידנית כוללים:
● סוגים מסוימים של בדיקות לא פונקציונליות, כולל בדיקות עומס ובדיקות ביצועים, אינם מעשיים לביצוע ידני
● בדיקה ידנית לוקחת הרבה יותר זמן מאשר בדיקות אוטומטיות שאינן פונקציונליות
● בודקים ידניים עלולים להסיח את דעתו, לאבד מיקוד ולעשות טעויות, במיוחד בעת ביצוע משימות בדיקה שחוזרות על עצמן.
בדיקות אוטומטיות לא פונקציונליות: יתרונות, אתגרים ותהליכים
בדיקות אוטומטיות שאינן פונקציונליות מתבצעות על ידי סקריפטים וכלי בדיקה אוטומטיים. בעת שימוש בשיטות בדיקה אוטומטיות, בודקים יכולים לבצע בדיקות ברקע תוך כדי ביצוע משימות אחרות, לאחר שהבדיקות האוטומטיות החלו.
1. כמה מהיתרונות של אוטומציה של בדיקות לא פונקציונליות הן:
1. חסוך זמן ומשאבים על ידי הפחתת כמות הזמן שאתה מבלה במשימות ארוכות וגוזלות זמן
2. אוטומציה מאפשרת להגדיל את כיסוי הבדיקה על ידי כיסוי מגוון רחב יותר של רכיבים ותכונות
3. כדאי יותר לבצע בדיקות אוטומטיות בתדירות גבוהה מכיוון שלוקח פחות זמן לבצען
4. בדיקות אוטומטיות אידיאליות למשימות בדיקה שגוזלות זמן כמו בדיקת עומס, בדיקת נפח ובדיקות מאמץ שקשה מאוד לבצע אותן באופן ידני
5. קיים סיכוי נמוך יותר להתעוררות שגיאות בעת ביצוע בדיקות אוטומטיות
עם זאת, יש גם כמה חסרונות לבדיקות אוטומטיות, מה שאומר שזו לא תמיד הגישה הנכונה לכל סוגי הבדיקות הלא פונקציונליות.
2. חלק מהאתגרים של בדיקות אוטומטיות לא פונקציונליות כוללים:
1. בדיקה אוטומטית יקרה יותר להגדרה מאשר בדיקה ידנית
2. הגדרת אוטומציה של בדיקות עשויה לקחת זמן ומשאבים טכניים
3. אוטומציה של בדיקות לא מאפשרת מקום לבדיקות חקרניות
4. אוטומציה של בדיקות עדיין דורשת זמן ליצירת מקרי בדיקה
מסקנה: ידני או אוטומטי
בדיקה לא פונקציונלית?
ברוב סוגי בדיקות התוכנה, שילוב של בדיקות ידניות ואוטומטיות מציע בדרך כלל את התוצאות הטובות ביותר. זה מאפשר לצוותי בדיקה להפיק תועלת מהיעילות, האמינות והדיוק של בדיקות אוטומטיות תוך ביצוע בדיקות חקרניות המאפשרות לבודקים להעריך תוכנה מנקודת מבט סובייקטיבית יותר.
בבדיקות לא פונקציונליות, הן בדיקות ידניות והן בדיקות אוטומטיות נחוצות למעשה עבור רוב צוותי הבדיקה.
בדיקות ידניות משמשות בצורה הטובה ביותר לביצוע משימות בדיקה שאינן פונקציונליות כמו בדיקות שמישות, בעוד שבדיקות אוטומטיות משמשות לרוב לביצוע בדיקות שגוזלות זמן רב מדי וקשות לביצוע באופן ידני, כגון בדיקות מאמץ או בדיקות נפח.
בדיקה לא פונקציונלית היא אחד התחומים הברורים ביותר לשימוש בטכניקות אוטומציה של בדיקות מכיוון שמדובר בסוג בדיקות כמותי מדיד שאינו מבקש תוצאות סובייקטיביות.
בדומה לסוגים אחרים של בדיקות, בדיקות לא פונקציונליות מבוצעות בדרך כלל תוך שימוש בתערובת של בדיקות ידניות ובדיקות אוטומטיות.
עם זאת, בדיקה אוטומטית נחוצה למעשה עבור סוגים רבים של בדיקות לא פונקציונליות, והפרמטרים והמדדים של בדיקות לא פונקציונליות אומרות שהאוטומציה מתאימה יותר לסוג זה של בדיקות מאשר בדיקות פונקציונליות.
שיטות עבודה מומלצות לבדיקות לא פונקציונליות
כאשר אתה מבצע בדיקות לא פונקציונליות בפעם הראשונה, ביצוע שיטות עבודה מומלצות לבדיקה יכול לעזור לך לתקן את תהליך הבדיקה שלך ולמטב את יעילות הבדיקות שלך.
שיטות עבודה מומלצות משמשות כהנחיות לצוותי בדיקות תוכנה שרוצים לשפר את תהליכי הבדיקה ולהתאים לסטנדרטים בתעשייה.
1. השתמש בכלי אוטומציה
בבדיקות לא פונקציונליות יותר מסוגי בדיקות אחרים, חשוב להשתמש בכלי אוטומציה כדי להפוך סוגים מסוימים של בדיקות לאוטומטיות, במיוחד בדיקות נפח, בדיקות מאמץ ובדיקות עומס.
סוגים אלה של בדיקות בדרך כלל מאמתים עד כמה התוכנה פועלת תחת לחץ כבד מצד משתמשים, נתונים ותעבורה, שיכולים להיות תנאים קשים מאוד לחיקוי ידני.
אוטומציה של בדיקות לא פונקציונליות מסוג זה לא רק תהיה יעילה יותר אלא גם מדויקת יותר ותאפשר לבודקים לשכפל עומסים ולחצים גבוהים יותר בקלות.
2. סקירת עמיתים בכל התיעוד
בנוסף לבקש מעמיתים לסקור מקרי בדיקה שאתה יוצר, בקש מעמיתים בצוות הבדיקה שלך לסקור דוחות באגים, דוחות בדיקה, תוכניות בדיקה וצורות אחרות של תיעוד רשמי שנוצר במהלך תהליך הבדיקה.
זה מפחית את הסיכון לטעויות קטנות שעלולות לגרום לעיכובים רציניים בתהליך הבדיקה והפיתוח.
3. הגדירו דרישות מדידות
כאשר אתה מגדיר את הדרישות של התוכנה שלך לפני שמתחילות בדיקות לא פונקציונליות, ודא שכל דרישה היא אובייקטיבית וניתנת למדידה.
זה מקל על הבודקים לוודא האם התוכנה עומדת בדרישות אלו במהלך הבדיקה ולא מותיר מקום לפרשנות.
מה נחשב “מהיר” או “יעיל”? השתמש במספרים ובערכים כמותיים כדי להגדיר מה אתה מחפש.
4. שקלו היטב את הבדיקות של מדדים
לפני שתחליט באילו מדדים אתה הולך להשתמש כדי למדוד את הביצועים של התוכנה שלך, שקול מה המשתמשים של התוכנה ירצו ואילו מדדים בעצם מתאימים לתוכנית התוכנה ולדרישות.
רוב התוכנות צריכות להיות מהירות ואמינות, אבל אילו מדדים נוספים המשתמשים שלך יכולים לחפש? האם יש מדדים ספציפיים לתוכנה שכדאי לקחת בחשבון במהלך תהליך הבדיקה?
סוגי פלט מבדיקה לא פונקציונלית
כאשר אתה מבצע בדיקות לא פונקציונליות, תקבל סוגים שונים של פלטים מהבדיקות שאתה מבצע.
אלה בדרך כלל שונים למדי מפלטי בדיקה פונקציונליים, שלעתים קרובות הם חתוכים ברורים יותר מכיוון שבדיקות פונקציונליות פשוט בודקות אם פונקציה פועלת כפי שהיא צריכה או לא.
בדומה לבדיקות פונקציונליות, בודקים צריכים להגדיר ציפיות ברורות לכל מקרה מבחן שמקלות לקבוע אם כל מבחן עובר או נכשל.
1. מספרים מוחלטים
בעת ביצוע בדיקות ביצועים, בדיקות מאמץ וסוגים אחרים של בדיקות לא פונקציונליות, התפוקות שאתה עשוי להסתכל עליהן לרוב הן מהירויות ומספרים מוחלטים אחרים.
בדיקת ביצועים מוודאת באיזו מידה המערכת יכולה לבצע משימות מסוימות, וזה יימדד בשניות או אלפיות שניות.
אם אתה מבצע בדיקות עומס, תוכל להעריך כמה נתונים התוכנה יכולה להתמודד בבת אחת מבלי לקרוס או לפגר.
2. הודעות שגיאה
בדיקות לא פונקציונליות גם מאמתות כיצד המערכת פועלת כאשר מתרחשות שגיאות, כגון שגיאות אבטחה, שגיאות אימות ושגיאות תצורה.
חשוב שמערכות יציגו הודעות שגיאה מדויקות וברורות כאשר מתרחשות שגיאות, כך שהמשתמשים יוכלו לנקוט בצעדים לתיקון הבעיה ולהמשיך להשתמש בתוכנה.
הודעות שגיאה צריכות להופיע גם במהלך בדיקות אבטחה כאשר המערכת מונעת ממשתמשים להפר את תכונות האבטחה המובנות של התוכנה.
3. קריסות
קריסה היא סימן לכשל במערכת, וזה בדרך כלל מצביע על כך שהמערכת לא מסוגלת לבצע את הביצועים ברמה שאתה בודק ויכול להיות שהמבחן עובר.
במקרים מסוימים, המערכת עלולה לקרוס ועדיין לעבור את מקרה המבחן עליו אתה עובד, למשל, אם המערכת עומדת בכמות הלחץ או התנועה הנדרשת לפני התרסקות.
בעת ביצוע בדיקות לא פונקציונליות, בודקים צריכים לצפות מהמערכת לקרוס באופן קבוע, במיוחד כאשר דוחפים אותה לגבולותיה עבור מבחני מאמץ ומבחני ביצועים אחרים.
דוגמאות למבחנים לא פונקציונליים
דוגמאות לבדיקות לא פונקציונליות דומות לדוגמאות לעיל עבור מקרי בדיקה לא פונקציונליים.
אתה יכול להסתכל על דוגמאות של בדיקות לא פונקציונליות כדי להבין טוב יותר מהי בדיקה לא פונקציונלית ומה היא בודקת בתוך יישום תוכנה.
1. דוגמה לבדיקת ביצועים
אם אתה עובד על אפליקציה לנייד שמחברת משתמשים למסד נתונים מקוון, חשוב שמספר רב של משתמשים יוכלו לגשת ולהוריד את הנתונים ממסד הנתונים הזה בו-זמנית.
זהו גם חלק מרכזי בבדיקת מדרגיות, במיוחד אם אתה רוצה להגדיל את מספר המשתמשים באפליקציה בעתיד.
לאחר מכן תבדוק כיצד המערכת מגיבה כאשר, למשל, 1000 משתמשים מנסים לגשת לאותו מסד נתונים בו זמנית ותגדיר דרישות למהירות הטעינה של האפליקציה בתנאי זה.
2. בדיקת תאימות
אם אתה בודק יישום חדש לניהול מסמכים, תצטרך לבדוק שהוא פועל בכל המכשירים שהוא מיועד להם.
משמעות הדבר היא בדיקה שאתה יכול להתקין ולטעון את היישום בכל הגירסאות העדכניות ביותר של Windows , Mac וכל מערכות הפעלה אחרות (כגון Linux ) שאליהן אתה רוצה שהתוכנה תהיה תואמת.
3. בדיקות אבטחה
כאשר אתה מבצע בדיקות אבטחה, תבדוק כמה מהדרכים שבהן אנשים עשויים לנסות לגשת לנתונים סודיים או להפר את אמצעי האבטחה של התוכנה כדי לוודא שהמערכת מתנהגת כפי שאתה מצפה ממנה במצבים אלה.
לדוגמה, אתה עשוי להיכנס כמשתמש ולנסות לגשת לקבצים שאין לך אישור אבטחה עבורם כדי לוודא שהמערכת לא מאפשרת לך לגשת לקבצים אלה.
סוגי שגיאות ובאגים שזוהו
באמצעות בדיקות לא תפקודיות
בדיקות לא פונקציונליות יכולות לחשוף הרבה באגים ופגמים שלא קל למצוא כמו אלו שזוהו בבדיקות פונקציונליות. הסיבה לכך היא שבדיקות לא פונקציונליות מחייבות לעתים קרובות בודקים לאמת תצורות, הגדרות ושילובים שונים של תנאים כדי להעריך את ביצועי המערכת במספר עצום של הגדרות שונות.
1. ליקויי ביצועים
פגמים בביצועים מתעוררים כאשר המערכת פועלת, אך היא אינה פועלת במהירות או ביעילות כפי שאתה מצפה ממנה.
לדוגמה, ייתכן שתגלה שהמערכת לא נטענת מספיק מהר בתנאים מסוימים או אפילו קורסת אם משתמשים רבים מדי נכנסים בו זמנית.
פגמים בביצועים אינם מונעים לחלוטין מאנשים להשתמש בתוכנה שלך, אך הם יכולים להפוך את התוכנה שלך לפחות שמישה ולפחות סיכוי לעמוד בדרישות המשתמש.
2. ליקויי אבטחה
פגמי אבטחה הם אותם פגמים המשפיעים על האבטחה של מערכת התוכנה שלך והנתונים המאוחסנים בה.
פגמי אבטחה עשויים להיווצר אם, למשל, משתמשים יכולים לגשת לנתונים סודיים שלא אמורה להיות להם גישה אליהם או אם חלקים מסוימים של האפליקציה אינם מוגנים כהלכה באמצעות סיסמה, או אם ההצפנה נכשלת.
אלה עלולים לגרום לפרצות אבטחה, שעלולות להיות להן השפעה חמורה על המוניטין של מפרסם תוכנה.
3. ליקויים תפקודיים
בעוד שבדיקות לא פונקציונליות לא נועדו לבדוק את הפונקציות של יישום תוכנה, במקרים מסוימים בדיקות לא פונקציונליות יכולות לזהות פגמים תפקודיים בתוכנה.
לדוגמה, מטרת בדיקת האמינות היא לא לבדוק אם האפליקציה מתפקדת אלא לבדוק אם האפליקציה מתפקדת בצורה מהימנה בניסיונות חוזרים ונשנים.
זה עשוי לחשוף שתכונות מסוימות אינן פועלות באופן מהימן כשפעולה חוזרת על עצמה, ואלה עשויות להיות מסווגות כשגיאות פונקציונליות.
מדדי בדיקה נפוצים שאינם פונקציונליים
מדדי בדיקה לא פונקציונליים מתארים את אותם מדדים שבאמצעותם נמדדים הביצועים והיעילות של המערכת.
סוגים שונים של בדיקות לא פונקציונליות מסתמכות על מדדים שונים, ואתה יכול לבחור להשתמש במגוון מדדים בהתאם למטרות הסופיות של הפרויקט.
זמן 1
מדדי זמן מודדים כמה זמן לוקח לבצע משימות מסוימות או כמה זמן משתמשים צריכים לחכות לטעינת הפונקציות.
כמה דוגמאות למדדי זמן הן מספר העסקאות או ההורדות שאפליקציה יכולה לבצע בתוך מסגרת זמן נתונה, זמני התגובה של פונקציות שונות והזמן שלוקח לאפליקציה להשלים פעולה מסוימת.
סוגים שונים של בדיקות ימדוד תוצאות בשניות או כמצגת של כמה פעולות בשנייה.
2. רווח
החלל הוא מדד חשוב נוסף בבדיקות לא פונקציונליות. מדדי שטח עשויים לבדוק כמה שטח מעבד דורשת המערכת או כמה מקום בכונן הקשיח התוכנה תופסת לאחר ההתקנה המלאה.
כמה דוגמאות למדדי שטח כוללות זיכרון מטמון, זיכרון ראשי וזיכרון עזר.
תוכנה שדורשת כמות גדולה של שטח כדי לפעול בצורה חלקה עשויה להתאים למספר קטן יותר של לקוחות.
3. שימושיות
כמה מדדים בבדיקות לא פונקציונליות לוקחים בחשבון את השימושיות של המערכת, למשל, כמה זמן לוקח להכשיר את המשתמשים להשתמש במערכת כראוי, כמה אפשרויות יש למשתמשים לנווט דרכם כדי לבצע פונקציות מפתח, או כמה לחיצות עכבר נדרש לבצע משימות מסוימות.
בדיקות לא פונקציונליות יכולות למדוד כל אחד מהמדדים הללו בצורה כמותית, כאשר מספרים נמוכים יותר מרמזים בדרך כלל על רמות גבוהות יותר של שימושיות.
4. אמינות
מדד חשוב נוסף בבדיקות לא פונקציונליות הוא אמינות. מהימנות משקפת את הסבירות שהמערכת מתנהגת באותה צורה פעם אחר פעם או מתפקדת כפי שהיא צריכה במשך תקופה ארוכה.
כמה דוגמאות למדדים המשמשים למדידת אמינות כוללות זמן ממוצע עד לכשל, שיעור כשל, זמינות והסתברות לזמן השבתה.
כל אחד מהמדדים הללו עוזר לבודקים לוודא שהמערכת יכולה לפעול לאורך זמן מבלי לחוות כשלים או קריסות.
5. איתנות
החוסן הוא המדד למידת יכולת המערכת להתמודד עם כשלים ועד כמה המערכת יכולה לשחזר את עצמה במקרה של כשל.
כמה דוגמאות למדדים המודדים חוסן כוללות את הזמן שלוקח למערכת לשחזר את עצמה לאחר תקלה, אחוז התקריות המובילות לכשל קטסטרופלי, וההסתברות שקובצי נתונים פגומים לאחר כשל במערכת.
אלו מדדים חשובים מכיוון שמשתמשים מצפים שלעיתים מערכות עלולות להיכשל מבלי לאבד את כל הנתונים או להשחית קבצים.
6. ניידות
מדדי ניידות מודדים באיזו קלות ניתן להעביר את התוכנה למערכות שונות או להעביר למיקום חדש בתוך רשת.
כמה דוגמאות למדדים המודדים ניידות כוללות את אחוז הקוד שאינו נייד ומספר המערכות בהן התוכנה יכולה לפעול.
באופן אידיאלי, תוכנה שיכולה לפעול על הרבה מערכות שונות היא ניידת יותר ולכן נוחה יותר לשימוש בהגדרות שעשויות לדרוש העברות או העברות תכופות.
אסטרטגיות לביצוע בדיקות לא פונקציונליות
כאשר אתה מתחיל בדיקות לא פונקציונליות, חשוב לגשת לשלב זה של הבדיקה מתוך מחשבה על אסטרטגיה. לידים של QA ומנהלי בדיקות תוכנה צריכים לשקול את הסיכונים שבבדיקות, את המשאבים העומדים לרשותם ואת מטרת הבדיקה לפני תחילת בדיקות לא פונקציונליות.
פיתוח אסטרטגיה יכול לעזור לך לייעל את הבדיקות הלא פונקציונליות שלך מההתחלה.
1. הקצאת תפקידים ואחריות
לפני שתתחיל בבדיקות לא פונקציונליות, הקצה תפקידים ואחריות לחברי המפתח של צוות הבדיקות. זה מקל על ניהול עומס העבודה של בדיקות לא פונקציונליות ולוודא שבודקים מנוסים אחראים לשמירה על האיכות והיעילות של הבדיקות שאתה עורך.
ודא שלאנשים שאתה בוחר לקחת על עצמם את התפקידים האלה יש את הידע והניסיון שהם צריכים כדי לבצע את המשימות שאתה מצפה מהם, במיוחד אם המשימות האלה דורשות מיומנויות טכניות.
2. אסוף כלי בדיקה רלוונטיים
אסוף את כל הטכנולוגיות והכלים שבהם אתה רוצה להשתמש כדי לבצע בדיקות לא פונקציונליות. ודא שכל הצוות שלך יודע להשתמש בהם ביעילות, וערוך הדרכה למילוי פערי מיומנויות במידת הצורך.
לוודא שכולם יודעים באילו כלי בדיקה להשתמש וכיצד להשתמש בהם לפני שמתחילות בדיקות לא פונקציונליות מפחיתה את הסיכון להשהות את הבדיקות או לבצע מחדש בדיקות בגלל חוסר ידע.
3. תעדוף בדיקות
לפני שתתחיל בבדיקות לא פונקציונליות, ערוך רשימה של כל ההיבטים של המערכת שאתה צריך לבדוק ותעדף אותם לפי דחיפות וחשיבות.
אתה יכול לתעדף בדיקות לא פונקציונליות על סמך רמת הסיכון הכרוכה בכל היבט של המערכת שאתה בודק.
לדוגמה, בדיקות אבטחה בסיסיות עשויות להתקיים מכיוון שאבטחה נאותה נחשבת חשובה ביותר בתוכנה מודרנית. ככל שתזהה מוקדם יותר פגמים בסיכון גבוה, ההשפעה הפוטנציאלית של פגמים אלו יכולה להיות נמוכה יותר בהיבטים אחרים של המערכת.
7 כלי הבדיקה הלא פונקציונליים הטובים ביותר
כלי בדיקה לא פונקציונליים יכולים לייעל את תהליך הבדיקה, להקל וחסכוני יותר להפוך את הבדיקות לאוטומטיות ולעזור ללידים QA לנהל את תהליך הבדיקה והתיעוד.
יש הרבה כלי בדיקה בחינם שאינם פונקציונליים זמינים באינטרנט, כמו גם כמה כלים שאתה יכול לשלם תשלום חודשי כדי לשדרג.
1. מהדורה חינמית של ZAPTEST
ZAPTEST הוא כלי פופולרי לבדיקת תוכנה המאפשר למשתמשים לבצע בדיקות תוכנה פונקציונליות ולא פונקציונליות במהירות ובקלות. אתה יכול להשתמש ב-ZAPTEST כדי להפוך בדיקות תוכנה לאוטומטיות ולהשתמש בטכנולוגיית RPA כדי לחקות פונקציות ותנאים שונים בבדיקות לא פונקציונליות.
מהדורת ZAPTEST FREE היא רק גרסה מצומצמת של המהדורה הארגונית, המציעה רבות מאותן פונקציות בקנה מידה קטן יותר. אתה יכול לבקש תמיכה בפורום ZAPTEST ולבצע מבחני ביצועים עם משתמשים וירטואליים ללא הגבלה.
2. אפיום
Appium הוא כלי חינמי לבדיקת תוכנה המתאים ביותר לבדיקת יישומים ניידים במגוון פלטפורמות שונות כולל מכשירי iOS ו- Android כאחד. Appium מציעה למשתמשים גמישות רבה להמציא מסגרות ואסטרטגיות בדיקה משלהם תוך תועלת מיכולות האוטומציה שמציעה Appium.
3. Loadium
Loadium הוא כלי בדיקה לא פונקציונלי המתאים ביותר לביצוע בדיקות ביצועים ובדיקות עומס, שני סוגים של בדיקות לא פונקציונליות שהרבה יותר קל לבצע באמצעות כלי אוטומציה.
Loadium מאפשרת למשתמשים להריץ בדיקות עומס בקנה מידה גדול ומציעה פתרונות מותאמים אישית כך שתוכל להתאים את הבדיקות שלך למטרות התוכנה שלך.
אתה יכול לנסות את Loadium בחינם או לשלם כדי להוריד את הגרסה המלאה של האפליקציה.
4. אובקיו
Obkio הוא כלי לבדיקת תוכנה המסייע להובלות QA ולמנהלי בדיקות לתעדף ולסווג בעיות על סמך מידת הרצינות שלהן. Obkio יכולה לזהות בעיות לפני שמשתמשים עושים זאת, מציעה למשתמשים התראות חכמות, ויכולה לעזור לזהות היכן הבעיה.
Obkio אינו מיועד רק לבדיקות לא פונקציונליות, אלא הוא כלי בדיקה חינמי שימושי ביותר שניתן להשתמש בו בכל שלבי מחזור חיי הבדיקה.
5. SonarQube
SonarQube הוא כלי לבדיקת אבטחה בקוד פתוח שיכול לנתח קוד באופן אוטומטי כדי לזהות באגים ופגיעויות. כתוב ב-Java, אתה יכול להשתמש ב-SonarQube כדי לנתח קוד בלמעלה מעשרים שפות תכנות שונות והממשק הנקי של המערכת מקל על זיהוי בעיות שעלולות לגרום לפרצות אבטחה בעתיד.
6. טסונג
Tsung הוא כלי בדיקה נוסף שאינו פונקציונלי ואידיאלי אם אתה רוצה להפוך את בדיקות העומס והלחץ לאוטומטיות אך לא ממשיך עם הגרסה החינמית של Loadium.
Tsung הוא כלי קוד פתוח המאפשר למשתמשים לבצע בדיקות עומס בנפח גבוה על פני מספר פרוטוקולים ושרתים כולל HTTP ו-SOAP.
Tsung חינמית לחלוטין והיא יכולה לעזור לבודקים להבטיח שהתוכנה עליה הם עובדים מציעה רמות ביצועים גבוהות במגוון תנאים מאתגרים.
7. סיקולי
Sikuli היא אפליקציה נוספת המשתמשת באוטומציה רובוטית של תהליכים כדי להפוך את תהליך הבדיקה לאוטומטי. האפליקציה יכולה להפוך כל דבר שניתן לראות על המסך לאוטומטי. אתה יכול להשתמש ב-Sikuli כדי לבדוק יישומים שאינם מבוססי אינטרנט ולשחזר במהירות באגים.
רשימת בדיקה לא פונקציונלית, טיפים וטריקים
לפני שתתחיל בבדיקות לא פונקציונליות, בדוק שיש לך את כל מה שאתה צריך כדי לבצע בדיקות לא פונקציונליות יסודיות בסביבה מוכנה.
עקוב אחר רשימת הבדיקה שלהלן לקבלת טיפים וטריקים לפני התחלת בדיקות לא פונקציונליות.
1. עבדו לפי לוח זמנים
בין אם אתה כולל אותו בתוכנית הבדיקה שלך או יוצר עבורה מסמך נפרד, בנה את בדיקות התוכנה שלך סביב לוח זמנים לבדיקה.
אם אתה מוצא יותר באגים ופגמים ממה שאתה מצפה, אתה עלול לחרוג מלוח הזמנים לפעמים, אבל קיום לוח זמנים מלכתחילה יכול לעזור להנחות את הבודקים ולהניע אותם לעבוד ביעילות, במיוחד בעת ביצוע בדיקות ידניות שגוזלות זמן.
2. זהה את צוות המבחן שלך
האצלת אחריות והקצאת חברי צוות הבדיקה שלך עם תפקידים ותארים רשמיים יכולים לעזור להבטיח שתהליך הבדיקה יעבור בצורה חלקה.
תקשר בבירור תפקידים ואחריות בתוך הצוות שלך לפני תחילת הבדיקות, והקצה לבודקים שונים את האחריות להיבטים שונים של בדיקות לא פונקציונליות, כך שכל אחד יישא באחריות למשימות שלו.
3. בחר כלים וטכנולוגיות לפני הבדיקה
אם תחליט לעבוד עם כלים וטכנולוגיה מסוימים רק לאחר שתתחיל בדיקות לא פונקציונליות, זה יכול לעכב את תהליך הבדיקה ולגרום לבלבול בקרב הבודקים.
במקום זאת, בצע את המחקר שלך מראש והחליט אם יש כלים שאתה רוצה להשתמש בהם לפני תחילת הבדיקה. זה מקל לשלב את הכלים האלה בתוכנית הבדיקה ולהכשיר את הבודקים שלך להשתמש בהם לפני תחילת הבדיקה.
4. השג תמיד חתימה רשמית על בדיקות ותיעוד
בדיקה היא תהליך הבטחת איכות, והדרך הטובה ביותר למקסם את הערך של הבדיקות שאתה מבצע היא לבצע QA בסיסי גם בבדיקות שאתה מתכנן ומפעיל.
הצג פרוטוקולים פשוטים המחייבים בודקים לבקש מהלידים של QA ומנהלים לבדוק ולחתום על תוכניות בדיקה ודוחות בדיקה לפני המעבר לשלב הבא.
זה מגדיל באופן מסיבי את הסיכוי שטעויות בדיקה נתפסות ומתוקנות מוקדם.
7 טעויות ומלכודות שיש להימנע מהם בעת יישום בדיקות לא פונקציונליות
אם אתה חדש בבדיקות לא פונקציונליות, זה יכול להיות קל לעשות כמה טעויות נפוצות שלעתים קרובות נופלים בהן בודקים ואנשי מקצוע בתחום ה-QA.
בדיקה לא פונקציונלית היא עבודה מורכבת הכוללת בחינת בניית תוכנה מכל הזוויות והפרספקטיבות.
להלן רשימה של כמה מהמלכודות הנפוצות ביותר שעושים בודקים בעת ביצוע בדיקות לא פונקציונליות.
1. לא מתכנן
אם אתה חדש בבדיקות לא פונקציונליות, אתה עשוי לחשוב שאתה יכול פשוט לצלול ישר לשלב הבדיקה מבלי ליצור תוכנית בדיקה יסודית מראש.
צוותי בדיקה מסוימים עשויים להרכיב מסמכי בדיקה חלקיים או סיכומים שטחיים של תוכנית הבדיקה, שאינם מתארים כראוי את הפעולות שעל הבודקים לבצע במהלך בדיקות לא פונקציונליות.
2. בדיקת ניהול כושל
בעיות יכולות להתעורר אם בדיקות מנוהלות בצורה לא נכונה בכל שלב של תהליך הבדיקה. ניהול לא הולם עלול לגרום לכך שלבודקים אין את המשאבים המתאימים לבצע בדיקות ביסודיות או שלבודקים לא ניתן מספיק זמן לבדוק כל היבט של ה-build.
מנהלי מבחנים חייבים להיות מסוגלים ללמוד מהטעויות שהם עושים ולפתח תוכניות בדיקה יעילות יותר קדימה.
3. תקשורת לקויה
תקשורת לקויה עלולה לגרום להרבה בעיות במהלך תהליך הבדיקה, במיוחד בתוך בדיקות לא פונקציונליות.
זה יכול להיות תקשורת לקויה בתוך צוות הבדיקות או תקשורת לקויה בין בודקים, מפתחים ובעלי עניין.
זה קורה לעתים קרובות כאשר הבודקים אינם מתחזקים מסמכי בדיקה בצורה מספקת או אינם מתקשרים באופן קבוע עם מחלקות אחרות במהלך תהליך הבדיקה.
4. התעלמות ממפתחים
בודקים ומפתחים בדרך כלל עובדים די בנפרד אחד מהשני, אך צוותי בדיקה שעובדים בשיתוף פעולה הדוק עם מפתחים יכולים להפיק תועלת מידע נוסף על אופן פעולת התוכנה וכיצד מודולים שונים מתקשרים זה עם זה.
שיתוף מפתחים בתהליך הבדיקה, או בקשת משוב ממפתחים בזמני מפתח, יכול לעזור לצוותי בדיקה להרכיב תוכניות בדיקה יעילות ויסודיות יותר.
5. מטרת הבדיקה
בודקים רבים עדיין מאמינים שמטרת הבדיקה היא לבדוק שהתוכנה עובדת או להוכיח לבעלי עניין ומשקיעים שהתוכנה עובדת.
במקום זאת, בודקים צריכים לגשת לבדיקות מתוך גישה שמטרת הבדיקה היא לחפש פגמים.
בודקים שלא מוצאים פגמים יכולים לשמוח שהתוכנה שהם בודקים נקייה מבאגים רק אם הם מרוצים שהם חיפשו בכל מקום שאולי יתגלו פגמים.
6. שגיאות ידניות מול אוטומציה
חשוב להקדיש זמן לשקול האם בדיקה ידנית או בדיקה אוטומטית עדיפה לכל סוג בדיקה שאתה מבצע.
שיטות בדיקה אוטומטיות מתאימות ביותר כמעט לכל צורות הבדיקות הלא פונקציונליות, וצוותי בדיקה המשמשים לבדיקות פונקציונליות עשויים לטעות ולהניח שהם יכולים לבדוק תכונות לא פונקציונליות באופן ידני באותה קלות.
7. שימוש בכלי בדיקה שגויים
קל לבחור את כלי הבדיקה והטכנולוגיות הלא נכונים לפני שמתחילים בבדיקות לא פונקציונליות, במיוחד אם צוותי הבדיקה רגילים לבצע בדיקות ידניות ואינם רגילים להשתמש בכלי בדיקה.
חקור את שיטות הבדיקה הלא פונקציונליות שבהן תרצה להשתמש מראש ובחר כלי תוכנה וכלי אוטומציה העונים על הדרישות הספציפיות של הפרויקט שלך.
סיכום
בדיקות לא פונקציונליות הן שלב חיוני בתהליך הבדיקה המאפשר לבודקים לאמת עד כמה המערכת מתפקדת ובאיזו מידה היא עומדת בדרישות לא פונקציונליות כגון זמני טעינה, קיבולת ושמירה על אבטחה.
ישנן דרכים רבות ושונות לבצע בדיקות לא פונקציונליות, אך כלי אוטומציה עכשוויים מקלים על מקסום הכיסוי והדיוק של הבדיקות מבלי לפגוע באיכות התוצאות שלך.
שאלות נפוצות ומשאבים
אם אתה רוצה לברר עוד על בדיקות לא פונקציונליות, יש הרבה שאלות נפוצות ומשאבים זמינים באינטרנט.
עיין במשאבי הבדיקה הלא-פונקציונליים המועדפים עלינו למטה או קרא את התשובות לכמה מהשאלות הנפוצות ביותר לגבי בדיקות לא-פונקציונליות.
1. הקורסים הטובים ביותר על בדיקות לא פונקציונליות
ישנם המון קורסים זמינים באינטרנט שיכולים לעזור לך להרחיב את הידע שלך על שיטות וגישות בדיקה לא פונקציונליות.
חלק מהקורסים הללו זמינים בחינם, ואחרים עשויים להציע תעודה או הסמכה בתמורה לתשלום. אם אתה רוצה לעבור קורס מוסמך, תוכל לשאול את המעסיק שלך אם הוא יתן לך חסות ויכסה את עלות שכר הלימוד.
כמה מהקורסים הטובים ביותר בנושא בדיקות לא פונקציונליות כוללים:
- TSG: קורס אימון לא פונקציונלי בן יומיים
- Udemy: Bootcamp השלם לבדיקות תוכנה לשנת 2023
- Edx: תעודת מקצוען לבדיקת תוכנה
- חינוכי: אוטומציה של בדיקות ביצועים 101
2. מהן 5 שאלות הראיון המובילות בנושא בדיקות לא פונקציונליות?
אם אתה מתכונן לראיון עבודה כדי לעבוד בבדיקות תוכנה, המראיין שלך עשוי לשאול אותך שאלות לגבי בדיקות לא פונקציונליות כדי לוודא שאתה מבין כיצד עובד השלב החיוני הזה של בדיקות תוכנה. התכונן לראיון שלך על ידי הכנת תשובות יעילות לשאלות נפוצות בראיון מראש.
● במה עשויות הגישות והשיטות שבהן אתה משתמש בבדיקות לא פונקציונליות להיות שונות מהגישות שבהן אתה משתמש בבדיקות פונקציונליות?
● במה שונה בדיקות לא תפקודיות מבדיקות תפקודיות?
● אילו סוגים שונים של בדיקות לא פונקציונליות קיימים?
● איך אתה נותן עדיפות לבדיקות פונקציונליות ומקרי בדיקה?
● באיזה שלב של בדיקות תוכנה מתבצעות בדרך כלל בדיקות פונקציונליות?
3. מדריכי YouTube הטובים ביותר על בדיקות לא פונקציונליות
אם אתה מעדיף ללמוד על ידי צפייה בסרטונים, ייתכן שתמצא מדריכי YouTube על בדיקות לא פונקציונליות דרך שימושית ללמוד עוד על סוג זה של בדיקות תוכנה.
להלן כמה מהמדריכים הטובים ביותר של YouTube בנושא בדיקות תוכנה הזמינים כיום.
מהי בדיקת תוכנה לא פונקציונלית? מדריך לבדיקת תוכנה
עזרה לבדיקת תוכנה: בדיקות לא פונקציונליות
בדיקות לא פונקציונליות בבדיקות תוכנה
בקר ב-W3Schools
בדיקה פונקציונלית ולא פונקציונלית
4. כיצד לשמור על בדיקות לא פונקציונליות
תחזוקה נכונה של בדיקות מבטיחה שניתן לחזור על בדיקות תוכנה מבלי להתפשר על איכות תוצאות הבדיקה.
על ידי שמירה על בדיקות לא פונקציונליות, אתה יכול להבטיח שהבדיקה בכל שלב בתהליך הפיתוח היא נאותה ושהבדיקות שלך מעודכנות תמיד בהתאם לקוד המשתנה כל הזמן.
אתה יכול לשמור על בדיקות לא פונקציונליות על ידי ביצוע הטיפים שלנו למטה.
● תקשורת ברורה בין צוות הבדיקות בעת יצירת מקרי בדיקה וכתיבת תיעוד
● פעל תמיד לפי נוהלי תכנון הבדיקה הטובים ביותר
● להעריך מחדש את פרוטוקולי הבדיקה בשלבים שונים של תהליך הבדיקה
● עדכן שינויים בבדיקה תוך כדי תנועה
שקול פרויקטים עתידיים בעת ביצוע שינויים בבדיקות הנוכחיות
5. האם בדיקה לא פונקציונלית היא קופסה שחורה או קופסה לבנה?
בדיקות לא פונקציונליות הן סוג של בדיקת קופסה שחורה, מה שאומר שהבודקים לא עוסקים בפעולה הפנימית של המערכת, אלא רק ביציאות החיצוניות שלה.
זה מנוגד לבדיקת קופסה לבנה, הבודקת את אופן פעולת המערכת הפנימית. דוגמאות לבדיקת קופסה לבנה כוללות בדיקת יחידות ובדיקות אינטגרציה.
בדיקות דרישות פונקציונליות ולא פונקציונליות הן דוגמאות לבדיקת קופסה שחורה. המשמעות היא שהבודקים אינם דורשים מיומנויות טכניות מתקדמות או ידע בתכנות מחשבים כדי לבצע בדיקות קופסה שחורה, וגם אינם צריכים ללמוד כיצד ליישם את המערכות שהם בודקים.
