Test case and bug description specification reference

Catalog

One 、BUG Describe the basics

Two 、 Use case design basics

---

One 、BUG Describe the basics

1. Bug The title should include Bug The specific location of the and 【】 mark give an example ：【 modular - Sub module - page 】XXXXXXXXXXXX

2. Bug There must be no typos in the title The wrong sample ： Run away （ collapse ）, electric shock （ Click on ）, land ,（ Sign in ）, Reset （ Recharge ）, reality （ Show ）

3. When found Bug When the precondition is empty , Need to fill in none . Under special conditions Bug Must describe in detail the generation of Bug The premise of . Example ： Only use the pictures in the attachment （ Big picture ：60M） when , This Bug.

4. The page switching in the description reproduction step is to avoid unclear description or ambiguity , need “->” Symbolic connection The correct sample ：（ home page -> my -> My order -> Did not pay , Click on an unpaid order , Go to the order details page ）

5. In the process of description Error prompt class Bug Use quotation marks , There must be no situation that cannot be described clearly .

6. Bug The screenshot included in the attachment of the shall be marked with corresponding red box , Easy Bug The positioning of .

7. The proposed Bug The name of the attachment should be the same as Bug The title echoes , There should be no odd or verbose names . The wrong sample ：QQ video 20168377894872.MP4

8. Bug The video attachment in the shall adopt MP4 Format , No non - Mp4 Format video

9. Description Bug There must be no imprecise words in the process , This can lead to Bug The description is not clear , There is no way to reproduce Bug

   • Example 1： Several times in a row , Click the , Long time sliding up and down the screen and other vague expressions

   • Example 2： Wait a while after entering the page . Click again XX Key .

   • Example 3：APP collapse , Cell phone crash , System crash ,APP restart , Such expressions as restarting the mobile phone are confused .

10. describe Bug In the process “ Expected results ” And “ The actual result ” Must be organized and logical .

11. Crash Of Log Try not to take longer than 10 minute .

12. Bug Screenshot 、 video 、Log And the description needs to be with Bug The content must be consistent with .

13. During the delivery process, it is necessary to propose Bug The contents shall be sorted out and classified without obvious repetition Bug.

              

Two 、 Use case design basics

1. Before use case execution , A rigorous test plan is required , And half a day of internal audit time must be set aside in the test plan .

2. The test case description shall be strictly followed during the execution of the use case , Prescribed prerequisites 、 input data 、 step , Check the actual results , The authenticity of the test results must be ensured .

3. When problems are found during use case execution , Record complete information , Such as ： Test the phone model 、 Operating system version 、 Test network 、 Standard supporting documents （ video 、 picture 、Log file ）.

4. The execution case is not Pass The use case of must add detailed remarks ,Fail Use cases must be added BugID; Because of some Bug Or the lack of test conditions makes the use case impossible to execute , Marked as Block Add notes ; The function module is not well designed , Or use cases that are not applicable to this round of testing , Marked as N/A Add remarks .

5. The test case that cannot be executed appears in the execution case , Or when there is no test data , Must communicate with customers in a timely manner , It needs to be confirmed by the customer before handling , If you cannot fill in the notes independently, do not execute .

6. In principle, the execution case is the same Bug Can only Fail A test case , In other test cases , If this exists Bug, But it doesn't affect the test , Cannot skip not executing .

7. The test progress in the execution case must be executed in strict accordance with the test plan , If there is an irresistible factor , Can't finish the task on time , Must communicate with customers in advance , Only with the consent of the customer can the extension be made .

8. The test cases in the design cases are written according to the unified template , And agree on how to use the template .

9. When the test case in the design case begins to be designed , A complete design plan must be prepared , List the functional sub modules to be covered , And the approximate number of use cases of each sub module .

10. The use cases in the design use cases shall be written in strict accordance with the requirements specification and the functional analysis points of the test requirements , It is required to cover all required function points .

11. The test case design in the design case is clear , The description is correct . Use case name ： Describe the purpose of the test case . The use case must clearly describe the prerequisites for this use case . The test case should be written with clear steps , Input and output elements are clear , And clear without doubt . Decidability of test case results ： That is to say, the correctness of test execution results can be determined , Each test case should have corresponding expected results which can be verified .

12. The granularity of test cases in design cases must be reasonable , Uniform coverage of test requirements , The fundamental degree is ： Verify a function point （ There is no operation on the same page , The overall page check is a function point ） A use case , No repetition 、 Redundant test cases .