65.9K
CodeProject 正在变化。 阅读更多。
Home

使用 Watin 在 ASP NET MVC 中进行自动化 UI 测试

Robert Corvus
starIconstarIconstarIconstarIcon
emptyStarIcon
starIcon

4.83/5 (5投票s)

2010年8月28日

CPOL

5分钟阅读

viewsIcon

45301

downloadIcon

870

如何在 ASP NET MVC 中使用 Watin 创建自动浏览器测试。

引言

您是否曾经成功构建项目并使所有单元测试都通过，却发现当您尝试登录时应用程序崩溃？如果有一个“冒烟测试”可以自动验证用户是否真的可以访问 Web 应用程序并成功登录，那岂不是更好？使用免费的开源 Watin（发音为“watt inn”）在您的测试项目中，您可以使用真实的浏览器自动测试用户如何与您的 Web 应用程序进行交互，包括登录、页面加载、按钮点击和表单提交。此外，Watin 使用页面上 HTML 元素的 ID 或文本来填充文本框、点击按钮等，这意味着您可以更改页面上元素的位置，而无需更新您的 UI 测试。

下面是具体实现方法。

Watin 和 NUnit

首先，将 nunit.framework.dll、WatiN.Core.dll 和 Interop.SHDocVw.dll 添加到您的程序集文件夹，并在您的测试项目中引用它们。您可以从这里下载 Watin 的当前版本，从这里下载 NUnit。

您不需要 Resharper 来运行 NUnit 测试，但它很有用。您可以从这里下载 Resharper 的试用版。

App.Config

接下来，我们为 Watin 设置 app.config。

在 configSections 节点中添加此部分配置

<sectionGroup name="NUnit">
    <section name="TestRunner" type="System.Configuration.NameValueSectionHandler"/>
</sectionGroup>

然后，由于 Internet Explorer 浏览器实例需要在单线程模式下运行，请在 configSections 节点之后的 configuration 节点中添加此部分。

<NUnit>
<TestRunner>
    <!-- Valid values are STA or MTA (Others are ignored) -->
    <add key="ApartmentState" value="STA" />
</TestRunner>
</NUnit>

最后，由于我们的根 URL 可能因环境（例如集成服务器）而异，请将此键添加到 appSettings 节点

<add key="RootURL" value="https:///1423/"/>

我们的基础测试

接下来，我们创建一个 BaseUITest ，其中包含我们的 Internet Explorer 实例，该实例被所有测试用于实际打开浏览器并访问我们的 Web 应用程序。我们不希望在测试运行时浏览器到处弹出，因此在打开浏览器实例之前，我们需要将 MakeNewIeInstanceVisible 设置为 false 。这将隐藏测试浏览器在测试运行期间的所有实例。如果您想观看一个模拟用户打开浏览器窗口并填写表单（这看起来相当酷），请注释掉此行或将其设置为 true。

Settings.Instance.MakeNewIeInstanceVisible = false;

我们的单个测试将使用相同的浏览器会话，并通过单个浏览器实例导航到不同的页面。在我们的测试中，我们希望从访问登录页面开始（并且如果您的网站的其余部分需要登录才能继续，您可能也想登录）。

browser = new IE(rootURL + "Account/LogOn");

最后，您应该始终等待页面或操作完成，否则可能会在运行时出现错误。

browser.WaitForComplete();

在 TestFixtureTearDown 中，我们关闭任何打开的浏览器实例（即使它们被隐藏）。注意：这将关闭您在桌面上正在使用的任何 Internet Explorer 浏览器，但 Internet Explorer 允许您在重新打开浏览器后立即恢复这些会话。

if (browser != null)
{
    browser.ForceClose();
}

我们的 UI 测试

在我们的 TestAccount 类中，我们将创建一个冒烟测试，以验证我们可以

  1. 访问登录页面并
  2. 成功登录。

首先，我们创建 TestAccount 类，它继承自 BaseUITest。我们创建了一个用 Test 标签标记的方法，名为 CorrectlyGetsToLoginPage ，该方法仅访问登录页面，等待页面加载，然后验证页面包含短语“Log On”并且标题为“Log On”。

[Test]
public void CorrectlyGetsToLoginPage() 
{ 
     browser.GoTo(rootURL + "Account/LogOn");
     browser.WaitForComplete();
     Assert.IsTrue(browser.Title == "Log On");
     Assert.IsTrue(browser.Text.Contains("Log On"));
}

接下来，我们创建 CorrectlyLogsIn 测试方法，该方法首先访问登录页面，等待页面加载，找到用户名和密码文本框，并用相应的值填充它们。请注意，该测试通过 HTML 元素的 ID 来查找文本框，这意味着您的 UI 设计师可以随意更改 UI，而您无需像使用其他测试产品那样更新测试中的新元素位置。

browser.GoTo(rootURL + "Account/LogOn");
browser.WaitForComplete();
browser.TextField(Find.ById("username")).TypeText("robert.corvus");
browser.TextField(Find.ById("password")).TypeText("secretpw");

然后，我们找到并点击提交按钮。请注意，在这种情况下，我们通过值（即 input 元素的文本）来查找提交按钮，因为我们碰巧没有为该控件设置 ID。请注意 Internet Explorer 实例存在一些问题，因此我们希望使用 ClickNoWait 和 WaitForComplete 方法，而不是简单的 Click 方法（请注意互联网上的示例代码，它们使用了 Click，您可能会在运行时遇到错误）。

browser.Button(Find.ByValue("Log On")).ClickNoWait(); 
browser.WaitForComplete();

最后，我们验证我们是否转到了正确的页面，以及它是否包含我们登录的用户的姓名。

Assert.AreEqual(rootURL, browser.Url);
Assert.IsTrue(browser.Text.Contains("Welcome robert.corvus!"));

运行测试

我在我们的环境中遇到的唯一一个不容易解决的陷阱是，Watin 测试需要在 NUnit 应用中以“与桌面交互”模式运行，并且需要用户登录。这意味着 Watin 测试在 Visual Studio 中使用 Resharper 的“运行单元测试”在桌面上运行时可以正常工作，但它们在以特定用户身份作为服务运行的 Cruise Control 上将无法运行。除非您想更改 Cruise Control 的运行方式，否则您可以执行以下两项操作之一：

  1. 您可以将 Watin 测试标记为 Ignore 标签，这意味着它们将在常规测试中被跳过，但可以通过 Resharper 插件在 Visual Studio 中手动运行它们，只需右键单击它们并选择“运行选定测试”。
  2. 您可以将 Watin 测试移到一个单独的测试项目中（就像我们在本次演示中所做的那样），该项目不会被您的 Cruise Control 构建项目调用。这样，Cruise Control 就永远不会调用您的 Watin 测试，但当您在桌面上使用 Resharper 的“运行解决方案中的所有测试”时，您的 Watin 测试将始终运行。

如果您启动 ASP.NET 开发服务器并运行您的单元测试，您应该会看到所有 UI 测试都通过。

历史

  • 2010 年 8 月 28日：初始发布
© . All rights reserved.