יום שלישי, 5 בפברואר 2008

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

יש שני סוגים של בדיקות וריפיקציה:
  1. "קופסה לבנה", white box. אלו בדיקות שבהן נדרש הבודק בידע תכנותי. עליו למצוא בעיות ולהביא את הסיבות להן. בד"כ אנשי הפיתוח עורכים בדיקות אלה.
  2. "קופסה שחורה", black box. בדיקות "חיצוניות" של האפליקציה מבלי להכנס לקוד.
בדיקות white box כוללות:
  1. בדיקות יחידה, unit tests. הכוונה היא שכשמוצר מורכב מכמה חלקים, כמו שבד"כ זה קורה, והיישומים כוללים אינטגרציה בין החלקים, אז קודם כל בודקים חלק חלק בנפרד.
    למשל נניח שהמוצר הוא אתר אינטרנט, והוא מורכב מחלק שקשור לבסיס נתונים, חלק שקשור ל-GUI או לממשק הגראפי וחלק שהוא מנוע חיפוש. אם מוסיפים יכולת למנוע החיפוש אלו שינויים בכל התחומים הללו: יש להוסיף את האפשרות למשתמש ב-GUI, לשדרג את אלגוריתם החיפוש ולשנות בהתאם את בסיס הנתונים. אז לפני שמחברים את הכל ביחד כל פונקציה פיתוחית מתאימה בודקת את החלק הרלונטי שלה. לזה אין בד"כ ממשק משתמש וגם לכן דרוש מפתח.
    סיבות ותועלת:
    א. תיקון באג בשלב הזה יעיל וחסכוני לאין שיעור ממציאתו בנקודות הבאות בתהליך (אינטגרציה, בדיקות וכו'). גם כי זה "טרי" אצל המפתח בראש, גם כי ברור שהבעיה היא בחלק שלו (מה שלא ברור תמיד במוצר הגמור), וגם אם יש שינוי שקשור לקומפוננטה אחרת זה המקום החסכוני לעשות זאת.
    ב. לבודק ייקח הרבה יותר זמן להבין ולשחזר את הבעיה.
  2. בדיקות אינטגרציה של היחידות (נקרא גם: Private Integration): בדיקות של החיבור בין המערכות, גם באחריות הפיתוח. על צוות הבדיקות לוודא שבדיקות האינטגרציה התבצאו במלואן, ואם משהו לא תוקן לקבל עליו מידע. מן הראוי שמהנדסי הבדיקות יעברו על מסמך הבדיקות של הפיתוח ויוסיפו אם צריך.
בדיקות black box כוללות:
  1. בדיקות אינטגרציה "חיצוניות": במקרים של מערכות גדולות שיש הרבה סיכון ברבדים הנמוכים של האפליקציה: התקנה מסובכת, דרייברים חדשים, חומרה חדשה וכו' לעתים יש צוות אינטגרציה בעל ידע ספציפי בתחומים הללו, לפעמים גם ידע תכנותי. היתרון: מציאה וטיפול מהיר בבעיות שלא תמיד יכולות להתגלות ע"י הבדיקות. גם הפיתוח מתייחס אליהם אחרת, מהר יותר, כי הבעיות שהם מגלים בד"כ קריטיות.
  2. בדיקות יוזביליות: לוודא את התאמת האפליקציה לדרך בה משתמשים בה משתמשי הקצה והאדמיניסטרטורים, ולא מאלצים את המשתמשים להתאים את עצמם לתוכנה.
    א. בדיקת קיום סטאנדארטים. אם לא הרשמיים שיוצאים ע"י האגודות, לפחות את הסטאנדרטים המקובלים.
    ב. גישתיות (Accessibility). האם המשתמשים יכולים לנווט ולצאת באופן אינטואיטיבי (או עם הסברים נאותים).
    ג. Responsiveness. האם המשתמשים יכולים למלא את רצונם, בזמן שהם רוצים ובצורה ברורה?
    ד. יעילות. האם המשתמשים יכולים למלא את רצונים במינימום צעדים וזמן?
    ה. הבנתיות. האם המשתמשים מבינים את מבנה המוצר, את מערכת העזרה ואת התיעוד שלה?
  3. בדיקות פונקציונליות:
    א. שימוש נכון במוצר. בדיקה של הדרישות: אם עושים X קורה Y.
    ב. שימוש שאינו נכון. לחיצות חוזרות ונשנות על אותו כפתור למשל.
    ג. בדיקות GUI. מיקום המסגרות, אי-חריגה בשל טקסט רק.
    ד. פעילויות של משתמש קצה. חשוב ביותר. למשל משתמש "רגיל" מתחבר, הולך למקום מסויים, עושה פעילות כזו או אחרת, חוזר, הולך למקום אחר וכד'.
    ה. שימוש אפקי, או זרימה. מתחיל תהליך מסויים עם המשתמש למשל, הוא מכניס מידע, וידוא שהמידע עובר נכון בכל נקודה, שהמערכת אח"כ משתמשת נכון במידע וכד'.
    ו. מקרי קצה. הכנסת ערכים גבוהים או שליליים או נמוכים, תמונה במקום של טקסט וכד'.
    ז. בדיקה שכל היישומים הרשומים בדרישות נכנסו (ברור למה) וגם מה שאינו שם לא נכנס (לכרואה יופי, עוד פונקציונליות, אבל אם זה לא רשום זה לא ייבדק כראוי ויביא לתלונות מרובות של המשתמשים).
    ח. אינטגרציה עם אפליקציות אחרות. אם המוצר שומר למשל קבצי אקסל, יש לפתוח ולראות תאימות.
  4. בדיקות מערכת:
    א. האם יש התראות לכל בעיה שצצה?
    ב. שימוש בבסיסי נתונים גדולים.
    ג. בדיקות עומס.
    ד. security.
    ה. ביצועים.
    ו. שימוש במשאבי מערכת.
    ז. התקנות.
    ח. recovery. של המערכת.
    ט. recovery. של נתונים.
    י. מהימנות. עבודה לאורך זמן.
    יא. רשיונות (גם של צד ג').
    יב. תאימות לדרישות.
    יג. האם זה באמת נותן ללקוח את הכלים שלהם הוא זקוק?
  5. acceptness tests או ATP, או GFAT. בדיקות סופיות של המוצר מהקיט הסופי. התקנה וריצה על פונקציונליות מרכזית, קיימת וחדשה.

3 תגובות:

  1. היי דורון,

    כמה דברים לא מובנים לי,
    אני רגיל לחלוקה (ככה למדתי) של:

    Functional tests
    Non-Functional tests

    אתה יכול להסביר את החלוקה שעשית למעלה ואיך זה מתיישב עם מה שמוכר לי (ושלמדתי בקורס ההסמכה)?

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

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

    תודה,
    יגאל

    השבמחק
  2. בדיקות פונקציונליות וכאלה שהן לא זו עוד דרך לחלוקה שיכולה להיות גם ב-white box וגם ב-black box. מכיוון שהסוג האחרון יותר מעניין אותי אומר שחלק 4 הוא לא פונקציונלי.

    יכולה להיות מערכת אחת שמחוברת לכמה מערכות אחרות. ניתן לבדוק כל התקנה נוספת בנפרד ואח"כ את כולן יחד. לדוגמא מורידים משחק שבדרך מתקין .net אח"כ כמה דרייברים ולבסוף direct x. בבדיקות מערכת הכוונה לבדיקה מקיפה של ההתקנה הראשית וכל שאר ההתקנות ביחד.

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

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

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

    מזה AVG?

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

    בכל אופן, הבנתי למה אתה מתכוון אבל לא בטוח שאני מסכים עם זה מאחר ובדיקות פונקציונליות יכולות בהרבה מקרים להיות גם בדיקות E2E, אם יש לך מערכת שמנטרת ביצועים בשכבות WEB, J2EE, DB או מביאה נתונים מהדפדפן וכו', הרי אם אתה בודק במקרים כאלה E2E שזה בעצם לבדוק את הפונקציונליות עצמה - העברת נתונים נכונה, נירמול שלהם, תקינות הנתונים, איך הם עוברים, איך הם מופיעים ב-GUI ועוד, האם אני טועה?

    תודה,
    יגאל

    השבמחק

רשומות פופולריות