בדיקה שלילית בבדיקות תוכנה היא טכניקה המאמתת כיצד האפליקציה שלך מגיבה להתנהגויות לא צפויות או לנתונים לא חוקיים. סוג זה של בדיקות יכול לעזור לצוותי אבטחת איכות לשפר את החוסן והיציבות של התוכנה שלהם על ידי חיפוש חריגים שגורמים להקפאה, קריסות או תוצאות לא רצויות אחרות.
במאמר זה, נחקור מהי בדיקת תוכנה שלילית, מדוע היא חשובה וכמה מהגישות, הטכניקות והכלים השונים שבהם תוכל להשתמש לטכניקה זו.
מהי בדיקת תוכנה שלילית?
בדיקה שלילית היא טכניקת בדיקת תוכנה שמזינה מערכת בכוונה עם תשומות לא חוקיות או נתונים בלתי צפויים כדי לראות כיצד היא מטפלת בתרחישים אלו. הידועה גם כבדיקת כשל או בדיקת נתיב שגיאה, גישה זו מדמה את מגוון התרחישים בעולם האמיתי שהאפליקציה שלך תיתקל בהם, כגון משתמשים שמזינים תאריכים או תווים לא חוקיים או שימוש בפונקציות מסוימות בדרכים שמעולם לא התכוונת.
רוב סוגי הבדיקות משתמשים בנתונים חוקיים כדי לבדוק אפליקציה. עם זאת, בדיקות שליליות נוקטות בגישה שונה על ידי בדיקה סביב הקצוות ומעבר לתשומות טיפוסיות ולראות כיצד היישום מטפל בחריגים.
חשוב לבדוק שהאפליקציה שלך פועלת כמתוכנן. אבל, מהצד השני, ההבנה מה קורה כאשר משתמשים יוצאים מההזמנה היא חיונית, במיוחד אם השימושים הלא מכוונים הללו גורמים לקריסות, הקפאה או פגמים אחרים.
ההבדל בין בדיקה חיובית לשלילית
בדיקות בבדיקות תוכנה
כפי שתיארנו לעיל, בדיקות שליליות משתמשות בנתונים בלתי צפויים או לא חוקיים כדי לאמת את ההתנהגות של מערכת. לעומת זאת, בדיקה חיובית דוחפת נתונים צפויים או חוקיים כדי לוודא שהמערכת פועלת כמצופה.
במילים אחרות:
- בדיקה חיובית עוזרת לך להבין אם היישום שלך עובד כמתוכנן
- בדיקה שלילית קובעת אם האפליקציה שלך יכולה להתמודד עם אירועים בלתי צפויים
הן בדיקות חיוביות והן בדיקות שליליות בבדיקות תוכנה נדרשות אם ברצונכם לבדוק את האפליקציה שלכם בקפדנות.
מדוע בדיקת תוכנה שלילית חיונית?
כאשר מפתחים בונים תוכנה, יש להם מושג ברור כיצד הם מצפים מהמשתמש להשתמש בתוכנה. עם זאת, משתמשים לא תמיד פועלים לפי הכללים. לעתים קרובות הם ינסו ללחוץ על כפתורים שאינם קיימים, להזין אותיות בשדות מספרים, או לנסות קלט שפשוט לא ציפיתם.
בדיקות שליליות שואפות להביא בחשבון את מקרי הקצה הללו שלא ניתן לגלות על ידי טכניקות בדיקה חיוביות כמו בדיקות יחידה , מערכת או אינטגרציה. זה דורש קצת חשיבה לא שגרתית כדי להמציא “כדורי עקומה” לזרוק על המערכת. עם זאת, התוצאה נטו היא יישום יציב וחזק יותר.
מה המטרה של בדיקה שלילית
בבדיקות תוכנה?
לבדיקות שליליות יש מטרות דומות לאלו של סוגים אחרים של בדיקות תוכנה. כלומר, לחשוף באגים, פגמים ופגיעויות באפליקציה. עם זאת, הוא ממלא תפקיד מיוחד במציאת פגמים שלא ניתן לחשוף באמצעות שימוש בנתונים תקפים. הנה כמה מהסיבות לאמץ גישת בדיקה שלילית.
1. חשיפת פגמים
המטרה המרכזית של בדיקות שליליות בבדיקות תוכנה היא לחשוף פגמים הנובעים מנתונים לא חוקיים או תשומות בלתי צפויות. זה מאפשר לבודקים לנקוט בגישה פרואקטיבית יותר לאיתור באגים ולהבטיח שהתוכנה עומדת בציפיות.
2. אבטחה
קלט בלתי צפוי או נתונים לא חוקיים עלולים לחשוף פרצות אבטחה. בדיקה ופתרון מקרי קצה אלו מובילים ליישום מאובטח וחזק יותר על ידי צמצום האפשרות להתקפות זדוניות, פגמים בהזרקה או ניסיונות גישה לא מורשית.
3. טיפול בשגיאות
בדיקה שלילית שימושית לאימות טיפול בשגיאות. זה לא רק להבטיח שהמערכת תישאר יציבה לאחר מפגש עם קלט או נתונים בלתי צפויים אלא גם על האופן שבו היא מגיבה לאירועים אלה, כגון הפקת הודעות שגיאה כדי להבטיח שמשתמש הקצה יודע שהנתונים אינם חוקיים.
4. שיפור כיסוי הבדיקה
בדיקות חיוביות ושליליות בבדיקות תוכנה משלימות מאוד. שניהם מכסים אלמנטים שונים של קלט נתונים, מה שאומר שהבדיקה שלך מקיפה יותר.
5. חווית משתמש טובה יותר
בדיקות שליליות עוזרות לגלות את המקור להודעות שגיאה, קריסות והתנהגויות בלתי צפויות אחרות שעלולות להשפיע לרעה על חווית המשתמש.
הבדל בין חיובי לשלילי
בדיקות בהנדסת תוכנה
כפי שהזכרנו לעיל, בדיקה שלילית שולחת נתונים בלתי צפויים או לא חוקיים כדי לאמת את ההתנהגות של מערכת. בדיקה חיובית, לעומת זאת, שולחת נתונים צפויים או חוקיים כדי לוודא שהמערכת פועלת כמצופה.
ההבדל בין בדיקה חיובית לשלילית כולל:
1. מטרות:
בדיקה חיובית מוודאת אם התוכנה פועלת כמתוכנן; בדיקות שליליות מבקשות להבין מה קורה בתרחישים לא מכוונים.
2. נתונים:
בדיקה חיובית משתמשת בנתונים חוקיים, ובדיקה שלילית משתמשת בקלט לא חוקי, ערכים קיצוניים ופורמטים בלתי צפויים.
3. התמקדות:
בדיקה חיובית מתמקדת בתרחישי הצלחה, בעוד שבדיקות שליליות עוסקות יותר בתרחישים לא מוצלחים.
סוגים שונים של בדיקות שליליות
בדיקה שלילית היא מושג המכסה מספר גישות שונות לאימות האיכות והשלמות של אפליקציה. להלן שבעה סוגים של בדיקות שליליות שאתה צריך לדעת.
#1. בדיקת ערך גבול
בדיקת ערך גבול מבקשת לבדוק את התוכנה עם כניסות שנמצאות בגבולות או בקצוות של טווח הקלט. הוא בודק את הערכים המקסימליים והמינימליים הצפויים, אך גם בודק רק מעבר לכניסות אלה.
דוגמא: שדה קלט מקבל מספרים בין 1-9. בדיקת ערך גבול תזין גם 1 וגם 9 אבל גם מבחן 0 ו-10.
#2. בדיקת ערך קלט
בדיקת ערך קלט קובעת כיצד המערכת תגיב לכניסות בלתי צפויות או לא חוקיות. חלק מהכניסות שהוא יבדוק כוללים:
- סוגי נתונים שגויים
- ערכים מחוץ לטווח
- תווים מיוחדים
- שדות ריקים.
דוגמה: תיבת קלט דורשת מספר בלבד, כך שהבדיקה תזין אות ותראה כיצד המערכת מגיבה.
#3. בדיקת עומס
בדיקת עומס מסייעת לבודקים להעריך כיצד המערכת תגיב תחת לחץ או עומסים כבדים, כגון מערכי נתונים גדולים או נפחי תעבורה גבוהים. כלי אוטומציה לבדיקה יכולים לדמות תנאים קיצוניים אלה כדי להבין כיצד המערכת מגיבה תחת כפייה.
דוגמה: הבוחן ידמה אלפי משתמשים בו-זמנית ניגשים לאתר.
#4. בדיקת חריגים
סוג זה של בדיקה בוחן כיצד המערכת תגיב לאירועים או שגיאות חריגים. חלק מהבדיקות כוללות
- מדמיית קריסות מערכת
- כשלים ברשת
- שגיאות במסד נתונים
- בעיות שטח דיסק
- חסרים קבצים.
דוגמה: הבדיקה עשויה לחקור מה קורה כאשר משתמש מוריד קובץ מהאפליקציה, והאינטרנט מנותק.
#5. בדיקות אבטחה
בדיקות אבטחה משתמשות בגישת בדיקה שלילית כדי להדגיש ולהבין נקודות תורפה בתוכנה שעלולות להיחשף על ידי קלט לא חוקי או בלתי צפוי. גישה זו בודקת התקפות נפוצות, כגון:
- הזרקת SQL
- סקריפטים חוצי אתרים (XSS)
- המאגר עולה על גדותיו.
דוגמה: בדיקת אבטחה עשויה לנסות להחדיר קוד זדוני לשדה קלט של משתמש.
#6. בדיקת ממשק משתמש
סוג זה של בדיקה מתמקד בשגיאות המתרחשות כאשר המשתמש מקיים אינטראקציה עם התוכנה. חלק מהדברים שהוא ינסה לקבוע כוללים:
- תגובות לא צפויות לאינטראקציות של משתמשים
- הודעות שגיאה שגויות
- בעיות ניווט
דוגמה: הבדיקה תחקור מה קורה כאשר פעולות מסוימות מבוצעות מחוץ לרצף.
#7. בדיקת שלמות נתונים
בדיקת שלמות הנתונים מבטיחה שהנתונים יישארו מדויקים ועקביים במגוון פעולות בתוך האפליקציה. חלק מהדברים הנבדקים כוללים:
- השחתות נתונים אפשריות
- תרחישי אובדן נתונים
- שינויים בנתונים בשוגג
דוגמה: הבדיקה תוודא שהנתונים נשארים זהים לאחר שידור.
כפי שאתה יכול לראות, יש הרבה גישות בדיקות שליליות שונות. המשותף לכולם הוא השימוש בקלט בלתי צפוי או בנתונים לא חוקיים כדי לראות כיצד האפליקציה פועלת בתנאים לא טיפוסיים.
יתרונות של בדיקה שלילית
בדיקה שלילית עוסקת בהבנת אופן הפעולה של האפליקציה שלך כאשר מתעוררים מצבים בלתי צפויים. להלן כמה מהיתרונות העיקריים של שימוש בגישה זו.
- זה עוזר לך להבין את ההשפעה שתהיה לקלט בלתי צפוי או נתונים לא חוקיים על היישום שלך. זה יקרוס? פלט הודעת שגיאה לא מדויקת?
- בדיקה שלילית היא חלק מגישה אחראית של אבטחת איכות מכיוון שהיא שואפת לזהות חולשות במערכת
- בדיקות שליליות מעמידות את התוכנה בקצביה על ידי בדיקת תגובתה לתרחישים בלתי צפויים או בלתי צפויים שהיא תיתקל בהם בטבע
- שוב, בדיקות שליליות הן מרכיב חיוני בגישה יסודית לאבטחה מכיוון שהיא מדגישה וקטורי תקיפה פוטנציאליים שתוקפי סייבר עשויים לנצל אותם.
חסרונות של בדיקה שלילית
בדיקות שליליות מציעות שפע של יתרונות, אבל יש לה כמה חסרונות שיש להתגבר גם עליהם.
- בדיקות שליליות יסודיות יכולות לדרוש חומרה ותוכנה נוספים, מה שיכול להגדיל את עלויות הבדיקה. עבור צוותים הפועלים בתקציב מצומצם, זה יכול להיות חסרון.
- בדיקה שלילית יכולה להיות די גוזלת זמן מכיוון שהיא דורשת יצירת מקרי בדיקה רבים כדי לכסות את התמורות השונות של תשומות שהתוכנה תתמודד מולן בייצור
- יש גבולות לכמות המצבים הבלתי צפויים שאתה יכול לכסות בבדיקות שליליות. אכן, מצבים מסוימים עשויים להיות כל כך בלתי צפויים עד שהבודקים לא יכולים לשקול אותם.
- אוטומציה של מקרי מבחן שליליים היא מאתגרת. עם זאת, עם התוכנה הנכונה, כגון ZAPTEST, התהליך הרבה יותר ניתן לניהול.
אתגרים של בדיקות שליליות
בדיקות שליליות הן קריטיות אם ברצונך לבנות תוכנה חזקה ואמינה המסוגלת לעמוד בלחצים ובמתחים של אינטראקציה עם המשתמש. עם זאת, יש כמה אתגרים ביישום הגישה שאתה צריך להיות מודע אליהם.
בואו נפרק כמה מהאתגרים היותר מתמידים.
1. זיהוי תרחישים שליליים בבדיקות תוכנה
כיסוי מספיק:
אחד האתגרים הגדולים ביותר בבדיקות שליליות הוא להבטיח שתכסה מספיק תרחישים בלתי צפויים. יש הרבה תרחישים ותמורות שליליות, כך שבחינת כולם דורשת נקיטת גישה יצירתית כדי לדמיין כיצד המשתמשים שלך יתקשרו עם התוכנה.
תעדוף:
עם כל כך הרבה תרחישים שליליים פוטנציאליים לשים מתחת למיקרוסקופ, הבודקים לא תמיד בטוחים היכן עליהם להתחיל. כמה קריטריונים מוצקים להערכת מה לתעדף כוללים חיזוי:
- מצבים עם סבירות גבוהה לליקויים
- חומרת התוצאה של ליקויים.
2. תכנון מקרי מבחן שליליים נאותים
אימות קלט:
תכנון מקרי בדיקה שליליים מוצקים דורש הבנה מקיפה למדי של התנהגות המערכת, הארכיטקטורה והמגבלות של המערכת שלך. בדיקת התוכנה דורשת שימוש בתשומות ובנתונים שקולים בקפידה. אמנם נקיטת גישה אקראית יכולה לעזור לך לחשוף כמה פגמים, אך היא מחווירה בהשוואה לגישה מדויקת ושיטתית יותר לבדיקות שליליות.
מגוון נתונים:
בהתאם למאפיינים המיוחדים של המערכת שלך, ייתכן שתצטרך לבדוק מול סט נתונים מגוונים למדי. אכן, ישנם פורמטים רבים ושונים של נתונים, כגון מספרים, טקסט, תאריכים וכן הלאה, שכל אחד מהם עשוי לקבל. האתגר כאן כרוך בתכנון מקרי בדיקה שיכולים להסביר כל פורמט, ובפרט, כל וריאציה של נתונים לא חוקיים. מצב זה יכול להיות די גוזל זמן עבור צוותי בדיקה.
3. יעילות ואוטומציה של בדיקות
דורש זמן רב:
בדיקה חיובית נועדה לאמת את התוכנה מול התוצאות הצפויות. מבחן שלילי, לעומת זאת, חייב להתעמק בבלתי צפוי ולחקור תרחישים פוטנציאליים. מעבר על טריטוריה לא ידועה לוקח יותר זמן. כתוצאה מכך, אם אתה רוצה את התוצאות המקיפות שמגיעות עם בדיקות שליליות, עליך להיות מוכן להשקיע כמה שעות נוספות.
מורכבות האוטומציה:
בדיקות שליליות יכולות להיות עתירות זמן ומשאבים. ככזה, זוהי עבודה מושלמת עבור אוטומציה של בדיקות תוכנה. עם זאת, יש כמה מורכבויות שיש להתגבר עליהן. לדוגמה, תכנון מקרי בדיקה המגדירים תוצאות צפויות עבור תשומות בלתי צפויות דורש קצת ניסיון וידע. בנוסף, ייתכן שהמסגרת הקיימת שלך לבדיקות אוטומציה לא תתמוך בנתונים הלא חוקיים שברצונך לדחוף לאפליקציה שלך, מה שמוסיף שכבה נוספת של מורכבות.
4. הערכת תוצאות
חיובי שווא:
כיול הבדיקות שלך כדי להבטיח איזון משביע רצון בין דיוק לקיימות היא בעיה מוכרת עבור בודקים שליליים. במצבים מסוימים, טיפול בשגיאות רגיש יתר על המידה יבלבל באופן שקרי בין תשומות תקפות לתשומות שליליות, מה שיוביל לבזבוז זמן על בעיות שאינן רלוונטיות.
תוצאות לא ברורות:
כאשר מערכת מקבלת קלט לא חוקי, זה יכול לגרום לקריסות, שגיאות או הקפאה. במקרים רבים, זהו סימן בטוח לבאג. עם זאת, באחרים, מדובר בהוכחה למקרה קצה לא מטופל שהמפתחים לא שקלו. ההבחנה בין המצבים הבדידים הללו חשובה, אך חקירת הסיבה האמיתית גוזלת זמן.
ניהול נתונים:
בדיקה שלילית דורשת כמות לא מבוטלת של נתונים. מידע בדיקה זה חייב להיווצר ולתחזק. בתרחישי פיתוח עם לוחות זמנים צפופים, זוהי עבודה נוספת שיש לקחת בחשבון.
5. סוגיות ארגוניות
חוסר מומחיות בבדיקות שליליות:
בעוד שבדיקות שליליות פופולריות, בודקים רבים חסרים את הכישורים והמומחיות ליישם סוג זה של בדיקות בצורה מקיפה. עיצוב מקרי מבחן שליליים מסוימים הוא פחות אינטואיטיבי מאשר המקבילה למקרי מבחן חיוביים. יתרה מכך, הטמעת אוטומציה של בדיקות יכולה להיות גם מאתגרת ללא המומחיות הנכונה.
לחץ עסקי:
בעלי עניין, בודקים והנהלה חייבים להבין את התפקיד הקריטי שממלאות בדיקות שליליות בפיתוח יישומים חזקים. אי הערכת חשיבותו עלולה להוביל ללחץ להתמקד בבדיקות חיוביות במחיר של בדיקות שליליות.
ברור שיש כמה אתגרים שעומדים בפני צוותים שרוצים לנצל את היתרונות של בדיקות שליליות. עם זאת, עם הגישה הנכונה וכלי בדיקת התוכנה הנכונים, תוכלו להתגבר על בעיות אלו ולבנות תוכנה שעולה מעל ומעבר לציפיות המשתמשים.
איך כותבים מקרי בדיקות שליליים בתוכנה
כתיבת תוכנה הבודקת מקרי מבחן שליליים דורשת קצת ניסיון וחשיבה יצירתית. להלן מדריך שלב אחר שלב שיעזור לך לבנות את מקרי הבדיקה הקריטיים הללו.
#1. קבע את היעדים שלך
לפני שאתה כותב מקרי בדיקות שליליות בתוכנה שלך, עליך להבין מדוע אתה רוצה לבצע בדיקות שליליות. לא כל היישומים נהנים מבדיקות שליליות.
אז תבין מה אתה רוצה להשיג. בדיקות שליליות נועדו לחשוף שגיאות וקריסות הנובעות מתרחישים או מצבים בלתי צפויים של אינטראקציה עם המשתמש.
#2. תאר תרחישים שליליים פוטנציאליים
בשלב הבא, עליך לעשות חשבון על סוג התרחישים השליליים שעלולים להתרחש כאשר משתמשים מקיימים אינטראקציה עם התוכנה שלך. מחקר במהלך שלב זה הוא קריטי. כמה תחומים שכדאי לחקור הם:
- דרישות מערכת
- מקרי שימוש אופייניים
- תכונות ופונקציות של יישום
כרה את המצבים האלה וערוך רשימה של תרחישים שבהם ייתכן שהאפליקציה לא תפעל כפי שהתכוונת.
לאחר מכן, שקול תרחישים של אימות קלט קריטי. בדרך כלל, זה יכלול טפסי הזנת נתונים, שדות התחברות וכן הלאה.
לבסוף, שקול את שלל הדרכים הלא קונבנציונליות שבהן משתמשים עלולים לקיים אינטראקציה עם התוכנה שלך ואירועים בלתי צפויים שיכולים לייצר תוצאות שליליות, כמו ניתוקי רשת, כיבויים פתאומיים של מערכת, העברות נתונים מסיביות וכו’.
לאחר שתיעדת כמה שיותר תרחישים, הגיע הזמן לקבוע את התוצאות הצפויות של תרחישים בלתי צפויים אלה.
#3. תאר את התוצאות הצפויות
לכל מקרה מבחן חייבת להיות תוצאה צפויה, ומקרה מבחן שלילי אינו שונה. השיטה הטובה ביותר כאן היא לכתוב כל תרחיש שלילי ולקבוע מה צריכה להיות התוצאה.
חלק מהתוצאות הפוטנציאליות עשויות לכלול:
- הודעות שגיאה מדויקות ואינפורמטיביות
- הפניות מתאימות
- טיפול חינני במערכת, למשל, מניעת הקפאת מערכת או קריסות.
#4. בחר כניסות לבדיקה
עכשיו, הגיע הזמן לראות אילו כניסות אתה צריך לבדוק. תשומות אלו צריכות להיות אלו שסביר להניח שיגרמו לשגיאה או התנהגויות שליליות אחרות.
כמה כניסות שאתה צריך לכלול הן:
- ערכים מחוץ לטווח (ערכים שליליים בשדה גיל וכו’)
- נתונים לא חוקיים (אותיות בשדה מספרי וכו’)
- תווים או סמלים בלתי צפויים
- תווים מיוחדים
- מידע חסר
#5. כתוב את מקרי המבחן שלך
לאחר שאספתם את כל התרחישים שלכם, הגיע הזמן לכתוב את מקרי המבחן שלכם. כעת, עם בדיקות שליליות, יש מספר כמעט בלתי מוגבל של מקרי בדיקה שאתה יכול לכתוב. אחרי הכל, סוג זה של בדיקות עוסק במציאת מה קורה כשאנשים משתמשים בתוכנה בדרכים שלא התכוונת. עם זאת, מועדים מכתיבים לך לצמצם את רשימת המקרים הפוטנציאליים למצבים שסביר להניח שיגרמו לבעיות.
כמו תמיד, כתוב את מקרי המבחן שלך בשפה ברורה, תמציתית ואובייקטיבית. אין כאן מקום לעמימות.
הנה פורמט טוב למקרי הבדיקה השליליים שלך.
- השתמש במזהה מקרה מבחן
- תאר במדויק מה נבדק
- שים לב לכל התנאים המוקדמים למבחן השלילי שלך
- תאר את מערך השלבים המעורבים
- קבע תוצאות ברורות ואובייקטיביות
- רשום את התוצאה האמיתית של הבדיקה שלך
#6. תזמן את המבחן
עכשיו, אתה צריך לתזמן את הבדיקות שלך. שוב, חשוב לתעדף את התרחישים שיש להם את התוצאות השליליות החמורות ביותר, כגון קריסות, או היכן יש סיכוי גבוה יותר להתגלות בעיות.
מקרה מבחן שלילי לדוגמה
הנה דוגמה למקרה מבחן שלילי.
מזהה מקרה מבחן: TC001
תיאור: ודא שהודעת שגיאה מופיעה אם המשתמש מזין כתובת דוא”ל לא חוקית
תנאים מוקדמים: המשתמש חייב להיות בדף הכניסה לאפליקציה
שלבים: 1. הזן כתובת אימייל לא חוקית. 2. לחץ על “התחברות”
תוצאה צפויה: כאשר המשתמש לוחץ על “התחברות”, מתרחשת הודעת שגיאה, האומרת “כתובת אימייל שגויה הוזנה”.
תוצאה: רשום מה קרה כשנבחרה “התחברות”.
דוגמאות לתרחישים שליליים בבדיקות תוכנה
להלן כמה תרחישים אופייניים שתוכלו לאמת באמצעות שיטות בדיקה שליליות.
1. סוגי נתונים ושדה
אם מילאתם טופס מקוון, תדע שתיבות אלה מוגדרות לקבל סוגים מסוימים של נתונים. חלקם הם מספרים בלבד, בעוד שאחרים מקבלים תאריכים, טקסט או סוגים אחרים של נתונים.
בדיקה שלילית עבור תיבות אלה כוללת שליחת נתונים לא חוקיים, למשל, הזנת אותיות בשדה מספרי.
2. שדות חובה
שוב, שדות חובה הם מאפיינים נפוצים של טפסים ויישומים. הם כלי שימושי כדי להבטיח שכל המידע הקריטי נאסף לפני שהמשתמש ממשיך לשלב הבא.
מקרה מבחן טוב עבור תרחישים אלה כרוך לראות מה קורה כאשר שדות אלה נותרים ריקים. בתרחיש אידיאלי, יש להפעיל הודעת שגיאה, שקוראת למשתמש למלא את השדה הנדרש.
3. מספר תווים מתאים
אם יש לך יישום של דפי אינטרנט בבדיקה, ייתכן שיש לך שדה נתונים הדורש מספר מוגבל של תווים. זה יכול להיות עבור שמות משתמש, מספרי טלפון, מספרי רישום וכן הלאה.
אתה יכול ליצור מקרי בדיקה שליליים עבור שדות אלה על ידי כתיבת מבחנים שמזינים את התווים המרביים המותרים כדי לראות כיצד האפליקציה מגיבה.
4. גבולות ומגבלות נתונים
בטפסים מסוימים יהיו שדות עם מגבלות קבועות. לדוגמה, אם אתה רוצה שמישהו ידרג משהו מתוך 100, גבולות הנתונים יהיו 1-100.
צור מקרה מבחן שלילי שבו אתה מנסה להזין 0, 101 או ערכים שליליים או חיוביים אחרים מתוך 1-100.
שיטות עבודה מומלצות לבדיקות שליליות
ישנן מספר שיטות עבודה מומלצות המעורבות בהבטחת בדיקות שליליות באיכות גבוהה. הנה כמה טיפים שיעזרו לך להגיע לשם.
1. הגדר את התשומות הלא חוקיות שלך:
יש לשפוך על תיעוד פיתוח, מקרי שימוש ו-UI/UX כדי להבין ולזהות קלט פוטנציאלי לא חוקי. חפש סוגי נתונים לא חוקיים, ערכים קיצוניים, נתונים חסרים, שדות ריקים, פורמטים לא צפויים ועוד.
2. השתמש בניתוח ערכי גבול:
כפי שהוזכר לעיל, הגדר את ערכי הגבול שלך כדי למצוא מקרי קצה שעלולים לגרום לתגובות בלתי צפויות.
3. חלוקת שוויון עובדים:
תסתכל על תחומי הקלט שלך ופצל אותם למחיצות שקילות של ערכים חוקיים ובלתי חוקיים כאחד. תהליך זה עוזר להפחית את מספר מקרי הבדיקה שתצטרך לכתוב מכיוון שאם נתון שווה ערך של נתונים לא חוקיים גורם לבעיות עבור קלט אחד, סביר להניח שהוא יהיה מיוצג על פני כל המחלקה.
4. חיקו משתמשים רעים:
בדיקה חיובית מאמתת את התנהגות המשתמש הצפויה. בדיקה שלילית בודקת מה קורה כשאנשים משתמשים לרעה באפליקציה שלך. לכן, חשבו על התרחישים השונים שבהם זה יכול לקרות ושכפל אותם במקרי הבדיקה שלכם.
5. תן לסיכון ולהשפעה להנחות את הבדיקות שלך:
לאף בודק אין זמן בלתי מוגבל. בשלב מסוים, תצטרך לעשות בחירות קשות מכיוון שאינך יכול לבדוק (או אפילו לדעת) כל תוצאה בלתי צפויה. כאשר אתה צריך להחליט אילו סוגי בדיקות שליליות להפעיל, תעדוף את התחומים שיביאו את הסיכון או ההשפעה השלילית ביותר למוצר שלך.
6. שגיאה בטיפול באימות:
ודא שאתה עושה טיפול בשגיאות כחלק מהבדיקה שלך, וודא שהודעות השגיאה שימושיות ומדויקות.
7. אוטומציה ככל האפשר:
אוטומציה מיומנת בטיפול במשימות שגרתיות וחוזרות על עצמן. עם זאת, בדיקות שליליות עדיין דורשות גישה ידנית לבדיקות חקרניות ומציאת מקרי קצה.
כלי הבדיקה השליליים הטובים ביותר לשנת 2024
בעוד שבדיקות תוכנה שליליות נפוצות בכל התעשייה, יש חוסר בכלים מובהקים לתפקיד. סיבה גדולה לכך היא האופי הרב-תכליתי של בדיקות שליליות. יתרה מכך, רבים מאותם כלים המשמשים לבדיקות חיוביות עובדים עבור בדיקות שליליות כאשר אתה מכוון את נתוני הקלט.
ZAPTEST הוא הכלי הטוב ביותר לבדיקות שליליות בגלל אופיו הרב-תכליתי והמודולרי. זה קל לשימוש וניתן להתאמה אישית, ובזכות יכולות חוצות פלטפורמות ויישומים, הוא מציע גמישות שקשה לנצח אותה.
בדיקות מונעות נתונים ובדיקת מוטציות הפונקציונליות הופכת את ZAPTEST למושלם עבור בדיקות שליליות. מה שכן, בזכותו RPA תכונות, אתה יכול לדמות משתמשים בעולם האמיתי, לעשות שימוש חוזר בבדיקות ולבנות דוחות ותיעוד בקלות. בקצרה, היכולת של ZAPTEST להריץ אוטומציית תוכנה מתקדמת ותוכנת אוטומציה של תהליכים רובוטיים הופכת אותה לנקודה אחת לכל משימת אוטומציה, כולל בדיקות שליליות.
מחשבות אחרונות
בדיקות שליליות בבדיקות תוכנה עוזרות לצוותים להבין כיצד היישום שלהם יטפל בקלט בלתי צפוי ובנתונים לא חוקיים. בעוד בדיקות חיוביות בודקות אם התוכנה שלך מתפקדת כמתוכנן, בדיקות תוכנה שליליות עוזרות לך להבין מה קורה כאשר משתמשים בוחרים קלט ונתונים בצורה שגויה. שתי הגישות חשובות אם אתה רוצה יישום יציב וחזק שיכול להתמודד עם הלחצים והמתחים של אינטראקציה מגוונת של משתמשים.
