QA/BugTriage/zh-hans

From The Document Foundation Wiki
< QA
Jump to: navigation, search
This page is a translated version of the page QA/BugTriage and the translation is 28% complete.

Outdated translations are marked like this.
Other languages:
Deutsch • ‎English • ‎français • ‎Nederlands • ‎português do Brasil • ‎русский • ‎Türkçe • ‎中文(简体)‎


This document provides information on how to triage bugs for LibreOffice. Triaging is the name given for confirming, prioritizing, and organizing bug reports and is a good place for new contributors and/or contributors with limited programming abilities to help LibreOffice become a better product for everyone. Triaging is an incredibly important aspect of development that benefits users and developers alike.

适合初学者的 bug 诊断指南

当前页面中的描述和步骤比较详细。如果您是初学者,希望简单入门,请阅读:适合初学者的 bug 诊断指南

在哪里能找到 QA 团队的成员

您在 bug 诊断过程中遇到任何问题,都可以通过如下渠道联系我们的 QA 团队成员。他们很有经验,明天都在积极地进行各种 bug 诊断任务,而且也很乐意将自己的经验传授给您。

  1. 邮件列表:
    • libreoffice-qa@lists.freedesktop.org
    • libreoffice@lists.freedesktop.org
  2. 位于 freenode 上的 IRC 频道:
  3. QA 团队成员:
    这里有一个不完整的 QA 团队成员名单。如果愿意帮忙,您可以将自己的名字添加进去。如果列表中的成员已经同意您直接联系他(她),您可以随时跟他(她)联系。

There are a few places where you can find/contact members from the QA team, many of whom can help with triaging questions and are actively triaging themselves.

  1. Mailing Lists
    • libreoffice-qa@lists.freedesktop.org
    • libreoffice@lists.freedesktop.org
  2. IRC Channels on Freenode
  3. QA Members
    Here is a list of QA members (feel free to add your own name if you intend on contributing to QA). If the user has given you permission to contact them directly, feel free to do so. Also you'll find them hanging out in the chat rooms somewhat frequently.

Bug 诊断步骤

这部分列出了要正确进行 bug 诊断需要遵循的详细步骤。这里的描述力求精准,有些地方还给出了要了解进一步信息的链接。这些步骤其实可以分为三大步:准备;重现;确定优先级。

This section lists the steps necessary in order to triage correctly. This guide aims to be concise, links in some sections will provide more information relevant to the particular step. The triage process can be essentially broken up into three parts, the first being "preparation" the second being "reproducing" the third being "prioritization".

步骤概述

  1. 找到要诊断的 bug
  2. 对 bug 报告进行预先筛查
  3. 查找重复的 bug
  4. 检查 bug 报告中的信息,确保完整
  5. 尝试重现这个 bug
  6. 设置这个 Bug 的 Status (状态)
  7. 设置这个 bug 的优先级顺序
  8. 通知开发者(如果确实必要)
  1. Find Bugs to Triage
  2. Pre-filter Bug Reports
  3. Search for Duplicates of Bug(s)
  4. Check Information Provided in Bug Report
  5. Attempt to Reproduce Bug
  6. Set Bug Status
  7. Prioritize Bug
  8. Notify Developers -- Needed only in very specific cases if bug seems to be a Blocker/Critical.

步骤详情

准备工作

首先在 bugzilla 上创建账户,然后登录。我们建议您在 preferences 页面将 'Automatically add me to the CC list of bugs I change' 设置为 'Only if I have no role on them',这样就能确保您参与过的 bug 有任何更改时能随时收到提醒。

Preparation

In general you'll always want to do the following steps in preparing to triage bugs. Remember that you can work on bugs only when logged in (please create an account if you do not already have one). And once you have an account, it is good to go to your preferences and set 'Automatically add me to the CC list of bugs I change' to 'Only if I have no role on them' if you want to be notified whenever someone replies in any of the bug reports you commented in.

第一步:找到要诊断的 bug

a) 在 Bugzilla 中搜索

前往 LibreOffice 的 bug 跟踪系统中(位于 bugs.documentfoundation.org. 登录后,浏览 当前处于开放状态的 bug 报告清单。您可以根据组件进行浏览;或者自定义搜索符合下列条件的 bug:

1) 报告在 LibreOffice 产品下;

2) Bug 的状态为 UNCONFIRMED 或 REOPENED;

3) 添加其他它您感兴趣的限制条件。

获得搜索结果之后,从中挑选出中意的 bug. 您可以在 Advanced Search 表单 中构建自定义搜索,也可以在 Quick Search 框中输入关键词进行搜索(请参考“Bugzilla 快速搜索”帮助)。您还可以单击下列整理好的直接链接进行搜索。

第二步:预先筛查

有一些 bug 需要其他团队的特别注意:

UX 改进建议

任何涉及 LibreOffice UI/UX 功能改进的建议,都应当先提交给 UX 团队进行判断。

Any bugs which cover enhancements to the UI/UX of LibreOffice should be given to the UX Team

  1. 在 Keywords 字段中加入 'needsUXEval' 关键词,意思是这个 bug 需要 UX 团队的评估
  2. 修改 status 状态:
    • 如果这个功能改进建议内容完整,并且有一定道理:请设置 StatusNEW
    • 如果需要原报告者提供进一步解释说明:请设置 StatusNEEDINFO
  3. 添加一条评论,内容如下:
UX Team -- please take a look at this enhancement. Thanks!


    • If the request looks complete and plausible, Status -> NEW
    • If the request seems incomplete or needs explaining, Status -> NEEDINFO
  1. Leave a comment along the lines of:
UX Team -- please take a look at this enhancement. Thanks!

有一些 bug 不应当在 Bugzilla 上报告,这些情况以及应当报告的位置,请见:“如何报告 LibreOffice 中的 Bug”页面。

  • 如果不应当报告在 Bugzilla 的 bug 却报告到了 Bugzilla, 请将其 Status 更改为 RESOLVED NOTOURBUG(意思是“不是我们的 Bug),并加入如下的评论:
Thank you for getting in touch with us!
Although Bugzilla sometimes feels like the center of the
Universe, there are a few topics that need to be
reported elsewhere. To find the right place to report
your issue, please look at the BugReport wiki page:
https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

第三步:搜索重复的 bug

Duplicates are bugs marked RESOLVED DUPLICATE which are very similar or identical but reported by different users. Such bugs are automatically counted by Bugzilla and available at Most Frequently Reported Bugs page. When triaging please check that list and do a quick search through bugs in Bugzilla to see if there are any duplicates of the bug that you have, but don't need to spend a lifetime on this. As you see more bugs you may remember seeing a similar bug and can easily close the newest of the two (or more) bugs. In general minimizing the amount of duplicate bugs entered into Bugzilla will save time for QA team members.

Duplicates are reports which are very similar or identical, but reported by different users. You typically want to keep the NEW status for the report with the most valuable information and close others as RESOLVED DUPLICATE. So even though an older report exists, there is no need to keep it open, if it contains confusing or incomplete information.Closed duplicates are automatically counted by Bugzilla and available at Most Frequently Reported Bugs page. When triaging please, check that list and do a quick search through reports in Bugzilla to see if there are any duplicates of the report you are examining. You don't need to spend a lifetime on this. As you see more reports you may start spotting duplicates without having to use the search.

If you find a duplicate bug skip to step #5

第四步:检查核对 bug 中的信息

槛车并核对 bug 中的信息,这对于软件开发非常重要。您应该重点关注以下信息:

  1. Bug 的概述(即标题,Summary 字段)清晰易懂。
  2. 有清楚的问题描述。
  3. 列出了重现问题的步骤。但是,如果从标题或问题描述能够很容易肯出重现步骤,则这个信息可以不包含。
  4. 附件 -- 很多情况下,需要有用于测试的附件才能重现该问题,否则根本无法修复该问题。

Checking information is critical for development. What you should look for is the following:

  1. Clear and meaningful summary
  2. Clear problem description
  3. Steps to reproduce the problem -- if not clear from summary and/or description
  4. Attachments -- in many cases attachments are needed to reproduce the problem, if attachment(s) are not provided this can hinder proper fixes

如果以上所有的信息都已经提供,则进入第五步。

第五步:尝试重现

如果这个 bug “通过”了以上的“准备”环节,那么下一步我们将尝试重现该 bug. 尝试重现步骤很简单:根据 bug 报告中提供的重现步骤进行操作,看看 bug 行为能不能在您的系统上出现。就这么简单! 如果您能重现,那么您需要注意以下问题:

  1. 原 bug 报告中提供的重现步骤已经清楚准确了吗?您有没有进行额外的步骤才重现的?如果有额外的步骤,请在评论中指出。
  2. 您的重现步骤导致了与原报告相同的结果,还是出现了类似却有不完全相同的结果?或者一切工作正常?

If the bug "passed" the Preparation steps it's time to try to reproduce the bug.

Do just that: Go through the steps necessary and try to reproduce the bug, that simple! When you reproduce it, keep these things in mind:

  1. Did the bug reporter leave enough information in Bugzilla itself to reproduce the bug, or did you have to take extra steps? If extra steps were needed, add a comment to describe the extra step(s).
  2. Did your reproduction lead to the same result, something similar but not identical, or did everything work flawlessly?

第六步:设置状态

这一步是进行 bug 诊断需要进行的最后一个“强制性”步骤,而且只能在“第一”到“第四”步(如果第四步不适用,则为第一到第三步)均完成之后才能进行。

This section is the last "mandatory" step of a successful triage and can only be done once steps #1–#4 are done (or #3 if #4 isn't applicable).

Bug 的状态 (STATUS) 取决于您进行上述步骤对应的结果:

  1. NEW: 该 Bug 已被确认,并且所需要的所有信息都已提供。
  2. NEEDINFO: 缺少尝试重现 bug 所需的某些必要信息。在这种情况下,请在评论里向特定的人索要特定的信息。
  3. RESOLVED: 具体有以下选项:如果您不能重现该 bug, 则 RESOLVED WORKSFORME 可能是比较好的方式,但请务必查看这里的更进一步信息。
  4. VERIFIED: 这个选项仅适用于当前选项是 RESOLVED 的情况。您可以将已经 RESOLVED FIXED 了的 bug 标记为 VERIFIED,当且仅当您经过测试能够确信当前 bug 已被评论中提到的某个明确的 commit 修复了。进行这一步,对于修复了这个 bug 的开发者也是一种鼓励和感激,他(她)将会很开心,同时又是对这个 bug 是否真的已被修复所做的确认。另一方面,Bug 报告者也可以将自己报告的原来是 RESOLVED WORKSFORME 的 bug 标记为 VERIFIED WORKSFORME,以确认这个 bug 确实已经不存在了。
  5. INVALID: There are many reasons why a bug can be determined to be invalid, but this usually requires input from other QA members. If you come across a bug that you believe to be invalid, best bet is to get a second opinion from the QA IRC channel or send an email out to the mailing list explaining why you believe the bug to be invalid.
  6. UNCONFIRMED: This is the status given to all new bugs that have not gone through triage process. Note that such bug might be also in NEEDINFO state.
  1. NEW: Confirmed bug, all information necessary is there
  2. NEEDINFO: All information needed to attempt replication is not included in the bug report. Please ask a particular person for a particular information in a comment.
  3. RESOLVED: This category comes with several options, if you can't replicate the bug, RESOLVED WORKSFORME is the appropriate STATUS, see HERE for more information.
  4. VERIFIED: This option is only available when the current bug status is RESOLVED. You can mark a RESOLVED FIXED bug as VERIFIED, when you can confirm it is fixed with the version mentioned in the bug report. It is also pleasant for the developer who fixed the issue, and is a confirmation the problem is solved now. Otherwise a bug reporter can mark their own bug that is in RESOLVED WORKSFORME state as VERIFIED WORKSFORME to verify it is somehow fixed.
  5. INVALID: There are many reasons why a bug can be determined to be invalid, but this usually requires input from other QA members. If you come across a bug that you believe to be invalid, best bet is to get a second opinion from the QA IRC channel or send an email out to the mailing list explaining why you believe the bug to be invalid.
  6. UNCONFIRMED: This is the status given to all new bugs that have not gone through triage process. Note that such bug might be also in NEEDINFO state.

ANY time you make changes you should put a comment that politely explains why you made the change

Flowcharts below are examples of how to visually think of setting STATUS. Feel free to edit and upload your own version if you'd like.
PDF file
LibreOffice Draw file

Step 7: Regression Testing

Use older versions of LibreOffice to find out whether the bug has been introduced since LibreOffice began.

Download and install a number of old versions, the oldest being LibreOffice 3.3. At a minimum you should have one version from all the main release lines (3.x, 4.x, 5.x, 6.x...).

You have to have some awareness of when various features were introduced into the software to avoid getting irrelevant test results. Please consult other team members, if you are unsure of something.

  • If the bug is present in version 3.3.0, set version to "inherited from OOo" and add the following comment:
This bug is already present in Libreoffice 3.3.0

Changing version to "inherited from OOo"
  • If the bug is not present in 3.3.0 add "regression" to the keywords field and add the following comment:
This bug is not present in Libreoffice 3.3.0, thus it's a regression

For regressions that are older than version 3.5.0, also add the keyword preBibisect. For newer regressions add the keyword bibisectRequest and update the version field to match the earliest known problematic version.

第七步:设置优先级

We currently highlight only critical bugs by CC-ing developers, adding special whiteboard entries, keywords, and updating MABs. See below for more information.

We currently highlight only critical bugs by CC-ing developers and adding keywords. See below for more information.

Bug prioritization for LibreOffice is currently a mess, but as triagers we should always be actively trying to make it better. Prioritizing a bug is relatively subjective, but the triager should always try to be consistent with how they determine a bug's prioritization. The QA team member triaging should have a clear idea of what constitutes each priority state and then try to stick with that methodology. Also, commenting on the bug after prioritizing is incredibly important to let the bug reporter (as well as developers and other users) know what thought process you used to come up with the priority status.

To prioritize bugs above medium-normal, you need to be added to the contributors group in Bugzilla. In order to get this done, please contact one of the Bugzilla admins.

The flowchart below shows rough guidelines on how to deal with prioritization.

Example 1 JPG

Example 1 Draw

It is usually easier to determine the severity of an issue than try to think of a suitable priority.

Small aesthetic tweaks to the UI can be considered low priority and trivial severity.

Problems that make you angry, but you can tolerate or work around somehow can be set to minor severity.

Bugs that break some functionality and do not have a workaround are normal severity.

Crashes, hangs and freezes resulting from a specific file or command are major severity.

一些有用的额外步骤(可选)

关键词 Keywords

The Keywords field holds Keywords pertaining to the categorization of this bug.

Keywords

The Keywords field holds Keywords pertaining to the categorization of this bug.

Some categories of Keywords include:

One interesting Keyword is needsDevEval. An easyHack is a bug that will most likely not take long to fix and can be done by a new developer and/or a developer without a lot of programming skills. As QA we should NOT mark a bug as easyHack as it requires several additional steps (including finding a developer to mentor for the bug). If you think a bug qualifies as an easyhack, mark as needsDevEval.

Crash reports

Having a crash report (aka backtrace) for a bug makes it easy for a developer to identify what is causing the crash. If a crash report is added to a bug report, the havebacktrace keyword should be added to the Keywords field.

Meta reports

Look at our existing meta reports that collect reports of the same genre. If you find a good fit, add the meta report number to the Blocks field of the report you are triaging.

为评论添加 tag 标记

Comment tags act as notes that help everyone get a quick overview of the comment history and value/relevance of individual comments. Click the tag text in the header of a comment, input your tag and press enter. There is no need to save the report. You can invent new tags or use existing tags. The tag input field supports auto-completion.

Entering one of these tags make the comment hidden by default: obsolete, spam, me-too, off-topic, abusive, no-value, bibisection. You can show a hidden comment by clicking on the "Toggle comment display" widget in the comment header. You can also hide regular comments and show tagged comments by clicking on the tag name of your choosing under the "Comment Tags" list next to the bug description (comment 0). Click Expand all comments to show everything.

Checking Additional Info

As a triager we should try to check the information that was originally reported by the bug reporter. Things to check include:

  • Product
  • Version
  • Platform

将开发者添加到抄送列表 (CC)

This step should only be done if you're sure that it is important enough to CC a developer. If you think that a bug is serious enough that it deserves extra attention but maybe not the status of MAB, then you should seek out an expert for additional input. Please try to use this with care as we don't want to inundate our expert developers with minor bug pings. To add the user simply add their name to the CC list and put a comment on the bug telling the developers why you've added them to the CC Anyway, the right names can be found in the list of experts.

This step should only be done if you're sure that it is important enough to CC a developer. If you think that a bug is serious enough that it deserves extra attention but maybe not the status of MAB, then you should seek out an expert for additional input. Please try to use this with care as we don't want to inundate our expert developers with minor bug pings. To add the user simply add their name to the CC list and put a comment on the bug telling the developers why you've added them to the CC Anyway, the right names can be found in the list of experts.

将 QA 添加到抄送列表

This mostly is not used but if you feel like adding yourself or another QA member to the list might be useful, feel free to do so. Again, please make sure to add a comment if you're adding someone else to the list, otherwise they might get irritated at not knowing what's going on.

This mostly is not used but if you feel like adding yourself or another QA member to the list might be useful, feel free to do so. Again, please make sure to add a comment if you're adding someone else to the list, otherwise they might get irritated at not knowing what's going on.

Most Annoying Bugs

Really critical bugs should be highlighted as Most Annoying Bugs (MABs). Please, think twice here as we need to keep the list on a reasonable level.

Hard Hacks

If a bug seems to be especially hard, affects a substantial amount of users and would be considered a MAB, the bug is a candidate for a hard hack. This list can be found here:

HardHacks wiki

QA 团队 bug 诊断疑难问题

Here are some notes for Advanced Triagers on the QA/Team. If you're new, don't worry about any of this!

很难进行诊断或关闭的 bug

Sometimes we need special software or hardware to reproduce a bug or we face some other difficulty that prevents us from investigating. For these cases we have:

The collection uses the MediaWiki Bugzilla extension, which pulls data from meta reports and various other queries.

扩展

对应 LibreOffice 扩展程序中的 bug, 最好的办法是让扩展的作者加入到诊断中来。Bug 的报告者需要负责联系扩展程序的作者。

参考:

推荐的诊断顺序

下表显示了推荐的 bug 诊断顺序。QA 团队的目标是优先诊断最糟糕的 bug.

The tables below represent a suggested order to approach triaging. The goal of QA is to confirm the worst bugs first.

根据操作系统排列

Description All Bugs Windows Linux macOS Comments
崩溃型 bug (Crashes) CrasherAll CrasherWindows CrasherLinux CrashermacOS These are bugs that have "crash" or some similar word in the title of the bug. For crashers the severity should be set to Major/Critical depending on how many users will be affected. Also, QA should look at if the crash is a regression or not and add "regression" to keywords if the bug is determined to be a regression.
有“倒退”可能性的 bug possibleRegressionAll possibleRegresionWindows possibleRegressionLinux possibleRegressionmacOS These bugs are marked as possibleRegression which is an automatic status given in BSA if a user reporting a bug said that in a particular version the bug was not present. If the bug is a regression, the Keyword "possibleRegression" should be removed and "regression" should be added to the keywords.
关键词中包含 Regression 的 bug RegressionAll RegressionWindows RegressionLinux RegressionmacOS The reporter of the bug or someone else has put regression in the keyword. Equally important as the row above but Bugzilla does not allow an "or" search so had to split into two rows.
报告为 Critical 的 bug CriticalAll CriticalWindows CriticalLinux CriticalmacOS Users can currently set the severity of their own bugs, if the bug is incorrectly marked as critical please change the severity and explain to the user why the bug is not critical. Critical is reserved for very serious bugs (such as data loss which will affect many userse). For guidance see PriorityFlowChart
报告为 Major 的 bug MajorAll MajorWindows MajorLinux MajormacOS Users can currently set the severity of their own bugs, if the bug is incorrectly marked as major please change the severity and explain to the user why the bug is not a major bug. Major is reserved for very serious bugs (such as data loss) but which will likely not affect many users or are only happening in corner cases with individual documents. For guidance see PriorityFlowChart.
所有 Bug AllBugs AllWindows AllLinux AllmacOS List of all bug reports (no enhancements). If the above bugs are tackled first then the ones remaining will be of slightly lower priority to confirm. Suggestion is to do these in chronological order (oldest first so that users who reported the longest time ago get priority).
改进建议 EnhancementAll EnhancementWindows EnhancementLinux EnhancementmacOS Enhancement requests are the lowest priority to confirm as valid requests.

=== 根据组件排列 ===

描述 Writer Calc Impress Draw Base 其他 注释
崩溃型 bug WriterCrasher SpreadsheetCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers If a bug is incorrectly marked as critical please change the severity and explain why the bug is not critical. 'Critical' severity is reserved for only the most serious bugs (such as inability to install LibreOffice). For guidance see PriorityFlowChart
存在“倒退”可能性的 bug WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg These bugs are marked as possibleRegression which is an automatic status given in BSA if a user reporting a bug said that in a particular version the bug was not present. If the bug is a regression, the Keyword "possibleRegression" should be removed and "regression" should be added.
关键词中包含 Regression 的 bug WriterRegression SpreadsheetRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions The reporter of the bug or someone else has put regression in the keyword. Equally important as the row above but Bugzilla does not allow an "or" search so had to split into two rows.
报告为 Critical 的 bug WriterCritical SpreadsheetCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical Users can currently set the severity of their own bugs, if the bug is incorrectly marked as critical please change the severity and explain to the user why the bug is not critical. Critical is reserved for very serious bugs (such as data loss which will affect many userse). For guidance see PriorityFlowChart.
报告为 Major 的 bug WriterMajor SpreadsheetMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor Users can currently set the severity of their own bugs, if the bug is incorrectly marked as major please change the severity and explain to the user why the bug is not a major bug. Major is reserved for very serious bugs (such as data loss) but which will likely not affect many users or are only happening in corner cases with individual documents. For guidance see PriorityFlowChart.
其他 Bug WriterOther SpreadsheetOther PresentationOther DrawingOther DatabaseOther AllOther These are all bugs marked as anything below Major but not including Enhancements.
改进建议 WriterEnhance SpreadsheetEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance 改进建议