在前面的文章網站測試自動化系統—基于Selenium和VSTT當中，我簡單介紹了使用selenium錄制測試步驟，以及優化生成的C#代碼，對代碼使用面向對象的編程理念進行一些封裝，以便規避網站界面更動對測試代碼所帶來的風險。

在網站測試當中（甚至是桌面程序的功能測試），很多情況下，測試步驟是不變，變化的僅僅是測試數據而已。比如說，為了測試網站是否支持國際化，一個正常登錄成功的測試，你可能會使用英文的用戶名；也可能會使用中文的用戶名；甚至還會使用包含一些合法的特殊字符串的用戶名。這三個測試用例的操作步驟都是一樣，都是輸入用戶名和密碼，然后點擊登錄按鈕，唯一不同的就是用戶名和其密碼。又比如，為了執行SQL注入或者腳本注入安全性測試，你可能會設計一個針對用戶提交評論的通用測試步驟，然而用戶評論的內容（包括SQL注入語句或者腳本注入語句）是變化的。 這些測試場景，都可以使用 數據驅動測試來避免重復創建雷同的測試用例，而且數據驅動也給我們提供了很大的彈性，這是因為如果在后續測試過程中發現有些特殊數據被遺漏了，只要更新數據文件就可以了。

VSTT自帶了數據驅動測試功能，網上已經有很多文章介紹使用VSTT執行數據驅動的方法了，這里我就不詳細說了，如果你不熟悉這個方法的話，請參考MSDN的這篇文章：

http://msdn.microsoft.com/zh-cn/library/ms182527%28VS.80%29.aspx

你可以使用很多數據源來保存數據驅動所需的測試數據，例如access數據庫、其他關系型數據庫（只要你能提供合法的數據庫連接字符串）、csv文件以及Excel文件。

我們在本次測試過程中，采用的是Excel數據源，原因是因為：

1.???????? Excel文件相對于其他數據庫來說，更廉價一些，畢竟Excel相對于Access以及其他關系型數據庫來說，更便宜（并且易用）一些。

2.???????? Excel文件和csv文件都可以使用Excel來編輯，然而之所以選擇Excel文件是因為一個Excel文件可以包括多個工作簿（Worksheet），這個功能方便我們管理測試數據，原因在下文中介紹到。

3.???????? 但是如果你使用Office 2007的話，需要注意，Visual Studio Team Test 2008只支持Excel 2003的格式，因此你在保存文件的時候，千萬要保存為Excel 2003的格式，否則VSTT會告訴你它無法訪問測試數據源。

為了讓例子簡單一些，我們還是采用上一篇提到的登錄測試的用例，下面是已經改進過的代碼：

[TestClass] public class UsersTest { ??? [TestMethod] ??? public void LogOnTest() ??? { ??????? var username = "donjuan"; ??????? var password = "它是個秘密"; ??????? TestLibrary.UserHelper.LogOn(username, password); ? ??????? Assert.IsTrue(selenium.IsTextPresented(...)); ??? } }

在上面的代碼中，我們已經注意到，username和password是可以變化的測試數據，而LogOn所封裝的測試步驟是不會更改的，因此，創建一個Excel 2003的文件用來保存LogOnTest所需的測試數據。這個Excel 2003的文件名就叫UsersTest.xls，在文件中創建一個名為LogOnTest的工作簿（worksheet），LogOnTest工作簿里面有兩列，一個叫username, 另一列是password，如下圖所示：

?

接著，上面的測試代碼就得改成下面的樣子：

[TestClass] public class UsersTest { ??? // 測試數據文件的名稱與測試用例所在的類型名相同 ??? [DeploymentItem("UsersTest.xls")] ??? // 每一個測試用例有自己的worksheet，注意第三個字符串，worksheet名后面的 ??? // 美元符號“$” ??? [DataSource( ??????? "System.Data.Odbc", ??????? @"Driver={Microsoft Excel Driver (*.xls)};DriverId=790;Dbq=UsersTest.xls;DefaultDir=.", ??????? "LogOnTest$", DataAccessMethod.Sequential)] ??? [TestMethod] ??? public void LogOnTest() ??? { ??????? var username = TestContext.DataRow["username"] as string; ??????? var password = TestContext.DataRow["password"] as string; ??????? TestLibrary.UserHelper.LogOn(username, password); ? ??????? Assert.IsTrue(selenium.IsTextPresented(...)); ??? } }

?

將Excel文件名命名跟測試用例的類型名相同，是因為方便維護測試代碼的時候快速找到對應的測試數據文件。另外，一般也不會把測試數據和測試代碼放在同一個文件夾。在VSTT的測試工程文件里，有一個后綴名為.testrunconfig的文件，這個文件用來設置一些測試環境，在“解決方案瀏覽器（Solution Explorer）”里雙擊這個文件會打開測試環境配置對話框。左邊列表框的第四項“部署（Deployment）”，允許你在測試用例執行之前， 指引VSTT將你指定文件夾里面的所有文件都拷貝到測試用例所在的文件夾里（這個文件夾可以通過TestContext.TestDeploymentDir屬性獲取到）。這樣，測試代碼才能在運行的時候，獲取到其所需的測試數據。

另外，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的測試用例手工執行一遍。

下一篇在測試代碼中硬編碼測試數據講解如何在測試代碼中硬編碼一些測試數據。

轉載于:https://www.cnblogs.com/killmyday/archive/2010/03/15/1685832.html

總結

以上是生活随笔為你收集整理的网站测试自动化系统—数据驱动测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。