质控/Bug整理

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/BugTriage and the translation is 90% complete.
    Outdated translations are marked like this.

    文档基金会 LibreOffice官网 Document Liberation 项目 社区博客 Weblate翻译 Nextcloud Redmine Ask LibreOffice 问答 捐助

    Other languages:


    简介

    此页面提供了诊断 LibreOffice 中 bug 的方法、详细步骤及注意事项。“诊断”一词，指的是确认、设置优先级、组织 bug 报告的一系列过程。这个过程其实很简单，即使没有编程经验的非开发者也可以胜任这个角色。这个过程对于确保 LibreOffice 的稳定性和用户体验非常非常非常重要。

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

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

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

    Bug 诊断步骤

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

    步骤概述

    1. 找到要诊断的 bug
    2. 对 bug 报告进行预先筛查
    3. 查找重复的 bug
    4. 检查 bug 报告中的信息，确保完整
    1. 尝试重现这个 bug
    2. 设置这个 Bug 的 Status（状态）
    3. 设置这个 bug 的优先级顺序
    4. 通知开发者（仅在必要时，比如这个 bug 是一个 Blocker/致命的缺陷）

    步骤详情

    准备工作

    通常情况下，要开始 bug 整理，您需要按照以下步骤进行准备工作。 首先在 bugzilla 上创建账户，然后登录。我们建议您在 preferences 页面将 'Automatically add me to the CC list of bugs I change' 设置为 'Only if I have no role on them'，这样就能确保您参与过的 bug 有任何更改时能随时收到提醒。

    第一步：找到要诊断的 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 团队进行判断。

    1. 在 Keywords 字段中加入 'needsUXEval' 关键词，意思是这个 bug 需要 UX 团队的评估
    2. 将这个邮件地址加入到 CC 列表： libreoffice-ux-advise@lists.freedesktop.org
    3. 更新状态
      • 如果这项请求是完整的，而且看似有理：Status -> NEW
      • 如果这项请求看起来不完整，或者需要进一步解释：Status -> NEEDINFO
    2. 添加下列的评论：
    UX Team -- please take a look at this enhancement. Thanks!

    有一些 bug 不应当在 Bugzilla 上报告，这些情况以及应当报告的位置，请见：“缺陷报告页面。

    • 如果不应当报告在 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

    “重复的 bug”是指，由不同的人报告的非常类似或者完全相同的 bug。若存在重复的 bug，通常情况下您需要保留包含最完整、最有用信息的那个 bug 的 NEW 状态，并将另外的 bug 设置为 RESOLVED DUPLICATE。因此，尽管存在一个很早之前报告的 bug，如果这个老 bug 包含的信息不全或者容易让人迷惑，就没必要保持它的 open 状态。 已经关闭的 bug 会被加入到以下位置的 Bugzilla 统计清单中：最常报告的 Bug。在 Bug 整理过程中，请检查这个清单，并快速地搜索一下 Bugzilla 以检查是否存在重复的报告。您没必要花费太多时间去检查是否有重复的 bug, 当经手的 bug 多了之后，您自然就熟练了，不通过搜索也能知道哪些是重复的。

    如果您找到了重复的 bug, 那么请转到第五步

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

    检查并核对 bug 中的信息，这对于软件开发非常重要。您应该重点关注以下信息：

    1. Bug 的概述（即标题，Summary 字段）清晰易懂。
    2. 有清楚的问题描述。
    3. 列出了重现问题的步骤。但是，如果从标题或问题描述能够很容易肯出重现步骤，则这个信息可以不包含。
    4. 附件 -- 很多情况下，需要有用于测试的附件才能重现该问题，否则根本无法修复该问题。
    5. If the report refers to external data (screenshots, documents, screencasts, etc.), copy and attach them to the bug, so they don't vanish later and eventually render it unreproducible.

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

    第五步：尝试重现

    如果这个 bug “通过”了以上的“准备”环节，那么下一步我们将尝试重现该 bug.

    尝试重现步骤很简单：根据 bug 报告中提供的重现步骤进行操作，看看 bug 行为能不能在您的系统上出现。就这么简单！ 如果您能重现，那么您需要注意以下问题：

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

    第六步：设置状态

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

    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: Bug 会由于很多种原因被设置为 invalid（无效），但是这通常情况下需要征求其他 QA 团队成员的观点。如果您遇到了一个可能是无效的 bug，最好的方式是通过 QA IRC 频道或者邮件列表获得其他成员的建议，并解释您为何认为这个 bug 是无效的。
    6. UNCONFIRMED: 这个状态是所有已经报告、但是尚未经过整理的 bug 的初始状态。需要注意的是，这些未经整理的 bug 也可能存在于 NEEDINFO 状态。

    任何时候，当您作出一项更改时，您应当留下一条评论，礼貌性地解释您为何进行这项更改

    下面的流程图展示了设置 STATUS 字段状态的思维流程图。如果您有更好的版本，尽管上传到这里来。
    PDF 文件
    LibreOffice Draw 绘图文件

    第七步：倒退测试

    使用一个老版本的 LibreOffice，检查这个 Bug 是否在 LibreOffice 诞生的时候就已经存在了。

    下载并安装几个老版本的 LibreOffice，最老的是LibreOffice 3.3. 您至少应当安装几个老的已发布主版本 (3.x, 4.x, 5.x, 6.x...).

    您需要了解一些背景信息，以便确定各项新功能是在何时被添加到哪个版本中的，从而避免进行大量无用的测试。如果您不确定，请咨询其他团队成员。

    • 如果该 bug 在 3.3.0 版本中可以重现，请将 version 字段设置为 "inherited from OOo" 并添加如下的评论：
    This bug is already present in Libreoffice 3.3.0

Changing version to "inherited from OOo"
    • 如果该 bug 在 3.3.0 版本中不能重现，请在 keywords 字段中添加 "regression" 关键词，并添加如下的评论：
    This bug is not present in Libreoffice 3.3.0, thus it's a regression

    对于早于 3.5.0 版本的倒退型 bug, 请同时在 keywords 字段中添加 preBibisect 关键词。对于比这个版本新的倒退型 bug，添加关键词 bibisectRequest，并将 version 字段修改为已知的能重现该 bug 的最早版本。

    第八步：设置优先级

    我们当前只会将 致命的 bug，通过将开发者添加到到 CC 抄送列表并添加关键词的方式，进行 高亮 提示。更多信息请见下方。

    Bug 的整理过程确实是带有很大主观性的，但是整理者应当总是尝试在决定 bug 的优先级的标准问题上保持一致性。QA 团队的 bug 整理者必须对什么样的 bug 应当被赋予什么样的优先级有一个清晰的思路，并自始至终坚持这样的方法。同时，整理过程中在 bug 中添加评论很重要，因为这会让 bug 报告者、开发者以及其他用户知道您是依据什么标准将这个 bug 标记为这样的优先级的。

    要想将 bug 标记为 medium-normal 以上的优先级，您需要位于 Bugzilla 的“贡献者”群组中。要获得这样的权利，请联系 Bugzilla 管理员。

    下面的流程图简单展示了对 bug 进行优先级设置的指引。

    Example 1 JPG

    Example 1 Draw

    通常，决定这个 bug 的严重程度比尝试去思考合适的优先级更容易一些。

    类似对用户界面的“微调”这样的问题，可以被视为 low 优先级且 trivial 严重性。

    能让你恼火的、但是您还能忍受，或者存在“变通”做法以绕过这个问题的 bug，可以赋予其 minor 严重性。

    使得某些功能损坏、且没有“变通”做法的 bug，通常属于 normal 严重性。

    由于某些特殊的文件或者特殊的命令导致的程序崩溃、卡死等影响使用的问题，通常属于 major 严重性。

    一些有用的额外步骤（可选）

    Keywords（关键词）

    Keywords 字段储存了用于区分 bug 分类的关键词信息。

    关键词的一些常见类别包括：

    其中一个有趣的关键词是 needsDevEval。在 Bugzilla 上，被标记为 easyHack 关键词的 bug 是指修复这个 bug 不需要花费太多的时间，因此一个新人开发者或者没有太多编程知识的开发者即可胜任这项工作。作为 QA 团队的成员，我们不应当将 bug 随意标记为 easyHack, 这项标记工作应当由开发者来做，因为这需要额外的步骤（比如找到另外一个开发者以指导该 bug 的修复）。如果您认为某个 bug 属于 easyhack, 那么请将其标记为 needsDevEval。

    崩溃型的报告

    对于崩溃型的 bug，生成的“崩溃报告”（也叫 backtrace）可以极大程度上方便开发者快速定位造成崩溃问题的根源。如果某个 bug 报告已经包含了 backtrace，那么请添加 havebacktrace 关键词。

    “元”报告（Meta Bugs）

    您可以在现有的“元报告”页面查看我们收集的同类型的 Bug 清单。如果您找到了适合这些元报告的 bug，请将这个元报告的编号添加到您正在整理的这个 bug 的 Blocks 字段。

    给评论添加标记

    您可以给 bug 中的评论添加 tag 标记，这相当于一个笔记，对于帮助其他人快速审阅评论历史及评论相关性很有帮助。要添加 tag 标记，请点击评论头部的 tag 链接，输入您的 tag，然后按下回车键。添加 tag 之后您不需要保存整个 bug 报告。您可以创造新的 tag，或者使用现有的 tag。Tag 输入框支持自动完成功能。

    输入下列 tag 中的一个，可以将该项评论在默认情况下隐藏： obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise. 您可以点击评论头部的 "Toggle comment display" 以显示隐藏的评论。您也可以隐藏普通的评论，或通过点击 comment 0 中描述里的 "Comment Tags" 清单中某个 tag 名称以显示该 tag 下的评论。点击 Expand All Comments 可以显示所有评论。

    检查额外的信息

    作为一名 bug 整理者，我们应当检查 bug 报告者在原报告中提供的信息。应当检查的信息报告：

    • 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 does not belong in the category of Most Annoying Bugs, 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 添加到抄送列表

    如果您觉得将您自己或另外一个 QA 团队成员加入到这个清单中可能有用，那么尽管去做吧。但是，在添加别人到清单中时，请务必同时添加一条评论，否则别人收到邮件提示后会一脸蒙，不知道发生了什么。

    Interoperability testing

    If the requirement for testing is opening or saving a file with Microsoft Office and you don't have access to the software, you might make use of Office Web Viewer. It works with Word, Excel, PowerPoint and ODF documents. You need to upload the document somewhere and then add the URL to the end of this link:

    https://view.officeapps.live.com/op/view.aspx?src=

    You can then click the Print button in the top menu and finally Open PDF to get access to a PDF rendering of the document. This will both allow you to see how the document looks like in the latest version of Microsoft Office and share the PDF in Bugzilla.

    Bugzilla attachment links work with the viewer.

    To conveniently use the live viewer in Firefox
    • Add a new bookmark
    • Set some Name
    • Set the URL to:
    https://view.officeapps.live.com/op/view.aspx?src=%s
    • Set a Keyword, such as lv, press OK.
    • Now you can use the bookmarks keyword plus a bugdoc URL in the URL bar to open the bugdoc in the Office live viewer:
    lv https://bugs.documentfoundation.org/attachment.cgi?id=180059

    QA 团队 bug 整理特殊问题

    以下是一些针对 QA 团队的高级整理者的笔记。如果您是新人，请放心忽略！

    很难进行整理或关闭的 bug

    有些时候，我们需要一些特殊的硬件或软件环境，从而才能重现某个 bug。同时，我们可能会面临其他困难，阻止我们进一步调查这个 bug。针对这些情况，我们有：

    该清单使用了 MediaWiki Bugzilla 扩展程序，从“元报告”或其它查询中抓去数据。

    扩展

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

    参考：

    Locale-related controversy

    Sometimes we are faced with hot topics related to locales. There might be a situation where a national standard for something differs from the actual practice. In these cases, it can be useful to direct the issue reporter to the Unicode Common Locale Data Repository and their survey tool.

    推荐的诊断顺序

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

    根据操作系统排列

    描述 所有 Bug Windows Linux macOS 注释
    崩溃型 bug (Crashes) CrasherAll CrasherWindows CrasherLinux CrashermacOS 以下是一些标题中包含 "crash" 或者类似词语的报告。对于崩溃型的报告，其严重性应当被设置为 Major 或 Critical，取决于有多少用户受到了影响。同时，QA 团队应当检查这个崩溃问题是否属于“倒退”，如果是的话请添加 "regression" 关键词。
    有“倒退”可能性的 bug possibleRegressionAll possibleRegresionWindows possibleRegressionLinux possibleRegressionmacOS 如果确认该bug属于regression, 那么关键词"possibleRegression"应当被移除，并添加关键词"regression"。
    关键词中包含 Regression 的 bug RegressionAll RegressionWindows RegressionLinux RegressionmacOS 报告者或者其他人已经给这个 bug 添加了 regression 关键词。与上面的部分同样重要，但是 Bugzilla 不允许使用 "or" 进行搜索，因此被单独拆分成了两行。
    报告为 Critical（致命型）的 bug CriticalAll CriticalWindows CriticalLinux CriticalmacOS 只有具有特殊权限的用户才能将bug的严重性程度设置为critical (严重)。Critical 只为特别严重的 bug 预留（例如导致数据丢失并影响到大量用户的 bug）。具体的指南，请见优先级流程图。
    报告为 Major 的 bug MajorAll MajorWindows MajorLinux MajormacOS 只有具有特殊权限的用户才能将bug的严重性程度设置为major (主要的)。Major 只为特别严重的 bug 预留（例如导致数据丢失，但不会影响到太多用户，或者仅在极为特殊的情况下或一些特殊的文件中才能重现的 bug）。具体的指南，请见优先级流程图。
    所有 Bug AllBugs AllWindows AllLinux AllmacOS 所有的 Bug 报告清单（不含“改进建议”类）。如果上面的 bug 整理的差不多了，那么剩下的就是优先级比较低的需要确认的 bug 了。我们建议您按照发生时间顺序进行（最早报告的 bug 优先进行整理）。
    改进建议 EnhancementAll EnhancementWindows EnhancementLinux EnhancementmacOS “功能改进建议（Enhancement Requests）”类的 bug 优先级最低，对于这些 bug 您在整理时需要评估它是否属于有效的请求。

    根据组件排列

    描述 Writer Calc Impress Draw Base 其他 注释
    崩溃型 bug WriterCrasher SpreadsheetCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers Critical 只为特别严重的 bug 预留（例如导致数据丢失并影响到大量用户的 bug）。具体的指南，请见 优先级流程图。
    存在“倒退”可能性的 bug WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg 如果该 bug 经检查确实是个 regression, 那么请移除 "possibleRegression" 关键词，并添加 "regression" 关键词。
    关键词中包含 Regression 的 bug WriterRegression SpreadsheetRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions 报告者或者其他人已经给这个 bug 添加了 regression 关键词。与上面的部分同样重要，但是 Bugzilla 不允许使用 "or" 进行搜索，因此被单独拆分成了两行。
    报告为 Critical 的 bug WriterCritical SpreadsheetCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical 只有具有特殊权限的用户才能将bug的严重性程度设置为critical (严重)。Critical 只为特别严重的 bug 预留（例如导致数据丢失并影响到大量用户的 bug）。具体的指南，请见优先级流程图。
    报告为 Major 的 bug WriterMajor SpreadsheetMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor 只有具有特殊权限的用户才能将bug的严重性程度设置为major (主要的)。Major 只为特别严重的 bug 预留（例如导致数据丢失，但不会影响到太多用户，或者仅在极为特殊的情况下或一些特殊的文件中才能重现的 bug）。具体的指南，请见优先级流程图。
    其他 Bug WriterOther SpreadsheetOther PresentationOther DrawingOther DatabaseOther AllOther 这里是所有被标记为 Major 优先级以下的 bug，但不包括改进建议类。
    改进建议 WriterEnhance SpreadsheetEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance 改进建议
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/BugTriage/zh-cn&oldid=774317"