How to write test cases

Question 1: How to write software test cases? Suggestions for writing software test cases are as follows:

1. The name of the test case, also known as the title of the test case, must be written concisely. It is necessary to describe the starting point and focus of test cases in common language, so that testers can understand the purpose of test cases at first sight. Generally, it is required that there should be no hypothetical statements in the use case name. In principle, the name of each use case cannot be repeated.

2. The preset conditions should be clear, including test environment, test data and test scenario. Because many bugs can only be reproduced in specific environments and specific scenarios. Without the correct preconditions, the following test steps cannot be carried out or the expected results cannot be obtained.

3. The description of the test steps should be simple and clear, and the description of each step should be clear, such as: Step 1, enter the user name; Step 2, enter the login password; Step 3, the user clicks Login. The steps are clearly written, which helps to improve the operability of the use case.

4. The expected result of the use case should be complete and clear, and the output result should be written, including the content of the return value, the records of relevant fields in the database, the response results of the interface, the rule compliance of the output result, the check of logs and the check of other business impacts.

5. Test case levels should be clearly divided, so that test execution can be divided into primary and secondary levels.

6. The division of test cases should also be single, and a test case only checks one situation of function points. There are too many use cases in a use case, which will lead to unclear purpose of use cases. In addition, organizing use cases in this way is beneficial to the statistics of demand coverage. It is clear at a glance what we have tested at a function point and which function points we have paid attention to.

Question 2: How to write a good test case For a piece of software, the suggestion for writing a good test case is: 1. The name of the test case, also known as the title of the test case, must be written concisely. It is necessary to describe the starting point and focus of test cases in common language, so that testers can understand the purpose of test cases at first sight.

Question 3: How to write test cases? I want to know the specific model. Thank you. Let's assume. Now you are required to test Baidu's known submit and answer functions.

Use case number: submit the question 00 1 (the number is generally written according to the function or module).

The purpose of the test is to verify whether the user can submit the answer normally after answering the question. (Most of them will write a requirement statement, in short, let people know what you want to test in this use case. )

Test title: This sometimes includes the test purpose and can be omitted, but the test case title is necessary.

Importance level: most use cases such as submission and answer will be listed as the highest level use cases, because this is the most basic function. Often the more basic, the higher the level. The reason is that if the basic function is defective, you don't need to test other functions at all and return to the version directly. Prefabrication condition: 1, Baidu knows it works normally. 2. The user has logged in. 3. Go to the question page you want to answer. (That is, you must have a prerequisite before doing this test)

Operating steps: 1. Click the cursor in the input field under "Let me help him answer".

2. Enter the answer you want to submit.

3. Click Submit to answer.

4. Verify whether the submitted answer can be displayed under the current question.

(Most of the input data is incorporated into the operation steps, for example, the input data in this article is the "answer")

Expected result: 1 After clicking Submit Answer, the page prompts that the answer is successful. When you look at the question again, the answer just now can be displayed correctly. ...

Question 4: What are the methods of writing test cases? Hello!

1. equivalence class

2. Boundary value

3. Wrong speculation

4. Causality diagram

5. Decision table

6. Orthogonal test

7. Logic diagram

Wait, personally, I think the first three are most commonly used, and orthogonal tables are occasionally used!

Complex business may use causality diagram!

You can refer to: 360doc/....shtml.

Question 5: How to write test cases efficiently? The design and execution of test cases is the core of test work and one of the biggest tasks.

At present, there is no classic definition of test cases. Generally speaking, it refers to the description of a specific software product testing task, which embodies the testing scheme, method, technology and strategy. The contents include test objectives, test environment, input data, test steps, expected results, test scripts, etc. , and form a document.

Preparation of test case writing

1

Apply to the configuration administrator for software configuration: requirement specification and design specification;

2

According to the requirement specification and design specification, learn the real needs of users in detail, have an accurate understanding of the functions realized by the software, and then set about making test cases.

Principles of test case formulation

1 The test case should include the functions to be tested, the data to be input and the expected output results.

2 test data should be as complete as possible, with a small amount of effective test data.

Use case coverage

1 correctness test: input the actual data of users to verify that the system meets the requirements of the requirements specification; The test points in the test case must first ensure that at least all the functions in the requirement specification are covered and are normal.

2 Fault tolerance (robustness) test: the program can receive correct data input and produce correct (expected) output, and input illegal data (illegal types, unqualified data, overflow data, etc. ), and the program should be able to give hints and handle them accordingly. Imagine yourself as a customer who knows nothing about product operation and is doing any operation.

3 Integrity (security) test: the attempt of unauthorized people to use the software system or data, the degree to which the system can control, and the data processing of the program can maintain the integrity of external information (database or file).

Interface testing: testing the coordination and communication between modules, the consistency and correctness of data input and output.

5. Pressure test: enter 10 to record the operation of various functions, 30 to record the operation and 50 to record the test.

6. Performance: whether the predetermined function is completed and the running time of the system (mainly for the database).

7 Understandability (operability): the difficulty of understanding and using the system (friendly interface).

8 portability: operability under different operating systems and hardware configurations.

test method

1 boundary value analysis method: determine the boundary conditions (just equal to, slightly less than, slightly greater than, just greater than the equivalent boundary value), and mainly input some legal data/illegal data in the testing process of our system, and mainly select the vicinity of the boundary value.

Equivalence division: divide all possible input data (valid and invalid) into several equivalence classes.

3 error speculation: mainly based on test experience and intuition, refer to the errors of previous software systems.

Fill in the test case

1 A software system or project shares a complete set of test cases. After the whole system test process is completed, the actual test results should be filled in the test case, and the operation steps should be as detailed as possible. Test conclusion refers to the final test result (conclusion: pass or fail).

Question 6: How to write a complete and comprehensive test case 1 Principles of writing test cases

There is no doubt about the importance of test case, which is the core of the whole process of software testing and the basic basis of test execution. Principles for writing test cases:

1. Test cases should cover the function points of the software system to the maximum extent. After the test plan is written, the test engineer should write test cases in the development stage, refer to the requirement specification and software function points, and refine the operation of each function point to achieve the maximum requirement coverage as much as possible.

2. Test cases should have accurate definitions of test function points, test conditions, test steps, input values and expected results.

3. The design of test cases should include various types of test cases. When designing test cases, we should not only meet the basic functional requirements of the system, but also consider various abnormal situations, boundary conditions and the ability to withstand pressure.

4. Management of test cases. Use the test case management system to manage test cases.

A good test case should have a high probability of finding an undiscovered error, while a successful test case can find an undiscovered error. Usually, a good test case has the following characteristics:

1, there is a high probability of finding an error.

2. There are no redundant tests and redundant steps.

3. Testing is the "best category"

It is neither too simple nor too complicated.

5. The case can be reused and easily tracked.

6. Ensure that the system can meet the functional requirements.

Test cases can't be designed seamlessly, and can't completely meet the coverage of software requirements. During the test execution, some test paths or data will definitely not be reflected in the use case, so they should be added to the use case library afterwards to facilitate other and subsequent versions of the test.

Second, how to write test cases

There is a lot of information in the test case, which can be added or deleted according to the actual situation. Generally speaking, an excellent test case should include the following information:

1, product related information

(1) Software product or project name

(2) Version of the software product or project

(3) Name of function module

(4) Function description

(5) Test platform

These information suggestions can be selected manually in the test case.

2. Basic record information

(1) Test Case Checker

(2) Test case warehousing time

(3) Test case updater

(4) test case update time

These information suggestions can be automatically generated by test cases.

3. Properties of test cases

(1) test case ID: the ID of the test case (automatically generated by the case management system to facilitate tracking management).

(2) test case name: the name of the test case

(3) Test function point: the function checkpoint of the test.

(4) Test purpose: Test purpose of test function point.

(5) Test level: main path test, smoke test, basic function test and detailed function test.

These test levels are described below:

A. Main path test: Compared with the most important functional path of important modules and functions in requirements, the main path test is a test case, which is the main basis for designing probe modules and quickly checking the testability of programs (testability also includes whether the installation test is successful).

B. smoke testing: Compared with the main functional paths of all modules in the requirements, the main path test cases are a subset of smoke testing's use cases, and smoke testing is the main basis for regression testing.

C. Basic function test: According to the requirements and the basic function paths of all modules and functions in the overall design, basic function test is the main basis for testing non-important modules of software products and writing complete automated test scripts.

D detailed functional test: according to the functional paths of all modules and functions in the overall design, test all modules and functions at all levels and types. Detailed functional test cases are the main basis for key modules and error-prone modules.

(6) Test types: function test, boundary test, abnormality test, performance test, stress test, compatibility test, safety test, recovery test, installation test, interface test, start/stop test, document test, configuration test, reliability test, usability test and multilingual test.

(7) Preset conditions: explain the special conditions or configuration of the test.

(8) Test steps: describe the test process in detail, and the recommended operation steps are less than 15.

(9) Expected results: expected test results.

Third, the test case design process

For a brand-new product, the first thing to understand is the relationship between product requirements documents and product modules. Then you need to write the main path test cases and smoke testing test cases corresponding to all requirements in the requirements document. At this moment ... >>

Question 7: How to write a unit test case 1? The concept of unit testing

In layman's terms, a unit refers to a function that realizes a simple function. Unit testing is to test whether the function is normal and return the correct output when there is only a specific set of inputs (test cases).

Coverage type of test

1. statement coverage: statement coverage is to design several test cases and run the program under test so that each executable statement can be executed at least once.

2. Judgment coverage (also called branch coverage): design several test cases and run the program under test, so that each judged true branch and false branch in the program is executed at least once.

3. Conditional coverage: design enough test cases and run the tested program, so that every possible value of every condition judged in the program is executed at least once.

4. Judgment condition coverage: design enough test cases and run the tested program, so that every possible value and every possible judgment result in the program can be executed at least once.

5. Conditional combination test: design enough test cases and run the program under test, so that all the conditional value combinations judged in the program are executed at least once.

6. Path testing: design enough test cases, run the tested program, and cover all possible paths in the program.

The use case design scheme mainly includes: conditional test, basic path test and loop test. Through the above method, the logic coverage and path coverage of the program by test cases can be realized.

Second, the preparation before the start of the test

At the beginning of the test, we should declare that no matter how many test cases you design and how perfect your test scheme is, it is impossible to find all bugs completely at 100%. What we have to do is to do the most tests with the least resources, find a balance point and ensure the correctness of the program. A thorough test is impossible. So now I choose the basic path testing method commonly used in unit testing.

Third, start testing.

Basic path test method: The test case should be designed to ensure that each basic independent path is executed at least once.

Function description: when I _ flag = 0; Returns i_count+ 100.

When I _ flag = 1; Returns i_count * 10.

Otherwise i_count *20 is returned.

Input parameters: int i_count,

int i_flag

Output parameter: int i _ return

Code:

1 int test (int i_count, int i_flag)

2 {

3 int I _ temp = 0；

4 while(I _ count & gt； 0)

5 {

6 if (0 == i_flag)

7 {

8 I _ temp = I _ count+ 100；

9 broken;

10 }

1 1 other

12 {

13 if ( 1 == i_flag)

14 {

15 I _ temp = I _ temp+ 10；

16 }

17 others

18 {

19 I _ temp = I _ temp+20；

20 }

2 1 }

22i _ count-；

23 }

2 1 }

22i _ count-；

23 }

24 return i _ temp

25 }

1. Draw the program control flow chart.

The number in the circle represents the line number of the statement. Maybe someone will ask why 4, 6, 13, 8 ... are all selected as nodes, and what is not a node in the second and third lines, because the selection of nodes is regular. Let's watch the program; Lines 2 and 3 are executed in sequence. The loop operation does not appear until line 4. But there is no judgment in lines 2 and 3, so we choose equal branch operation, so we combine all 2, 3 and 4 into one node. Others are merged according to this rule, and the above flow chart is obtained.

2. Computational cycle complexity

With the chart, we need to know how many test cases we have written to meet the basic path test.

A new concept-cyclomatic complexity has emerged.

Cyclic complexity is a software metric, which provides a quantitative test of program logic complexity. This metric is used to calculate the number of basic independent paths of a program. Make sure that all statements are at least ... >>

Question 8: How to write the design experience of test cases? Firstly, test types are divided, then test modules are designed according to data flow, test checkpoints are sorted out, and finally some strange test cases are designed.

Question 9: How to write the test case 1, enter the correct mobile phone number and click to get the verification code. Expected result: The mobile phone receives the verification code.

Use case 2, enter the wrong mobile phone number and click to get the expected result of the verification code: prompt to enter the correct mobile phone number.

Use case 3, enter English letters and click to get the expected result of verification code: prompt to enter the correct mobile phone number.

Use case 4, enter special characters, and click to get the expected result of verification code: prompt to enter the correct mobile phone number.

Use case 5, enter extra-long characters and click to get the expected result of verification code: prompt to enter the correct mobile phone number.

Use case 6, enter the correct verification code, and click OK to determine the expected result: verification passed.

Use Case 7: Enter the wrong verification code, and click OK to confirm the expected result: if the verification fails, you will be prompted that the verification code is wrong.

Use case 8: Enter the verification code of special characters, and click OK to confirm the expected result: if the verification fails, you will be prompted that the verification code is wrong.

Use case 8: Enter a long verification code, and click OK to confirm the expected result: the verification fails, prompting that the verification code is wrong.

Handmade, forget to use, you can contact 854 155 14 1 to continue communication.