Here we go again.
The last two months. He’s like a monkey. Study the business every day. Only spare time to maintain tools and platforms.
But I recently turned down a business test. Lose one’s temper. Even threatened to quit the big deal, have the ability to fire me… This “rhetoric”.
After inquiry learned that our group before a lot of colleagues have been tested by the department of different degrees of bullying. For example, there is no test environment, it is required to rush online, online testing. And then something goes wrong, testing the blame. Or online tests can only last for a long time because there is no way to make use of various tools/scripts to save manpower and time. For example, you need to wait for 3 days to test a three-day discount coupon, and this coupon has to go through layers of financial approval to prevent you from cashing out. There’s a bug, and before I can mention it, you’re on the way from finance and risk control.
The scariest part is that there are often some anti-disturb tests that need to be tested at midnight. In a test environment we can easily modify the database to implement the substitution. But online hehe. You really need to wait for the middle of the night to get up.
What’s more, you must have seen tsest push on many well-known big software, right? And then sha a test sacrifice to heaven? The real reason is not the test.
For example, if they want to test their tweets online, they say they will write an if filter for you and only send them to you. You start out nervous, only to find that it has been pushed to tens of millions of users…. Because that if write wrong, or just write by others online deployment to cover the original state…..
This is not a serious development project cycle at all. Why drag the tester? Because the need to carry the pot man….
But recently, when I was supporting the various departments, it hit me in the head, and as a veteran with a keen sense of smell, I immediately rebelled. Contingency is contingency. You can’t afford to take the risk. Either don’t go online, or you can test yourself. Well, you didn’t self-test for smoke, and the procedure was wrong.
Of course, the leader still sided with me, and an emergency meeting put the matter to rest, with apologies and backsliding. But I still didn’t let go. I either invested in a test environment or didn’t test anything in their department in the future. However, I heard from my team members that I had suffered many losses before. I dared not speak out and applied for a test environment, but I did not approve. This time I made a big fuss and applied for a top P, and it turned out… And yet it failed. Forget it. I can’t take it.
Take advantage of the free time, or come back to work on the UI automation architecture you designed earlier. To put it bluntly, it is a set of keyword-driven core architecture. It’s just a lot of design, a lot of tricks. Thousands of use cases written by each of our test students can be directly translated into the code in the cache to make the mobile app run.
It’s amazing to see that the phone starts running automatically when describing various use cases in Chinese. The automated testers who write scripts in the middle are gone.
Before doing this, I analyzed the various features and application scenarios of UI automation, including some issues that we didn’t consider before.
Questions like:
It’s said that UI automation is bad because it’s expensive to maintain and the front end is always changing.
Think about:
Why high? Because the front end always changes, right? So what has changed? In fact, there are three: 1 is old use case logic, 2 is old use case element positioning statement, and 3 is new use case.
If you solve these three problems, will UI automation be stable? Of course, we can’t solve it completely, but we can solve it as much as we can, and when we reach an acceptable maintenance cost, can we do it? And if ai intelligence can be used to continuously improve the accuracy of error correction, will eventually reach a state that does not need human maintenance?
Of course, there are many nodes similar to the above assumption and analysis.
And in the beginning, I also analyzed and predicted all kinds of development risks, the most terrible is a sudden problem that has not been considered, and then can not be solved or bypassed, resulting in the whole project design efforts wasted, and then resign
After a month of sporadic time in the development, really as I expected, encountered a lot of sudden problems. Fortunately, it all worked out perfectly.
Finally last night, the first demo case was successful. Directly facing a use case on our use case platform, the mobile app starts to run, with the same logic and judgment as human beings.
This demo proved that the idea of this architecture was successful, and the effect was very, very shocking. I tried to change the example and write some logic and assertions casually. Sure enough, the app, acting like a living person, starts to run and assert exactly as you write Chinese characters.
For example, THE use case I wrote is: enter the personal center page, click login, and login is successful, and then go to the home page to see if the welcome is correct, and then go to the personal Settings page to see the nickname.
Then the practice of the new architecture is to open the app first, and then determine to go to the personal center page, but their current were not on this page, find themselves on the front page, and then figure out how to do to the shortest path into the heart of the individual, and the people into the then go after, decide whether to enter a success, and then start looking for landing button, click. Then go in and identify use cases need to log in successfully, good, automatic find username/password/login button, after the success, he will decide whether really log in successfully, then feel to go to the home page, but he is not on the front page, and then find a way to jump to the home page, look at the popular language feel no problem, Then do the same thing and go to the profile page to see the nickname.
Anyway, look, this may seem like a normal operation, but it’s actually quite shocking to see, as if it’s alive. For example, AFTER I login successfully, go to the chat page to see if there is a new notification of the little red dot. Executing it again will do exactly that.
So, that’s my solution and the techniques I’ve implemented to solve the problem of using case logic changes.
Next is how to deal with the problem of element location change. Fortunately, MY wQRFNIum_APP automatic maintenance element of the open source tool was developed first, which can be directly applied to deal with many front-end element location problems.
Next comes the question of new use cases. Never mind that. Because every execution, to the architectural system, is a new use case, will follow the logic to run the app again. So it doesn’t matter.
Encountered many unexpected problems:
For example, the same page, under different login status, the content inside is completely different.
For example, two pages, in some state, the contents of the same, so that the system does not know where it is currently located.
For example, the data for an input box element is too scribbled on the use case and does not give the exact content that should be entered.
For example, a process use case is missing a lot of key information, such as login, should write enter user name/enter password/click login button, but in use cases we often see a simple four words: login success
Many, many of these unexpected problems have been solved by adding new controllers, adding new layers, adding new filtering layers, adding new components, and introducing technologies like AI deep learning and big data recognition.
The above is just the process of locating an operation. The other big process is assertion. And of course it was implemented.
An architecture that sounds simple at first, but actually reaches a stable working state, doubles the code twice at least. Failure to solve any small problem can lead to failure.
After the first use case is successfully executed, the line is open. Other use cases are expected to encounter some unexpected risks, but the total is fixed. After several iterations, all use cases will be resolved.
I think I can write a tutorial or a book after this works well. Of course, there are many more tutorials waiting to be written, so I hope there are still people reading this account and blog by then.
The personal domain address of the blog
Collected in topic # Test open diary series essays
27
Previous Test Developer Diary: 2020.9.21 Next Test Developer Diary: 2020.10.10