網站測試自動化系統—資料驅動測試

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

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

<a href="http://msdn.microsoft.com/zh-cn/library/ms182527%28VS.80%29.aspx" target="_blank">http://msdn.microsoft.com/zh-cn/library/ms182527%28VS.80%29.aspx</a>

你可以使用很多資料源來儲存資料驅動所需的測試資料，例如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，如下圖所示：

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

    // 測試資料檔案的名稱與測試用例所在的類型名相同

    [DeploymentItem("UsersTest.xls")]

    // 每一個測試用例有自己的worksheet，注意第三個字元串，worksheet名後面的

    // 美元符号“$”

    [DataSource(

        "System.Data.Odbc",

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

        "LogOnTest$", DataAccessMethod.Sequential)]

        var username = TestContext.DataRow["username"] as string;

        var password = TestContext.DataRow["password"] as string;

将Excel檔案名命名跟測試用例的類型名相同，是因為友善維護測試代碼的時候快速找到對應的測試資料檔案。另外，一般也不會把測試資料和測試代碼放在同一個檔案夾。在VSTT的測試工程檔案裡，有一個字尾名為.testrunconfig的檔案，這個檔案用來設定一些測試環境，在“解決方案浏覽器（Solution Explorer）”裡輕按兩下這個檔案會打開測試環境配置對話框。左邊清單框的第四項“部署（Deployment）”，允許你在測試用例執行之前， 指引VSTT将你指定檔案夾裡面的所有檔案都拷貝到測試用例所在的檔案夾裡（這個檔案夾可以通過TestContext.TestDeploymentDir屬性擷取到）。這樣，測試代碼才能在運作的時候，擷取到其所需的測試資料。

另外，TestContext.DataRow有一個局限，就是DataRow屬性實際上隻能表示一個表（我沒有成功地在DataRow裡面通路到一個以上的表）。但是一般來說，一個測試類型（也就是上面的UsersTest類）都會包含好幾個測試用例（類似LogOnTest的單個函數）。如果把一個測試類型的所有測試用例所需要的資料都儲存在一個工作簿（worksheet） 裡面的話，這個worksheet結果未免過于龐大，難以維護。而如果對每一個測試用例建立一個Excel檔案（workbook），最後也導緻我們的檔案夾有太多的Excel檔案，同樣難以維護。是以當時我們采取的方案是，對每一個測試類型建立一個Excel檔案，每一個需要用到測試資料的測試用例有單獨的工作簿（Worksheet），工作簿的名字用測試用例的函數名命名。

這樣一來，UsersTest裡面新的測試用例類似于下面的形式（注意黃色高亮顯示的部分）：

    // 省略其他測試用例

    ...

        "PermissionTest$", DataAccessMethod.Sequential)]

    public void PermissionTest()

        ...

當然啦，也許在後面執行自動化測試用例的時候，有可能因為測試人員的疏忽，導緻測試資料和測試代碼不同步。發生這種情況的話，也不會有太大影響，因為在前一篇文章中，測試所需的庫函數都執行了參數驗證，并扔出CaseErrorException向測試人員報告了這個錯誤。如果不清楚的話，可以再看看下面的代碼：

public class UserOperationsHelper

    public void LogOn(string username, string password)

        // string.Empty留出來為測試目的服務

        if (username == null)

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

        if (password == null)

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

一般情況下，批量的自動化測試用例在晚上執行完畢以後，第二天早上，如果時間緊張的話，測試人員可以将所有結果為CaseErrorException的測試用例手工執行一遍。

本文轉自 donjuan 部落格園部落格，原文連結：http://www.cnblogs.com/killmyday/archive/2010/03/15/1685832.html   ，如需轉載請自行聯系原作者