ARCHIVED
!注意“归档”
This chapter has not been updated for the current version of Orchard, and has been ARCHIVED.
We apply selenium for UI automation test; please download selenium IDE and selenium RC from its official website. Please read the selenium document in the web site to learn its usage.
我们将硒应用于UI自动化测试;请从官方网站下载selenium IDE和selenium RC。请阅读网站上的selenium文档以了解其用法。
Export test case to VSTT
将测试用例导出到VSTT
Please export test cases as C# code in Selenium IDE, after you finished recording a test case. Although the generated C# code targets NUnit only, however, it is not difficult for you to do tiny modification to use the code in VSTT. Below are all modification you should make:
完成录制测试用例后,请在Selenium IDE中将测试用例导出为C#代码。虽然生成的C#代码仅针对NUnit,但是您不难进行微小修改以使用VSTT中的代码。以下是您应该进行的所有修改:
- Changing [TestFixture] attribute to [TestClass] attribute.
1.将\ [TestFixture \]属性更改为\ [TestClass \]属性\。
- Changing [Setup] attribute to [TestInitialize] attribute
2.将\ [Setup \]属性更改为\ [TestInitialize \]属性
- Changing [TearDown] attribute to [TestCleanup].
3.将\ [TearDown \]属性更改为\ [TestCleanup \] \。
- Changing [Test] attribute to [TestMethod].
4.将\ [Test \]属性更改为\ [TestMethod \] \。
Encapsulate common test actions to functions & classes
将常见的测试操作封装到函数和类中
Though Selenium does a great job for us to generate C# test code, however, many common actions exist in our test cases. For e.g. most of site administration functions require user logon, before making any actions. Actions like logon, create blog/post are good candidates to be rewritten as a common function.
虽然Selenium为我们生成C#测试代码做了很好的工作,但是我们的测试用例中存在许多常见的操作。对于例如在执行任何操作之前,大多数站点管理功能都需要用户登录。登录,创建博客/帖子等操作是作为常用功能重写的好选择。
If you see common steps/verifications in more 2 test cases, you'd better to think moving the steps to a helper class (classes derived from class HelperBase).
如果您在更多2个测试用例中看到常见步骤/验证,则最好将这些步骤转移到辅助类(从类HelperBase派生的类)。
Create a simple test by using the test framework
使用测试框架创建一个简单的测试
Let's say you are going to create a test which verifies a link named "Admin" is presented, for Administrators. Below is the tests based on the test framework:
假设您要创建一个测试,用于验证管理员是否显示名为“Admin”的链接。以下是基于测试框架的测试:
[TestMethod]
public void CanNotAccessAdminPanelTestHelper()
{
TestLibrary.UserHelper.LogOn("Administrator", "0123456");
Assert.IsFalse(selenium.IsElementPresent("link=Admin"));
}
In above code, the UI actions required for logon actions are encapsulated to TestLibrary.UserHelper.LogOn method, which accepts logon user name as its first parameter, the password as its second parameter. This is the source code of TestLibrary.UserHelper.LogOn, you can see how the logic is applied:
在上面的代码中,登录操作所需的UI操作被封装到TestLibrary.UserHelper.LogOn方法,该方法接受登录用户名作为其第一个参数,密码作为其第二个参数。这是TestLibrary.UserHelper.LogOn的源代码,您可以看到逻辑的应用方式:
public void LogOn(string username, string password)
{
if (username == null)
throw new CaseErrorException(new ArgumentNullException("username"));
if (password == null)
throw new CaseErrorException(new ArgumentNullException("password"));
selenium.Open("/");
selenium.Click("link=Log On");
selenium.WaitForPageToLoad(TestLibrary.Consts.TimeToWaitForPageToLoad);
selenium.Type("username", username);
selenium.Type("password", password);
selenium.Click("//input[@value='Log On']");
selenium.WaitForPageToLoad(TestLibrary.Consts.TimeToWaitForPageToLoad);
}
Because logon as default administrator is frequently used in test code, we created a handy method called TestLibrary.UserHelper.LogOnAsAdmin for this. Above code can be rewritten as below:
由于在测试代码中经常使用登录作为默认管理员,因此我们为此创建了一个名为TestLibrary.UserHelper.LogOnAsAdmin的方便方法。上面的代码可以重写如下:
[TestMethod]
public void CanNotAccessAdminPanelTestHelper()
{
TestLibrary.UserHelper.LogOnAsAdmin();
Assert.IsFalse(selenium.IsElementPresent("link=Admin"));
}
Description of Important Classes & Methods
重要类和方法的描述
Class CaseErrorException
CaseErrorException类
If you need throw an exception from your test code, indicates test code error. Please throw an instance of CaseErrorException, instead of throwing original exception directly. For e.g, in below test code:
如果需要从测试代码中抛出异常,则表示测试代码错误。请抛出CaseErrorException的实例,而不是直接抛出原始异常。例如,在下面的测试代码中:
public Blog CreateBlog(string title, string menuText, string permalink,
string description, bool addMainMenu, string owner)
{
// empty string is intentionally left for testing purpose
if (title == null)
throw new CaseErrorException(new ArgumentNullException("title"));
if (permalink != null)
throw new CaseErrorException("Set menu Permalink is not implemented yet!");
if (owner != null)
throw new CaseErrorException("Set owner is not implemented yet!");
...
}
If a null reference is passed to parameter "title", this is a bug in test code. In order to distinguish test bugs from product bugs, we'd better throw an instance of CaseErrorException, with the original exception as its inner exception. This is useful in controller test, because the test code calls controllers directly, we need a way to distinguish test bugs from product bugs, while investigate test failures.
如果将null引用传递给参数“title”,则这是测试代码中的错误。为了区分测试错误和产品错误,我们最好抛出一个CaseErrorException实例,将原始异常作为内部异常。这在控制器测试中很有用,因为测试代码直接调用控制器,我们需要一种方法来区分测试错误和产品错误,同时调查测试失败。
Class TestLibrary.Consts
TestLibrary.Consts类
Please put all constants to this class, for e.g. the default administrator name/password in the test database.
请将所有常量放在此类中,例如测试数据库中的默认管理员名称/密码。
Method TestLibrary.SetupTest
方法TestLibrary.SetupTest
This static method launches different browsers according to predefined excel spreadsheet file. Because it is common for us to debug new test and test failures in local machine, the method is able to detect this.
此静态方法根据预定义的Excel电子表格文件启动不同的浏览器。因为我们在本地机器中调试新的测试和测试失败是很常见的,所以该方法能够检测到这一点。
Data driven test approach
数据驱动的测试方法
Methodology of data driven tests
数据驱动测试的方法
Please check the following article to understand how data driven tests is done in Visual Studio Team Test/Suite edition:
请查看以下文章,了解如何在Visual Studio Team Test / Suite版本中完成数据驱动测试:
http://www.julmar.com/blog/mark/PermaLink,guid,e47f09cc-e893-46a6-aa13-7202d4e50986.aspx
http://www.julmar.com/blog/mark/PermaLink,guid,e47f09cc-e893-46a6-aa13-7202d4e50986.aspx
Running tests against different browsers
针对不同浏览器运行测试
In order to run all tests on different browsers, and reuse the same test logics. The test code saves browsers settings in the excel file. Test team developed a script, which adds browser settings, such as "opera", "iexplorer" and e.t.c to the excel files. So in test case automation phase, just put test data in the excel files is fine. The script is run before any tests, which adds browser settings to all excel files and copy the files to %TestOutputDir%.
为了在不同的浏览器上运行所有测试,并重用相同的测试逻辑。测试代码将浏览器设置保存在excel文件中。测试团队开发了一个脚本,它将浏览器设置(例如“ opera”,“ iexplorer”和e.t.c)添加到excel文件中。因此在测试用例自动化阶段,只需将测试数据放入excel文件即可。该脚本在任何测试之前运行,这会将浏览器设置添加到所有excel文件并将文件复制到%TestOutputDir%。
There is another way to launch different browser, selenium remote control sever has a switch called -forcedBrowserMode, this switch overrides settings (hard code browser string) in code. This is also quite convenient while debugging test failures.
还有另一种方法可以启动不同的浏览器,selenium远程控制服务器有一个名为-forcedBrowserMode的开关,这个开关会覆盖代码中的设置(硬编码浏览器字符串)。调试测试失败时,这也非常方便。
Naming Convention
命名惯例
In order to keep test cases and test data are easy to read, please follow below guideline:
为了使测试用例和测试数据易于阅读,请遵循以下准则:
- One test class should have 1 excel file which saves test data. For e.g. If you need save test data for class CommentsTest, please name the excel file as CommentsTest.xls. Please note that only Excel 2003 file format is supported by Visual Studio Team Test Edition.
1.一个测试类应该有1个excel文件,用于保存测试数据。对于例如如果需要为类CommentsTest保存测试数据,请将excel文件命名为CommentsTest.xls。请注意,Visual Studio Team Test Edition仅支持Excel 2003文件格式。
- Each test method has its own worksheet to save test data, and the worksheet's name is same as test method name.
2.每个测试方法都有自己的工作表来保存测试数据,工作表的名称与测试方法名称相同。
- Please refer to test class Orchard.Test\Automation\Components\Comments\CommentsTest.cs for a sample of this guideline.
3.有关本指南的示例,请参阅测试类Orchard.Test \ Automation \ Components \ Comments \ CommentsTest.cs。
// TODO: add steps to create BVT.ordertest and other test suites
// TODO:添加创建BVT.ordertest和其他测试套件的步骤