Materi TIS10

download Materi TIS10

of 53

Transcript of Materi TIS10

  • 7/29/2019 Materi TIS10

    1/53

    Testing dan

    Implementasi Sistem

    Siti Muharramah

  • 7/29/2019 Materi TIS10

    2/53

    Objektivitas

    Pemahaman mengenai use case

  • 7/29/2019 Materi TIS10

    3/53

    3

    Importance of Testing inSDLC & Various Kinds of

    Testing

  • 7/29/2019 Materi TIS10

    4/53

    4

    Software Development LifecycleAll software development can be characterized as a problem solving loop in which

    four distinct stages are encounter: -

    Status quo: represents the current state of affairs;

    Problem definition: identifies the specific problem to be solved

    Technical development: solves the problem through the application of some

    technology.

    Solution integration: delivers the results (e.g., documents, programs, data, new

    business function, new product) to those who requested the solution in the first

    Place.

  • 7/29/2019 Materi TIS10

    5/53

    5

    Waterfall Model

    Analysis Design Code Test

    System/informationengineering

  • 7/29/2019 Materi TIS10

    6/53

    6

    The Prototyping ModelListen tocustomer Build/revise mock-up

    Customertest-drivesmock-up

  • 7/29/2019 Materi TIS10

    7/53

    7

    The RAD ModelBusinessmodeling

    Datamodeling

    Processmodelin

    g

    Application modeling

    Testand

    turnover

    Businessmodeling

    Datamodeling

    Processmodeling

    Applicationmodeling

    Test andturnover

    Businessmodeling

    Datamodeling

    Processmodelin

    g

    Application modeling

    Testand

    turnover

    Team #1

    Team #2

    Team #3

  • 7/29/2019 Materi TIS10

    8/53

    8

    Boehms Spiral Model

  • 7/29/2019 Materi TIS10

    9/53

    9

    V- Model

    SRS

    Unit test

    Testedmodules

    Integration Test

    Integratedsoftware

    System

    Integration Test

    Testedsoftware

    System Test,

    AcceptanceTest

    Requirements

    Specification

    System Design

    Detailed

    Design

    Coding

    SystemDesign

    SRS

    Moduledesigns

    Code

    UserManual

  • 7/29/2019 Materi TIS10

    10/53

    10

    Importance of Software testing in SDLC Its helps to verify that all the software requirements are implemented

    correctly or not.

    Identifying defects and ensuring they are addressed before software

    deployment. Because if any defect will found after deployment and force

    to fixed it, than the correction cost will much higher than the cost of it

    fixed it at earlier stage of development.

    Effective testing is demonstrates that software-testing function appear to

    be working according to specification, that behavioral and performance

    requirement appear to have been met.

    Whenever any system is developed in different components, its helps to

    verify the proper integration/interaction of each component to rest of the

    system.

    Data collection as testing is conducted provide a good indication of

    software reliability and some indication of software quality as a whole.

  • 7/29/2019 Materi TIS10

    11/53

    11

    Different Types of Testing Dynamic v/s static testing.

    Development v/s independent testing.

    Black v/s white box testing.

    Behavioral v/s structural testing.

    Automated v/s manual testing.

    Sanity, acceptance and smoke testing .

    Regression testing.

    Exploratory and monkey testing.

    Debugging v/s be bugging.

  • 7/29/2019 Materi TIS10

    12/53

    12

    Dynamic v/s staticStatic Testing: This testing refers to testing something thats not

    running-Examining and reviewing it.

    Dynamic Testing: This you would normally think of as testing-

    running and using the software.

  • 7/29/2019 Materi TIS10

    13/53

    13

    Development v/s independent testingDevelopment testing denotes the aspects of test design and implementation

    most appropriate for the team of developers to undertake. This is in contrastto Independent Testing. In most cases, test execution initially occurs with

    the developer testing group who designed and implemented the test, but it is

    a good practice for the developers to create their tests in such a way so as to

    make them available to independent testing groups for execution.

    Independent testing denotes the test design and implementation most

    appropriately performed by someone who is independent from the team of

    developers. You can consider this distinction a superset, which includes

    Independent Verification & Validation. In most cases, test execution initially

    occurs with the independent testing group that designed and implemented

    the test, but the independent testers should create their tests to make them

    available to the developer testing groups for execution

  • 7/29/2019 Materi TIS10

    14/53

    14

    Black v/s white box testingThe purpose of a black-box test is to verify the unit's specified function and

    observable behavior without knowledge ofhow the unit implements the

    function and behavior. Black-box tests focus and rely upon the unit's input

    and output.

    A white-box test approach should be taken to verify a unit's internal

    structure. Theoretically, you should test every possible path through the

    code, but that is possible only in very simple units. At the very least you

    should exercise every decision-to-decision path (DD-path) at least once

    because you are then executing all statements at least once. A decision is

    typically an if-statement, and a DD-path is a path between two decisions.

  • 7/29/2019 Materi TIS10

    15/53

    15

    Behavioral v/s structural testing

    Behavioral Testing:This is another name commonly given to Black Box

    Testing as you are testing the behavior of the software when its used

    without knowing the internal logics how they are implemented.

    Structural Testing:This is another name commonly used for white Box

    testing in which you can see and use the underlying structure of the code to

    design and run your tests.

  • 7/29/2019 Materi TIS10

    16/53

    16

    Automated v/s manualAutomated Testing: Software testing assisted with software tools that

    require no operator input, analysis, or evaluation.

    Manual Testing: That part of software testing that requires human input,

    analysis, or evaluation.

  • 7/29/2019 Materi TIS10

    17/53

    17

    Sanity, Acceptance and Smoke testingSanity Testing: Sanity testing is a cursory testing; it is performed whenever a

    cursory testing is sufficient to prove the application is functioning accordingto specifications. It normally includes a set of core tests of basic GUI

    functionality to demonstrate connectivity to the database, application

    servers, printers, etc.

    Acceptance testing: Acceptance testing is the final test action before deploying

    the software. The goal of acceptance testing is to verify that the software is

    ready and can be used by your end users to perform those functions and

    tasks for which the software was built.

    Smoke Testing: Smoke testing is non-exhaustive software testing, ascertaining

    that the most crucial functions of a program work, but not bothering with

    finer details.

  • 7/29/2019 Materi TIS10

    18/53

    18

    Regression testingThe selective retesting of a software system that has been modified to

    ensure that any bugs have been fixed and that no other previously

    working functions have failed as a result of the modifications and that

    newly added features have not created problems with previous versions

    of the software.

    Regression testing is initiated after a programmer has attempted to fix a

    recognized problem or has added source code to a program that may

    have inadvertently introduced errors. It is a quality control measure to

    ensure that the newly modified code still complies with its specified

    requirements and that unmodified code has not been affected by the

    maintenance activity.

  • 7/29/2019 Materi TIS10

    19/53

    19

    Exploratory and monkey testingExploratory testing involves simultaneously learning,

    planning, running tests, and reporting /troubleshooting results.

    Monkey testing- This is another name for "Ad HocTesting"; it comes from the joke that if you put 100monkeys in a room with 100 typewriters, randomlypunching keys, sooner or later they will type out a

    Shakespearean sonnet. So every time one of your adhoc testers finds a new bug, you can toss him abanana. The use of monkey testing is to simulate howyour customers will use your software in real time.

  • 7/29/2019 Materi TIS10

    20/53

    20

    Debugging v/s bebuggingDebugging: The process of finding and removing the causes of

    failures in software. The role is performed by a programmer.

    Bebugging:The process of intentionally adding known faults to those

    already in a computer program for the purpose of monitoring the

    rate of detection and removal, and estimating the number of faults

    remaining in the program

  • 7/29/2019 Materi TIS10

    21/53

    21

    Black Box & White BoxTesting Techniques

  • 7/29/2019 Materi TIS10

    22/53

    22

    Black-Box TestingProgram viewed as a Black-box, which accepts some inputsand produces some outputs

    Test cases are derived solely from the specifications,

    without knowledge of the internal structure of theprogram.

  • 7/29/2019 Materi TIS10

    23/53

    23

    Functional Test-Case Design Techniques

    Equivalence class partitioning

    Boundary value analysis

    Cause-effect graphing

    Error guessing

  • 7/29/2019 Materi TIS10

    24/53

    24

    Equivalence Class PartitioningPartition the program input domain into equivalence classes(classes of data which according to the specifications aretreated identically by the program)

    The basis of this technique is that test of a representativevalue of each class is equivalent to a test of any other valueof the same class.

    Identify valid as well as invalid equivalence classes

    For each equivalence class, generate a test case to exercisean input representative of that class

  • 7/29/2019 Materi TIS10

    25/53

    25

    ExampleExample: input condition 0

  • 7/29/2019 Materi TIS10

    26/53

    26

    Guidelines for Identifying Equivalence ClassesInput Condition Valid Eq Classes Invalid Eq Classes

    range of values one valid two inavlid

    (eg. 1 - 200) (value within range) (one outside eachend of range)

    number N valid one valid two invalid

    values (none, more than N)

    Set of input values one valid eq class one

    each handled for each value (eg. any value not

    differently by the in valid input set )

    program (eg. A, B, C)

  • 7/29/2019 Materi TIS10

    27/53

    27

    Guidelines for Identifying Equivalence ClassesInput Condition Valid Eq Classes Invalid Eq Classes

    must be condition one one

    (e.g. Id name must begin (e.g.. it is a letter) (e.g.. it is not a letter)with a letter )

    If you know that elements in an equivalence class are not handledidentically by the program, split the equivalence class into smallerequivalence classes.

  • 7/29/2019 Materi TIS10

    28/53

    28

    Identifying Test Cases for Equivalence ClassesAssign a unique number to each equivalence class

    Until all valid equivalence classes have been covered bytest cases, write a new test case covering as many of theuncovered valid equivalence classes as possible.

    Each invalid equivalence class cover by a separate testcase.

  • 7/29/2019 Materi TIS10

    29/53

    29

    Boundary Value AnalysisDesign test cases that exercise values that lie at the

    boundaries of an equivalence class and for situations justbeyond the ends.

    Example: input condition 0

  • 7/29/2019 Materi TIS10

    30/53

    30

    Cause Effect GraphingA technique that aids in selecting test cases for combinationsof input conditions in a systematic way.

  • 7/29/2019 Materi TIS10

    31/53

    31

    Cause Effect Graphing Technique1. Identify the causes (input conditions) and effects (output

    conditions) of the program under test.

    2. For each effect, identify the causes that can produce thateffect. Draw a Cause-Effect Graph.

    3. Generate a test case for each combination of input conditionsthat make some effect to be true.

  • 7/29/2019 Materi TIS10

    32/53

    32

    ExampleConsider a program with the following:

    Input conditions Output conditions

    c1: command is credit e1: print invalid command

    c2: command is debit e2: print invalid A/C

    c3: A/C is valid e3: print debit amountnot valid

    c4: Transaction amount not e4: debit A/Cvalid e5: credit A/C

  • 7/29/2019 Materi TIS10

    33/53

    33

    Example: Cause-Effect Graph

    C1

    C2

    C3

    C4

    E1

    E2

    E3

    E5

    E4andand

    or

    and

    and

    and

    and

    and

    not

    not

  • 7/29/2019 Materi TIS10

    34/53

    34

    and

    Example: Cause-Effect GraphC1

    C2

    C3

    C4

    E1

    E2

    E5

    E4

    E3and and

    ornot

    andand

    andand

    not

  • 7/29/2019 Materi TIS10

    35/53

    35

    ExampleDecision table showing the combinations of input

    conditions that make an effect true. (Summarized fromCause Effect Graph)

    Write test cases to exercise each Rule in decision Table.

    Example: C1C2

    C3

    C4

    00

    -

    -

    1-

    0

    -

    -1

    1

    0

    -1

    1

    1

    1-

    1

    1

    E1

    E2

    E3

    E4

    E5

    1

    1

    1

    1

    1

  • 7/29/2019 Materi TIS10

    36/53

    36

    Error GuessingFrom intuition and experience, enumerate a list of possible

    errors or error prone situations and then write test cases toexpose those errors.

  • 7/29/2019 Materi TIS10

    37/53

    37

    White Box TestingWhite box testing is concerned with the degree to which testcases exercise or cover the logic (source code) of the program.

    White box Test case design techniques

    Statement coverage Basis Path Testing

    Decision coverage Loop testing

    Condition coverage Decision-condition coverage

    Multiple condition coverage Data flow testing

  • 7/29/2019 Materi TIS10

    38/53

    38

    White Box Test-Case DesignStatement coverage write enough test cases to execute every statement atleast once

    TER (Test Effectiveness Ratio)

    TER1 = statements exercised / total statements

  • 7/29/2019 Materi TIS10

    39/53

    39

    Examplevoid function eval (int A, int B, int X )

    {

    if ( A > 1) and ( B = 0 )

    then X = X / A;if ( A = 2 ) or ( X > 1)

    then X = X + 1;

    }Statement coverage test cases:

    1) A = 2, B = 0, X = 3 ( X can be assigned any value)

  • 7/29/2019 Materi TIS10

    40/53

    40

    Decision coverage write test cases to exercise the true and false

    outcomes of every decision

    TER2 = branches exercised / total branches

    Condition coverage write test cases such that each condition in a

    decision takes on all possible outcomes atleast once

    may not always satisfy decision coverage

    White Box Test-Case Design

  • 7/29/2019 Materi TIS10

    41/53

    41

    Examplevoid function eval (int A, int B, int X )

    {

    if ( A > 1) and ( B = 0 ) then

    X = X / A;if ( A = 2 ) or ( X > 1) then

    X = X + 1;

    }

    Decision coverage test cases:

    A > 1

    andB = 0

    A = 2or

    X > 1

    X = X+

    X = X/

    a

    cT

    Fb

    eT

    Fd

    2) A = 2, B = 1, X = 1 (abe)

    1) A = 3, B = 0, X = 3 (acd)

  • 7/29/2019 Materi TIS10

    42/53

    42

    ExampleCondition coverage test cases must

    cover conditions

    A>1, A1, X 1andB = 0

    A = 2or

    X > 1

    X = X+

    X = X/

    a

    cT

    Fb

    eT

    F

    d

  • 7/29/2019 Materi TIS10

    43/53

    43

    White Box Test-Case DesignDecision Condition coverage write test cases such that each condition in a decision takes

    on all possible outcomes at least once and each decisiontakes on all possible outcomes at least once

    Multiple Condition coverage write test cases to exercise all possible combinations of

    True and False outcomes of conditions within a decision

  • 7/29/2019 Materi TIS10

    44/53

    44

    ExampleDecision Condition coverage test

    cases must cover conditions

    A>1, A1, X 1 and B = 0) T, F

    ( A = 2 or X > 1) T, F

    Test cases:1) A = 2, B = 0, X = 4 (ace)

    2) A = 1, B = 1, X = 1 (abd)

    A > 1andB = 0

    A = 2or

    X > 1

    X = X+1

    X = X/ A

    a

    cT

    Fb

    eT

    F

    d

  • 7/29/2019 Materi TIS10

    45/53

    45

    ExampleMultiple Condition coverage must cover conditions

    1) A >1, B =0 5) A=2, X>12) A >1, B !=0 6) A=2, X

  • 7/29/2019 Materi TIS10

    46/53

    46

    Basis Path Testing1. Draw control flow graph of program from the program

    detailed design or code.

    2. Compute the Cyclomatic complexity V(G) of the flow

    graph using any of the formulas:V(G) = #Edges - #Nodes + 2

    or V(G) = #regions in flow graph

    or V(G) = #predicates + 1

  • 7/29/2019 Materi TIS10

    47/53

    47

    Example

    1

    2

    3

    4

    5 10

    6

    7

    8

    9

    R4

    R3

    R211

    12

    13

    R1

    R6

    R5

    V(G) = 6 regions

    V(G) = #Edges - #Nodes

    + 2 = 17 - 13 + 2 = 6

    V(G) = 5 predicate-nodes

    + 1 = 6

    6 linearlyindependent paths

  • 7/29/2019 Materi TIS10

    48/53

    48

    Basis Path Testing (contd)3. Determine a basis set of linearly independent paths.

    4. Prepare test cases that will force execution of each path in

    the Basis set.

    The value of Cyclomatic complexity provides an upper bound on

    the number of tests that must be designed to guarantee coverage

    of all program statements.

    http://testing2_iitkh.ppt/http://testing2_iitkh.ppt/
  • 7/29/2019 Materi TIS10

    49/53

    49

    Loop TestingAims to expose bugs in loops

    Fundamental Loop Test criteria1) bypass the loop altogether

    2) one pass through the loop

    3) two passes through the loop before exiting

    4) A typical number of passes through the loop, unlesscovered by some other test

  • 7/29/2019 Materi TIS10

    50/53

    51

    Data Flow TestingSelect test paths of a program based on the Definition-Use

    (DU) chain of variables in the program.

    Write test cases to cover every DU chain is at least once.

  • 7/29/2019 Materi TIS10

    51/53

    52

    Thank You

    Any Questions ????

  • 7/29/2019 Materi TIS10

    52/53

    Question

    ??

  • 7/29/2019 Materi TIS10

    53/53

    Thank you