How to effectively manage Test Cases

I just saw a post posted on the 51testing Forum, saying that I don't have a good idea to write test cases. Are there any good test coverage methods for some complicated functional points, such as advanced queries, do I have to list such detailed test cases? ~~~~ After reading it, I couldn't help but speak. As a tester, designing a test case is my job. If the basic patience of writing a test case is discarded, I 'd like to talk about the test. The developer cannot say that it is difficult to write code. There are no shortcuts to many things, and there is no way to escape things that must be done. Otherwise, we will lose the meaning of our work.

In fact, it was also due to the recent Design of test cases that gave me some reflection. How to design test cases, how to review test cases, and how to manage test cases are all problems that must be improved in our testing work. In the previous company, due to the busy team, we didn't have much time to manage and optimize test cases. Therefore, we did not think much about the use cases, in addition, although there is a review of the use case, I have always thought that it is not doing well. After all, every review, I feel that the effect is not as good as expected, we still don't have enough time to manage it, so we can't pay attention to it. However, now I think it takes a lot of time for me to manage the use cases. In addition, we need to ensure that the test cases should be conducted in an orderly manner. Finally, we need to output the test cases that all the team members think are satisfied and efficient. I personally think that the root problem of case management is classification. How to effectively maintain and optimize use cases requires a clear classification plan in the early stage, the classification can be completed step by step based on the classification priority. At the end, we can also effectively control the test coverage.

Currently, we can divide test cases into three aspects: functions, UIS, and business processes.

1. From the perspective of functionality, functionality is the focus of testing for each project. When testers get the requirement documents, we start designing test cases, at this time, the requirements document lists all functions and some business logic. Therefore, the first stage of the test case is to complete the function case design. However, this will certainly make many people confused. In fact, functions, businesses, and UIS are all associated and cannot be broken down in many cases. Here I will give an example to illustrate it, but it is not always classifier. I just want to talk about how to break it down. The most important thing is not to leave it blank.

2. From the UI perspective, UI usually refers to interface testing. This should not be difficult to understand, but it is not easy to distinguish it from functional points, so Let's explain it intuitively. Ui testing focuses on style, appearance, cleanliness, placement, and ease of use, as well as user experience.

3. From the business point of view, this is relatively easy to understand. A business usually refers to a process connected by a series of actions. This process must have behaviors, objectives, or directions. Business is usually the core of a project or product design. At present, more and more application business processes are very complicated. Therefore, the business case design is to test the business level of a tester.

The following describes how to buy and withdraw a ticket on a securities trading platform:

Business Description: The purchase business includes the stock code, current price, purchase price, number of stocks to be bought, confirm the Buy button, and cancel button;

Withdrawing a ticket includes the unsold services selected for withdrawing the ticket, successful withdrawing of the ticket, failed withdrawing of the ticket, and buttons for canceling the withdrawing the ticket;

The above is just a rough list.

Features: Buy, cancel, withdraw, and cancel

Ui test: stock code, current price, purchase price, number of bought shares, all text boxes; prompt box for successful/failed purchases; prompt box for successful/failed orders; successful withdrawal/failed service status

Business test: the purchase business can be withdrawn from the data in the input purchase form, to the position indicated in the submission form, to the display of the final purchase form, and the order submitted but not closed, after the withdrawal is completed, the withdrawal is successful or fails. This combination of work is a business process.

In fact, there is a controversial issue here. For buying and withdrawing orders, it can be either a functional point or a business logic, but in essence, features focus on separate operations, while business flows focus on a process, and specific businesses need to be screened. The Design of function points mainly applies to the use case design of the button for buying and withdrawing orders. The business needs to be designed from the input before the purchase and withdrawal to the final output.

The above is just a simple description. The specific operation must be performed according to the actual process. After all, the management of test cases is a long-term accumulation and accumulation process, all the good methods are summarized. For testing, use cases are the foundation, and regression testing, automation, and performance are all fundamental. Managing test cases is to improve the quality of testing.