Software Testing Work Specification

1. Making rules

In order to standardize the testing work, reduce the communication cost before development and test, ensure the project progress and improve the software quality, the test team drafted the software test work specification.

1.1. Coding Specifications

Software program development needs to abide by coding norms, one can reduce the maintenance cost of code, improve the development efficiency, the second is conducive to the continuation of development work, inheritance, reduce project risk.

1.1.1. Reasonable amount of comments

Good code should be self-describing, confusing places with annotations.

1.1.2. naming formats for specifications

A lot of norms, to let others and one months of self-understanding. Word-poor words refer to codelf:

http://unbug.github.io/codelf/#%E8%8D%AF%E8%81%9A%E6%B1%87

1.2. Test and test results 1.2.1. Unit Testing and reporting

Unit tests must be done. In-depth understanding of the "Test driven development" thought, if conditional, first write the test code, then write the development code. Use a variety of overlay methods, such as paths, functions, conditions, and statements, to ensure that the Code coverage is above 80%.

Provide unit test reports uniformly.

1.2.2. Integration testing and reporting

Integration testing must also be done. Test work to cover all modules and interfaces.

Integrated test reports are provided uniformly.

1.2.3. System Testing

After the unit and integration are passed, the project is measured and enters the system testing phase.

The system test scope can be divided into functional and non-functional tests depending on the project.

1.2.3.1. Mode

According to the pattern of alpha1-to alpha1n.

Beta version 1 after the smoke test passes, it enters the first round of tests (remember to do ALPHA1) and executes the full use case. Testing and development, and constantly submit and fix bugs until the use case execution is complete;

Development repair All defects, packaging release version 2;

Beta version 2 after the smoke test passes, it enters the second round of tests (remember to do ALPHA2), validates the defect, and executes some of the use cases. Testing and development, and constantly submit and fix bugs until the use case execution is complete;

Development repair All defects, packaging release version 3;

Beta version 3 after the smoke test passes, it enters the third round of tests (remember to do ALPHA3), validates the defect, and executes some of the use cases. Testing and development, and constantly submit and fix bugs until the use case execution is complete;

......

So, the cycle, until the defect convergence, to meet the test exit criteria, the system test completed.

Issue System Test Report.

1.2.3.2. Entering the standard

1) The functions stipulated in the requirement specification have been realized;

2) The main process can go through.

3) The functions on the interface have been realized and conform to the functions stipulated in the design document.

1.2.3.3. Suspension criteria

1) The number of first-level errors is greater than 1 and two errors are greater than 2;

2) When the software project needs to be paused for adjustment.

1.2.3.4. Exit Criteria

1) completed the system test according to the test plan;

2) to meet the requirements of the test plan for the system testing requirements of coverage;

3) The errors found in the system testing have been modified, and the repair rate of each defect has reached the requirement.

1.3. Workflow 1.3.1. Requirements and changes 1.3.1.1. Requirements Definition

The requirements are determined and presented to the tester in a document and prototype manner. Should include terminology explanations, functional descriptions, precise data limitations, and so on.

Unified training for development and testing personnel.

1.3.1.2. Baselines

After confirming and stabilizing the product requirement document, a baseline should be established, which is the basis for further development and testing. When a baseline is formed, the person responsible for software configuration management needs to notify the relevant person that the baseline has been formed and where the baseline version can be found. This process can be thought of as internal publishing. As for the official release of the external, it should be released from the baseline version.

1.3.1.3. Change Management

Changes in the software engineering process cannot be avoided, and such changes must be strictly controlled and managed, the information maintained, and accurate and clear information communicated to the next step in the software engineering process. Software change management includes the establishment of control points and the establishment of reporting and review systems.

The main tasks of change management include:

1, analyze the necessity and rationality of the change, determine whether to implement the change;

2, record the change information, fill in the Change Control list;

3, modify the corresponding software configuration item (baseline), to establish a new version;

4, after the review released a new version.

1.3.2. Project reference 1.3.2.1. Time to test

Project timing should be scheduled after development is completed, through unit and integration testing. Developers have time to go through the smoke test cases to increase the success rate of the smoke test.

1.3.2.2. Delivery of the test material

"Unit Test Report"

The Integration test report

The Test Environment Deployment manual

"Deployment Package"

"Database Initialization Script"

1.3.2.3. Version control

1) The development team develops and follows certain software system version naming formats, such as:

"The version number of the software system consists of 3 parts, i.e. the major version number + minor version number + revision number. Major version number 1, only if the system in the structure and function of a major breakthrough in the changes only after the change, the minor version number 2, the modification number 8, the date of the submission, when the system made any changes, including the structure of the database changes, the modification number should be changed. For example: Ver3.31.19990317 ";

2) The version number of each subsystem is independent;

3) software system, after generating a new version, the old version of the software system will continue to save, depending on the following conditions:

A, the old version of the system if the customer is still in use, before the customer upgrade, must continue to save.

b, the old version of the system has not been used by customers, and the new version of the system has the old system of the document has been completely upgraded, so that you can delete or overwrite the old version of the system resources.

C, for the old version of the system to be deleted or overwritten, can be backed up uniformly.

1.3.2.4. Test interval

After the project is first tested, subsequent measurements should be scheduled after the completion of the software testing work and have tried to repair most of the defects.

A version is severely eliminated during system testing only to fix a bug.

1.3.2.5. Test environment 1.3.2.5.1. Environmental classification

In order to ensure the quality of work and optimize the workflow, the software environment should have at least the following three sets:

Development Environment : Development Department development, debugging, integration of software use.

System test Environment : Test Department system test use.

production environment : User use, operation and maintenance department management.

In order to further improve the user experience and improve the efficiency of defect repair, according to the conditions can also add the following two sets of environments:

Beta environment : After the system test is passed, the beta test is used and managed by the operations department.

Line Mirroring Environment : Emergency replication, debugging, solve the problem on the line.

1.3.2.5.2. Environmental management

Decentralization

The production environment only opens query permissions for development and testing. (Need to modify permissions need to undergo a certain mechanism to control the record, generally only in the debugging program when the permission to open the modification);

The test environment has only open query permissions for development. (Need to modify the permissions to be confirmed, generally only when debugging programs to open the permission to modify);

Development environment for testers only open query permission;

The above three environment, the person is responsible for upgrading, maintenance.

Regular comparison to

Take the production environment database as the standard and compare the test environment.

Extract the Difference section (table structure, process, trigger, etc.) for analysis. If the variance section is not the result of a planned upgrade, it should be deleted. This allows the test environment and production environment to be structurally consistent after the next scheduled version is upgraded, and the next scheduled version is not in the test environment up-front version.

Development environment, in contrast to the production environment, the difference section first removes the most recent script impact to release the production, and then the remaining, within the Development Group communication confirmation, will be no one responsible for deletion. In this way, a relatively uniform environment can be obtained.

Because the development environment, generally only one, so in multiple versions of parallel development process, database management is relatively chaotic. In this case, try to ensure that the test environment and production environment of the database structure of the unity. It is of great significance to guarantee the release quality.

1.3.2.6. Smoke Test

Smoke tests occur in two scenarios, one in-house, and one in the production environment.

The smoke test verifies that the main function has been implemented, which is helpful for rough verification of the testability of the analyte and whether there are any major problems with the system after the on-line deployment.

1.3.3. Defect handling 1.3.3.1. Repair time

The defect treatment should have certain timeliness.

Priority level	Description
1-Emergency	Must be repaired within one business day
2-High	Must be repaired within three business days
3-General	Must be repaired within five business days
4-No hurry	Have time to fix it again

1.4. Quality Assurance 1.4.1. Review 1.4.1.1. Requirements Review

The evaluation of product requirements can be divided into three dimensions:

value Identification -there is no value to the user, input-output ratio;

Demand Quality -whether the demand is easy to understand, the details are not clear, the logic is established;

Technical Feasibility -can be done, the cost of large-scale, how much risk.

1.4.1.2. Review of design proposals

It is up to the development team to organize itself, and from the process, it must be done.

1.4.1.3. Use case Review

participants : Product, test, development and project leader;

Objective :

1) Reduce the testing personnel to do invalid work during the execution phase;

2) to avoid the three-party needs to understand inconsistent;

3) The quality standards of each tester agree with the standard of the project requirements.

1.4.2. Cross-testing

1, each tester has its own limitations of thinking, a thinking test, the software will be resistant to this test thinking, it is difficult to find new problems, through cross-testing, you can bring the new test thinking, test out the bug not found.

2, to prevent the test personnel work careless cause leakage test.

2. Executive Oversight

First, the consensus, on the basis of joint supervision and implementation, and arrange for the supervision of personnel.

3. Optimization improvements

This document lists, defines a series of software testing specifications, the main purpose is to ensure project progress, improve software quality. In the process of implementation of the program, we are guided by the principle of concise, efficient, and constantly optimize the improvement, in order to come up with the most suitable for drug gathered software testing work norms.

3.1. Test evolution

3.2. Defect prevention

1) The requirement phase test begins to enter the project;

2) unit test-code static analysis;

3) Continuous integration-daily build, automatic feedback.