特别说明：本文虽归类于原创，但并非原创，实收集整理于网络！
一、 数据库测试概论
随着软件业的迅猛发展，我们的开发也从以前的单层结构进入了三层架构甚至现在多层架构的设计，而数据库从以前一个默默无闻的后台仓库，逐渐成为了数据库系统，而数据库开发设计人员成为了炙手可热的核心人员。以前我们往往把数据库操作写在应用层，从而提高各个模块的独立性和易用性，而现在越来越多的数据库操作被作为存储过程直接放在数据库上进行执行来提高执行效率和提高安全性。因此，对数据库进行系统完整的成为了必然。
（一） 数据库测试预备工作
1、 数据库中的“CRUD”
C：创建——创建用户。
R：检索——执行检索视图操作。
U：更新——更新数据库信息。
D：删除——执行删除数据库操作。
2、 ACID属性
ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性(Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。在数据库测试期间必须测试这四个要素，确保正确
3、 数据完整性
考虑到不同模块的应用程序以不同的方式使用相同的数据，并执行对数据所有的CRUD操作。确保数据库中包含的数据尽可能地准确和一致的数据性质，这就是数据完整性。
4、 业务准确性
数据库发展至今，已不再是单纯的用来存储记录。事实上，数据库系统已经发展成为强大的工具，为开发者们提供了足够的扩展支持。数据库系统比以前具有了更多的强大功能，例如参考完整性，关系约束，触发器和存储过程。
5、
（二） 测试什么
图1展示了数据库测试时应该考虑的事项。该图是针对单一数据库，其中虚线划定了测试边界，表示做数据库测试时应该考虑到数据库本身（白盒测试）和数据库访问接口（黑盒测试）。
（三） 怎样测试
由于数据库开发和应用开发并没有实质上的区别，所以软件测试的方法同样适用于数据库测试。从测试过程的角度来说我们也可以把数据库测试分为
1、 系统测试
传统软件系统测试的测试重点是需求覆盖，而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试.例如存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的.另一方面我们需要确认数据库设计文档和最终的数据库相同，当设计文档变化时我们同样要验证改修改是否落实到数据库上。
这个阶段我们的测试主要通过数据库设计评审来实现。
2、 集成测试
集成测试是主要针对接口进行的测试工作，从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说，需要考虑的是
·数据项的增删改查操作
·数据表增加满
·数据表删除空
·删除空表中的记录
·数据表的并发操作
·针对存储过程的接口测试
·结合业务逻辑做关联表的接口测试
同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试。
3、 单元测试
单元测试侧重于逻辑覆盖，相对对于复杂的代码来说，数据库开发的单元测试相对简单些，可以通过语句覆盖和走读的方式完成。也可以从测试关注点的角度对数据库进行分类。
针对每个联机事务处理逻辑单元（一般为一个访问接口）测试细则具体如下：
1） 数据正确性验证
输入正确的参数应该返回正确的数据结果。这里输入的参数至少需包含两端边界值及一个中间值。
2） 防错处理能力测试
·非法参数处理测试（针对非法参数应该范围约定标志）
非法参数包括：两端边界值、指针类型传NULL、其他错误参数。
·内存分配管理测试
若单元内涉及内存分配，需在单元外进行内存释放测试（具体可引用单元内所分配内存以检测）。
3）
4、 功能测试
对数据库功能的测试我们可以依赖与工具进行
DBunit
一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试，对输入输出进行校验
QTP
大名鼎鼎的自动测试工具，通过对对象的捕捉识别，我们可以通过QTP来模拟用户的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。个人觉得比较偏向灰盒。
DataFactory
一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试
5、 数据库性能
虽然我们的硬件最近几年进步很快，但是我们需要处理的数据以更快的速度在增加。几亿条记录的表格在现在是司空见惯的，如此庞大的数据量在大量并发连接操作时，我们不能像以前一样随意的使用查询，连接查询，嵌套查询，视图，这些操作如果不当会给系统带来非常巨大的压力，严重影响系统性能
性能优化分4部分
1）物理存储方面
2）逻辑设计方面
3）数据库的参数调整
4）SQL语句优化.
通过数据库系统的SQL语句分析工具，可以分析得到数据库语句执行的瓶颈，从而优化SQL语句。
Loadrunner
可以通过对协议的编程来对数据库做压力测试
Swingbench（这是一个重量级别的feature，类似LR，而且非常强大，只不过专门针对oracle而已）。
Oracle11g已经提供了real application test，提供数据库性能测试，分析系统的应用瓶颈。
还有很多第三方公司开发了SQL语句优化工具来帮助你自动的进行语句优化工作从而提高执行效率。
6、 安全测试
软件日益复杂，而数据又成为了系统中重中之重的核心，从以往对系统的破坏现在更倾向于对数据的获取和破坏。而数据库的安全被提到了最前端
自从SQL 注入攻击被发现，冒失万无一失的数据库一下从后台变为了前台，而一旦数据库被攻破，整个系统也会暴露在黑客的手下，通过数据库强大的存储过程，黑客可以轻松的获得整个系统的权限。而SQL的注入看似简单缺很难防范，对于安全测试来说，如何防范系统被注入是测试的难点。
业界也有相关的数据库注入检测工具，来帮助用户对自身系统进行安全检测。
对于这点来说业界也有标准，例如ISO IEC 21827，也叫做SSE CMM 3.0，是CMM和ISO的集成的产物，专门针对系统安全领域的
另外一方面，数据库的健壮性，容错性和恢复能力也是测试的要点
二、 报表测试
报表测试根据项目的定义有大有小,有时只是作为软件的一个部分进行测试,有时整个项目都是测试各种报表.但不论如何,报表的作用始终都是将系统中已经存在的数据根据用户的设置计算加工/整理汇总/最终以清晰的格式展示给用户,以便用户进一步做数据分析或统计。
软件中的报表实现一般分为定义报表的所需数据(一般可以通过选择或手工输入条件来缩小数据范围)和定义报表格式两个部分.报表格式除了如国家各行业标准中规定的报表使用固定格式外,大多是根据企业或用户的需要定制报表。
所以,做报表测试时要注意以下方面:
(一) 数据统计方面
1、 数据的正确性
用户使用报表就是期望通过一个简单方便的平台能快速的查找到他所需要的数据.所以在测试报表时首先就要检查报表中的数据是不是用户需要的数据,如果没有加工的数据,是否保持了原貌;加工过的数据查看加工的结构是否和手工加工的结果一致，细则如下：
|
测试项目 |
测试要点 |
|
数据的来源 |
来源于哪张表,哪个字段,数据库中的数值与界面数据的对应.如数据库中性别的数据可能是0或1,但界面显示为男或女,这个对应关系是否正确. |
|
数据的范围 |
是否只显示了报表设置的对应范围特别要注意边界数据,要清楚报表的需求,是否需要过滤掉被选择的数据.如时间选择为2006-9-27~2007-9-27,那么是否应该包含9-27这天. |
|
数据的对应关系 |
数据库中的字段是否与报表中的信息对应 |
|
数据的格式 |
小数位,千位符,四舍五入等是否与报表设置一致 单位或税率转换是否正确 组合显示的数据是否合理 |
|
数据的排序 |
排序方式是否与报表设置一致(如果没有设置,是否有一个清晰的默认排序方式,如按字母或数字排序) |
|
流水号 |
如报表有使用流水号,流水号的生成和格式是否正确. 取消操作是否会生成流水号. |
|
明细与合计的一致性 |
各部分明细或小节是否与最后总和一致 |
|
|
试这一部分内容需要对业务逻辑相当熟悉,对数据库的设计也要非常了解.必要时可以通过自己写查询语句查看数据.
有些报表的条件有多有少,但测试方法都是一样.根据条件通过等价类划分和排列组合设置各种条件组合.千万不要盲目的测试,否则会导致该测的没测,多余的测试做了一堆..一般来说有类别划分的(一般界面表现为下拉框),每个类别都要测试到,如性别中的男,女都要测试.输入的可以用等价类来划分要测试的数据。
2、 数据的完整性
3、 数据的合法性
(二) 报表格式
这一点主要是看报表的输出格式是否符合要求，可以从以下几方面来检查：
|
测试项目 |
测试要点 |
|
报表的整体风格 |
报表是否符合规定的或用户设置的格式 |
|
报表标题 |
报表的标题是否是正确的报表名称 如报表中有嵌入的数据(会跟随用户的选择而变化的).需要检查数据是否正确,如XX企业9月份财务报表,这个9月就是用户选择的;或者XX公司2006-9-27~2007-9-27的网站访问量,这个时间段也是用户选择的. |
|
公司的一些标志 |
如logo,名称,地址之类的是否正确 |
|
报表的页首与页尾 |
是否采用了一致的规则. |
|
分页 |
当输出的内容多时,分页是否正确. 翻页功能是否正确 |
|
友好性 |
数据或图表是否清晰,一目了然, 数据的展示符合用户的习惯 需要特别提醒的数据(如合计,异常数据)是否突出显示 复杂算法处,用户不明白或容易混淆处是否有注释 一些默认的格式是否让人感觉舒服,如对齐,边界,间隔等 |
(三) 权限控制
对于有权限控制的系统,报表当然也应该和用户所具有的权限相一致.需要从两方面校验权限的控制.
报表的条件定义:在条件选择区域,有些下拉框中应该不能显示用户权限范围外的数据.如普通文员在使用报表时,报表名称下拉框中是不可以显示管理者才能查看的报表的.有些以输入的文本框有级别的划分时,都应该要测试输入超越权限的数据的相应.
注意这里一定要测试每个条目.
报表内容:报表中的内容不能显示用户本没有权限查看的数据.
(四) 报表输出
细则如下：
1、预览中的显示完整性；
2、多页情况下，第2页的表头显示；
3、能否实现需求要求的特定印刷情况；（比如，印刷使用指定的模板）
4、预览后印刷；
5、不预览，直接印刷
6、需求规定各类打印机的测试
(五) 报表性能
用户在设置好条件后都希望不要等待报表太长时间,当然有时数据量大时等待时间长些也是合理的.但是在做报表的开发时或测试人员可以提出一些意思来提高报表的性能.
报表的条件设置区域应该设置默认值以避免用户不输入任何条件直接生成报表所造成的长时间等待.例如开始和结束时间可以默认为当前的一个月,一些输入文本框可以根据用户的身份默认一个数值.
生成报表时用类似进度条表现进度,避免用户盲目的等待
提供让用户选择每页显示多少条数据的选项, 默认为最小的选项,这样可以避免无谓的资源浪费.
生成报表的语句尽量采用最优的查询语句,多调试几遍,查看语句的性能.
注意:如果可以所有的条件为空时,需要测试条件为空时的性能.
(六) 一般性测试
测试报表条件选择区域,主要需要注意如下问题:
每个字段的类型校验
每个字段的长度校验
每个字段中输入特殊字符的校验(包括空/空格)
通配符的测试(对信息量大的系统,建议最好作处理不支持通配符以避免性能的低下)
字段与字段之间的关系的测试(如约束关系或排斥关系)