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

1. This specification is a guiding document for project software testing, which generally standardizes the test theory, test type, test method, test standard and test process involved in the software testing process. in order to effectively ensure the quality of software products. Project software testing is a means of controlling software design and a means of checking and auditing the quality of software products. Project testers should check and test the software according to the requirements of this specification. two。 Test objectives (1) testing is the process of executing a program in order to find errors in the program; (2) good test cases are likely to find errors that have not been found so far; and (3) successful tests are tests that find errors that have not been found so far. 3. Software testing process

Without rules, there is no square, to do a good project is to do the right thing, and to handle things correctly can improve efficiency. After receiving a new project, the testing department needs to gradually carry out the testing work according to the following five processes, which can be supplemented and improved according to the actual situation.

3.1. Test reference documentation

After the testers have done their work, they need to use the documents provided by the product personnel and developers, which can provide a basis for the testing work. Specific reference documents include: product requirements specification, product design prototype, database design scheme, code specification of development department, developer (front-end and background) task allocation table, and so on.

3.2. Test work flow chart

The basic flow chart of the test work is shown below:

4. Software testing method

According to the needs of the project, functional testing and performance testing are mainly carried out. At present, functional testing is mainly used, and the most commonly used testing methods are equivalent class division method, boundary value analysis method and error inference method. All three are the most commonly used, typical and important black box testing methods. Other methods will also involve causality diagram method, decision table method, orthogonal analysis method, scene method and so on.

4.1. The equivalence class partition method divides all possible input data into several subsets. In each subset, if any input data has the same effect on exposing potential errors in the program, then such a subset constitutes an equivalence 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 method

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.

Example: for the "user login" function, based on equivalence class division and boundary value analysis, the test cases we designed include:

1. Enter the registered user name and correct password to verify that the login is successful

two。 Enter a registered user name and incorrect password, verify that login failed, and prompt for correct information

3. Enter an unregistered user name and any password to verify that the login failed, and the prompt information is correct

4. Both user name and password are empty, verify that login failed, and prompt information is correct

5. One of the user name and password is empty, verify that the login failed, and the prompt information is correct

6. If the login function enables the CAPTCHA function, enter the correct CAPTCHA if the user name and password are correct, and verify whether the login is successful.

7. If the login function enables the CAPTCHA function, enter the wrong CAPTCHA under the premise that the user name and password are correct, verify that the login failed, and the prompt information is correct.

If you add the error inference method (which varies from person to person), the following test cases will be added:

1. Whether the user name and password are case sensitive

two。 Whether the password box on the page is encrypted

3. Whether the user created by the background system will be prompted to change the password when he logs in successfully for the first time

4. Whether the function of forgetting user name and password is available

5. Whether the front-end page limits the length of the user name and password according to the design requirements

6. If the login function requires a CAPTCHA, click on the CAPTCHA picture to see if the CAPTCHA can be changed, and whether the CAPTCHA is available after replacement

7. Whether refreshing the page will refresh the CAPTCHA

8. If the verification code is timely, it is necessary to verify the validity of the in-time verification code and the out-of-time verification code respectively.

9. After the user logs in successfully but the session times out, whether to continue the operation will be redirected to the user login interface

10. Whether the permissions of different levels of users, such as administrator users and ordinary users, are correct after logging in to the system

11. Whether the default focus of the page is located in the input box of the user name

twelve。 Shortcut keys such as Tab and Enter, whether they can be used normally.

5. Non-functional testing

For a high-quality software system, in addition to explicit functional requirements, other non-functional requirements, namely implicit functional requirements, are also extremely critical. The meaning of explicit functional requirements can be understood literally, which refers to the specific functions that the software itself needs to implement. For example, "normal users can log in successfully with the correct user name and password" and "non-registered users cannot log in", which are typical descriptions of explicit functional requirements. From the perspective of software testing, non-functional requirements are mainly related to security, performance and compatibility. In all the above test case design, we do not consider the testing of non-functional requirements at all, but these are often the key factors that determine the quality of the software.

Example: let's continue to refine the "user login" test case.

Additional test cases in terms of security include:

1. Whether the background storage of user passwords is encrypted

two。 Whether the user password is encrypted during network transmission

3. Whether the password has a validity period, and whether you are prompted to change the password after the expiration of the password.

4. If you do not log in, enter the login URL address directly in the browser to verify whether it will be redirected to the user login interface.

5. Whether the password input box does not support copy and paste

6. Whether all the passwords entered in the password input box can be viewed in the page source mode

7. Enter the typical "SQL injection * *" string into the user name and password input boxes respectively to verify the return page of the system.

8. Enter the typical "XSS cross-site script * *" string into the user name and password input boxes to verify whether the system behavior has been tampered with.

9. In the case of successive login failures, will the system block subsequent attempts to deal with brute force cracking

10. The same user logs in on multiple browsers of the same terminal to verify whether the mutual exclusion of the login function meets the design expectations.

11. The same user logs in successively on browsers of multiple terminals to verify whether the login is mutually exclusive.

From the perspective of performance stress testing, test cases include:

1. Whether the response time of single user login is less than 3 seconds

two。 Whether there are too many requests in the background when a single user logs in

3. Whether the response time of user login in high concurrency scenario is less than 5 seconds.

4. Whether the monitoring indicators of the server in high concurrency scenarios are in line with expectations

5. Whether there are resource deadlocks and unreasonable resource waits in high rendezvous point concurrency scenarios

6. For a long time, a large number of users log in and log out continuously, whether there is a memory leak on the server side.

From the perspective of compatibility testing, test case supplements include:

1. Verify the display and functional correctness of the login page under different browsers

two。 Verify the display and functional correctness of the login page under different versions of the same browser

3. Verify the display and functional correctness of the login page under different browsers of different mobile device terminals

4. Verify the display and functional correctness of the login page under the interface with different resolutions.

For high-quality software testing, use case design needs to consider not only explicit functional requirements, but also a series of non-functional requirements such as compatibility, security and performance. These non-functional requirements play an important role in the quality of the software system. However, the use case design of software testing is inexhaustible, and the engineering practice is inevitably subject to time cost and economic cost, so the testing department needs to strike a balance between defect risk and R & D cost.

6. Defect classification

According to the definition of defects, defects are divided into the following four categories:

6.1 document defects

Refers to defects found during the static inspection of a document. Inspection activities include peer review, product audit, etc. The defects of the review should be determined according to the type of object to be reviewed, including the final product and the intermediate process product. Such as product requirements documents, prototype design documents, test plans, test cases and so on.

6.2 Code defects

Refers to defects found during peer review, audit, or code walkthrough of code.

6.3 Test defects

It refers to the defects of the test object found by the test activity, which generally refers to the runnable code and system, excluding the problems found by the static test.

6.4 process defects

Also known as non-conformance problem, it refers to the defects and problems about the process found through process audit, process analysis, management review, quality assessment, quality audit and other activities. The discoverers of process defects are generally testers, project managers, and so on.

7 severity definition of Bug

Depending on the severity of the submitted bug, this specification defines the following five levels.

Category A: serious errors, including the following errors:

(1) illegal exit due to the crash caused by the program.

(2) endless cycle

(3) deadlock occurs in the database

(4) Program interruption caused by incorrect operation

(5) functional error

(6) error connecting to database

(7) data communication error

Category B: more serious errors, including the following errors:

(1) Program error

(2) Program interface error

(3) constraints such as tables, business rules and default values without integrity of the database

Class C: general errors, including the following errors:

(1) error in the operation interface (including whether the definition and meaning of column names in the data window are consistent)

(2) wrong print content and format

(3) simple input restrictions are not put in the foreground for control.

(4) No prompt is given for deletion operation.

(5) too many empty fields in the database table

Category D: minor errors, including the following errors:

(1) the interface is not standard

(2) the auxiliary description is not clear.

(3) input and output is not standard.

(4) the long operation does not prompt the user.

(5) the text of the prompt window does not use industry terminology.

(6) there is no obvious distinction between the input area and the read-only area.

Category E: test recommendation

8. Priority definition of Bug

This specification defines the following five levels based on the priority of the submitted bug.

1. Highest: indicates that the problem must be solved immediately, otherwise the system will not be able to meet the predetermined requirements.

2. High: it means that the repair of the problem is very urgent and urgent, which is related to whether the main functional modules of the system can be normal.

3. Medium: it means that the problem should be solved immediately when there is time, otherwise the system deviates from the demand or the scheduled function cannot be realized normally.

4. Low: indicates that the plan is solved, indicating that the problem does not affect the implementation of the requirements, but affects other aspects of use, such as page call errors, calling errors, and so on.

5. Lowest: that is, the problem must be confirmed or not resolved before the system is released.

9. Test standard

The passing criteria for functional tests are generally as follows:

(1) the unit function is consistent with the design requirements.

(2) the prescribed path coverage and coverage classes meet the requirements and are executed correctly.

(3) the prescribed black box testing methods are used and executed correctly.

(4) having a legal explanation for the residual error or being approved for temporary detention

(5) although the path coverage can not be achieved, the error detection rate of other tests tends to be zero or stable (the time depends on the situation).

All kinds of software tests must meet the following standards.

Class An error

Class B error

Class C error

Class D error

Category E recommendation

None

None

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.