如何将回归单元测试与问题跟踪器相关联?

时间:2015-01-18 22:29:16

标签: unit-testing bug-tracking issue-tracking regression-testing

我正在研究一个现有的Web应用程序(用.NET编写),令人惊讶的是,它有一些bug。我们在错误跟踪器(JIRA,在本例中)中跟踪优秀,并且已经有一些测试库(用NUnit编写)。

我希望能够做的是,在关闭问题时,能够将该问题链接到确保不会发生回归的单元/集成测试,并且我希望能够尽可能容易地公开这些信息。

有一些我可以想到的东西,根据我想走多远,它可以在不同的组合中使用:

  • 复制问题的网址并将其粘贴为测试代码中的注释;
  • 为测试添加一个Category属性并将其命名为Regressions,因此我可以明确选择回归测试并将其作为一个组运行(但如何自动报告哪些问题的回归测试失败?);
  • 将问题编号作为测试用例名称的一部分;
  • 创建一个自定义回归属性,该属性将问题的URI作为必需参数;
  • 在问题跟踪器中创建新的自定义字段,以存储回归测试的名称(或路径);

对我来说理想的情况是,我可以查看问题跟踪器,看看已经通过回归测试关闭了哪些问题(给开发人员一个金星!),并查看测试报告,看看哪个问题是失败的回归测试。

有没有人遇到或想出一个很好的解决方案呢?

1 个答案:

答案 0 :(得分:0)

我看不出是什么让回归测试与其他测试不同。为什么你只想运行回归测试或除了回归测试之外的所有事情。如果回归或非回归测试失败,则表示此特定功能无效,产品所有者必须决定问题的严重程度。如果你停止区分测试,那么只需进行代码审查,不允许任何未经测试的提交。

如果我们想看看针对具体问题添加了哪些测试,我们会发布跟踪系统。有所有提交,理想情况下只有一个(感谢压扁),问题跟踪器连接到git所以我们可以轻松浏览更改的文件

如果我们想看(无论出于什么原因)什么问题与某些特定的测试/代码行有关,我们只是给测试一个有意义的商业名称,这有助于找到任何相关的信息。如果问题更具技术性,我们知道可能需要特定问题,那么我们只需在评论中添加问题编号。如果你想自动检索只是标准化评论的格式

另一项有用的技巧是正确构建程序。如果每个功能都有它自己的包,测试打包并有意义地命名,那么它也很容易找到任何相关的代码