How to make full use of automated testing in the project?
First, you need to analyze whether the current project is suitable for automated testing:
Test requirements are clear and do not change frequently
Regression test-based projects
The software system interface is stable with few changes.
Each iteration requires running duplicate cases on multiple platforms (or multiple OS, multiple Browser).
Long software maintenance support cycles
Manual testing cannot simulate scenarios. Such as stress testing, concurrent testing, etc.
Basic automated test platform
The following is an automated testing framework for a project that I have participated in.
Realize automatic code update, compilation, packaging, deployment, restart services, regular execution of script tasks, log report output, automatic email notification.
Before automation begins, it is necessary to determine expectations and what needs to be achieved. Instead of abstractly reducing labor costs, finding as many bugs as possible or saving time, etc. Automated testing should be realized after discovering repetitive activities that can be automated by tools. Not 100% of cases can be automated. The experience of testers, logical judgments and exploratory testing methods cannot be effectively automated.
In general projects, it is necessary to ensure the basic quality of the version under test, and a large number of functional tests and stress tests can be carried out.
(1) Defects found at the environmental level.
Many defects found in the project system testing phase will be heard by developers when there is no problem in self-test, even when there is no such defect in local testing, the Bug will be directly returned and marked as unable to reproduce. This is an environmental problem. I once encountered a problem that caused the submenu to be confused when clicking on a first level menu (it was confused with the submenu of other first level menus). After investigation, we know that the development has written the coordinate value of the menu dead, resulting in the inability to recognize the menu information normally after changing the environment. This is a typical environmental problem that can only be detected through retest. The other is that the development self-test is local, and some installation packages or tools are deployed on your own machine with administrator privileges, and it is not clear whether the version under test depends on these packages or tools during self-test. Some problems were discovered when deployed to a test environment. Problems similar to the above, if built in a timely manner, and automatically perform basic functions, these environmental problems will be discovered before formal testing, rather than waiting until the system test phase to troubleshoot.
(2) Identify errors in the integration phase as soon as possible.
If the defects in the integration test phase are not exposed or do not affect the normal process, it is impossible to determine which developer is responsible for the module, and the developers cannot test most of the potential integration defects due to time problems, resulting in errors exposed during deployment to the system test phase, which undoubtedly increases the development test time. If every build can be automated to basic functionality, developers can detect integration errors in a timely manner, and at the same time make up for the lack of unit testing, providing system-level test feedback quickly.
