为什么要测试数据库？数据映射
在软件系统中，数据经常从UI（用户界面）到后端数据库之间来回穿梭，反之亦然。因此，这些是需要注意的一些方面：
检查用户界面/前端表单中的字段是否与数据库表中的相应字段有一致的映射。 通常情况下，这种映射信息在需求文件中被定义。
每当在应用程序的前端执行某个动作时，相应的CRUD（创建、检索、更新和删除）动作会在后端被调用。测试人员必须检查是否调用了正确的动作，以及调用的动作本身是否成功。
ACID属性验证
原子性、一致性、隔离性和持久性。DB执行的每个事务都必须遵守这四个属性。
- 原子性意味着一个事务要么失败要么通过。这意味着，即使交易部分失败了，也意味着整个交易都失败了。通常情况下，这被称为 “全有或全无 “规则。
- 一致性： 事务将总是导致数据库的有效状态。
- 隔离性： 如果有多个事务同时被执行，DB的结果/状态应该与它们逐一执行的情况相同。
- 持久性： 一旦事务完成并提交，任何外部因素，如断电或崩溃，都不能改变它。
数据完整性
对于任何CRUD操作，共享数据的更新和最新的值/状态应该出现在所有的表格和屏幕上。
- C Create : 创建 – 当用户 “保存 “任何新事务时，”创建 “操作被执行。
- R Retrieve : 检索 – 当用户 “搜索 “或 “查看 “任何已保存的事务时，会执行 “检索 “操作。
- U Update : 更新 – 当用户’编辑’或’修改’现有的记录，DB的’更新’操作被执行。
- D Delete : 删除 – 当用户从系统中’删除’任何记录时，将执行DB的’删除’操作。
业务规则的符合性
数据库中更多的复杂性意味着更复杂的组件，如关系约束、触发器、存储过程等。因此，测试人员必须想出适当的SQL查询，以验证这些复杂的对象。
数据库测试检查表事务
当测试交易时，重要的是确保它们满足ACID属性。
这些是常用的语句：
BEGIN TRANSACTION TRANSACTION#END TRANSACTION TRANSACTION#ROLLBACK TRANSACTION#SELECT * FROM TABLENAME 数据库模式
数据库模式是对数据在数据库中如何组织的正式定义。为了测试它：
- 确定数据库运行所基于的要求。样品要求：
- 在创建任何其他字段之前，应先创建主键。
- 外键应该是完全索引的，以便于检索和搜索。
- 字段名以某些字符开始或结束。
- 具有限制条件的字段，即某些值可以或不可以被插入。
- 根据相关性，使用以下方法之一：
- SQL查询DESC来验证模式。
- 用正则表达式来验证各个字段的名称和它们的值
- 像SchemaCrawler这样的工具
触发器
当某个事件发生在某个表上时，一段代码（触发器）自动执行。
例如，新学生加入了学校。该学生正在上2门课：数学和科学。该学生被添加到 “学生表 “中。 一旦该学生被添加到学生表中，触发器可以将他添加到相应的科目表中。
常用的测试方法是，首先独立执行嵌入在触发器中的SQL查询，并记录结果。之后再执行整个触发器比较结果。
- 白盒测试：
桩和驱动用于插入或更新或删除数据，这将导致触发器被调用。在与前端（UI）集成之前，只测试数据库。
- 黑盒测试：
- 从前端插入/删除/更新数据的方式来调用Trigger。
- 直接加载调用触发器的数据，看它是否按预期工作。
存储过程
存储程序或多或少类似于用户定义的函数。这些程序可以通过调用程序/执行程序语句来调用，其输出通常是结果集。
这些过程存储在RDBMS中供应用。
- 白盒测试
使用桩来调用存储程序，然后根据预期值来验证结果。
- 黑盒测试： 从应用程序的前端（UI）执行操作，并检查存储过程的执行情况及其结果。
字段约束
默认值，唯一值，和外键：
数据测试活动数据映射：
确保AUT的不同表格或屏幕与数据库之间的映射不仅准确，而且符合设计文件（SRS/BRS）或代码。基本上，你需要验证每个前端字段和其对应的后台数据库字段之间的映射。
对于所有的CRUD操作，验证当用户从应用程序的GUI点击 “保存”、”更新”、”搜索 “或 “删除 “时，相应的表和记录是否被更新。
- 表的映射，列的映射，以及数据类型的映射。
- 查询数据映射。
- 在用户界面上的每个用户操作都调用了正确的CRUD操作。
- CRUD操作是成功的。
ACID
DB事务的ACID属性是指 “原子性”、”一致性”、”隔离性 “和 “持久性”。在数据库测试活动中必须对这四个属性进行适当的测试。你需要验证每一个交易是否满足数据库的ACID属性。
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));隔离测试将确保如果两个事务同时发生并试图修改ACID测试表的数据，那么这些事务是在隔离的情况下执行的。
持久性测试将确保一旦该表上的事务被提交，它将保持不变，即使是在断电、崩溃或错误的情况下。
如果你的应用程序使用的是分布式数据库，这个领域需要更严格、更彻底、更敏锐的测试。
数据的完整性
- 检查所有的触发器是否已经到位，以更新参考表记录。
- 检查每个表的主要列中是否存在任何不正确/无效的数据。
- 尝试在表中插入错误的数据，观察是否有任何故障发生。
- 检查如果你试图在插入子表之前插入其父表会发生什么（尝试玩弄主键和外键）。
- 测试如果你删除一条仍然被其他表中的数据引用的记录，是否会发生故障。
- 检查复制服务器和数据库是否处于同步状态。
确保实施的业务规则的准确性：
今天，数据库不仅仅是为了存储记录。事实上，数据库已经发展成为非常强大的工具，为开发人员提供充分的支持，在数据库层面上实现业务逻辑。
使用这些和许多其他由数据库提供的功能，开发人员在数据库层面实现业务逻辑。测试人员必须确保实现的业务逻辑是正确的，并能准确地工作。
如何测试数据库
- 准备好环境
- 运行测试
- 检查测试结果
- 根据预期结果进行验证
- 报告结果
通常情况下，使用SQL查询来开发测试。最常用的命令是 “选择”。
Select * from where 除了Select之外，SQL还有3种重要的命令类型：
- DDL: 数据定义语言
- DML： 数据操作语言
- DCL：数据控制语言
让我们看看最常用的语句的语法。
数据定义语言 使用CREATE, ALTER, RENAME, DROP和TRUNCATE来处理表（和索引）。
数据操作语言 包括添加、更新和删除记录的语句。
数据控制语言： 处理给用户操作和访问数据的授权问题。Grant和Revoke是使用的两个语句。
Grant 语法：
Grant select/updateOn To ;Revoke语法：
Revokeselect/updateon from;实用技巧
- 自己写查询：
为了准确地测试数据库，测试人员应该有非常好的SQL和DML（数据操作语言）语句的知识。测试人员还应该知道AUT的内部数据库结构。
你可以结合GUI和各自表中的数据验证，以获得更好的覆盖率。如果你使用的是SQL服务器，那么你可以利用SQL查询分析器来编写查询，执行它们并检索结果。
当应用程序的复杂程度较低或中等时，这是测试数据库的最佳和强大的方法。
如果应用程序非常复杂，那么测试人员可能很难或不可能编写所有需要的SQL查询。对于复杂的查询，你可以从开发人员那里得到帮助。我一直推荐这种方法，因为它能给你测试的信心，也能提高你的SQL技能。
- 观察每个表中的数据：
你可以使用CRUD操作的结果进行数据验证。当你知道数据库集成时，这可以通过使用应用程序UI手动完成。但是，当不同的数据库表中有大量的数据时，这可能是一项繁琐的工作。
对于手动数据测试，数据库测试人员必须拥有良好的数据库表结构知识。
- 从开发人员那里获得查询
这是最简单的测试数据库的方法。从GUI中执行任何CRUD操作，并通过执行从开发人员那里获得的相应SQL查询来验证其影响。它既不需要很好的SQL知识，也不需要对应用程序的数据库结构有很好的了解。
但这种方法需要谨慎使用。如果开发人员给出的查询在语义上是错误的，或者不能正确地满足用户的要求，怎么办？这个过程将直接导致数据验证失败。
- 利用数据库自动化测试工具：
有几种工具可用于数据测试过程。你应该根据你的需要选择正确的工具，并对其进行最佳利用。
总结
有了所有这些在数据库上测试的功能、因素和过程，对测试人员精通关键数据库概念的技术要求越来越高。尽管有些人认为测试数据库会产生新的瓶颈，并且是大量的额外支出，但这是一个吸引大量关注和需求的测试领域。