更多原创测试技术文章同步更新到微信公众号 ：三国测，敬请扫码关注个人的微信号，感谢！
原文链接：
传统测试认为功能测试（黑盒测试）就是数据驱动测试，而在自动化测试体系中，数据驱动测试则有了新的诠释。以一个基础的自动化框架为例，它可以分为三层设计，数据层、逻辑层、业务层，假设数据层的设计足够抽象，即可实现多套测试数据运行同样的测试代码逻辑；另一方面从功能测试的角度理解，这种设计同样可以完成多角度测试的覆盖（等价类划分、边界值测试等等）。因此，我们认为这同样属于数据驱动测试范畴。
拿我们熟悉的机酒产品预订流程举例，比如为了测试订单的备注信息，我们需要设计一个针对备注信息输入内容的通用测试步骤，然而用户输入的备注信息内容是变化的。又或者为了测试网站联盟不同用户登录后的功能区别，我们需要设计一个开通联盟的正常用户数据，也可能会使用一个新用户数据，甚至可能使用特殊用户。但这几个用例的操作步骤基本是一致的，包括输入用户名、密码，点击登录按钮，查看信息等等，唯一不同的就是用户名和密码信息。
以上罗列的这些测试场景，都可以使用数据驱动测试策略来避免重复创建雷同的测试用例。而且数据驱动测试给了我们很大的扩展性，假如在后续测试过程中发现有遗漏的比较特殊的测试用例，只要添加新的测试数据就可以了。
下面我们以机酒的查询为例，进行实战演练：
如图所示，我们简单以选择单程或者往返为例，那么我们的代码可能如下：
public void SearchVacationPackages() { //设定单程或者往返的选择钮id string TripRadio = "trip_radio_id"; //根据id，选择单程或者往返 driver.FindElement(By.Id(TripRadio)).Click(); } 在上面的代码中可以看到，TripRadio是可以变化的测试数据，而函数SearchVacationPackages()是不会变化的，因此我们可以把TripRadio放在xml文件里面，就是我们的测试数据文件，格式如下（此处沿用我们测试框架设计，不做详细解释）：
同时呢，我们的测试代码就要稍微改一下了，新的代码如下：
public void SearchVacationPackages() { //设定单程或者往返的选择钮id string TripRadio = CaseData["trip_radio_id"].ToString(); //根据id，选择单程或者往返 driver.FindElement(By.Id(TripRadio)).Click(); } 这样如果页面设计师变更了控件，我们只要在数据文件里做改动就可以了，效率提高了不少。不过这样子就完美了吗？我们接下来看，如果我们选择往返航行，哎呀，流程变了：
注意图片，我们多了一个返程日期的输入框！这个怎么用数据驱动来适应呢？别着急，我们可以在数据文件中加一个控制开关还有返程日期的id和值：
我们的测试代码也因此加一些变化：
public void SearchVacationPackages() { //设定单程或者往返的选择钮id string TripRadio = CaseData["trip_radio_id"].ToString(); //设定是否单程 string IsOneway = CaseData["IsOneway"].ToString(); //取得返程日期输入框id string ReturnDateId = CaseData["return_date_id"].ToString(); //设定返程日期 string ReturnDate = CaseData["return_date"].ToString(); //根据id，选择单程或者往返 driver.FindElement(By.Id(TripRadio)).Click(); //判断是否单程，如果单程跳过，如果往返则执行 if (!IsOneway.Equals("1")) { driver.FindElement(By.Id(ReturnDateId)).SendKeys(ReturnDate); } } 写到这里可以看出我们的代码健壮了许多，这时候不管测试数据是单程的或者往返的，甚至在出现了新的控件情况下，我们的测试代码都可以不做改动，也就是说我们这一小段代码，起码可以运行两个测试用例，是不是提高了一些效率呢。
作者原创技术文章，转载请注明出处