ךמסומ קדוב סיסבה תמר...

בודק מוסמך

רמת הבסיססילבוס

2013.10מהדורה עברית טיוטת

באנגלית 1122מהדורה מבוססת על

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

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

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

1121מאי 12 85מ 1עמוד 2013.10מהדורה עברית

©International Software Testing Qualifications Board and Israel Testing Certification Board 1122על בסיס מהדורה אנגלית

הארגון הישראלי

להסמכת בודקי תוכנה

הארגון הבינלאומי


Copyright Notice כויות יוצריםז

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

Copyright Notice: This document may be copied in its entirety, or extracts made, if the source is acknowledged.

הארגון הישראלי להסמכת בודקי תוכנה© ITCBזכויות יוצרים

Copyright Notice ©Israel Testing Certification Board (hereinafter called ITCB®) ITCB is a registered trademark of the Israel Testing Certification Board

Copyright Notice © International Software Testing Qualifications Board (hereinafter called ISTQB©

) ISTQB is a registered trademark of the International Software Testing Qualifications Board.

1121.12שונה עריכת המהדורה העברית הרא 1121© זכויות יוצרים

)אבי עופר, בשיתוף עם מיכאל שטאלד"ר (

1121.21מהדורה העברית טיוטת העריכת 1121© זכויות יוצרים

)אבי עופרד"ר (

Copyright © 2013 the editor for the Hebrew Draft version 2013.21 (Dr. Avi Ofer)

Copyright © 2013 the editors for the first Hebrew version 2013.05 (Dr. Avi Ofer, in collaboration with Michael Stahl)

Copyright © 2011 the authors for the update 2011 (Thomas Müller (chair), Debra Friedenberg, and the ISTQB WG Foundation Level)

Copyright © 2010 the authors for the update 2010 (Thomas Müller (chair), Armin Beer, Martin Klonk, Rahul Verma)

Copyright © 2007 the authors for the update 2007 (Thomas Müller (chair), Dorothy Graham, Debra Friedenberg and Erik van Veenendaal)

Copyright © 2005, the authors (Thomas Müller (chair), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson and Erik van Veenendaal)

All rights reserved.

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

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

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

של הסילבוס העברי, ובלבד שכל פרסומת מוזכרים בתור המקור ובעלי זכויות היוצרים ISTQB-ו ITCB, העברית

לשם הסמכה רשמית ITCB-לקורס כזה תזכיר את הסילבוס רק לאחר שחומרי ההדרכה נמסרו ל

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

.זכויות היוצרים של המהדורה העבריתמוזכרים כמקור וכבעלי ISTQB-ו ITCB, המהדורה העברית

The authors hereby transfer the copyright to the International Software Testing Qualifications Board (ISTQB). The authors (as current copyright holders) and ISTQB (as the future copyright holder) have agreed to the following conditions of use:

1. Any individual or training company may use this syllabus as the basis for a training course if the authors and the ISTQB are acknowledged as the source and copyright owners of the syllabus and provided that any advertisement of such a training course may mention the syllabus only after submission for official accreditation of the training materials to an ISTQB recognized National Board.

2. Any individual or group of individuals may use this syllabus as the basis for articles, books, or other derivative writings if the authors and the ISTQB are acknowledged as the source and copyright owners of the syllabus.

3. Any ISTQB-recognized National Board may translate this syllabus and license the syllabus (or its translation) to other parties








ית גרסאותהסטורי

הערות תאריך גירסה

ITCB לתרגום העברי המלא של סילבוס (1121) גירסה ראשונה 1121מאי 12 1121.12 1122הרמה הבסיסית

Revision History

Version Date Remarks

ISTQB 2011 Effective 1-Apr-2011 Certified Tester Foundation Level Syllabus

Maintenance Release – see Appendix E – Release

Notes

ISTQB 2010 Effective 30-Mar-2010 Certified Tester Foundation Level Syllabus

Maintenance Release – see Appendix E – Release

Notes

ISTQB 2007 01-May-2007 Certified Tester Foundation Level Syllabus

Maintenance Release

ISTQB 2005 01-July-2005 Certified Tester Foundation Level Syllabus

ASQF V2.2 July-2003 ASQF Syllabus Foundation Level Version 2.2

“Lehrplan Grundlagen des Software-testens“

ISEB V2.0 25-Feb-1999 ISEB Software Testing Foundation Syllabus V2.0

25 February 1999








תוכן העניינים 6 ...................................................................................................................................... תודות

7 ........................................................................................................... זו לימודים לתוכנית הקדמה

9 ................................................................................................ (K2) תוכנה בדיקות סודותי .1

21 ........................................................................ (K2) ?נחוצות הבדיקות מדוע 2.2 11 ...................................................................... (K1) תוכנה מערכות: ההקשר .1.1.1 11 ..................................................................... (K2) בתוכנה לפגמים הגורמים .1.1.1 11 .................................. (K2) התוכנה ותפעול תחזוקה, בפיתוח הבדיקות תפקיד .1.1.1 11 ................................................................................... (K2) ואיכות בדיקות .1.1.1 11 .............................................................................. (K2? )לבדוק צריך כמה .1.1.1

21 ..................................................................................... (K2) ?מהן ,בדיקות 2.1 21 ....................................................................... (K2) הבדיקה עקרונות שבעת 2.1 24 ...................................................................... (K1) היסודיים הבדיקה תהליכי 2.4

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

21 ........................................................................(K2) בדיקות של הפסיכולוגיה 2.2 21 ......................................................................................... (K2) האתי הקוד 2.1

22 ............................................................................. (K2) התוכנה חיי מחזור לאורך בדיקות .2

12 .......................................................................... (K2) תוכנה לפיתוח מודלים 1.2 11 ................................................................ (K2( )סדרתי פיתוח מודל) V מודל .1.1.1 11 ................................................................................... (K2) בסבבים פיתוח .1.1.1 11 ........................................................... (K2) החיים מחזור מודל בתוך בדיקות .1.1.1

11 ....................................................................................... (K2) בדיקה רמות 1.1 11 ................................................................................... (K2) רכיבים בדיקות .1.1.1 11 .............................................................................. (K2) אינטגרציה בדיקות .1.1.1 11 .................................................................................. (K2) מערכת בדיקות .1.1.1 11 .................................................................................... (K2) קבלה בדיקות .1.1.1

12 ........................................................................................ (K2) בדיקות סוגי 1.1 12 ............................................................................... (K2) תפקודיות בדיקות .1.1.1 12 ............. (K2( )תפקודיות-לא בדיקות) התוכנה של תפקודיים לא מאפיינים בדיקת .1.1.1 12 ......................... (K2( )מבניות בדיקות) התוכנה של ארכיטקטורה/ מבנה בדיקת .1.1.1 Re-testing and) נסיגה ובדיקות חוזרות בדיקות: משינויים הנובעות בדיקות .1.1.1

regression testing) (K2) ............................................................................ 12 12 .................................................................................. (K2) תחזוקה בדיקות 1.4

32 ....................................................................................................... (K2) סטטיות שיטות .3

11 ............................................................. (K2) הבדיקה ותהליך סטטיות שיטות 1.2 14 ................................................................................... (K2) הסקירה תהליך 1.1

11 .......................................................... (K1) רשמית סקירה במסגרת פעילויות .1.1.1 11 ..................................................................... (K1) אחריות ותחומי תפקידים .1.1.1 11 ....................................................................................... (K2) סקירות סוגי .1.1.1 13 ........................................................ (K2) סקירות להצלחת התורמים גורמים .1.1.1

12 ................................................................... (K2) כלים באמצעות סטטי ניתוח 1.1

42 ........................................................................................ (K4) הבדיקות לעיצוב טכניקות .4

41 ......................................................................... (K3) הבדיקות פיתוח תהליך 4.2 41 .................................................................. (K2) בדיקות לעיצוב טכניקות סוגי 4.1 44 ............................................... (K3) שחורה קופסה - מיפרט-מבוססות טכניקות 4.1

11 ................................................................................... (K3) שקילות חלוקת .1.1.1 11 ................................................................................. (K3) גבול ערכי ניתוח .1.1.1 11 ......................................................................... (K3) החלטה טבלת בדיקות .1.1.1 11 .......................................................................... (K3) מצבים החלף בדיקות .1.1.1 11 ........................................................................... (K2) שימוש מקרי בדיקות .1.1.1

41 ................................................... (K4) לבנה קופסה - מבנה-מבוססות טכניקות 4.4 11 ............................................................ (K4) משפטים וכיסוי משפטים בדיקת .1.1.1








11 ............................................................. (K4) החלטות וכיסוי החלטות בדיקת .1.1.1 13 ........................................................... (K1) אחרות מבנה-מבוססות טכניקות .1.1.1

42 ....................................................................... (K2) ניסיון-מבוססות טכניקות 4.2 41 ........................................................................ (K2) הבדיקה טכניקת בחירת 4.1

52 ....................................................................................................... (K3) הבדיקות ניהול .5

21 .................................................................................... (K2) הבדיקות ארגון 2.2 11 ..................................................................... (K2) ועצמאותן הבדיקות ארגון .1.1.1 11 ................................................ (K1) בודק ושל בדיקות מוביל של משימותיהם .1.1.1

24 ..................................................... (K3) העבודה היקף והערכת הבדיקות תכנון 2.1 11 ................................................................................... (K2) הבדיקות תכנון .1.1.1 11 ........................................................................ (K3) בדיקות תכנון פעילויות .1.1.1 11 ...................................................... (K2) (entry criteria) לכניסה מידה אמות .1.1.1 11 ......................................................... (K2) (exit criteria) ליציאה מידה אמות .1.1.1 11 .............................................................. (K2) הבדיקות עבודת היקף הערכת .1.1.1 11 .................................................... (K2) לבדיקות גישה, הבדיקות אסטרטגיית .1.1.1

K2)) ...................................................... 21 הבדיקות התקדמות של ובקרה מעקב 2.1 13 ............................................................ (K1) הבדיקות התקדמות אחר מעקב .1.1.1 13 ................................................................................. (K2) בדיקות על דיווח .1.1.1 12 .................................................................................... (K2) בדיקות בקרת .1.1.1

K2)) ....................................................................................... 21 תצורה ניהול 2.4 K2)) ...................................................................................... 11 ובדיקות סיכון 2.2

11 .................................................................................... (K2) פרויקט סיכוני .1.1.1 11 ........................................................................................ (K2) מוצר סיכוני .1.1.1

K3)) ...................................................................................... 11 אירועים ניהול 2.1

64 ................................................................................................. (K2) בדיקות תומכי כלים .6

12 ............................................................................. (K2) בדיקה כלי של סוגים 1.2 11 .................................................................................... בדיקות תומכי כלים .1.1.1 11 .................................................................................. (K2) בדיקה כלי סיווג .1.1.1 11 ....................................... (K1) והבדיקות הבדיקה תהליך בניהול לתמיכה כלים .1.1.1 11 ............................................................ (K1) סטטיות בבדיקות לתמיכה כלים .1.1.1 13 ............................................................. (K1) בדיקות במיפרטי לתמיכה כלים .1.1.1 13 .................................................. (K1) וברישום בדיקות בהרצת לתמיכה כלים .1.1.1 12 ........................................................... (K1) ובמעקב בביצועים לתמיכה כלים .1.1.3 12 .................................................... (K1) ספציפיים בדיקה בצרכי לתמיכה כלים .1.1.2

11 ................................................... (K2) וסיכונים תועלת :בכלים אפקטיבי שימוש 1.1 12 .................. (K2( )הכלים כל) בבדיקות לתמיכה בכלים אפשריים וסיכונים תועלת .1.1.1 31 .............................................. (K1) מסוימים כלים סוגי עבור מיוחדים שיקולים .1.1.1

12 ................................................................................ (K1) לארגון כלי הכנסת 1.1

72 ....................................................................................................... ביבליוגרפית רשימה .7

73 ....................................................................................... הקורס לתוכנית רקע -' א נספח .8

75 .................................................... הידיעה של הקוגניטיבית הרמה/ הלימוד יעדי –' ב נספח .9

ISTQB ................................................................. 77 ארגון את המשמשים הכללים –' ג נספח .12

33 ........................................................................................................ כללי .11.1.1 33 ................................................................................................ עדכני תוכן .11.1.1 33 ................................................................................................ לימוד דייע .11.1.1 33 ................................................................................................ כללי מבנה .11.1.1 32 .....................................................................................................ניותהפ .11.1.1 32 .......................................................................................... מידע מקורות .11.1.1

79 ................................................................................... ההדרכה לספקי הודעה -' ד נספח .11

82 ................................................................ באנגלית הקודמות למהדורות הערות -' ה נספח .12

83 .................................................................................................................................... מפתח








תתודו

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

International Software Testing Qualifications Board Working Group Foundation Level (Edition 2011): Thomas Müller (chair), Debra Friedenberg. The core team thanks the review team (Dan Almog, Armin Beer, Rex Black, Julie Gardiner, Judy McKay, Tuula Pääkkönen, Eric Riou du Cosquier Hans Schaefer, Stephanie Ulrich, Erik van Veenendaal) and all National Boards for the suggestions for the current version of the syllabus.

International Software Testing Qualifications Board Working Group Foundation Level (Edition 2010): Thomas Müller (chair), Rahul Verma, Martin Klonk and Armin Beer. The core team thanks the review team (Rex Black, Mette Bruhn-Pederson, Debra Friedenberg, Klaus Olsen, Judy McKay, Tuula Pääkkönen, Meile Posthuma, Hans Schaefer, Stephanie Ulrich, Pete Williams, Erik van Veenendaal) and all National Boards for their suggestions.

International Software Testing Qualifications Board Working Group Foundation Level (Edition 2007): Thomas Müller (chair), Dorothy Graham, Debra Friedenberg, and Erik van Veenendaal. The core team thanks the review team (Hans Schaefer, Stephanie Ulrich, Meile Posthuma, Anders Pettersson, and Wonil Kwon) and all the National Boards for their suggestions.

International Software Testing Qualifications Board Working Group Foundation Level (Edition 2005): Thomas Müller (chair), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson and Erik van Veenendaal and the review team and all National Boards for their suggestions.








הקדמה לתוכנית לימודים זו

מטרת המסמך

את הבסיס להסמכה הבינלאומית לבדיקת תוכנה ברמת הבסיס. תוכנית לימודים זו מהווה

להנהלות ( STQB) על ידי הארגון הבינלאומי להסמכת בודקי תוכנה התוכנית נמסרת

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

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

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

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

בדיקות תוכנה ברמת הבסיסבודק מוסמך ל

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

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

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

לדרגת הסמכה מתקדמת יותר.

יעדי לימוד/ רמת ידע קוגניטיבית

בכל יחידה של תוכנית זו ומסווגים כך: יעדי הלימוד מופיעים

2K :זכורל

1K :ןיהבל

1K :יישםל

4K :נתחל

פרטים נוספים ודוגמאות ליעדי לימוד ניתן למצוא בנספח ב'.

" בכל פרק מושגים( את כל המושגים המופיעים תחת הכותרת "2Kהלומדים נדרשים לזכור )

הלימוד.אפילו במקרה שהדבר אינו מצויין באופן מפורש ביעדי

הבחינה

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

נכללות בבחינה.תוכנית זו. כל יחידות התוכנית

.ברירתי )מבחן אמריקאי(-הבחינה בנויה במתכונת שאלון רב

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

.לבחינה








הכרה

רשאית להסמיך ספקי הדרכה (ITCB)בישראל, זהו ארגון ISTQBההנהלה המקומית של

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

. משמעות ההכרה היא שהקורס תואם את תוכנית הלימודים הזאת, ורשאי ITCBמ להכרה

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

הנחיות נוספות לספקי הדרכה נמצאות בנספח ד'.

רמת הפירוט

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

מטרת רמת הבסיסיעדי הוראה כלליים המתארים את

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

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

רשימת מונחים שהתלמידים נדרשים לזכור ולהבין

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

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

מבנה תוכנית הלימודים

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

דקות 111 (2K. בדיקות במהלך מחזור חיי התוכנה )2

בכותרת מצויינת ההרמה ) 2Kכוללים את 1היא שיעדי הלימוד של פרק כותרת זו משמעות

דקות 222יש להקדיש ש, ו(1K)אך לא את 1K( ואת הנמוכות ממנההרמות כוללת את

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

הזמן של היחידה.








דקות 155 (K2יסודות בדיקות תוכנה ) .1

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

מתארים את הפעולות שתוכל לעשות לאחר השלמת כל יחידה. הלימודיעדי

(K2הבדיקות נחוצות? ) מדוע 1.1

1LO-1.1. בתוכנה עלול לגרום נזק תאר באמצעות דוגמאות את האופן שבו פגם

(K2לאדם, לסביבה או לחברה )

2LO-1.1. ( הבחן בין שורש הבעיה הגורמת לפגם לבין השפעותיו של הפגםK2)

3LO-1.1. ( הסבר באמצעות דוגמאות את הסיבות לנחיצותן של בדיקותK2)

4LO-1.1. והבא דוגמאות לאופן בו הבטחת האיכותקות הן חלק מתאר מדוע בדי ,

בדיקות תורמות לרמת איכות גבוהה יותר

5LO-1.1. פגם, הסבר והשווה, תוך שימוש בדוגמאות, את המושגים: שגיאה ,

(K2) ובאג , ואת המושגים התואמים טעותתקלה, כשל

(K2בדיקות, מהן? ) 1.2

1LO-1.2. ( פרט את יעדי הבדיקות הנפוציםK1)

2LO-1.2. בשלבים שונים של מחזור החיים של הבא דוגמאות ליעדי בדיקות

(K2התוכנה )

3LO-1.2. הבחן בין בדיקות לבין ניפוי באגים (debugging( )K2)

(K2שבעת עקרונות הבדיקה ) 1.3

4LO-1.3. הסבר את שבעת עקרונות הב( דיקהK2)

(K1הבסיסי) תהליך הבדיקה 1.4

1LO-1.4. חזור על חמש פעולות הבדיקה הבסיסיות והמשימות התואמות, משלב

(K1התכנון ועד שלב הסגירה )

(K2) הפסיכולוגיה של בדיקות 1.5

1LO-1.5. חזור על הגורמים הפסיכולוגיים המשפיעים על הצלחת הבדיקות(K1)

2LO-1.5. הנגד את דפוס החשיבה של בודק ( עם דפוס החשיבה של מפתחK2)








דקות 22 (K2בדיקות נחוצות? )ה מדוע 1.1

מושגים

;((bugבאג , (fault) תקלהגם: ,(defectפגם ) ;(mistake) טעות גם: ,(error) שגיאה

(riskסיכון ) ;(quality) איכות ;(failure) כשל

(K1: מערכות תוכנה )ההקשר .1.1.1

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

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

(K2הגורמים לפגמים בתוכנה ) .1.1.2

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

במסמכים (. פגמים בתוכנה, במערכות או failureממנה היה עליה להימנע(, ולגרום לכשל )

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

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

(system interactions.)

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

(, או להשפיע על ביצועי התוכנה על ידי firmwareוזיהום יכולים לגרום לתקלות בקושחה )

שינוי בסביבה ובתנאים בהם החומרה פועלת.

(K2תפקיד הבדיקות בפיתוח, תחזוקה ותפעול התוכנה ) .1.1.3

( של המערכות והתיעוד שלהן עשויות לסייע בהפחתת rigorous testing) קות מחמירותבדי

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

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

(K2בדיקות ואיכות ) .1.1.4

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

(reliability)שימושיות , (usability)יעילות , (efficiency)תחזוקתיות , (maintainability)

, למידע נוסף על 1ראו פרק פונקציונליות-(. למידע נוסף על בדיקות לאportability) וניידות

.Software Engineering-Software Product Quality (ISO 9126)מאפייני תוכנה ראו

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

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








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

.הבטחת האיכותד. זהו היבט אחד של תהליך המערכות בעתי אפשר לשפר את איכות

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

(K2כמה צריך לבדוק? ) .1.1.5

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

.2יידון בפירוט בפרק

על מנת לאפשר להם לקבל (stakeholdersעל הבדיקות לספק די מידע לבעלי העניין )

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








דקות 30 (K2בדיקות, מהן? ) 1.2

מושגים

;(testing) בדיקות ;(reviewסקירה ) ;(requirements) דרישות

(debuggingניפוי באגים ) ;(test case) מקרה בדיקה ;(test objectiveיעד הבדיקות )

רקע

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

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

(, דיווח על תהליך הבדיקה ועל המערכת הנבדקת, סיכום וסיום exit criteria) ליציאה

הושלם. בדיקות כוללות גם סקירת ( test phaseפעילויות סגירה לאחר ששלב הבדיקה )

(.static analysis( ועריכת ניתוח סטטי )source code-מסמכים )כולל קוד מקור

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

הבאים: לבדיקות תוכנה ייתכנו היעדים

מציאת פגמים

השגת אמון בהערכה של רמת האיכות

השגת מידע הנחוץ לקבלת החלטות

םמניעת פגמי

תהליך המחשבה והפעילויות הכרוכים בעיצוב בדיקות בשלב מוקדם במחזור החיים )אימות

(( עשויים לסייע במניעת test design) ( באמצעות עיצוב הבדיקהtest basisבסיס הבדיקה )

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

נקודות מבט שונות במהלך בדיקות תוכנה מתחשבות ביעדים שונים. למשל, בבדיקות פיתוח

(development testing בדיקות רכיבים, אינטגרציה ומערכת, היעד העיקרי הוא לגרום ,)

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

(acceptance testingהיעד העיקרי עשוי להיות אישור ,) שהמערכת פועלת כמצופה, על

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

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

(maintenance testing כוללות בדיקות לשלילת הופעתם של פגמים חדשים במהלך ביצוע )

( היעד המרכזי עשוי להיות operational testing) ליותהשינויים. במהלך בדיקות תפעו

הערכת מאפייני המערכת כמו למשל: אמינות או זמינות.

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

בהמשך,

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

.2.4תהליך הבדיקה והפעולות הכרוכות בו מוסברים בפסקה








דקות 11 (K2שבעת עקרונות הבדיקה ) 1.1

מושגים

(exhaustive testing) בדיקות ממצות

עקרונות

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

בדיקות מצביעות על נוכחותם של פגמים – 1עקרון

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

הוכחת תקינות.פגמים אין בכך

בלתי אפשרי לבצע בדיקות ממצות – 2עקרון

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

ולהעמיד סדרי עדיפויות על מנת (risk analysis) ממצות, יש לעשות שימוש בניתוח סיכונים

למקד את מאמץ הבדיקה.

(early testingבדיקות מוקדמות ) – 1עקרון

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

(defect clusteringהתקבצות פגמים ) – 4עקרון

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

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

(pesticide paradox) פרדוקס ההדברה – 1עקרון

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

(, יש צורך pesticide paradox" )עוד פגמים חדשים. כדי להתגבר על "פרדוקס ההדברה

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

(context dependentבדיקות הן תלויות הקשר ) – 6עקרון

( safety-criticalבדיקות נעשות באופן שונה, על פי ההקשר. למשל: תוכנה למערכת חיונית )

תר למסחר אלקטרוני.נבדקת באופן שונה מאשר א

(absence-of-errors fallacyאשליית העדר שגיאות ) – 7עקרון

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








דקות 11 (K1) תהליכי הבדיקה היסודיים 1.4

מושגים

;(test plan) תוכנית בדיקות ;(test basis) בסיס בדיקות ;(test policyמדיניות בדיקות )

נתוני בדיקות ;(test condition)בדיקה תנאי ;(testware ;ותמכלול מרכיבי הבדיק)ּבֹוְדָקה

(test data); בדיקותנוהל (test procedure); סדרת בדיקות (test suite); כיסוי

(coverage) , :כיסוי בדיקותגם (test coverage); ( אמות מידה ליציאהexit criteria); ביצוע

בדיקות חוזרות ;(incident) אירוע ;(test log) רישום בדיקות ;(test executionבדיקות )

(re-testing), :אישור בדיקות גם(confirmation testing); בדיקות נסיגה (regression testing); דו"ח סיכום בדיקות (test summary report)

רקע

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

להכנה לביצוע ולהערכת התוצאות.

תהליך הבדיקה הבסיסי כולל את הפעילויות העיקריות האלה:

תכנון ובקרה

ועיצובניתוח

יישום וביצוע

ודיווח הערכת אמות המידה ליציאה

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

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

(K1)ון הבדיקות ובקרתן תכנ .1.4.1

פעילויות הבדיקה מיפרט( היא פעילות הגדרת יעדי הבדיקה וtest planning) תכנון בדיקות

לעמידה ביעדי המשימה. ותהנחוצ

( היא פעילות מתמשכת בה משווים את ההתקדמות בפועל אל test control) בקרת בדיקות

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

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

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








ניתוח הבדיקות ועיצובן .1.4.2

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

מורכב מהמשימות העיקריות שלהלן: שלב ניתוח ועיצוב הבדיקות

סקירת בסיס הבדיקות, כגון: דרישות, רמת תקינות התוכנה1(software integrity level )- רמת הסיכון, דוחות ניתוח סיכונים

(risk analysisארכיטקטורה ,)עיצוב, דרישות הממשק ,

בדיקּותהערכת ה (testabilityשל בסיס הבדיקות ושל יעדי הבדיקות )

( זיהוי ותעדוף תנאי הבדיקות על סמך ניתוח פריטי הבדיקותtest items ,)

ומבנה התוכנה והתנהגותה מיפרטה

עיצוב ותעדוף מקרי בדיקה ( כללייםhigh level test cases)

הנחוצים לקיום תנאי הבדיקות ומקרי הבדיקה זיהוי נתוני בדיקות

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

דו נֱֶעָקבּותיצירת-( כיווניתbi-directional traceability בין בסיס הבדיקות לבין )

מקרי הבדיקה

(K1)יישום הבדיקות וביצוען .1.4.3

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

הבדיקה; לאחר מכן מקימים את הסביבה ומריצים את הבדיקות.

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

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

תוך יצירת נתוני בדיקות, והכנת רתמת בדיקות ותבדיק נהליפיתוח ותעדוף (test harnessותסריטים אוטומטיים במקרים בהם הבדיקות מיועדות לאוטומציה ) .

יצירת סדרות בדיקה מהליכי הבדיקות במטרה לקבל ביצוע יעיל של הבדיקות

הקמה תקינה של סביבת הבדיקה אימות

כיוונית בין בסיס הבדיקות ומקרי הבדיקה-דו נֱֶעָקבּותאימות ועדכון

בדיקות באופן ידני או אוטומטי )באמצעות כלי האוטומציה(, לפי הרצף נהליביצוע המתוכנן

רישום תוצאות ביצוע הבדיקות, ותיעוד זהויותיהם וגרסאותיהם של התוכנה (מכלול מרכיבי הבדיקה) ּבֹוְדָקהההנבדקת, של כלי הבדיקה, ושל

השוואת התוצאות בפועל לתוצאות הצפויות

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

ביצוע הבדיקה(

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

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

(נסיגה

1תוכנה, -רמת התאימות הקיימת או הנדרשת מן התוכנה לקבוצה של תכונות תוכנה או תכונות תלויות

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








הערכת אמות מידה ליציאה, ודיווח .1.4.4

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

הערכת אמות המידה ליציאה כוללת את המשימות העיקריות הבאות:

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

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

( כתיבת דו"ח סיכום בדיקהtest summary reportעבור בעלי העניין )

(K1)פעילויות סגירת בדיקה .1.4.5

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

( כמו למשל כאשר משחררים milestonesמתבצעות בנקודות אבן הדרך של פרויקט )

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

(.maintenance releaseכאשר הושלמה גרסת תחזוקה )

פעילויות סגירת בדיקה כוללות את המשימות העיקריות הבאות:

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

( סגירת דוחות אירועיםincident reportsורישום דוחות שנש ,) ארו פתוחים לשם

תיעוד, תיקון עתידי או כבקשות לשינויים

( תיעוד קבלת המערכתacceptance)

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

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

במידע שנאסף לשיפור בשלות הבדיקותשימוש (test maturity)








דקות 21 (K2הפסיכולוגיה של בדיקות ) 1.1

מושגים

(;error guessing) ניחוש שגיאות

(independence) תלות-אי גם:, (independence of testing)עצמאות הבדיקות

רקע

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

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

יכולות להתבצע בכל שלב של הבדיקות.

, משפרת author bias))תלות, שמטרתה להימנע מהטיית המחבר -רמה מסוימת של אי

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

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

תלות נמוכה(-בדיקות שעוצבו על ידי אלו שכתבו את התוכנה הנבדקת )רמת אי

)בדיקות שעוצבו על ידי אדם אחר )למשל: חבר צוות הפיתוח

קות שעוצבו על ידי אדם מקבוצה ארגונית אחרת )למשל: צוות בדיקה בלתי בדי תלוי( או על ידי מומחה בדיקה )למשל: מומחי בדיקות שימושיּות או ביצועים(

בדיקות שעוצבו על ידי אדם מארגון או חברה אחרים )למשל: מיקור חוץ או הסמכה על ידי גוף חיצוני(

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

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

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

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

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

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

(, המעצבים והמפתחים. הדבר נכון לגבי פגמים המתגלים הן analystsמנתחי המערכות )

במהלך הבדיקות. במהלך הסקירות והן

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

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

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








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

להזכיר לכולם -להתחיל ממקום של שיתוף פעולה ולא ממקום של עימות טובה יותר שהמטרה המשותפת היא מערכות באיכות

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

מצאיםהמ

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

לוודא שהצד השני הבין לאשורם את הדברים שנאמרו, וכן להיפך








דקות 12 הקוד האתי 1.6

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

את הקוד ISTQB, ניסח ארגון IEEE-ו ACMהאתיים למהנדסים, כפי שנוסחו על ידי ארגוני

האתי הבא:

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

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

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

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

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

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

עמיתים: בודקי תוכנה מוסמכים יהיו הוגנים כלפי עמיתיהם, יתמכו בהם, ויקדמו שיתוף פעולה עם מפתחי תוכנה

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








דקות 111 (K2בדיקות לאורך מחזור חיי התוכנה ) .2

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

מתארים את הפעולות שתוכל לעשות לאחר השלמת כל יחידה.הלימוד יעדי

(K2פיתוח תוכנה )למודלים 2.1

LO-2.1.1 פעילויות בדיקה ותוצרים במחזור הפיתוח, את הקשר בין פיתוח הסבר ,

(K2באמצעות דוגמאות העושות שימוש בסוגי פרויקטים ומוצרים )

LO-2.1.2 הפרויקט התוכנה להקשר של במודל פיתוחלבצע התאמות הבן שיש

(K1ולתכונות והמוצר )

LO-2.1.3 פרט מאפיינים של בדיקות נכונות המתאימים לכל מודל מחזור חיים

(K1)

((K2רמות בדיקה 2.2

1LO-2.2. רמות הבדיקה השונות: יעדים מרכזיים, מושאי בדיקה השווה את

( או functionalטיפוסיים, מטרות בדיקה טיפוסיות כגון תפקודיות )

ים, סוגי ( ותוצרי עבודה נלווים, מי הם הבודקstructuralמבניות )

(.K2ים שניתן לזהות )הפגמים והכשל

( (K2סוגי בדיקות 2.3

1LO-2.3. השווה באמצעות דוגמאות בין ארבעה סוגי בדיקות: תפקודיות

((functionalתפקודיות )-, לאnon-functional( מבניות ,)(structural

(.change-related( .)K2) שינויים-וקשורות

2LO-2.3. הבן שבדיקות תפקודיות ( ומבניות מתרחשות בכל רמות הבדיקהK1.)

3LO-2.3. המבוססות על דרישות לא תפקודיות-הכר ותאר סוגי בדיקות לא-

(.K1) תפקודיות

4LO-2.3. הכר ותאר את סוגי הבדיקות המבוססות על ניתוח המבנה או

(.K2של מערכת התוכנה ) הארכיטקטורה

5LO-2.3. אישור תאר את מטרתן של בדיקות(confirmation) ובדיקות נסיגה

((regression (K2.)

( Maintenance Testing) (K2)בדיקות תחזוקה 2.4

1LO-2.4. בדיקת מערכת קיימת( לבדיקת יישום חדש השווה בדיקות תחזוקה(

לפי סוגי הבדיקות, הגורמים שבגללם מבצעים בדיקות )מחוללי

(.K2( וכמות הבדיקות )triggers -הבדיקות

2LO-2.4. ,הכר ולמד לזהות את המצבים הדורשים בדיקות תחזוקה: התאמות

(.retirement( )K1, סיום חיי תוכנה )migration)) הגירה

3LO-2.4. תאר את תפקידן של בדיקות הנסיגה וניתוח השפעה

(impact analysis( במסגרת בדיקות תחזוקה )K2.)








דקות 22 (K2מודלים לפיתוח תוכנה ) 2.1

מושגים

V (V-model)מודל ;validation)) תיקוף ;(verification) אימות

(iterative-incremental development model) מודל מחזור חיים מבוסס סבבים מצטברים

רקע

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

(K2)מודל פיתוח סדרתי( ) Vמודל .2.1.1

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

אשר חופפות לארבעת שלבי הפיתוח. רמות בדיקה

המשמשים בתוכנית לימודים זו הינם: ארבעת שלבי הבדיקה

בדיקות רכיבים (component testing)

( בדיקות אינטגרציהintegration testing)

בדיקות מערכת (system testing)

בדיקות קבלה (acceptance testing)

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

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

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

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

(, "תהליכים Capability Maturity Model Integration ,CMMI"מודל הבשלות המשולב" )

. אפשר לבצע אימותSoftware Life Cycle Processes , (IEEE/IEור חיי תוכנה" )במחז

ותיקוף )וכן עיצוב בדיקות מוקדם( תוך כדי פיתוח מוצרי התוכנה.

(K2פיתוח בסבבים ) .2.1.2

הינו תהליך של ( iterative-incremental developmentמחזורי בסבבים מצטברים ) פיתוח

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

RAD - פיתוח יישומים מהיר(, prototyping) טיפוס-בניית אב :לכך הן

(Rapid Application Development ,)RUD (Rational Unified Development ומודלים )

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

(. כל תוספת לשלבים הקודמים שפותחו כבר, יוצרת iterationרמות במהלך כל סבב )

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








(K2בדיקות בתוך מודל מחזור החיים ) .2.1.3

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

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

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

,במהלך פעילות הפיתוח מתחילים ועיצובן ניתוח הבדיקותעבור כל רמת בדיקה המקבילה

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

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

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

תפקודיות ובדיקות משתמש ו/ או בדיקות תפעוליות(.








דקות 42 (K2רמות בדיקה ) 2.2

מושגים

מנהל ;(stub) תותב ;(component testingבדיקות רכיבים ) ;(test levelרמת בדיקה )

;(robustness testing) בדיקות חוסן; (test environment) סביבת בדיקה; (driverהתקן )

תפקודיות-דרישות לא ;(functional requirements) דרישות תפקודיות

(non-functional requirements); בדיקות-פיתוח מובל (test driven development);

על ידיבדיקות קבלה ; (system testingבדיקות מערכת ); (integration) אינטגרציה

;(acceptance testing)גם בדיקות קבלה , (user acceptance testing) /תמשתמש

-COTS, commercial offמדף מסחרי )-גם: מוצר(, off-the-shelf softwareמדף )-תוכנתthe-shelf,) תוכנת-( מדף מסחריתcommercial off-the-shelf software); בדיקות אלפא

(alpha testing); ( בדיקות בטאbeta testing) ,גם ( בדיקות שדהfield testing)

רקע

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

(test object פגמים וכשלים אופייניים שיש לזהות ,)כלומר, הדבר אותו בודקים ,

((defects and failuresשל , דרישות ( רתמת הבדיקותtest harness requirementsו ) של

יכה ברתמה, וכן גישות ותחומי אחריות ספציפיים.לתמ tools)כלים )

( של מערכת כבר configuration dataיש לקחת בחשבון את הצורך בבדיקת נתוני התצורה )

.בעת תכנון הבדיקות

(K2בדיקות רכיבים ) .2.2.1

הבדיקות:בסיס

דרישות הרכיבים

עיצוב מפורט

קוד

בדיקה אופייניים:מושאי

רכיבים

תוכנות

תוכנות להמרה או הגירה של נתונים

(migration programs/ data conversion)

מודולים של מסדי נתונים

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

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

ובסימולטורים. (drivers), במנהלי התקנים (stubs)ים בתותב להשתמשניתן לשם כך

תפקודיים מסוימים, -ושל מאפיינים לא בדיקות רכיבים עשויות לכלול בדיקות של תפקודיות

-, כגון חיפוש דליפות זיכרון resource behaviorכמו למשל: התנהגות המשאבים )

memory leaksכמו גם בדיקות מבניותבדיקות חוסן ( או , (structural testing :למשל( )

של רכיב, מיפרטמופקים מתוצרים כגון: (. מקרי בדיקהdecision coverageכיסוי החלטות,

עיצוב התוכנה או מודל הנתונים.








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

(, או כלי לניפוי באגיםunit test framework) מערכת לבדיקות יחידהפיתוח כמו

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

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

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

". ( או "פיתוח מובל בדיקותtest-first approach" )הקוד. גישה זו מכונה "בדיקות תחילה

מבוססת על מחזורים . היאסבבים באופן מובהק-מבוססתו( iterativeגישה זו היא מחזורית )

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

(K2בדיקות אינטגרציה ) .2.2.2

בסיס הבדיקות:

עיצוב התוכנה והמערכת

ארכיטקטורה

( סדר פעולותworkflow)

מקרי שימוש (use cases)

מושאי בדיקה אופייניים:

מערכות-תת

יישום מסדי נתונים

( תשתיתinfrastructure)

( ממשקיםinterfaces)

תצורת מערכת ונתוני תצורה

(system configuration and configuration data)

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

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

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

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

עובדה זו יכולה להיחשב כסיכון.

( תהליכים עסקייםbusiness processes המיושמים כסדר פעולות עשויים לכלול )

משמעותיות. (cross platform)מערכות. יתכנו בעיות חוצות מערכת סדרה של

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

(troubleshooting.)

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

, על משימות תפקודיות, על רצף עיבוד )(bottom-up) ( ומלמטה למעלהtop-down) למטה

היבטים אחרים של המערכת או (, או על transaction processing sequences) תנועות








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

((incremental ( "ולא "במכה אחתbig bang.)

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

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

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

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

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

(K2בדיקות מערכת ) .2.2.3

:בסיס הבדיקות

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

מקרי שימוש

תפקודי מיפרט

סיכוניםדוחות ניתוח (risk analysis reports)


המערכת עצמה

תיעוד הנלווה למערכת: מדריכי המערכת, המשתמש וההפעלה

תצורת המערכת ונתוני תצורה

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

( להיקף הבדיקות level test plan( או בתוכנית הרמה )master test plan)בתוכנית האב

שיבוצע ברמת בדיקה זו.

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

הבדיקות.

יכולות לכלול בדיקות המבוססות על: בדיקות מערכת

סיכונים

י דרישותמיפרט

תהליכים עסקיים

מקרי שימוש

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

ההפעלהאינטראקציות עם מערכת

משאבי המערכתsystem resources))

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

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

( המתאימות ביותר להיבט black box)קופסה שחורה, מיפרטה-בטכניקות מבוססות

( עבור צירופים של תופעות decision tableהמערכתי הנבדק. למשל, יצירת טבלת החלטה )








(. לאחר מכן אפשר להפעיל טכניקות business rulesהמתוארות בכללים העסקיים )

( על מנת להעריך את מידת היסודיות של white box)קופסה לבנה, מבוססות מבנה

(.4הבדיקות ביחס לאלמנט מבני, כגון: מבנה תפריט או ניווט בדף אינטרנט )ראה פרק

בדיקות מערכת.במקרים רבים צוות בדיקות עצמאי הוא המבצע

(K2בדיקות קבלה ) .2.2.4

:בסיס הבדיקות

דרישות המשתמש

דרישות המערכת

מקרי שימוש

תהליכים עסקיים

דוחות ניתוח סיכונים


תהליכים עסקיים על גבי מערכת שעברה אינטגרציה מלאה

תהליכים תפעוליים ותחזוקתיים

( נוהלי משתמשuser procedure)

טפסים

דוחות

נתוני תצורה

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

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

מסוימים שלה. מציאת פגמים איננה עומדת במוקד בדיקות (non-functional)תפקודיים

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

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

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

מדף מסחרי -מוצר (COTS) יעבור בדיקות קבלה בעת התקנתו או שילובו במערכת

קיימת

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

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

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

משתמשה יבדיקות קבלה על יד

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

בדיקות )קבלה( תפעוליות

(, כולל:system administratorsעל ידי מנהלי המערכת ) קבלת המערכת

בדיקת גיבוי ושחזור

התאוששות מאסון (disaster recovery)

ניהול משתמשים

משימות תחזוקה








עומס נתונים ומשימות הגירה (migration)

בדיקות תקופתיות לפרצות אבטחה

בדיקות קבלה חוזיות ורגולטוריות

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

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

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

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

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

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

(factory acceptance testing( ובדיקות באתר )site acceptance testing עבור מערכות )

הנבדקות לפני ואחרי ההעברה לאתר הלקוח.








דקות 42 (K2סוגי בדיקות ) 2.1

מושגים

;(black-box testing) בדיקות קופסה שחורה (;functional testing) תפקודיות בדיקות

;(security testing) בדיקות אבטחה ;(interoperabilityהדדית )-יכולת פעולהבדיקות ל

;(load testingבדיקות עומס ) ;(performance testing) בדיקות ביצועים

בדיקות תחזוקתיות ;(usability testing) בדיקות שימושיות ;(stress testing) בדיקות מאמץ

(maintainability testing) ;בדיקות אמינות (reliability testing); בדיקות ניידות

(portability testing); בנהבדיקות קופסה ל (white-box testing) ; בדיקות מבנה

(structural testing); כיסוי קוד(code coverage)

רקע

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

מתמקד ביעד בדיקה מסוים, למשל: סוג בדיקה

תפקוד מסוים של התוכנה

תפקודי כגון: אמינות או שימושיות-מאפיין איכותי, לא

מבנה או ארכיטקטורה של התוכנה או המערכת

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

או לעשות בו שימוש:\אפשר לפתח מודל של התוכנה ו

בבדיקות מבניות; למשל: מודל זרימת הבקרה (control flow model או מודל )

(menu structure modelמבנה התפריט )

למשל: מודל ביצועים, מודל שימושיות, מודל איומי תפקודיות-בבדיקות לא ;

(security threat modelingאבטחה )

( בבדיקות תפקודיות; למשל: מודל זרימת תהליךprocess flow modelמוד ,) ל

הכתוב בשפה פשוטה מיפרט(, או state transition model) 2החלף מצבים

(plain language specification)

(K2בדיקות תפקודיות ) .2.3.1

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

"מה שהמערכת עושה".

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

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

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

(.החיצונית של התוכנה )בדיקות קופסה שחורה

2מעבר מצבים" או "מעבר בין " כ state transitionהערה על התרגום: בעבר היה נהוג לתרגם

מצבים"








חומת אש, , שהן סוג של בדיקות תפקודיות, חוקרות תפקודים )למשל, בדיקות אבטחה

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

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

(K2תפקודיות( )-יינים לא תפקודיים של התוכנה )בדיקות לאבדיקת מאפ .2.3.2

, בדיקות , בדיקות עומס, בדיקות מאמץכוללות בדיקות ביצועים בדיקות לא תפקודיות

, אך אינן ובדיקות ניידות (, בדיקות אמינותmaintainability) שימושיות, בדיקות תחזוקתיות

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

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

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

(Software Engineering – Software Product quality - ISO 9126 בדיקות לא .)

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

(K2בדיקת מבנה/ ארכיטקטורה של התוכנה )בדיקות מבניות( ) .2.3.3

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

מסוים.שהושגה עבור מבנה (coverage)הבדיקות על ידי הערכת רמת הכיסוי

הוא המידה בה פריט מסוים )כגון: שורות קוד( נבדק בפועל על ידי סדרת בדיקות הכיסוי

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

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

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

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

(calling hierarchy.)

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

בדיקות הנובעות משינויים: בדיקות חוזרות ובדיקות נסיגה .2.3.4(Re-testing and regression testing) (K2)

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

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

איתור פגמים ותיקונם( הינו פעילות פיתוח ולא פעילות בדיקה.

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

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

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

מאמץ בבדיקות נסיגה.








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

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

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








דקות 11 (K2בדיקות תחזוקה ) 2.4

מושגים

(impact analysis) ניתוח השפעה; (maintenance testing) בדיקות תחזוקה

רקע

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

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

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

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

המערכת.

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

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

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

ההפעלה.

, למשל מפלטפורמה אחת לאחרת( יש migrationבמסגרת בדיקות תחזוקה לפני הגירה )

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

המתוחזקת.

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

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

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

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

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

ביבליוגרפיה

2.1.3 CMMI, Craig, 2002, Hetzel, 1988, IEEE 12207

2.2 Hetzel, 1988

2.2.4 Copeland, 2004, Myers, 1979

2.3.1 Beizer, 1990, Black, 2001, Copeland, 2004

2.3.2 Black, 2001, ISO 9126

2.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 1988

2.3.4 Hetzel, 1988, IEEE Std 829-1998

2.4 Black, 2001, Craig, 2002, Hetzel, 1988, IEEE Std 829-1998








דקות 62 (K2שיטות סטטיות ) .3

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

הפעולות שתוכל לעשות לאחר השלמת כל יחידה. מתארים את הלימוד יעדי

(K2) סטטיות ותהליך הבדיקהשיטות 3.1

1LO-3.1. ותהסטטישיטות הניתן לבחון באמצעות שאת תוצרי התוכנה הכר

(K1שונות )ה

2LO-3.1. השימוש בשיטות את החשיבות והערך שבעטיים יש לשקול אתתאר

(K2ות להערכת תוצרי תוכנה )סטטי

3LO-3.1. ות, בהתחשב דינמיות לבין שיטות סטטיהסבר את ההבדל בין שיטות

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

(software life cycle( )K2סגרת מחזור חיי התוכנה )במ

(K2) תהליך הסקירה 3.2

1LO-3.2. בתהליך של סקירה פעילויות, תפקידים ותחומי האחריות פרט

(K1) תאופייני ( (formal reviewרשמית

2LO-3.2. לא רשמית שונות: סקירה הסבר את ההבדלים בין סוגי הסקירות

review) informal)דיון מודרך, , סקירה טכנית (walkthrough )

(inspection( )K2) וביקורת

3LO-3.2. המשפיעים עלהסבר את הגורמים ( ביצוע מוצלח של סקירותK2)

(K2) באמצעות כלים סטטיניתוח 3.3

1LO-3.3. סטטיפגמים ושגיאות אופייניים הניתנים לזיהוי באמצעות ניתוח פרט

(dynamic testing( )K1) ותדינמיוהשווה אותם לסקירות ולבדיקות

2LO-3.3. סטטי המאפיינים ניתוחתאר באמצעות דוגמאות את היתרונות (K1)

3LO-3.3. הניתנים לזיהוי באמצעות כלים לניתוח טיפוסייםפגמי קוד ועיצוב פרט

(K1) סטטי








דקות 11 (K2ות ותהליך הבדיקה )סטטי שיטות 1.1

מושגים

(static testing) ותסטטי, בדיקות (dynamic testing) ותדינמיבדיקות

רקע

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

באמצעות סקירות ,כולל הקוד ,(software work productsלבדוק את תוצרי העבודה ) ניתן

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

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

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

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

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

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

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

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

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

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

( בלתי maintainabilityתקנים, פגמים בדרישות, פגמים בעיצוב, תחזוקתיות )מהגדרות של

י ממשק שגויים.מיפרטמספקת ו








דקות 21 (K2הסקירה ) תהליך 1.2

מושגים

;(metric) מדד ;(entry criteriaאמות מידה לכניסה )(; formal review) רשמיתסקירה

;(scribe) ; רשם(reviewer) סוקר ;(moderator) מתאם

סקירה טכנית; (walkthrough) דיון מודרך ;((informal review סקירה לא רשמית

(technical review); ( ביקורתinspection); סקירת עמיתים (peer review)

רקע

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

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

auditנתיב ביקורת )דרישות חוקיות או רגולטוריות או הצורך בהצגת עמידה בהפיתוח, trail.)

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

(K1ת )רשמיפעילויות במסגרת סקירה .3.2.1

ת כוללת בדרך כלל את הפעילויות העיקריות הבאות:רשמיסקירה

תכנון .2

הגדרת א( מות המידה של הסקירהreview criteria)

בחירת הצוות

חלוקת תפקידים

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

, entry and exit criteria)ויציאה )

יסקרושיאו חלקי המסמכים בחירת המסמכים

ות יותר(רשמיבדיקת אמות המידה לכניסה )עבור סקירות

(kick-off) נעההת .1

הפצת מסמכים

הסברת היעדים, התהליך והמסמכים למשתתפים

הכנה אישית .1

הכנה לישיבת הסקירה על ידי סקירת המסמכים

שאלות והערותפוטנציאלייםהכנת רשימה של פגמים ,

בחינה/ הערכה/ רישום של תוצאות הישיבה .4

ות יותר( תוצאות מתועדות או פרוטוקול רשמי)עבור סקירות דיון או רישום, כולל

רישום של פגמים, הצעת המלצות לגבי הטיפול בפגמים, קבלת החלטות לגבי הפגמים

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








תיקונים .2

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

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

מעקב .1

טופלושהפגמים ווידוא

איסוף מדדים

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

(K1תפקידים ותחומי אחריות ) .3.2.2

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

מקצה זמן בלו"ז הפרויקט ובודק שיעדי הסקירה מנהל: מחליט על ביצוע סקירות , הושגו

מתאם (moderator) סט המסמכים, : האדם המוביל את הסקירה של המסמך או

( לאחר הישיבה. אם יש follow upכולל תכנון הסקירה, ניהול הישיבה, ומעקב )

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

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

)ים(הנסקר

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

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

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

במהלך הישיבה

-התבוננות במוצרי תוכנה או תוצרי עבודה נלווים מנקודות מבט שונות ושימוש ברשימות

ביקורת -תולדוגמא, רשימ. ןתורמים לאפקטיביות של הסקירות וליעילות checklists)) ביקורת

או ,, בודק או מתפעל(maintainer) ת על נקודות מבט שונות כמו משתמש, מתחזקוהמבוסס

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

(K2סקירות ) סוגי .3.2.3

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

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

המצויים: אלה הם המאפיינים, האפשרויות, והמטרות העיקריים של סוגי הסקירות

תרשמי לאסקירה

רשמי אין תהליך

יכולה להתבצע( במסגרת תכנות בזוגותpair programming או על ידי מוביל )

טכני הסוקר את העיצוב והקוד

יתכן תיעוד של הממצאים

מידת התועלת תלויה בסוקרים

:השגת תועלת מסוימת, בעלות נמוכהמטרה עיקרית








דיון מודרך

מחברפגישה בהנחיית ה

על יבשהרצת הקוד " או תרחישיםתיאור בצורת יכול להתבצע למשל( "dry run עמיתיםפעילה של קבוצת השתתפות (, תוך

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

o להכין את הסוקרים טרם הישיבה

o להכין דוח סקירה ובו רשימת הממצאים

o (מחבר)שאיננו ה רשם למנות

מאד רשמידי לבין למ רשמי-ע בין בלתיוניכול לבפועל אופי הסקירה

מטרות עיקריות: למידה, הבנה, מציאת פגמים

סקירה טכנית

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

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

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

הכנה מוקדמת של הסוקרים טרם הישיבה

ביקורת -ותאפשרות לשימוש ברשימ

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

מאד רשמילמדי לבין רשמי-ע בין בלתיוניכול לבפועל אופי הסקירה

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

ביקורת

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

כבחינתלרוב מתבצעת ( עמיתיםpeer examination)

תפקידים מוגדרים

כוללת איסוף מדדים

ביקורת-המבוסס על כללים ורשימות רשמיתהליך

מוצר התוכנה אישורויציאה מוגדרות לצורך אמות המידה לכניסה

לישיבההכנה מוקדמת

כולל רשימת ממצאים ,דוח ביקורתכתיבת

תהליך מעקב (follow-up) שיפור פת רכיבים שלאפשרות להוסעם ) רשמי

תהליכים(

אפשרות למינוי קורא (reader)

מטרה עיקרית: מציאת פגמים

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








(K2גורמים התורמים להצלחת סקירות ) .3.2.4

:ותהצלחת סקירהתורמים לבין הגורמים

קיום יעדים ברורים ומוגדרים מראש

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

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

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

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

עובד -בתהליכי הערכתלא ישמשו יהתוצאות ;וירה של אמוןוהסקירה מתבצעת בא

(evaluationשל ) המשתתפים

ולרמה לסוג וכן הסקירה מותאמות להשגת היעדים, טכניקות(level) תוצר של

סוקריםוליכולת ה ,העבודה

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

ת רשמימתבצעת הדרכה בשיטות הסקירה הנתונות, במיוחד במקרה של סקירה יותר כמו ביקורת

ההנהלה תומכת בתהליך סקירה תקין )למשל על ידי הקצאת זמן מספיק לפעילויות הסקירה בלו"ז הפרויקט(

שיפור תהליכים קיים דגש על למידה ועל








דקות 22 (K2)באמצעות כלים סטטיניתוח 1.1

מושגים

(;complexity) סיבוכיות (;control flow) ; זרימת בקרה(static analysis)סטטי ניתוח

(compiler) מהדר

רקע

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

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

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

HTMLוכן גם פלט כמו , וזרימת נתונים( את זרימת הבקרהמנתחים את קוד התוכנית )למשל

.XMLו

:סטטימניתוח המופקתהתועלת

גילוי מוקדם של פגמים עוד בטרם ביצוע בדיקות

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

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

תלויות גילוי ((dependencies במודלים של התוכנה, כמו למשל עקביותוחוסר

(links) קישורים

הקוד והעיצוב שיפור תחזוקתיות

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

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

משתנה בעל ערך שאינו מוגדרשימוש ב

( ממשקים לא אחידים בין מודוליםmodules( ורכיבים )components)

משתנים שאינם בשימוש או הצהרה לא תקינה על משתנים

מתקוד (dead code)

)לוגיקה חסרה או שגויה )פוטנציאל ללולאות אינסופיות

מבנים מורכבים יתר על המידה

תקניהת תכנוהסטיות מנהלי

פרצות אבטחה

( שגיאות תחבירsyntaxבקוד ובמודלים )

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

((check-in ניהולאל תוך כלי ( תצורהconfiguration management המעצבים עושים .)

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

בכלים.

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









3.2 IEEE 1028

3.2.2 Gilb, 1993, van Veenendaal, 2004

3.2.4 Gilb, 1993, IEEE 1028

3.3 van Veenendaal, 2004








דקות 281 (K4טכניקות לעיצוב הבדיקות ) .4

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

מתארים את הפעולות שתוכל לעשות לאחר השלמת כל יחידה. הלימודיעדי

(K3תהליך פיתוח הבדיקות ) 4.1

1LO-4.1. עיצוב בדיקות ) מיפרטהבחן בין(test design specification ,מיפרט

בדיקות נוהל מיפרט( וtest case specificationמקרי בדיקה )

(test procedure specification( )K2)

2LO-4.1. תנאיהשווה בין המונחים ( בדיקהtest condition ,)

(K2) (test procedure) ותבדיק ונוהל (test case) מקרה בדיקה

3LO-4.1. נֱֶעָקבּותהערך את איכות מקרי הבדיקה במונחים של (traceability ,)

(K2ורמת הבהירות של התוצאות הצפויות )

4LO-4.1. מאוסף של מקרי בדיקה, ברמת פירוט ותבדיק נוהל מיפרטצור

(K3התואמת את הידע של הבודקים )

(K2) סוגי טכניקות לעיצוב בדיקות 4.2

1LO-4.2. מיפרט-מבוססות הסיבות לכך שגם טכניקות עיצוב בדיקותפרט את

המבנה )קופסה לבנה, -( וגם אלה מבוססותblack box, )קופסה שחורה

white box הן שימושיות ופרט את הטכניקות הנפוצות בכל אחד )

(K1מהסוגים )

2LO-4.2. מיפרט-הסבר את המאפיינים של בדיקות מבוססות

(specification-basedבדיקות מבוססות ,)-( מבנהstructure-based )

(, וכן את המשותף להן experience-basedניסיון )-ובדיקות מבוססות

(K2והשונה ביניהן )

(K3) או טכניקות קופסה שחורה מיפרטטכניקות מבוססות 4.3

1LO-4.3. מודל של תוכנה, כתוב מקרי בדיקה מתאימים, תוך שימוש בהנתן

בטכניקות של: חלוקה למחלקות שקילות

(equivalence partitioning ניתוח ערכי ,)גבול

(boundary value analysis( טבלאות החלטה ,)decision tables )

(state transition diagrams( )K3) החלף מצביםותרשימי/ טבלאות

2LO-4.3. ,הסבר את המטרה העיקרית של כל אחת מארבע טכניקות הבדיקה

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

(coverage( )K2)

3LO-4.3. הסבר את העקרון העומד מאחורי בדיקות מקרי-( שימושuse case )

(K2ואת התועלת שבהן )








(K4) טכניקות מבוססות מבנה או טכניקות קופסה לבנה 4.4

1LO-4.4. תאר את( המושג כיסוי קודcode coverage ואת התועלת הגלומה בו )

(K2)

2LO-4.4. הסבר את המושגים כיסוי משפטים (statement coverageוכיסוי )

(, והסבר מדוע אפשר לעשות בהם decision coverageהחלטות )

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

(K2ברמת המערכת( )

3LO-4.4. נתונים תוך שימוש זרימת בקרהכתוב מקרי בדיקה עבור מסלולי

(K3בטכניקות של כיסוי משפטים והחלטות )

4LO-4.4. השווה את רמת כיסוי המשפטים וההחלטות ביחס ליעד שהוגדר באמות

(K4המידה )הקריטריון( ליציאה )

(K2) ניסיון-טכניקות מבוססות 4.5

1LO-4.5. פרט סיבות לכתיבת מקרי בדיקה על פי האינטואיציה, הניסיון וההכרות

(K1עם פגמים נפוצים )

2LO-4.5. מיפרט-ניסיון עם טכניקות מבוססות-השווה טכניקות מבוססות (K2)

(K2) טכניקות הבדיקהבחירת 4.6

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

(K2בדיקות, למודלים או מאפיינים של התוכנה )








דקות 11 (K3תהליך פיתוח הבדיקות ) 4.1

מושגים

,תכנית ביצוע (test design)(, עיצוב בדיקות test case specification) מקרה בדיקה מיפרט

בדיקות נוהל מיפרט(, test execution schedule) בדיקות

((test procedure specificationות, תסריט בדיק (test script ,)נֱֶעָקבּות (traceability)

רקע

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

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

על מנת להחליט מה יש לבדוק, , מנתחים את מסמכי בסיס הבדיקותבמהלך ניתוח הבדיקות

מוגדר כפריט או אירוע (. תנאי בדיקהtest conditionsכלומר, מזהים את תנאי הבדיקות )

(, transactionשניתן לאמת באמצעות מקרה בדיקה אחד או יותר; למשל פונקציה, תנועה )

תכונה, מאפיין, או אלמנט מבני.

ים והדרישות מאפשרת ניתוח השפעהמיפרטמתנאי הבדיקה חזרה אל ה נֱֶעָקבּותיצירת

(impact analysisאפקטיבי כאשר הדרישות משתנות, וגם את קביעת רמת כיסוי ) הדרישות

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

(detailed test approach ,על ידי בחירת טכניקות עיצוב בהן נשתמש. הבחירה מתבססת )

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

( מיוצרים ומאופיינים במהלך עיצוב הבדיקות. test dataמקרי הבדיקה ונתוני הבדיקה )

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

(execution precondition תוצאות ,)ביצוע -ותנאי בתר צפויות

(execution postconditions התנאים מוגדרים כך שיתנו כיסוי ליעדי בדיקה מסוימים או .)

לתיעוד בדיקות תוכנה IEEEלתנאי בדיקה מסוים. תקן

( Standard for Software Test Documentation, IEEE Std 829-1998 מתאר את תוכן )

מקרי הבדיקה. מיפרטהעיצוב של בדיקות )המכיל תנאי בדיקה( ואת תוכן מיפרט

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

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

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

מגדיר את רצף הפעולות לביצוע הבדיקה. ותבדיק נוהל(. IEEE Std 829-1998 ) ותבדיק

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

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

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








דקות 11 (K2סוגי טכניקות לעיצוב בדיקות ) 4.2

מושגים

(,black-box test design techniqueטכניקת קופסה שחורה )

(,experience-based test design technique) ניסיון מבוססות טכניקות (,test design technique) בדיקות עיצוב טכניקת (white-box test design technique) לבנה קופסה טכניקת

רקע

לעיצוב בדיקות היא לקבוע את תנאי הבדיקה, מקרי הבדיקה ונתוני המטרה של טכניקה הבדיקה.

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

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

(. מעצם הגדרתן בדיקות קופסה functional and non-functional testing) תפקודיות

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

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

דוק.בקבלת ההחלטה מה יש לב

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

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

:מיפרט-מאפיינים נפוצים של טכניקות עיצוב בדיקות מבוססות

רשמיים משמשים לאפיון הבעיה אותה יש לפתור, התוכנה -מודלים רשמיים או לא או רכיביה

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

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

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

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

:ניסיון-מבוססות מאפיינים נפוצים של טכניקות עיצוב בדיקות

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

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

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








דקות 112 (K3) קופסה שחורה - מיפרט-טכניקות מבוססות 4.1

מושגים

3גבולניתוח ערכי (,equivalence partitioningחלוקת שקילות )

(boundary value analysisבדיקות טבלאות החלטה ,) (decision table testing ,)

(,state transition testing) מצבים החלף בדיקות

(.use case testing) שימוש מקרי בדיקות

(K3חלוקת שקילות ) .4.3.1

( לתוכנה או למערכת מחולק לקבוצות לפי הדמיון input, ַהֶקֶלט )במסגרת חלוקת שקילות

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

(equivalence classes( קיימות עבור נתונים תקפים )valid כלומר ערכים קבילים, וכן עבור ,)

(, כלומר ערכים שיש לדחות. אפשר להגדיר מחלקות עבור ֶפֶלט invalidתקפים )-נתונים לא

(outputערכים פנימיים, ערכים תלויי ,)- למשל, לפני או אחרי אירוע(, פרמטרים של זמן(

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

בכל רמות הבדיקה.

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

.אינטגרציה

(K3) גבולניתוח ערכי .4.3.2

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

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

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

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

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

(, או טווחי טבלאות transactionsאו דרישות למהירות של תנועות ) time outטווחי זמן כגון

(.121X121)למשל, גודל טבלה הוא

(K3בדיקות טבלת החלטה ) .4.3.3

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

(business rules ,מורכבים אשר המערכת נדרשת ליישם. כאשר יוצרים טבלאות החלטה )

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

נכון -( או לאtrue( כלומר, הם יכולים להיות במצב נכון )Booleanמיוצגים באופן בוליאני )

(false( טבלת ההחלטה מכילה את התנאים המחוללים .)triggering conditions שהם ,)

לות המערכת הנובעות מכל צירוף נכון עבור כל ערכי הקלט, ופעו-לרוב צירופים של נכון ולא

3 הערה על התרגום: בעבר היה מקובל למושג זה התרגום "ערך גבול קיצון" או "ערך קצה"








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

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

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

לוגיות. במספר החלטות

(K3) החלף מצביםבדיקות .4.3.4

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

-אפשר לייצג בתרשים מעבר. במקרה כזה, היבט זה של המערכת (state -)"מצב המערכת"

לבודק לצפות בתוכנה במונחים של (. התרשים מאפשר state transition diagram) מצבים

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

זיהוי.-סופי של מצבים אפשריים, והם נבדלים וברי

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

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

ובצת מצבים משמשות רבות את תעשיית התוכנה המש-החלףבדיקות

(embedded softwareואת המיכון ) הטכני באופן כללי. אולם, הטכניקה מתאימה גם

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

(K2בדיקות מקרי שימוש ) .4.3.5

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

: משתמשים או מערכות( אשר מייצרות תוצאה בעלת ערך למשתמש actorsהפועלות )

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

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

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

: זה שיתבצע בדרך כלל( mainstreamהשימוש. בדרך כלל למקרה שימוש יש תרחיש ראשי )

ותרחישים חלופיים.

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

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

(acceptance tests בהשתתפות הלקוח או המשתמש. הם אף מסייעים בחשיפת פגמי )

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

אחרות. מיפרט-בדיקה מבוססות








דקות 62 (K4) קופסה לבנה - מבנה-טכניקות מבוססות 4.4

מושגים

(, code coverage) כיסוי קוד, (structure-based testingבדיקות מבוססות מבנה )

(decision coverageכיסוי החלטות )(, statement coverage) כיסוי משפטים

רקע

מבוססות על כך שהבודקים מכירים מבנים או בדיקות קופסה לבנה מבנה-בדיקות מבוססות

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

רמת הרכיב(component) : ,המבנים המרכיבים את רכיב התוכנה, כלומר

(, או אפילו מסלולים.branches(, החלטות, הסתעפויות )statementsמשפטים )

רמ( ת האינטגרציה: המבנה עשוי להיות עץ קריאהcall tree כלומר תרשים ,)

שבו מודולים קוראים למודולים אחרים.

( רמת המערכת: המבנה עשוי להיות מבנה תפריטmenu structure תהליך ,)

עסקי או מבנה דף אינטרנט.

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

(control flow diagram.לכל החלטה )( על מנת להציג את החלופות )האלטרנטיבות

(K4משפטים )בדיקת משפטים וכיסוי .4.4.1

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

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

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

הערכות של הכיסוי שיתקבל גם בשלב העיצוב. שהורצו בפועל; ניתן לעשות

(K4בדיקת החלטות וכיסוי החלטות ) .4.4.2

(, הינו הערכת אחוז תוצאות branch coverageהחלטות, הנקרא גם כיסוי הסתעפויות ) כיסוי

( אשר נבחנו IFשל פקודת – True/False –של החלטות )למשל, אפשרויות "נכון" ו"לא נכון"

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

.בעקבות ההחלטה, מסלול הבקרה משתנה ועובר לחלק אחר בקוד הנבדק

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

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

, אך ההיפך אינו נכון.211%מבטיח כיסוי משפטים של 211%החלטות של כיסוי -משפטים








(K1מבנה אחרות )-טכניקות מבוססות .4.4.3

תנאים חזקות יותר של כיסוי מבני מאשר כיסוי החלטות, למשל, כיסוי קיימות רמות

(condition coverage( וכיסוי תנאים מרובים )multiple condition coverage.)

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

מודולים, רכיבים או מחלקות.

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








דקות 12 (K2ניסיון )-טכניקות מבוססות 4.1

מושגים

(fault attack) (, התקפה מוכוונת ליקוייםexploratory testing) בדיקות חוקרות

רקע

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

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

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

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

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

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

בתוכנה.

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

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

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

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








דקות 11 (K2בחירת טכניקת הבדיקה ) 4.6

מושגים

אין מושגים מיוחדים

רקע

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

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

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

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

data) נתונים-( ומונחותrule drivenכללים )-(, מונחותprocess drivenתהליך )-ונחותמdriven.על מנת להבטיח כיסוי נאות של העצם הנבדק ,)


4.1 Craig, 2002, Hetzel, 1988, IEEE Std 829-1998

4.2 Beizer, 1990, Copeland, 2004

4.3.1 Copeland, 2004, Myers, 1979

4.3.2 Copeland, 2004, Myers, 1979

4.3.3 Beizer, 1990, Copeland, 2004


4.3.5 Copeland, 2004


4.5 Kaner, 2002

4.6 Beizer, 1990, Copeland, 2004








דקות 172 (K3הבדיקות ) ניהול .5

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

.הפעולות שתוכל לעשות לאחר השלמת כל יחידה מתארים את יעדי הלימוד

(K2) ארגון הבדיקות 5.1

1LO-5.1. עצמאי ובלתי תלוי של הבן את החשיבות של ביצוע( בדיקותK1)

2LO-5.1. בתוך ותעצמאיהסבר את היתרונות והחסרונות של ביצוע בדיקות

(K2הארגון )

3LO-5.1. שיש לקחת בחשבון בהקמת צוות בדיקות צוותזהה מאפיינים של חברי

(K1)

4LO-5.1. ולבודקפרט משימות האופייניות למוביל בדיקות (K1)

(K3) והערכת היקף העבודהתכנון בדיקות 5.2

1LO-5.2. זהה ( את הרמות והיעדים השונים של תכנון בדיקותK1)

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

Standard forתיעוד בדיקות תוכנה )תקן על פי בדיקותה נוהלומסמכי Software Test Documentation( )IEEE Std 829-1998 ) (K1)

3LO-5.2. :ות, אנליטיהבחן בין גישות שונות לתכנון בדיקות, כמו למשל

מודל, שיטתיות, תואמות תהליך/ תקן, דינמיות/ האוריסטיות -מבוססות

(heuristic ,)ייעוציות(consultative) , ונוגדות-

(K2) (regression-averse)נסיגה

4LO-5.2. הבחן בין תכנון בדיקות (test planning) תכנון סדר עבור מערכת לבין

(K2) (scheduling test executionותזמון ביצוע הבדיקות )

5LO-5.2. ביצוע בדיקות עבור סדרת בדיקות נתונה. התחשב בסדרי סדר כתוב

(K3עדיפויות ובתלויות טכניות ולוגיות )

6LO-5.2. בעת עליהן יש לתת את הדעתיות הכנה וביצוע הכן רשימה של פעילו

(K3תכנון בדיקות )

7LO-5.2. ( פרט גורמים אופייניים המשפיעים על המאמץeffortהקשור בבדיקות )

(K1)

8LO-5.2. :המדדים-מבוססת שהגיהבחן בין שתי גישות הערכה שונות בתפיסתן

(metrics-based) מומח-וגישה מבוססת( הexpert-based) (K2)

9LO-5.2. צורך באמות מידה נאותות לכניסה ויציאה עבור והבא צידוקים ל זהה

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

(K2( )תשימושיּו








(K2) הבדיקות מעקב ובקרה על התקדמות 5.3

1LO-5.3. הכנת בדיקותים נפוצים המשמשים למעקב אחר מדדפרט ( וביצועןK1)

2LO-5.3. לצורך בדיקותמדדי והשווה )במונחים של מטרה ושימוש( בין הסבר

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

(K2)לו( בדיקות שעברו ושנכש

3LO-5.3. על פי תקן תיעוד בדיקותסכם את המטרות והתוכן של דו"ח סיכום

(K2) ( IEEE Std 829-1998 ) בדיקות תוכנה

(K2) ניהול תצורה 5.4

1LO-5.4. 4סכם כיצד ניהול תצורה (configuration management תומך )

(K2בבדיקות )

(K2) סיכון ובדיקות 5.5

1LO-5.5. כפי השגת יעדי הפרויקטב לפגועתאר סיכון כבעיה אפשרית העשויה

(K2שהוצבו על ידי אחד או יותר מבעלי העניין )

2LO-5.5. כי רמת הסיכון נקבעת על פי הסיכוי )להתרחשות( וההשפעה הבן

(K1)הנזק שיגרם כתוצאה מההתרחשות( )

3LO-5.5. וסיכוני פרויקט מוצרסיכוני הבחן בין (K2)

4LO-5.5. ( זהה סיכונים אופייניים למוצר ולפרויקטK1)

5LO-5.5. תאר באמצעות דוגמאות כיצד אפשר לעשות שימוש בניתוח סיכונים

(K2תכנון בדיקות ) לצורך ,ובניהול סיכונים

(K3) ניהול אירועים 5.6

1LO-5.6. את התוכן של דו"ח אירועיםהכר (incident report) על פי תקן תיעוד

(IEEE Std 829-1998( )K1 ) בדיקות תוכנה

2LO-5.6. המתאר כשל שהתגלהכתוב דו"ח אירועים ( במהלך בדיקותK3)

4 זה מוכר לעיתים גם כ"בקרת תצורה" הערה על התרגום: מושג








דקות 12 (K2ארגון הבדיקות ) 1.1

מושגים

(test manager) , מנהל בדיקות(test leader) , מוביל בדיקות(tester) בודק

(K2) ועצמאותןארגון הבדיקות .5.1.1

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

תלות עצמם בודקים את הקוד שכתבוהמפתחים -ים עצמאיבודקים אין( מוחלטת(

בתוך צוותי הפיתוח יםעצמאיבודקים

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

או מתוך קהילת המשתמשים מהיחידה העסקיתים עצמאיבודקים

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

או דרישות רגולטוריות(

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

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

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

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

:יתרונות הבדיקה העצמאית כוללים

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

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

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

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

המחויבות לאיכותמפתחים עלולים לאבד את תחושת האחריות ו

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

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

.(Infrastructure and ITשל מערכי מיחשוב ) ותשתית

(K1משימותיהם של מוביל בדיקות ושל בודק ) .5.1.2

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

ובארגון. ,הממלאים את התפקידים

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

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








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

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

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

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

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

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

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

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

(exit criteriaובדיקת אמות המידה ליציאה )

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

נאות של מכלול יישום ניהול תצורה( ּבֹוְדָקהמרכיבי הבדיקות, testware לצורך )

(traceability)נֱֶעָקבּות

( הגדרת מדדיםmetrics מתאימים למדידת התקדמות הבדיקות ולהערכת )

והמוצר איכות הבדיקות

עד איזו רמה, וכיצדאוטומציההחלטה אילו בדיקות תעבורנה ,

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

סביבת הבדיקות איך ליישם אתקבלת החלטה

כתיבת דוחות סיכום בדיקות על בסיס המידע שנאסף במהלך הבדיקות

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

והשתתפות בכתיבתןכניות הבדיקה סקירת ת

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

(testability) הבדיקּות שלהן

י מיפרטיצירת( בדיקותtest specifications)

לעיתים קרובות בתיאום עם מנהל ה בדיקותסביבת ה ויישום הגדרת(IT )והרשת

השגה ו/או הכנת נתוני הבדיקות

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

הצורךשימוש בכלי ניהול בדיקות ובכלי מעקב לפי

לאוטומציה שלבדיקות )לעיתים בתמיכת מפתח או מומחה אוטומציה של בדיקות(

( מדידת ביצועיםperformanceשל רכיבים ושל מערכות )

סקירת בדיקות שפותחו על ידי אחרים

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

(test level) בידי אנשים שונים, יופקד והסיכונים הקשורים במוצר ובפרויקט, תפקיד הבודק

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

מפעילים יהיו( operational acceptance testing - OAT) ברמת בדיקות קבלה תפעוליות

(operators).








דקות 12 (K3והערכת היקף העבודה )תכנון הבדיקות 1.2

מושגים

(test strategy) בדיקות(, אסטרטגיית test approach) ה לבדיקותגיש

(K2) בדיקותתכנון ה .5.2.1

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

ובתוכניות בדיקה (master test plan) את התכנון ניתן לתעד בתוכנית אב לבדיקותתחזוקה.

ובדיקות קבלה system testing)) בדיקות מערכת כגון לכל רמת בדיקהנפרדות

(acceptance testing .)מכוסה בתקן לתיעוד בדיקות בדיקותשל מסמך תכנון המיתאר

(.IEEE Std 829-1998 ) תוכנה

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

וזמינות משאבים. עם התקדמות ( testability)בדיקּות ה(, מידת criticality) קריטיותמידת ה

.להוסיף פרטים לתכנית הבדיקותהפרויקט ותכנון הבדיקות, מתקבל מידע רב יותר וניתן

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

שניתן להתאים את התכנון לשינויים.

(K3פעילויות תכנון בדיקות ) .5.2.2

:כוללות, בין היתרשל מערכת שלמה או חלק ממנה ותהבדיקתכנון פעילויות

בדיקותבחינת ההיקף והסיכונים וזיהוי יעדי ה

הכללית, כולל הגדרת רמות הבדיקה ואמות המידה בדיקותהגדרת גישת ה לכניסה ויציאה

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

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

הבדיקות

פעילויות ניתוח הבדיקות ועיצובןשל קביעת לו"ז וסדר ביצוע

יישום, ביצוע והערכת הבדיקותשל קביעת לו"ז וסדר ביצוע

הגדרת כמות, דרגת פירוט, מבנה ותבניות(templates) מסמכי הבדיקותשל

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

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

(K2) (entry criteria) אמות מידה לכניסה .5.2.3

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

בדרך כלל אמות המידה לכניסה מכסות את הנקודות הבאות:

ומוכנותה בדיקותזמינות סביבת ה

בסביבת הבדיקה בדיקותמוכנות כלי ה

בדיקותל מוכןזמינותו של קוד

בדיקותזמינות נתוני








(K2) (exit criteria)אמות מידה ליציאה .5.2.4

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

כלל אמות המידה ליציאה מכסות את הנקודות הבאות: בדרך

כמו כיסוי קוד הבדיקות מדדים ליסודיות (code coverage ,) כיסוי תפקודיות

(functionality) כיסוי סיכוניםאו

הערכות של צפיפות הפגמים (defect density( או מדדי אמינות )reliability)

עלות

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

לוחות זמנים כמו אלה המבוססים על זמן ההגעה לשוק

(K2) הערכת היקף עבודת הבדיקות .5.2.5

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

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

לפי הערכות המתקבלות מבעלי היקף המשימות : הערכת המומח-גישה מבוססת המשימות או ממומחים

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

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

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

התחום בו עוסקת (, גודל המוצר, מורכבות test basisבסיס הבדיקות, :)כלומר

, דרישות האמינות והאבטחה ודרישות התיעודהתוכנה

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

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

(K2) ה לבדיקות, גישבדיקותת האסטרטגיי .5.2.6

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

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

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

.הרגולציה תקנותו בדיקות,יעדי ה








גישות אופייניות הינן:

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

גישות מבוססות מודל, כגון( בדיקות אקראיותstochastic testing) המשתמשות

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

פילים ( או אודות השימוש )למשל פרוreliability growth models -והאיכות

תפעוליים(

והתקפה מוכוונת )כולל ניחוש שגיאות גישות שיטתיות, כגון גישה מבוססת כשל

, מבוססות (, וגישות מבוססות ניסיוןerror guessing, fault attacks :ליקויים

ומבוססות מאפייני איכות ביקורתרשימת

גישות תואמות תהליך או תקן, כגון אלה המוכתבות על ידי תקנים תעשייתיים או

( למיניהן.agile) זריזות שיטותעל ידי

גישות דינמיות והאוריסטיות, כגון בדיקות חוקרות (exploratory testing ) בהן

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

זו בזו

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

הבדיקות

נסיגה -)נוגדות לתופעות נסיגה גישות המתמקדות בהפחתת הסיכוןregression-averse approaches) במקרי בדיקה קיימים, כגון אלה הכוללות שימוש חוזר ,

בדיקה ושימוש בסדרות תפקודיות נסיגה-של בדיקותנרחבת באוטומציה סטנדרטיות

סיכונים.-מבוססתגם ניתן לשלב גישות שונות, למשל, גישה דינמית שהיא








דקות K2)) 22התקדמות הבדיקות שלמעקב ובקרה 1.1

מושגים

test) בדיקות(, בקרת failure rate) ים(, שיעור כשלdefect densityצפיפות פגמים )control ,)בדיקות ניטור (test monitoring דו"ח סיכום ,)בדיקות (test summary report)

(K1) בדיקותמעקב אחר התקדמות ה .5.3.1

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

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

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

שבוצע בפועלסביבת העבודהשל אחוז עבודת ההכנה ,

( מספר מקרי הבדיקה שהורצו/ שלא הורצו ומקרי למשלביצוע מקרי בדיקה , דיקה שעברו/ שנכשלו(הב

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

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

המוצר באיכותתחושת הביטחון הסובייקטיבית של הבודקים

של אבני דרך מועדיהןמדדים הקשורים ב(milestones )בבדיקות

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

(K2דיווח על בדיקות ) .5.3.2

, כולל:בדיקותה מאמץמתייחס לסיכום המידע אודות דיווח על בדיקות

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

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

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

מופיעים בתקן לתיעוד בדיקות תוכנה בדיקותשל דו"ח סיכום המבנה והסעיפים

(IEEE Std 829-1998).

המדדים יש לאסוף במהלך רמת הבדיקה ובסופה, על מנת להעריך את: את

לרמת הבדיקה הנדונה בדיקותיעדי ה התאמתם של

התאמת גישות הבדיקה שננקטו

ןביחס ליעדיה בדיקותיעילות ה








(K2בקרת בדיקות ) .5.3.3

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

מחזור חיי התוכנה.ב אחרתאו משימה

להלן דוגמאות לפעולות בקרת בדיקות:

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

עדוף מחדש של בדיקות בעקבות התממשות סיכון צפוי )למשל איחור באספקת ית התוכנה(

בעקבות שינוי בזמינות סביבת העבודה סדר ביצוע הבדיקותאו ב בלו"ז שינוי

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

ה( לפני קבלתם אל תוך הגרסconfirmation: אישור)בדיקות








דקות K2)) 12ניהול תצורה 1.4

מושגים

(version control) (, בקרת גרסאותconfiguration management) ניהול תצורה

רקע

מוצרי התוכנה או המערכת של ( integrityשלמות )הניהול תצורה מיועד לבסס ולשמר את

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

מצד הבדיקות, ניהול תצורה קשור להבטחת הנקודות הבאות:

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

לכל אורך תהליך ( באופן שמאפשר נֱֶעָקבּותtest objects)מושאי בדיקה,

הבדיקות

משמעית במסמכי -ופריטי התוכנה המזוהים יש הפניה מזהה חד לכל המסמכים בדיקותה

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

.והבדיקה עצמה (test harnessהבדיקה )

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








דקות K2)) 12סיכון ובדיקות 1.1

מושגים

-risk) (, בדיקות מבוססות סיכוןproject risk) (, סיכוני פרויקטproduct risk) סיכוני מוצרbased testing)

רקע

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

גרם כתוצאה מהארוע.ת)הנזק( ש

(K2סיכוני פרויקט ) .5.5.1

יעדיו, למשל:לעמוד ביכולת הפרויקט ל סיכונים הנוגעיםהינם סיכוני פרויקט

:גורמים ארגוניים

o ובאנשי צוותבמיומנות, בהכשרה סריםוח

o בתחום משאבי אנוש בעיות

o כמו:של פוליטיקה ארגוניתבעיות ,

את צרכיהם ואת תוצאות הבדיקותלתקשר קושי של הבודקים באופן אפקטיבי

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

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

:בעיות טכניות

o קושי בהגדרת הדרישות הנכונות

o בדרישות כתוצאה מאילוצים קיימים עמידהה-היקף אי

o אינה מוכנה בזמן בדיקותסביבת ה

o במרת נתונים, האיחור ב( תכנון ופיתוח הגירהmigrationו )בדיקת ב

(conversion) הנתונים/ כלי ההמרה המרת

o התצורה, נתוני הבדיקות והבדיקות העיצוב, הקוד, נתונינמוכה של איכות

:בעיות מצד ספקים

o (תבהתחייבויואי עמידה )כגון: כשל צד שלישי

o בעיות חוזיות

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

דורש (IEEE Std 829-1998מוכרים היטב לניהול פרויקטים. תקן תיעוד בדיקות תוכנה )

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








(K2סיכוני מוצר ) .5.5.2

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

ביניהם נמנים:

אספקת תוכנה שנוטה להכשל

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

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

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

תוכנה שאינה מבצעת את הפעולות שלשמן נועדה

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

השלילית.

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

.(contingency plansושל מימוש תכניות חירום )הסרת פגמים קריטיים

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

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

מבוססת סיכונים אפשר להשתמש בסיכונים שזוהו כדי:בגישה

טכניקות הבדיקהאת לבחור

לקבוע את היקף הבדיקות אותן יש לבצע

לתעדף את הבדיקות במטרה לגלות פגמים קריטיים מוקדם ככל האפשר

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

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

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

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

להחליט באילו סיכונים חשוב לטפל

ליישם פעולות להתמודדות עם סיכונים אלה

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








דקות K3)) 40ניהול אירועים 1.6

מושגים

,(incident report) ח אירועים", דו (incident logging) רישום אירועים

(incident management) ניהול אירועים

רקע

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

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

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

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

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

אלה היעדים של דוחות אירועים:

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

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

(system under testואחר התקדמות הבדיקות )

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

לכלול: אירוע עשוייםופיעים בדוח הפרטים המ

אליו הוא שייךהארגון ו , שם מחבר הדוחכתיבת הדוחתאריך

תוצאות צפויות ותוצאות בפועל

( פרטים מזהים של פריט הבדיקותtest item) / פריט התצורה(configuration item )בדיקותהת ושל סביב

נצפה האירוע וב - במחזור חיי התוכנה או המערכת - שלבה

,תיאור של האירוע, אשר יאפשר את שחזורו ופתרונו( כולל לוגיםlogs), תוכן

(screenshots) מסך צילומיאו (,dump)קבצי בסיסי נתונים

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

חומרת ההשפעה (impact) על המערכת

תיקוןדחיפות או סדר עדיפות ל

מצב האירוע (status.) פתוח, דחוי :למשל (deferred)כפול , (duplicate) ,

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

מסקנות, המלצות, אישורים

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

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

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








. (IEEE Std 829-1998 ) בתקן תיעוד בדיקות תוכנה מצוי מבנהו של דו"ח אירועים


5.1.1 Black, 2001, Hetzel, 1988

5.1.2 Black, 2001, Hetzel, 1988

5.2.5 Black, 2001, Craig, 2002, IEEE Std 829-1998, Kaner 2002

5.3.3 Black, 2001, Craig, 2002, Hetzel, 1988, IEEE Std 829-1998

5.4 Craig, 2002

5.5.2 Black, 2001 , IEEE Std 829-1998

5.6 Black, 2001, IEEE Std 829-1998








דקות 82 (K2כלים תומכי בדיקות ) .6

יעדי הלימוד של פרק כלים תומכי בדיקות

מתארים את הפעולות שתוכל לעשות לאחר השלמת כל יחידה. דיעדי הלימו

(K2) סוגים של כלי בדיקה 6.1

1LO-6.1. לפי מטרותיהם ולפי פעילויות סווג את הסוגים השונים של כלי בדיקות

(K2תהליך הבדיקה הבסיסי ומחזור חיי התוכנה )

1LO-6.1. הסבר את המושג כלי בדיקה ואת המטרה של שימוש בכלים לתמיכה

5(K2) בבדיקות

(K2שימוש אפקטיבי בכלים: תועלת וסיכונים אפשריים ) 6.2

2LO-6.2. דיקות באוטומציה של הבוהסיכונים האפשריים היתרונותסכם את

(K2שימוש בכלים תומכי בדיקה )בו

3LO-6.2. פרט שיקולים מיוחדים בבחירה ובשימוש בכלים לביצוע בדיקות, לניתוח

(K1ולניהול בדיקות ) סטטי

(K1) כלי לארגון הכנסת 6.3

1LO-6.3. כלי אל תוך ארגון הכנסתיים של פרט את העקרונות המרכז (K1)

2LO-6.3. היתכנות והתאמה )הוכחת פרט את המטרות שלPOC: proof of concept ( לצורך הערכת כלים, ושל שלב הניסוי )פיילוט( להטמעתם

(K1)

3LO-6.3. דע שמעבר לרכישת כלי יש עוד מרכיבים הדרושים על מנת שהשימוש

(K1בכלי יהיה יעיל )

5 בוטל LO-6.1.2סעיף








דקות 41 (K2סוגים של כלי בדיקה ) 6.1

מושגים

כלי ניהול (, test management) כלי ניהול בדיקות(, probe effect) אפקט הגשושית

(, incident managementכלי ניהול אירועים )(, requirements management) דרישות

סטטי(, כלי ניתוח review) סקירה כלי(, configuration managementכלי ניהול תצורה )

(static analysis,) כלי מידול (modeling,) כלי עיצוב בדיקות (test design,) להכנת כלי

(, test executionכלי ביצוע בדיקות ) (,test-data preparationנתוני בדיקה )

(,test harnessרתמת בדיקות ), (unit-test framework toolלבדיקות יחידה )מערכת

(,securityכלי אבטחה ) (,coverageכיסוי )למדידת כלי (, test comparator) הכלי השווא

(, performance testing)כלי לבדיקת ביצועים (,dynamic analysisכלי ניתוח דינמי )

(,stress testing) מאמץכלי בדיקת (,load testing) כלי בדיקות עומסים

(debugging) באגים כלי לניפוי (,monitoring) כלי ניטור

תומכי בדיקות כלים .6.1.1

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

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

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

ביצוע הבדיקות

כלי העוקב אחרי פעולות : למשל .(exploration)כלים המשמשים לחקירה .3

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

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

להיות אחת או יותר מן המטרות הבאות, בהתאם ותלשימוש בכלים תומכי בדיקות עשוי

:להקשר

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

בדיקות וניטור

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

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

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

התוכנה בדיקות ( נפוץ בתחום test frameworks) מונח מסגרות בדיקהשימוש בהערה: ה

שונות לפחות:בשלוש משמעויות

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

ת נתוניםיהבדיקות; למשל מונח אוטומצייתסוג העיצוב של (data driven ,)

(keyword driven) מפתח-ת מילותימונח

שם כולל לתהליך ביצוע הבדיקות

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








(K2סיווג כלי בדיקה ) .6.1.2

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

לימודים זו הכלים מסווגים לפי פעילויות הבדיקה בהן הם תומכים.

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

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

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

שתנה כתוצאה מהפקודות הנוספות ( מactual timing)בפועל לדוגמא, תזמון המערכת

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

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

שלהלן.

(K1) כלים לתמיכה בניהול תהליך הבדיקה והבדיקות .6.1.3

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

כלי ניהול בדיקות

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

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

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

כלי ניהול דרישות

של הדרישות, כולל סדר (attributes)מפורטות הדרישות מהתוכנה, וכן התכונות בכלים אלה

לכל דרישה, ומאפשר (unique identifier)העדיפות של כל דרישה. הכלי מספק מזהה יחודי

בין דרישות לבדיקות. כלים אלה יכולים לסייע בזיהוי דרישות לא עקביות או tracing)) קישור

חסרות.

(ים)כלים למעקב אחר פגמ כלי ניהול אירועים

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

תמיכה בניתוח סטטיסטי.

כלי ניהול תצורה

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

( והתוכנות הנלוות, בעיקר כאשר בודקים על testware ,ותמכלול מרכיבי הבדיק)ּבֹוְדָקה ה

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

((compilers.'דפדפנים וכו ,

(K1סטטיות ) כלים לתמיכה בבדיקות .6.1.4

( לגילוי יותר cost effectiveמספקים שיטה יעילה מבחינה כלכלית ) כלי בדיקות סטטיות

.פגמים בשלבים מוקדמים של תהליך הפיתוח








(review)כלי סקירה

ובהנחיות סקירה. הם (checklistsביקורת )אלה תומכים בתהליכי הסקירה, ברשימות כלים

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

או מבוזרים גיאוגרפית.

כלי ניתוח סטטי )מ(

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

( וניתוח secure codingתמיכה באכיפת תקנים לכתיבת קוד )כולל כתיבת קוד מאובטח

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

(.complexityים שהם מספקים ביחס לקוד )למשל סיבוכיות בעזרת המדד

כלי מידול )מ(

בדיקת ל - PDM -כלים אלה משמשים לאימות מודלים של תוכנה )למשל, מודל נתונים פיזי

(, וזאת על relational database - נתונים טבלאי-מסדהקישורים שקיימים בין טבלאות של

. לעיתים קרובות כלים אלה מסייעים ביצירת (inconsistencyגילוי פגמים וחוסר עקביות )ידי

מקרי בדיקה המבוססים על המודל.

(K1י בדיקות )מיפרטכלים לתמיכה ב .6.1.5

כלי עיצוב בדיקות

( ו/ executableיקה שניתן להרצה )אלה משמשים לייצור קלט בדיקות, לייצור קוד בד כלים

, וזאת מתוך הדרישות, הממשקים הגרפיים, test oracles)) אורקלים לבדיקותלייצור או

(, או מן הקוד.עצמים, נתונים או מצביםמודלי העיצוב )

כלים להכנת נתוני בדיקה

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

( על מנת להגדיר נתוני בדיקות שישמשו במהלך ביצוע data transmissionsנתונים )

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

(.security through data anonymityשל אבטחת מידע )

(K1בהרצת בדיקות וברישום ) כלים לתמיכה .6.1.6

כלי הרצת בדיקות

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

בקלט ובתוצאות צפויות ( ותוך שימוש scripting language) תסריט בשפת תסריטים

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

( של ערכי נתונים בבדיקות, והתאמות parameterizationתומכים בשינוי פרמטרים )

(customizationאחרות של הבדיקות ) שפת תסריטיםבעזרת (scripting language או )

(.GUI-based configurationבאמצעות ממשק משתמש גרפי )

)מ(( לבדיקות יחידה harnessרתמה ) /מערכת

בבדיקת רכיבי מערכת או חלקים ממנה תמסייע( לבדיקות יחידה harnessרתמה ) /מערכת

הבדיקה. ההדמיה מושגת באמצעות על ידי הדמיה )סימולציה( של סביבת ההרצה של מושא

(.drivers( או מנהלי התקנים )stubs) ( כגון תותבים mock objectsאובייקטים מדומים )

כלי השוואה

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








, במיוחד במקרה שהוא ממוכן נפרד. כלי להשוואת בדיקות עשוי להשתמש באורקל בדיקות )אוטומטי(.

)מ(כיסוי למדידתכלים

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

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

ת אבטחהוכלים לבדיק

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

(, הרשאה authentication, אימות זהות )(data integrityמידע )שלמות , סודיות מידעעל

(authorization ,)( זמינותavailability) ואי-( איבוד הרשאותnon-repudiation כלי .)

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

(K1כלים לתמיכה בביצועים ובמעקב ) .6.1.7

כלי ניתוח דינמיים )מ(

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

(time dependencies( או דליפות זיכרון )memory leaks הכלים הללו בדרך כלל .)

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

(middleware.)

כלי בדיקות ביצועים/ עומסים/ מאמץ

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

(ramp-up pattern) ,תדירות וכן ה( והאחוז היחסי של התנועותtransactions ההדמיה .)

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

(.load generators) "עומסים

כלי ניטור

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

(K1כלים לתמיכה בצרכי בדיקה ספציפיים ) .6.1.8

הערכת איכות הנתונים

נתונים הם המוקד של פרויקטים מסוימים כמו למשל פרויקטים להמרת נתונים או הגירתם,

מאפייניהם של נתונים אלו נבדלים זה . (data warehousesני נתונים )ושל יישומים כגון מחס

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

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

.(usability) שימושיּותכלים אחרים קיימים לשם בדיקות








דקות 22 (K2אפקטיבי בכלים: תועלת וסיכונים ) שימוש 6.2

מושגים

מפתח-מילות מונחות(, בדיקות data-driven testingנתונים )-מונחותבדיקות

(keyword-driven testingשפת תסריטים ,) (scripting language)

(K2תועלת וסיכונים אפשריים בכלים לתמיכה בבדיקות )כל הכלים( ) .6.2.1

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

.ואפשרויות רבות, אך קיימים גם סיכונים

:שימוש בכליםמתועלת אפשרית

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

( עקביות וחזרתיותrepeatability ( טובות יותר )למשל, בדיקות המבוצעות על

ידי כלי באותו סדר ובאותה תדירות, ובדיקות המופקות מן הדרישות(.

ת )למשל, מדידות סטטיות, כיסוי(.הערכה נטולת פניו

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

יש למנות: בין הסיכונים בשימוש בכלים

וחות השימוש(.ציפיות לא מציאותיות מן הכלי )כולל תפקודיות ונ

אומדן-( חסרunderestimating) של הזמן, העלות והמאמץ הנדרשים להכנסתו

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

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

השימוש בכלי(.

של המאמץ שנדרש לתחזק את מה שהכלי מייצרחסר -אומדן.

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

הזנחת בקרת הגרסאות של( נכסי הבדיקהtest assets) כלי.הקשורים ל

פעולה הדדיתהזנחת קישוריות ובעיות ביכולת חיבור וב (interoperability בין )

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

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

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

בכלים חינמיים או כלים שמקורם הוא קוד-( פתוחopen source סיכון של :)

(suspensionהשעייה )הפסקת הפרויקט

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








(K1)מיוחדים עבור סוגי כלים מסוימים שיקולים .6.2.2

כלי ניהול בדיקות

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

(static analysis)כלי ניתוח סטטי

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

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

ההתראות.

כלי ביצוע בדיקות

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

(automated test scripts סוג זה של כלי דורש לעיתים קרובות מאמץ ניכר על מנת .)

להפיק ממנו תועלת משמעותית.

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

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

קלט הבדיקות )הנתונים(,פרידה את מ (data driven testing) נתונים-תיגישת בדיקות מונח

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

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

, בהן במקום להציב אוסף נתונים נתונים-קיימות גם שיטות אחרות ליישום טכניקות מונחות

( בתוך הגיליון האלקטרוני, מייצרים נתונים בשעת ההרצה באמצעות hard-codedקבועים )

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

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

(.seed, random seedבגרעין אקראיות )שימוש

מפתח המתארות פעולות שיש -הגיליון האלקטרוני מכיל מילות מפתח-ת מילותיבגישה מונח

( ונתוני בדיקה. הבודקים )גם אם אינם action wordsפעולה, -לנקוט בהן )מכונות גם מילות

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

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

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








דקות 11 (K1כלי לארגון ) הכנסת 6.1

מושגים

אין מושגים מיוחדים.

רקע

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

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

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

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

.(POCהוכחת היתכנות והתאמה )שימוש מעשי בכלי על ידי ביצוע מהלך של

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

ארגוניות-פניםזיהוי דרישות ( לאימוןcoaching( וחונכות )mentoring בשימוש )

בכלי.

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

מבוססת על נתוני פרויקט אמיתיתועלת -הערכת יחס עלות (concrete business case.)

הכנסת הכלי שנבחר אל הארגון מתחילה בתכנית ניסוי )פיילוט( בעלת היעדים הבאים:

.למידת פרטים רבים יותר אודות הכלי

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

קבלת החלטה לגבי שיטות מוסכמות לשימוש, ניהול, אחסון ותחזוקה של הכלי

למשל שיטה מוסכמת למתן שמות לקבצים (:test assetsנכסי הבדיקה )ושל

ולבדיקות, יצירת ספריות והגדרת המודולאריות של סדרות בדיקות.

.ניסיון להעריך אם התועלת הצפויה תושג בעלות סבירה

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

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

התאמת תהליכים ושיפורם על מנת שיתאימו לשימוש בכלי

הכשרה, תירגול, אימון וחונכות למשתמשים חדשים

הנחיות לשימוש בכליהגדרת

איסוף מידע אודות השימוש בפועל

השימוש בכלי והתועלת ממנו ניטור

תמיכה בצוות הבדיקות המשתמש בכלי

הפקת לקחים מפעילות כל הצוותים


6.2.2 Buwalda, 2001, Fewster, 1999

6.3 Fewster, 1999








רשימה ביבליוגרפית .7

תקנים

ISTQB Glossary of Terms used in Software Testing Version 2.1

[CMMI] Chrissis, M.B., Konrad, M. and Shrum, S. (2004) CMMI, Guidelines for Process Integration and Product Improvement, Addison Wesley: Reading, MA See Section 2.1

[IEEE Std 829-1998] IEEE Std 829™ (1998) IEEE Standard for Software Test Documentation See Sections 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6

[IEEE 1028] IEEE Std 1028™ (2008) IEEE Standard for Software Reviews and Audits See Section 3.2

[IEEE 12207] IEEE 12207/ISO/IEC 12207-2008, Software life cycle processes See Section 2.1

[ISO 9126] " ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality See Section 2.3

ספרים

[Beizer, 1990] Beizer, B. (1990) Software Testing Techniques (2nd edition), Van Nostrand Reinhold: Boston See Sections 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6

[Black, 2001] Black, R. (2001) Managing the Testing Process (3rd edition), John Wiley & Sons: New York See Sections 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6

[Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Automation, Addison Wesley: Reading, MA See Section 6.2

[Copeland, 2004] Copeland, L. (2004) A Practitioner’s Guide to Software Test Design, Artech House: Norwood, MA See Sections 2.2, 2.3, 4.2, 4.3, 4.4, 4.6

[Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing, Artech House: Norwood, MA See Sections 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4

[Fewster, 1999] Fewster, M. and Graham, D. (1999) Software Test Automation, Addison Wesley: Reading, MA See Sections 6.2, 6.3

[Gilb, 1993]: Gilb, Tom and Graham, Dorothy (1993) Software Inspection, Addison Wesley: Reading, MA See Sections 3.2.2, 3.2.4

[Hetzel, 1988] Hetzel, W. (1988) Complete Guide to Software Testing, QED: Wellesley, MA See Sections 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 4.1, 5.1, 5.3

[Kaner, 2002] Kaner, C., Bach, J. and Pettticord, B. (2002) Lessons Learned in Software Testing, John Wiley & Sons: New York See Sections 1.1, 4.5, 5.2

[Myers 1979] Myers, Glenford J. (1979) The Art of Software Testing, John Wiley & Sons: New York See Sections 1.2, 1.3, 2.2, 4.3

[van Veenendaal, 2004] van Veenendaal, E. (ed.) (2004) The Testing Practitioner (Chapters 6, 8, 10), UTN Publishers: The Netherlands.

See Sections 3.2, 3.3








הקורס רקע לתוכנית - נספח א' .8

ההסטוריה של מסמך זה

קבוצת העבודה שמונתה לצורך כך על ידי ארגון בידי 1114-1122מסמך זה נערך בין השנים

ISTQB (International Software Testing Qualifications Board בשלב ראשון המסמך .)

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

ITCBבידי צוות מיוחד שמונה לשם כך על ידי ארגון 1121המסמך תורגם לעברית בשנת

(Israel Testing Certification Board.)

מסמך זה הוא תוכנית הקורס לתעודת ההסמכה הבינלאומית לבדיקות תוכנה ברמת הבסיס,

ISTQBרמת ההסמכה הבינלאומית הראשונה המוכרת על ידי ארגון שהיא

(www.istqb.org) כפי שתורגם לעברית בידי ארגוןITCB (www.itcb.org.il).

:יעדי ההסמכה ברמת הבסיס

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

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

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

במקצוע הבדיקות(

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

להצביע על נושאים בתחום הבדיקות שהם רלוונטיים ובעלי ערך לתעשיה

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

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

(2221בסולנטונה, נובמבר ISTQBההסמכה הבינלאומית )על פי מפגש יעדי

בין מיומנויות בדיקה במדינות שונות לאפשר השוואה

התוכנה לעבוד במדינות שונות ילהקל על בודק

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

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

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

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

זה

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

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

בין מדינותלאפשר שיתוף ידע ומשאבים

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

http://www.istqb.org/








סף להסמכה זו דרישות

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

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

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

המקומי שלארגון הבוגרי קורס אשר מוכר מטעם ISTQB כמתאים לתוכנית

ISTQBהלימודים ודרישות אחרות של

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

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

, שהוא ISEB (Information Systems Examination Board)במסגרת 2112תוכנה בשנת

בשנת (.www.bcs.org.uk/iseb) הועד לבחינת מערכות מידע של איגוד המחשבים הבריטי

בגרמניה לתמוך בתוכנית להסמכת בודקים גרמנים ASQF, החל ארגון 1111

(www.asqf.deתוכנית קורס זה מבוססת .) על התוכניות שלISEB ושלASQF אך החומר

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

או של ארגון מקומי מוכר על ASQFאו ISEBתעודת הסמכה לבדיקות תוכנה ברמת בסיס )של

כשוות ערך לתעודה מוכרת( שניתנה לפני השקתה של התעודה הבינלאומית ISTQBידי

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

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

. חובותיהם של הארגונים (ITCB)בישראל ארגון ISTQBלבדיקות תוכנה המוכר על ידי ארגון

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

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

http://www.asqf.de/








יעדי הלימוד/ הרמה הקוגניטיבית של הידיעה –נספח ב' .9

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

(K1: לזכור )1רמה

יזהה ויזכור את המונח או המושג.המועמד

לזכור, לאחזר, לזהות, לדעת מילות מפתח:

דוגמא

( מוגדר כ:failureיזהה ש"כשל" ) המועמד

של שירות למשתמש הקצה או לכל בעל עניין אחר""אי הגשה

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

(K2: להבין )2רמה

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

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

דוגמא

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

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

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

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

תפקודיים-דמיון: בדיקות של יותר מרכיב אחד, וכן האפשרות לבדוק היבטים לא

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

(K3: ליישם )3רמה

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

ליישם, לבצע, להשתמש, לפעול על פי נוהל, ליישם נוהל מילות מפתח:

דוגמא

תקפות-שקילות תקפות ובלתי מחלקותעבור גבוללזהות ערכי

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








(K4: לנתח )4רמה

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

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

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

דוגמא

לנתח את סיכוני המוצר ולהציע פעולות מנע ופעולות מתקנות למיתון הסיכון

לתאר אילו חלקים מדו"ח האירועים הם עובדתיים ואילו מהם הוסקו מתוך התוצאות

גרפיהביבליו

)עבור הרמות הקוגניטיביות של יעדי הלימוד(

Anderson, L. W. and Krathwohl, D. R. (eds) (2001) A Taxonomy for Learning, Teaching, and

Assessing: A Revision of Bloom's Taxonomy of Educational Objectives, Allyn & Bacon








ISTQBהכללים המשמשים את ארגון –נספח ג' .12

ברמת הבסיסתוכנית הלימוד

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

כללי .12.1.1

SG1 או יותר( חודשי ניסיון 1-1: על התוכנית להיות מובנת וקליטה על ידי אנשים בעלי(

[חודשים-1] .בבדיקות

SG2 .[מעשית]: על התוכנית להיות מעשית יותר מאשר תיאורטית

SG3[ברורה] .משמעית עבור קוראיה-: על התוכנית להיות ברורה וחד

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

[קלה לתרגום]

SG5[איתאמריק-אנגלית] .: התוכנית תיכתב באנגלית אמריקאית

תוכן עדכני .12.1.2

2SC :ותהמיטביהשיטות את ולשקף מעודכנים מושגים לכלול התוכנית על (best practices )

[עדכנית]. כללית הסכמה יש ןעליה

1SCזמן, כגון: תנאי השוק הנוכחיים, על -נושאים תלוייל התייחסויות : על התוכנית לצמצם

[)חיי מדף .חיי מדף של שלוש עד חמש שנים לאפשר להמנת

יעדי לימוד .12.1.3

2LO2רמה קוגניטיבית ]טים אותם יש להכיר/ לזכור ילהבחין בין פר : על יעדי הלימודK ,)

( 1Kלדעת ליישם ) המועמדטים שעל י(, פר1Kלהבין ברמת מושגית ) המועמדטים שעל יפר

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

(4K .)[רמת ידיעה]

1LO .[עקביות]: על תיאור התוכן לעלות בקנה אחד עם יעדי הלימוד

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

[מבחן-LO]. על מנת להדגים את יעדי הלימוד

נה כללימב .12.1.4

2ST ,על מבנה התוכנית להיות ברור ולאפשר הפניה לחלקיה השונים מתוך פרקי התוכנית :

[הפניות]מתוך שאלות מבחנים ומתוך מסמכים רלוונטיים אחרים.

1ST .[חפיפה]: יש לצמצם את החפיפה בין פרקי התוכנית

1ST[מבנה עקבי] .: מבנה כל פרקי התוכנית יהיה אחיד

4ST .[גירסה]: על התוכנית לכלול מספר גירסה, תאריך הוצאה ומספר עמוד על כל דף

2ST על התוכנית לכלול קווי הנחיה לגבי פרק הזמן שיש להקדיש לכל פרק )אשר ישקף את :

[זמן מוקדש]חשיבותו היחסית של כל נושא(.








הפניות .12.1.5

2SRסייע לנותני ההכשרה : יש להציג מקורות והפניות עבור המושגים בתוכנית על מנת ל

[הפניות]למצוא מידע נוסף בנושא.

1SR במקרים בהם לא ניתן להצביע בקלות על מקור ברור, על התוכנית להכיל מידע יותר :

[פירוט ללא הפניות]מפורט.

מקורות מידע .12.1.6

:למונחי בדיקותמונחים המופיעים בתוכנית מוגדרים במילון ISTQB Standard glossary of terms used in Software Testing .

.ISTQBניתן לקבל את המילון מ

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








ה לספקי ההדרכההודע -ד' נספח .11

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

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

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

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

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

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

נחוץ תרגול מעשי אותו יש לכלול בחומרי ההדרכה. 4Kו 1Kלכל יעדי הלימוד בדרגת








הערות למהדורות הקודמות באנגלית - נספח ה' .12

Release 2010

1. Changes to Learning Objectives (LO) include some clarification

a. Wording changed for the following LOs (content and level of LO remains unchanged): LO-1.2.2, LO-1.3.1, LO-1.4.1, LO-1.5.1, LO-2.1.1, LO-2.1.3, LO-2.4.2, LO-4.1.3, LO-4.2.1, LO-4.2.2, LO-4.3.1, LO-4.3.2, LO-4.3.3, LO-4.4.1, LO-4.4.2, LO-4.4.3, LO-4.6.1, LO-5.1.2, LO-5.2.2, LO-5.3.2, LO-5.3.3, LO-5.5.2, LO-5.6.1, LO-6.1.1, LO-6.2.2, LO-6.3.2.

b. LO-1.1.5 has been reworded and upgraded to K2. Because a comparison of terms of defect related terms can be expected.

c. LO-1.2.3 (K2) has been added. The content was already covered in the 2007 syllabus.

d. LO-3.1.3 (K2) now combines the content of LO-3.1.3 and LO-3.1.4.

e. LO-3.1.4 has been removed from the 2010 syllabus, as it is partially redundant with LO-3.1.3.

f. LO-3.2.1 has been reworded for consistency with the 2010 syllabus content.

g. LO-3.3.2 has been modified, and its level has been changed from K1 to K2, for consistency with LO-3.1.2.

h. LO 4.4.4 has been modified for clarity, and has been changed from a K3 to a K4. Reason: LO-4.4.4 had already been written in a K4 manner.

i. LO-6.1.2 (K1) was dropped from the 2010 syllabus and was replaced with LO-6.1.3 (K2). There is no LO-6.1.2 in the 2010 syllabus.

2. Consistent use for test approach according to the definition in the glossary. The term test strategy will not be required as term to recall.

3. Chapter 1.4 now contains the concept of traceability between test basis and test cases.

4. Chapter 2.x now contains test objects and test basis.

5. Re-testing is now the main term in the glossary instead of confirmation testing.

6. The aspect data quality and testing has been added at several locations in the syllabus: data quality and risk in Chapter 2.2, 5.5, 6.1.8.

7. Chapter 5.2.3 Entry Criteria are added as a new subchapter. Reason: Consistency to Exit Criteria (-> entry criteria added to LO-5.2.9).

8. Consistent use of the terms test strategy and test approach with their definition in the glossary.

9. Chapter 6.1 shortened because the tool descriptions were too large for a 45 minute lesson.

10. IEEE Std 829:2008 has been released. This version of the syllabus does not yet consider this new edition. Section 5.2 refers to the document Master Test Plan. The content of the Master Test Plan is covered by the








concept that the document “Test Plan” covers different levels of planning: Test plans for the test levels can be created as well as a test plan on the project level covering multiple test levels. Latter is named Master Test Plan in this syllabus and in the ISTQB Glossary.

11. Code of Ethics has been moved from the CTAL to CTFL

Release 2011

Changes made with the Maintenance Release 2011

1. General: Working Party replaced by Working Group

2. Replaced post-conditions by postconditions in order to be consistent with the ISTQB Glossary 2.1.

3. First occurrence: ISTQB replaced by ISTQB®

4. Introduction to this Syllabus: Descriptions of Cognitive Levels of Knowledge removed, because this was redundant to Appendix B.

5. Section 1.6: Because the intent was not to define a Learning Objective for the Code of Ethics, the cognitive level for the section has been removed.

6. Section 2.2.1, 2.2.2, 2.2.3 and 2.2.4, 3.2.3: Fixed formatting issues in lists.

7. Section 2.2.2 The word failure was not correct for “…isolate failures to a specific component …”. Therefore replaced with “defect” in that sentence.

8. Section 2.3: Corrected formatting of bullet list of test objectives related to test terms in section Test Types (K2).

9. Section 2.3.4: Updated description of debugging to be consistent with Version 2.1 of the ISTQB Glossary.

10. Section 2.4 removed word “extensive” from “includes extensive regression testing”, because the “extensive” depends on the change (size, risks, value, etc.) as written in the next sentence.

11. Section 3.2: The word “including” has been removed to clarify the sentence.

12. Section 3.2.1: Because the activities of a formal review had been incorrectly formatted, the review process had 12 main activities instead of six, as intended. It has been changed back to six, which makes this section compliant with the Syllabus 2007 and the ISTQB Advanced Level Syllabus 2007.

13. Section 4: Word “developed” replaced by “defined” because test cases get defined and not developed.

14. Section 4.2: Text change to clarify how black-box and white-box testing could be used in conjunction with experience-based techniques.

15. Section 4.3.5 text change “..between actors, including users and the system..” to “ …between actors (users or systems), … “.

16. Section 4.3.5 alternative path replaced by alternative scenario.








17. Section 4.4.2: In order to clarify the term branch testing in the text of Section 4.4, a sentence to clarify the focus of branch testing has been changed.

18. Section 4.5, Section 5.2.6: The term “experienced-based” testing has been replaced by the correct term “experience-based”.

19. Section 6.1: Heading “6.1.1 Understanding the Meaning and Purpose of Tool Support for Testing (K2)” replaced by “6.1.1 Tool Support for Testing (K2)”.

20. Section 7 / Books: The 3rd edition of [Black,2001] listed, replacing 2nd edition.

21. Appendix D: Chapters requiring exercises have been replaced by the generic requirement that all Learning Objectives K3 and higher require exercises. This is a requirement specified in the ISTQB Accreditation Process (Version 1.26).

22. Appendix E: Th changed learning objectives between Version 2007 and 2010

are now correctly listed.








מפתח

IEEE Std 829.......... 42 ,52 ,51 ,54 ,57 ,62 ,72

ISO 9126 ....................................... 12 ,29 ,72

PDM ........................................................ 67

RAD ......................................................... 21

RUD ......................................................... 21

71, 72, 65, 56, 53, 45, 32, 15 ........ אוטומציה 68, 67 ..................................... בדיקות אורקל 61, 18, 11, 12, 7 .................................. איכות

21 ....................................... הבדיקות איכות 12, 12 .................................. הנתונים איכות 21, 21 .................................. התוכנה איכות

22 ........................................ איכות הבטחת 21, 17, 15 ........................................... אימות

בדיקות גם ראו, 53, 25, 24 ............. אינטגרציה אינטגרציה 11 ....................... המערכת ברמת אינטגרציה 12 ................................. בשלבים אינטגרציה

42 ...................................... אינטגרציה פגמי 62, 14 .................................................. אירוע 11 .................................... אירועים ניהול כלי

11 ......................................... אירועים ניהול 12, 11 ............................................... סיכון 41 ........................................... בדיקה תנאי

62, 36, 29, 28, 22, 12 ......................... אישור 17 .................................................... תלות-אי

57, 55, 36, 35, 14, 12 ....... ליציאה מידה אמות 54 .................................... לכניסה מידה אמות

55, 54 ............................. בדיקות אסטרטגיית 21 ......................................... בדיקות מוביל

66, 65 ................................... הגשושית אפקט 52 ............................................. בדיקות ארגון

29, 25, 24, 22, 15 ..................... ארכיטקטורה 13 ................................ שגיאות העדר אשליית

12, 9 ...................................................... באג 68, 29, 28 ............................. אבטחה בדיקות 75, 44, 24, 22 ................... אינטגרציה בדיקות

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

14 .......................................... בדיקה רמות 14 .......................................... המערכת של 14 ............................................. רכיבים של

58, 28, 15, 14 .......................... אישור בדיקות 27, 23 ...................................... אלפא בדיקות 29, 28 .................................... אמינות בדיקות 27, 23 ........................................ בטא בדיקות 68, 65, 29, 28 ....................... ביצועים בדיקות 38, 33, 32, 12 ....................... דינמיות בדיקות 44 ................................. מצבים החלף בדיקות בדיקות גם ראו, 57, 29, 28, 12 . חוזרות בדיקות

אישור 23 .............................................. חוסן בדיקות 56, 48 .................................... חוקרות בדיקות 44 ............................. החלטה טבלאות בדיקות רכיבים בדיקות ראו ..................... יחידה בדיקות-לא בדיקות ראו........... פונקציונליות-לא בדיקות

תפקודיות 29, 22 ........................... תפקודיות-לא בדיקות

41 ............................ שחורה קופסא טכניקות 12 ........................................... בדיקות סוגי

29, 28 ...................................... מאמץ בדיקות מבנה מבוססות בדיקות

41, 41 .......................................... טכניקות 41 ......................................................רקע 45 ............................ מיפרט מבוססות בדיקות

41 ............................................... מאפיינים 61, 56 ......................... סיכון מבוססות בדיקות מבוססות טכניקות ראו .. ניסיון-מבוססות בדיקות

ניסיון 29, 23 .................................... מבניות בדיקות 72, 69 ................ מפתח-מילות מונחות בדיקות 12 ....................................... מחמירות בדיקות 13 .......................................... ממצות בדיקות 54, 25, 21 .............................. מערכת בדיקות

12 ...................................... הבדיקות הרכב 45, 44 ............................ שימוש מקרי בדיקות 29, 28 ..................................... ניידות בדיקות, 56, 31, 29, 28, 21, 22, 15, 14 .נסיגה בדיקות

69 33, 12 ................................... סטטיות בדיקות 11 ............................................. בדיקה כלי

68, 65 ................................... עומסים בדיקות 52 ....................................... עצמאיות בדיקות 26, 21 ...................................... קבלה בדיקות

11 ....................................... במפעל בדיקות 11 ........................................ חוזיות בדיקות 11, 11 .......... המשתמש ידי על קבלה בדיקות 11 ................................. רגולטוריות בדיקות 21 ................................... תפעוליות בדיקות

43, 28 ............................ לבנה קופסה בדיקות 41 ......................................................רקע 68, 46, 29, 28, 24, 23, 21 ...... רכיבים בדיקות 27 ............................................. שדה בדיקות 28 ...................................... שימושיות בדיקות 31, 22, 12 ............................. תחזוקה בדיקות בדיקות מובל פיתוח ראו ............ תחילה בדיקות 31, 26, 12 .......................... תפעוליות בדיקות 28, 22 ................................ תפקודיות בדיקות 46 ......................................... משפטים בדיקת

73, 52, 52, 22, 17, 9 ............................ בודק 21 ...................................... הבודק משימות 12 ................................................. סקירות

21 ................................................ אתי קוד הבדיקה מרכיבי מכלול ראו .................... ּבֹוְדָקה 52 ........................................ עצמאיים בודקים

14 ............................................ בדיקות ביצוע 11 ..................................................... כלים 41 .............................................. זמנים לוח

21 ......................................... בדיקות מוביל 12 ....................................... בדיקה מסגרות 22 .....................................עיקריות משימות

36, 32 ............................................... ביקורת 11 ................................................... מעקב

12 ........................................... סקירות סוגי 21 ......................................... טיפוס-אב בניית 42, 26, 23, 14 ........................ הבדיקות בסיס 62, 16, 11 ..................................... עניין בעלי

58, 14 ......................................בדיקות בקרת 59 ........................................... גרסאות בקרת








72 .................................. נתונים-מונחית גישה 61 .................... סיכונים-מבוססת בדיקות גישת 55, 54, 21 .............................. הבדיקות גישת

63, 62, 51 ................................. אירועים ח"דו 57, 51, 14 ........................ בדיקות סיכום ח"דו

57 ........................................ בדיקות על דיווח 36, 34, 32 ..................................... מודרך דיון

25, 12 ............................................... דרישות 23, 22 ........................... תפקודיות-לא דרישות 25, 23 ................................ תפקודיות דרישות 68, 31, 27, 22 ..................................... הגירה

71, 64 ................................ לארגון כלי הכנסת 55, 52 ........................... העבודה היקף הערכת 34 ...................................................... התנעה

62, 57, 51 ........................ הבדיקות התקדמות 56, 48 ........................ ליקויים מוכוונת התקפה

41, 38 ....................................... בקרה זרימת 12 ..................................................... מודל 12 ............................................ סטטי ניתוח

41 .................................................. תרשים 44 .......................................... שקילות חלוקת

44 ........................................ החלטה טבלאות 43, 41, 26 ................. מבנה מבוססות טכניקות

41 ............................................... מאפיינים 44, 43, 28 ............... מיפרט מבוססות טכניקות 56, 48, 43 ................. ניסיון מבוססות טכניקות 42 .......................................... טעויות ניחוש 72 .............................. נתונים-מונחות טכניקות מבוססות טכניקות ראו ..... לבנה קופסה טכניקות מבנה גם ראו, 44, 43, 42 ...... שחורה קופסה טכניקות

מיפרט מבוססות טכניקות 31 ......................................................... טלאי 12, 9 .................................................... טעות

21 ....................................... לפגמים גורמים 42 .............................................בדיקות יישום

22 ..................................... עיקריות משימות 53 .......................................... הבדיקות יישום 12, 9 .......................................... בדיקות יעדי

21 .................................. ליציאה מידה אמות 77, 75, 64, 52, 42, 32, 22, 9 ....... הלימוד יעדי

42, 29 ................................................... כיסוי 21, 24 ............................................ בדיקות 41 ................................................. דרישות

41, 42 .......................................... החלטות החלטות כיסוי ראו ........................ הסתעפויות

42 ..................................... החלטה טבלאות 12 .................................. כיסוי למדידת כלים

41, 42 .......................................... משפטים 41 ................................................... תנאים

66, 55, 46, 29, 28 ........................... קוד כיסוי 65, 64 ........................................... בדיקה כלי

11 ............................................... כלים סוגי 66 ....................................... אירועים ניהול כלי

11 ....................................... וסיכונים תועלת 72, 66, 65 ........................... בדיקות ניהול כלי 66, 65 ................................. דרישות ניהול כלי 68, 65 ............................................. ניטור כלי 68 ...................................... דינמיים ניתוח כלי 72, 67, 38 ............................. סטטי ניתוח כלי 67, 65 ........................................... סקירה כלי

68 ................................ ביצועים לבדיקות כלים

66 ............................ פגמים אחר למעקב כלים 67, 66, 64 ................... בבדיקות לתמיכה כלים

11 ...................................... וסיכונים תועלת 11 ............................................... לבדוק כמה 22, 12, 12, 9 ......................................... כשל

21 ................................. כשל מבוססת גישה 21 ........................................... כשלים זיהוי 11 ................................... אירועים ניהול כלי

11 ....................................... שלישי צד כשל 21 ........................................... תפעולי כשל

12 ................................. סביבה תלויי כשלים 12 ............................................ מוצר סיכוני

11 ....................................... סטטיות שיטות 21 ......................................... כשלים שיעור

57, 55, 13 ............................. הבדיקות מאמץ 51, 34 ................................................... מדד

12 ......................................... מדדים איסוף 22 ................................. ליציאה מידה אמות

22 .................. הבדיקות עבודת היקף הערכת 21 ................ הבדיקות התקדמות אחר מעקב 11, 12 ..................................... סטטי ניתוח

38 ....................................................... מהדר 52, 52 ...................................... בדיקות מוביל

V ..................................................... 21 מודל

21, 22 ......................................... פיתוח מודל V ................................................. 12 מודל

12 ............... מצטברים בסבבים מחזורי פיתוח 65, 49 ...................................... נתונים-מונחה

31, 22 ........................................... מדף מוצר 68 .......................................... עומסים מחוללי

אוטומציה ראו .......................................... מיכון מפתח-מילות

11 .......................................... בדיקה גישת 12 ............................................. בדיקה כלי 35, 21 .................................... דרישות מיפרט 42 .................................. בדיקה מקרה מיפרט 28, 25 .................................... תפקודי מיפרט 66, 16, 14 ................... הבדיקה מרכיבי מכלול

24 .......................................... למעלה מלמטה 24 .......................................... למטה מלמעלה

מתאם גם ראו, 62, 52 ................ בדיקות מנהל 23 ............................................... התקן מנהל

24 .............................. יחידה לבדיקות מערכת 42, 42, 15, 12 ........................... בדיקה מקרה

11 ....................................... רכיבים בדיקות 41 ........................... בדיקות לעיצוב טכניקות

21 ..................................... להתקדמות מדד 45, 44, 24 ................................. שימוש מקרה 52, 36, 35, 34 ..................................... מתאם

54, 52, 52, 42, 42, 15, 14 .......... בדיקות נוהל 62, 51 ...................................... אירועים ניהול

11 ................................... אירועים ניהול כלי 52 ............................................. בדיקות ניהול

11 ..................................................... כלים 21 ................................................ אתי קוד 66 ............................................ דרישות ניהול 59 .............................................. תצורה ניהול

11 ..................................... תצורה ניהול כלי 56, 17 ...................................... שגיאות ניחוש 68, 57, 14 ................................ בדיקות ניטור 65 ,29, 24, 12, 9 ......................... באגים ניפוי

42, 22, 15 ................................ בדיקות ניתוח








31 ............................................ השפעה ניתוח 41 ........................................ בדיקות פיתוח

64, 33, 32 ................................... סטטי ניתוח 11, 11, 12 .......................... סטטי ניתוח כלי

12 ................................................... מהדר 12 ........................ הנחשפים אופייניים פגמים

12 ...................................................... רקע 51, 25, 13 ................................ סיכונים ניתוח 44, 42 ................................... גבול ערכי ניתוח

59, 42, 42 ......................................... ֶנֱעָקבּות 54, 15, 14 ................................. בדיקות נתוני

11 ......................................... להכנתם כלים 25, 23 ...................................... בדיקה סביבת

24 ................................. לכניסה מידה אמות 16 ............................................ בדיקה סגירת 14 ............................................ בדיקות סדרת

בדיקות סוגי 12 ............................................ בדיקה יעדי

35, 34 ................................................... סוקר 38 ................................................... סיבוכיות

69 ................................. בכלים השימוש סיכוני 61, 62, 51 ................................... מוצר סיכוני 62, 51 ...................................... פרויקט סיכוני 36, 34, 32 ................................. טכנית סקירה 35, 34, 32 .......................... רשמית לא סקירה 34, 32 ..................................... רשמית סקירה

12 ................................................... מעקב 12 .......................... אחריות ותחומי תפקידים

35, 34, 32 ......................................... סקירות 11 ....................... להצלחתן התורמים גורמים

11 ...................................................... רקע 36, 34 .................................... עמיתים סקירת 42 ............................................ בדיקות עיצוב

41 ................................................ טכניקות 11 ..................................................... כלים

41 ....................................... ניסיון מבוססות 42 ........................................... שימוש מקרי

22 ..................................... עיקריות משימות 52 .................................................... עצמאות

21 ...................... העצמאית הבדיקה חסרונות 21 .................................................אתי קוד

21 ......................................... הבודק תפקיד 13 .......................................... בדיקה עקרונות

44, 42 ............................................ גבול ערכי 62, 29, 15, 12, 9 .................................... פגם

22 ....................................................... פיתוח 42 ............................................בדיקות פיתוח 21 .......................................... בסבבים פיתוח 21 ................................... מהיר יישומים פיתוח 24, 23 ............................. בדיקות מובל פיתוח

22, 17 ....................................... תוכנה פיתוח V ................................................. 12 מודל

12 .................................................. מודלים 12 ....................................... בסבבים פיתוח

69, 29 ...................................... הדדית פעולה 13 ....................................... ההדברה פרדוקס 57, 55 ................................... הפגמים צפיפות 44, 43, 42, 28 ......................... שחורה קופסה 62 ........................................... אירועים רישום 14 ........................................... בדיקות רישום

53, 52, 49, 47 ............................. בדיקה רמת V ................................................. 12 מודל 11 .................................. טובה בדיקות רמת 11 ......................................................רקע

24 ..................................... תנועות עיבוד רצף 36, 35 .................................... ביקורת רשימת

36, 35 ................................................... רשם 65, 15 ..................................... בדיקות רתמת 12, 9 .................................................. שגיאה 11 ............................................. הבעיה שורש

33, 32 .................................... סטטיות שיטות 12 .................................................. שימושיות 68, 52 ............................................ שימושיּות

62, 59, 31, 28, 22, 16 ....................... שינויים 57 ............................................. כשלים שיעור 21 ............................................ הבדיקה שלבי 72, 67 .................................... תסריטים שפת

27 ............................... ללקוח מותאמת תוכנה 14 .......................................... בדיקות תוכנית 69 ............................... בכלים משימוש תועלת

62, 42 .................................... צפויות תוצאות 67, 23 .................................................. תותב 35 ........................................... אחריות תחומי

38, 28, 12 ....................................תחזוקתיות 11 .............................. תפקודיות לא בדיקות

21 ....................................................... תיקוף 62, 54, 53, 23, 14 .................... בדיקות תכנון

42 .................................. בדיקות ביצוע תכנית 42 .............................................. בדיקה תנאי

42 .......................................... בדיקות תסריט 11 .................................... בדיקות ביצוע כלי

72 ........................................... מוקלט תסריט 61, 23 ............................................ תפקודיות 52 ............................ אחריות ותחומי תפקידים

12 ....................................................... תקלה תקן

IEEE Std 829. 41 ,21 ,22 ,24 ,21 ,11 ,11 ,11

ISO 9126 ................................ 21 ,11 ,11 45 .................................. מצבים החלף תרשים

ךמסומ קדוב סיסבה תמר...

Documents