Reference no: EM13309917

The goal of testing is to demonstrate that the software satisfies its requirements and to demonstrate with a high degree of confidence that errors, which could lead to unacceptable failure condition, have been removed. The following sections describe three basic areas of testing that apply to testing programs: (1) normal range testing, (2) robustness testing, and (3) stress testing. These categories of test cases should be applied to unit, or class, testing and integration testing, which are described in the following sections. The following figure illustrates four basic categories of testing2:

1. White box, or structural testing, is testing that takes into account the internal mechanism of a component or system. This includes branch testing, path testing, and statement testing. It is important to note that a white box test, may or may not be directly traceable to a user requirement.
2. Black box, or requirements-based testing, is testing that ignores the internal mechanism of a component, or system, and focuses solely on the outputs generated in response to a selected set of inputs and execution conditions. Black box tests are directly traceable to user and derived requirements.
Normal range testing is where you will test the system under nominal operating conditions with nominal inputs to validate that the software performs its intended function. To meet this objective, a series of normal range test cases should be developed to demonstrate the ability of the software to respond to normal inputs and conditions.
• Real and integer input variables should be exercised using valid equivalence classes and boundary values.
• For time-related functions, such as filters, integrators, and delays, multiple iterations of the code should be performed to check the characteristics of the function.
• For state transitions, test cases should be developed to exercise the transitions possible during normal operation.
• For requirements expressed by logic equations, the normal range test cases should verify the variable usage and boolean operators.

Robustness test cases evaluate what happens when the system is outside the normal operational environment (i.e., what happens when something does go wrong). These robustness test cases demonstrate the ability of the software to respond to abnormal inputs and conditions. They should include real and integer variables that are exercised using equivalence class selection of invalid values.

• System initialization should be exercised during abnormal conditions.
• The possible failure modes of the incoming data should be determined, especially complex digital data strings from external systems.
• For loops where the loop count is a computed value, test cases should be developed to attempt to compute out-of-range loop count values.
• A check should be made to ensure that the protection mechanism for exceeded frame times responds correctly.
• For time-related functions, such as filters, integrators, and delays, test cases should be developed for arithmetic overflow protection mechanisms.
For state transitions, test cases should be developed to provide transitions that are not allowed by the software requirements.

The following section will discuss the concept of test case equivalence classes, which will help your team determine an adequate set of test cases.

Attachment:- 353768_1_Test-Plan-Outline-and-guidance.docx

Attachment:- 353768_2_CIS-470-Design-Specification-Template.docx

Attachment:- 353768_3_Data-Dictionary-Team-A.docx

Attachment:- 353768_4_Case-Project--TPS-WebSite.docx