在上一篇博客《RnP与Coded UI自动化测试》中介绍了如何编写、录制和播放手工测试用例，以及如何由录制的内容生成Coded UI Test（CUIT）自动化测试用例。那里所使用的测试用例比较简单，仅测试了计算器的加法功能。而在实际的测试工作中，在测试步骤系统情况下，往往会有多组测试输入数据，需要判断每组输入的结果是否正确，这也就是所谓的数据驱动的测试（DDT，Data-Driven Test）。
Visual Studio 2010对手工测试用例的编写也支持DDT，每个测试步骤允许定义一个或多个参数（@Parameter)，一组参数就构成了一个测试输入组，也被称为Iteration。然后只要录制一输入组的测试，就可以将录制内容应以于其它的输入组。马上就要春节了，辛苦了一年，就要回家过年了，买车票是件大事，下面就以"火车网“的车票查询网站的查询操作测试为例。下图是在MTLM中定义的一个测试用例，一组执行步骤，但有多组输入数据：
-
输入 @起始车站
-
输入 @到达车站
-
查询
-
关闭浏览器
上面的测试步骤很简单，唯一值得注意的就是“@起始车站”和“@到达车站”，它们实际上是为两个步骤分别定义的参数，而参数的具体组合最下面的表格所示，表中每一行就是一个测试输入组合。而参数的创建则是通过测试步骤上面的“@ Insert Parameter”按钮完成的。在Test Runner中录制一个Iteration的执行时，当执行到一个带有参数的步骤时，测试步骤会被展开，一个小箭头指到第一个参数上，如下图所示。
此时Test Runner会自动将这个参数对应的内容拷贝到剪贴板中，测试人员只要通过CTRL+V将其粘贴到要输入的位置就可以了。可不要小瞧这一操作，Test Runner在幕后做些重要工作，它要记录这个参数@起始车站和哪个界面控件进行了绑定。这样在录制完一组数据后，自动执行其它组数据时，工具就知道该把数据放到位置了。
下图显示了要测试用的查询页面，我们在“出发站”输入框中按CRTL+V粘贴起始车站“北京”。
在操作完毕后，如果这一测试步骤还有参数Test Runner会自动下移一下箭头，用户可以继续粘贴下一个参数到指定位置，上一个参数则会被显示为：
在录制完一组输入 （Iteration）的执行后，录制的操作步骤可以直接应用到其它组输入上，这样执行起来就方便多了，不需要给每个Iteration都手工录制一遍，这才是真正体现了数据驱动测试（DDT），即一次录制适用于多组不同数据。在Test Runner左上角的位置，可以切换不同的Iteration。例如：上面录制采用的输入是 北京 -> 上海，在Test Runer中选择其它Iteration时，Test Runner会自动用这个Iteration的数据替换掉测试步骤中@标识的参数，如下图所示：
在录制过程中，可能有些步骤是你不想要的，可以展开Test Runer最右下角的Action Captured，显示出所有已经录制的操作，你可以选择删除其中不需要的内容。另外，在《VS 2010 测试功能学习(三) 真正的主角儿》中我曾经提到过，测试管理的核心是TFS，在MTLM中进行的所有这些操作需要连接到TFS才能完成，这是一个优势，但有时候也是问题。一旦TFS挂了，MTLM中的所有这些功能也就全歇了，呵呵！
除了上述的手动测试使用DDT，也可以直接在Coded UI Test (CUIT) 自动互测试用例代码中直接使用Data Driving， 详细内容可参见：
参考资料:
4336
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
