Please enable JavaScript.
Coggle requires JavaScript to display documents.
Object-Oriented System Testing (Guidelines for Developing Quality…
Object-Oriented System Testing
Quality Assurance Tests
Quality assurance test (or testing) process also include debugging.
Debugging is the process of finding out when something goes wrong and correcting the code to eliminate the errors or bugs that caused the unexpected results.
Some bugs are stealthy (hidden) and might not surface until appropriate test data is used in the testing. Eg: Max limit.
errors
Language syntax errors (e.g., incorrect keyword, punctuation omitted, etc)
Run-time errors (e.g., program tries to access non-existent object (file), divide by zero)
Logic errors occurs. Code syntactically valid, can run without performing any invalid operations but produce incorrect result.
Error-based testing - Use various/different input. Also known as testing the boundary condition.
E.g = “How many items would you like to order?”
Scenario-based testing - Concentrates on what user does. Also called usage-based testing. Check if the system satisfy its requirements (Use Cases).
Testing Strategies
White Box Testing
Logic must be tested to guarantee the system functioning properly. Also called path-testing.
Two type of path-testing:
(i) Statement Coverage testing and
Every statement in the program must be executed at least once.
Every branch alternative must be executed at least once under some test.
(ii) Branch Coverage testing.
Top-down Testing
Main logic or object interaction need more testing than the individual object’s methods.
Bottom-up Testing
Start with the methods and classes (objects), next combine them and test their interaction (messages) this will lead to integration testing.
It assumes that individual programs and modules are fully developed as stand alone processes.
These modules are tested individually, then combined for integration testing
Bottom-up testing is more appropriate for O-O systems.
You test each object then combine them and test the whole system by utilizing the top-down approach
Black Box Testing
In a black box, the test item is treated as "black" whose logic (inside working) is unknown.
All that's known is what goes in (input) and what comes out (output).
Black box test works very nicely in testing objects in an O-O environment.
Once you have created fully tested and debugged classes of objects you will put them into library for use or reuse
Impact of OO on Testing
Inheritance does make testing a system more difficult.
If you do not follow the OOD guidelines, you will end up with objects that are extremely hard to debug and maintain.
Test Cases
To have a comprehensive test scheme, test must cover all methods.
To test a system, you must construct some test input cases then describe how the output will look. Next compare the outcome with the expected output.
Use cases developed during analysis can be used to describe the usage test case.
Test cases are developed to find errors.
A good test case is one that can detect errors that are not detected earlier.
Guidelines for Developing Quality Assurance Test Cases
Basically test case is a set of ‘what-if’ questions.
The general format is:
If it receives certain input, it produces certain output.
Guidelines to develop test case as follows:
Describe feature or service that your test attempt to cover
If test case is based on a use case, it is a good idea to refer to the use case name.
Specify what you are testing (the target), what you are going to do to test the feature (testing step) and what you expect to happen.
Test the normal use of object’s methods.
test the abnormal but reasonable use of object’s methods.
Test the boundary condition.
Test objects interactions and messages sent among them.
Document the cases so they become the starting basis for the follow-up test.
Add other ‘what-if’ questions to the list and try to answer them, repeat this process until the list is acceptable.