Acceptance Testing: Acceptance testing is designed to demonstrate to buyers of the software that the software system meets the needs of its users. The purpose of acceptance testing is to discover "unimplemented requirements " and to evaluate "fitness-for-use ". The purpose of this type of testing is not to find defects. Its test data is usually a subset of the test data for system tests. . . The difference is that acceptance testing often has a representative of the purchaser of the software system on-site, even at the site where the software is installed and used. This is the final test of the software before it is put into use.
Regression testing : Regression testing is generally performed during the software maintenance phase after the software has been modified. Its purpose is to verify that the modifications made to the software are correct. Here, the correctness of the modification has two meanings: one is that the modification has achieved the intended purpose, such as the error has been corrected, and the new operating environment can be adapted; the other is that it does not affect the correctness of other functions of the software.
There are four main stages of software testing: unit testing, integration testing, system testing and acceptance testing.
unit test
A unit test (module test) is a small piece of code written by a developer to verify that a small, well-defined function of the code under test is correct. Generally speaking, a unit test is used to determine the behavior of a specific function under a specific condition (or scenario). Unit tests are also usually written by developers (a type of white box testing). The methods that can be used are static code analysis, data flow analysis, code coverage analysis, etc.
Integration Testing
Integration testing, also called assembly testing or joint testing. On the basis of unit testing, all modules are assembled into subsystems or systems according to design requirements (such as according to the structure diagram), and integration testing is performed. Practice has shown that although some modules can work individually, there is no guarantee that they can work normally when connected. Problems that cannot be reflected in some parts of the program are likely to be exposed globally and affect the realization of functions. Also, if the program consists of multiple processes, they should be tested in pairs, not all of them at the same time. An effective integration test helps to resolve the compatibility and operability problems of related software with other systems.
System test
System test is to combine the confirmed software, computer hardware, peripherals, network and other elements together to carry out various assembly tests and confirmation tests of the information system. Whether the system satisfies the definition of the requirements specification, find out the places that are inconsistent with or contradict the requirements specification, and then propose a more complete solution. After the system test finds a problem, it is necessary to debug to find out the cause and location of the error, and then make corrections. It is a black-box test based on the overall requirements specification of the system and should cover all the joint components of the system. The object includes not only the software to be tested, but also the hardware, peripherals, and even some data, some supporting software and its interfaces that the software depends on.
Acceptance Test
Acceptance testing is the last test operation before deploying the software. After the software product has completed unit testing, integration testing and system testing, the software testing activity that is carried out before the product is released. It is the last stage of technical testing, also known as delivery testing. The purpose of acceptance testing is to ensure that the software is ready and ready for use by end users to perform the intended functions and tasks of the software.
There are many ways to define software testing methods from different perspectives.
Static & Dynamic Partitioning
Static testing includes code inspection, static structural analysis, code quality measurement, etc. Code inspection includes code walkthrough, desktop inspection, code review, etc., mainly to check the consistency of code and design, code compliance with standards, readability, correctness of logical expression of code, rationality of code structure, etc.; it can be found that Problems violating programming standards, unsafe, ambiguous and ambiguous parts of programs, identifying non-portable parts of programs, violating programming style, including variable checking, naming and type checking, syntax checking, and program structure checking, etc. . In actual use, code inspection is more effective than dynamic testing, can quickly find defects, and find 30~70% of logic design and coding defects; code inspection sees the problem itself rather than the symptom. But code inspection is very time-consuming, and code inspection requires accumulation of knowledge and experience. Code inspection should be carried out before compilation and dynamic testing. Before inspection, requirements description documents, program design documents, program source code lists, code coding standards and code defect checklists should be prepared. Static testing has the advantages of early detection of defects, reduction of rework costs, coverage of key points and high probability of defect detection.
Dynamic testing refers to running the program under test, checking the difference between the operating result and the expected result, and analyzing the operating efficiency and robustness. It mainly includes three methods: constructing a test instance, executing the program, and analyzing the output of the program. At present, dynamic testing is also the main way of testing in most companies.
" box " division
Software testing methods can traditionally be divided into white box testing and black box testing. The so-called white box or black box, the simplest difference is whether the program source code is visible to testers.
white box testing
Also known as structural testing, transparent box testing, logic-driven testing, or code-based testing. The white box method fully understands the internal logic structure of the program and tests all logic paths. White-box methods are exhaustive path testing. When using this scheme, the tester must check the internal structure of the program, start with checking the logic of the program, and obtain test data. White box testing methods include API testing, code coverage testing, error injection testing, program mutation testing, and static testing.
白盒测试的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
黑盒测试
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，程序被看做一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序是否按照需求规格说明书规定的正常使用，程序是否能适当地接收输入数据并产生正确的输出信息。主要针对软件界面和软件功能进行测试。黑盒测试方法主要包含等价类划分法，边界值分析法，决策表法，因果图法，模块测试，模糊测试，用例测试，探索测试还有根据需求规格制定的测试等。
灰盒测试
灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
1. 等价类划分
2. 边界值分析 ---- 考虑边界条件选取测试用例的一种黑盒测试方法
3. 因果图 ------对等价划分的扩展，等价类的组合判定表
4. 状态图
5. 场景法 ---事件触发时的场景便形成的场景
边界值分析：
正好等于，刚刚小于和刚刚大于边界值，而不是选取每个等价类内的典型值或任意值作为测试数据
bug的等级划分
致命级
严重级
一般级
提示级