1. Stages of Test
and Types of Test
Tài liệu đào tạo

2. Agenda
 Test
methods
 Types of Test
 Stages of Test
 Test Web Application
 Demo Tool Test WAPT

3. Two Fundamental Approaches
Structural Testing
–
–
Also known as: white box testing.
Test is based on the structure of the code.
Functional Testing
- Also known as: black box testing, functional
testing, behavioral testing.
- Test is based on the behavior of the software.
The code itself is not looked at.

4. White Box vs. Black Box Testing
White Box
INPUT
INPUT
OUTPUT
OUTPUT

5. White Box (Structural) Testing




Examines internal software design.
Requires the tester to have detailed knowledge of the
software structure.
Static structural analysis
– Complexity
– Code coverage
– Paths
Dynamic structural analysis
– Call pairs
– Control Flow
– Data flow
– Memory leaks

6. White Box Testing - Definition
A test case design method that uses the control
structure of the procedural design to derive test
cases.

7. White Box Testing
 Driven
by program structure
 Looks at the implementation details.
 Concerned with:
–
–
–
–
–
Programming style
Control method
Language
Database design
Coding details

8. Black Box (Functional) Testing



Based upon functional operation, does not require
knowledge of the code or software structure.
Functional test coverage (requirements tracing).
Examples:
–
–
–
–
–
–
–
Requirements based testing
Use case testing
State machine testing
Boundary value testing (domain testing)
Equivalence class partitioning
Syntax testing
Data flow testing

9. Stages of Test – V Model

10. Developer Testing vs. Independent Testing
(Tester)




Some testing is done by the code developers.
Some testing is done by an independent testing group.
The presence of an independent test group does not
mean that the developers stop testing.
The need for independent Testing: Developers know
how to make their code word so they miss a lot of bugs

11. Organizational Roles - Testing
Unit Testing
Code
Developers
Independent
Test Group
Integration
Testing
System
Testing

12. Unit Test







Test individual units of program: method, function, procedure
Done by the developers.
White box testing.
Test cases are defined by specifying paths.
Focus on a relatively small segment of code.
A path is an instruction sequence that threads through the
entire program form initial entry to final exit.
Simplest approach is to ensure that every statement is
exercised once.
More stringent: Require coverage of every path. Usually not
practical.

13. Unit Test (cont.)

What to test:
•
•
•
•
•
Data structure is examined
Boundary conditions are tested to ensure
that the module operates properly for
input and output data
All independent paths are exercised
Error handling paths are tested
Use of stubs (modules to be called) and
drivers (modules that calls)

14. Integration Test
Test integrated components/modules, interface of program
– Executed by developers, testers
Combining the individual components
Problems may occur due to:
– Data lost across interface
– One module can have an adverse affect on another
– Sub functions may not produce the desired major functions
– Individual acceptable imprecision but unacceptable if
magnified
– Global data structures presents problems
Is a systematic technique for constructing the program structure
while conducting tests to uncover errors associated with
interfacing
Objective is to take unit tested modules and build a program
structure that has been dictated by design
–





15. System Test
–
–
–
Testing system as whole
Testing requirements and business processes
Executed by testers

16. How to perform System test


Objectives
 To make sure the software functions properly in
accordance with software requirements specification.
Method
 Black-Box Testing
 Input – Compare results – Log defect (if any)

17. System Test Categories









Functionality
Reliability/Availability – To find problems based upon continuous
running of the system.
Load/Stress – To identify problems caused by peak load conditions.
Volume – To find problems in the system’s ability to process a
heavy load continuously.
Performance – To determine the actual response time and CPU
loading conditions of the system.
Installablities:
Recovery – Force the system to fail and then find problems in the
recovery processing of the system. .Particularly data.
Security – To find holes in the system’s security provision.
Serviceability – Maintenance and repair procedures.

18. Acceptance Test
–
–
–
–
–
–
it is the customer’s way to verify that what was
wanted is what is built
uncovers more than requirements discrepancies
allows the customers to determine what they really
want, whether specified in the document or not.
new problems may arise
rapid prototyping
changes may not only mean improper definition of
requirement, but also because customers may
decide that the problem is changed and a different
solution is needed

19. Acceptance Test
 To
validate that the delivered system meets the
actual business needs of the corporation.
 Executed by customer
 The customer may write the acceptance test
criteria and request that these be executed by
the developer,
 The developer may produce the acceptance test
criteria which are to be approved by the
customer.

20. Type of Test
–
–
–
–
–
–
–
–
–
–
–
Functional testing (F)
User Interface testing (U)
Performance testing (P)
Data & Data integrity testing (D)
Security & Access control testing (A)
Load testing (L)
Stress testing (S)
Volume testing (V)
Regression testing (R)
Installation testing (I)
Business Cycle Testing (B)

21. Functional testing



Function testing of the target-of-test should focus on
any requirements for test that can be traced directly to
use cases or business functions and business rules.
The goals of these tests are to verify proper data
acceptance, processing, and retrieval, and the
appropriate implementation of the business rules.
This type of testing is based upon black box
techniques that are verifying the application

22. Functional testing (cont.)
Test Objective:
Technique:
Test functions follow requirements
Ensure proper target-of-test functionality, including
navigation, data entry, processing, and retrieval.
Execute each use case, use-case flow, or function,
using valid and invalid data, to verify the
following:
- The expected results occur when valid and invalid
data is used.
- Valid input data is updated correctly to database
- Each business rule is properly applied.
Completion Criteria: - All planned tests have been executed.
Special
Considerations:
Functional test on Max OS X

23. User Interface testing
 Objective:
–
–
–
Verify navigation
Verify using of access methods (tab keys, mouse
movements, accelerator keys)
Window objects and characteristics, such as menus,
size, position, state, and focus conform to standards

24. User Interface testing (cont.)
 Technique:
–
Create or modify tests for each window to verify
proper navigation and object states for each
application window and objects
 Completion
–
Criteria:
Each window successfully verified to remain
consistent with benchmark version or within
acceptable standard

25. Performance testing
 Objective:
verify performance requirements
have been achieved
–
–
–
Response time
Transaction rates
Other time-sensitive requirements are measured
and evaluated

26. Performance Testing (Cont.)


Technique:
– Use Test Procedures developed for Function or Business
Cycle Testing
– Modify data files to increase the number of transactions or the
scripts to increase the number of iterations each transaction
occurs
Completion Criteria:
– Single Transaction: Successful completion of the test scripts
without any failures and within the expected or required time
allocation per transaction
– Multiple transactions: Successful completion of the test scripts
without any failures and within acceptable time allocation

27. Data & Data integrity testing

Objective:
–

Technique:
–
–

Ensure database access methods and processes function
properly and without data corruption
Check the returned data to ensure that the correct data was
retrieved for the correct transaction
Check the database to ensure the data has been populated as
intended, all database events occurred properly
Completion Criteria:
–
All database access methods and processes function as
designed and without any data corruption

28. Security & Access control testing
 Application-level
–
Check user right: verify that an actor/user can
access only those functions or data if they have
right
 System-level
–
Security
Security
Verify that only those users granted access to the
system are capable of accessing the applications
and only through the appropriate gateways

29. Load testing







Forcing the system to do a large amount of processing
Depends on the type of system.
Large number of transactions.
Large files.
Large number of files.
Large number of clients.
Repeated operations.

30. Load testing (cont.)

Objective:
– Verify performance behavior time for designated transactions
or business cases under varying workload conditions
Technique:
– Use tests developed for Function or Business Cycle Testing
– Modify data files to increase the number of transactions or the
tests to increase the number of times each transaction occurs

Completion Criteria:

–
–
Multiple transactions or multiple users: Successful completion
of the tests without any failures and within acceptable time
allocation
Performed on a dedicated machine or at a dedicated time

31. Stress testing

Objective: verify functions work without error under the
following stress conditions:
–
–
–

Little or no memory available on the server (RAM)
Maximum actual or physically capable number of clients
connected or simulated
Multiple users performing the same transactions against the
same data or accounts
Technique:
–
–
Use tests developed for Performance Profiling or Load Testing
To test limited resources, tests should be run on a single
machine, and RAM on server should be reduced or limited

32. Volume testing
 Objective:
–
Test with large amounts of data to determine if limits
are reached that cause the software to fail
 Technique:
–
–
Data and database integration
Use tests developed for Function testing

33. Regression testing
 Objective
–
Validate modified parts of the software, to make
sure that the modification does not cause errors in
other parts
 Technique
–
Reuse the set of test cases from an existing test
suite to test a modified module

34. Regression testing (cont.)

What is Regression test
Test the system as a whole. Similar to System test
 Usually take a lot of efforts


When to perform Regression test
–
Regression test usually is performed when:
Total number of change requests arisen since the latest baseline
(with regression test) > the number of requirements in that
baseline
 The total number of post-release defects is out of a pre-defined
threshold
 As planned in Maintenance plan (with Maintenance projects)


35. Installation testing
 To
identify problems in the installation
procedures

36. Business Cycle Testing
 Objective:
–
Ensure proper target-of-test and background
processes function according to required business
models and schedules
 Technique:
–
–
–
All functions that occur on a periodic schedule will
be executed or launched at the appropriate time
Testing will include using valid and invalid data
Each business rule is properly applied

37. Type of Test
Stage of Test
Unit
Integration
System
Acceptance
X
X
X
X
User Interface Tests
X
X
Performance
X
X
Load Testing
X
Security and Access
control Tests
X
Functional Tests

38. Test Web Application

What to test:
•
All components of a Web application on both the client and
server side
•
Validation or Functional Testing
•
HTML Validation
•
Link Testing
•
Load and stress Testing
•
Security Testing
•
Regression Testing

39. Test Web Application (cont.)

Problem:
–
–
–

Impossible to test all possible dependencies and
everything that could go wrong with this site.
Impossible to test varied target audience and platforms
that a web applications addresses
Tools used for load test, volume test
Solution:
–
–
Determine where to focus testing efforts within budget
and schedule constraints
Analyse risks and set priorities based on risk analysis