Volume tests - Volume Testing of Batch Processing Systems

Capacity drivers in batch processing systems are also critical as certain record types may require significant CPU processing, while other record types may invoke substantial database and disk activity. Some batch processes also contain substantial aggregation processing, and the mix of transactions can significantly impact the processing requirements of the aggregation phase.

In addition to the contents of any batch file, the total amount of processing effort may also depend on the size and makeup of the database that the batch process interacts with. Also, some details in the database may be used to validate batch records, so the test database must match test batch files.


Before conducting a meaningful test on a batch system, the following must be known :
- The capacity drivers for the batch records.
- The mix of batch records to be processed, grouped by capacity driver.
- Peak expected batch sizes (check end of month, quarter and year batch sizes).
- Similarity of production database and test database.
- Performance Requirements.


Batch runs can be analyzed and the capacity drivers can be identified, so that large batches can be generated for validation of processing within batch windows. Volume tests are also executed to ensure that the anticipated numbers of transactions are able to be processed and that they satisfy the stated performance requirements.

Volume tests - Volume Testing of Messaging systems

Volume tests are often most appropriate to messaging, batch and conversion processing type situations. In a volume test, there is often no such measure as response time. Instead, there is usually a concept of throughput. A key to effective volume testing is the identification of the relevant capacity drivers. A capacity driver is something that directly impacts on the total processing capacity. For a messaging system, a capacity driver may well be the size of messages being processed.

Most messaging systems do not interrogate the body of the messages they are processing, so varying the content of the test messages may not impact the total message throughput capacity, but significantly changing the size of the messages may have a significant effect. However, the message header may include indicators that have a very significant impact on processing efficiency. For example, a flag saying that the message need not be delivered under certain circumstances is much easier to deal with than a message with a flag saying that it must be held for delivery for as long as necessary to deliver the message, and the message must not be lost. In the former example, the message may be held in memory, but in the later example, the message must be physically written to disk multiple times.

Before conducting a meaningful test on a messaging system, the following must be known:

- the capacity drivers for the messages.
- the peak rate of messages that need to be processed, grouped by capacity driver.
- the duration of peak message activity that needs to be replicated.
- the required message processing rates.


A test can then be designed to measure the throughput of a messaging system as well as the internal messaging system metrics while that throughput rate is being processed. Such measures would typically include CPU utilization and disk activity. It is important that a test be run, at peak load, for a period of time equal to or greater than the expected production duration of peak load.

Purpose of Volume Testing and what are its features.

Volume testing belongs to the group of non-functional tests. Huge amount of data is processed through the application (which is being tested) in order to check the extreme limitations of the system.
- Volume testing refers to testing a software application for a certain data volume.
- Volume testing can (and should) be used in component testing.
- Volume testing will also be undertaken (normally) as part of the User Acceptance test.
- Volume testing is used to find faults and give credible information about the state of the component, on which business decisions can be taken.
- Volume testing might take place to confirm that the central core architecture is the one to proceed with.
- Developers across customers & finish users can do. The tests can be outsourced to a testing laboratory that specializes in performance testing.

Examples:
- Online system: Input fast, but not necessarily fastest possible, from different input channels.
- Database system: The database should be very large. Every object occurs with maximum number of instances.
- File exchange: Especially long files. Maximal lengths. Lengths longer than typical
maximum values in communication protocols.
- Disk space: Try to fill disk space everywhere there are disks.

Volume test is interesting if
• The volume test is not executed before.
• Does the system always has the necessary memory resources?
• Can we guarantee this if several systems share the hardware?
• Is it guaranteed that no larger data volumes than specified will occur?
• Is there a low risk if data volume turn greater than specified anyway but the
system does not work well enough then?

What are different types of black box testing ?

The base of the Black box testing strategy lies in the selection of appropriate data as per functionality and testing it against the functional specifications in order to check for normal and abnormal behavior of the system. These testing types are again divided in two groups:

Testing in which user plays a role of tester.

- Functional Testing : The testing of the software is done against the functional requirements.
- Load testing : It is the process of subjecting a computer, peripheral, server, network or application to a work level approaching the limits of its specifications.
- Stress Testing : The process of determining the ability of a computer, network, program or device to maintain a certain level of effectiveness under unfavorable conditions.
- Ad-hoc testing : Testing carried out informally; no formal test preparation takes place, no recognized test design technique is used, there are no expectations for results and randomness guides the test execution activity.
- Smoke Testing : It is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level.
- Recovery Testing : Testing aimed at verifying the system's ability to recover from varying degrees of failure.
- Volume Testing : Huge amount of data is processed through the application in order to check the extreme limitations of the system.
- Usability Testing : This testing is done if User Interface of the application stands an important consideration and needs to be specific for the specific type of user.

User is not required.

- Alpha Testing : Testing of a software product or system conducted at the developer's site by the end user.
- Beta Testing : The pre-testing of hardware or software products with selected typical customers to discover inadequate features or possible product enhancements before it is released to the general public. Testing of a rerelease of a software product conducted by customers.
- User Acceptance Testing : The end users who will be using the applications test the application before ‘accepting’ the application. This type of testing gives the end users the confidence that the application being delivered to them meets their requirements.