质控/测试/倒退测试

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/Testing/Regression Tests and the translation is 100% complete.

    软件的开发者只是普通的人类。他们对源代码的修改,有些时候会导致不可预期的副作用,从而导致新的 bug,或者导致软件运行时的性能下降。“倒退测试”可以帮助我们找到这些问题。这些测试会检查某项特定的功能是否能按照设计的初衷正常工作,从而最终用户可以在日常工作中正常使用。

    倒退测试会在每一个可供测试的新的编译版本中进行。现实情况是,我们没有能力对如此庞大的软件的每个细节在每次发布中都进行细致的测试。因此,我们会对经常使用的功能,在 beta 和 RC 阶段,进行选择性的测试。

    现有的测试

    LibreOffice 有一套定义好的发布周期发布条件。他们是 主版本 X.Y.0,以及他们各自的每日构建版、公开测试版、和候选发布版。同时,会有 bug 修复版本 X.Y.Z,bug 修复版本又有其各自的候选发布版本。以下是需要进行的测试:

    • 冒烟测试需要在每一次 beta 或 RC 发布之前进行。
    • 完整的倒退测试需要在每一次主版本发布前进行。
    • 基本的倒退测试需要在每一次 bug 修复版本发布前进行。

    冒烟测试

    所有的软件包构建都会在正式发布公告前 1-2 天内准备好。我们需要确它们在某种程度上在尽可能多的平台上能够运行。因此,请协助我们进行如下的工作:

    • 监测 libreoffice@lists.freedesktop.org 邮件列表
    • 开发测试版预发布网站上下载您所用平台的包
    • 进行一些基本的操作(例如,在 Writer, Calc, Impress 和 Draw 中打开/保存文件)
    • 如果您发现了一个 bug,导致这个构建版本无法使用,请通过回复发布公告邮件的方式告知我们。回复时,请将所有人保留在邮件的CC抄送列表中。
    • 提交 Bug 报告至 Bugzilla.

    FIXME: 目前有一些自动化测试的尝试。


    完整的倒退测试

    当前,自动化测试 是在软件编译时进行的。


    基本的倒退测试

    纯 bug 修复版本会在主版本发布后的每个月推出。没有时间对这些版本进行完整的倒退测试。开发者会尽量不在这些版本中引入倒退问题,这是通过加强对代码的审核达到的。但是,他们只是普通人类,所以还是有必要对这些版本进行必要的倒退测试。通常,优先级 1 和 2 的测试样例会在这个阶段进行。