java - 在UI和其余Api之间造成缺陷的差异

Question

在UI上创建缺陷时，不能仅将其分配给测试用例，而是自动分配用户案例。如果我尝试删除用户故事，测试用例也会消失。

但是通过restApi，我只能涉及测试用例，而无需提及用户故事。

我认为这是一个错误，因为无论您如何创建缺陷，行为都应该相似。

我没有提到它，但是我们总是有与用户案例相关的测试用例。

Answer 1

可以通过API和UI将缺陷与用户案例和测试用例相关联。但这是在特殊情况下发生的，首先将故事与测试案例相关联，然后将缺陷与该案例相关联，然后单击缺陷详细信息页面上的TestCase字段，它将在选择器中显示唯一选项-已经与故事关联的测试用例。

接下来是令人困惑的。

有两种方法可以将测试用例与Rally UI中的缺陷相关联：

使用“详细信息”页面上的“测试用例”字段

使用“详细信息”页面左侧的“测试用例”链接

这不仅会导致UI中的操作不一致，而且还会在用户检查WS API请求的结果时引起混乱。

假设使用“缺陷”详细信息页面上的“测试用例”字段将现有TestCase与一个缺陷相关联，然后使用左侧的“测试用例”链接将一个新的测试用例与该缺陷相关联。

此时，我们有两个与同一个缺陷关联的独立测试案例：TC7和TC59。

但是，当我们查询此Defect及其TestCases集合时，它仅显示一个TestCase（在我的示例中为TC59），它是通过左侧的“ Test Cases”链接添加的。

这是获取TestCases集合的第一个查询：

https://rally1.rallydev.com/slm/webservice/v2.0/defect?workspace=https://rally1.rallydev.com/slm/webservice/v2.0/workspace/1111&query=(FormattedID%20%3D%20DE19)&fetch=TestCases

和第一个查询返回的结果：

{ 
QueryResult: { 
_rallyAPIMajor: "2", 
_rallyAPIMinor: "0", 
Errors: [ ], 
Warnings: [ ], 
TotalResultCount: 1, 
StartIndex: 1, 
PageSize: 20, 
Results: [ 
{ 
_rallyAPIMajor: "2", 
_rallyAPIMinor: "0", 
_ref: "https://rally1.rallydev.com/slm/webservice/v2.0/defect/12655123753", 
_refObjectUUID: "91f66a35-d860-41e0-a10d-db6dad460f28", 
_objectVersion: "7", 
_refObjectName: "Error found in US20: story C2", 
TestCases: { 
_rallyAPIMajor: "2", 
_rallyAPIMinor: "0", 
_ref: "https://rally1.rallydev.com/slm/webservice/v2.0/Defect/12655123753/TestCases", 
_type: "TestCase", 
Count: 1 
}, 
_type: "Defect" 
} 
] 
} 
}

使用我们从第一个查询的结果中获得的TestCases集合的URI，我们运行了另一个查询来检查集合本身，为简便起见，仅提取FormattedID和WorkProduct：

https://rally1.rallydev.com/slm/webservice/v2.0/Defect/12655123753/TestCases?fetch=FormattedID,WorkProduct 

结果仅包括TC59：

https://rally1.rallydev.com/slm/webservice/v2.0/Defect/12655123753/TestCases?fetch=FormattedID,WorkProduct 

{ 
QueryResult: { 
_rallyAPIMajor: "2", 
_rallyAPIMinor: "0", 
Errors: [ ], 
Warnings: [ ], 
TotalResultCount: 1, 
StartIndex: 1, 
PageSize: 20, 
Results: [ 
{ 
_rallyAPIMajor: "2", 
_rallyAPIMinor: "0", 
_ref: "https://rally1.rallydev.com/slm/webservice/v2.0/testcase/17593081118", 
_refObjectUUID: "dbdbd621-97f7-4c27-b24a-f0ca92be73ff", 
_objectVersion: "1", 
_refObjectName: "Error found in US20: story C2", 
FormattedID: "TC59", 
WorkProduct: { 
_rallyAPIMajor: "2", 
_rallyAPIMinor: "0", 
_ref: "https://rally1.rallydev.com/slm/webservice/v2.0/defect/12655123753", 
_refObjectUUID: "91f66a35-d860-41e0-a10d-db6dad460f28", 
_objectVersion: "7", 
_refObjectName: "Error found in US20: story C2", 
FormattedID: "DE19", 
_type: "Defect" 
}, 
_type: "TestCase" 
} 
] 
} 
} 

接下来，我们要通过Web服务API创建一个新的TestCase，并将其与相同的Defect DE19关联。
重要：通过左侧的“测试用例”链接将新TestCase与缺陷关联的UI方法等效于WS API中的以下POST请求。

在此示例中，“ WorkProduct”：“ / defect / 12655123753”引用相同缺陷的ObjectID。

要求网址：

https://rally1.rallydev.com/slm/webservice/v2.0/testcase/create?key=7b193d4b....

有效负载：

{ 
"TestCase":{ 
"Name": "some tc", 
"WorkProduct":"/defect/12655123753" 
} 
}

我们在UI中验证WS API创建请求是否成功。
接下来，我们查询相同的TestCases集合，并按预期看到两个结果。这次为了简洁起见仅提取FormattedID。返回TC59和TC60。

https://rally1.rallydev.com/slm/webservice/v2.0/Defect/12655123753/TestCases?fetch=FormattedID 

如我们所见，该查询未返回通过Defect的详细信息页面上的“测试用例”字段在UI中创建的TC7。在Web Services API中，缺陷对象具有与此讨论相关的两个属性：TestCase和TestCases。

该查询：

https://rally1.rallydev.com/slm/webservice/v2.0/defect?workspace=https://rally1.rallydev.com/slm/webservice/v2.0/workspace/1111&query=(FormattedID%20%3D%20DE19)&fetch=TestCase,FormattedID

返回TC7：

{ 
QueryResult: { 
_rallyAPIMajor: "2", 
_rallyAPIMinor: "0", 
Errors: [ ], 
Warnings: [ ], 
TotalResultCount: 1, 
StartIndex: 1, 
PageSize: 20, 
Results: [ 
{ 
_rallyAPIMajor: "2", 
_rallyAPIMinor: "0", 
_ref: "https://rally1.rallydev.com/slm/webservice/v2.0/defect/12655123753", 
_refObjectUUID: "91f66a35-d860-41e0-a10d-db6dad460f28", 
_objectVersion: "9", 
_refObjectName: "Error found in US20: story C2", 
FormattedID: "DE19", 
TestCase: { 
_rallyAPIMajor: "2", 
_rallyAPIMinor: "0", 
_ref: "https://rally1.rallydev.com/slm/webservice/v2.0/testcase/12476557645", 
_refObjectUUID: "a8d50053-e250-43c1-aebc-58472fec2988", 
_objectVersion: "10", 
_refObjectName: "myTS3", 
FormattedID: "TC7", 
_type: "TestCase" 
}, 
_type: "Defect" 
} 
] 
} 
} 

既然我们知道如何在通过UI和WS API将TestCase添加到Defect的TestCases集合中的情况下，将TestCase与Defect关联起来，我们想要找到一个与将TestCase与带有TestCase的Defect关联的API等效的API。

我们将使用没有链接到故事的缺陷，因为原始缺陷（在我的示例中为DE19）已经链接了US20。根据WS API文档中有关Defect的TestCase属性的注释，只需指定其中一个即可。

注意此缺陷所涉及的测试用例。可以指定Requirement或TestCase，但不能同时指定。

我们将向对象ID 14710889543引用的另一个缺陷DE81添加一个由ObjectID 14604252931引用的预先存在的TestCase：

要求网址：

https://rally1.rallydev.com/slm/webservice/v2.0/defect/14710889543?key=7b193d4b-.... 

有效负载：

{"Defect":{ 
"TestCase":"/testcase/14604252931" 
} 
} 

请注意，如果此时第二个Defect DE81与UI中的随机故事相关联，则与TestCase的关联将被删除，而不会出现任何错误或警告。

现在，这变得更加令人困惑。在第一个Defect的DE19详细信息页面上，我们看到它同时具有US20和TC7。似乎无法使用详细信息页面上的“测试用例”字段将DE81与TestCase关联。当我们单击放大镜图标时，选择器对话框为空。事实证明，将DE81关联到UserStory和TestCase的唯一方法是创建一个与UserStory关联的新TestCase。

这两个步骤如下：
一个。将用户故事链接到TestCase
b。返回“缺陷”，然后在详细信息页面上单击“测试用例”字段。这次，选择器对话框将使用上面创建的新TestCase进行填充。
现在，TestCase和UserStory都与此缺陷相关联。

如果此时尝试将TC61替换为与UserStory不相关的其他TestCase，它将失败。如果通过API进行此尝试，如下所示：

要求网址：

https://rally1.rallydev.com/slm/webservice/v2.0/defect/14710889543?key=7b193d4b-.... 

有效负载：

{"Defect":{ 
"TestCase":"/testcase/14604252931" 
} 
} 

这将导致此错误：

{"OperationResult": {"_rallyAPIMajor": "2", "_rallyAPIMinor": "0", "Errors": ["Validation error: Defect.TestCase is an invalid relationship "], "Warnings": []}}

UPDATE re：在Stella的评论中描述的案例：

在UI中创建了一个名为StoryG的UserStory
/ userstory / 17824476422

通过详细信息页面左侧的TestCases链接将新的TestCase与之关联。
/ testcase / 17824476889

现在，此TestCAse通过User Story上的TestCases集合与该故事相关联。

接下来，通过API创建缺陷：

https://rally1.rallydev.com/slm/webservice/v2.0/defect/create?key=733c0893-0e5b-4c66-8204-9a2afa548d36

有效负载：

{"Defect":{ 
"Name":"Bug with StoryG",
"Requirement":"/hierarchicalrequirement/17824476422",
"TestCase":"/testcase/17824476889"
}
}

这行得通：新缺陷与UserStory和TestCase都关联。
实际上，这与UI一致。使用API​​时，必须在有效负载中同时引用 Requirement和 TestCase。并且在UI中创建缺陷时，必须同时指定两者：请参见响应的第一段。选择TestCase时，TestCase选择器仅显示一个选项：已经与UserStory关联的TestCase。

以下是无法使用的方案，该方案在API和UI之间是一致的。
让我们看看如果我尝试将不相关的UserStory和TestCase链接到缺陷会发生什么

创建了一个用户故事StoryH
/ userstory / 17824480704

通过详细信息页面左侧的TestCases链接将新的TestCase与之关联。
/ testcase / 17824481042

现在，此TestCase通过User Story上的TestCases集合与该故事相关联。

接下来，在创建缺陷时引用不相关的TestCase：/ testcase / 17824638756

https://rally1.rallydev.com/slm/webservice/v2.0/defect/create?key=733c0893-0e5b-4c66-8204-9a2afa548d36

有效负载：

{"Defect":{ 
"Name":"Bug with StoryH",
"Requirement":"/hierarchicalrequirement/17824480704",
"TestCase":"/testcase/17824638756"
}
}

这将返回预期的错误，并且与UI一致：

{"CreateResult": {"_rallyAPIMajor": "2", "_rallyAPIMinor": "0", "Errors": ["Validation error: Defect.TestCase is an invalid relationship "], "Warnings": []}}

还有另一种方法可以关联此缺陷用户故事测试用例三角形的所有成员。
在这里可以观察到UI和API之间的差异：

在用户界面中：

a）使用故事详细信息页面左侧的TestCases链接，将用户故事与测试用例相关联
b）创建新缺陷，并使用“缺陷”详细信息页面上的“测试用例”字段将其与测试用例关联。

从测试用例选择器中选择了一个测试用例后，故事会自动显示。

在API中：

a）使用故事详细信息页面左侧的TestCases链接，将用户故事与测试用例相关联
b）使用浏览器的REST客户端创建缺陷，同时设置其TestCase字段，并期望故事自动链接。

https://rally1.rallydev.com/slm/webservice/v2.0/defect/create?key=5e10c58...

有效负载：

{"Defect":{ 
"Name":"Bug with TC77",
"TestCase":"/testcase/17866645137"
}
}

测试用例详细信息页面左侧的Defects（1）链接显示了新创建的缺陷。
但是，“缺陷”的详细信息页面没有显示故事。
我提交了一个错误。

回顾这个三角形，它出现在WS API中：


缺陷-该工件可以通过Requirement属性引用UserStory，并通过TestCase属性引用TestCase。
每个WSAPI文档都说可以有一个，但不能两个都有。链接这三个工件时，它们必须全部一致。
如果将缺陷定义为指向“用户故事”和“测试用例”，那么这两个缺陷也必须彼此指向，这实际上是“要么/或”规则的例外。
缺陷上的TestCase属性与缺陷上的TestCases集合完全分开。
UserStory-该工件具有TestCases集合和Defect集合。
TestCase-该工件可以通过WorkProduct属性具有指向Requirement（这是一个UserStory）的指针。