{"id":3169,"date":"2022-02-21T16:37:45","date_gmt":"2022-02-21T15:37:45","guid":{"rendered":"https:\/\/www.sipsa.net\/?p=3169"},"modified":"2022-02-21T16:45:08","modified_gmt":"2022-02-21T15:45:08","slug":"levels-of-software-testing","status":"publish","type":"post","link":"https:\/\/www.sipsa.net\/en\/levels-of-software-testing\/","title":{"rendered":"Levels of Software Testing."},"content":{"rendered":"

\n<\/div>

<\/div><\/div><\/div><\/div><\/div>

In the last article we talked about the V-Model, as one of the SQA (software quality assurance) standards used to describe testing activities as part of the software development process<\/strong>. Today we are going to take a closer look at the testing activities described in this model, divided into levels.<\/span>\u00a0<\/span><\/p>\n

Each of them is related to a specific software development phase, as you can see in this picture:<\/span>\u00a0<\/span><\/p>\n

\"V-Model<\/p>\n

There are two main approaches<\/strong> to test case design:<\/span>\u00a0<\/span><\/p>\n

– Structural or white box<\/strong>. The internal structure of the component is verified independently of the functionality established for it.\u00a0<\/span>\u00a0<\/span><\/p>\n

Therefore, results are not tested for correctness if they occur. Examples of this type of tests can be executing all the instructions of the program, locating unused code, checking the logical paths of the program, etc.<\/span>\u00a0<\/span><\/p>\n

– Functional or black box<\/strong>. <\/span>These test that the components that make up the information system are\u00a0 functioning correctly,<\/span> by<\/span> analysing the inputs and outputs and verifying that the result is as expected. The inputs and outputs of the system are considered exclusively without concern for the internal structure of the system.<\/span>\u00a0<\/span><\/p>\n

The approach usually adopted for unit testing, the first testing phase set out in the V-Model, is clearly oriented towards the design of white box cases, although it is complemented by black box <\/span>testing.<\/span><\/p>\n

1.Unit Testing.<\/span><\/b><\/h2>\n

We start with unit testing.<\/span>\u00a0<\/span><\/p>\n

Unit tests are usually performed by programmers, whereby individual units of source code are tested to determine their suitability for use.\u00a0<\/span>\u00a0<\/span><\/p>\n

These tests verify that the smaller components of the program work correctly<\/strong>. <\/span><\/p>\n

Depending on the programming language, a component can be a module, a unit, or a class.<\/span>\u00a0<\/span><\/p>\n

Depending on t<\/span>he component type<\/span>, the tests will be called module tests, unit tests or class tests<\/strong>.<\/span>\u00a0<\/span><\/p>\n

Component tests check the output of the component after providing an input based on the component specification.<\/span>\u00a0<\/span><\/p>\n

The main characteristic of component testing is that individual components are tested in isolation and without interacting with other components. As no other components are involved, it is much easier to locate defects.<\/span>\u00a0<\/span><\/p>\n

Usually, the implementation of the tests is done with the help of a testing framework, e.g. JUnit, CPPUnit or PyUnit, to name a few popular unit testing frameworks.<\/span>\u00a0<\/span><\/p>\n

In addition to functional testing, component testing can address non-functional aspects such as efficiency (e.g. storage consumption) and maintainability (e.g. code complexity).<\/span>\u00a0<\/span><\/p>\n

Unit testing aims at verifying the functionality and structure of each individual component once it has been coded<\/strong>.<\/span>\u00a0<\/span><\/p>\n

Necessary steps to performing<\/strong> unit tests<\/strong>:<\/span>\u00a0<\/span><\/p>\n

– Execute all test cases associated with each verification set out in the test plan, recording their result. The test cases must contemplate both valid and expected conditions as well as invalid and unexpected ones.<\/span>\u00a0<\/span><\/p>\n

– Correct the errors or defects found and repeat the tests that detected them. If deemed necessary, due to their implication or importance, other test cases already performed previously shall be repeated.<\/span>\u00a0<\/span><\/p>\n

The unit test is terminated when all established checks have been performed and no defects are found, or when it is determined that the unit test is discontinued.<\/span><\/p>\n

2.<\/span>Integration Testing.\u00a0<\/span><\/b><\/h2>\n

After completing the unit tests, the integration tests are carried out.<\/span>\u00a0<\/span><\/p>\n

The objective of integration testing is to verify the correct assembly between the different components<\/strong> <\/span>once unit tests have been\"\"<\/a> carried out,<\/span> check that they interact correctly<\/strong> through their interfaces, both internal and external, cover the established functionality and conform to the non-functional requirements specified in the corresponding verifications.<\/span>\u00a0<\/span><\/p>\n

Testing may cover only two specific components, groups of components or even independent subsystems of a software system. Integration testing is usually performed after the components have been tested in the lower component testing phase.<\/span>\u00a0<\/span><\/p>\n

The development of integration tests can be based on the functional specification, system architecture, use cases or workflow descriptions. Integration testing focuses on component interfaces (or subsystem interfaces) and attempts to reveal defects that are triggered through their interaction and that would otherwise not be triggered by testing isolated components.<\/span>\u00a0<\/span><\/p>\n

Integration testing can also focus on the interfaces to the application environment, such as external software or hardware systems. This is often referred to as system integration testing<\/strong>, in contrast to component integration testing<\/strong>.<\/span>\u00a0<\/span><\/p>\n

Integration testing examines the interfaces between groups of components or subsystems to ensure that they are called when necessary and that the data or messages being transmitted are as <\/span>specified<\/span>.<\/span>\u00a0<\/span><\/p>\n

Unit testing is often combined with integration testing, as unit testing requires the creation of auxiliary modules to simulate the actions of the components invoked by the component under test, and the creation of components to establish the necessary preconditions, to call the component under test and examine the test results.<\/span>\u00a0<\/span><\/p>\n

The main types of integration are<\/strong>:<\/span>\u00a0<\/span><\/h3>\n