Decision table testing – Functional testing

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

לדוגמה:

בדוגמה הזו אנחנו בונים מקרי הבדיקה (test cases) ובכך בודקים לפי תוצאה הצפויה (אם הכל מתקיים).

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

2^n where n is inputs (New Customer, VISA CARD, Coupon => 3 inputs)
In our example: 2^3=8 rules

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

בדיקות ערכי גבול וקבוצות שקילות

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

BVA – Boundary value analysis – בדיקות ערכי גבול

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

Just below the minimum
Minimum
Just above the minimum


A nominal value


Just below the maximum
Maximum
Just above the maximum

לדוגמה יש STRING שיכול להכיל מ-1 עד 30 סימנים. אז יש לבדוק במקרים הבאים:

ערכים לא תקינים: 0, 31
ערכים תקינים: 1,2,15,29,30

Equivalence partitioning – EP – קבוצות שקילות

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

לדוגמה:

הלקוח מקבל 3% הנחה כאשר הוא קונה בין 0 ל-100 דולר.
הלקוח מקבל 5% הנחה כאשר הוא קונה בין 100 ל-1000 דולר.
הלקוח מקבל 7% הנחה כאשר הוא קונה מעל 1000 דולר.

בדוגמה הזאת יש לחלק ל-4 תחומים, כאשר יש לקחת מכל תחום מדגם ולבדוק כגון:

מינוס 10 דולר חייב לתת INVALID
50$ אמור לתת 3% הנחה
260$ אמור לתת 5% הנחה
1400$ אמור לתת 7% הנחה

לסיכום: טוב להשתמש בטכניקות של BVA & EP כאשר יש לבחור מתוך טווח גדול של ערכים שיהיו כנתוני כניסה עבור מקרי בדיקה.

ב-AGILE יש מספר גישות, נתרכז בגישה שנקראת SCRUM. ב-SCRUM יש הרצה של ספרינט אחרי ספרינט עד שמשלימים את הפיתוח של המוצר. בדרך כלל ספרינט אחת נמשך 1-4 שבועות, כאשר בתחילת כל ספרינט יש פגישה של – SPRINT PLANNING.

הסבר שלב אחרי שלב:

שלב א) מנהל המוצר – PRODUCT MANAGER מציג את המשימות שזה למעשה דרישות הלקוח (User Stories) שיש לממש לצוות הפיתוח ובודקי תוכנה ומעביר אותם ל-PRODUCT BACKLOG.

שלב ב) במהלך SPRINT PLANING (בהתחלה של הספרינט) SCRUM MASTER בוחר מספר משימות מ- PRODUCT BACKLOG ומעביר אותם ל-SPRINT. כאשר- SCRUM MASTER מקשר את PRODUCT MANAGER ל- DEV TEAM.

כאשר החלטה איזו משימות (User stories) להעביר מ- PRODUCT BACKLOG ל-SPRINT במהלך SPRINT PLANNING, נובעת מפגישה של מנתח עסקי, מפתחים, מנהל המוצר ובודקי תוכנה ורמת הקושי של ה-user story.
* בדרך כלל SCRUM MASTER הוא גם Team Lead.

במהלך SPRINT PLANNING (תכנון SPRINT) קובעים כמה משימות להעביר מ-Backlog על סמך נקודות משקל.
לכל משימה יש נקודות משקל( user story points) ועל סמך נקודות משקל האלו, ניתן להעריך בערך רמת הקושי של משימה עבור-SPRINT.

לאחר מכן בזמן של SPRINT כל צוות נפגש לצורך –
DAILY STANDUP / DAILY SCRUM MEETING ששם כל אחד מהצוות אומר מה הוא עשה ומה הבעיות שיש, DAILY STANDUP נמשך כ-15 דקות – בדרך כלל כל יום בשעות הבוקר, לפני תחילת עבודה או לאחר יום עבודה.

כאשר לפי Burn down chart – גרף שריפת נקודות (לכל משימה- User Story ב-PRODUCT BACKLOG יש נקודות Story Points ) אפשר לראות את הקצב התקדמות של פיתוח המוצר/תוכנה.

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

* בודקי תוכנה משתלבים לא רק בסוף של SPRINT כאשר בודקים SPRINT DEMO אלא הם עושים בדיקות סטטיות של דוקומנטציה וכתיבת מקרי בדיקה, checklists במהלך כל SPRINT עבור הרצת בדיקות ל-SPRINT DEMO

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

דוגמה ל-Agile Scrum

שלב א)

מנהל המוצר – PRODUCT MANAGER מציג את המשימות (User Stories) שיש לממש לצוות הפיתוח ו-Test Team ומעביר אותם ל-PRODUCT BACKLOG.

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

במהלך SPRINT PLANNING (בהתחלת של הספרינט) SCRUM MASTER בוחר מספר משימות מ- PRODUCT BACKLOG ומעביר אותם ל-"Sprint 2".

כאשר אדום מסמל BUG
כאשר ירוק מסמל USER STORY

כאשר לכל USER STORY יש POINTS

בואו נתרכז Active Sprint

עכשיו בואו נצפה ב-Burn down chart גרף – שריפת נקודות

בואו נתבונן איך נראה USER STORY ב-Jira

מתי עדיף להשתמש ב-AGILE SCRUM?

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

1 – ASP.NET

ברוכים הבאים לעולם של DOTnet בנושא: ASP.NET בעמוד הזה יש צילומי מסך עם הסברים שלי בסרטון וידאו לכל צילום וצילום.

להלן סרטון וידאו עם הסבר לכל צילומי מסך שיש בעמוד הזה:

Let's create Web project – Web

Let's create Master Page

Let's add menu to MasterPage

Let's create sitemap for menu

Let's add sitemap as data source for menu

================

Let's change bit DropDownList

================

Let's set as default BLACK

Let's add C# code – basic class

Let's call in constructor "PreInit"

Let's check cookies if there saved previous selected theme

Now let's get name of theme from PAGE & if we have name of theme in cookies so let's get name of theme from cookies.

============================

For memory – Page defined in Web.Config as Black

=====================

If no saved name of theme in Cookies so we get name of theme from Page.Theme. Than we check if DropDownList contains BGColor

Print BGcolor

Now let's create test ASPX page

Java examples

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

אז ברוכים הבאים ל-Java בעמוד הזה יש צילומי מסך עם הסברים שלי בסרטון וידאו לכל צילום וצילום.

להלן סרטון וידאו עם הסבר לכל צילומי מסך שיש בעמוד הזה:

if(n%2==0){
        System.out.println("even number");
    }else{
        System.out.println("odd number");
    }
}

public static void Switch(int n) {
    switch (n) {
        case 10:
            System.out.println("10");
            break;
        case 20:
            System.out.println("20");
            break;
        case 30:
            System.out.println("30");
            break;
        default:
            System.out.println("Other");
    }
}

public static void ForFun(int n, int arr[]){
    for(int i:arr){
        System.out.println(i);
    }

    for(int i=1;i<=n;i++){
        System.out.println(i);
    }

}

public static void WhileFun(int n){
    while(n<=10){
        System.out.println(n);
        n++;
    }

    do{
        System.out.println(n);
        n++;
    }while(n<=10);
}



//Anonymous object
class Factorial {
    void factorial(int n) {
        int factorial = 1;
        for (int i = 1; i <= n; i++) {
            factorial = factorial * i;
        }
        System.out.println("factorial is " + factorial);
    }
}



class StaticClass {
    static int n = 0;

    public StaticClass() {
        n++;
        System.out.println(n);
    }
}

 



class ThisClass2{
    ThisClass1 obj;
    ThisClass2(ThisClass1 obj){
        this.obj=obj;
    }
    void fun(){
        System.out.println(obj.n);//10
    }
}


class ThisClass1{

    int n=10;

    ThisClass1(){
        ThisClass2 obj2=new ThisClass2(this);
        obj2.fun();
    }

    public static void main(String args[]){
        ThisClass1 obj1=new ThisClass1();
    }
}

class Animal{
    void fun(){System.out.println("Animal eats");}
}

class Dog extends Animal{
    void fun(){System.out.println("Dog eats");}
}

class Cat extends Dog{
    }


class Inheritance{
    public static void main(String args[]){
        Dog obj1=new Dog();
        obj1.fun();//Dog eats
        Cat obj2=new Cat();
        obj2.fun();//Dog eats
        Animal obj3= new Cat();
        obj3.fun();//Dog eats
    }
}

interface Test2{}

class A implements Test2{
    public void a(){System.out.println("A");}
}
class B implements Test2{
    public void b(){System.out.println("B");}
}

class Test3{
    void fun(Test2 x){//Test2 x=new B();
        if(x instanceof A){//False
            A a=(A)x;
            a.a();
        }
        if(x instanceof B){//true
            B b=(B)x;//B b=new B();
            b.b();//B
        }

    }
}

class Test4{
    public static void main(String args[]){
        Test2 a=new B();
        Test3 b=new Test3();
        b.fun(a);
    }
}

Interface

Implements

Get Object by Function

Get Object_array by Function

For, Array, Object, If

This Object

Genereics

<String>

Strings.getLength, Strings.get

Static, <GENERIC_TYPE>

CustomArrayList, Add to Array with T element

Get (T) data[index], Exception

Clear

Collections, Exception, FileInputStream, Get File

length, Array-Bit, Read file and put it on Data

Byte to String

ArrayList, Split, Array [], Straings

Add, ArrayList, Split, For

HashMap, TreeMap

For, String, Array, Map, If, Put, Get

Map: key,value

Get, KeySet

Dir.list, File, Dir, String, FileInputStream, FileNotFoundException, IOException

Read byte by Byte files, Array, Input.Read_File

Add to file – no remove previous content

Output.write, String, File

Exception, ExampleException, My Exception

מודל V

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

Requirements <-> Acceptance test

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

Specification <-> System Testing

בשלב של Specification צוות הפיתוח עושה טרנספורמציה של דרישות שיש במסמך BRS למסמך SRS
צוות QA כותב מקרי בדיקה עבור בדיקות מערכת (System Testing) לפי מסמך SRS.

Design <-> Integration testing

בשלב אפיון (Design) צוות הפיתוח עושה טרנספורמציה של דרישות אשר מתארות במסמך SRS למסמך SDD כאשר יש:
– Architecture Design: תכנון על-ידי מפתחים high-level design, איך מודולים במערכת יעבדו אחד עם השני.
– Module Design: תכנון על-ידי מפתחים low-level design, איך מודול בעצמו יעבוד כלומר מה מאפיינים שלו.
בודקי תוכנה כותבים מקרי בדיקות עבור בדיקות אינטגרציה (Integration Testing) לפי מסמך SRS ו-SDD.

High Level Design – HLD: תיאור מודולים שונים במערכת ויחסם אחת כלפי השני.

Low Level Design – LLD: תיאור מפורט של כל מודול/קומפוננט.

Code <-> Unit testing

מתכנתים מפתחים את המוצר/תוכנה(Coding) וגם עושים בדיקות קופסה לבנה ( debugging, code coverage.. ) עבור היחידה שמתפתחת (Unit testing), תוך שימוש בטכניקות של קופסה לבנה.

לסיכום מודל V זה:

Verification Testing

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

Validation testing

בדיקה שכל דרישות מתקיימות לשם שימוש.

למעשה מודל V:

הצד השמאלי של מודל V זה תהליך הפיתוח של המערכת
– SDLC – Software Development Life Cycle
הצד הימני של מודל V זה תהליך של בדיקות
– STLC – Software Test Life Cycle

Validation take place after Verification phase

VALIDATION TESTING מבצעים בזמן : integration testing, system testing, load testing, compatibility testing, stress testing, functional testing.

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

מתי משתמשים במודל V ?

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

מודל V מחליף מודל ישן Waterfall Model.

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

בדיקות אינטגרציה

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

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

:Big Bang Approach

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

:Incremental Approach

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

משתמשים במקום מודלים חסרים ב-STUBS ובמקום בקרה משתמשים ב-DRIVER.

פיתוח בסבבים

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

Spiral Model – פיתוח בסבבים

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

למעשה זה פיתוח מחזורי מצטבר עם אותו תהליך :

[ הגדרת חלק מהדרישות – בדיקת סיכונים – עיצוב ומימוש + בדיקות – בדיקות קבלה וחזרה לדרישות ] ⇐ תחזוקה.

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

הערה: כאשר מוסיפים עוד ועוד דרישות יש לבדוק אם לא נגרמו פגמים למערכת (בדיקות רגרסיה – Regression testing ).

:Planning Phase

הבנה ותרגום דרישות של הלקוח למסמך דרישות עסקיות BRS.

:Risk analysis phase

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

:Developed phase

בונים מסמך SRS על סמך מסמך BRS ועל סמך SRS את המסמך SDD ו-STD.
מממשים את הדרישות אשר במסמך SDD ועושים בדיקות לפי מסמך STD (מריצים מקרי בדיקה ומדווחים על הבאגים ..).

:Evaluation phase

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

יתרונות פיתוח בסבבים:

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

מתי משתמשים ב-Spiral Model ?

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

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

מודל מפל המים

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

דרישות – אפיון – עיצוב – מימוש – בדיקות– תחזוקה

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

מודל ישן ולכן אני לא ממליץ להשתמש ב-Waterfall כי זה לא חסכוני גם כלכלית וגם מבחינת הזמן.

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

מחזור פיתוח תוכנה – תחזוקה

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

SDLC:

Requirements & Analysis (SRS doc.) => Design (SDD doc.)=> Code (unit test)=> Test (Fixing bugs, Reporting bugs by QA team)=> Deployment & Maintenance

STLC:

Requirements & Analysis(STP doc.) => Design (STD doc.) => Test (Fixing bugs, Reporting bugs by QA team) => Deployment & Maintenance

Deployment – פריסת המערכת

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

Maintenance – תחזוקה

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