Scribd
Upload
9 views17 pages

Software Testing & Quality - Wk6

Uploaded by

moayyadsmra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
9 views17 pages

Software Testing & Quality - Wk6

Uploaded by

moayyadsmra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

Click to edit Master title style

Software Testing & Quality


M o d u l e ( U n i t ) Te s t i n g

1
Click to edit Master title style

Module (Unit) Testing

2 2
Click to edit
Mid-term Report
Master title style

• Find a software testing tool and make an assessment


• Prepare an 8-mins talk & a 5-mins QA session
• What are the features?
• Who are the target users?
• What type of applications can it be applied to? What special supports
does it have?

• Presentation Date: 11/8 Wed 14:00-17:00


• Report Due: 11/12 Sun 24:00
• Submit a 500 words report

3 3
Click to (Unit)
Module edit Master
Testing
title style

• Module testing (or unit testing) is a process of testing


the individual subprograms, subroutines, classes, or
procedures in a program.
• Motivations:
1. Handling heterogeneity of software system,
2. Localizing bugs,
3. Parallelizing testing process.

4 4
Click to (Unit)
Module edit Master
Testing
title style

• White-box testing-oriented:
1. White-box testing is possible for smaller programs;
2. Validation is the focus of later stages.
• The test-case design procedure for a module test:
Analyze the module’s logic using one or more of the
white-box methods, and then supplement these test cases
by applying black-box methods to the module’s
specification.

5 5
Click to (Unit)
Module edit Master
Testing
title style

• We need to consider the implications of the manner


in which the modules are combined to form a
working program:
• The form in which module test cases are written
• The types of test tools that might be used
• The order in which modules are coded and tested
• The cost of generating test cases
• The cost of debugging (locating and repairing detected
errors)

• Non-incremental vs incremental

6 6
Click to (Unit)
Module edit Master
Testing
title style

• Pros of incremental testing:


1. Non-incremental testing requires more work.
2. Programming errors related to mismatching interfaces
or incorrect assumptions among modules will be
detected earlier.
3. Debugging should be easier.
4. Incremental testing might result in more thorough
testing.
• ……and cons:
1. The non-incremental approach appears to use less
machine time.
2. At the beginning of the module testing phase, there is
more opportunity for parallel activities when non-
incremental testing is used.

7 7
Click to edit
Top-down Testing
Master title style

• Top-down testing = Top-down development ≠ Top-down design


• Stub modules should contain more than returning control, sending an
error message or fixed outputs.
• Example:
A — Main module.
B — Obtain summary of transaction file.
C — Determine whether weekly status meets quota.
D — Produce weekly summary report.

8 8
Click to edit
Top-down Testing
Master title style

• Possible testing sequences:


1. ABCDEFGHIJKL
2. ABEFJCGKDHLI
3. ADHIKLCGBFJE
4. ABFJDIECGKHL
5. ABFJDICGEKHL

• Guidelines:
1. “Critical sections” first;
2. I/O modules first.

9 9
Click to edit
Top-down Testing
Master title style

• Advantages:
1. Allows you to find human-factor errors and problems.
2. Makes it possible to demonstrate the program to the eventual user.
3. Serves as evidence that the overall design of the program is sound.
4. Serves as a morale booster.

• Disadvantages:
1. Some test cases for a module distant from the input module (e.g., H)
might not be created.
2. It’s difficult to reason how to create those test cases even if they are
possible.
3. It’s hard to relate the final outputs to the immediate results produced by
a module under testing (e.g., E) distant from the output module.
4. Top level design might change through time.
5. Incomplete testing might happen due to (a) difficulty to build stub
modules or (b) upper level modules providing resourse for lower ones.
1010
Click to editTesting
Bottom-up Master title style

• Guidelines:
1. “Critical sections” first;
2. I/O modules first.

1111
Click to edit Master title style
Comparison

1212
Click to edit
General Guidelines
Master title style

• Do inspections or code reviews first.


• Use automatic tools.
• Check side effects.
• Test another person’s code. (e.g., caller module programmer can be
the best candidate for testing callee module.)
• Avoid throwaway test cases.
• Practice breakage testing.

1313
Click to edit Master
Higher-Order Testingtitle style

1. Translate the program user’s needs into a set of


written requirements. These are the goals for the
product.
2. Translate the requirements into specific objectives by
assessing feasibility, time, and cost, resolving
conflicting requirements, and establishing priorities
and trade-offs.
3. Translate the objectives into a precise product
specification, viewing the product as a black box and
considering only its interfaces and interactions with
the end user. This description is called the external
specification.
4. If the product is a system such as an operating
system, flight-control system, database system, or
employee personnel management system, rather
than an application (e.g., compiler, payroll program,
word processor), the next process is system design.
1414
Click to edit Master
Higher-Order Testingtitle style

5. Design the structure of the program or programs by


specifying the function of each module, the
hierarchical structure of the modules, and the
interfaces between modules.
6. Develop a precise specification that defines the
interface to, and function of, each module.
7. Translate, through one or more substeps, the module
interface specification into the source code algorithm
of each module.

1515
Click to edit Master
Higher-Order Testingtitle style

• Requirements specify why the program is needed.


• Objectives specify what the program should do and
how well the program should do it.
• External specifications define the exact representation
of the program to users.
• Documentation associated with the subsequent
processes specifies, in increasing levels of detail, how
the program is constructed.

1616
Click to edit Master title style

Thank You!

17

You might also like