1. Unit Testing in the OO Context(Chapter 19-Roger P)
It involves testing for each class and each instance of a class (object) packages, attributes (i.e. data) and the operations (also known as methods or services) that manipulate these data.
Rather than testing an individual module, the smallest testable unit is the encapsulated class or object. This is so because a class can contain a number of different operations and a particular operation may exist as part of a number of different classes.
Consider a class hierarchy in which an operation X is defined for the superclass and is inherited by a number of subclasses.
Each subclass uses operation X, but it is applied within the context of the private attributes and operations that have been defined for the subclass.
Because the context in which operation X is used varies in subtle ways, it is necessary to test operation X in the context of each of the subclasses.
Class testing for OO software is the equivalent of unit testing for conventional ware.
Unlike unit testing class testing for OO software is driven by the operations encapsulated by the class and the state behavior of the class.

2. Integration testing
There are two different strategies for integration testing of OO system
The first i.e. thread-based testing, integrates the set of classes required to respond to one input or event for the system. Each thread is integrated and tested individually. Regression testing is applied to ensure that no side effect occur.
The second integration approach i.e. the use-based testing, begins the construction of the system by testing those classes (called independent classes) that use very few (if any) of server classes. After the Independent classes are tested, the next layer of classes, called dependent classes, that use the independent classes are tested. This sequence of testing layers of dependent classes continue until the entire system is constructed.
Cluster testing is one step in the integration testing. Here a cluster of collaborating classes (det ermined by examine the CRC and object-relationship model) is exercised by designing test cases that attempt to uncover errors in the collaborations.

3. Validation Testing in an OO Context
The validation of OO software focuses on user-visible actions and user-recognisable output from the system. To assist in the derivation of validation testing, the tester should
work upon the use-cases that are part of the analysis model. The use-case provides a scenario that has a high likelihood of uncovered errors in the user interaction requirements.
Conventional black-box testing methods can be used to drive validation tests.
In addition, test cases may be derived from the object-behavior model and from event flow diagram created as part of OOA.

4. Test Case Design For OO Software
an overall approach to OO test case design has been defined by Berard:
Each test case should be uniquely identified and explicitly associated with the class to be tested.
The purpose of the test should be stated.
A list of testing steps should be developed for each test and should contain:
A list of specified states for the object that is to be tested.
A list of messages and operations that will be executed as a consequence of the test.
A list of exceptions that may occur as the object is being tested.
A list of external conditions (i.e., the changes in the environment external to the software that must exist in order to properly conduct the test.)
Supplementary information that will aid in understanding or implementing the test.
--Unlike conventional test case design, which is driven by an input-process-output view of software or the algorithmic detail of individual modules
--object-oriented testing focuses on designing appropriate sequences of operations to exercise the states of a class.

5. Fault Based Testing
The object of fault-based testing within an OO system is to design tests that have a high likelihood of uncovering plausible (i.e. hidden) faults.
 Testing a SQRT operation that returns errors for negative numbers. Try the boundaries: a negative number close to zero and zero itself. “Zero itself” checks whether the programmer made a mistake like
If (x>0) calculate_the_square_root():
Instead of the correct
If (x>=0) calculate_the_square_root():
 Consider another example:
If (a && !b || c)
 Possible errors could be
&& should be ||
! was left out
Need of parenthesis around !b || c
 For such plausible faults, we need to design test cases that will force the incorrect expression to fail

6. Website Testing
WebApp testing is a collection of related activities with a single goal: to uncover errors in WebApp content,function,usability,navigability,performance,capacity and security
Web engg and other project stakeholders participate in the webApp testing
The webApp testing process begins by focusing on user-visible aspects of the WebApp and proceeds to tests that exercise technology and infrastructure

7. Testing for WebApps
The objectives of testing within a web engg context, one should consider the dimension of quality
Dimensions of quality:- quality is incorporated into a web applicn as a consequence of good design
Its evaluated by applying a series of technical reviews that assist various elements of design model & by applying a testing process
Dimensions of Quality:-Both reviews and testing examine one or more quality dimensions:-
Content is evaluated at both a syntactic and semantic level. At syntactic, spelling, punctuation and grammar are assessed for text based docs. At semantic,correctness,consistency and lack of ambiguity are assessed
Function is tested to uncover errors indicate lack of conformance to customer requirements. Its assessed for correctness,instability and general conformance to appropriate implementation std
Structure is assessed to ensure that it properly delivers WebApp content and function that is extensible, new functionality may be added
Usability is tested to ensure that each category of user is supported by the interface and can learn and apply all reqd.navigation syntax and semantics
Navigability is tested to ensure that all navigation syntax and semantics are exercised to uncover any navigation errors(ex. dead links, improper links, erroneous links)

8. Testing for WebApps
Performance:- tested under variety of operating conditions,configurations and loading to ensure that the system is responsive to user interaction
Compatibility:-is tested by executing WebApp in a variety of diff host config.on both the client and server sides
Interoperability:- it is tested to ensure that the WebApp properly interfaces with other applications and/or databases
Security:- it is tested by potential vulnerabilities and attempting to exploit each

9. Errors within WebApp environment
Many types of Webapp tests uncover problems that are first evidenced on client side
Because webapp is implemented on client side on diff config,diff platforms and in diff environments
Some errors may be there in the incorrect design or HTML coding
Errors are difficult to trace in 3 layer architecture:- client,server and n/w layer

10. Self Study Pg 443-448 Pankaj Jalote Book
Planning s/w Testing
Self Study Pg Pankaj Jalote Book