Quantcast
Channel: בלוגים המדוברים
Viewing all articles
Browse latest Browse all 25516

מודל פיתוח ושילוב הבדיקות בתוכו V MODEL- מודל וי

$
0
0

"מודל הוי" - V model הינו מודל פיתוח המתאר את פעילויות מחזור חיי הפיתוח של המערכת או התוכנה החל ממפרט הדרישות ועד לשלב התחזוקה.

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

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

רמות הפיתוח ורמות הבדיקה בהתאמה הינן:

·         ניתוח הדרישות מצד הפיתוח אל מול בדיקות קבלה בצד הבדיקות.

·         עיצוב המערכת מצד הפיתוח אל מול בדיקות המערכת בצד הבדיקות.

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

·         עיצוב היחידות הבודדות/ מודולים וקידוד מצד הפיתוח אל מול בדיקות היחידה בצד הבדיקות.

 

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

 

יתרונות שימוש במודל מנקודת מבט של הבדיקות ושל הפרויקט בכלל:

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

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

 

עתה אסקור כל אחת מפעולות הבדיקות על פי מודל זה.

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

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

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

בדרך כלל, ככל שהיקף המערכות גדולות יותר כך קשה יותר לבודד את התקלות.

 

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

 

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

 

ניתן לקרוא עוד על מודל זה בויקיפדיה.

תרשים V model


Viewing all articles
Browse latest Browse all 25516


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>