用Python实现数据库的自动化测试（1）

　　目前公司的数据库应用除了web application的交互，还有大量的后台数据分析系统、 电信BOSS 系统。主要用到的数据有MySQL， Vertica， orcale. 目前实现的关于数据库的自动化测试主要有下列三个方案。
　　· 第一类应用是大家都很常见的web application和数据库的交互。这个会在以后selenium章节讨论实现方案。
　　· 第二类应用是电信BOSS 系统，是电信计费系统的后台。大量的通话记录、短信记录、流量源记录数据输入到源数据库表里，然后后台进程按照计费规则计算出每个用户的月花费
　　· 第三类应用是数据比较简单的，数据输出比较简单。 比如客户每天通过FTP 传给我们手机用户订制流量数据包的记录，我们后台进程定时读取客户传过来的文件，根据一定的逻辑运算对订购表和用户属性表，进行写入，更新和删除操作。
　　第二类应用测试方案：
　　此类应用数据量非常膨大，业务逻辑很复杂，曾经考虑过下面的方案。
　　1. 采用直接导入产品线数据的方案，然后运行后台进程，计算出结果，自动化测试工具去检查数据准确性，这个方案等于是要完全实现一套新的BOSS 后台产品，后面开发部门对逻辑做了改动，测试工具也要完全要做一样的事情。考虑到目前测试和开发的人员比例关系，这种方案显然是行不通的。
　　2. 采用预先设计好的数据源，能覆盖到所有回归测试的cases， 这种情况下输出结果是固定的，实现起来简单了。但这种方案，如果产品的逻辑发生了变化，你需要插入一条新的数据源去覆盖新的逻辑，这样会导致很多cases的输出会发生改变。而且你可能没有预计到被改变的 cases是有bug.  这种方案我们曾经用过，后来被我买抛弃了。
　　3.  采用一样的数据源，比较新老版本输出的结果。 我们自动化测试目标也是定位在回归测试，对于新的逻辑，我们在手工测试已经覆盖。所以我们自动化测试工具的目标是要想办法过滤掉这些新逻辑产生的数据， 这个过滤方案要设计好，确保以后的变更不需要修改代码，通过配置即可。 这样我们新老版本的数据比较，可以确保不引入bug，而且数据源直接采用实际产品线的数据，保证了覆盖率。
　　我们公司整个测试方案是从2过渡到3的。
　　第三类应用测试方案：
　　这个应用里面我们同样考虑过第一类应用里面的方案一，这个显然是不现实的。但这个应用业务逻辑比较简单。数据的写入表比较单一。大部分case只有1个，少部分有2-3个表。所以我们采用的方案是预先设计好输入数据，结果数据按case 放到对应的csv文件里面。 这样后期有新的逻辑变更，导致了数据的变更，因为输出数据少，我们可以直接在csv文件里面修改参考数据。  下面是我们的一个参考数据配置文件例子。
<database_name>
<compare_item action="insert" description="比较XXX的输出结果">
<!--  获取实时测试数据的SQL 语句 -->
<query_sql>SELECT * FROM table1 WHERE carrieraa = '87'</query_sql>
<!-- 参考结果的文件 ct.csv -->
<expected_result>ct.csv</expected_result>
<!-- 结果在此文件的第一和第二行，为了工具使用人员的方便，我们可以在代码里面做逻辑判断，如果没有这个配置项，那都全部文件，或者支持1，3，6这样的配置-->
<result_lines>1-2</result_lines>
</compare_item>
<compare_item action="update" description="比较XXX的输出结果">
<!--  获取实时测试数据的SQL 语句 -->
<query_sql>SELECT * FROM table1 WHERE carrierbb = '87'</query_sql>
<!-- 参考结果的文件 ct.csv -->
<expected_result>ct.csv</expected_result>
<!-- 结果在此文件的第一和第二行，为了工具使用人员的方便，我们可以在代码里面做逻辑判断，如果没有这个配置项，那都全部文件，或者支持1，3，6这样的配置-->
<result_lines>3，4</result_lines>
</compare_item>
</database_name>