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

This article mainly introduces "what is the Android software defect management". In the daily operation, I believe many people have doubts about the Android software defect management. The editor consulted all kinds of materials and sorted out the simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what is the Android software defect management?" Next, please follow the editor to study!

Software defects-concept

Software defects-the basic concepts are mainly divided into: defects, faults, failure defects (Defect): exist in the interior of the software in static form, equivalent to BUG; faults (Fault): the state that occurs in the operation of the software, if not dealt with, may fail and exist in a dynamic form; failure (Failure): the external abnormal behavior results produced when the software is running, which is inconsistent with the needs of users.

Defects do not necessarily lead to failure, and faults do not necessarily lead to failure; defects lead to failure, which may or may not lead to failure.

Software defect-definition

Definition of software defect

The software does not reach the function indicated in the product specification, the software does not reach the target software that is not pointed out in the product specification, but there is an error in the software that will not occur in the product specification. Software testers think that the software is difficult to understand, difficult to use, and slow to run. Or several types of defects that end users think are bad: unreasonable design Functions and features are not realized or partially realized; running errors, including running interruptions, system crashes, interface confusion, etc.; inconsistent with requirements, the actual results and expected results are inconsistent with the implementation of TestCase; other problems that users can not accept, such as long access time and unattractive interface; the software implements functions that are not mentioned in the requirements.

Software defects-the cause

Personnel communication is not in place, there are misunderstandings in communication or do not exchange documents at all, imperfect requirements are constantly changing, participants are overconfident in programming errors, software complexity, short duration, heavy tasks, time pressure, software development tools and software and hardware

Identify software defects

Identified by the expected results in the test case, identified by the requirements specification

Identify through user manuals and other documents through mature commercial software similar to the same industry

Identify through communication with developers through communication with experienced testers

Identify by referring to the implicit needs of the same industry

Software defects-organizational architecture

Title of defect (brief description of the problem in a sentence) basic information of defect testing software and hardware environment testing software version defect type defect severity defect handling of priority defect operation steps (test steps, expected results, measured results) remarks / comments text and screenshots

Software defects-related attributes

Defect related attributes: author, date of submission, BUG status, severity, defect priority, defect version, repair date.

1. Defect discoverer: the most direct one is the tester, and the number of BUG found by the tester is the basis for personal performance appraisal. two。 Defect discovery time: the time when BUG was found and submitted. 3. Defect priority: immediately resolve P1, high priority P2, normal queue P3, low priority P4. Immediate resolution means that the defect makes the system almost impossible to use or the test can not continue and needs to be repaired immediately; high priority means that the defect seriously affects the test and needs to be given priority; normal queuing means that the defect is normally queued for repair; and low priority means that the defect can be finally modified. 4. Defective version: perform the test and find the version number of the BUG. 5. Bug fix date: the date the developer fixed the BUG.

Defect state

1. Initial state of the new New defect

two。 Open the Open tester to submit the BUG

3. Assign Assigned to relevant developers for repair

4. Fixed Fixed developer fixed

5. Closed Closed test passed, closed

6. Reopen the Reopen regression test failed, or closed and then reappeared

7. Postpone Postpone to defer modification

8. Reject Rejected developers refuse to modify

9. Repeat Duplicate repeat submission

10. Canceled / terminated Abandon rejected and repeatedly submitted BUG, set this status after confirming that it is not a problem

Severity of defects: fatal, severe, average, minor, suggestions for improvement; or A, B, C, D, E

1. Fatal: software crashes, exits or crashes, data loss, complete loss of main functions, resulting in anomalies in this module and related modules. Such as code errors, dead loops, database deadlocks, database connection errors or data communication errors, do not consider abnormal operations, functional errors and so on. two。 Serious: part of the main function is lost, the data cannot be saved, and the secondary function of the system is completely lost. Such as fatal error declaration, program interface error, database tables, business rules, default values without integrity and other constraints. 3. General: secondary functions are not fully implemented but do not affect use. For example, the prompt information is not accurate, or the user interface is poor, the operation time is long, the function of the module is invalid, the print content and format are wrong, the deletion operation is not prompted, and there are too many empty fields in the database table. 4. Smaller: make the operator inconvenient or encounter trouble, but it does not affect the operation and implementation of functions, such as typos, interface is not standard, auxiliary description is not clear. 5. Improvement suggestions: comments, suggestions, or questions about software improvements made by testers.

Software defects-fill in requirements

1. Defect identification: required, identification number of the defect. two。 Assigner: required, newly submitted questions are assigned to the appropriate developer. 3. Author: required, the submitter of the question defaults to himself. 4. Test version: required, the software version number found at the beginning of the problem, corresponding to the development version number. 5. Test date: required, and the time when the question was first submitted defaults to the same day. 6. Severity: required. The higher the severity of the problem, the more serious it is. Probability of defect occurrence: required, probability of occurrence is necessary, probabilistic occurrence (several times), non-reproducibility. 8. Priority: required. The higher the defect needs to be resolved, the higher it means that the developer will fix the problem as soon as possible. 9. Defect status: required, defect status, default is "New" when newly submitted. 10. Origin of defects: at which stage of requirements, architecture, design, coding, testing, and users. 11. Source of defects: from requirements specifications, design documents, integration interfaces, code. twelve。 Defect module: required, which function module's BUG. 13. Problem description: required, describe the problem in detail, the description must include expected results and actual results, attach drawings as far as possible, and write suggestions for modification if there is any suggestion. 14. Problem handling comments: the suggestions given by the project staff on how to deal with the defects can be read and written.

Software defect-description principle

Defect description principles: accurate classification, concise description, clear steps, easy reproduction, and documented complex problems (screenshots or other forms of attachments). The details are:

Problem description format: when describing the problem, it is recommended to describe it in several steps: module or function point = > test step = > expected result = > real result = > other information, which can be adjusted according to the actual situation; the description is simple and accurate, one defect report; the description of each step is as concise and clear as possible. Short and concise: only explain the facts, demonstrate and describe the necessary details of the software defect, do not write irrelevant information; reproduction: can be reproduced (individual serious problems can also be stored in the database, but need to be marked); specific conditions: whether the defect will occur under specific conditions; supplement and improvement: complex problems should be accompanied by screenshots, LOG and other information as supplementary instructions.

Do not use abstract words: such as "there is an error", "is it", "Please confirm", etc.; do not comment: do not add personal subjective thoughts to evaluate BUG defects in the BUG description.

Software defect-Life cycle

Simple cycle: discover, open, repair, close

The tester finds and registers the software defect, which is handed over to the programmer

The programmer fixes the software defect, the software defect is handed over to the tester to make sure that the software defect is fixed, and the tester closes the software defect.

Complex cycle:

Find defects (testers find and register defects, software defects are transferred to programmers) the software defects are transferred to the project administrator (resolved in the form of non-repair) the project manager thinks that the software defects are not important, the software defects are handed over to the tester to reactivate the defect (tester disagrees, identify common failure cases The software defect is handed over to the project administrator) the project administrator agrees that the defect needs to be fixed, and the defect is transferred to the programmer to resolve it in the form of repair (tester confirms that the software defect has been fixed, tester closes the software defect) defect closure

Test / Development role responsibilities

Test executor: defect discoverer. Test the version to find the BUG and verify the repaired BUG. Test team leader: defect manager. Responsible for the review, tracking and reporting of defects, and coordinate with all parties to the disputed BUG. Person in charge of development: defect solver. Receive BUG and assign it to specific developers to fix it, and give solutions or suggestions for repair. Developer: defect fixer. Perform the BUG repair assigned by the developer and self-test whether the repair is passed.

Software defect management process

BUG tracking process: 1. Testers get the latest software version and execute the test; 2. Discover BUG and record it to BUG management platform; submit BUG report or test report, email CC developer; 3. Developers get the latest BUG and fix BUG (such as complex problems, expert reviews on how to deal with them) 4. After repairing BUG, Check in the new code to the source code server; 5.Buider personnel will compile the version and submit it to the release server; 6. The testers began to perform a new round of testing tasks.

Defect tracking purpose: 1. Ensure that the BUG is effectively tracked and resolved, so that each link is responsible for the corresponding person. two。 Conduct defect analysis and product measurement.

Software defect analysis

Defect analysis is to analyze the distribution of defects on one or more parameter values associated with defects. Defect analysis provides a software reliability index.

Main parameter status: the current state of the defect (open, being repaired or closed, etc.). Priority: the relative importance that defects must be addressed and resolved. Severity: related effects of defects. Impact on end users, organizations, or third parties, and so on. Origin: the origin and location of the defect, or the components that need to be repaired to eliminate the defect

Create defect trend chart or report; provide judgment basis for revealing defect trend or defect distribution of software reliability.

Defect report

Defect report-concept:

During the test execution, after finding the defect fault / failure, submit a written report.

Defect report-role:

1. Record software defects 2. Classify defects 3. For defect analysis 4. Tracking software defects 5. Measure software quality

5C guidelines for defect reporting:

Correct (accurate) Clear (clear) Concise (concise) Complete (complete) Consistent (consistent)

BUG management tools

Tools for managing BUG: Excel, Bugzilla, TestDirector (TD), ClearQuest (CQ), Bugfree, JIRA, etc.

TestDirector business, support for Win platform, Bamp S architecture, automated software quality testing and management in a wide range of application environments

ClearQuest Commerce, support for the Unix/Win platform, Cmax S, Bamp S architecture, provides a complete audit trail from development to deployment, and extends traceability across the lifecycle

Bugzilla is free, supports the Unix/Win platform, Bamp S architecture, and the Bug tracking system is designed to help manage software development

Bugfree is free, draws lessons from Microsoft's research and development process and Bug management concept, and uses a Bug management system written independently by PHP+MySQL. Simple and practical, free and open source code

JIRA business is a commercial software that integrates project planning, task allocation, requirements management and error tracking.

At this point, the study of "what are the Android software defect management" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.