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

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

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

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

דוגמה לבדיקת רגרסיה

כאן ניקח מקרה כדי להגדיר את בדיקת הרגרסיה ביעילות:

שקול מוצר Y, שבו אחת הפונקציונליות היא הפעלת אישור, קבלה ושליחה של מיילים. זה גם צריך להיבדק כדי לוודא שהשינוי בקוד לא השפיע עליהם. נסיגת בדיקה לא תלויה בשום שפת תכנות כמו Java , C++ , C# , וכו'. שיטה זו משמשת כדי לבדוק את המוצר עבור שינויים או עדכונים כלשהם שנעשו. זה מבטיח שכל שינוי במוצר לא ישפיע על המודול הקיים של המוצר. ודא שהבאגים תוקנו והתכונות החדשות שנוספו לא יצרו שום בעיה בגרסת העבודה הקודמת של התוכנה.

מתי נוכל לבצע בדיקות רגרסיה?

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

אנו יכולים לבצע בדיקות רגרסיה בתרחיש הבא, אלה הם:

1. כאשר פונקציונליות חדשה הוספה לאפליקציה.

דוגמא:

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

2. כאשר יש דרישת שינוי.

דוגמא:

זכור שהסיסמה הוסרה מדף הכניסה שהייתה רלוונטית בעבר.

3. כאשר הפגם תוקן

דוגמא:

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

4. כשיש בעיה בביצועים תקן

דוגמא:

טעינת דף בית אורכת 5 שניות, מה שמפחית את זמן הטעינה ל-2 שניות.

5. כשיש שינוי סביבה

דוגמא:

כאשר אנו מעדכנים את מסד הנתונים מ-MySql ל-Oracle.

כיצד לבצע בדיקת רגרסיה?

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

ניתן לבצע בדיקת רגרסיה באמצעות הטכניקות הבאות:

1. בדוק שוב הכל:

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

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

2. בחירת מבחן רגרסיה:

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

3. תעדוף מקרי מבחן:

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

מהם הכלים לבדיקת רגרסיה?

בדיקת רגרסיה היא חלק חיוני מתהליך ה-QA; במהלך ביצוע הרגרסיה אנו עשויים להתמודד עם האתגרים הבאים:

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

תהליך בדיקת רגרסיה

ניתן לבצע את תהליך בדיקת הרגרסיה ברחבי בונה וה משחרר .

בדיקות רגרסיה על פני המבנה

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

לדוגמה , כיצד אנו מבצעים את בדיקת הרגרסיה אם יש לנו מבנה שונה כמו Build 1, Build 2 ו-Build 3 , שיש להם תרחישים שונים.

בנייה 1

• ראשית הלקוח יספק את צרכי העסק.
• ואז צוות הפיתוח מתחיל לפתח את התכונות.
• לאחר מכן, צוות הבדיקות יתחיל לכתוב את מקרי הבדיקה; לדוגמה, הם כותבים 900 מקרי בדיקה עבור ההפצה מס' 1 של המוצר.
• ואז, הם יתחילו ליישם את מקרי הבדיקה.
• לאחר שחרור המוצר, הלקוח מבצע סבב אחד של בדיקת קבלה.
• ובסופו של דבר, המוצר מועבר לשרת הייצור.

בנייה2

• כעת, הלקוח מבקש להוסיף 3-4 תכונות נוספות (חדשות) וכן מספק את הדרישות לתכונות החדשות.
• צוות הפיתוח מתחיל לפתח תכונות חדשות.
• לאחר מכן, צוות הבדיקות יתחיל לכתוב את מקרה הבדיקה עבור הפיצ'רים החדשים, והם כותבים כ-150 מקרי בדיקה חדשים. לכן, המספר הכולל של מקרה המבחן שנכתב הוא 1050 עבור שתי המהדורות.
• כעת צוות הבדיקות מתחיל לבדוק את התכונות החדשות באמצעות 150 מקרי בדיקה חדשים.
• לאחר שזה יסתיים, הם יתחילו לבדוק את התכונות הישנות בעזרת 900 מקרי בדיקה כדי לוודא שהוספת הפיצ'ר החדש פגעה בתכונות הישנות או לא.
• כאן, בדיקת התכונות הישנות ידועה בשם בדיקות רגרסיה .
• לאחר שנבדקו כל התכונות (חדש וישן), המוצר מועבר ללקוח, ולאחר מכן הלקוח יבצע את בדיקת הקבלה.
• לאחר ביצוע בדיקת הקבלה, המוצר מועבר לשרת הייצור.

בנייה 3

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

הערה:

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

בדיקת רגרסיה על פני השחרור

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

כדי להבין את תהליך בדיקת הרגרסיה, נבצע את השלבים הבאים:

שלב 1

אין בדיקות רגרסיה ב שחרור מס' 1 כי לא קרה שום שינוי במהדורה מס' 1 שכן הגרסה חדשה בעצמה.

שלב 2

הרעיון של בדיקת רגרסיה מתחיל מ שחרור מס' 2 כשהלקוח נותן קצת דרישות חדשות .

שלב 3

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

שלב 4

f סרטים

לאחר הבנת הדרישות החדשות, נבצע סבב אחד של ניתוח השפעה כדי להימנע מהסיכון הגדול, אבל כאן נשאלת השאלה מי יבצע את ניתוח ההשפעה?

שלב 5

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

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

שלב 6

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

שלב 7

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

שלב 8

ברגע שמוביל המבחן יקבל את הדוחות #, הוא/היא יקבל לְגַבֵּשׁ הדוחות ומאוחסנים ב מאגר דרישות מקרי בדיקה לשחרור מס' 1.

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

שלב 9

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

הערה:

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

שלב 10

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

שלב 11

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

סוגי בדיקות רגרסיה

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

1. בדיקת רגרסיה של יחידה [URT]
2. בדיקת רגרסיה אזורית[RRT]
3. בדיקת רגרסיה מלאה או מלאה [FRT]

1) בדיקת רגרסיה של יחידה [URT]

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

דוגמה1

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

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

דוגמה2

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

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

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

2) בדיקת רגרסיה אזורית [RRT]

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

לדוגמה:

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

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

רשימה ריקה java

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

בְּעָיָה:

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

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

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

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

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

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

פִּתָרוֹן

כדי לפתור את הבעיה שלעיל, נבצע את התהליך הבא:

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

כאשר יגיע בנייה חדשה, צוות הבדיקה יבצע את ההליך הבא:

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

חסרון בשימוש בבדיקת יחידה ורגרסיה אזורית

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

• אנחנו עלולים להחמיץ איזור השפעה.
• ייתכן שנזהה את אזור ההשפעה הלא נכון.

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

3) בדיקת רגרסיה מלאה [FRT]

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

לכן, אנו יכולים לומר כי בדיקת ה תכונות ששונו ו כל התכונות הנותרות (הישנות). נקרא ה בדיקת רגרסיה מלאה .

מתי אנחנו מבצעים בדיקות רגרסיה מלאה?

אנו נבצע את ה-FRT כאשר יהיו לנו התנאים הבאים:

• כאשר השינוי מתרחש בקובץ המקור של המוצר. לדוגמה , JVM הוא קובץ השורש של אפליקציית JAVA, ואם עומד לקרות שינוי כלשהו ב-JVM, כל תוכנית ה-JAVA תיבדק.
• כאשר עלינו לבצע מספר n של שינויים.

הערה:

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

וכאן אנחנו הולכים לפתור את הבעיה בעזרת הגישה הבאה:

• כאשר תינתן הבקשה לבדיקה, מהנדס הבדיקה יבדוק את המחזור הראשון של 10-14, ויבצע את RRT .
• ואז עבור המחזור ה-15, אנחנו עושים FRT. ושוב, למחזור 10-15 הבא, אנחנו עושים זאת בדיקת רגרסיה אזורית , ולמחזור ה-31, אנחנו עושים את בדיקת רגרסיה מלאה , ונמשיך כך.
• אבל בעשרת המחזורים האחרונים של השחרור, אנחנו נבצע רק בדיקת רגרסיה מלאה .

לכן, אם נפעל לפי הגישה שלעיל, נוכל לקבל יותר פגמים.

החיסרון של ביצוע בדיקות רגרסיה באופן ידני שוב ושוב:

• הפריון תקטן.
• זו עבודה קשה לביצוע.
• אין עקביות בביצוע הבדיקה.
• וגם זמן ביצוע הבדיקה גדל.

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

תהליך בדיקת רגרסיה אוטומטי

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

תהליך בדיקת רגרסיית האוטומציה יכול להיעשות בשלבים הבאים:

הערה 1:

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

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

כאן, ניתן לבצע את הכניסה בשתי דרכים, שהן כדלקמן:

באופן ידני: בכך נבצע רגרסיה רק ​​פעם אחת ופעמיים.

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

הערה 2: בזמן אמת, אם התמודדנו עם כמה בעיות כגון:

שלב 1

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

שלב 2

כשהמהדורה החדשה והשיפור מתחילים, יש לנו שני צוותים, כלומר, צוות ידני וצוות האוטומציה.

שלב 3

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

שלב 4

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

שלב 5

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

שלב 6

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

שלב 7

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

שלב 8

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

שלב 9

לאחר השלמת הביצוע, אנו מקבלים סטטוס שונה כמו עובר/נכשל .

שלב 10

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

שלב 11

תהליך זה נמשך עד לכל התכונות החדשות, ותכונת הרגרסיה תעבור.

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

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

כיצד לבחור מקרי מבחן לבדיקת רגרסיה?

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

מבחן רגרסיה יכול להתבצע על ידי:

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

כלים לבדיקת רגרסיה

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

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

סֵלֶנִיוּם

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

סטודיו רנורקס

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

מקצוען בדיקה מהירה (QTP)

סוג תאריך בכתב כתיבה

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

בודק פונקציונלי רציונלי (RTF)

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

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

https://www.javatpoint.com/automation-testing-tool

בדיקות רגרסיה וניהול תצורה

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

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

הבדלים בין בדיקה חוזרת לבדיקת רגרסיה

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

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

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

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

ההבדלים בין בדיקה חוזרת לבדיקת רגרסיה הם כדלקמן:

יתרונות בדיקת רגרסיה

היתרונות של בדיקת רגרסיה הם:

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

החסרונות של בדיקת רגרסיה

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

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

סיכום

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

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