Basic Concepts and Methods of software testing

The main reason why software testing methods fail to be fully standardized and unified is that there are various types of software from software industry products to software testing. However, there are still many common software testing methods available. The idea and method we will introduce here is that it can be used for testing most applications. There are six basic concepts related to software testing methods that are important: white box testing, black box testing, gray box testing, valid and invalid cases, boundary conditions and equivalence tests.
White box testing or white box testing (white-box testing or glass-box testing) is a test through the source code of the program without using the user interface. This type of test requires you to detect defects or errors of internal code in algorithms, overflow, paths, conditions, and so on from the code syntax, and then correct them.
Black-box testing or black-box testing is performed strictly by using the entire software or some software function, without checking the source code of the program, or knowing how the source code program of the software or a software function is designed clearly. Testers can understand how the software works by entering their data and then looking at the output results. Generally, when testing, the tester not only uses input data that must produce correct results, it also uses challenging input data and input data that may result in errors to understand how the software processes various types of data.
Gray-box test or gray-box testing: the gray-box test is like a black-box test, however, testers have already understood how the source code program of the software or a software function is designed. I even read some of the source code. Therefore, testers can test certain conditions/functions in a targeted manner. The significance of this is: if you know the internal design of the product and have an in-depth understanding of the product through the user interface, you can test its performance more effectively and deeply from the user interface.
A valid case (valid case) or a valid input case is a test case that can be correctly handled by known software programs. Generally, it refers to the test case of software input. For example, in Microsoft Excel, enter "= 1 + 1" on the keyboard and the result is "2 ". The valid use case entered here is "= 1 + 1 ". Invalid use cases (invalid input use cases) or error Use Cases: test cases that are known to be not supported by the software program. For example, in Microsoft Excel, enter "= a + 1" on the keyboard and the result is "# name ?". The "= a + 1" entered here is both an invalid use case and an error use case.
Boundary cases: A test of the surrounding boundary value. It usually means the maximum value, the minimum value, or the longest string that the design software can process. For example, the font size of a software font can range from 8 to 72. Then, the test cases should include: less than 8, equal to 8, equal to 72, and greater than 72.
Equivalent Classes: an equivalent test case indicates that if many test cases are executed, no new defects will be found. Although the input and output results are different, they all use the source code path of the same software. Generally, as long as the path of a source code program is used to process all values within a certain value range, all values within the boundary value range, except the boundary value, generally belong to the equivalence class. Because if the software program can correctly process a value, it means that the program can correctly process any valid input value except the boundary value within this range. Let's use the font size of the above software font for example. The font size range supported by the software is from 8 to 72. All supported font sizes between 8 and 72 can be considered as test cases of equivalence classes. Another example is the two use case http://www.yahoo.com/and http://www.yahoo2.com/is also the test case of the equivalence class when the hyperlink is tested.
?

Basic software testing methods

Software testing methods may be categorized into different categories in different books, different methods of calling and different interpretations. For example, from the tester's point of view, it can be divided into manual testing and automatic testing. Source code can be divided into unit test and function test. From the theoretical definition, it can be divided into black box test, white box test and gray box test. The basic software testing methods to be discussed here mainly focus on the black box testing methods of software functions: functional testing (functionality test), acceptability testing (Acceptance Test), user interface (user interface or UI) testing: Ad hoc generally refers to 'exploratory or open' testing, boundary condition testing, performance testing, and regression testing ), stress test, configuration and Setup test, comparability test, International sufficiency, and localization ).
Function Test: verify whether the software function can be properly tested according to its design. Check whether the expected behaviors of running software comply with the original design. For example, to test the Microsoft Excel insert-> symbol function, including the ability to correctly insert and display the correct symbol in the cells selected by Microsoft Excel? Can the symbols in different fonts be correctly displayed?
Acceptability test: A simple test of the most basic functions performed before the test version is delivered to the test department for a wide range of tests. Because before you deliver the tested version to the testing department for a wide range of tests, you should first verify that the version is basically stable for the tested functions. Some minimum requirements must be met. For example, the program will not be easily suspended or crashed. If a new version does not pass the testability verification, the test department should be blocked from taking the time to test the test version. At the same time, we also need to find the major defects that cause instability of the version and urge them to fix them as soon as possible.
User Interface Test: analyze whether the design of the software user interface meets user expectations or requirements. It usually includes tests on menus, buttons, text, error prompts, and help information (menu and help content) in the dialog box. For example, you can test the dialog box size used to insert symbols in Microsoft Excel, whether all buttons are aligned, the font size of the string, the error message content and font size, and the toolbar position/icon.
'Exploratory or open' testing: it is not a step-by-step test case based on one formal test case, nor is it limited to the specific steps of the test case. In this test, the tester uses the flexible and diverse imagination and creativity to simulate the user's needs to use the various functions of the software. This software usually involves many test cases or more complex steps.
Border condition test: it is a test of the surrounding boundary value. It usually means testing whether the software functions can correctly process the maximum value, the minimum value, or the longest string that the design software can process.
Performance testing is generally used to verify that the performance of the software can meet performance indicators in normal and system conditions. Or the new version is no slower than the old version when the same task is executed. It also checks whether the system memory capacity will be lost (Memory Leak) when running the program ). For example, the verification program saves a large new version of the file, which is no slower than the old version.
Regression testing: Re-tests based on fixed defects. The purpose is to verify that previously encountered but fixed defects do not reappear. It generally refers to re-testing a known corrected Defect Based on its original steps. It is usually difficult to determine the scope of the required retest, especially when the product release date is approaching. Because the source code must be changed to correct a defect, it may affect the functions controlled by the source code. Therefore, when verifying repaired defects, you must not only follow the steps for re-testing when the defects originally occurred, but also test all functions that may be affected. Therefore, automation of all regression test cases should be encouraged.
Strong testing: It usually verifies the performance of the software in various extreme environments and system conditions. Or verify the performance of the software under various extreme environments and system conditions. For example, in the case of the lowest hard drive space or system memory capacity, the validators repeatedly open and save a huge file for 1000 times without crashing or crashing.
Integration and compatibility test: Verify that this function can be coordinated with other programs or components as expected. Compatibility often means coordination between new and old versions, and compatibility between tested products and other products. For example, using a new version of the same product does not affect the operation of saving files, formats, and other data between users of the old version.
Assembly/installation/configuration test: Verify that the software program is deployed on the hardware of different manufacturers and supports the new and old versions of the platform in different languages, and software installed in different ways can run as expected. For example, install Microsoft Office 2003 in English version on Windows ME in Korean and verify that all functions are running properly.
Internationalization Support Testing: verifies that software programs run as expected on platforms in different countries or regions, and that common local dates and fonts can be used to respect and support the original design, text representation, special format, and so on. For example, Can Windows XP and Microsoft Word in English versions display Arabic strings? Can I use Arabic Windows XP and Arabic Microsoft Word to display Arabic strings? For example, does the Microsoft Excel dialog box in the Japanese version display the correct Japanese translation? Once it is said that testers performing international support testing often need to basically understand the language requirements and expected behavior of these countries or regions.
Localized language testing: Verify that all software versions in different languages planned to be released are correctly translated into the local language as expected. Such tests generally include the verification menu, dialog box, error information, help content, and other texts on the user interface, which can display the locally translated text correctly.