[SCM] Bugzilla Confidential Hand

xiaoxiao2021-03-06  65

Bugzilla Confidential Hand

1 Introduction: Bugzilla is a free defect tracking tool for Mozilla to provide us with an open source. As a record and tracking tool for product defects, it can create a complete BUG tracking system, including report bugs, query bug records, and generate reports, processing resolution, administrator system initialization, and set up. And with the following features: L Based on web way, easy to install, easy to run, easy to manage. l Concerns contributing to defects. This system uses the database to manage, providing a comprehensive detailed report entry, generating a standardized bug report. Provide a large number of analytical options and powerful query matching capabilities, BUG statistics can be combined according to various conditional combinations. When the error changes in its life cycle, developers, testers, and managers will promptly obtain dynamic change information, allowing you to get history records and refer to this record when checking errors. l System flexible, powerful configible capabilities. Bugzilla tools can set different modules for software products and set developers and testers for different modules; this can be automatically issued to the specified responsible person when submitting a report; and can set different groups. Setting different users with different operation permissions of bugs, valid control management. Allows the setting of different severity and priority, can manage errors in the wrong life period, have detailed records from the initial report to the final solution, ensuring that the error will not be ignored, while allowing the developer Attention is concentrated in a high priority and high degree of severity. l Auto Send Email to notify the relevant personnel. Automatically send the latest dynamic information to the different responsible persons, which effectively help testers and developers communicate. 2 Bugzilla operation process: 2. User login and setup process: l Open the browser, enter the bugzilla server address: http: // server / bugzilla / L After entering the main page, click [New Account] to enter the registration page. l Enter the E-Mail address and user code in the registration page, then click [CREATE Accent], then you will receive an E-mail including the initial password. l After receiving E-mail, click [Login], enter the E-mail address used when the account bar is entered, enter the initial password notified in the password bar, then click [Login]. l Forgot your password, enter the registered user name in the landing page, click [Submit Request], and reset the password according to the received message. l If you have successfully logged in, click [EDIT property] -> [account setting] to modify the password. l Click [Edit property] -> [mail setting] for email notification settings. l Click [EDIT property] -> [Permissions] to perform permission query. 2.2 BUG Process Process Overview: l After the tester or developer discovers bug, it is determined which module belongs to which module is brought. After filling the bug report, the project team leader or directly notifies the developer directly through the Email. l The project team leader is re-impathed to the developer who belongs to the BUG according to the specific situation. l After the developer receives E-mail information, it is judged whether or not it is a range of modifications. A. If not, reassigned the developer assigned to the project team leader or should be assigned; B. If it is processed, resolved and give a solution.

(Create a patch attachment and supplementary description); l Tester query the developer has modified BUG to retest. (Create Test Case Accessories) A. After verifying, modify the status is Verified. After the entire product is released, modify it to close. B. There is also a problem, reopened, the state is revert to "New", and email notifications. l If this bug has never been processed in a week. Bugzilla will always harass its owner with E-mail until it takes action. 2.3 A bug survival cycle diagram:

2.4 Tester Report BUG process: l First, please check first, confirm that the bug report to be submitted will not exist in the original record, if there is already, if there is any suggestion, you can add comments in the original record, inform them The owner, let the BUG's owner sees this after you want to modify it. l If the bug does not exist, create a valid BUG report to submit. l Conventional operation: Click [New], after selecting the product, fill in the table of a bug report. Fill in the table Note: [Assignment] Owner set by default to the air, or manually. [Cc] can be multiple people, need to be separated by commas. [Description] The following statements are described in detail: A. The step of finding the problem; B. Execute the situation that appears after the above steps; C. Expected results should appear. l [platform], [operating system], [priority], [severe level], can choose from the specific situation. l [dependence] refers to the BUG number associated with this new bug. l [blocks] If you are not clear, J L is completed, click [Commit] to submit, send email notification to the relevant personnel. 2.5 BUG Different Process Status Explanation: l Bug's home (OWNER) confirmed and accepted this bug, then give a solution, and fill in [additional instructions], you can also [establish a new attachment] (such as: Change submission) and many more. l The developer can adjust the BUG state as follows: A. Fixed => Description has been modified; b. invalid => Description problem is not a bug (after input error, cancel); C. Wontfix => Description The problem will never be fixed; D. Later => The problem described will not be resolved in this version of the product; E. Duplicate => Description is a problem that exists bugs; F. Worksforme => The attempt to react to this bug is invalid. If there is more information, reassign this bug, and now use it to archive it. l After the tester receives the modification of the bug, you can do the following adjustments: A. Leave as resolved fixed => Keep the Fixed status unchanged; B. Reopen bug => This bug has problems, reopen; C. Mark Bug as verified => This bug is indeed correctly modified; D. Mark bug as closed => The product has been released, and this bug is turned off. 2.6 Description of Permissions: The member of the group has the right to query the BUG, ​​but cannot be modified. l BUG's Owner and Reporter have the right to modify. l Users with special permissions have the right to modify.

转载请注明原文地址:https://www.9cbs.com/read-119689.html

New Post(0)