Introduction to test Cases

I. What is a functional test case

A test case is a set of test inputs, execution conditions, and expected results that are prepared for a particular goal to test a program path or verify that a specific requirement is met.

Popular speaking: It is the operation of our test system with a certain format in accordance with the text description.

Purpose of the test

We make it do it must be done.

We don't let it do it must not be done.

Perhaps you will find that there is an additional function, that is, the customer did not request, we added such a function, it may add this feature system will look better. What happens then? Is that a problem?

As a developer, the best way to do things, if there are really good features to add, need to communicate with customers, and then write to the requirements. After all, a little more functionality and a little more risk. Oh

As testers, those who do not meet the requirements of the document need to be asked when the problem points. The responsibility is clear, lest the subsequent trouble.

Ii. What are the benefits of writing test cases?

Clear your mind and avoid omissions

Here is what we think is the most important point, if we test the project is large and complex, we can subdivide the project function, according to each function by writing a use case to organize our test system thinking, to avoid missing the function points to test.

Track test Progress

By writing test cases and executing test cases, we are well aware of our testing progress.

Historical references

In our project, there may be many functions are the same or similar, we have designed the test case for such functions, so that we can come across similar functions in the future when the reference.

Repeatability of

We're testing a system that's not a man's test. Even if the test is done and needs to be tested repeatedly, we need a test case to standardize and guide our testing behavior.

Tell the leader, this matter I did, otherwise how other people know you test not test, survey of comprehensive not comprehensive, take test case to them to see Bai! I just follow this work, hehe!

Iii.When can we design test cases

When a project requirements Analysis document is organized according to customer needs, we can write test cases according to the requirements document. However, in general we (most of the domestic small companies) project requirements documents are very "humble", so it is difficult to design test cases according to the requirements of the document.

We only wait until the project developer has developed the project to give us the system documentation, the deployment environment, the database structure (if the system involves a database), we eliminate these documents to design test cases.

Iv. under what circumstances is not suitable for writing test cases

File time

If a feature I finished testing quickly and only need to test once, but we design the test case is more troublesome, take a long time. There is no need to write test cases at this time.

Large and frequent demand changes

The functional changes of the requirements are very frequent and vary greatly, and the test cases written previously are simply not available and must be rewritten, and there is no need to design test cases at this time.

Project time is not allowed

This is a less-than-honest approach, so try not to do so if you are not in urgent need of delivery and, of course, you can supplement and refine your test cases later if you just show or try.

Don't write test cases that are incomplete or not understood by others, and that doesn't make sense.

V. Review and update of test cases

Is the test case design complete after we have designed it? is the system compliant? Meet customer requirements? It is essential to make a review of use cases. There are different processes for different companies on the way to review.

The test cases we write are not changed after the review, and as the requirements change and the functionality is improved, the test cases certainly need to be updated and changed.

Vi. How to write test cases

Equivalence class Partitioning

In a subset of an input field, in which each input data is equivalent to an error in the disclosure program. If there is an input box that requires 1-10000 number, we cannot try each number, we enter 5 and enter 6 to verify and expose the input box errors can be considered equivalent. So at this point we can randomly extract some data for verification. such as: 10, 99, 7777 ...

Equivalence classes: Valid equivalence classes and invalid equivalence classes

input box requires a number of 1-10000

Valid equivalence classes: You can enter a number between 1-10000 to verify, such as: 2, 5, 99, 8495 ...

invalid equivalence class: You can enter any character validation other than 1-10000, such as: 20000, letters, underscores, special symbols, spaces, carriage returns .....

Boundary value

The boundary value is a complement to the equivalence class, and the Test experience tells us that a large number of errors are on the boundary price of the input and output. We also take the example above, where an input box requires the number of 1-10000 to be entered. We're going to test if it's out of this range, such as: 0,-1,-2, 1000, 10001 ... etc., to determine whether it is beyond our scope.

Causality diagram

The final result of the causality diagram method is the decision table, which is suitable for checking the various combinations of program input conditions. For example: The reason:a=0,b=0, the result I can decide: a=b. He is, to be sure, a causal relationship idea. It will invisibly guide this to our testing. Of course, in order to avoid omission, we can draw the causal relation in the system by drawing. But the big and complex system is a physical activity. Oh.

Error-guessing method

Based on experience and intuition, the possible errors of the system are inferred, so that the method of designing test cases is targeted.

Other

There are many ways to design test cases, we often use the above, and other methods are: State migration diagram, process analysis method, positive proof method and so on.

Iv. format and elements of test cases

A test case should include: number, title, test scenario, test step, expected result.

of course, you can also add some of its options, such as: priority, test phase ....

Vii. Exploratory Testing

The complete execution of the test case is a very boring thing, the individual in the execution of the test case will do some, other unconventional operations, to see if the system will have appropriate processing and hints. Part of my bug was found under this unconventional operation.

Of course, real exploratory testing requires a deep understanding of the product and a depth and breadth of software development techniques. Let's think of our exploratory testing as a blind hand! Oh.

Eight, Cross Test

There are wood found, when we first test the system, it will be very serious, but we have to test the second time, we do not want to be as serious as the first time to measure, it does not mean that we are not responsible, but everyone has psychological phenomenon. At this point, we can exchange features with other testers to test, improve efficiency, and make it easier to spot problems.

Nine, stop the standard of software testing .

The minimum statement coverage must not be less than 80%, the test requirement coverage reached 100%, the test case coverage reached 100%, the secondary defect repair rate reached 100%, the 三、四级 repair rate reached 80%.

(The above sentence is again online search, not the standard, just a reference)

Bug level:

First level: Very serious bug

level Two: serious bugs

Level Three: General bug

Level four: Suggested issues

Introduction to test Cases