Software Teting Structural

Structural system testing is designed to verify that the developed system and programs work. The objective is to ensure that the product designed is structurally sound and will function correctly. It attempts to determine that the technology has been used properly and that when all the component parts are assembled they function as a cohesive unit.

The structural system testing techniques provide the facility for determining that the implemented configuration and its interrelationship of parts functions so that they can perform the intended tasks. The techniques are not designed to ensure that the application system is functionally correct, but rather, that it is structurally sound.

Click here to see different kinds of structural testing.

Stress Testing Techniques:

Stress testing is designed to determine if the system can function when subject to large volumes of work i.e., larger than would be normally expected. The areas that are stressed include input transactions, internal tables, disk space, output, communications, computer capacity, and interaction with people. If the application functions adequately under test, it can be assumed that it will function properly with normal volumes of work.

Objectives of stress testing :

The objective of stress testing is to simulate a production environment for the purpose of determining that:

1 • Normal or above-normal volumes of transactions can be processed through the transaction within the expected time frame.

2 • The application system is structurally able to process large volumes of data.

3 • System capacity, including communication lines, has sufficient resources available to meet expected turnaround times.

4 • People can perform their assigned tasks and maintain the desired turnaround time.

How to use this :

Stress testing should simulate as closely as possible the production environment. Online systems should be stress tested by having people enter transactions at a normal or above normal pace.


Batch systems can be stress tested with large input batches. Error conditions should be included in tested transactions. Transactions for use in stress testing can be obtained from one of the following three sources:

1. • Test data generators
2. • Test transactions created by the test group
3. • Transactions previously processed in the production environment

In stress testing, the system should be run as it would in the production environment. Operators should use standard documentation, and the people entering transactions or working with the system should be the clerical personnel that will work with the system after it goes into production. Online systems should be tested for an extended period of time, and batch systems tested using more than one batch of transactions.

Stress testing should be used when there is uncertainty regarding the amount of work the application system can handle without failing. Stress testing attempts to break the system by overloading it with a large volume of transactions. Stress testing is most common with online applications because it is difficult to simulate heavy volume transactions using the other testing techniques.

The disadvantage of stress testing is the amount of time it takes to prepare for the test, plus the amount of resources consumed during the actual execution of the test. These costs need to be weighed against the risk of not identifying volume-related failures until the application is placed into an operational mode.(126)

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO