jira上bug怎么追溯_X射线在Jira中的双向可追溯性

jira上bug怎么追溯

A while ago I wrote about using Notion to build a test reporting structure that allows for bi-directional traceability from User Story to Test Execution and vice-versa.

前一阵子， 我写过关于使用Notion构建测试报告结构的信息 ，该结构允许从用户故事到测试执行，以及反之亦然的双向追溯。

I then turned that blog into a talk — ‘Test Reporting — Why I Hate Piecharts’ and gave it at my local Ministry of Testing meet-up where I argued the case against test reports being just a number of tests run and a pass rate.

然后，我将该博客转为演讲-“测试报告-为什么我讨厌皮埃尔夏特”，并在我当地的测试部会议上将其介绍给我，我认为测试报告只是大量测试和通过率的理由。

When I started building up a backlog in Jira for the app I’m currently working on I knew that I wanted to have bi-directional traceability between the user stories I was adding and the automated test suite I’d be eventually writing to check everything was working.

当我开始在正在使用的应用程序的Jira中建立积压工作时，我知道我想在要添加的用户故事和最终要编写的自动测试套件之间进行双向可追溯性检查在工作。

The decision I had to make was then — which Jira based test reporting tool to use, Zephyr or X-Ray?

然后，我必须做出的决定是-使用哪种基于Jira的测试报告工具，Zephyr或X-Ray？

I’ve used Zephyr in the past and found it to be really powerful but the custom ZQL language that it uses to query test cases was a little bit of a put off.

我过去使用过Zephyr，发现它确实功能强大，但是用于查询测试用例的自定义ZQL语言有点拖延。

X-Ray on the other hand uses Jira’s JQL so you can build custom views easily anywhere you can use JQL queries.

另一方面，X-Ray使用Jira的JQL，因此您可以在任何可以使用JQL查询的地方轻松构建自定义视图。

X射线入门 (Getting Started with X-Ray)

X-Ray uses Jira tasks as a backing for the entities it uses:

X-Ray使用Jira任务作为其使用的实体的支持：

• Test — A test case to verify behaviour

  测试 —验证行为的测试用例

• Test Set — A grouping of tests

  测试集 —一组测试

• Precondition — Set up for a test case

  前提条件 —设置测试用例

• Test Execution — The actual running of a test case

  测试执行 - 测试用例的实际运行

• Test Plan — A plan of what to test

  测试计划 — 测试内容的计划

If you don’t already have the relevant issue types created you’ll need to create them and configure X-Ray’s mapping, if you’re using a Next-Gen project then you might find that this involves some work as you don’t start with many issue types.

如果尚未创建相关的问题类型，则需要创建它们并配置X-Ray的映射，如果您正在使用Next-Gen项目，则可能会发现这涉及一些工作，因为您没有从许多问题类型开始。

Once you have the mapping in place you’ll then be able to create test cases for your user stories.

一旦映射到位，就可以为用户案例创建测试用例。

X-Ray supports three types of test case structures; Gherkin, Manual and Unstructured which can be used to define how to carry out the test and be used in automation.

X-Ray支持三种类型的测试用例结构： Gherkin，Manual和Unstructured，可用于定义如何执行测试以及如何在自动化中使用。

I’m not a big fan of Gherkin so I chose to go with Unstructured format and link the description to the name of the test in Jest, the test runner I’m using in my project.

我不是Gherkin的忠实拥护者，所以我选择使用非结构化格式，并将描述链接到我在项目中使用的测试运行者Jest中的测试名称。

使事情可追溯 (Making things traceable)

Having floating test cases won’t give you much benefit but you can link them to your user stories and epics using Jira’s issue linking tool and defining a ‘tests’ and ‘tested by’ relationship between the test case and the user story/epic.

拥有浮动测试用例不会给您带来太多好处，但是您可以使用Jira的问题链接工具将它们链接到您的用户故事和史诗，并在测试用例和用户故事/史诗之间定义“测试”和“测试依据”关系。

You can define the relationship to use for traceability in X-Ray’s settings if you want to use a custom one but the default ‘tests’/’tested by’ relationship should cover most use cases.

如果要使用自定义的关系，则可以在X-Ray的设置中定义用于追溯的关系，但是默认的“测试” /“测试依据”关系应涵盖大多数用例。

Once the relationship between the user story/epic and the test case is created you should then see the Coverage section of the user story populated with the test case, over time this will show the status of test executions as they are run.

一旦创建了用户案例/史诗与测试用例之间的关系，您就应该看到填充了测试用例的用户案例的Coverage部分，随着时间的推移，这将显示测试执行的状态。

In Jira Next-Gen projects there’s one new feature that I really like as someone acting as Product Owner, which is the Roadmap view.

在Jira Next-Gen项目中，我确实很喜欢作为产品负责人的一个新功能，即“路线图”视图。

The Roadmap view shows the epics in a Gantt chart and shows you how much of the epic’s stories have been completed.

路线图视图在甘特图中显示史诗，并向您显示史诗的故事已经完成了多少。

If you create a relationship between the test case and the epic then you can also see the test coverage of all stories under the epic which brings your test reporting into this higher level and gives a really powerful insight into the quality of what you’re building.

如果您在测试用例和史诗之间建立关系，那么您还可以查看史诗下所有故事的测试覆盖范围，这将您的测试报告带入更高的层次，并为您构建的质量提供了真正强大的洞察力。

自动化测试报告 (Automating test reporting)

The basic relationship setup will allow you to carry out your manual tests and provide traceability on those but the real benefit of a tool like X-Ray is that you can import test run data and automate this process to run tests across multiple environments.

基本的关系设置将允许您执行手动测试并提供对这些测试的可追溯性，但是像X-Ray这样的工具的真正好处是，您可以导入测试运行数据并使该过程自动化以在多个环境中运行测试。

This automation is something I had done previously with Zephyr, running tests against 20 environments in parallel and using Jira as a dashboard to show the status of the tests for reporting this to the team.

这种自动化是我以前使用Zephyr进行的工作，它在20个环境中并行运行测试，并使用Jira作为仪表板来显示测试状态以将其报告给团队。

X-Ray offers a number of means for automating test case and test execution creation, allowing you to create in bulk via an import or to create on the fly via calls to a set of API endpoints.

X-Ray提供了许多用于自动化测试用例和测试执行创建的方法，允许您通过导入批量创建或通过调用一组API端点即时创建。

If you’re running a suite of tests then I would recommend the bulk import approach as you only need to hit the API once which keeps your test run fast, if you do hit up the API as you run your tests then you’ll have the overhead of the network requests which will add time.

如果您正在运行一组测试，那么我建议您采用批量导入的方式，因为您只需要点击一次API即可保持测试快速运行；如果您在运行测试时确实点击了API，那么您将拥有网络请求的开销，这会增加时间。

For my project I’m using an upload of a JUnit report from Jest generated using the jest-junit test reporter which once configured correctly allowed me to link a test case in Jest to an Acceptance Criteria in my user stories.

对于我的项目，我使用的是Jest的JUnit报告的上载，该报告是使用jest-junit测试报告程序生成的，该报告程序配置正确后，就可以将Jest中的测试用例链接到用户故事中的验收标准。

创建JUnit报告 (Creating JUnit Reports)

I found with jest-junit I had some additional work to do in order to set it up how I wanted it, here’s the config I used:

我发现使用jest-junit要做一些额外的工作，以便按照我的需要进行设置，这是我使用的配置：

module.exports = {
  reporters: [
    'default',
    [
      'jest-junit',
      {
        suiteName: 'Tests',
        classNameTemplate: '{classname}', titleTemplate: '{title}'
      }
    ]
  ],
}

By default the titleTemplate includes the classname which for my use meant I had duplicated titles which threw the test linking off.

默认情况下， titleTemplate包含类名，对我而言，这意味着我有重复的标题，从而导致测试链接断开。

使用X射线进行身份验证以上传测试结果 (Authenticating with X-Ray to upload test results)

In order to use the X-Ray API to upload test results you need to first create an API key, this can be done by going to:

为了使用X-Ray API上传测试结果，您需要首先创建一个API密钥，这可以通过以下操作来完成：

1. Settings (cog icon in top right, not to be confused with project settings)
   设置(右上角的齿轮图标，请勿与项目设置混淆)
2. Apps (bottom of list)
   应用程序(列表底部)
3. API Keys (under the X-Ray heading)
   API密钥(在X射线标题下)

Once you’ve created a client_id and client_secret you’ll then use those to create an auth token which will be used when talking to the API.

创建client_id和client_secret您将使用它们创建一个auth令牌，该令牌将在与API通讯时使用。

You can use the following cURL command to get an authentication token:

您可以使用以下cURL命令获取身份验证令牌：

token=$(curl -H "Content-Type: application/json" -X POST --data @"xray_auth.json" https://xray.cloud.xpand-it.com/api/v1/authenticate| tr -d '"')

The xray_auth.json file looks like:

xray_auth.json文件如下所示：

{"client_id": "[ADD CLIENT ID HERE]", "client_secret": "[ADD CLIENT SECRET HERE]"}

Once you’ve got a token you can then use it in your calls to upload your tests:

获得令牌后，就可以在调用中使用它来上传测试：

curl -H "Content-Type: text/xml" -X POST -H "Authorization: Bearer $token"  --data @"junit.xml" https://xray.cloud.xpand-it.com/api/v1/import/execution/junit?projectKey=[PROJECT KEY]

The junit.xml file is the output from jest-junit or however you’ll be generating your JUnit format test report.

junit.xml文件是jest-junit的输出，但是您将生成JUnit格式的测试报告。

When running this setup in CI I stored the client_id and client_secret in the CI’s secret store and used echo to construct the xray_auth.json file before calling the cURL to generate the token, this allows for the credentials to be stored and used securely without committing to git.

在CI中运行此设置时，我将client_id和client_secret存储在CI的秘密存储区中，并在调用cURL生成令牌之前使用echo来构造xray_auth.json文件，这允许安全地存储和使用凭据，而无需提交git。

测试覆盖率报告 (Test Coverage Reports)

Within Jira you can make use of the test coverage data to help prioritise your backlog items in order to fix technical debt & bugs and you can also use it to see the health of a particular piece of functionality as it progresses through different environments.

在Jira中，您可以利用测试覆盖率数据来帮助确定待办事项的优先级，以解决技术问题和错误，还可以使用它来查看特定功能在不同环境中的运行状况。

Ultimately how you use the test coverage will be dependent on your situation but for my app I’m using it to automate my Acceptance Criteria testing and then using the test results across a range of devices to ensure that my app is working and to highlight where additional development effort may be needed to support older or more obscure set ups.

最终，您如何使用测试范围将取决于您的情况，但是对于我的应用程序，我正在使用它来自动化我的验收标准测试，然后在一系列设备上使用测试结果，以确保我的应用程序正常工作并突出显示在哪里可能需要额外的开发工作来支持较旧或更模糊的设置。

Out of the box X-Ray offers a number of traceability reports and even allows for custom templates for the PDF test run reports, I don’t use these though as I’m of the opinion that test reports are never actually used and just go into inboxes to die.

X-Ray开箱即用地提供了许多可追溯性报告，甚至允许为PDF测试运行报告提供​​自定义模板，尽管我不使用这些，但我认为测试报告从未实际使用过，只是去了即可。进入收件箱就死了。

For me the real power of a tool like X-Ray is to be able to use dashboards and other dynamic reporting tools to see the data, query it and explore the links between different tickets to uncover the real quality issues impacting the product instead of just checking that some tests have been run.

对我来说，像X-Ray这样的工具的真正力量是能够使用仪表板和其他动态报告工具来查看数据，查询数据并探索不同标签之间的链接，以发现影响产品的实际质量问题，而不仅仅是检查是否已运行某些测试。

翻译自: https://medium.com/swlh/bi-directional-traceability-in-jira-with-x-ray-c070729afa06

jira上bug怎么追溯