Talk about test cases

The editor will start from this article to organize all related articles on functional testing, and select them to form a collection for your review and reference. The first article of this issue will be the theory of test cases-talk about test cases

It may be helpful to describe the operation steps of the system test in words

benefit

1) Clear thinking and avoid omissions

  • When the system has many and complex functions, according to each module of the system, split the function points, spend some time thinking and organize them into documents, combine functions and businesses as much as possible, and simulate different scenarios, which fundamentally avoids the "hurry up and running" of directly testing the system. ".

2) Clear test progress

  • With reference to test cases, you can clearly see which use cases are executed and which use cases are not executed, from which you can see where the test is going, and combined with the problem management platform, you can visually analyze the progress of the project from a testing perspective.

3) Defect rate of system modules

  • According to the problems found in the test cases, you can see which functional modules have more bugs.

method

  • Equivalence classification: select the input subset, if the input requires the input of numbers 1 to 10, then enter 4 and 7 to verify;

  • Boundary value: input the maximum value supported. If the maximum value of a text input box is 100, the input content exceeds 101;

  • Causality diagram: Judgment table, judged by causality;

  • Error speculation: based on test experience, speculate in what kind of operation the system may be wrong;

element

1) Directory

  • According to the split system function points, each function point can be distinguished by a directory, such as a system of system management-user management-user addition, then system management is the first-level directory, user management is the second-level directory, and user addition is Three-level directory;

2) Test items

  • Same as above, according to the three-level directory, the general user add includes the user name, password input box, save button, cancel, then each element can be divided into a test item;

3) Operation steps

  • Each test item corresponds to the corresponding operation step, which can be divided into operation step 1 and operation step 2. The operation steps can be refined to the point where you click the button to add a user, enter the username and password in the input box, and click the save button;

4) Expected results

  • Operation steps, before completing a series of actions, there must be corresponding expected results as a reference. This reference is the requirement analysis document provided by the business department at the beginning, and the requirement analysis document tells us what kind of result each function should have;

5) Actual results

  • After the operation steps are completed, the actual situation needs to be recorded. If it does not match the expected result, it can be classified as a bug;

    Consider whether the actual results can be changed into comments to avoid one-to-one correspondence with expected results and decoupling.

6) Priority exploratory testing

  • When designing test cases, it is not completely guaranteed that every function and every scenario is in place, and it is very boring to simply execute the test, so add a little divergent thinking, perform some unconventional operations, and use the system with the mindset of the user , Or "destroy" the system to your heart's content and discover system problems.

  • True exploratory testing requires a deep understanding of the product, as well as a certain depth and breadth of software development technology.

Use case review

After the test case is written, it needs to be reviewed within the test. The content of the review includes: whether the function is complete and whether the requirements are met, so that every tester does not have the deviation of the main thinking during the system test.

At the same time, use case review is also a good learning process. When each tester introduces the system, he can realize the shortcomings of their respective design use cases, including automation and performance, and can conduct technical discussions.

No need for use case

  • The function is too simple
  • The disadvantage of rushing to deliver is that the test coverage cannot be guaranteed.

In this chapter, we have a preliminary understanding of test cases,

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: Should you love or hate test cases?

Here is a collection of selected dry goods articles for functional testing:

Dry goods sharing | Featured article collection of functional tests (Are you afraid that you can't find the article you need?)

Guess you like

Origin blog.csdn.net/m0_52668874/article/details/115128507