网站测试自动化系统—数据驱动测试

核心提示： 另外，TestContext.DataRow有一个局限，网站测试自动化系统—数据驱动测试(4)，就是DataRow属性实际上只能表示一个表（我没有成功地在DataRow里面访问到一个以上的表），但是一般来说，第二天早上，如果时间紧张的话，一个测试类型（也就是上面的UsersTest类）都会包含好

另外，TestContext.DataRow有一个局限，就是DataRow属性实际上只能表示一个表（我没有成功地在DataRow里面访问到一个以上的表）。但是一般来说，一个测试类型（也就是上面的UsersTest类）都会包含好几个测试用例（类似LogOnTest的单个函数）。如果把一个测试类型的所有测试用例所需要的数据都保存在一个工作簿（worksheet） 里面的话，这个worksheet结果未免过于庞大，难以维护。而如果对每一个测试用例创建一个Excel文件（workbook），最后也导致我们的文件夹有太多的Excel文件，同样难以维护。因此当时我们采取的方案是，对每一个测试类型创建一个Excel文件，每一个需要用到测试数据的测试用例有单独的工作簿（Worksheet），工作簿的名字用测试用例的函数名命名。

这样一来，UsersTest里面新的测试用例类似于下面的形式（注意黄色高亮显示的部分）：

[TestClass]

public class UsersTest

{

　　　 // 省略其他测试用例

　　 　...

　

　　　 // 测试数据文件的名称与测试用例所在的类型名相同

　　　 [DeploymentItem("UsersTest.xls")]

　　　 // 每一个测试用例有自己的worksheet，注意第三个字符串，worksheet名后面的

　　　 // 美元符号“$”

　　　 [DataSource(

　　　　　　　 "System.Data.Odbc",

　　　　　　　 @"Driver={Microsoft Excel Driver (*.xls)};DriverId=790;Dbq=UsersTest.xls;DefaultDir=.",

　　　　　　　 "PermissionTest$", DataAccessMethod.Sequential)]

　　　 [TestMethod]

　　　 public void PermissionTest()

　　　 {

　　　　　　　 ...

　　　 }

}

当然啦，也许在后面执行自动化测试用例的时候，有可能因为测试人员的疏忽，导致测试数据和测试代码不同步。发生这种情况的话，也不会有太大影响，因为在前一篇文章中，测试所需的库函数都执行了参数验证，并扔出CaseErrorException向测试人员报告了这个错误。如果不清楚的话，可以再看看下面的代码：

public class UserOperationsHelper

{

　　　 public void LogOn(string username, string password)

　　　 {

　　　　　　　 // string.Empty留出来为测试目的服务

　　　　　　　 if (username == null)

　　　　　　　　　　　 throw new CaseErrorException(new ArgumentNullException("username"));

　　　　　　　 if (password == null)

　　　　　　　　　　　 throw new CaseErrorException(new ArgumentNullException("password"));

　

　　　　　　　 ...

　　　 }

}


一般情况下，批量的自动化测试用例在晚上执行完毕以后，第二天早上，如果时间紧张的话，测试人员可以将所有结果为CaseErrorException的测试用例手工执行一遍。