The design of test cases generally starts from the analysis of the requirements design specification, to understand the developer's ideas for designing the project, design requirements, and realized functions (it is best to have a use case, which looks clearer). The W model of software testing requires testing and development to be synchronized. The testing process is started when the design requirements and design specifications are developed. Under normal circumstances, the participation of the test supervisor or team members is required when discussing the requirements design to understand the overall design of the project. Happening. In fact, test cases are generally written in
The real start after the requirements design specification is finalized. Because the content of the test case should be based on the requirements design specification, the functions not reflected in the design specification do not need to be reflected in the test case.
To write a test case (here refers to the preparation of a functional test case), the first thing to do is to design a test case template. Each company has a template suitable for its own company's use cases, each with its own characteristics.
The format of the test case includes, test case summary, test case requirement number (a requirement design specification can be divided into several use cases to write), the date of writing the case, the author, the date of writing, preconditions, data preparation, and so on. There is no fixed requirement for the format. You can change the format of the test case according to your own test case design ideas.
Let's take a login window as an example to talk about my ideas and methods for designing the login interface. I divide this test case into a three-tier structure, form testing, logical judgment, and business process.
1 form test
The form test is the lowest level (the most basic). This part of the test case is to test the most basic functions of the input box, button function, and interface of the login window. Generally speaking, the login user name and login user password are embodied in the form of input boxes, so what we need is to test the functions of these two input boxes. At this time, we only need to consider the function of this input box, without considering the content of the business. In this way, we consider what is the length limit of this input box? Can I enter special characters? Can I enter full-width characters? Of course, there are other buttons in the login window, such as login button, logout button, interface design, etc. The test cases at this level only test their simplest functions.
I think this level of test cases is very important for new development projects, and must be executed, because these are the most basic functional guarantees. When the project enters the maintenance phase, if there is no modification, there is no need to perform this part of the test. The priority of the use cases in this layer is set to the lowest, and there is no need to execute them if there is insufficient time.
2 Logical judgment layer
Logical judgment layer. According to the design of requirements, the simple logical connection between each function. Take the login window as an example, account login, account and password must correspond to login, otherwise login fails. Based on this, we can design this layer of test cases from this requirement. For example, when the account and password are inconsistent; when the account is empty; when the password is empty; when the account and password correspond, etc. When entering these conditions, what kind of logic control does the program do? Is the control correct? Is there a corresponding prompt message? In my opinion, the use cases of this layer are the most conventional layer, and some situations that are often encountered when using this software, after routine testing or modification of this part of the function, the test cases of this part must also be executed.
3 business process layer
Business process layer. This part does not care about the basic functions of the software itself, but cares about whether the business of the software is realized. Different needs have different business needs. Taking the login window as an example, there may be different requirements. The user may require the disabled account to be able to log in to the system (may require that other operations are not allowed after login), or the user may directly request that the disabled user account is not allowed to log in to the system. According to different business needs, there are different business processes. For this layer of test cases, we only need to consider the business requirements, and still take the login window as an example, we only need to consider whether the deleted user can log in? Can disabled users log in? How does the super user log in? How do ordinary users log in? To put it simply, the use cases at this level only describe the business process and do not care about how the business is implemented. When performing this part of the use case, do not consider which input box controls how much length, whether you can enter spaces and other functions, because of this part The test needs to be based on the test cases of the above two layers that have been tested, so in the project maintenance phase or the time-critical phase, we only need to execute this part of the use cases to ensure that the business can be completed smoothly. In fact, I personally feel that when implementing this part of the use cases, some obvious problems should be found for the basic function tests. Although strictly speaking, the test coverage is very low, but it can basically meet the requirements.
The combination of these three layers is a complete test case. This is my personal idea and method of test case design. When actually designing this test case, black-box test case methods may be used, such as equivalence class division, boundary value analysis, error guessing method (mainly personal experience), orthogonal decomposition and other methods to design test cases for specific situations . The idea of layered test cases mainly comes from the consideration of automatic test realization. Because I think that if you need to implement automated testing, you must subdivide the test cases. The finer the division, the more conducive to the realization of automation.
The above three-tier division is not very comprehensive, and needs to be continuously improved in practice. For example, it is possible to increase the analysis of data verification of some functions of the database. In short, the test cases are written meticulously, comprehensively, and the steps are clear. Whether it is achieved by manual testing or automated testing, as long as you can run a complete test case, you will achieve the goal of the test.
Software testing exchange group: 785128166
WeChat public account: Programmer Erhei; After paying attention, you can receive a set of video resources for free; explain in detail: python automated testing, web automation, interface automation, mobile terminal automation, interview experience and other related content, the value of learning resources depends on you Action, don’t be a "collector"
Next update: How to write good test cases?
Here is a collection of selected dry goods articles for functional testing: