Common Software Testing Methods

With the continuous development of software testing technology, the testing methods are becoming more and more diversified and more targeted. choosing the appropriate software testing method can help us get twice the result with half the effort. The following are some common software testing methods:

βTest_betaTest

Beta testing. The English version is beta testing. Also known as beta testing,User Acceptance Test(UAT ).

Beta testing isTesting by multiple users of the software in the actual use environment of one or more users. Developers are usually not in the test site, and beta testing cannot be performedProgramCompleted by the tester or tester.

Tests are performed when development and testing are complete, and the final errors and problems need to be found before the final release. This testGenerally completed by end users or other personnel, not by programmers or testers.

αTest_alphaTest

Alpha testing. The English version is Alpha testing. Also known as alpha testing.

Alpha testing is a test performed by a user in the development environment. It can also be a controlled test performed by the company's internal users in the simulated actual operating environment. Alpha TestingCannot be completed by programmers or testers of the system.

Test the application system when system development is nearing completion. After the test, there will still be a small number of design changes. Such tests are generally completed by end users or other personnel, and cannot be completed by programmers or testers.

Portability Test

Portability test. The English version is portability testing. Also known as compatibility testing.

Portability testing is to test whether the software can be successfully transplanted to a specified hardware or software platform.

User Interface Test-UITest

User Interface testing. Also known as UI testing.

User Interface. YesVisible appearance in the software and its underlying interaction with users (menus, dialogs, windows, and other controls).

The user interface test is to test whether the style of the user interface meets the customer's requirements, whether the text is correct, whether the page is beautiful, whether the text and image combinations are perfect, and whether the operations are friendly. The purpose of the UI test is to ensure that the user interface provides users with access or browsing functions by testing the image functions. Ensure that the user interface complies with company or industry standards. Including user-friendly, user-friendly, and easy-to-operate tests.

The user interface tests 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.

Smoke test

Smoke test: Smoke Testing.

The name of the smoke test can be understood as this test.Short time consumptionOnly one bag of cigarettes is enough. Some people think that it is similar to the basic function inspection of the new circuit board. After soldering any new circuit board, the system first Performs electrical check. If a design defect exists, the circuit board may be short-circuited, and the Board smoke.

Smoke Testing is intended for every newly compiled software version that needs to be officially tested.Confirm that the basic functions of the software are normal, and perform subsequent formal tests. The implementer of the smoke test is the version compiler.

Random test

Random test. The English version is adhoc testing.

Random tests do not contain written test cases, record expected results, check lists, scripts or instructions. The function and performance of the software are checked based on the tester's experience. Random testing is an important supplementary means to execute test cases according to the test manual.Effective methods and processes to ensure test coverage integrity.

The random test mainly involves a retest of some important functions of the software under test, and also includes the tests that are not covered by the current test case. In addition, software updates and new functions should be tested. Focuses on some special points, special use environments, concurrency, and inspection. In particular, re-testing of major bugs found in previous tests can be performed in conjunction with regressive testing.

Localization test

Localization test. The English version is localization testing.

Localization is to change the language of the software version. For example, if you change windows in English to Chinese, it is localization. The localized test is similar to the localized version of the software. The purpose of the localization test is to test the Software Localization quality set for a specific target region. The environment for localization testing is to install localized software on a localized operating system. The test methods can be divided into basic function testing, installation/uninstall testing, and software and hardware compatibility testing in the local area. The test content mainly includes the interface layout after software localization and the language quality of software translation, including software, documentation and on-line help.

Localization Capability Test

Localizability testing.

Localization capability testing does not require re-design or modification.CodeThe ability to translate the user interface of the program into any target language. To reduce the cost of localization capability testing and improve the testing efficiency, the localization capability side is usually carried out on the pseudo-localization version of the software.

Typical errors found in the localization capability test include hard encoding of characters (that is, the characters to be localized in the software are written inside the code), and fixed values are set for the characters to be localized, when the software is running, it locates at the control position. icons and bitmaps contain the text to be localized, and the user interface of the software is inconsistent with the terminology of the document.

International Testing

International testing. The English version is international testing. Also known as international support testing.

The purpose of internationalization testing is to test the software's internationalization support capability, discover potential problems of software internationalization, and ensure that the software can run normally in different regions of the world. The internationalization test uses each possible international input type and checks whether the product functions are normal for any region or region. The emphasis of the Software Internationalization test is to execute the input/output functions of international strings. International Test Data must contain a mix of East Asian, German, complex script characters, and (optional) English characters.

International support testing is to verify 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.

Installation test

Installation test. The installation test is in English.

Installation testing is to ensure that the software can be installed in normal and abnormal circumstances, such as for the first installation, upgrade, complete or custom installation. Exceptions include insufficient disk space and a lack of Directory Creation permissions. Verify that the software runs properly immediately after installation. Installation testing includes testing the installation code and the installation manual. The installation manual provides how to install and the installation Code provides the basic data that can be run by installing some programs.

White box testing-Structure Test-Logic-Driven Testing

White box test. The English version is white box testing. Also known as structure test or logic-driven test.

The white box test regards the test object as an open box. When using the white box test method for dynamic testing, you need to test the internal structure and processing process of the software product, and do not need to test the functions of the software product.

The coverage standards of the white box test method include logical coverage, cyclic coverage, and basic path testing. Logical overwrites include statement overwrites, decision overwrites, condition overwrites, decision/condition overwrites, condition combination overwrites, and path overwrites.

The white box test is to know the internal working process of the product. It can be tested to check whether the internal actions of the product are normal according to the specifications. The test procedure is based on the internal structure of the program, check whether each path in the program can work correctly according to the predefined requirements, regardless of its function, the main white box testing methods include logic-driven, baseline testing, etc., mainly used for software verification.

Common white box testing tools include jtest, vcsmith, jcontract, C ++ test, CodeWizard, and logiscope.

Black box testing-Function Test-Data-Driven Testing

Black box test. The English version is black box testing. It is also called function test or data-driven test.

Black box testing is a test of the software according to the specifications of the Software. Such tests do not consider the internal operating principle of the software, so the software is like a black box for users.

Software testers discover Software defects from the user's perspective through various inputs and observations of the software's output results, regardless of how the program is implemented.

Common black box testing tools include autorunner, winrunner, and LoadRunner.

Automated Testing

Automated Testing.

Automated testing tools are used for testing. Such tests generally do not require human intervention and are usually used in Gui, performance, and other testing and functional testing. Record the test script and run the script to automate the test process. Zezhong software is a leading provider of automated testing services in China. Automated testing tools include autorunner and tar.

Regression testing

Regression testing. The English version is regression testing.

Regression testing refers to re-testing previous tests after a change to ensure the correctness of the changes. In theory, regression testing is required for Software Generation of new versions to verify whether errors found and fixed previously occur again on the new software version.

Perform the test again based on the repaired defects. The purpose of regression testing is to verify that the defects that have been fixed before 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 it must be changed to correct a defectSource codeThus, the functions controlled by the source code may be affected. 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, automated tests for all regression test cases should be encouraged.

Acceptance Test

Acceptance Test: acceptance testing.

Acceptance testing refers to a stage of the system development lifecycle methodology. At this time, the relevant users or independent testers test and receive the system according to the test plan and results. It allows the System user to decide whether to receive the system. It is a test to determine whether the product meets the contractual or user-defined requirements.

There are generally three acceptance testing strategies: formal acceptance, informal acceptance, Alpha testing, and beta testing.

Dynamic Testing

Dynamic test. The English version is moment testing.

Dynamic Testing is to test the correctness of dynamic behaviors and running results of software by running software.

Based on the stages and functions of dynamic testing in software development, dynamic testing can be divided into the following steps:

1. Unit Test

2. Integration Testing

3. System Testing

4. Acceptance Test

5. regression testing

Exploration Test

Test discovery. The English version is exploratory testing.

Test discovery refers to testing that is commonly used without a product specification. This requires the software to be viewed as a product specification, and the software features should be explored step by step to record the software implementation and describe the features in detail, comprehensive use of static and dynamic technologies for testing. Discovery testers only rely on intelligence, insight, and experience to determine the location of bugs. Therefore, discovery testing is also called free form testing.

Unit Test

Unit test. unit testing is used in English.

Unit testing is a minimal test to test a function or code block. Typically, programmers rather than testers need to know the details of internal program design and coding. This work is not easy to do unless the application system has a well-designed architecture; you may also need to develop test drive modules or test kits.

Integration Test

Integration test. The English language is integration testing.

Integration testing refers to the joint testing of various components of an application system to determine whether they can work together without conflict. Parts can be code blocks, independent applications, clients on the network, or server programs. This type of test is especially related to the client server and distributed system. Before integration testing, unit testing must be completed.

Integration testing is a logical extension of unit testing. The simplest form is to combine two tested units into one component and test the interfaces between them. In this sense, components refer to the integration and aggregation of multiple units. In practical scenarios, many units are combined into components, and these components are aggregated into a larger part of the program. The method is to test the combination of fragments and expand the process to test your modules with modules in other groups. Finally, all modules that constitute the process are tested together. In addition, if a program is composed of multiple processes, test them in pairs instead of testing all processes at the same time.

Integration Testing identifies problems with the combination unit. By using a testing plan that requires testing each unit before the combination unit and ensuring the viability of each unit, it can be seen that any errors found during unit combination may be related to interfaces between units. This method reduces the number of possible cases to a simpler analysis level.

System Test

System test. The English version is system testing.

System testing is a black box testing based on the overall requirement specification of the system and should cover all the components associated with the system. System testing is a test of the entire product system. It aims to verify whether the system meets the definition of the requirement specification and find out the places that do not match or conflict with the requirement specification.

The system testing includes not only the software of the product system to be tested, but also the hardware, peripherals, and even some data, some supporting software and interfaces on which the software depends. Therefore, software in the system must be combined with various dependent resources for testing in the actual operating environment of the system.

End-to-End Testing

End-to-end testing.

An end-to-end test is similar to a system test. The test-level "grand" endpoint involves all the tests that simulate the situation when the entire application system environment is used in a real world. For example, talking to a database, communicating over the network, or talking to external hardware, application systems, or appropriate systems. End-to-end architecture testing includes functional testing and performance testing for all access points. End-to-end architecture testing is essentially a "gray-box" test, a testing method that combines the advantages of white-box testing and black-box testing.

Sound test

Sound test: sanity testing.

A sound test is an initial test to determine whether a new software version test is sufficient to perform the next big test. For example, if a new version of software conflicts with the system every five minutes, causing the system to get stuck, it means that the software is not "sound" and is currently not qualified for further testing.

Failure Test

Failure Test: failure testing.

Failure testing refers to a "retest" after the software or environment is repaired or corrected ". It may be difficult to determine how many times a test is required. Especially when the development cycle ends. Automated testing tools are especially useful for such tests.

Acceptance Test

Acceptance Test. The English version is accept testing.

Acceptance testing is a final test based on the specifications of the customer or end user, or based on the use of the user for a period of time, to see if the software meets the customer's requirements. Generally, the function, user interface, performance, and business relevance are tested.

Load Testing

Load Testing: load testing.

Load Testing is used to test the performance of an application under heavy loads. For example, to test when a web site is under heavy load, the system response degrades or fails to detect design errors or verify the system's load capacity. In this test, the test object will take on different workloads to evaluate and evaluate the performance behavior of the test object under different workload conditions and the ability to continue normal operation.

The purpose of the load test is to determine and ensure that the system can still run normally when it exceeds the maximum expected workload. In addition, the load test also evaluates performance characteristics, such as response time, transaction processing rate, and otherTimeRelated aspects.

Force test

Force test. The English version is force testing.

Force testing is a term that is often used in alternate load and performance tests. It is also used to describe tests such as system function tests under unusual heavy loads, such as a certain action or a large number of input duplicates and a large amount of data input, A large number of complex queries are performed on a database system.

Stress Testing

Stress Testing: stress testing. Similar to load testing.

Stress testing is a basic quality assurance behavior and is part of every important software testing task. The basic idea of stress testing is simple: it is not to run manual or automatic testing under normal conditions, but to run the test under the condition of a small number of computers or a lack of system resources. Generally, resources for stress testing include internal memory, CPU availability, disk space, and network bandwidth. Concurrency is generally used for stress testing.

Performance Testing

Performance test. The English version is performance testing.

Performance testing is a term that is often used in alternating loads and forced tests. Ideal "performance tests" (and other types of tests) should be defined in the requirement document or quality assurance, test plan. Performance testing generally includes load testing and stress testing.

Generally, it is verified that the performance of the software can meet the performance index if it is reused in the normal environment 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.

Availability Test

Availability test. The English version is practical usability testing.

Usability testing is a user-friendly test. Obviously this is subjective and will depend on the target end user or customer. User interviews, surveys, user conversation videos, and other technologies are available. Generally, programmers and testers are not suitable for usability testers.

Uninstall Test

Uninstall testing.

The uninstall test is a test of all, part, or upgrade of the software. It mainly tests whether the software can be detached, whether the uninstallation is clean, whether there are changes to the system, how to deal with the residual files in the system and the generated files. Whether or not the original system value has been modified

RECOVERY TEST

Recovery test. The English version is recovery testing.

The recovery test is to test whether a system can be well recovered from the following disasters, such as system crashes, hardware damages, or other catastrophic problems. Recovery testing refers to detecting whether the system can be correctly restored by making software (or hardware) faulty. It usually focuses on the time required for recovery and the degree of recovery.

The recovery test mainly checks the system's fault tolerance capabilities. When a system error occurs, can the system be corrected and restarted at a specified time interval. The recovery test should first adopt various methods to force the system to fail, and then verify whether the system can be restored as soon as possible. For automatic recovery, the reinitialization, Checkpointing mechanism, data recovery, and restart mechanisms must be verified. For manual recovery systems, you also need to estimate the average repair time to determine whether it is within the acceptable range.

Security Testing

Security Test: security testing.

Security Testing is to test how the system prevents unauthorized internal or external users from accessing or intentionally damaging the system. This may require complex testing techniques. The security test checks the system's defense against illegal intrusions. During the Security test, the tester pretended to be an illegal intruder and tried to break through the defense line in various ways. For example:

① Try to intercept or decrypt the password;

② Dedicated protection mechanisms for software damage systems;

③ Intentionally causing system failure and attempting to illegally access the recovered machine;

④ Try to derive the required information by browsing non-confidential data. Theoretically, as long as there is sufficient time and resources, there is no inaccessible system. Therefore, the principle of system security design is to make the cost of illegal intrusion more than the value of protected information. At this time, the illegal intruder is no longer available.

Compatibility Test

Compatibility test. The English version is compatibility testing.

Compatibility testing tests the performance of software in a specific hardware/software/operating system/network environment. Compatible with up to backward, and compatible with hardware. There are many considerations for software compatibility.

Comparison Test

Comparison test. The English version is compare testing.

A comparative test is a comparison test with a competitor's products, such as software weaknesses, strengths, or strengths. To enhance product competitiveness.

Acceptability test

Acceptability test. The English version is acceptability testing.

The acceptability test is a simple test of the most basic functions that is conducted 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.

Boundary Condition Test

Boudary testing. It is also called the Boundary Value test.

A black box testing method is a supplement to the equivalence analysis method. It is learned from long-term testing experience that a large number of errors occur on the input or output boundary. Therefore, you can design test cases for various boundary conditions to identify more errors.

The boundary condition test 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.

Strong Testing

Strong test. The English version is mightiness testing.

Strong testing typically verifies that the performance of the software works properly in a variety of 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.

Assembly/Install/Configuration Test

The Assembly/installation/configuration test verifies 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.

Static Test

Static test. The English version is static testing.

Static testing refers to the part where the test is not run, such as the test product manual, which is checked and reviewed .. Static method means that the program itself is not run, and the correctness of the program is checked only by analyzing or checking the grammar, structure, process, and interface of the source program. The static method analyzes the static characteristics of the program to find out the deficiencies and suspicious points, for example, unmatched parameters, inappropriate nested loops and nested branches, unallowed recursion, unused variables, null pointer references, and suspicious calculations. Static Test results can be used to further identify errors and provide guidance for selecting test cases.

Common static testing tools include logiscope and prqa;

Hide data test

Hiding data testing is essential and important in the Software acceptance and validation phase. The quality of the program is not only verified by the visual data on the user interface, but also must include all the data in the system.

Assume that an application requires two pieces of information-the user name and password-to create an account. The user enters the two data and saves the data. Finally, a confirmation window will show the user name and password to the user by finding the data in the database. To verify that all data is correctly saved, a QA tester will simply check the user name and password in this confirmation window. If they succeed? Assume that the database records the third message, the creation date, which may not appear in the confirmation window but only in the archive. If the creation date is retained incorrectly, and the QA tester only verifies the data on the screen, this problem cannot be found. The creation date may be a bug. Because a user account saves an incorrect date to the database, this problem cannot be noticed because it is hidden from the user interface. This is just a simple example, but it evolved into a point: hiding the importance of data testing.

Equivalent division Test

Equivalence partition testing is used in the equivalent division test.

Equivalent division testing is a technique used to design test cases based on equivalence classes. One of the typical black box testing methods is to divide all possible input data domains of the tested program into several parts. Selecting a few representative data from each part as test cases can effectively reduce the number of tests, greatly improve the software test efficiency, and shorten the software development cycle. the purpose of the equivalence class division test is to achieve better testing results with a small amount of representative data with limited test resources. Valid equivalence class box invalid equivalence class. The data in the valid equivalence class represents a set of correct and meaningful data that meets the requirements document. Invalid equivalence classes are the opposite.

Discriminant table

A table is a set of conditions and conditions that result in actions.

Definition: A table is a tool used to analyze and express different operations under multiple logical conditions.

Advantages of table determination: the ability to list all complex problems according to various possible situations, which is concise and avoids omission. Therefore, a complete set of test cases can be designed using the discriminant table.

In some data processing problems, the implementation of some operations depends on the combination of multiple logical conditions, that is, the combined values of different logical conditions are executed separately. The discriminant table is suitable for solving such problems.

Deep Test

The depth test is used to execute all the details of one feature of a product, but not all features.

When the comparison function returns true, the result is displayed. You must enable "# Deep test" to perform the test. Disable it when you do not use it.

Design-based testing

Design-based testing is an English design-based test. It is a method that leads to test cases based on the software architecture or detailed design.

A Model-Based Testing System (Matis ). this method uses the user interface to automatically generate a method to organize the class attribute definitions in the design model and the control attributes in the implementation to construct a logical comparison table of the description interface, the auxiliary test Script Engine executes the automatic test script. with the extended class definitions in the design model, the Matis method can automatically generate test cases and test data.

Document Test

The English document test is documentation testing. The test focuses on the correctness of the document.

There are three main types of document testing: Development files, user files, and management files.

1. Development documents: feasibility study report, software requirement manual, data requirement manual, summary Design Manual, detailed design manual, database design manual, module development file.

2. User Files: User Manual and operation manual.

3. manage files: project development plan, test plan, test analysis report, development progress monthly report, and Project Development Summary Report.

Document testing in software testing mainly tests the relevant design reports and user instructions. The design reports mainly refer to the consistency between the testing program and the design ideas in the Design Report; when testing user instructions, we mainly test whether the descriptions of the procedure operation methods in user instructions are correct. The focus is on testing the operation examples mentioned in user instructions, ensure that the example can be correctly completed in the program.

Generally, documents are an important part of software. Therefore, document testing is also the main content of software testing. There will be many documents throughout the entire life cycle of the Software. Generally, documents can be roughly divided into three types: development documents, management documents and user documents.

Because documents and code are different and cannot be run directly, testing documents can only be conducted in document review mode. Management documents and reviews are typically attributed to management rather than software testing because management document reviews are not intended to discover and eliminate defects in the software that users see, it is to better manage the software development process. For development documents, because these documents themselves reflect the actual form of software in the development phase, testing these documents is actually the main activity of early software testing. User documents are those that are delivered to users along with the program. They are actually an important part of the software delivered to users. Testing of these documents is part of testing the final software product.

Domain Test

Domain testing is used for domain testing. For definitions, see equivalence partition testing );

It is generally divided into single-domain testing and multi-domain testing, where single-domain testing includes device testing and business testing, device testing includes testing a system's Softswitch device, relay media gateway device, signaling gateway device, access media gateway, Iad, and other devices.

There are two different equivalence classes: Valid equivalence classes and invalid equivalence classes. These two equivalence classes should be considered at the same time, because the software must not only receive reasonable data, but also be able to withstand unexpected tests.

Valid equivalence class: it refers to a set of reasonable and meaningful input data for the program specification description. Effective equivalence classes can be used to check whether the program has implemented the functions and performance specified in the Specification Description.

Invalid equivalence class: It is opposite to the definition of valid equivalence class.

Interface Test

Interface testing is used to test the interface between system components.

Benefits of API testing:

Because the Interface Test code itself is implemented by JUnit (of course, the interface type is different, not necessarily by JUnit), it belongs to the scope of automated testing, therefore, it must also include the inherent advantages of automated testing.

1) Improve Testing Quality

The process of software development is a process of continuous integration and improvement, and each improvement may introduce new bugs. Therefore, when one or all of the software is modified, software products must be retested. The purpose is to verify that the modified product meets the requirements. When there is no automated test code, it is often due to a variety of reasons, the regression is insufficient, leading to the omission of bugs.

2) Improve test efficiency

The scale of software systems is growing and the number of functional points is increasing. self-testing by developers or manual testing by testers is time-consuming and cumbersome, which will inevitably lead to low testing efficiency, however, automated testing solves these time-consuming and tedious tasks and achieves a permanent write and use effect without changing the external interface functions.

3) Improve test coverage

It is difficult to test some deeper exceptions and security issues through manual testing. Some auxiliary testing tools can analyze the code coverage rate, improve the test depth by improving the coverage rate.

4) Better reproduction of Software defects

Because the same code is executed each time, once the Code fails, the regression error is inevitable.

5) Better error locating

Because the interface test is a kind of bottom-up test, once an error occurs, it is very easy to locate the error, not to test the system, once there is a bug, the error location can be determined only after several layers of verification.

6) Reduce the bug modification cost. The interface test is basically parallel to the coding of the developer. Therefore, the problem is found much earlier than the system test, thus reducing the bug modification cost.

7) enhance the cooperation between testers and developers. In order to better carry out the work, test engineers must have a deep understanding and practice of development technology, have more communication with development engineers.

8) reduces the risk of project release failure due to early intervention in API testing, the core module of the project code has been thoroughly tested before being submitted to the system for testing, the system test time must be accelerated to ensure that the project is released on time.

9) Improve testing personnel skills. To perform interface testing, you must understand the development process and skills of the developers, use methods and ideas of the testing tools, and increase the technical value-added of the testers, it improves its competitiveness.

10) promote the standardization of the project development process

To perform interface testing, complete documentation is required to ensure that there is no test document. Interface testing will be difficult to implement, interface testing will increase the standardized output of the development process, and the standardized output will also ensure the quality of the project.

Reverse test, reverse test, negative test

The English version of reverse/Negative tests is negative testing, which aims to make the system unable to work.

Comparison between negative test and positive test:

Negative testing is relative to positive testing. They are also two very important parts of the test design. To put it simply, a positive test is to test whether the system has completed the work it should have done, and a negative test is to test whether the system has not performed the operations it should not have done. A positive test is like a respectful elementary school student. A teacher asks me to do what I do, and a negative test is like a naughty child, I am not doing this, and I am in conflict with you. Developers also hate to modify such bugs.

Test non-functional requirements

Non-functional requirements testing is used to test non-functional requirements, such as performance testing and availability testing.

Why are non-functional requirements important?

It is of course important to meet functional requirements when designing a solution. However, if you do not consider non-functional requirements, it is difficult for your solution to achieve results.

Non-functional requirements: 1. Do not leave the actual environment; 2. reliability; 3. availability; 4. Effectiveness; 5. maintainability; 6. Portability.

Limit Test

In essence, the ultimate test is a set of testing strategies and processes designed to meet the ideas and processes of the ultimate test. It is not limited to the use of specific testing techniques and methods.

Process

1. Unit Test 2. Acceptance Test