Basic software testing methods

 

 

Dynamic black box testing

 

Software testing methods that do not go deep into code details. It is often called behavior testing because it tests the actual behavior of the software during use.

 

First, obtain the software input and expected output of the test object from the product manual.

Next, define the test case. Test Case: The input for testing and the Program for testing the software.

Selecting test cases is the most important task for Software testers. Incorrect selection may result in too much or too small testing capacity, or even incorrect testing objectives. It is a success to accurately assess risks and reduce the possibility of not being too short to be controlled.

 

Test method: pass test vs failure test

 

Pass testing: confirm what the software can do without testing its capabilities.

Failed test: A test case designed and executed purely to damage the software, also known as an error-forcing test. Deliberately attack the weak links of software.

When designing and executing test cases, always pass the test first. It is important to check whether the basic functions of the software are implemented before destructive testing. Otherwise, when the software is used normally, it may wonder why there are so many Software defects.

A common test case is to force the software to receive error messages. The product specification may provide such functional requirements. The test for this problem may pass the test or fail the test. Both of them are possible. You don't have to differentiate them. What's important is to find Software defects!

 

Select Test Case: equivalent allocation

 

Equivalent allocation: it refers to the process of reducing too many (unlimited) test cases to a small range that is equally effective. It is also called equivalent division.

The equivalence assignment technique provides a system method for selecting and dropping values.

Equivalence classes or equivalence zones refer to a set of test cases that test the same purpose or expose the same software defects. When looking for equivalence zones, you can divide similar input, output, and operations of the software into groups. These groups are equivalent areas.

The purpose of the equivalent allocation is to reduce the possible test case combinations to the control scope that is still sufficient to test the software. Because incomplete tests are selected, a certain risk is required. If the equivalent allocation is performed to reduce the number of test cases, the risk of testing increases. In addition, there is no standard for division between equivalence zones, as long as it is sufficient to cover the test object.

 

Data Testing

 

Software consists of two basic elements: data (including keyboard input, mouse click, disk file, print output, and so on) and Program (executable process, conversion, logic, and operation.

If you perform software testing on the data, you must check whether the user input information, returned results, and intermediate calculation results are correct. The equivalence distribution is mainly carried out based on the following principles to reasonably reduce test cases: boundary conditions, subboundary conditions, and invalid data.

 

1. boundary condition test

 

The program is correct when processing a large number of intermediate values, but an error may occur at the boundary. For example, the processing of the [0] element of the array. To define an array of 10 elements in basic, if Dim data (10) as integer is used, an array of 11 elements is defined, use for I = 1 to 10 again when assigning initial values... to assign a value, it will generate permissions, because the program forgets to process the 0 element of I = 0.

Boundary Condition refers to the edge condition of the Operation boundary of the software plan.

 

Data Type: Numeric value, character, position, quantity, speed, address, size, etc., all contain definite boundary.

Features to be considered: first/last, start/finish, empty/full, slowest/fastest, adjacent/farthest, minimum/maximum, exceeds/, shortest/longest, earliest/latest, highest/ minimum. These are possible boundary conditions.

Select the data contained in the equivalent allocation based on the boundary. However, data points on the test boundary line are often insufficient. When a boundary condition is proposed, it is necessary to test the legal data near the boundary, that is, to test the last legal data and the illegal data that has just exceeded the boundary. The following example illustrates how to consider all possible boundaries:

 

--------------------------------------------------------------------------------

If the text input field can contain 1-characters.

Try: Enter 1 character and 255 characters (valid range), or add 254 characters as valid test.

Enter 0 characters and 256 characters as invalid intervals.

 

--------------------------------------------------------------------------------

 

If the program reads/writes a floppy disk

Try: Save a file of extremely small size, or even only one item.

Then save a large file that is within the capacity limit of the floppy disk.

Save the empty file.

Save files larger than the disk capacity.

 

--------------------------------------------------------------------------------

 

If the program allows printing multiple pages on one piece of paper

Try: print only one page

Print the maximum allowed pages

Print 0 pages

More than allowed pages (if possible)

 

--------------------------------------------------------------------------------

 

--------------------------------------------------------------------------------

 

2. border condition tests

 

The above is a general boundary condition which is defined in the product manual or determined during the software process. However, some boundaries are within the software, and end users can hardly see them. However, software tests still need to be checked. Such boundary conditions become subboundary conditions or internal boundary conditions. Looking for such boundary conditions does not require software testers to become programmers or have the ability to read source code, but does require a general understanding of how the software works. The multiplication and ASCII tables of 2 are as follows:

 

--------------------------------------------------------------------------------

Multiplication of 2

Terms

Range or value

 

Bit

0 or 1

 

Double-bit doublebit

0 ~ 15

 

Byte

0 ~ 255

 

Word

0 ~ 65,535 or 0 ~ 4,294,967,295

 

K

1,024

 

MB

1,048,576

 

Billion

1,073,741,824

 

Trillion

1,099,511,627,776

 

Computers and software are based on binary numbers. Therefore, the multiplication of two is an important data used as a boundary condition. For example, in communication software, the bandwidth or ability to transmit information is always limited, so software engineers will do everything they can to compress more data in communication strings. One of the methods is to compress the information into the smallest possible unit, send the most commonly used information of these small units, and expand to larger units if necessary. Assume a communication protocol supports 256 commands. The software will send the most commonly used 15 commands encoded as a dual-bit data; If the command between 16th and 256 is used, the software will send the command encoded as a longer byte. In this way, the software will perform specialized computing and different operations based on the dual/byte boundary.

When establishing an equivalence zone, consider whether to include the multiplication Boundary Condition of 2. For example, the software accepts 1 ~ For numbers in the range of 1000, the valid range is not only 1 and 1000, but also 2 and 999. There should also be multiplication boundaries near 2: 254,255, 16, 256, and.

 

--------------------------------------------------------------------------------

 

ASCII table

 

The ASCII code table is not a continuous table with good structure. Number 0 ~ 9 corresponds to 48 ~ 57; slash (/) before 0, colon (after 9; uppercase letter ~ Z corresponds to 65 ~ 90; 97-90 for lowercase letters ~ 122. These conditions all represent the subboundary conditions.

If you test the software for text input or text conversion, it is wise to refer to the ASCII table when defining the values contained in the data range. For example, the text box for testing only accepts characters ~ Z and ~ Z, it should include the values before and after the characters in the ASCII table in the illegal range --@,',[,{.

 

--------------------------------------------------------------------------------

 

--------------------------------------------------------------------------------

 

3. Default Value Test (default value, Blank Value, null value, zero value, and none)

 

A good software can handle this situation. A common method is to set the input content to the minimum value within a valid boundary by default, or a reasonable value within a valid range, and an error message is returned.

These values usually need special processing in the software. Therefore, separate equivalence zones should be established. By default, if the user inputs 0 or-1 as an invalid value, different software processing processes can be executed.

 

--------------------------------------------------------------------------------

 

4. Damage testing (illegal, incorrect, incorrect, and junk data)

 

This type of data test is the object of the failed test. There are no actual rules for such tests, but they try to destroy the software. Do not act as required by the Software. Please make full use of your creativity!

 

--------------------------------------------------------------------------------

 

Status Test

 

A status test is a logical process that passes different status verification procedures. The software Tester must test the software status and its transition. The software status refers to the current situation or mode of the software. The software enters a process branch through code, triggers some data bits, sets some variables, reads some variables, and transfers them to a new state.

Like Data Testing, status testing uses the equivalent allocation technology to select the status and branch. Because the selection is not completely tested, it is necessary to bear certain risks, but reduce the risks through reasonable selection.

 

1. Create a status transition diagram

 

Use: box and arrow; Circle (bubble) and arrow.

Items to be included:

-Each independent state that the software may enter.

If it cannot be determined whether it is independent, first think it is; if it is not found later, remove it at any time.

-Input and conditions required for transferring from one status to another.

The reasons for status changes and existence are the objects we are looking.

-Set conditions and output results when entering or exiting a certain state.

Including displayed menus and buttons, set flags, printed output, and executed operations.

As it is a black box test, you only need to create a state chart from the user's perspective.

 

2. Reduce the status to be tested and the number of conversions

 

It is impossible to test the combination of each route and travel all branches. A large number of possibilities also need to be reduced to a set of operable test cases. There are 5 methods:

-Each status can be accessed at least once.

No matter what method is used, each status must be tested.

-Test the most common and common state transition

-The least frequently used Branch between test states.

These branches are most easily overlooked by product designers and programmers.

-Test the return values of all machines with errors.

Whether the error is correctly handled, whether the error prompt information is correct, and whether the software is correctly restored when the error is fixed.

-Test random state conversion.

 

3. perform specific tests-Define test cases

 

Test status and its conversion include checking all state variables-static conditions, information, values, and functions related to the entry and exit states. For example: Window appearance, window size definition (fixed/last used size), displayed menu, default value, document name, etc. The status must be determined whether it is visible or not. Status variables may not be visible, but they are very important. In a common example, mark the document (to determine whether to ask for saving when exiting ).

 

Failed status test

 

The failure test cases of status testing mainly include competition conditions, repetition, oppression, and burden.

 

1. competition conditions and time series disorder

 

Designing a multi-task operating system is not difficult. Designing a software that makes full use of the multi-task capability is an arduous task. In a real multi-task environment, software design cannot be taken for granted. It must be able to run together with any other software in the system when it is interrupted at any time, it also shares memory, disks, communication devices, and other hardware resources.

As a result, the competition conditions may occur. Unexpected interruptions of the software will lead to disordered timing.

It is difficult to design a race condition test. First, you should carefully check each status in the status transition diagram to find out which external effects will interrupt the status. Consider what the status will be if data is not ready or changes when it is used. How are several arcs or straight lines connected at the same time.

 

The following is a typical scenario that requires competition:

-Two different programs save or open the same document at the same time.

-Share the same printer, communication port, or other peripheral devices.

-When the software is in the read or modify status, press the key or click the mouse.

-Close or start multiple instances of the software at the same time.

-Use a common database with different program orientations at the same time.

 

2. repetition, oppression, and burden

 

The purpose of these three tests is to be able to deal with problems that may arise under harsh conditions that even programmers did not think.

 

-Repeated tests

 

Repeated tests are performed continuously. The simplest thing is to start and close the program constantly, read and write data repeatedly, or select the same operation. The main purpose of this test is to check whether the memory is insufficient. If the memory is allocated for an operation but the operation is not completely released, a common software problem occurs.

 

-Compression Test

 

Stress Testing enables the software to run under unsatisfactory conditions, such as small memory, less disk space, slow CPU speed, and low modem rate. Observe the requirements and dependencies of software on external resources. Stress testing is to minimize support, with the aim of limiting the necessary software conditions as much as possible.

 

-Load Test

 

Stress testing is the opposite of stress testing. Stress testing is to restrict software as much as possible, while stress testing is to provide conditions as much as possible. Allow software to process as large data files as possible. The ability to discover software to the maximum extent overwhelmed it. For example, when the software operates on the printer or communication port, it connects all the connected devices. The server can process thousands of analog connections, as he said.

Don't forget, time is also a heavy test.

 

Repeated, compressed, and overwhelmed tests should be used together and carried out simultaneously.

 

Note that:

I. project administrators and group programmers may not fully accept the software tester's practice of breaking the software. However, the task of the software tester is to ensure that the software works normally under such harsh conditions, otherwise the Software defects will be reported. How to report Software defects in the best way, so that they can be taken seriously and repaired is also a learning.

2. Numerous repeated connections and thousands of connections are impossible for manual operations. Therefore, we need to use automated testing tools.

 

Other black box testing methods

 

1. Do it like inexperienced users

 

Enter unexpected data, change your mind in the middle, and return to execute other operations. Click something that should not be clicked ......

 

2. Search for Software defects.

 

There are two reasons: first, the centralization of Software defects. If a large number of Software defects with upper boundary conditions are found in different features, the upper boundary conditions should be emphasized for all features. Some cases should be put into consideration for a defect to ensure that this problem is not universal. Second, programmers tend to modify only the reported Software defects. For example, if the report is "start-stop-Restart" for 255 times, resulting in a conflict, the programmer may only fix this problem. During the retest, you must re-execute the same test for more than 256 times.

 

3. Experience, intuition, and Precognition

 

Record which technologies are effective and which ones are not. Try different ways. If you think there is something suspicious, you should carefully explore it. Follow the hunch until it is confirmed that this is an error.

Experience is the title of wrong behaviors.