Simple introduction to test cases-for new testers

Before that, I collected some knowledge about test cases. Later I made a special discussion in our QQ Group to discuss test cases. After all, this is a big topic, it is difficult to cover all aspects, but I will try to be as comprehensive as possible to use test cases in plain language.

Bytes ---------------------------------------------------------------------------------------

Note: The test cases here refer to functional test cases.

1. What is a test case?

A test case is a set of test inputs, execution conditions, and expected results prepared for a specific purpose to testProgramPath or verify whether a specific requirement is met.

In layman's terms, the operation steps of the test system are described in text in a certain format.

2. What are the advantages of writing test cases?

• Clear your ideas and avoid omissions

Here is what we think is the most important. If the project we test is large and complex, we can divide the project functions, based on each function, we can organize our ideas for testing the system by writing test cases to avoid missing functional points to be tested.

• Tracking Test Progress

By writing test cases and executing test cases, we can clearly understand the Test Progress.

• Historical reference

In our projects, many functions may be the same or similar. We have designed test cases for such functions to facilitate reference when we encounter similar functions in the future.

• Repeatability

If we test a system that is not tested by a single user, we need to perform tests repeatedly. Therefore, we need test cases to standardize and guide our testing behavior.

• Tell the leaders that they have done this. Otherwise, how can someone else know that your test is not complete and the test is not comprehensive? Show them the test cases! I am working like this, huh, huh!

Iii. Test Case Methods

Well, I know what a test case is. I also know why I want to write a test case. How should I write it? No way to start. Before writing test cases, we should first learn several methods, which are the guiding ideology for writing test cases.

1. Division of equivalence classes

In a subset of an input field, each input data in this subset is equivalent to exposing errors in the program. If an input box requires 1-numbers, we cannot use each number for testing. We can enter 5 and 6 to verify and expose the errors in the input box. This is equivalent. In this case, we can randomly extract some data for verification. For example, 10, 99, 7777 ......

Equivalence Class: Valid equivalence class and invalid equivalence class

Enter 1-in the input box.

Valid equivalence class: You can enter a number between 1 and 8495 for verification, such as: 2, 5, 99 ......

Invalid equivalence class: You can enter any character other than 1-20000 for verification, such as, letters, underscores, special characters, spaces, and carriage return .....

2. Boundary Value

The boundary value is a supplement to the equivalence class. The test experience tells us that a large number of errors are caused by the input and output boundary price. We also take the example above. An input box requires the number between 1 and. We need to test whether it has exceeded this range, for example, 0,-1,-2, 1000, 10001... and so on to determine whether it has exceeded our range.

3. Cause and Effect

The Cause-to-cause method generates a discriminant table,It is suitable for checking various combinations of program input conditions. For example, the reason is: a = 0, B = 0, and I can determine that a = B. Specifically, he is a causal relationship. It guides this test virtually. Of course, in order to avoid omission, we can draw the causal relationship in the system. However, if the system is big and complex, it is a physical activity. Haha.

4. incorrect estimation

Based on experience and intuition, the system may have errors, so as to design the test case method.

5. Others

There are many methods to design test cases. We usually use the above methods. Other methods include status migration diagram, process analysis method, orthogonal verification method, and so on.

 

Iv. Format and elements of Test Cases

A test case should include:Number, title, test scenario, test procedure, and expected results.

Of course, you can also add some options, such as priority, test phase ....

Note: The above format is taken from the software test path of Microsoft. It is not necessarily suitable for you. I just want you to understand the test format.

Storage and management of test cases:

1. Use Case management provided by the project management system. It is generally linked to projects by regular meetings. It has fixed formats, search, modification, and other functions, making it very convenient to use. Examples of management functions such as Zen road project management, QC, and bugfree are provided.

2. Manage the test cases in the form of world \ Excel documents. The advantage is that you can customize the test case format.

----------------------- Test case example --------------------------------------------------------

The basic knowledge is almost the same. Let's take a look at a specific test case. We will have a deeper understanding.

Note: This is not a complete test case, and the format is not fixed. You can write design test cases as needed.

========================================================== ========================================

---------------------------------- We also need to know about the test case -------------------------------

I. When can we design test cases?

When the project requirement analysis documents are compiled according to the customer's requirements, we can compile test cases according to the requirement documents. However, generally, our (most small companies in China) project requirement documents are "simple", so it is difficult to design test cases according to the requirement documents.

We only need to wait until the project developer develops the project, and give us the system documents, deployment environment, and database structure (if the system involves a database). We will reject these documents to design test cases.

Ii. Review and update Test Cases

After the design of the test case is completed, is it complete? Does it comply with the system? Meet customer requirements? It is essential to make a review of the use case. Different companies have different processes for review.

The test cases we have compiled do not change after review. As the requirements change and functions improve, the test cases also need to be updated and changed.

Iii. Under what circumstances is the test case unsuitable?

• File time

If a function is tested quickly and only needs to be tested, it takes a long time to design a test case. At this time, there is no need to write test cases.

• Large and frequent demand changes

The required functions are frequently changed and greatly changed. previously written test cases cannot be used at all. You must re-compile them. At this time, you do not need to design test cases.

• Project time is not allowed

This is not a good practice. If you do not need to deliver the customer urgently, try not to do so. Of course, if you only want to show the customer or try it out, you can supplement and improve the test cases later.

• Do not write incomplete or incomprehensible test cases.

============== Personal chat content, welcome to correction ============

4. Standards for stopping software testing.

Statement overwrite must be at least80%, The test requirement coverage rate reaches100%, The test case coverage rate reaches100%, Level 1 and level 2DefectsRepair rate reached100%, Level 3 and Level 4 repair rate reached80%.

(The above sentence was found online again. It is not a standard, but a reference)

Bug level:

Level 1: Very serious bugs

Level 2: serious bugs

Level 3: General bugs

Level 4: Suggestion

5. exploratory testing

It is a very boring thing to fully execute test cases. When executing test cases, I will do some other unconventional operations to check whether the system will handle and prompt accordingly. Some of my bugs are found in this unconventional operation.

Of course, the real exploratory test requires a deep understanding of the product and a certain depth and width of the software development technology. Let's take our exploratory test as a trick! Haha.

Vi. Cross-test

It was discovered that when we tested the system for the first time, it would be very serious. But when we wanted to test the system for the second time, we did not want to take the test as seriously as we did for the first time, this does not mean we are not responsible, but the psychological phenomenon that everyone has. At this time, we can exchange functions with other testers to test, improve efficiency, and more easily detect problems.

VII. Purpose of the test

1. what we make it do must be done.

2. we won't let it do what it has to do.

You may find that when there are additional features, the customer has no requirements. We have added such features, and the system may look better. What should I do? Is it a problem?

As a developer, it is best to do things in a regular manner. If there are really good functions to be added, you need to communicate with the customer and then write them into the requirement. After all, a little more features and a little more risks. Haha

As a tester, any document that does not meet the requirements must be raised as a problem. Clear responsibilities to avoid future troubles.

----------------------------------------------------

Modify:

1. Remove "actual results" from the elements of the test case format"

2. Interpretation of the test method "equivalence classification.

Thank You For Your correction. :)