我目前正在使用 NUnit 构建我的自动化框架,我已经让一切正常,我想做的最后一个增强是能够将我的自动化测试脚本映射到我的测试软件中的测试用例。
我正在为我所有的测试用例使用 TestRail。
我的理想情况是能够在测试轨道中使用相应的测试用例 ID 装饰每个测试用例,当涉及到在 TestRail 中报告测试结果时,我只能使用 Case ID。 目前我正在通过匹配测试名称/脚本名称来执行此操作。
例-
[Test]
[TestCaseId("001")]
public void NavigateToSite()
{
LoginPage login = new LoginPage(Driver);
login.NavigateToLogInPage();
login.AssertLoginPageLoaded();
}
然后在我的拆解方法中,它会是这样的——
[TearDown]
public static void TestTearDown(IWebDriver Driver)
{
var testcaseId = TestContext.CurrentContext.TestCaseid;
var result = TestContext.CurrentContext.Result.Outcome;
//Static method to report to Testrail using API
Report.ReportTestResult(testcaseId, result);
}
我刚刚组成了testcaseid属性,但这就是我正在寻找的。
[测试用例ID("001")]
如果它已经存在,我可能会错过这个,或者我该如何扩展 NUnit 来做到这一点?
您可以使用NUnit 提供的PropertyAttribute
。
例:
[Property("TestCaseId", "001")]
[Test]
public void NavigateToSite()
{
...
}
[TearDown]
public void TearDown()
{
var testCaseId = TestContext.CurrentContext.Test.Properties["TestCaseId"];
}
此外,您还可以创建自定义属性属性 - 请参阅 NUnit 链接
多年来,我建议人们不要这样做:将测试管理代码混合到测试本身中。这显然违反了单一责任原则,并且给维护测试带来了困难。
此外,还有一个问题是,拆解中呈现的结果可能不是最终的。例如,如果您在测试中使用了[MaxTime]
并且它超过了指定的时间,则成功的测试将更改为失败。其他几个内置属性以这种方式工作,当然始终存在用户创建属性的可能性。TearDown 的目的是清理代码,而不是作为创建报告或测试管理系统的跳板。
也就是说,对于旧版本的 NUnit,人们养成了这样做的习惯。这部分是由于NUnit插件(我们设计的方法)编写起来相当复杂。问题也较少,因为 NUNit V2 在测试端的可扩展性明显较差。在 3.0 中,我们提供了一种创建测试管理函数的方法,例如作为 NUnit 引擎的扩展,我建议您考虑使用该工具,而不是将它们与测试代码混合在一起。
一般的方法是创建一个属性,正如Sulo的答案中所建议的那样,但将TearUp代码替换为将结果报告给TestRail的EventListener扩展。EventListener 可以以 XML 格式访问所有结果信息,而不仅仅是 TestContext 中可用的有限字段。你可以很容易地提取任何需要去TestRail的东西。
编写 TestEngine 扩展的详细信息可在此处找到:https://github.com/nunit/docs/wiki/Writing-Engine-Extensions
请注意,如果要在我们正在处理的Visual Studio适配器下使用扩展,则存在一些未决问题。现在,您将获得使用控制台运行程序的最佳体验。