National Computer technology and software Professional technical qualification (level) exam "software Evaluator"-Test content Summary (16) test project management

16. Test Project Management 16.1 software test configuration Management 16.1.1 Software test Configuration management concept

Configuration management (MANAGEMENT,CM) is a series of measures to control and standardize the software product and its development process and life cycle. The goal of configuration management is to document the evolution of software products and to ensure that software developers have accurate product configurations at all stages of the software lifecycle. Software Test Configuration Management general application process method and system method to establish software test management system, that is, the software test management as a system, the formation of the system of the various processes to identify and manage, in order to achieve the set of system goals. At the same time, to make these processes synergistic and mutually promote, so that their overall role is greater than the sum of each process. The main goal of software test configuration management is to find and identify software defects as far as possible under the set conditions. Test configuration management is a subset of software configuration management that is used in various stages of testing. Its management objects include software test plans, test scenarios (use cases), test versions, test tools and environments, test results, and more.

16.1.2 related concepts in software configuration management

Software configuration management has the following related concepts:

16.1.2.1 software configuration items (software config Item,sci)

Software configuration items are viewed as a basic independent unit for the purpose of configuration management, or their aggregate, such as externally submitted software products, project deliverables (code, documents, and data), and support tools used within the project (such as document test case software tools). In most software configuration management systems, the most basic software configuration items are stored and managed in the form of disk files.

16.1.2.2 Baseline (Baseline)

has been formally reviewed and approved as the basis for next development and only configuration items that can be changed through formal change control procedures.

16.1.2.3 Software Configuration Control Board (software configuration controls BOARD,SCCB)

It is the Software configuration Control Committee

16.1.2.4 Configuration Management Library

It is divided into development libraries, test libraries, baseline libraries (controlled libraries) and product libraries.

(1) Development Library

A library of configuration items and related information related to the development activity during a certain phase of the software life cycle.

(2) Test Library

The configuration item associated with the test, after the unit test, before the end of the system test.

(3) Baseline library (controlled library)

A library of configuration items and related information that is released as a result of a phase at the end of a phase of the software life cycle, related to development activities. Changes to the configuration items included in the baseline library must follow the change process guidance.

(4) Product Library

Before the project results are formally submitted to the user, SCM extracts the final product configuration items from the baseline library under the direction of the project manager.

16.1.2.5 software configuration management (software configuration MANAGEMENT,SCM)

It is software configuration management

16.1.2.6 software work products (software workproduct)

Any artifacts that are generated as part of defining, maintaining, or using a software process. It includes process descriptions, plans, procedures, computer programs, and associated documents.

16.1.2.7 Peer review (peer Review)

A software work Product Builder's peers follow defined procedures to review the product to identify defects and improvements

16.1.3 the main processes and activities of software configuration management

The main processes and activities of software configuration management are as follows

(1) Configuration item recognition

(2) Working space management

(3) Version control

(4) Change control

(5) Status statistics and reporting

(6) Configuration audit and review

(7) Product generation

(8) Process Management

The main processes and activities of software configuration management are as follows:

16.1.4 main tasks of software configuration management

The main tasks of software configuration management are as follows:

(1) Develop the project configuration plan

(2) Configuration item identification and configuration library management

(3) Version control

(4) Change control

(5) Regular configuration audits

(6) Report configuration status to relevant personnel

16.1.5 Software Configuration Management plan

The content of the software configuration management plan is as follows:

(1) Configuration management software resources and hardware resources

(2) Configuring the library structure

(3) Personnel, roles, and configuration management practices

(4) Baseline plan

(5) Configuring the library backup plan

Main functions of 16.1.6 configuration management system

The main functions of the configuration management system are as follows:

(1) Parallel development support

(2) Revised edition management

(3) Version control

(4) Product release Management

(5) Building Management

(6) Process Control

(7) Change Request management

(8) Code sharing

16.2 defect (bug) management process classification of 16.2.1 defects

From different angles, bugs can be divided into software errors, software defects, software failures and software failure

(1) Software error

Software errors refer to a series of issues that exist in software products that result in differences between expected run results and actual running results.

(2) Software defects

Software defects are those that exist in the software that are not desirable or unacceptable deviations.

(3) Software failure

Software failure refers to an unwanted or unacceptable internal state that occurs during the course of a software operation.

(4) Software failure

Software invalidation refers to the result of an unacceptable external behavior when the software is running.

16.2.2 Concepts related to software defects 16.2.2.1 the scope of software defects

The ability to conform to the following 5 rules is called a software flaw:

(1) The software does not meet the function specified in the product specification.

(2) The software shows the error that the product specification indicates will not occur.

(3) The SOFTWARE function is beyond the scope specified in the product specification.

(4) The software does not meet the objectives that the product specification does not indicate but should be achieved.

(5) Software Testers believe that the software is difficult to understand, difficult to use, slow to run, or the end user is considered bad.

16.2.2.2 Classification of software defects

The classification of software defects is as follows:

(1) function is not normal

(2) The software is not easy to use

(3) The structure of the software is not well planned

(4) Insufficient function

(5) Poor interaction with software operators

(6) Poor use performance

(7) Not doing error handling

(8) Boundary error

(9) Calculation error

(10) Errors resulting from the use of a period of time

(11) Error in control process

(12) Errors caused by large data volume pressure

(13) Errors generated in different hardware environments

(14) Errors caused by poor version control

(15) Errors in the software documentation

16.2.2.3 Severity of software defects

The severity of software defects can be divided into:

(1) Fatal (Fatal)

Complete loss of functionality, system crashes, crashes, data loss or corruption

(2) Serious (Critical)

Some of the main function loss, result error, function omission and data cannot be saved

(3) General (Major)

Minor features are not implemented, but do not affect normal use, such as interface layout, incorrect hints, and glitches

(4) smaller (Minor)

Does not affect the use of defects or small suggestions

16.2.2.4 Priority of software defects

The priority of software defects can be divided into:

(1) highest priority (P1): System can hardly be used or test cannot continue, need immediate fix

(2) Sub-high priority (P2): Must be repaired before product release

(3) Medium priority (P3): If time permits should be fixed

(4) General priority (P4): can be repaired, but does not affect publishing

16.2.2.5 software defect Tracking status

The state of the software defect in Bugzilla is described as follows:

(1) NEW

The tester submits the bug to the task dispatcher (the development module owner), where the bug status is new, starting the life cycle of the bug, and if the tester knows the specific responsible developer, it can also be specified directly, and enter the specific responsible developer email in the Assign to project.

(2) ASSI

When the task dispatcher distributes the bug to the designated developer, the bug is set to the Assi state, and the work to fix the bug begins.

(3) Reso DUPL

After the developer receives the bug assigned to it, check the bug list in the current project to see if the bug is duplicated with the previous bug, and if it repeats, place the new bug in the Reso dupl state and indicate in Commnet which bug is duplicated (some developers have placed the old bug Reso DUPL is wrong)

(4) Reso Inva

The developer has fixed a bug that has not been duplicated, and after analysis, if the bug is due to the wrong environment or due to faulty operation or due to the error of the tester, it is an invalid bug, the bug is set to the Reso Inva status, and the reason why it is invalid in Commnet is stated.

(5) Reso late

The developer fixes a valid bug that is not duplicated, analyzes it, if the current version cannot be repaired, but fixes it later in the project or when the condition is ripe, resets the bug to the Reso late state and notes the reason for late in Commnet ( Some developers mistakenly set this type of bug to Reso Inva is wrong)

(6) Reso WONT

The developer fixes a valid bug that is not duplicated, is analyzed, is not within the scope of the product requirement, and does not provide this functionality for the foreseeable future, placing the bug in the Reso wont state and stating the reason for wont in commnet

(7) Reso work

The developer will fix a valid bug without duplication, follow the steps of the bug, verify it multiple times, but not reproduce the bug, and require the tester to tell himself when the bug is discovered, so that when the bug is found, it is reso work status

(8) Reso FIXE

The developer has fixed a bug that has not been duplicated, found the cause of the problem, changed the code, can eliminate the bug, set the bug to Reso fixe status, and indicate the cause of the issue, the method of repair and the version to be repaired in commnet. For accurate and timely verification by testers (some developers only note that bugs have been fixed, but no version is stated, or the version is incorrect)

(9) VERI FIXE

When the tester is working on reso fixe, it is validated in the specified version and later versions, and if the bug is found to be no longer present, set the bug to Veri fixe status and indicate the verified version in Commnet

(10) Reop

When the tester is working on reso fixe, it is validated in the specified version and later versions, if the bug is found to be present, the bug is Reop state, the version of the bug is noted in commnet, the necessary information is added, and the developer continues to find the cause, Further fix the bug, the tester in the test process, found that the status of Veri fixe a bug is reproduced, the bug is set to Reop status, and in Commnet to indicate the version of the bug to reproduce, to supplement the necessary information, the developers need to continue to find the cause, further fix the bug, During the test, the tester discovers that a bug with a status of Clos is reproduced.

(11) CLOS

The tester verifies the bug in the veri fixe state again when the test is returned, if the bug is still not reproduced, resets the bug to the Clos state, and notes the last verified version in Commnet, the end of the bug's life cycle, and if the bug occurs in subsequent versions of the project. Requires Reop, the above operations are only handled in the same project, and there are no duplicate issues with bugs for different projects. When a tester submits a bug, if he wants others to know about the bug's progress, you can enter their email,bug in the CC entry and if you want others to know about the bug's progress, click Edit in the CC list to add their email

The Bug state transition diagram in Bugzilla is as follows

16.3 related applications of quality cost

Quality cost refers to all the expenses incurred by the enterprise in order to guarantee and improve the quality of the product or service, as well as all the losses caused by the failure to meet the product quality standards and the customer's needs.

Quality costs typically include:

(1) Consistent cost

All work to ensure consistency with requirements is called consistent cost

(2) Non-uniform cost

All work that is caused by non-conformance is called a non-uniform cost

The cost of these jobs mainly includes: prevention cost, appraisal cost, internal loss cost and external loss cost. The prevention cost and the appraisal cost are the consistent cost, and the internal loss cost and the external loss cost, collectively referred to as the failure cost, belong to the non-uniform cost.

The following table illustrates the calculation of consistent and non-uniform costs

Table 16-2 Test cost composition Table

Cost type	Quality Cost Item	Test cost Item	Automatic test (yuan)
Consistent Cost	Test investment	Test labor costs	50000
		Environmental usage Fee	10000
		Test Tool Fee	15000
		Test total investment	75000
Non-uniform Cost	Unit Test	Number of defects found	80
		Cost per defect	100
		Internal (development) defect costs	8000
	Independent testing	Number of defects found	215
		Cost per defect	400
		Internal (test) defect cost	86000
	Regression test	Number of defects found	5
		Cost per defect	4000
		External (user) Defect cost	20000
Total	Quality cost	Conformance costs	75000
		Non-uniform cost	(8000+86000+20000) =114000
		Total Quality Cost	(75000+114000) =189000
	Ddp	Defect detection Rate	(80+215)/(80+215+5) =98.3%

16.4 Software test Project management 16.4.1 The scope of software test management

(1) test process Management

(2) Testing personnel and organizations

(3) test plan and test progress

(4) Test risk management

(5) Test cost management

(6) Management of test outputs

16.4.2 the process of testing quality control

Test quality control can be carried out in the following ways:

(1) Develop quality assurance plan

(2) Review the test document

(3) Audit test activities

National Computer technology and software Professional technical qualification (level) exam "software Evaluator"-Test content Summary (16) test project management