preface

According to one report, application crashes cause 71% of uninstalls. Other reasons that force users to uninstall applications are page response times, confusing UI, battery consumption, and so on. This demonstrates the importance of functional and non-functional testing to delivering user-friendly applications.

1. Importance of test foundation

As a new tester, the test foundation is very, very important. The basis here is not only what software testing is and the purpose of software testing, but also the ability to design test cases.

Due to my work, I have recently met many test students who graduated 3 or 4 years ago, or even 7 or 8 years ago, and they still stay in the theoretical stage of use case design, which makes people unable to make fun of them.

Question: What are the testing methods for software test cases?

Answer: equivalence classes, boundary values, cause-and-effect diagrams, etc.

Problem: A common approach to test case design in the context of a real business scenario.

Answer: Many of the replies are explained by logging in.

In fact, there are only a few use-case designs commonly used in daily work. If we can apply the theory to practical work well, it is easy to get a salary increase.

So how do you design good test cases? Business, business, business, three important things.

It is very important to design use cases in combination with actual business scenarios. The use cases not only involve the current functions, but also need to take the upstream and downstream related businesses into consideration and cover as complete as possible. Here is to give you a special introduction ~

Two, improve the database processing capacity

As a qualified tester, the addition, deletion, and associated query of the database are required subjects. But for new testers, this seems a bit difficult, many people tend to focus on appearances before doing things.

For example: click save, submit save, then whether to judge the save function is normal?

The correct way is that we must go to the database to check the data falling into the database and confirm whether the field values are stored correctly. It involves the function of business association, and we also need to go to the database to further confirm the accuracy of the data. Be aware of where your business data is going.

Three, have the ability to locate the problem

In the process of testing, we often encounter interface error, abnormal error information and other situations. As a new tester, your first instinct might be to throw it at the developer: “Hey, buddy, you got a mistake here.”

But when the developer asks, “Is the front end or the back end reporting an error?”

You might be left with nothing but confusion. Because most of the current software is front and back separate. So, what you need to do is learn to read the journal.

Based on logs, you can determine the front-end or back-end problems, including: Using a packet capture tool, you can determine whether the front-end value is incorrectly transmitted or the back-end logic processing is incorrect. And through the initial positioning of the problem, help developers to improve the efficiency of problem solving.

Four, have summary ability

As new testers, we need to summarize more.

Blogger asked a recent graduate of colleagues, he has its own summary way such as: through the x – mind comb summary/grooming business, will record the problem of processing method, also form their own experience in testing work, and will share his way into the team, the members in the company is growing very fast, because of outstanding performance, get a promotion.

As a technical student, the ability to summarize is very important. In daily work, we would step on a variety of holes, summarize the problems encountered, form experience and share it with others, so that we could stand out more in the competition. In the future work, we can sometimes look at them and have different harvest each time.

5. Timely capacity improvement

The eternal topic of technical personnel: the promotion of technical level.

New people grow very fast in the early stage, so they can think more in the testing process, and think about whether there is a better way to solve problems when they meet.

Before I heard that many new mentality is more impetuous, always want to use automation to solve problems, but their automation test level is limited, do up the problems emerge in endlessly.

You can almost say that you want to run before you learn to walk. Think we can lay the groundwork, do functional testing, and figure out how to do the testing more efficiently/in a high quality way with an understanding of the business.

The blogger thinks that in fact, when some students are dealing with testing work, many times they are automating for the sake of automation. Many automation frameworks have not been applied to work, nor have they produced any practical value, and they have not yet had their own thinking. It is suggested that you can first do a framework, and then introduce a certain thinking, combined with the business to do automated testing.

For example, you can start with tools that are already on the market.

For example: interface test tools such as JMeter/Postman, etc., first through the tools to understand the interface test process and method, and then combined with their own business, found that the current test tools can not solve the problem. Later combined with the business development platform, continuous thinking and practice.

Vi. Test workflow of functional testing

1. Test plan: This plan, I personally think, should be made when the detailed design is decided and the code is written, because I am a big fan of the “start testing early” idea.

A) The test plan is mainly to give some guidelines for the later test work. It should not be written as a plan for the leader to see, but a plan for the person doing the work to see

B) It may include:

  • Test team personnel and division of labor (make sure that the designated personnel are available when defects are defined, test environment is prepared, etc.)

  • Test start and end time (ideally, do not schedule too tight, it is certain to cause delay or incomplete test, but the gap between ideal and reality is set to be large)

  • Test environment configuration (what kind of hardware conditions, whether network, equipment, etc., what address to access the system, access permissions, test data to use, etc., expect and prepare)

  • What to test is clear, here I suggest incorporating a simple test outline into the test plan. On the one hand, the leader can see how detailed your plan is, and on the other hand, the outline can be a good basis for writing use cases

  • How to test to say clear, if only do system test, that must write clear do not do integration test, if need integration test, need to write clear integration order. In addition, if performance, documentation, and other tests need to be carried out, this plan should also be specified. Although this plan is generally for functional tests, if there are other tests, they should also be written and scheduled, and the relevant plans for the tests should also be specified

  • The test end flag (to indicate at what point the test is over, not until all the defects have been found, because that would be 10,000 years), allows defects to remain in the system, we just need to find out how much to leave

2. Test Cases: This document describes the specific test steps

However, in practical application, at least in my project at present, due to time constraints, very few of them are written, and even if they are written, they are hardly used in the test. Most of the projects here are directly tested and checked by my personal experience.

Actually he is very important but I want to say, maybe you don’t need to write very detailed, but definitely need such steps to streamline the train of thought, the stand or fall of this document and the practical level, can determine whether or not you can direct “with the least amount of work (and time), as soon as possible to find as many defects”, wrote this document requires some testing methods theory, Such as equivalence class division, boundary values, this table that table (sweat… Forget)

3. Defect record: It is the most frequently used document in the process of functional testing. It is used to record the defects found in the process of testing

A) This article will also help to analyze the “error cluster” phenomenon of developers, summarize the error prone areas, do more in-depth testing on the parts with many defects, and remind developers to avoid defects

B) Defect record filling Guide:

  • The defect level (severity), generally defined by the company, is used to classify defects found in order to determine the urgency of modification

  • Bug classification: Identifies where a bug occurs, whether functional or performance, effectiveness or other problems, etc., together with the bug level, is used to determine the degree to which a bug needs to be modified

  • Bug status: indicates the current state of the bug, indicating whether it has been handled (closed status)

  • These indicators are generally defined by the company (generally the same criteria) and are used for project measurement

C) Points for attention when using defect records:

  • There are three elements to describing a bug: where, under what conditions, and what kind of problem happened

  • You can describe a bug in terms of screenshots, reference locations, modules, etc. The goal is to allow the developer to immediately reproduce the bug through your description, and even if it does not reproduce, the developer will know where the error is

  • The defect report is done by both the developer and the tester, who urge the developer to fill out the form to test the subsequent backtest

  • If the bug report is filled in while the use case is being executed, the last column of the use case can usually fill in the execution result of the use case. If the use case has an unexpected result, then the problem should be recorded in the defect record. In this case, the number of the use case can be referenced in the defect record

Iv. Test summary report: It is used to report and summarize the execution results of project test work, enumerate and make statistics of relevant test data, compare and analyze the data, that is, the problems existing in the work, to make suggestions for subsequent work, and record the remaining problems, etc

A) Another function of the summary report is to tell the project team members that the system has been tested in accordance with the requirements of the test plan and has met the “test end conditions” described in the test plan, which can prove that the system has reached the quality expected by the test plan

The last

If my article is helpful to you, if you like my blog content, please “like”, “comment”, “favorites” one key three charge oh!