Familiar with business
Familiar with the system
Testers must be proficient in various business scenarios of the system they participate in testing. Once the requirements change, you can clearly and quickly know the context. At the same time, you can clearly know which points need to be tested.
Familiar with the upstream and downstream system business that communicates with this system
The upstream and downstream systems that communicate with this system should also be very familiar. In this way, once a problem occurs in the system, the scope of the impact can be known.
Familiar with the company's main process business
Familiar with the company's main business process. Although it is not a system to test by itself, familiarity with the company's main business process can allow testers to have better and broader ideas when considering problems.
Logical thinking and good aura are also good
Internet applications are generally divided into multiple subsystems, and each system has its own business scope. The completion of a task usually requires the cooperation of multiple departments or groups. At this time, it is inevitable to carry out various meeting communication, within the group or between groups. Then, if the testers are not smart enough to quickly understand other people's intentions and ideas , they will be easily fooled or fall into various pits, and there will be endless testing tasks. In addition, when the other party is too strong, the testers should not be too weak. They should put forward their own opinions based on their own understanding of the business and the system, and do what should be done, and don't force what should not be done. Actively cooperate with each other, but not doing everything stupidly.
Control system launch schedule
If there are a lot of development tasks, the testers have to test a lot of functions. At this time, if the launch time of the function is determined by the development manager or PMO, then the testers can only work endless overtime . This is not acceptable. Testers have their own specialties and are proficient in the business. They must clearly know which tasks have high priority and which are low, and prioritize the tasks . It is stipulated how many functions can only be used in a certain period of time. What is the maximum task queue that the test team can bear, and the testers must have a bottom line. If the test task exceeds this queue, some tasks can be squeezed out according to the priority **.
Say "no" to uplines
Every time a function is launched, the tester should first ask the developer for one 回滚/降级/灰度方案. If the developer does not provide it, the tester has the right 不上线, because even if the tester tries his best to verify the function, there is no 100% guarantee that there will be no problems after the launch. If something goes wrong, the loss must be minimized. Either roll back, or downgrade, or have a switch to turn off new features. If it can't be done, it may take several hours to solve a fault, and the loss is very large. The testers must have an awareness that when there are online problems, they must reduce the loss as soon as possible and then 线下solve the problem, instead of a group of people gathering together to think about how to solve the current online problem.
Ability to write test cases that cover critical paths
After an accurate understanding of business requirements, testers can design key test cases based on business needs, which can completely cover business critical paths and scenarios , and ensure that as long as these key use cases can pass, it means that the key functions of the requirements have been OK. The key functions are OK, even if it goes online immediately, if there is a problem, it is only a small problem. Of course it would be best to be able to cover everything with test cases.
Ability to locate problems
When testers are testing the system, they should not go to the developer as soon as they encounter a problem. They must think deeply about the possible causes of the problem, and find more data to verify it. It is best to make the problem reproducible.
Familiar with testing technology
When testing Internet applications, the test must at least master the following technologies and concepts:
- Know how to use jmeter for performance testing;
- Know how to build the environment required for performance testing, such as server, redis, memcache, etc.;
- Know how to write performance test reports. For example, at least include interface response time, QPS, optimal concurrency, CPU usage, memory status, jitter, GC status, and so on.
- Understand the concepts of context switching, memory overflow, memory leak, QPS, stability testing, etc.
- To know how to do online UAT verification, especially for projects that require multi-system cooperation, UAT is an extremely important step.
Constrain developers to ensure development quality
When developing test code, testers should have the following awareness:
- Let the developers first merge or rebase the code of the master branch to their own branch to ensure that the code already contains the code of the master when testing, so that problems can be found in advance.
- After the functional testing of the code is completed, a regression test must be done again. At this time, developers must be strongly restrained, and no more code submissions are allowed. Unless it's a bug. Otherwise, after the tester finishes the regression test, the developer comes to tell the tester that the code has changed. In this case, the testers' hard regression testing will be in vain, and they have to go back again.
- Testers must reclaim the code submission authority of the master branch. Once the developer wants to submit the code, they can only communicate with the tester to explain what changes have been made to the code. Developers must not be allowed to submit code quietly. This behavior is very likely to cause online failures.
- If the functional module is cross-system, that is, it will call the interface of another system. In this case, the tester must require [ development joint debugging ] for the development between the various systems. Testers must force development to do this. Otherwise, various interface calls may fail, and the input and output parameters of the interface may be misunderstood, which will seriously hinder the progress of the test. If [Development Joint Debugging] is not done, the tester can call back directly.
Know how to write code for interface automation testing
Now microservices are very popular, and major Internet companies are developing microservice interfaces. For microservice interfaces, testers must know how to write code to perform interface automation testing. Think about it, suppose a system has 50 microservice interfaces. After the tester finishes testing once, the developer modifies the code of 10 of the interfaces. At this time, it should be possible to verify the changes of these 10 interfaces by running an automated case. The other 40 interfaces were not affected. This regression test is very efficient . If you have to manually perform interface regression testing every time, the testers will be exhausted.
If the article is helpful to you, remember to like, bookmark, and add attention. I will share some dry goods from time to time...
END Supporting Learning Resources Sharing
Finally: In order to give back to the die-hard fans, I have compiled a complete software testing video learning tutorial for you. If you need it, you can get it for free 【保证100%免费】
Software Testing Interview Documentation
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Ali, Tencent, and Byte, and some Byte bosses have given authoritative answers. Finish this set The interview materials believe that everyone can find a satisfactory job.
How to obtain the full set of information:
