Sunday, July 15, 2012
Describe some Caching Issues?
Saturday, August 6, 2011
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.
Posted by
Sunflower
at
8/06/2011 04:11:00 PM
0
comments
Labels: Attributes, Code, Coverage, Design, Effort, Inheritance, Messages, Metrics, Object Oriented, Objects, Package, Product Metrics, Quality, Software testing, Test cases, Testing
|
| Subscribe by Email |
|
Wednesday, April 13, 2011
What is Software Architecture ? What are subsystems and interfaces?
Software architecture defines a set of decisions about the organization. It includes:
- how to select structural elements.
- how to select their interfaces.
- how to select the behavior.
- how to select the composition of these structural and behavioral elements into larger subsystems.
- architectural style that guides this organization.
A software architecture is a description of the sub-systems and components of a software system and the relationships between them.
Software architecture is layered structure of software components and the manner in which these components interact.
A software architecture is modeled using package diagram of UML. A package is a model element that can contain other elements.
A subsystem is a combination of package and class. The advantages of defining subsystem are:
- Development of smaller units is possible.
- Re-usability increases.
- Handling complexity is managed properly.
- Maintainability eases.
- Supports portability.
An interface is a set of operations.
- Allows the separation of the declaration of behavior from the realization of the behavior.
- Serves as a contract to help in the independent development of the components by the development team, and ensures that the components can work together.
- There are two styles of communication subsystems use: client-server and peer-to-peer communication.
Posted by
Sunflower
at
4/13/2011 02:58:00 PM
1 comments
Labels: Architecture, Behavioral, Components, Diagram, Interfaces, Modeling, Organization, Package, Software, Software Architecture, Structural, Sub system, Sub Systems, UML
|
| Subscribe by Email |
|