Black box testing: not based on any knowledge of internal design and code, but on requirements and functionality.
White Box testing: Based on an internal logic knowledge of an application code, the test is based on overwriting all code, branches, paths, and conditions.
Unit tests: Tests of the smallest size to test a feature or block of code. It is typically done by programmers rather than testers, because it requires knowledge of the details of internal programming and coding. This work is not easy to do unless the application system has a well-designed architecture, and you may need to develop test drive modules or test kits.
Cumulative comprehensive testing: When a new feature is added, continuous testing is done on the application system. It requires that the different forms of the application system be independent enough to be able to work separately before all the systems are complete, or that the test drives have been developed when needed, and that such tests can be done by programmers or testers.
Integration testing: A joint test of the various components of an application system to determine whether they can work together. A part can be a block of code, a standalone application, a client on a network, or a server-side program. This type of testing is especially relevant to client servers and distributed systems.
Functional testing: A black-box test method for testing the functional requirements of the application system. This type of testing should be done by testers, which does not mean that programmers do not have to check that their code works before they are released (naturally he can use it for various stages of testing).
System Testing: Black box testing based on the overall requirements of the system, covering all the combined parts of the system.
End-to-end testing: Similar to system testing, test-level "grand" endpoints, all tests that involve the simulation of the entire application environment in a real-world scenario. For example, a conversation with a database, a network communication, or a conversation with an external hardware, an application system, or an appropriate system.
Sanity testing: Typically refers to an initialized test effort to determine whether a new software release test is sufficient to perform the next big test endeavor. For example, if a new version of the software conflicts with the system every 5 minutes, leaving the system in a quagmire, stating that the software is not "sound" and that there is currently no further testing condition.
Exhaustion Test: A "re-test" after a software or environment repair or correction. It may be difficult to determine how many times you need to test again. Especially at the close of the development cycle. Automated testing tools are especially useful for such tests.
Test: The final test based on the customer's or end-user's specification, or whether the software meets customer requirements after a period of user use.
Load test: Test the performance of an application under heavy load, such as testing a Web site under a large load, when the response of the system degrades or fails.
Forced testing: Terminology commonly used in alternating load and performance tests. It is also used to describe tests such as a system function test such as an unusual overload, such as an action or input of a large number of repetitions, a large amount of data input, a large number of complex queries on a database system, and so on.
Performance testing: Terminology commonly used in alternating load and forced tests. The ideal "performance test" (and other types of tests) should be defined in the requirements documentation or quality assurance, test plan.
Usability testing: Testing for "user-friendliness". Obviously this is subjective and will depend on the target end user or customer. User interviews, surveys, videos of user conversations, and other technologies are available. Programmers and testers are often not suitable for usability testers.
Install/Uninstall Test: Test all, part, or upgrade the installation/uninstallation process of the software.
Recovery testing: Test whether a system recovers well from the following disasters, such as system crashes, hardware corruption, or other catastrophic issues.
Security testing: What happens when a test system prevents unauthorized internal or external user access or vandalism. This may require complex testing techniques.
Compatibility testing: How the test software performs in a specific hardware/software/operating system/network environment.
Comparative testing: Comparative testing of products with competing partners, such as weaknesses, advantages, or strengths of software.
Alpha testing: Test the application system when the system development is nearing completion, and after testing, there will still be a small number of design changes. This test is typically done by an end user or other staff member, and cannot be done by a programmer or a tester.
Beta testing: Tests that are done when development and testing are complete, and the final errors and problems need to be found before the final release. This test is typically done by an end user or other staff member, and cannot be done by a programmer or a tester.
This article was selected from: http://www.spasvo.com/news/html/20141211143339.html
22 Test types to consider in the test design
