software testing 4th chapter

Q 1. What aspects of the software are tested in Unit Testing?

Ans:

         Diagram:

Explanation:

1)      Unit testing is a low level of the software testing process where individual units of a software are tested.

2)      The purpose is to validate that unit of the software performs as designed.

3)      A unit is a smallest testable part of sw.

4)      It usually has one or a few inputs & usually a single output.

5)      In procedural programming a unit may be an individual program, function, procedure, etc

6)      In object oriented programming the smallest unit is a method, which may belong to a    base/super class, abstract class or derived/child class.

Aspects of Unit testing:

1)       Interface:

1.       The module interface is tested to ensure that information properly flows into and out of the program unit under test.

2.       Tests of data flow across a module interface are required before any other test is initiated.

3.       If data do not enter and exit properly, all other tests are moot.

2)      Local data structure:

The local data structure is examined to ensure that data stored temporarily maintains its integrity during all steps in an algorithm's execution.

3)      Boundary conditions:

Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit or restrict processing.

4)      Independent paths:

All independent paths (basis paths) through the control structure are exercised to ensure that all statements in a module have been executed at least once.

5)      Error-handling paths:

All error handling paths are tested so as to ensure that the error are handled properly without causing system failure and the appropriate message is shown to user.

Q 2. Explain integration testing in OO context ?               

OR

Define integration testing in context with conventional software. Explain Top-down integration and Bottom-up integration.               

==>Integration Testing:

1)       Integration testing can be referred as a systematic technique for the purpose of

software architecture construction and at the same time carrying out test to find out

errors related to interfacing.

2)       The objective is to take unit tested components and build a program structure that has

been dictated by design.

3)       In most of the cases non-incremental approach is used. There will be a combination of

all components done in advance. Full program will be tested as a whole.

4)       The number of errors can be found out in integration testing but correction of these

errors is very difficult because separation of causes is complicated as the program

might be very big.

5)       Once the errors are removed, new errors may appear and this process will be continued

like endless loop.

6)       Small incremental are used to construct and test the program in incremental

integration. Finding out errors and correcting them is easy here. Interfaces are tested

      completely with the systematic test approach.

·         There are 2 Approaches of integration testing:

1)      Top- down  integration

2)      Bottom-up  integration

i) Top- down integration

                    i)            Main control module used as a test driver and stubs are substitutes for components directly subordinate to it.

                  ii)            Subordinate stubs are replaced one at a time with real components (following the depth-first or breadth-first approach).

                iii)            Tests are conducted as each component is integrated.

                iv)            On completion of each set of tests and other stub is replaced with a real component.

                  v)            Regression testing may be used to ensure that new errors not introduced.

ii) Bottom- up integration

i)                    Low level components are combined in clusters that perform specific software function.

ii)                  A driver (control program) is written to coordinate test case input and output.

iii)                The cluster is tested.

iv)                Drivers are removed and clusters are combined moving upward in the program structure.

Q 3. What do you mean by software testing ? Explain software testing strategy.

==>Software testing:

1. Testing is a process of executing a program with the intent of finding an error.

2. A good test case is one that has a high probability of finding an as-yet undiscovered

    error.

3. A successful test is one that uncovers an as-yet-undiscovered error

4. All tests should be traceable to customer requirements.

5. A good test has a high probability of finding an error.

6. A good test is not redundant

7. A good test should be ―best of breed‖

8. A good test should be neither too simple nor too complex.

Strategy:

1.      A good test has a high probability of finding an error:

 To achieve this goal, the tester must understand the software and attempt to develop a mental picture of how the software might fail.

For example, one class of potential failure in a GUI (graphical user interface) is a failure to recognize proper mouse position. A set of tests would be designed to exercise the mouse in an attempt to demonstrate an error in mouse position recognition.

2.      A good test is not redundant:

a.       Testing time and resources are limited.

b.      There is no point in conducting a test that has the same purpose as another test.

c.       Every test should have a different purpose (even if it is subtly different).

d.      For example, a module of the SafeHome software is designed to recognize a user password to activate and deactivate the system.

To uncover an error the tester designs a series of tests that input a sequence of passwords. Valid and invalid passwords are input as separate tests.

3.    A good test should be “best of breed”:

a.       In a group of tests that have a similar intent, time and resource limitations may mitigate toward the execution of only a subset of these tests.

b.      In such cases, the test that has the highest likelihood of uncovering a whole class of errors should be used.

4.      A good test should be neither too simple nor too complex:

a.       Although it is sometimes possible to combine a series of tests into one test case, the possible side effects associated with this approach may mask errors.

b.      In general, each test should be executed separately.  

Q 4. Explain types of system testing ?

è System Testing

1)      System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system.

2)      Although each test has a different purpose, all work to verify that system elements have been properly integrated and perform allocated functions.

Following are the types of System Testing:

I)                   Recovery testing

II)                Security testing

III)             Stress testing

IV)             Performance testing

1)      Recovery Testing:

Recovery testing is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed.

2)      Security Testing:

Security testing attempts to protect it from improper penetration.

The system‘s security must tested for invulnerability from attack.

3)      Stress Testing:

Stress testing executes a system in a abnormal quantity, frequency, or volume.

For example,

(1) special tests may be designed that generate ten interrupts per second, when one or two is the average rate,

 (2) test cases that require maximum memory or other resources are executed,

4)      Performance Testing:

Performance tests are often coupled with stress testing and usually require both hardware and software instrumentation.

Q  5. Discuss various Interface Analysis and Design methods.

==>

           

SOFTWARE TESTING 2nd Chapter

Q 1. Explain following terms with the help of example of software engineering:

i) Data Objects

ii) Data Attributes

iii) Relationships

iv) Cardinality and Modality

Ans:

1) Data objects

A data object‖ is a representation of almost any composite information that must be understood

by software. By composite information, something that has a number of different properties or

attributes.

Example:

Width (a single value) would not be a valid data object, but dimensions (incorporating height,

width and depth) could be defined as an object.

2) Attributes

Attributes define the properties of a data object and take one of three different characteristics.

They can be used to:

1. Name an instance of the data objects,

2. Describe the instance,

3. Make reference to another instance in another table.

Example: attributes must be defined as identifier. Referring to data object car, a reasonable

identifier or attribute might be the ID No, Color.

                       

3) Relationships

Data object are connected to one another in variety of different ways. This links or connection of

data objects or entities with each other is called as relationship.

Example:

A connection is established between person and car , because the two objects are related.

1.      A person owns a car

2.      A person purchase a car

3.      A person sells a car

4.      Person cleans a car

The relationship owns, purchase, sells, and cleans‖ define the relevant connections

between person and car.

4) Cardinality

Cardinality is the specification of the number of occurrences of one object that can be related to

the number of occurrences of another object. Cardinality is usually expressed as simply one or

many.

Example: One object can relate to only one other object (a 1:1 relationship);

One object can relate to many other objects (a 1: N relationship);

Some number of occurrences of an object can relate to some other number of occurrences of

another object (an M: N relationship);