What a good software test engineer should do-years of software testers share their growth experience

关注我，每天分享软件测试技术干货、面试经验，想要领取测试资料、进入软件测试学习交流群的可以直接私信我哦~~

——We grow up in change. Suppose you reject change, then you reject new beauty and new opportunities.

Initial software testing

"This is a cup, mainly for drinking water. How should its quality be considered?"

This is the question that the test supervisor asked me when I entered the interview at the previous company. The related answer is a bit vague, but from this question, it can be roughly understood that the test supervisor is examining my test thinking.

Secondly, how to accurately obtain and express these requirements, that is, how much relevant indicator data is. If you want to know the size, height, and volume, you have to use related measuring tools, such as rulers and compasses. To know the temperature tolerance range, you may need to use a thermometer, etc.

During the completion of the test work, the original requirements (including hidden requirements) must be clearly understood before the test design and execution, and then the corresponding test plan is required, what types of tests need to be performed, and what test tools are used.

I am very grateful to the test supervisor for guiding me in my testing work, not only in specific skills training, but also in other tasks for guiding me in my testing thinking.

Functional testing practice

After the interview, I entered the company. The first project I came into contact with was the National Tax Portal. The testing work performed was mainly functional testing, such as test case writing, execution, and test report feedback. At that time, I was very vague about the so-called software life cycle, and I felt that I just had to do my own test tasks, and the other things would be arranged by the superiors. Now think about it really so white, idiot white. In the next year, I was really exposed to the actual production process of project development and delivery. In short, the work tasks are endless, there will always be countless needs to be developed and tested, and there are a lot of things. Bugs need to be tracked. How to maintain a clear position in the middle is very important. Since there is only me as a tester in the project team, the result is that "all things tested are mine", which seems very powerful. But I'm just Xiao Bai.

"So and so, come here, this is the revised content of this version, probably to be completed on a certain day of a certain month, you have a look."

"Oh".

When the test is executed, the problem is found and submitted to the development colleague, and the development response: "This is the design."

"Oh".

About to go online, the project manager asked: "So-and-so, how is the testing situation of the system now, can it go online?"

"It should be about the same"

…

After the test supervisor learned about it, he emphasized a few points with me:

1. The basis of the test, the requirement baseline must be clear, and participation as early as possible;

2. The test must have a plan and design with examples, and it must not be carried out at will;

3. Bug tracking, you must have your own opinions and principles;

4. To grasp the test results, there must be result analysis. When the project is launched, it is necessary to synthesize your above test process and summarize the report based on the current situation, and even the project manager should listen to your opinions. Your role is not only testing, but also quality assurance.

Of course, the above situation is only a little bit of the problem encountered in the test, such as a grain of sand in the desert (how the child came here), but it also made me realize that the test is independent and important.

In the subsequent project testing work, while practicing the thought principles passed by the test supervisor, I also learned about related testing books, tools, and skills in parallel, and combined with the work to carry out related practices, gradually my testing ability became stronger and stronger.

After being dispatched to the provincial and national tax authorities for a year, the testing process became more organized, principled, and standardized. But it is only a personal conscious constraint. Many processes are not implemented in accordance with the standards of the software development cycle. For example, test cases and test reports are sometimes written after the release of the version (although the company has also passed CMMI3), that is, the quality of the test Ensure more dependence on personal qualities. Moreover, I personally believed that the proficiency of the test business was more determined by the familiarity of the system function itself and the familiarity of the test design implementation. Recognizing errors and conscious changes was the test process of the enterprise management system and the electronic tax service department at the fixed point of the local tax. .

After that, enter the fixed point of the land tax to contact the enterprise management system project team for testing. At that time, the project was about to enter the acceptance stage. The functions required by Party A were basically realized, but Party A was not satisfied at the time of delivery. Many requirements were put forward on the ease of use of some functions and the display of the system interface, which led to the final framework of the entire system. , The prototype was changed again, and the time limit for modification was very short (it was the beginning of overtime work again), and finally even the project leader was changed.

In summary, there are several problems:

1. The established and clear requirements have been implemented as required, but the implementation method is not suitable for Party A's appetite. If the chart is not rich enough, there is only a summary and no details.

2. The system interface does not have a unified style, and Party A bluntly said that it looks like a draft.

3. The process does not reflect the content and steps of Party A's daily work.

4. The risk control system is superficial and the indicators are not practical.

During this testing process, I formally participated in various demand discussion meetings organized by Party A. During the period, I realized that there is actually a design and implementation process from the original demand to the demand baseline. The degree of certainty depends on the person in charge or the product manager. Of spirituality. As a tester, in the requirements review process, you must compare the original requirements (to learn more about the specific daily work content, industry specifics, etc.) and the difference between the requirements baseline, give your own opinions, and remind yourself from time to time during the testing process. And whether the understanding of the requirements is deep, sometimes it is not achieved by participating in the formal requirements review. It also needs to go deep into the actual work scenarios of the users and understand the actual business and processes. As for the requirements that you cannot accurately grasp (risk control system) and users cannot provide accurately, you must set the boundaries and achieve what extent. Finally, easy-to-use software is not only the realization of functions, but also an interface style that allows you to start all over again. The project that was originally planned to be delivered in a short period of time, due to various subsequent modification requirements, did not basically end related testing activities until March of the following year.

After completing the test of the designated contact enterprise management system, I entered the project team of the Electronic Tax Service Office, where my personal business mastery was recognized. First of all, be familiar with the related business (documents, declarations, etc.) of the core system (the electronic tax service hall interface call provider), and can integrate with the corresponding system's Chinasoft project team (also learn from the lessons of poor communication in Shaanxi , Mentioned in detail later in the performance test). Secondly, I fully understand the needs of the electronic tax office, thanks to the patient guidance of the demanding personnel at the time (for the tax career, the gray-haired colleague), and finally I am familiar with the back-end data table structure of the relevant system. After a problem occurs, you can quickly sort out your ideas and locate the cause. After the problem arises, when you communicate with the relevant person in charge, they will be convinced. After more than a year of teamwork, the project team started the docking work with Jinsan (it will take 2 months to complete, and it is a good time to watch the stars and the moon). The project manager assigned me the task of joint debugging of the interface. In my understanding of the original two-party system and personnel.

Performance testing practice

Of course, there are more than just functional tests. The first contact with the performance test was also in the national tax portal project team, but the test object was not the national tax portal website. In fact, I don't know the specific business of that software system (ashamed), I only know that it is called a one-family query system. Although I learned about the principles of performance testing at that time, it was still a bit confusing how to do it. With the assistance and guidance of the test supervisor (it is not too much to say that it is not too much to help each step), it is difficult to complete.

Here, extra intercept the result data of a certain business scenario test at that time (the graph is not found, and post the data recorded in the table at that time. You read it right, it is 5 concurrent time 95s!!!)

Follow my WeChat public account:[Sad Spicy Strips]Receive a 216-page software test engineer interview book for free. And the corresponding video learning tutorials are free to share!

After performing this test, I learned the following related information about the same performance test:

1. The deployment composition of the system, and what are the related servers (the specific network topology is not yet known at this time).

2. The selection basis of relevant scenes.

3. The use of tools and the recording of scripts.

4. Main performance indicators.

5. Simple analysis based on tool results.

Forgive me for being simple and plain at the time, that's all I can grasp.

In the subsequent project testing process, I also have experience in performance testing, such as the tax enterprise communication project (C/S structure), the provincial national tax portal website, etc., but what really impressed me and benefited a lot is the online land tax declaration project .

There are multiple partners involved in the online newspaper project. Different companies are responsible for the delivery of the network, firewall, CA certification service, and core declaration. If there are problems during the testing process, it is often difficult to locate who is responsible.

In this case, it is particularly important to understand the network deployment topology of the system, and then the specific test scenarios are carried out.

Specific test scenarios are carried out:

1. Familiar with the network topology diagram, the physical and network deployment of related machines and servers, and prepare for the subsequent hierarchical testing.

2. The calculation of the number of concurrency, according to the calculation formula C=nL/T (C represents the number of concurrent, n represents the average number of online people, L represents the scene operation time, T represents the scene inspection time) is more idealized, because the project is not related Measures are monitored, so it is difficult to obtain specific parameters such as the average number of online users and operating time. At this time, it is necessary to consider the actual system usage. For example, the total number of taxpayers in the system and the total number of declarations, monthly declaration time (1st to 15th, generally the last week or 3 days is the majority), daily declaration time (9:00 a.m.-12:00 and 14:00-17 p.m. ：00) and other information to calculate the transaction throughput per second to get the number of concurrency (transaction throughput * business scenario time).

3. Select the business function scenario that needs to be tested according to the actual business.

4. Performance test scenarios, such as the maximum concurrency of the system, the maximum concurrency of a single node, the maximum concurrency of different network access points, stability testing, etc.

5. Other indicators such as response time and resource usage.

…

After the above plans and indicators are determined, specific preparations and implementations can be made.

During the execution process, of course, it will not be so smooth. Start to test from the outer network, the outermost part of the system. If the result is not ideal, then we must locate the cause, filter out the business scenarios with poor indicators, and then test separately. At this time, the relevant scenarios are added with time. Stamp the information, collect logs on each server, and then change different server addresses to test and compare the results of different access points in order to confirm the truth. Finally, take the specific results to the corresponding partners for discussion and analysis.

It took a lot of time to implement the overall design plan.

When the specific test is performed, the internal functions of the company are fairly smooth, but it is more troublesome when it comes to the layered test. The first is that it needs to be carried out in different office locations (no direct access to the IP), project team office, tax bureau computer room, China Unicom computer room, etc. Remember that after spending a night in the computer room, the sweat stains are all green. When encountering problems and communicating with partners, the response speed is the same as in scenarios with poor indicators-slow. Of course, your own communication method also has its shortcomings. For example, you should tell your partner that there is a problem with your system. It should not only be verbal, but should include specific evidence (error log, test result report, etc.), and set a resolution time, if necessary Party A is also required to be present.

But no matter what, the original test goal was finally completed. The process is arduous, but it makes my way of doing things in the future more organized, step-by-step, practical, and patient.

Growing up in change
Walking through the embankment, there is a willow, stepping into the field, it is a boundless wave of wheat. People will always experience different journey landscapes and gain different growth insights between changes.

The first work experience formed my basic understanding of testing and working methods. After receiving the test task, I would conditioned to imagine the type of testing that needs to be carried out and related plans. But whether these tasks can be carried out more standardized and engineered is only a vague concept.

After that, the test work was changed again, and the work started to be no different, except that test cases must be written before the test execution. But over time, I experienced a different atmosphere.

Testing should be started as soon as possible, and arbitrariness should be excluded, and it should be carried out in a planned way. This is one of the principles of the basic theory of software testing. In Gongjin, the software development process has a relatively complete process, during which testers have to go through requirements review, test case review, pre-test review (review before submission for testing, functions realized by development demonstration), test report review, etc. After the requirements review, detailed test analysis and use cases must be included in the task plan for monitoring. The execution results of the use cases can also be checked at any time to understand the test progress.

While implementing manual functional testing, we continue to carry out automated functional testing and performance testing.

In the eyes of many companies, automated testing is a contradictory thing, and the cost of manpower consumption and iterative release versions to maintain the original scripts should always be considered. Before an automated testing system was established, it could only be reduced to a personal interest or form.

Our automated testing work has gone through 2 years so far, and the coverage of automated functional testing has reached more than 95%. During this period, the students who conducted automated testing have gone from scratch to complete, and normalized execution. Now using Selenium to run scripts on multiple devices in a distributed manner, you can quickly execute test cases with original functions. With more and more complex business functions and more and more test cases, the status of functional automation testing becomes more obvious.

As for performance testing, it has also become relatively easy to carry out. The user usage scenario data of the relevant system can be easily obtained (for example, the number of concurrent calculations), and the test execution has also formed a normalized mechanism. It is not no longer performed after a certain test, or the test again after optimization needs to be done manually again. . In the current interface performance test and system performance test, after the business scenarios and scripts are determined, the specific operation design plan is automatically executed every day, and the execution results pass the report (not the report of the test tool itself, but the test results are saved to the database and restarted as required. Organize the output report) to show that the relevant person in charge can selectively optimize through the results, and then continue the test.

Whether it is functional automated testing, or interface and system performance testing, we have achieved engineering and automated working methods, and practiced the principle of continuous testing that is often mentioned in software testing.

It's easy to find that, in the past, it was a test process of one person fighting in groping and constantly climbing pits. Now it is an engineered and automated process of continuous optimization and improvement. Individuals are self-evident about the trend of the system.

The following are some points from personal testing experience:

1. Push the test forward as much as possible, find out as soon as possible, and reduce the cost of repair;

2. The purpose of testing is not to find bugs, but to prevent the occurrence of bugs;

3. Through various technical means and process improvements, gradually liberate the company's internal testers, allowing them to focus on the grasp of the product.

Especially for points 2 and 3, testers have been repositioned. And the automated test platform (ATP) we are building, it reduces the technical threshold of functional automated testing, integrates various types of test work, timely feedbacks test analysis results, improves test efficiency, and will truly release the capabilities of testers to achieve The above standards will no longer be empty talk. Although we cannot say that our testing work has reached such a standard, at least we are now on the right path. As long as the direction is right, then the goal will be reached.

Of course, no matter how good the starting platform is, the quality of testers is the guarantee that determines the final test quality. After being liberated from the original repetitive working methods, the comprehensive qualities of testers, such as industry knowledge, test thinking, and test design schemes, all affect the specific test results. These are tools and platforms that cannot be replaced.

Test encouragement

IT work is hard, and software testing is of course no exception. Execute use cases every day, track bugs, and quarrel with developers and product classmates about PK, and have fun with others~ But it is precisely because of these silent efforts that you let a disaster that should have occurred in front of users, in front of yourself in advance Happened, do you feel like a savior? You saved the user and saved the software, avoiding her fate of being abandoned and uninstalled.

If you are interested in software testing, want to learn more about testing knowledge, solving testing problems, and getting started guidance to help you solve the puzzles encountered in testing, we have technical experts here. If you are looking for a job or just came out of school, or have already worked but often find it difficult, you feel that you have not learned enough in the test, and you want to continue to learn, if you want to change careers and are afraid that you will not be able to learn, you can join us,, group, 902061117 . Receive the latest software test interview materials and learning materials for Python automation, interfaces, and framework building!

If the article is helpful to you, please reach out to make a fortune and give me a like. Thank you for your support. Your likes are my motivation for continuous updating.