在上一篇RobotFrameWork接口报文测试-----（二）demo的升级版基础上，将接口的xml的格式保存在xml文件中，然后程序如果增加一个接口，在xml文件里添加即可，无需修改自动化测试里的其他模块，然后在工具加case就可以了，但是接口取值的数据全部都是直接在case里面录入的，也就是说，每增加一条测试用例，就需要在工具内添加一条case，测试数据始终都是在工具内控制，这让以前使用excel管理过测试数据的我感觉很不爽，总感觉得把数据放到excel内，然后实现数据驱动测试。
围绕着这个想法，先给出一个大致的业务流程图。
.xml : 每个接口的xml定义的标准规范文档。如下：
.xls : 每个接口的测试数据，保存在xls内。如下：
从xml文件中读取接口的字段，再从excel中读取相应的数据，然后组装成sendbuf，调用报文处理模块，将报文进行预处理后（在dll内实现，在会话层添加一些数据，然后再进行加密操作 ）发往服务器端，服务器处理报文后，返回响应报文，报文处理模块将报文解析后，提取出状态码，将实际状态码与预期状态码进行对比，测试完成。在（二）的基础上，增加一个excel的处理模块，将excel内的数据全部读入到list中，简单的代码如下所示：
def readDataFromExcel():
data = xlrd.open_workbook(‘D:\logincase.xls‘)
table = data.sheets()[0]
nrows = table.nrows
nclos = table.ncols
listAll=[]
for row in range(3,nrows):
alist=[]
for col in range(1,nclos):
alist.append(table.cell(row,col).value)
listAll.append(alist)
return listAll
然后在RF工具内修改case，如下所示：
到此，已经把数据从case中剥离到了excel内，上图只读取了一条数据，如果要去读多条数据，直接在里面写个简单的for循环即可，于是我以为我完全实现了数据驱动测试，开心了好几天。。。。
一天无意间点到一位大师的博客，看了看，似乎觉得好像真有点道理，像我上面那样实现，就算实现了数据驱动测试了么？那什么又是数据驱动测试呢？
数据驱动测试是从数据文件（如Excel文件、文本文件、XML文件或数据库等）中读取测试数据，然后通过变量传入事先编写或录制好的测 试脚本中，这些变量既可传递测试输入数据也可传递测试输出的验证数据。测试数据只出现在数据文件中，测试脚本负责测试逻辑业务过 程、测试状态以及数据文件读取，因此，测试数据和测试脚本是分开存放的。数据文件中的每一行表示一组测试数据，通过循环遍历数据文件中的每一行，将数据逐一注入到相同的测试流程进行反复的测试验证。
对比下手工测试的场景：当一个手工测试人员A发现在测试数据存储目录下多了一套测试数据时，他就会意识到应该马上执行测试用例，并输入这套新的测试数据。其实是测试数据的变化触发了A的测试行为。再抽象一下，可以这样来看：当测试数据变化时，测试用例就会被执行，并且按照预先定义的规则去读取测试数据并执行测试用例。那么这种情况我们是不是可以理解为一种数据驱动呢？也就是说只要有了新的测试数据或者测试数据发生了变化，那么A就会去执行测试用例。这一过程的目的就是为了让所有的测试数据都得到输入并返回相应的输出结果。
很显然，这个概念强调了两点：第一：测试数据与测试脚本，模块的分离；第二：程序读取测试数据，自动完成一些列的测试流程并返回测试结果。很多时候，我们大部分人都是做了第一点，忽略了第二点；大多数都能实现测试数据的参数化处理，却无法完成自动运行相应的测试用例。了解数据驱动测试的相关概念后，自我审视觉得自己写的确实没法达到能完全自动运行的地步，至少存在以下几个问题：
第一：测试A接口，怎么确定使用哪个sheet的数据呢？
第二：测试A接口，有10条用例，放在一个RF的case内管理，那这10个用例内，冒烟测试只要运行3条，集成需要10条，这怎么设置？而且如果一个case里存在一个测试用例失败，则整个case是处于failed状态的，这该怎么办？
鉴于上面2个问题，实际上以前我都解决过；第一个问题好办，既然id能确定接口的xml的标准格式，那就可以以这个id作为测试数据的sheet的名称，就可以拿到具体接口的sheet数据。第二个办法运行几条case也好办，在每个xls最后一列加一列，是否执行列，读取为否，则不发送数据即可。但是第二个小问题，在RF内就无法解决了，应该是因为工具自身的局限性导致，一个RF的case不管里面实际跑了多少个测试用例，只要一个失败，就是全部失败状态。所以在RF内测试用例的管理有2种形式：
第一：一个suit 就是一个接口，一个case就是一条测试用例。
第二： 一个suit是一个模块，一个case是一个接口。
显然第一个可以更方便的控制执行粒度，但是每一个测试用例就得新建一个case，测试数据直接写在case内即可，是有点麻烦。如果碰到一个接口有四五十条测试用例，就只能呵呵了~~~第二个不太好控制执行粒度，但是在excel内管理数据，可以更好的管理测试数据。而且RF一直在说能实现数据驱动测试，但一直没找到相关资料，大多都是实现到这一层基本就没了下文，看了很多文档，基本也差不多就到此为止了，看来也是时候需要去看看官方各种文档了~~~~