Software engineering practice — software testing

This is the fourth day of my participation in Gwen Challenge

After the completion of a system software, and before it goes online, it needs to go through constant software testing, find out bugs and errors, and constantly repair before it can be officially launched. In the following article, we will cover some of the basics of software testing, test case design and software testing steps.

So let’s go ahead and explain.

A software testing overview

1. Purpose of software testing

(1) From a user and developer perspective

There are two very different purposes of testing based on different positions:

• From the user’s point of view, it is generally expected to expose hidden errors and defects in software through software testing to consider whether the product is acceptable.

• From the perspective of software developers, it is hoped that testing shows that there is no error process in software products, verifies that the software has correctly realized the requirements of users, and builds people’s confidence in software quality.

(2) Myers software testing purpose

• Testing is the execution of the program, the purpose is to find errors;

• A good test case is one that finds errors that have yet to be discovered;

• A successful test is one that finds errors that have yet to be discovered.

To sum up, the purpose of testing is to systematically find out potential errors and defects in software with the least amount of time and manpower. If we test successfully, we will be able to find errors in the software. A side benefit of testing is that it can demonstrate that the functionality and performance of the software conform to the requirements specification. The data collected from the test results provide the basis for reliability analysis.

2. Principles of software testing

• “Test software early and constantly” should be the motto of software developers.
• A test case should consist of two parts: test input data and corresponding expected output results.
• Programmers should avoid checking their own programs.
• When designing test cases, reasonable and unreasonable input conditions should be included.
• Be aware of clustering in tests. Experience shows that the number of errors that remain in a program after testing is proportional to the number of errors found in that program.
• Strictly follow the test plan and eliminate the randomness of testing.
• Every test result should be thoroughly checked.
• Properly store test plans, test cases, error statistics, and final analysis reports for maintenance.

3. Object of software testing

Software testing is not the same as program testing. Software testing should take place throughout the software definition and development period.

Requirements specifications, outline design specifications, detailed design specifications, and source programs should all be the object of software testing.

Simply put, programs, data, and documentation should all be tested.

Test the flow of information

Steps to test information:

• Software configuration (object) : software requirement specification, software design specification, source code, etc.
• Test configuration (method) : test plan, test case, test procedure, etc.
• Test tools: automatic test data generation program, static analysis program, dynamic analysis program, test results analysis program, and test database driving test, etc.
• Analysis of test results: compare measured results with expected results and evaluate whether errors occur.
• Troubleshooting (debugging) : To locate and determine the nature of errors that have been found, and to correct the errors, and to modify the relevant documentation.
• Retest the corrected document until it passes the test.

Conclusion:

By collecting and analyzing test data, the reliability model of software is established.

Use reliability analysis to evaluate software quality.

If the tests don’t find bugs, you can be sure that the test configuration wasn’t carefully thought through, and bugs are still lurking in the software.

5. The relationship between testing and software development stages

(1) The software development process is a top-down and step-by-step process, mainly consisting of the following steps:

• The software planning phase defines the software scope.
• Software requirements analysis stage to establish software information domain, functional and performance requirements, constraints, etc.
• Software design.
• To convert a design into program code in a programming language.

(2) The testing process is arranged in reverse order from the bottom up, gradually integrated process.

Software test cases

1. Overview of black box testing

The test object is regarded as a black box, the tester does not consider the logical structure and internal characteristics of the program, only according to the requirements of the specification to check whether the function of the program meets.

Black box testing is also called functional testing or data driven testing.

The black box test method is to test on the program interface, mainly to find the following errors:

• Are there incorrect or missing features?

• Is input accepted correctly on the interface? Can the output be correct?

• Is there a data file access error?

• Does the performance meet the requirements?

To find errors in a program with black-box testing, test data must be determined in all possible input and output conditions to check that the program produces the correct output.

But that’s not going to happen. Why is that?

Suppose a program P has inputs X and Y and outputs Z. Run on a computer with a 32-bit word length. If X and Y are integers, perform exhaustive test according to the black box test method:

Possible test data sets: 232 x 232 = 264.

If it took one millisecond to test a set of data, 365× 24 hours a year, it would take 500 million years to complete all the tests.

500 million years! It’s impossible to even think about. Therefore, there is generally no way for programs to introduce exhaustive tests.

2. Overview of white box testing

Think of the test object as a transparent box that allows testers to design test cases using the logic structure inside the program and test all logical paths of the program.

Determine whether the actual state is consistent with the expected state by examining the state of the program at different points.

Therefore, white box testing is also called structural testing or logic-driven testing.

White box test method, mainly on the program module to make the following checks:

• Test all independent execution paths of program modules at least once;
• All logical decisions should be tested at least once for both “true” and “false” cases;
• Execute the body of a loop within its bounds and run bounds;
• Test the effectiveness of internal data structures, and so on.

For a program with multiple selections and nested loops, the number of different paths can be astronomical. Give a flow chart of a small program that consists of a loop that executes 20 times.

It contains 520 different execution paths, and it takes 1 millisecond to test each path. Assuming 365 × 24 hours a year, it would take 3170 years to test all paths.

Compared with 500 million years in the exhaustive test, 3,170 years seems a lot less. But? The year 3170 isn’t going to be too long.

Therefore, we will introduce some black and white box testing methods to solve these problems.

3. White box test method

White box test methods mainly include the following six methods:

• Statement coverage
• Determine coverage
• Condition covering
• Decision – Conditional overlay
• Conditional combination coverage
• Path coverage

White box test method here is longer, put in another article, there is a need for partners ~

4. Conditional test path selection

When there is more than one decision condition in the program, the branch structure formed can be divided into two types: nested branch structure and chain branch structure.

For nested branch structure, if there are n decision statements, n+1 test cases are needed.

For chained branches, if there are n decision statements, there need to be 2n test cases covering its 2n paths.

As shown below:

5. Cycle test path selection

There are four different types of loops: simple loops, chained loops, nested loops, and unstructured loops. As shown below:

Each of the four loops is described next.

(1) Simple loop

Zero circulation: from the circulation entrance to the exit.

② One cycle: check the initial value of the cycle.

③ Secondary circulation: check multiple circulation.

④ M cycles: check in multiple cycles.

⑤ Maximum number of cycles: more than the maximum number of cycles, less.

(2) Nested loops

① Do all the tests for the innermost loop. The loop variables for all other layers are set to the minimum.

Step by step extrapolation, test the outer layer of the cycle. Keep the loop variables for all outer loops at minimum and the loop variables for all other nested inner loops at “typical” values when testing.

Repeat until all layers of the cycle test is completed.

④ Take the minimum cycle times or the maximum cycle times for all layers at the same time.

(3) Chain cycle

If the loops are independent of each other, they can be tested in the same way as simple loops. But if several loops are not independent of each other, you need to test nested loops.

(4) Unstructured circulation

This type of loop should redesign the test cases using a structured programming approach.

6. Basic path test

The basic path test method has also been put into the white box test method article, you need to help yourself ~

7. Test case design of black box test

Black box test methods mainly include the following 8 methods:

• Equivalence class partition method
• Boundary value analysis
• Error conjecture
• Causality diagram method
• Decision table drive method
• Orthogonal experimental design method
• Scenario method
• Functional diagram method

The black box test method is long and has been put in another article. If you need it, please refer to it by yourself

Three, software testing steps

The testing process needs to follow four steps, namely unit test (module), assembly test (integration), validation test and system test. The detailed process is as follows:

• The first is unit testing, focusing on the use of source code implementation of each program unit to test, check whether each program module correctly implemented the specified function.
• Assembly testing assembles tested modules to test the construction of software architecture related to design.
• Validation tests check that the implemented software meets the requirements identified in the requirements specifications and that the software configuration is complete and correct.
• System testing has been confirmed software into the actual operating environment, and other system components combined for testing.

The following sections explain each of the four testing steps.

1. Unit testing

(1) The definition of unit tests

Unit test, also known as module test, is the test of correctness check for the smallest unit of software design — program module. Its purpose is to find all kinds of errors that may exist in each module.

Unit testing requires the design of test cases from the internal structure of the program. Multiple modules can be unit tested independently in parallel.

(2) Content of unit test

In unit test, testers need to understand the I/O conditions and logical structure of the module according to the detailed design specification and source program list, and mainly use the test cases of white box test, supplemented by the test cases of black box test, so that it can identify and respond to any reasonable input and unreasonable input.

As shown below:

Here are the five tests.

1) Module interface test

At the beginning of unit testing, you should test the data flow that passes through the module under test. The test items include:

• Whether the input parameters of calling this module are correct;
• Whether the parameters input to the submodule when the module calls the submodule are correct;
• Whether the definition of global quantity is consistent across modules;

Consider:

• File attributes are correct;

• Whether OPEN and CLOSE statements are correct;

• Whether buffer capacity matches record length;

• Whether files are opened before reading or writing;

• Whether the file is closed at the end of file processing;

• Text writing/typing error,

• I/O errors are checked and handled.

2) Local data structure test

• Incorrect or inconsistent data type descriptions;
• Use variables that have not been assigned or initialized;
• Wrong initial value or wrong default value;
• Variable names misspelled or miswritten;
• Inconsistent data types;
• The impact of global data on modules.

3) Path test

• Select appropriate test cases to test the important execution paths in the module;
• Test cases should be designed to find errors due to incorrect calculations, incorrect comparisons, or abnormal control flow;
• Testing basic execution paths and loops reveals a large number of path errors.

4) Error handling tests

• Whether the description of the error is difficult to understand;
• Whether the description of the error can be located with the specific error;
• Whether the error displayed matches the actual error;
• Whether the error condition is handled correctly;
• Whether the error condition has caused the system to intervene before handling the error.

5) Boundary testing

• Pay attention to the possibility of error when the data flow or control flow is exactly equal to, greater than or less than the specified comparison value;
• Carefully select test cases for these areas and test them carefully;
• If there is a requirement for module uptime, you should also conduct critical path tests specifically to determine the factors that affect module uptime in the worst and normal cases.

(3) Steps of unit testing

Module is not an independent program, therefore, when considering the test module, we should consider its connection with the outside world at the same time, and use some auxiliary modules to simulate other modules connected with the tested module. Among them, auxiliary modules include:

• Driver module;
• Stub module — stub module.

According to the driving module and pile module, the steps of unit test are as follows:

If a module performs multiple functions, think of the module as consisting of several small programs. Each of these small programs must be unit tested first and performance tested for key modules.

For procedures that support certain standards, interconnect testing should be undertaken. Some people refer to this situation specifically as module testing to distinguish it from unit testing.

2. Assembly test

(1) What does the assembly test

Assembly testing, also known as integration testing or joint testing.

(2) Problems to be considered in assembly test

Usually, on the basis of unit testing, all modules need to be assembled into the system as designed. Here are some questions to consider:

• Whether data passing through module interfaces is lost when connecting modules;

• Whether the function of one module adversely affects the function of another module;

• The combination of each sub-function, whether to achieve the expected requirements of the parent function;

• Whether there is a problem with the global data structure;

• Whether the errors of a single module will be magnified when they accumulate to an unacceptable degree.

• At the same time of unit test, assembly test can be carried out to find and eliminate the possible problems in module connection, and finally constitute the required software system.

• Subsystem assembly testing, specifically called component testing, seeks to find inconsistencies between the assembled subsystem and system requirements specifications.

• In general, modules can be assembled into systems in one of two ways:

  • Single-use assembly
  • Proliferation assembly mode

3. Confirm tests

(1) What is the confirmation test

Validation testing is also called validity testing.

The task is to verify whether the function and performance of the software and other features are consistent with user requirements.

The functional and performance requirements of the software are clearly specified in the software requirements specification.

The information it contains is the basis for software validation testing.

As shown below:

(2) Confirm the test steps

• Conduct effectiveness testing (black box testing);
• Software configuration review;
• Alpha.Testing andBeta.Test;
• The acceptance test(Acceptance Testing) 。

4. System test

(1) What is system testing

The software that passes validation tests, as an element of the overall computer-based system, is combined with other system elements such as computer hardware, peripherals, some supporting software, data, and personnel

In the actual operating environment, a series of assembly tests and validation tests are carried out on the computer system.

Write at the end

🙋 🙋 🙋

In software engineering practice, software testing is also a step. However, compared with the software testing system, software testing accounts for a small proportion in software engineering. I think it is enough to master some basic contents. If you need to learn more about software testing, you can also go to the “Software Testing” column

This is the end of software testing in software engineering practice. If you need to know more about software engineering, you can go to the “Software Engineering” section to view and learn ~

At the same time, do not understand or wrong place also welcome to comment section comments or private letter I exchange ~

• Concern about the public number Monday laboratory, do not regularly share learning dry goods, learning on the way not lost ~
• If this article is useful to you, be sure to like it and follow it