בדיקות תוכנה עקרונות

בדיקות תוכנהעקרונות מהדורה 12

רשימת הנושאים • מבוא כללי • מצב קיים • מצב רצוי • מתודולוגיה • מסמך STP • טכניקות מהדורה 12

תפקידו של מנתח המערכות

ההבדל בין QA ו QC QA QC

לאבד את זה לאבד את משחק טכנולוגית הבדיקות פירושו לאבד את משחק האיכות ומשמעותו לאבד את משחק התוכנה לאבד את משחק התוכנה פירושו לאבד את משחק ה hi-tech ומשמעותו איבוד העסקים והמשרות שלנו (B. Beizer)

לאבד את זה 21/03/2007

לאבד את זה 21/11/2007

לאבד את זה

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

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

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

מהיכן צומחות השגיאות • דרישות לקויות 56% • עיצוב לקוי 27% • שגיאות אחרות 10% • שגיאות תכנות7%

ווטס המפרי • לאור בדיקה של 13,000 תוכנות • מתכנת מומחה עושה בין 100 ל 150 טעויות בכל 1000 שורות קוד

מקורות ידע • לחפש באגים-אוריאלה כהן • אתר הידע P2080 : פרק הבדיקות • Testing Computer Software, 2nd Edition: Cem Kaner • Lessons Learned in Software TestingBach: • ארגון ISTB

רשימת הנושאים • מבוא כללי • מצב קיים • מצב רצוי • מתודולוגיה • מסמך STP • טכניקה

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

הבדיקות כבעיה פסיכולוגית • מי לא עושה שגיאות • כמה שגיאות נותרו • מי יכול לגלות שגיאות • מה קורה כאשר מתקנים שגיאות • מי אוהב מגלי שגיאות- האם דוח שגיאות מהלקוח הוא מתנה? פגם כשל שגיאה Defect Failure Error תוצאה בפועל ≠ תוצאה צפויה פגם בקוד מקור אנושי של הבעיה

Fixing Bug Costגרף בוהם- Unit test Req Design Coding Int. test Sys. test Operation

חלוקה אופינית של ההשקעה בפיתוח ניתוח ועיצוב 40% בדיקות וניפוי 30% פיתוח 30%

עקרון 20/80 בבדיקות • 80 אחוז מהבגים מסתתרים ב 20 אחוז מהתוכנה • 80 אחוז מבעיות הביצועים מסתתרים ב 20 אחוז מהתוכנה • 80 אחוז מהסיכונים מסתתרים ב 20 אחוז מהתוכנה • 80 אחוז מבעיות הUsability מסתתרים ב 20 אחוז מהמימשק • 80 אחוז מהבדיקות החשובות ניתנות לביצוע עם 20 אחוז מהנתונים

רשימת הנושאים • מבוא כללי • מצב קיים • מצב רצוי • מתודולוגיה • מסמך STP • טכניקה

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

מניעת שגיאות • מניעת Bug היא תמיד עדיפה על Bug שנתגלה ותוקן • ברב המקרים עלות המניעה הרבה יותר זולה מאשר עלות הגילוי והתיקון

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

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

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

רשימת הנושאים • מבוא כללי • מצב קיים • מצב רצוי • מתודולוגיה • מסמך STP • טכניקות

מחזור חיים בדיקות תוכנה-IEEE829

תכנון-STP • הגדרת מדיניות הבדיקות • הגדרת סיכונים • הגדרת מטרות הבדיקות • הגדרת רמות הבדיקה • לו"ז • משאבים • תקנים: נוהל מפתח, IEE829

ניתוח ועיצוב-STD • ניתוח בסיס הבדיקות(Test basis) • פירוט מקרי בדיקה ,נתוני בדיקה ותוצאות צפויות • תעדוף מקרי הבדיקה • תכנון הקמת סביבת הבדיקות • יצירת עקביות בין בסיס הבדיקות למקרי הבדיקה • תכנון מנות בדיקה(Test Suits)

בצוע • הכנת הליכי בדיקהTest procedures)) • הרצת מקרי הבדיקה • השוואת תוצאות בפועל מול התוצאות הצפויות • ניתוח ודיווח על התקלות(בכלי תוכנה מתאים) • ביצוע בדיקות חוזרות(רגרסיה)

בדיקת מימוש תנאי סף ודיווח • בדיקת מימוש התנאי לסיום הבדיקות בהתאם להגדרה ב STP • כתיבת STR

פעילויות סיום • בדיקת תוצרי פרויקט הבדיקות(STP STD STR ) • השלמת רכיבי הבדיקות והעברתם לצוות תחזוקה • הפקת לקחים

בקרה-בדיקת תכנון מול ביצוע • מדידה וניתוח תוצאות • מעקב אחר רמת כיסוי • ייזום פעולות מתקנות • עדכון ה STP על פי הצורך

שילוב תהליך הפיתוח והבדיקות "מודל V"-קלאסי תיקוף-Validation בדיקות קבלה דרישות לקוח אפיון בדיקות מערכת עיצוב בדיקות אינטגרציה בדיקות סטטיות Verification בדיקות דינמיות בדיקות יחידה UNIT מפרטי רכיבים קידוד פיתוח

הפעילויות העיקריות של מהנדסי בדיקות • הכנת תוכנית בדיקות: STP • הכנת סביבת בדיקות • עיצוב הבדיקות: STD • הכנת נתוני הבדיקות • ביצוע הבדיקות • הכנת דוח בדיקות: STR • ניהול וסיווג תקלות ((Bug Tracking

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

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

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

תבנית תסריט בדיקה מטרה

כלי בדיקות • Test management and testing progress tracking • Defects tracking • Transactions generators • Support preparation of test data • Automate GUI regression tests • Static analyzers • Dynamic analyzers of memory use and coverage criteria

בדיקות קופסא לבנה • Static • Code Inspection • Complexity Analysis • Loop Analysis • Data Flow Analysis • Dynamic • Coverage Analysis • Memory Usage Analysis

רשימת הנושאים • מבוא כללי • מצב קיים • מצב רצוי • מתודולוגיה • מסמך STP • טכניקות

מסמך תכנית הבדיקות STP Software Test Plan לפי נוהל מפת"ח

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

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

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

בדיקות תוכנה עקרונות