Test Case writing guide

LSupplement the use case.
1. New test ideas or bugs are generated during the test execution phase. If no use cases are covered, add all the use cases within one week after the project is released. Overwrite each bug with corresponding use cases. Supervised by product line owner

LPublic Use Case library.
2. the directory structure of the public use case library should be properly planned to facilitate subsequent project updates. It is best for the product line owner to plan the directory structure in a unified manner.
3. Update the use cases to the Public Use Case library within one week after the project is released, under the supervision of the product line owner
4. Updated to the Public Use Case library within half a month after the release of small demand (considering that there are too many changes to small demand), it is supervised by the product line owner.
5. When updating the public use case library, if you need to overwrite the previous content, back up the previous content first.
6. don't get started with updates because you don't need to update them. In this way, the Public Use Case library will never be used and the update ratio is always better. You can discuss it with the product line owner, how to better update it.
7. Learn to use the public use case library and get a task to write the case. Do not write it yourself from start to end. You can refer to the Public Use Case library for reference, especially for some common functions.
8. When updating the use case library, you need to have a log record in the analysis of each major module. The following format can be referenced. (QC version management may be used in the future to replace manual logs for evaluation)
 Latest modification:
Modify the 01_xxx Module
Added the 02_xxx module.
Delete the 03_xxx Module
 Source:
XXX project or XXX small demand
 Modified/Time:
Xxx/XX-xx

LTemplate use case:
9. What is a template use case? The minimum granularity and complete function points can be repeatedly called by the use case and can be extracted and written as a template use case.
10. What types of use cases can be written as template Use Cases: page check, entry check, field check, field query check, shared Function Points, database check, etc.
11. the template use case also needs to be tested and analyzed. It mainly refers to the checkpoint of this template use case. If this template is parameterized with regular meetings, list the parameterized situations in the analysis, in the called test cases, the common checkpoints do not need to be repeatedly written.
12. We require that the template use case be fine-grained, but it is also a complete functional point. You do not need to split each step of the function point into a module use case.
13. Do not write the expected result in the step of calling the template use case, so that the execution of the use case is invisible.
14. The template use case should be written in the template use case folder and should not be mixed with the execution case.
15. Do not call a template again. The structure is too complicated and difficult to understand.
16. The template use cases in the same project can be continuously called by the test cases of the project
17. If you want to use the template use cases in other projects, copy the template use cases to this project as much as possible;

LTest lab:
18. the principle of case division is basically divided by functional modules. However, the test lab can adjust the order of cases from the perspective of ease of use case execution or in the order of business processes, you can also put the data preparation examples that can be done together in a test set.

LData Preparation
19. Data preparation in the use case should not only write data field values, but also write the conditions in the business process.
20. In addition to writing data that meets the XX condition, data preparation must also meet the XX condition. Otherwise, the data generated may be inaccurate:
21. To verify a function, you need to prepare a batch of data. Some students only write data, but do not write why you need to select this batch of data.
22. For complex data preparation, it is best to write SQL or stored procedures to facilitate reuse.

LDatabase related:
23. Check the data value not only whether the page is displayed consistent with the database, but also whether the database value is correctly calculated.
24. Check the database for all features that cause data addition, modification, and deletion.

LPage check:
25. During the page check, the division of each element by equivalence class should be covered by examples.
26. The demo is often written during page check. Please attach the demo as a step attachment. You can see it during case execution.

LFunction check:
27. Use cases should be considered in terms of operation success and operation failure. Then
28. For Use Cases of the Interface Class, check whether the data is consistent, correct, and the data of each field is the longest, shortest, various types, and data processing rules.
29. The Use Case Division principle is basically based on functional modules. However, a complete Use case must be provided for the entire business process.

LIncrease the use case coverage rate:
30. modify a small function point in a function module, or add a small function point in a function module. You need to confirm the regression scope, instead of testing this small feature.
31. For a function, there are many entries that need to be covered in the use case.
32. For a role that has many functions and is not applicable, You need to overwrite these roles in the use case.
33. When a function has multiple roles, consider the situation where a user has multiple roles.
34. Check the default value of the Form. Do not miss it.
35. You need to check the status that is opposite to the functional points on demand. For example, if a paid member has function A, you must also check that a free member does not have function.
36. For a series of system tasks, in addition to a single task check, you also need to check according to the online execution order.
37. the use case must overwrite the input correct data and generate the correct (expected) output, and overwrite the input illegal data (illegal data type, non-conforming data, and overflow data). Can you give a prompt, and perform corresponding processing.
38. For features with limited permissions, You need to test whether the system's permission control has taken effect.

LIncrease the readability of use cases:
39. A top-down analysis folder at the level of level 1 often repeats content. Avoid duplication as much as possible. Otherwise, it will bring a lot of maintenance work in the future. The analysis of the upper-level folders mainly refers to the idea of how to divide the lower-level folders and the common check points of the lower-level folders.
40. there is an error message on the front-end page. The specific text must be reflected in the use case, which is also a checkpoint. The error message on the back-end page is intended for internal users, unless otherwise specified.
41. The operation steps and expected results of the use case should be clearly distinguished. The expected results cannot be written in the desired results, but one step causes multiple expected results. The expected results can be written together, if multiple steps cause one expected result, the multiple steps can also be written together.
42. The check method in the use case must be operable
43. many people think that the test steps of the use case are very detailed and do not need to be written in the test analysis of the use case. However, the two are different, test Analysis of use cases reflects your checkpoints, and the steps involve more specific operation steps.
44. The entire process of the use case step needs to be complete and executable, such as the build operation and background review, which must be written to the step.
45. the granularity of use cases should be fine. Do not mix multiple function points in a single use case, or mix multiple situations in a single function point. For example, adding a record is usually divided into many scenarios, each case is a use case, rather than mixing each case into a use case.
46. exception checks, such as network transmission exceptions and interface call failures, need to be written in the case to achieve this exception. This requires a consensus with development when writing the case.
47. the directory structure of case division should be clear, and the name should be able to summarize the directory or case. The common structure is: Role + Action + can distinguish the ID of case, if an element does not exist or already exists, remove it.
48. For test analysis, each word in the test procedure must be accurately and unambiguous. Do not use the following words in the use case:
Correct data; wrong data; If; or; not processed by the system; matched by rules; "XX at most, how much is displayed for less than xx"

LOther considerations:
49. For test and analysis, please write in a uniform template format, beautiful and unified, and add points to the use case.
50. when two people jointly write a project's use case and the allocated module is interactive, they must first fully communicate with each other, who will write the public content, and determine the scope of each person's writing, start again.
51. There will be no issues to be confirmed in the use case. If such a problem is encountered, first communicate with the need for separate development. Do not wait until the TC review to confirm the problem.
52. Some points are out of the test scope, and some points cannot be tested. This should also be stated in the test analysis. We will tell the relevant personnel that we will not test these points.
53. if you want to call functions of an existing framework, such as page turning on the background page and top-to-bottom functions, you can skip the test, provided that relevant personnel check whether the existing framework is called, of course, use cases should also be covered.