SOFTWARE TEST CASE
In the software development and release cycle, testing and functional verification play a decisive role:
this is when every function is checked against business requirements.
Data-Ware verifies its own applications and those of its customers, preparing structured test plans
and, where possible, automating them to ensure quality and reliability before release.
TESTS
Types. Cases.
Test steps can be divided into two large macro areas: single unit tests or integrated functions and tests.
Testing of individual units and functions
At this stage, the project is realized as a set of programs (modules) in the chosen programming language.
Unit testing is used to verify that each module meets the required specifications.
The security functions involved at this stage are:
• Code Analysis and Testing - Before issuing new development code parts, testing is performed to identify
buffer overflow, sql code injection, etc ...
• Metrics and post mortem - keep track of the security issues identified during the tests.
For each vulnerability, you must keep track of the vulnerabilities in a bug database.
The bug database will also populate all security vulnerabilities not yet resolved.
Integrated tests
At this stage, you integrate the individual units together and run the complete system texts to make sure the specifications are met.
The safety tests involved at this stage can be identified in five macro activities:
1. Network Mapping
2. Vulnerability analysis using automatic tools
3. Penetration Testing
4. Password Cracking
5. Log auditing
Test case. Conditions.
A test case is a set of conditions through which the tester determines whether the application meets the requirements or not.
It is defined by three entities:
- input elements
- path
- result (output elements)
Normally, each application should have a set of test cases for all application scenarios that may occur, including errors.
In case of performance testing, it is not necessary to use all the application case tests, as there is no question of application functionality,
but its resistance.
Then we will have to select test cases that have meaningful use (at least over 5%), and those where resource consumption is heavier.
For example, if we have a web application, we could override the administrative or user customization part to test more
common functions, such as login / logout, search in the catalog, payment, cart management, etc.
For each test case we will associate a weight (usage), which will serve to define the workload during test sessions.
