目录
数据库模式测试
- 数据库模式测试主要是测试数据库逻辑模式、外模式、内模式的定义是否满足用户需求。本书主要关心数据库逻辑模式和外模式测试，即基本表测试和视图测试。基本表测试涉及到基本表数据结构测试、数据库完整性测试。
基本表数据结构测试
- 基本表数据结构测试是测试数据库基本表的数据结构是否合理，如字段的数据类型、宽度是否合理。例如，图书管理系统有基本表：图书（书号，书名，作者，出版社，出版日期，定价）。如果规定书名是40B的字符型数据，则书名长度超过40B的图书的信息就不能完整地保存在图书管理系统数据库中。
- 通过运行测试用例，数据库测试人员可以比较方便地进行基本表数据结构测试。然而，数据库测试人员也可以通过专门的数据库访问工具查看基本表属性来检查其数据结构。
数据库完整性测试
- 数据库完整性测试包括实体完整性、参照完整性、用户定义的完整性等测试。从基本表的角度来看，即测试基本表的表级、列级完整性约束是否满足用户需求。
- 例如，图书管理系统有两张表：图书（书号，书名，作者，出版社，出版日期，定价）、借书（读者号，书号，借出日期，应还日期）。其中，图书表的主码为书号、用户定义的完整性为定价>0，借书表的外码有书号（对应图书表的书号）。如果在图书表中某个记录的书号为空，则违反了实体完整性规则。如果在图书表中某个记录的定价为-1，则违反了用户定义的完整性规定。如果借书表中某个记录的书号为“AB121314”，但是在图书表中找不到“AB121314”号，则违反了参照完整性规则。
- 数据库完整性测试一般还包含了触发器的测试。
视图测试
- 数据库视图测试主要是测试数据库视图定义是否反映了用户的需求。例如，视图的列定义是否正确（视图的列可能是在相关基本表的列中选择的，也可能由相关基本表的某些列通过某种运算得到的）、视图数据的来源表名是否正确、视图数据过滤条件是否正确、视图的分组是否正确、视图的统计与排序是否正确。
数据库功能测试
- 数据库功能测试是通过测试用例运行数据库，以验证该数据库功能的正确和无遗漏。数据库功能测试的内容包括数据定义、数据操纵、数据库安全性、并发处理等的测试。
数据定义功能测试
- 数据库的数据定义功能是指对基本表、视图、索引、角色等对象的定义、修改与删除。这些对象一般通过可视化数据库设计工具或者SQL语句在数据库系统开发阶段进行创建、修改和删除。
- 但是，一些通用性较强的数据库系统的基本表、视图、索引、角色等对象相当一部分是在系统安装或者正常运行时自动产生的。此时，应该通过运行相应的模块，测试数据定义功能是否正确执行。数据定义功能测试的主要任务是测试数据库系统动态创建、修改和删除基本表、视图、索引、角色等是否符合用户需求。数据定义功能的测试输出结果一般通过专门的数据库访问工具查看，当然也可以通过在数据库系统中设置基本表、视图、索引、角色等对象查询模块来确定它们的存在性及属性。
- 例如，某B2C（Business to Customer，企业到用户的电子商务模式）网站销售管理系统的商品交易记录是按年存储的。2008年的数据库名为DB2008，2009年的数据库名为DB2009。销售管理系统发现相应年份数据库不存在时，就自动创建之。因此，应该设计合适的测试用例实现年份变换，测试销售管理系统能不能自动创建数据库。另一方面，还要测试数据库系统是否错误地重复定义数据。上例中，销售管理系统在同一年份重复创建数据库是不允许的。
数据操纵功能测试
- 数据库的数据操纵功能测试是指对数据库数据插入、修改、删除、查询、统计和排序等进行测试。
数据更新功能测试
-
数据更新功能测试
为了保证数据更新功能的正确执行，必须设计测试用例进行测试。数据更新功能的测试输出结果一般可以用数据库系统有关模块查看它们，也可以通过专门的数据库访问工具查看它们。
-
在测试时务必注意，一个数据更新操作可能引发一系列的数据更新操作。例如， 某些数据库系统要求插入数据时，同时要执行修改与删除数据的操作。因此测试输出结果可能涉及到多个基本表或视图，测试人员需要到多处查看测试输出结果。例如，销售管理系统每销售一件商品，需要插入销售记录、修改库存量，当该商品无库存并不再进货时还要删除该商品目录。此时，测试人员需要在销售记录表、库存表、商品目录表等处查看测试输出结果。
数据查询功能测试
- 数据查询是对数据库中的数据进行检索，筛选出满足特定条件的数据。数据查询功能测试就是测试数据库系统查询功能得到的数据是否符合预定要求。可以用专门的数据库访问工具获取满足相同条件的数据，通过比较来判断数据库系统处理是否正确。
数据统计和排序功能测试
- 数据查询时往往伴随着数据的统计和排序。因此，数据统计和排序功能测试一般和数据查询功能测试一同进行。例如，图书管理系统有基本表：图书（书号，书名，作者，出版社，出版日期，定价）。在此基本表上按出版社统计图书种数，然后按出版社增序排序输出统计结果就需要数据查询和统计、排序功能同时测试。
数据库安全性测试
- 数据库安全性测试就是测试数据库的安全措施是否发挥作用并达到预期效果，有无漏洞。为此要充分了解破坏数据库安全性的方法和工具，有针对性地设计一些测试用例对系统进行测试。成功的数据库安全性测试最终应能突破各种保护，控制数据库。
- 目前，已知的破坏数据库安全性的方法有：
- 攻击数据库系统数据输入部分，篡改或窃取输入的数据、阻止输入数据、擅自向数据库输入数据等。
- 攻击数据库系统数据修改部分，篡改修改的数据、阻止修改数据、擅自修改数据库中的数据等。
- 攻击数据库系统数据检查部分，篡改检查方法、阻止检查、擅自对数据库中的数据进行检查等。
- 攻击数据库系统数据运算部分，篡改运算公式、阻止运算、擅自对数据库中的数据进行运算等。
- 攻击数据库系统数据删除部分，篡改删除的内容、阻止删除数据、擅自删除数据库中的数据等。
- 攻击数据库系统数据传输部分，篡改或窃取数据、阻止数据传输、自行向数据库中发送数据等。
- 通过操作系统的漏洞，篡改或窃取数据库的数据，窃取用户口令及其他有用的信息以进入系统。
- 申请和占用过多的资源瘫痪系统，以破坏安全措施，从而进入系统。
- 故意使系统出错，利用系统恢复的过程，窃取用户口令及其他有用的信息。
- 通过浏览残留在计算机各种资源中的垃圾（无用信息），以获取如口令、安全码、译码关键字等重要信息。
- 浏览全局数据（如注册表中的数据），期望从中找到进入系统的关键字。
- 浏览那些逻辑上不存在，但物理上还存在的各种记录和资料。
并发处理测试
- 数据库系统一般能同时处理多个事务。例如，在网上销售管理系统中，往往有多个用户同时在线，有客户、也有业务管理人员。因此，如果数据库系统的并发处理机制存在缺陷，就会发生诸如两个客户购买同一物品、两个业务管理人员同时更新某种商品的库存等冲突事件。为了找出数据库系统并发处理机制的可能缺陷，就必须进行并发处理测试。
- 数据库系统并发处理机制的缺陷可能难于发现。如只有一个用户使用时缺陷不会曝露、多个用户使用时才会曝露，正常情况下不会曝露、仅在特殊的软硬件环境下才会曝露。
- 数据库系统并发处理机制的可能缺陷包括：
- 一个用户的不同模块同时更新同一数据。
- 多个用户同时更新同一数据。
- 一个用户的一个模块更新数据，而另一个模块同时读取数据。
- 一个用户更新数据，而另一个用户同时读取数据。
- 一个用户的一个模块更新基本表、视图、索引、角色等对象，而另一个模块正在使用这些对象。
- 一个用户更新基本表、视图、索引、角色等对象，而另一个用户正在使用这些对象。
- 两个基本表互为被参照表。
- 一个用户的多个模块对数据库操作时形成死锁。
- 多个用户的事务形成死锁。
数据库性能测试
- 数据库系统只满足要求的功能而达不到要求的性能是不行的。所以还需要进行性能测试。
- 数据库性能测试是通过测试用例运行数据库，以验证该数据库是否满足需求规格说明书中规定的性能。数据库性能测试包括响应时间、吞吐量、可靠性、可扩展性、可维护性等性能指标测试。
- 数据库性能测试分为平均性能测试、压力测试、负载测试和强度测试4种类型。平均性能测试是指当数据库处于平均负荷条件下（即数据流量、数据存量、用户数、事务数、并发数等处于预测平均值）的性能测试。压力测试用于确定数据库还能运行的数据流量、数据存量、用户数、事务数、并发数等的最大值，即满负荷值。负载测试是当数据库处于满负荷条件下的性能测试。强度测试用于确定数据库在最差工作环境（如网络带宽、系统内存配置较低）时的性能，也可用于验证数据库处于正常工作状态时的各种资源的下限指标。
- 性能测试可以出现在测试过程的各个阶段，甚至在单元层次上也可以进行性能测试。然而，只有当所有的系统元素全部组装完毕，系统性能才能完全确定。
影响数据库性能的因素
- 影响数据库性能的因素很多，可分硬件和软件两个方面。硬件如CPU、内存、硬盘、网络等均会影响到数据库的性能。一般地，CPU越快越好、内存越多越好、硬盘性能越高越好、网络速度越快越好。软件如操作系统、数据库应用系统、DBMS、主语言编译系统、应用系统开发工具等也会对数据库的性能有影响。这里，仅列出数据库应用系统开发方面的因素对数据库性能的影响。主要有：
- 对于大型分布式数据库，没有合理地组织数据库服务器，各服务器负荷不均匀，导致有的服务器满负荷运行、有的服务器很空闲，整个数据库系统性能不高。
- 数据库配置不合理。例如，对数据库数据量的增长估计错误可能导致严重的碎片问题。
- 数据库基本表、视图设计不合理。例如，多个基本表数据重复，造成数据冗余、不一致。该用视图时，不用视图而用基本表，占用存储空间。
- 表的结构不合理。
- 例如，全国居民信息表Citizen存储了公民身份号码（对应列名：CitizenID）。我国公民身份号码是特征组合码，由17位数字本体码和一位校验码组成。排列顺序从左至右依次为：6位数字地址码、8位数字出生日期码、三位数字顺序码和一位数字校验码。地址码表示居民常住户口所在县(市、旗、区)的行政区划代码，按国家标准GB/T2260的规定执行。地址码（对应列名：AreaID）与行政区划名称（对应列名：AreaName）的对应关系存储在表Area中。现需要按行政区划查询居民信息。
- 某程序员写了一条SQL语句： SELECT * FROM Citizen,Area WHERE
Left(Citizen.CitizenID,6) = Area.AreaID。该语句在Citizen表的数据量不多时，响应时间尚可接受。但当Citizen的元组数超过1万时，响应时间迅速增加。经过分析, 原因是表的结构不合理。于是在Citizen中增加一个AreaID列，表示居民所在的行政区划代码，为外码，对应Area的AreaID列。SQL语句修改为SELECT * FROM Citizen,Area WHERE Citizen.AreaID = Area.AreaID，响应就快得多了。
- 索引不合理。一是该创建索引时不创建索引。如用户经常利用“姓名”列查询，但在“姓名”列上没有创建索引。再如在大表上不创建索引。二是不该创建索引时创建索引，特别是在具有重复数值的列上创建索引。如在“性别”列上创建索引，由于该列只有两个唯一值，所以该索引的效率很低。再如在小表上创建索引。
- 并发用户太多。随着数据库系统并发用户的增多，需要为共享处理过程分配更多的内存。
- SQL语句不合理，复杂的SQL语句往往导致响应时间增加。