The cause of the incident lies in the boss’s two recent “breakdowns”, one last year’s and one recent. The common reason is that scaffolding makes mistakes when publishing and packaging on the publishing platform, resulting in the white screen of online applications not available.
The most amazing thing is that after several code reviews, no bug was found that could lead to this problem. Finally, it was speculated that there might be a problem with the server when publishing and packaging.
When the boss N + 1 Tucao, because he wrote the engineering tool to get the sky flying pot, I suddenly make complaints about how to avoid this kind of flying pot outside.
In the final analysis, the reason for this kind of online failure is that the packaged online code has not been verified. There are two ways to solve this problem
- Because of the different request addresses, the pre release (test) version can not be sent online directly, and the online version lacks the verification process before going online. Therefore, a new beta release can be added between the pre release and online release of the release system. The beta release uses the packaging process of online release. The difference is that only intranet access is allowed for internal testing. Some people may ask, even if the beta release is added, there is still no guarantee that the online release will not make mistakes when repackaging? The key point is that the core of this solution is that after the beta release test is passed, the packaged products released by beta will be directly released online, because there is no need for secondary packaging, so new problems in the packaging process are avoided. Because adding beta publishing requires the cooperation of different positions, such as operation and maintenance, back-end and mobile end, it is difficult to implement.
- To solve the problem, since the online version can’t be verified before it goes online, it will return to verification immediately after it goes online. If any problem is found, it will be rolled back manually immediately. The so-called no one found the fault is not a fault, perfect!
As mentioned before, it is difficult to implement the radical cure method, so we focus on the palliative cure method, that is, regression verification after online.
Speaking of which, let me ask you a question. After the requirements are online, as the front end, will you take the initiative to carry out regression verification instead of waiting for the test to verify?
Whether you will or not, I will not.
In this case, the front-end UI automation test is on the scene.
What is front end UI automated testing
As we all know, testing is a very important link, because of its importance, even TDD appears in software engineering.
Before, the so-called front-end testing was more about human flesh testing on the page, which was undoubtedly inefficient.
Therefore, with the front-end automated testing, the use of machines instead of manual. Generally speaking, there are two types of front-end automated testing: unit testing and E2E testing (UI automated testing).
Unit testing is essentially a kind of white box testing, which is to test the smallest testable unit in the program.
E2E test is essentially a kind of black box test, which is equivalent to simulating the user to visit the application, mainly checking whether the interface or function is correct.
Compared with unit testing, UI automation testing is more from the user’s point of view. However, because it is actually a kind of black box test, its efficiency is lower than that of white box test.
Comparison of front end UI automation test framework
Selenium: E2E is the ancestor of testing framework. There are many versions of programming languages. If you ask your company about testing, you will find that they are using Python version of selenium to write automated testing scripts. It is worth mentioning that it is based on webdriver rather than WebKit kernel, so selenium’s browser compatibility is much better than other browsers.
Phantom JS: pioneering headless testing framework, what is headless? That is, the browser without UI interface. The biggest advantage of headless is that it can run E2E test on the command line just like unit test.
Nightcare: in a word, the enhanced version of phantom JS, compared with phantom JS, has greatly improved both the development and operation efficiency.
Tips: nightcare has another advantage – it provides a chrome plug-in daydream, which can automatically generate test code by recording the screen, which is a boon for lazy people.
Nightwatch: an E2E framework with a name similar to nightcare, but completely different, is implemented by calling webdriver from node. Compared with selenium, it is more efficient in development and operation. The most important thing is that iterations are very active, which is understood by users of open source products.
Cypress: the first E2E testing framework I came into contact with is a product with the best testing interface and documentation. I recommend you to have a try.
Puppeter: the integrator of E2E testing framework. It runs in headless mode by default, but it can also be configured to run in chromium mode. The development efficiency and running efficiency are first-class. Most importantly, like nightware, it provides a test code generation plug-in — pushmeter recorder.
To sum up, if you consider browser compatibility, use nightwatch. Otherwise, choose cypress or puppeter. If you need headless or automatic code generation, use puppeter.
The value of automated testing using front end UI
In terms of the benefits of automated testing, automated testing has a formula:
The benefits of automation = iterations * full manual execution cost - first automation cost - maintenance times * maintenance cost
In short, the more frequent the iterations, the higher the maintenance cost of the project, the higher the value of adding automated testing. The introduction of front-end UI automatic testing in infrastructure projects or frequent iteration projects can greatly reduce the time of manual testing after each iteration. Compared with manual testing, front-end UI automatic testing is faster and more thorough.
On the other hand, with the rapid development of front-end technology, each company’s front-end development, monitoring system has been very perfect, but the lack of front-end extension in the direction of testing. The biggest value of front-end UI automatic testing is to make up for the blank area between development and monitoring in the front-end part, forming a complete closed-loop, three pronged approach, which greatly ensures the quality of the project.
I have thought about the front-end UI automation testing for a long time. I think there are two main directions:
- For a single project, we can test a series of key functions. However, if we need to pursue the test coverage, it is time-consuming. It is a more conventional and refined test scheme, so it is more suitable for some long-term maintenance infrastructure projects or large business projects. The disadvantage is that the activity page can’t basically cover them.
- For all projects, add an automated testing scaffold (or platform), which can automatically access the target page through configuration items, and conduct a series of E2E tests. According to different results, take different processing schemes such as screenshot, PDF generation, alarm, etc.
The second solution, that is, the general solution, is also the focus of my recent development. Next, I will write an article to introduce the design and implementation of this solution (if I don’t have a lazy cancer attack [Doge]).
If you have different ideas, you are welcome to communicate with us~
My GitHub: https://github.com/KarthusLorin/blog