数据库测试是依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行的测试。

软件应用程序已经离不开数据库。无论是在Web、桌面应用、客户端服务器、企业和个人业务，都需要数据库在后端操作。同样的在金融、租赁、零售、邮寄、医疗领域中，数据库也是不可缺少的。

随着应用的复杂程度增加需要更强大和安全系数高的数据库才可以满足需求。为了满足高频率的应用程序事务（如银行或财务应用），数据库的安全性成为首要之重。

目前，市场中有很多活跃的数据库工具，例如MS-Access2010，MS SQL Server2008 r2，Oracle 10g，Oracle Financial，MySQL，PostgreSQL，DB2等等。它们在成本、可靠性、功能和安全性都有各自的优势。

下面为大家简单的介绍数据库中‘CRUD’所代表的操作。

C：创建——创建用户。

R：检索——执行检索视图操作。

U：更新——更新数据库信息。

D：删除——执行删除数据库操作。

普遍用户在操作数据时，都会用到以上四种操作。

ACID属性

ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性(Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。在数据库测试期间必须测试这四个要素，确保正确。

数据完整性

考虑到不同模块的应用程序以不同的方式使用相同的数据，并执行对数据所有的CRUD操作。确保数据库中包含的数据尽可能地准确和一致的数据性质，这就是数据完整性。

业务准确性

数据库发展至今，已不再是单纯的用来存储记录。事实上，数据库系统已经发展成为强大的工具，为开发者们提供了足够的扩展支持。数据库系统比以前具有了更多的强大功能，例如参考完整性，关系约束，触发器和存储过程。

创建查询

为了测试测试数据库正确和准确性。首先，测试人员要熟练掌握SQL和DML（数据库语言）语句。其次，测试人员应该掌握数据库的结构。如果满足这两个条件，即可放心测试。对于小、中型技术开发出的应用程序是个很好的测试方法。此外，如果程序相对的复杂，测试人员需要求助开发人员帮忙。但是我建议大家从初级开始测试，既有信心也能提高自己的SQL技术。

查询数据表

测试人员可以通过查看数据表来验证应用程序GUI的操作结果。但是，这种方式对于拥有大量数据的数据库，查询是相当的乏味和繁琐。验证多个数据表也是相当困难。

从开发人员查询

这个是测试数据库最简单的方法，从GUI执行任何CRUD操作和执行各自的SQL查询，从开发人员获得验证及其结果。这种方式似乎是最好的测试数据库方式。如果开发人员查询出语句错误或是不符合用户的要求，可以尽快的修改错误语句。

传统软件系统测试的测试重点是需求覆盖，而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试.例如存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的.另一方面我们需要确认数据库设计文档和最终的数据库相同，当设计文档变化时我们同样要验证该修改是否落实到数据库上。

这个阶段我们的测试主要通过数据库设计评审来实现。

集成测试是主要针对接口进行的测试工作，从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说，需要考虑的是：

数据项的修改操作；

数据项的增加操作；

数据项的删除操作；

数据表增加满；

数据表删除空；

删除空表中的记录；

数据表的并发操作；

针对存储过程的接口测试；

结合业务逻辑做关联表的接口测试；

同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试。

数据库是应用的基础，其性能直接影响应用软件的性能。为了使数据库具有较好的性能，需要对数据库中的表进行规范化设计。规范化的范式可分为第一范式、第二范式、第三范式、BCNF 范式、第四范式和第五范式。一般来说，逻辑数据库设计应满足第三范式的要求，这是因为满足第三范式的表结构容易维护，且基本满足实际应用的要求。因此，实际应用中一般都按照第三范式的标准进行规范化。但是，规范化也有缺点：由于将一个表拆分成为多个表，在查询时需要多表连接，降低了查询速度。故数据库设计的测试包括前期需求分析产生数据库逻辑模型和后期业务系统开发中的测试两部分（这里指的是后者），我在这里称为实体测试。数据库是由若干的实体组成的，包括（表，视图，存储过程等），数据库最基本的测试就是实体测试，通过对这些实体的测试，可以发现数据库实体设计得是否充分，是否有遗漏，每个实体的内容是否全面，扩展性如何。实体测试，可以用来发现应用软件在功能上存在的不足，也可以发现数据冗余的问题。经过测试，测试人员对有异议的问题要及时和数据库的设计人员进行沟通解决。

在进行实体测试后，应进一步检查下面的内容以保障数据的一致性：

2.1 表的主键测试根据应用系统的实际需求，对每个表的主键进行测试，验证是否存在记录不唯一的情况，如果有，则要重新设置主键，使表中记录唯一。

2.2 表之间主外键关系的测试数据库中主外键字段在名称，数据类型，字段长度上的一致性测试。

2.3 级联表，删除主表数据后，相应从报表数据应同时删除的问题例如学生表和学生成绩表，学生数据已经删除，成绩表中相应学生的成绩记录应同时删除。

2.4 存储过程和触发器的测试存储过程可以人工执行，但触发器不能人工处理，所以在对存储过程和触发器执行的过程中针对SQL SERVER2005 及以上版本可以使用Microsoft SQL ServerProfiler 性能测试工具进行测试。Microsoft SQL Server Profiler 是SQL 跟踪的图形用户界面，用于监视数据库引擎或Analysis Services 的实例。测试人员可以捕获有关每个事件的数据并将其保存到文件或表中供以后分析。例如：可以对生产环境进行监视，了解哪些存储过程由于执行速度太慢影响了性能。

随着数据库系统的使用，数据量在飞速增长，如何在使用前对数据容量的增长情况进行初步估算，为最终用户提供参考，这在数据库使用和维护过程中，是非常重要的。可以通过对数据库设计中基本表的数据大小，和每天数据表的数据产生量进行初步估算。

记录数据量=各个字段所占字节数的总和

表的数据量=记录数据量* 记录数

数据库大小=各表数据量的总和

当然，数据库的大小不仅仅只是基本表的大小，还有系统表，视图，存储过程等其它实体所占的容量，但最基本的数据是表的数据。另外，数据库的容量还包括数据库日志文件的容量，一般应预留数据库文件的2 倍左右。

应用软件除了功能外，很重要的一部分就是软件的性能，而对于数据库系统，数据库性能的好坏会直接影响应用软件的性能，这部分的测试，一般手工测试就显得无能为力了，这时就要借助自动化的测试软件，例如：DataFactory，DataFactory 是一种强大的数据产生器，它允许开发人员和测试人员很容易产生百万行有意义的正确的测试数据库,该工具支持DB2、Oracle、Sybase、SQL Server 数据库。这样，就可以模拟出应用软件长期使用后，海量数据存储的数据库的性能状况。从而尽早发现问题，进行数据库性能的优化。

这里要注意，进行性能测试的时候，一定要注意测试环境的一致性，包括：操作系统、应用软件的版本以及硬件的配置等，而且在进行数据库方面的测试的时候一定要注意数据库的记录数、配置等要一致，只有在相同条件下进行测试，才可以对结果进行比较。否则无法和用户对软件的性能的观点达成一致。

说起测试，我们首先想到的就是软件正确性的测试，即常说的功能测试。软件功能正确仅是软件质量合格指标之一。在实际开发中，还有其它的非功能因素也起着决定性的因素，例如软件的响应速度。影响软件响应速度的因素有很多，有些是因为算法不够高效；还有些可能受用户并发数的影响。在众多类型的软件测试中，压力测试正是以软件响应速度为测试目标，尤其是针对在较短时间内大量并发用户的访问时，软件的抗压能力。但压力测试往往是手工难以测试的，必须借助自动化测试工具。常用的压力测试有：Web 测试、数据库测试等。

数据库在大多数软件项目中是不可缺少的，对于它进行压力测试是为了找出数据库对象是否可以有效地承受来自多个用户的并发访问。这些对象主要是：索引、触发器、存储过程和锁。通过对SQL语句和存储过程的测试，自动化的压力测试工具可以间接的反应数据库对象是否需要优化。

这些自动化的测试工具很多，各有特点，基于Java 的项目可以使用JMeter，.Net 项目可以采用.Net 集成开发环境中提供的测试方案。