Writing of functional test cases 04/05 Update SLTechnology News&Howtos

Writing of functional test cases

2025-04-05 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

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

Writing of functional test cases

Functional test case

1. The source of the test and the requirements for it

The main sources of test force are:

1) requirements description and related documentation

2) related design instructions (summary design, detailed design, etc.)

3) communicate with the development team on the record of requirements understanding (which can be an explanation of the developer)

4) UI that has been basically formed (can be targeted to supplement some use cases)

In short, try to get all the project documents you can get. Decompose some small "function points" from the moral data, understand the "function points", and write the corresponding test cases.

two。 How use cases are organized

Different companies have different practices. In principle, as long as it is easy to manage and track, you can organize it any way you like.

Use cases can be organized by large functional blocks, such as querying the use cases of functional modules, can be organized together, print test cases of modules, and can be organized separately.

In the absence of a special test case management tool, the use case execution dog produces two states: "pass" and "fail"-plus the "unexecuted" use case state, a total of three states.

That is, after executing a use case from the "unexecuted" use case, the use case status should be "failed" or "passed". Organize use cases in the same state.

As for the use case file format, it can be. DOS or... XLS (if there is a special test management tool, it is another matter)

3. How use cases relate to other materials, and how to solve the problem of use case tracking

Test cases face greater risks: changes in requirements, design modifications, errors and omissions in requirements, and so on.

Since the main source of force is the description of requirements and design, all use case tracking is actually the tracking of requirements and design, changes in requirements and design are bound to lead to changes in test cases.

As mentioned earlier, the function point number that will be decomposed. Associate with the corresponding use case. For example, you can make a table that lists the relationship between each (numbered) function point and the test case pick-up.

In this way, when the requirements and design changes, you only need to track whether the "function points" have changed and whether new function points have been added.

4. The presentation points of a good test case and the information that should be included in the use case

A good test case should contain the following information:

1) name of the software or project

2) version of the software or project (build number)

3) functional module specification

4) A simple description of the test case, that is, the purpose or method by which the use case is executed

5) reference information for test cases (easy to track and reference)

6) the dependency between this test case and other test cases

7) the prerequisites for this test case and the conditions that must be met to execute this use case, such as access to this database

8) the number of the use case (ID), for example, it can be the software name abbreviation-function block abbreviation-NO. .

9) step number, operation step description, test data description

10) expected results (this is the most important) and actual results (this can be omitted if bug management tools are available)

11) developers (must have) and testers (optional)

12) Test execution date

Give an example of a test that already contains a template for a test case.

Project / software

Network Application system for Technology Export contract

Program version

1.0.25

Function module name

Compiling person

Xxx

Use case number

TC-TEP_Login_1

Compilation time

2000.1.1

Related use cases

None

Functional characteristics

User authentication

Test purpose

Verify that legal information is entered, allow legal login, and prevent illegal login

Preset condition

None

Special procedure description

Such as database access

Reference information

Description of "login" in the requirements description

test data

User name = yiyh password = 1

Operation steps

pedagogical operation

data

Expected result

Actual result

Test status

one

Enter the user name and press the Login button

User name = yiyh password is empty

Displays the warning message "Please enter your user name and password"

two

Enter your password and press the Login button

User name is empty password = 1

Displays the warning message "Please enter your user name and password"

three