Shulou(Shulou.com)06/03 Report--

1 purpose

(1) be responsible for the quality of use cases, and the writing of use cases can be orderly and reasonable.

(2) unify the specification of test case writing, provide test designers with guidance for test case writing, and improve the readability, executability and rationality of test cases.

(3) it can effectively improve the coverage of all function points of the system.

2 scope of application

For people: for testers to read and execute. They may also be reviewed or implemented by developers, product managers, project managers, etc., and new employees can be used as a reference for business learning and test execution.

It is suitable for the company to write test cases for testing the business process and function (function point) of the project.

3 Test case 3.1 use case concept

A test case (Test Case) is a set of test inputs, execution conditions, and expected results developed for a particular goal to test a program path or verify whether a particular requirement is met.

3.2 purpose of the use case

(1) to guide the testing work to be carried out in an orderly manner, so that the data for the implementation of the test can be based on.

(2) ensure that the functions achieved are in line with the customer's expected needs.

(3) track the test progress and determine the key points of the test.

(4) Metrics for evaluating test results

(5) the standard for analyzing defects.

3.3 use case granularity Partition Specification

Use case granularity principle: the test case is the smallest entity to execute.

The basic principle of use case division is to divide use cases according to the minimum functional modules. In order to ensure the enforceability and coverage of use cases, the granularity requirements for standardizing and writing use cases are as follows:

(1) A functional process and write a test case

(2) multiple exception flows in a function, multiple test cases should be written separately.

(3) different entrances to the same function can be combined to write a test case.

(4) for different data preparation for the same function, multiple test cases should be written separately.

(5) the automation use case and the function use case of the same function use case should be matched. If the automation use case cannot completely cover the function use case, the automation use case and the function use case should be separated into two complementary test cases.

3.4 content format of the use case

Serial number

Use case name

Abstract

Precondition

Priority

Step number

Operation steps

Expected result

Test result

BugID

Test date

(1) number: use case number, unique identification

(2) use case name: the name of the test case, reflecting the main points of the test; the commonly used structure "subject, predicate, object", the name is simple and easy to understand, do not include specific operation steps

(3) Summary: function points to be tested (system, module functions)

(4) pre-conditions: relevant operations that need to be prepared before test execution, such as test data, role permissions, or login to a page of the system, etc.

(5) priority: the priority of the test case, divided into high, medium and low

(6) step number: the number of the operation step, which is used to import the corresponding test case tool later.

(7) Operation steps: the operation steps required to complete the test point; there are five specific requirements:

1. The operation procedure is described clearly. For example, on which page, which link or button to click; the page entry, link, button name should be clearly written.

2. The operation and the result correspond one to one, but do not include the check of the result in the operation.

3. Conjunctions and prepositions are not allowed in the use case description, such as: and, and (this case can be split into multiple points)

4. Hypothetical words are not allowed in the use case description, such as if, maybe, maybe, … Wait for the time

5. Ambiguous statements are not allowed in the use case description.

(8) expected results: the results of the expected performance of the program after the completion of the operation; there are three specific requirements:

1. In principle, each use case must have the expected result, and the result cannot be empty.

2. Only results can be included in the results, not steps.

3. When there are multiple checkpoints for a result, make sure the checkpoints are complete.

(9) Test results:

Whether it is consistent with the expected result, the Pass is displayed in the actual result (indicates that the use case passed)

Display Failed that is inconsistent with the expected results (indicates a deviation / error in the execution)

(10) BugID: the ID automatically generated in redmine after the Bug is submitted

(11) Test date: the date on which the test case was executed

4 use case design method 4.1 equivalent class division method

Divide all possible input data into several subsets, and in each subset, if any of the input data has the same effect on exposing potential errors in the program, then such a subset constitutes an equivalent class. Later, as long as a value is randomly selected from each equivalence class for testing, a small number of representative test inputs can be used to obtain better test coverage results.

4.2 Boundary value analysis

Select the boundary values of input and output to test. Because a large number of software errors usually occur on the boundary of the input or output range, it is necessary to focus on testing the boundary values, usually selecting values that are exactly equal to, just greater than or just less than the boundary as the test data. From the perspective of methodology, it can be seen that boundary value analysis is a supplement to equivalent class division, so the two testing methods are often used together.

4.3 error inference method

To a large extent, it is based on experience, based on the analysis of the results of the test work done in the past, and intuitive speculation about the regularity of the defects revealed.

5 principles of test case design 5.1 comprehensiveness

(1) the various paths of the program should be covered as far as possible.

(2) the existence of cross-year and cross-month data should be considered.

(3) preparation for concurrent testing of large amounts of data.

5.2 correctness

(1) the data after entering the interface should be consistent with the data recorded in the test document.

(2) the expected results should be consistent with the business of the test data.

5.3 comply with normal business practices

(1) the test data should be in line with the actual business process of the user.

(2) take into account the possibility of various business changes.

5.4 systematic

The main contents are as follows: (1) the business process of the system should be able to fully explain the business requirements of the whole system, the system is composed of several subsystems and the relationship between them.

(2) the module business process should be able to explain clearly the internal functions of the subsystem, the important function points and the relationship between them.

5.5 consistency

(1) for the business process of the system, how the subsystems are connected together, if an interface is needed, whether there is a correct interface between the subsystems; if it depends on the page link, whether the page link is correct.

(2) for the business process of the module, how the peer module and the superior and subordinate module constitute a subsystem, and whether its internal functional interface is coherent.

5.6 Simularity

The names of people, place names and telephone numbers should have analog functions and conform to the general naming convention.

5.7 maneuverability

The test case should write clearly the operation steps of the test and the corresponding operation results of different operation steps.

6 use case Design step 6.1 Test requirements Analysis

Understand the requirements of the project from the project requirements analysis document / summary design / detailed design / prototype diagram. Through the tester's own analysis, understanding, collation into the test requirements, so that the tester can be clear about the functional points contained in the project under test.

6.2 Business process Analysis

Analyze and understand the industry and business knowledge of the project under test. Sort out all the business processes of the project under test (you can draw the flow chart of the project or use brainstorming).

The process of the project: the main line process, the branch process, the data flow, the judgment conditions of the key points in the flow process and some non-necessary conditions to complete the operation.

6.3 Test case design

It mainly includes functional testing, interface testing, compatibility testing, ease-of-use testing, exception testing, performance testing, stress testing and so on. In the design of use cases, we should try to consider the processing of normal, boundary, outlier and other systems.

6.4 Test case review

Initiated by test case designers, participants should include test leaders, project managers, developers, and other relevant testers.

6.5 Test case perfection

After the test case is written, the test case should be maintained continuously:

(1) when the requirements of a new project change, the test cases should be modified in time.

(2) during the maintenance period, the use case can be maintained according to the project team cycle.

(3) all bug and faults found can not be found based on test cases and need to be converted into test cases.

More highlights are in the video course of Brother Yang. Address: http://edu.51cto.com/lecturer/5811414.html

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.