‫מרצים‪ :‬דני אלמוג‪ ,‬הדס חסידים‬

‫תשע"ח‬
‫באר שבע יום ‪10:00 – 13:00 3‬‬
‫‪17:00 - 14:00‬‬
‫אשדוד יום ג ‪11:00 – 14:00‬‬

‫שעות קבלה‪ :‬בתאום מראש‬

‫דואל‪hadasch@ac.sce.ac.il almog.dani@gmail.com :‬‬
‫‪1‬‬
 ‫מקורות‬ ‫שבוע נושא‬
‫רלוונטיים‬
‫‪1‬‬ ‫מבוא‪ ,‬מהי איכות תוכנה‪ ,‬איכות תוכנה במחזור חיי תוכנה‬ ‫‪1‬‬

‫‪1,2‬‬ ‫מדדי איכות של תוכנה‪ ,‬מה לומדים מהקוד‬ ‫‪2‬‬

‫‪7,9‬‬ ‫האורקל של הבדיקות‪ ,‬בדיקות בתהליך הקידוד (‪,)unit test‬פיתוח בדיקות )מסיפור משתמש למקרה הבדיקה)‬ ‫‪3‬‬

‫‪1,2,3‬‬ ‫סוגי בדיקות שונים‪ -‬פונקציונאליות‬ ‫‪4‬‬

‫‪4‬‬ ‫אזורי בדיקה טכניקות ומיפוי‪-‬שקילות‪ ,‬גבולות‬ ‫‪5‬‬
‫‪4‬‬ ‫המשך טכניקות בדיקה‪ -‬מונחה סיכונים ודרישות‬ ‫‪6‬‬
‫‪13‬‬ ‫שיטות לבחירת מקרי ותכולת הבדיקות‪Model Driven Testing ,‬‬ ‫‪7‬‬
‫עקיבות‪ ,‬דרגות הבדיקה‪ ,‬ניהול שגויים‬ ‫‪8‬‬
‫פיתוח וניהול תוכנית איכות ובדיקות‬ ‫‪9‬‬
‫סביבות בדיקה (בסיסי נתונים‪ ,‬מכונות וירטואליות‪ ,‬כלי בדיקה)‬ ‫‪10‬‬

‫‪11,12,14‬‬ ‫שיטות פיתוח ובדיקות בסביבות מתקדמות‪IoT ,Mobile DevOps -‬‬ ‫‪11‬‬

‫‪4‬‬ ‫הצד האנושי היבטים רכים –תפקידים‪ ,‬תקשורת‪ ,‬יכולות‬ ‫‪12‬‬

‫שעור חזרה והכנה לבחינה‬ ‫‪13 2‬‬
 ‫מה יהיה בשיעור זה‬
‫מה היה בשיעור‬
‫הקודם‬
‫‪ ‬חזרה‪ -‬אורקל‪ ,‬כיסוי בדיקות יחידה‬ ‫‪ ‬מהו האורקל של‬
‫הבדיקות‬
‫‪ ‬פיתוח מונע בדיקות ‪TDD‬‬ ‫‪ ‬מסיפורי משתמש למקרי‬
‫בדיקות‬
‫‪Mocks and Stubs ‬‬ ‫‪ ‬סוגי בדיקות‬
‫‪ ‬בדיקות יחידה‪ -‬מהי?‬
‫‪ ‬סוגי‪ -‬טכניקות בדיקה‬ ‫‪ ‬סביבת בדיקה ‪java‬‬
‫‪ ‬בדיקות פונקציונליות‬

‫‪3‬‬
Code coverage, using dedicated Model Driven Test Design Coverage
environment (MDTD)
 Statement – 100% coverage, every statement-line of Find values, automate, run, evaluate and
executable code report, considering test requirements (TR) and
 Branches- logical branches in the code (e.g., if, test criterion (TC)
while)  Graphs
 Path- testing all possible paths in the code  Logic expressions (based on e.g., state charts,
machine state charts)
Data coverage  Input domains
 Boundary condition
 Typical data values
 Pre and post conditions
 Illegal data
4
 A[] B[]
At least two out of the five statements, but
possibly more than two share equivalents of
the meaning: This class provides a
 Mark the only statements that share set of assertion
equivalent meaning
 Explain briefly the reason you have
methods, useful for
selected these items writing tests. Only
_________________________ failed assertions are
_________________________ recorded

C[] D[] E[ ]
@Test These annotations in JUnit provide the
Several tests need similar
@Before following information about test
objects created before
@After
methods −
they can run. Annotating
a public void method with @BeforeClass which methods are going to run before
and after test methods.
@Before causes that @AfterClass
method to be run before which methods run before and after all
@Ignore
the methods, and. which methods or
each Test method.
classes will be ignored during the 5
execution.
6
7
 If I touch it I brake it, so I will not…
And then the code become impossible to clean, risky, expensive…
8
 Performed Before implementation start

 Similarly to UT, is written to test the smallest unit of code

usually a function, method or class

 Code is written to Pass the code

 Iterative process

9
 Programmers dislike testing
 They will test reasonably thoroughly the first time
 The second time however, testing is usually less thorough
 The third time, well..

 Testing is considered a “boring” task

 Testing might be the job of another department / person
 TDD encourages programmers to maintain an exhaustive set of
repeatable tests
 Tests live alongside the Class/Code Under Test (CUT)
 With tool support, tests can be run selectively
 The tests can be run after every single change 10
 Even good design and “clean” code gets Rots over time

 Code degraded by time, became fragile, tangled, spaghetti

 Every fix should be in many places (unknown where)

 If you touch you brake the code

 Code ROTs --- > it is frightening to touch

11
What are the
symptoms?

12
Rigid

Fragile

Unpredictable

Inseparability (for modules)

Not reliable (hard to estimate changes)

13
 Stupid managers?

 Impatient customers ?

 Requirements changes?

 Stressed schedules?

 Go fast BUT go clean!

 Don’t blame-- > programmer writes the code

14
 Like making Sushi

 Elegant efficient-say a lot by only few words

 Efficient –runs quickly

 Can be read as a good prose

 Written by somebody who cares

 Each routine to read is like you expected

15
 Robert Stephenson Smyth Baden

 Always leave the campground cleaner than you

found it.

 If you find a mess on the ground, clean it up

regardless of who might have made the mess.

 Refer your code as a campground

16
 Clean code gives confident, not afraid to clean it
 “Before you write code, think about what it will do.
Write a test that will use the methods you haven’t even written yet.”
 A test is not something you “do”, it is something you “write” and run once,
twice, three times, etc.
 It is a piece of code
 Testing is therefore “automated”
 Repeatedly executed, even after small changes
 Maintain short list of defects
 TDD is a low level design
 TDD creates testable code
 TDD eliminated the fear, creates the courage to change
17
Three laws to keep code clean:
1. Write NO production code except to pass a failing test

2. Write only ENOUGH of a test to demonstrate a failure

3. Write only ENOUGH production code to pass the test

Test code test code test code……

18
1. Red – Write a little test that doesn’t work,
and perhaps doesn’t even compile at first.

2. Green – Make the test work quickly,

Refactor Red
committing whatever sins necessary in the
process.

3. Refactor – Eliminate all of the duplication

created in merely getting the test to
work. Green
19
 Write a test

Run test,
watch it pass
Compile

Refactor code Fix compile errors

Run test, Run test,

watch it pass watch it fail

Write code
20
21
 :‫ שאלה מספר‬1 [ ] 2[ ]
‫פיתוח מונחה בדיקות היא גישה נפוצה‬
__________________________ ‫לקידוד שדוגלת בפיתוח בצורה שונה‬
__________________________ ‫ במקום‬,2002 ‫שהתחיל להופיע משנת‬
__________________________ ‫לכתוב את הקוד ואז לבצע עליו‬
__________________________ ‫המתכנת כותב קודם‬TDD ‫ ב‬,‫בדיקות‬
__________________________ ‫ ולאחר מכן כותב‬, ‫את תסריטי הבדיקה‬
.‫קוד שיעבור בהכרח את הבדיקות‬
3 [] 4 [] 5 []
TDD is a technique whereby you Write a single test
Compile it. It should compile
write your test cases before you Run the test and see it passed
write any implementation code Implement just enough code to get the test to
Tests drive or dictate the code that pass
is developed Run the test and see it pass
Refactor for clarity and “once and only once”

22
1. Start small or not at all
select one small piece of functionality that you know is needed and you
understand.
2. Ask “what set of tests, when passed, will demonstrate the
presence of code we are confident fulfills this functionality
correctly?”
3. Make a to-do list, keep it next to the computer
1. Lists tests that need to be written
2. Reminds you of what needs to be done
3. Keeps you focused
4. When you finish an item, cross it off
5. When you think of another test to write, add it to the list 23
Which test should you pick from the list?
 Pick a test that will teach you something and that you are
confident you can implement.
 Each test should represent one step toward your overall
goal.
How should the running of tests affect one another?
 Not at all – isolated tests.

24
Where should you start building a system?
 With the stories you want to be able to tell about the finished
system.
Where should you start writing a bit of functionality?
 With the tests you want to pass on the finished code.
Where should you start writing a test?
 With the asserts that will pass when it is done.
25
11.2 Mocks and Stubs
27
 ‫‪ – Mocking ‬חיקוי‪.‬‬
‫‪ Mocking object ‬מממש את אותו ה‪ interface -‬של האובייקט אותו‬
‫הוא מדמה‪.‬‬
‫‪ ‬ניתן לדמות את התנהגות גמישה של האובייקט המדומה (זה לא ‪stub‬‬
‫"טיפש")‪:‬‬
‫‪ .1‬קביעת ערך החזרה‪.‬‬
‫‪ .2‬השמת ערכים לפרמטרים‪.‬‬
‫‪ .3‬זריקת ‪.exception‬‬

‫‪28‬‬
• Mocks and stubs are both dummy implementations of objects the

code under test interacts with.

• Stubs can be thought of as inputs

to the code under test.

• Mocks can be thought of as outputs from the code under test.

29
Class under communication
Stab
test
Class under communication
Mock
test

Test

Test

30
 Class under communication Mail service
ordering Stab
test (stub)

Test

a stub email server- always gives the

same answer
31
 Class under communication Email server
Ordering Mock
(mock)
test

Product ID Amount

Test

32
:Mock objects ‫ כלים אוטומטים ליצירת‬
Java ‫ מתאים ל‬Jmock 
easyMock 
C++ ‫ מתאים ל‬googleMock 

33
34
 ‫מאפיינים עיקריים של סוגי בדיקות‬
‫‪ ‬בדיקות פונקציונאליות ‪function al testing‬‬
‫‪ ‬בדיקות מונחות ספציפיקציות ‪Specification testing‬‬
‫‪ ‬בדיקת אזורי תפקוד ויחידות ‪Unit testing‬‬
‫‪ ‬בדיקות מונחות סיכון ‪Risk based testing‬‬
‫בדוק כל תפקוד ופונקציה לחוד‪.‬‬
‫‪ ‬בדיקות תסריטים‪scenarios testing‬‬
‫סרוק את המוצר‪ ,‬כיסוי כל תכונה‬ ‫‪ ‬בדיקות רגרסיה ‪Regression testing‬‬
‫או תפקוד במספר מספק של‬ ‫‪ ‬בדיקות לחץ ‪Stress‬‬
‫‪ ‬בדיקות משתמשים‪User testing‬‬
‫בדיקות על מנת לוודא שעובד כראוי‬
‫‪ ‬בדיקות מונחות מודל ומצבים‬
‫‪ ‬בדיקות ממוכנות בנפח גבוה ‪Load‬‬

‫‪35‬‬
 ‫מאפיינים עיקריים לסוגי הבדיקות‬
‫‪ ‬בדיקות פונקציונאליות ‪function al testing‬‬
‫‪ ‬בדיקות מונחות ספציפיקציות ‪Specification testing‬‬
‫‪ ‬בדיקת אזורי תפקוד ויחידות ‪Unit testing‬‬
‫בדוק כל אמירה המופיעה במסמכים‬
‫‪ ‬בדיקות מונחות סיכון ‪Risk based testing‬‬
‫המלווים את הפרויקט (כמו חוזים‬
‫‪ ‬בדיקות תסריטים‪scenarios testing‬‬
‫ומפרטים) בדוק עד לרמה שהוכחת‬ ‫‪ ‬בדיקות רגרסיה ‪Regression testing‬‬
‫שכל הנאמר מולא ועובד כמובטח‬ ‫‪ ‬בדיקות לחץ ‪Stress‬‬
‫‪ ‬בדיקות משתמשים‪User testing‬‬
‫‪ ‬בדיקות מונחות מודל ומצבים‬
‫‪ ‬בדיקות ממוכנות בנפח גבוה ‪Load‬‬
‫‪36‬‬
 ‫מאפיינים עיקריים לסוגי הבדיקות‬
‫‪ ‬בדיקות פונקציונאליות ‪function al testing‬‬
‫‪ ‬בדיקות מונחות ספציפיקציות ‪Specification testing‬‬
‫‪ ‬בדיקת אזורי תפקוד ויחידות ‪Unit testing‬‬
‫תתמקד במשתנים כמו ( ‪input, outputs,‬‬ ‫‪ ‬בדיקות מונחות סיכון ‪Risk based testing‬‬
‫‪ ) configuration or internal‬עבור כל‬ ‫‪ ‬בדיקות תסריטים‪scenarios testing‬‬
‫משתנה שכזה או קומבינציה בחן את מרחב‬ ‫‪ ‬בדיקות רגרסיה ‪Regression testing‬‬
‫‪ ‬בדיקות לחץ ‪Stress‬‬
‫האפשרויות של הערכים‪ .‬פשט את זה על‬
‫‪ ‬בדיקות משתמשים‪User testing‬‬
‫ידי חלוקה לתתי קבוצות‪ ,‬בחר מאפיינים‬
‫‪ ‬בדיקות מונחות מודל ומצבים‬
‫לכל אחת מהקבוצות ובדוק‪.‬‬ ‫‪ ‬בדיקות ממוכנות בנפח גבוה ‪Load‬‬
‫‪37‬‬
 ‫מאפיינים עיקריים לסוגי הבדיקות‬
‫‪ ‬בדיקות פונקציונאליות ‪function al testing‬‬
‫‪ ‬בדיקות מונחות ספציפיקציות ‪Specification testing‬‬
‫כל תוכנית היא אוסף ממוין של מקרים‬ ‫‪ ‬בדיקת אזורי תפקוד ויחידות ‪Unit testing‬‬
‫‪ ‬בדיקות מונחות סיכון ‪Risk based testing‬‬
‫שיכולים להתקלקל לפי הסיכוי והסיכון‬
‫‪ ‬בדיקות תסריטים‪scenarios testing‬‬
‫הכרוכים‪ .‬עבור כל הזדמנות שאתה‬
‫‪ ‬בדיקות רגרסיה ‪Regression testing‬‬
‫מסוגל לדמיין לנפילה עצב בדיקה‬
‫‪ ‬בדיקות לחץ ‪Stress‬‬
‫שבוחנת עד כמה באמת התוכנית עונה‬ ‫‪ ‬בדיקות משתמשים‪User testing‬‬
‫על הדרישות‪ -‬לפי סדר יורד של תוחלת‬ ‫‪ ‬בדיקות מונחות מודל ומצבים‬
‫הסיכון‪.‬‬ ‫‪ ‬בדיקות ממוכנות בנפח גבוה ‪Load‬‬
‫‪38‬‬
 ‫מאפיינים עיקריים לסוגי הבדיקות‬
‫‪ ‬בדיקות פונקציונאליות ‪function al testing‬‬
‫‪ ‬בדיקות מונחות ספציפיקציות ‪Specification testing‬‬
‫‪ ‬בדיקת אזורי תפקוד ויחידות ‪Unit testing‬‬
‫הבדיקות הינן סיפור מורכב‬
‫‪ ‬בדיקות מונחות סיכון ‪Risk based testing‬‬
‫שתופס כיצד התוכנית צריכה‬ ‫‪ ‬בדיקות תסריטים‪scenarios testing‬‬
‫להתנהג במצבי חיים אמיתיים‪.‬‬ ‫‪ ‬בדיקות רגרסיה ‪Regression testing‬‬
‫‪ ‬בדיקות לחץ ‪Stress‬‬
‫אלו הן קבוצות קומבינציה של‬
‫‪ ‬בדיקות משתמשים‪User testing‬‬
‫בדיקות המייצגות באופן מכובד‬ ‫‪ ‬בדיקות מונחות מודל ומצבים‬
‫את השימוש האמיתי‪.‬‬ ‫‪ ‬בדיקות ממוכנות בנפח גבוה‬
‫‪39‬‬
 ‫מאפיינים עיקריים לסוגי הבדיקות‬
‫‪ ‬בדיקות פונקציונאליות ‪function al testing‬‬
‫‪ ‬בדיקות מונחות ספציפיקציות ‪Specification testing‬‬
‫‪ ‬בדיקת אזורי תפקוד ויחידות ‪Unit testing‬‬
‫חזור על בדיקות מרכזיות לאחר כל‬
‫‪ ‬בדיקות מונחות סיכון ‪Risk based testing‬‬
‫שינוי בתוכנית‪ .‬כאשר נשתמש‬ ‫‪ ‬בדיקות תסריטים‪Scenarios testing‬‬
‫ברגרסיה באופן מסיבי עלינו ללמוד‬ ‫‪ ‬בדיקות רגרסיה ‪Regression testing‬‬
‫‪ ‬בדיקות לחץ ‪Stress‬‬
‫לתכנן בדיקות יעילות מאוד לצורך‬
‫‪ ‬בדיקות משתמשים‪User testing‬‬
‫החזרות הללו‪.‬‬ ‫‪ ‬בדיקות מונחות מודל ומצבים‬
‫‪ ‬בדיקות ממוכנות בנפח גבוה‬
‫‪40‬‬
 ‫מאפיינים עיקריים לסוגי הבדיקות‬
‫‪ ‬בדיקות פונקציונאליות ‪function al testing‬‬
‫‪ ‬בדיקות מונחות ספציפיקציות ‪Specification testing‬‬
‫‪ ‬בדיקת אזורי תפקוד ויחידות ‪Unit testing‬‬
‫יכולות להיות מספר הגדרות לבדיקות‬
‫‪ ‬בדיקות מונחות סיכון ‪Risk based testing‬‬
‫הלחץ‪ ,‬כאשר אנו אומרים לחץ משמעו‬ ‫‪ ‬בדיקות תסריטים‪Scenarios testing‬‬
‫להציף את התוכנה למשל בכמות וקצב‬ ‫‪ ‬בדיקות רגרסיה ‪Regression testing‬‬
‫מידע נכנס‪ ,‬קומבינציות כאלה שאנו‬ ‫‪ ‬בדיקות לחץ ‪Stress‬‬
‫מעריכים יפילו את התוכנית תוך כדי‬ ‫‪ ‬בדיקות משתמשים‪User testing‬‬
‫בחינה כיצד היא מנהגת בזמן ואחרי‬ ‫‪ ‬בדיקות מונחות מודל ומצבים‬
‫‪ ‬בדיקות ממוכנות בנפח גבוה‬
‫הנפילה‪.‬‬ ‫‪41‬‬
 ‫מאפיינים עיקריים לסוגי הבדיקות‬
‫‪ ‬בדיקות פונקציונאליות ‪function al testing‬‬
‫‪ ‬בדיקות מונחות ספציפיקציות ‪Specification testing‬‬
‫‪ ‬בדיקת אזורי תפקוד ויחידות ‪Unit testing‬‬
‫מסור את התוכנית ל"משתמש" וצפה‬ ‫‪ ‬בדיקות מונחות סיכון ‪Risk based testing‬‬
‫מה הוא עושה ומהן התגובות‬ ‫‪ ‬בדיקות תסריטים‪Scenarios testing‬‬
‫לפעולותיו‪ .‬בדיקות משתמש יכולות‬ ‫‪ ‬בדיקות רגרסיה ‪Regression testing‬‬
‫‪ ‬בדיקות לחץ ‪Stress‬‬
‫להיות מובנות ונוקשות או חופשיות‬
‫‪ ‬בדיקות משתמשים‪User testing‬‬
‫כאשר הדגש הוא הפעלת התוכנה‬
‫‪ ‬בדיקות מונחות מודל ומצבים‬
‫והתגובות כ "משתמש"‬ ‫‪ ‬בדיקות ממוכנות בנפח גבוה‬
‫‪42‬‬
 ‫מאפיינים עיקריים לסוגי הבדיקות‬
‫‪ ‬בדיקות פונקציונאליות ‪function al testing‬‬
‫על ידי מידול בתוכנית‬ ‫‪ ‬בדיקות מונחות ספציפיקציות ‪Specification testing‬‬
‫‪ ‬בדיקת אזורי תפקוד ויחידות ‪Unit testing‬‬
‫כמכונת מצבים שהרצתה‬
‫‪ ‬בדיקות מונחות סיכון ‪Risk based testing‬‬
‫מעבירה אותה ממצב למצב‬ ‫‪ ‬בדיקות תסריטים‪Scenarios testing‬‬
‫כתגובה לאירוע (למשל‬ ‫‪ ‬בדיקות רגרסיה ‪Regression testing‬‬
‫הזרמת מידע מסוים)‪ .‬נבחן‬ ‫‪ ‬בדיקות לחץ ‪Stress‬‬
‫‪ ‬בדיקות משתמשים‪User testing‬‬
‫בכל מצב האם התגובות הן‬
‫‪ ‬בדיקות מונחות מודל ומצבים‬
‫נכונות עבור כל אירוע‪.‬‬ ‫‪ ‬בדיקות ממוכנות בנפח גבוה ‪load‬‬
‫‪43‬‬
 ‫מאפיינים עיקריים לסוגי הבדיקות‬
‫‪ ‬בדיקות פונקציונאליות‬
‫‪ ‬בדיקות מונחות ספציפיקציות‬
‫תכנת והתקן את המחשב באופן‬
‫‪ ‬בדיקת אזורי תפקוד ויחידות‬
‫שיורצו מספר גדול ומסיבי של‬ ‫‪ ‬בדיקות מונחות סיכון‬
‫בדיקות‪ .‬תוך כדי אספקת‬ ‫‪ ‬בדיקות תסריטים‬

‫אורקל (ידע לוגי ה"מבין" את‬ ‫‪ ‬בדיקות רגרסיה‬

‫‪ ‬בדיקות לחץ‬
‫התוצאה)‪ .‬ובחן את תצורת‬
‫‪ ‬בדיקות משתמשים‬
‫תוצרי ההרצות‪.‬‬ ‫‪ ‬בדיקות מונחות מודל ומצבים‬
‫‪ ‬בדיקות ממוכנות בנפח גבוה ‪load‬‬
‫‪44‬‬
 ‫] [ ‪ 1‬שאלה מספר‪:‬‬ ‫][ ‪2‬‬
‫כל תוכנית היא אוסף ההזדמנויות של‬ ‫בדיקות מונחות ספציפיקציות‬
‫__________________________‬ ‫דברים שיכולים להתקלקל‪ .‬עבור כל‬
‫הזדמנות שאתה מסוגל לדמיין לנפילה __________________________‬
‫__________________________‬ ‫שכזאת עצב בדיקה שבוחנת עד כמה‬
‫__________________________‬ ‫באמת התוכנית מפשלת בנקודה זאת‬
‫__________________________‬

‫][ ‪3‬‬ ‫][‪4‬‬ ‫][ ‪5‬‬

‫תכנת והתקן את המחשב באופן‬
‫שהמעבד יגיע ל ‪ .90%‬תוך כדי‬
‫אספקת אורקל (ידע לוגי ה"מבין"‬
‫את התוצאה)‪ .‬ובחן את תצורת‬
‫תוצרי ההרצות‬
‫בדיקות מונחות סיכון‬ ‫תכנת והתקן את המחשב באופן שיורצו‬
‫מספר גדול ומסיבי של בדיקות‪ .‬תוך כדי‬
‫אספקת אורקל (ידע לוגי ה"מבין" את‬
‫התוצאה)‪ .‬ובחן את תצורת תוצרי‬
‫ההרצות‬

‫‪45‬‬
46
 ‫בדיקות פונקציונאליות‬
‫‪ ‬פונקציה היא יכולת של המוצר‬
‫‪ ‬לפעמים נקרא לפונקציה גם תכונה או פקודה ‪ /‬להזדהות רק במה שהיא עושה (בדרך כלל‪ ,‬או חלק‬
‫מכל דבר)‬
‫‪ ‬זיהוי כל פונקציה או תת פונקציה‬
‫‪ ‬מדרישות או במדריך למשתמש (אפילו חלקי)‬
‫‪ ‬ממעבר לאורך כל ממשקי המשתמש‬
‫‪ ‬מניסוי פקודות בכל שורות הפקודה‬
‫‪ ‬חיפוש בתוך התוכנית‪ ,‬הקוד או קבצי המקור של פקודות או שמות של פקודות‬
‫פונקציות‪:‬‬ ‫‪ ‬פעילויות מפתח כאשר בונים או משתמשים ברשימת‬
‫‪ ‬קבע באיזה אופן תדע שהפונקציה פועלת (שאלת האורקל)‬
‫‪ ‬זהה משתנים המשמשים את הפונקציה ובדוק את קצותיהם‬
‫‪ ‬זהה משתני סביבה שעשויים להגביל את הפונקציה בתוך הבדיקה‬
‫‪  47‬בדוק שכל פונקציה מבצעת את מה שהיא אמורה לבצע ואינה עושה את מה שאינה אמורה לעשות‬
 ‫הגדרת קטגוריות לפונקציה‬
. (Cut, Paste, Delete :‫ פונקציה מסוימת (כגון‬:‫הדגמה‬
‫ מידע נכנס‬
‫ משתנים‬
‫ ערך מקסימאלי‬
‫ ערך מינמאלי‬
‫ ערכים מיוחדים נוספים‬
‫ מידע יוצא‬
(e.g. Delete word, Delete paragraph) ‫ מרחב תפקוד אפשרי כמו‬
(e.g. configure the program to Delete the contents of a row ‫ אופציות של הפונקציה כמו‬
of a table, leaving a blank row versus Delete the row along with its contents)
(e.g. deleting from a word processor ‫ הנסיבות בהם הפונקציה מתנהגת באופן שונה‬
configured to track and display changes or not to track changes) 48
 ‫שימושים עיקריים בבדיקה פונקציונאליות‬
‫‪ ‬מוכוון להבטיח כסוי כל התפקודים‬
‫‪ ‬ביכולתך להשוות את רשימת הפונקציות לרשימות בתוכנית‬
‫הבדיקה כולל רשימת התסריטים ומקרי הבדיקה על מנת לכסות כל‬
‫רכיב‪,‬תפקוד‪,‬תת רכיב של כל תכונה‬
‫‪ ‬שימושי עבור הבדיקות הראשונות של המוצר‬
‫‪ ‬הכרות סימפטית עם היכולות של המוצר‬
‫‪ ‬סריקה מהירה לזיהוי בעיות רציניות שצריך לטפל בהם בהתחלה‬

‫‪49‬‬
 ‫‪ ‬נניח שנבנה מערכת לרכישת מנוי לחדר כושר‪ ,‬כך שהמתאמנים יכולים להגדיר את העלויות לפי‬
‫סוג המנוי לפי הדרישות הבאות‪:‬‬

‫‪.1‬מתאמן יוכל להתאמן באימוני ‪ TRX‬או אימוני ‪ Yogi‬אם מחזיק‬

‫במנוי ‪ basic‬או מנוי ‪Shanti‬‬
‫‪.2‬עלות מנוי ‪ $100 Basic‬לחודש‪ ,‬מנוי ‪ $150 Shanti‬לחודש‬
‫‪.3‬עלות אימוני ‪ $25 TRX‬לחודש‬
‫‪.4‬עלות אימוני ‪ $20 Yogi‬לחודש‬
‫ממשק משתמש יתמוך ברכישת האימונים ‪ TRX/Yogi‬כתלות במנוי‬
‫‪ basic‬או ‪)black box( Shanti‬‬
‫‪50‬‬
 Lets start with black box testing
For simplicity the focus is on the interface

Flow of execution
Execution steps --- > expected results

Basic, check TRX, click Calculate

Total cost is $125

Write 3 requirements and the corresponding TCs

51
 ‫הסיכונים של בדיקות פונקציונאליות‬
‫‪ ‬יופי של דרך להתחיל איתה‪ ,‬אבל מספר אנשים עשויים להסתמך על כך‬
‫כמהלך בדיקות מרכזי‬
‫‪ ‬כשיטה עיקרית לבדיקה הבעיה היא בהדגשת בדיקות יחידה תוך בידוד‬
‫יחידות מסוימות‪:‬‬
‫‪ ‬חסרה האינטראקציה בין הרכיבים‬
‫‪ ‬חסרים היבטים העוסקים בעומס‪ ,‬אינטראקציה עם מה שקורה ברקע ולא נבחן נושא‬
‫הפסקות ועצירות (מתוכננות ולא)‬
‫‪ ‬לעיתים קרובות מתמקד בתפקודים ללא התחשבות בגבולות או פרטי מידע‬
‫אחרים‬
‫‪ ‬אינו משיב על מטלות המשתמשים – כאשר הלקוח יכול להשיג את היתרון‬
‫המובטח על ידי התוכנה‬
‫‪52‬‬
 ‫דוגמא לבדיקות פונקציונאליות אתר "מאגר הטפסים"‬
‫‪http://www.gov.il/FirstGov/Forms/FormsSearchResults‬‬
‫‪‬שאלות ראשוניות ‪:‬‬
‫‪ ‬התמצאות באתר – איפה מונח כל דבר‬
‫‪ ‬איזה חלק הוא מידע ואיזה חלק שימוש‬
‫‪ ‬הרשאות – מי צריך מה (בכלל מאיפה נכנסים)‬
‫‪‬יותר לעומק‬
‫‪ ‬איזה שירותים למי‬
‫‪ ‬לאן כל לינק מגיע‬
‫‪ ‬מעבר שיטתי על כל הלינקים והפניות‬
‫‪ ‬האם יש שירותים שאינם מוכנים‬
‫‪53‬‬
‫הרחבה – הכן תוכנית לבדיקות פונקציונאליות לאתר‬
 ‫‪ .1‬שאלה מספר‪:‬‬
‫__________________________‬
‫__________________________‬
‫__________________________‬
‫__________________________‬
‫__________________________‬
‫‪.3‬‬
‫‪Can be defined as the type of‬‬
‫‪black box testing that is performed‬‬
‫‪to confirm that the functionality of‬‬
‫‪an application or system is‬‬
‫‪behaving as expected‬‬
‫‪.2‬‬
‫קבע באיזה אופן תדע שהפונקציה פועלת‪.‬‬ ‫לא קיים מצב שאין תקלות‪.‬‬
‫זהה משתנים המשמשים את הפונקציה‬ ‫נקודת המוצא היא כי אין מערכת‬
‫ובדוק את קצותיהם‬ ‫מושלמת שאין בה תקלות‪ .‬כמובן‬
‫זהה משתני סביבה שעשויים להגביל את‬
‫שיכולים להיות מצבים בהם לא מוצאים‬
‫הפונקציה בתוך הבדיקה‬
‫בדוק שכל פונקציה מבצעת את מה שהיא‬ ‫תקלות אך הסיכוי שבאמת אין תקלות‬
‫אמורה לבצע ואינה עושה את מה שאינה‬ ‫בכלל הוא אפסי‪.‬‬
‫אמורה לעשות‬
‫‪.4‬‬ ‫‪.5‬‬
‫הבעיה היא בהדגשת בדיקות יחידה תוך‬
‫בידוד יחידות מסוימות בגישת קופסה‬
‫שחורה‪:‬‬
‫חסרה האינטראקציה בין הרכיבים‬
‫חסר כל הנושאים שעוסקים בעומס‪,‬‬
‫אינטראקציה עם מה שקורה ברקע ולא‬
‫נבחן נושא הפסקות ועצירות (מתוכננות‬
‫ולא)‬ ‫‪54‬‬
 ‫מה היה בשיעור זה‬ ‫מה להתכונן לשיעור‬
‫הבא‬
From user story to test
‫ כיסוי בדיקות יחידה‬,‫ אורקל‬-‫ חזרה‬ requirements
Development of tests
TDD ‫ פיתוח מונע בדיקות‬ Testing techniques- cont’.
Specification based
Mocks and Stubs  testing
Cognitive aspects in
‫ טכניקות בדיקה‬-‫ סוגי‬ testing
‫ בדיקות פונקציונליות‬ Domain testing
techniques

55
‫להתראות בשבוע הבא‬

‫‪56‬‬