What are different metrics for testing?

Software testers must rely on analysis, design, and code metrics to guide them in design and execution of test cases. Metrics for testing fall into two broad categories:
- metrics that attempt to predict the likely number of tests required at various testing levels.
- metrics that focus on test coverage for a given component.

Function based metrics use a predictor for overall testing effort. Architectural design metrics provide information on the ease and difficulty which is associated with integration testing.

The metrics defined for object oriented provide a general indication of the amount of testing effort required to exercise an object oriented system. Object oriented testing can be quite complex. Metrics can assist in targeting testing resources at threads, scenarios, and packages of classes that are suspect based on measured characteristics. Design metrics that has direct influence on test-ability of object oriented system include:

- Lack of cohesion in methods (LCOM): Higher the value of LCOM, more states must be tested.
- Percent public and protected (PAP): High value of PAP increases the possibility of side effects among classes because public and protected attributes lead to high coupling.
- Public access to data members (PAD): High value of PAD increases the possibility of side effects among classes.
- Number of root causes (NOR): NOR is the count of distinct class hierarchy described in design model. As NOR increases, testing effort increases.
- Fan-in (FIN): It is an indication of multiple inheritance. If it is greater than 1, a class inherits its attributes and operations from more than one root class.
- Number of children (NOC) and depth of inheritance tree (DIT): The super class methods will have to be retested for each sub class.

Introduction to Object Oriented Testing Methods

Object oriented testing begins in the small with a series of tests designed to exercise class operations and check whether errors exist as one class collaborates with other classes. Use based testing along with fault based testing is applied to integrated classes. In the end, use cases are used to uncover errors at software validation level.

Encapsulation can create a minor problem when testing because testing reports on concrete and abstract state of an object. Multiple inheritance complicates testing by increasing number of contexts for which testing is required. Black box testing methods are appropriate for object oriented systems as they are for systems developed using conventional software engineering methods.

The strategy for fault based testing is to hypothesize a set of possible faults and then derive the tests to prove each of that hypothesis. The effectiveness of these techniques depends on how testers see a plausible fault.

Inheritance complicates the testing process. even though the base class has been properly tested, there is a need to test all classes derived from it.

Scenario based testing will uncover errors that occur when any actor interacts with the software. It concentrates on what the user does and not what the product does. This type of testing uncovers interaction errors.

Surface structure is an externally observable structure of object oriented program. Testing surface structure is similar to black box testing. Deep structure refers to the internal technical details of object oriented program. It exercises dependencies, behaviors and communication mechanisms. It is similar to white box testing.

How to implement Controllers - Programming Guidelines

To implement controllers, a good programming practice is to use abstract classes and interfaces. It increases the ability of the software to be reusable and manageable. It allows the software to have plug and play options.

WHAT IS AN ABSTRACT CLASS

Abstract class is a class that cannot be instantiated. It is located at the top of an object oriented class hierarchy. It defines the actions possible with objects of all subclasses of class. The methods defined in abstract class are called abstract methods.

WHAT IS AN INTERFACE

Interfaces define the signatures of a set of methods withoutthe body. Interfaces define a standard and public way of specifying the behavior of classes. Interface can only contain abstract methods, properties but we don’t need to put abstract and public keyword. All the methods and properties defined in Interface are by default public and abstract. Interfaces exhibits polymorphism.

- Interfaces are needed when similar methods are implemented by unrelated classes.
- Through interfaces, we can actually capture similarities among unrelated classes without artificially forcing a class relationship.
- Interfaces are needed to reveal an object's programming interface without revealing its class.
- Interfaces are needed to model multiple inheritance which allows aclass to have more than one superclass.

IMPLEMENTATION METRICS

The metrics used for implementation are the metrics for the design. These are:
- Lines of Code (LOC)
- Number of classes.
- Number of documentation pages.
- Total cost.
- Effort.

Designing Class based Components - Component Level Design Guidelines

As component level design proceeds, there are some guidelines other than basic design guidelines. These guidelines are applied to components and their interfaces, their dependencies and inheritance.

COMPONENTS
- Naming conventions should be established for components.
- These are specified as part of architectural model and then refined and elaborated as part of component level design.
- Architectural component names should be drawn from the problem domain.
- It should have meaning to all stakeholders.

INTERFACES
- Provides information about communication and collaboration.
- Lollipop approach to represent interface should be used in combination with UML box and dashed arrow.
- Interface should flow from left side of the component box for consistency.
- Only relevant interfaces to component should be shown.

DEPENDENCIES AND INHERITANCE
- Model dependencies from left to right.
- Model inheritance from bottom to top.
- Component interdependencies should be represented via interfaces.

Object Oriented Testing Methods - Fault Based Testing

Object oriented system testing begins at different levels to uncover errors that may occur as classes collaborate with one another and subsystems communicate across architectural layers.
Actual object oriented testing begins with a series of tests designed to exercise class operations and check whether errors exists when a class collaborates with other classes.
Attributes and operations are encapsulated, testing operations outside of the class is unproductive. Encapsulation, an essential design concept, creates a minor obstacle during testing. Inheritance also leads to additional challenges for the test case designer. Multiple inheritance complicates testing further by increasing the number of contexts for which testing is required.
White box testing methods like basis path, loop testing or data flow techniques can help to ensure that every statement in an operation has been tested. Black box testing methods are also appropriate for object oriented systems as they are for systems developed using conventional software engineering methods.

FAULT BASED TESTING

The strategy for fault based testing is to hypothesize a set of plausible faults and then derive tests to prove each hypothesis. The objective of fault based testing within an object oriented system is to design tests that have a higher possibility of uncovering plausible errors. Test cases are designed to exercise the design or code and to determine whether faults exist. This approach is really no better than any random testing technique if faults in object oriented systems are implausible.

Three types of faults are encountered when integration testing looks for plausible faults in operation calls or message connections. These faults are:
- unexpected result.
- wrong operation/message used.
- incorrect invocation.
Integration testing applies to attributes as well as operations. Integration testing attempts to find errors in the client side and not the server.