数据库在软件应用程序中是无法避免的部分之一。
不管是web，桌面应用，移动端，B2B，B2C等，数据库在后端都是必需的。随着应用程序复杂程度的增加，对更强大更安全的数据库需求也随之增加。对于具有高交易频率的应用来说功能齐全的数据库的必要性是耦合的。
为什么是数据库？
下面会看到为什么要验证数据库的以下方面：
①数据映射
在软件系统中，数据一般是在UI和后端数据库中来回传输，因为需要注意一下方面：
- 检查UI、前端表单中的字段是否与数据表中的字段一直映射。通常映射信息在需求文档中定义；
- 当应用程序在前段执行某个操作时，都会在后端调用相应的CURD操作。作为测试人员必须检查是否正确的调用以及调用操作本身是否成功。
②ACID属性验证
原子性、一致性、隔离性和持久性。数据库执行的每个事务都必须遵守这四个属性。
- 原子性：事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
- 一致性：一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
- 隔离性：当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
- 持久性：事务一旦提交完成，任何外部因素（断电/崩溃）都不能改变它。
③数据完整性
对于任何CURD操作，共享数据更新的最新值/状态都应显示在所有窗体和屏幕上。不应一个显示最新值一个显示比较旧的值。
C：创建–用户保存任何新的事务时，执行创建操作
R：检索–用户搜索或者查看任何已经保存的交易时，执行检索操作
U：更新–用户编辑或者修改现有记录时，执行更新操作
D：删除–用户从系统中删除任何记录时，执行删除操作
用户执行的任何数据库操作始终是以上四个操作之一。在设计数据库测试用例的方式包括检查数据在所有看起来的位置，以查看它是否始终相同。
④业务规则一致性
数据库中更复杂的组件意味着更复杂的组件，如关系约束、触发器、存储过程等。因此，测试人员必须提出适当的SQL查询才能验证这些复杂的对象。
数据库测试清单
1、事务
测试事务时，确保满足ACID属性。
2、数据库架构
- 确定数据库运行所依据的要求。样品要求：
- 在创建任何其他字段之前要创建的主键。
- 外键应完全索引，以便于检索和搜索。
- 字段名称以某些字符开头或结尾。
- 具有某些值可以或不能插入的约束的字段。
- 根据相关性使用下列方法之一：
- SQL 查询 *DESC<表名称>*以验证架构。
- 用于验证各个字段的名称及其值的正则表达式
- SchemaCrawler 等工具
3、 触发器
当某个事件发生在某个表上时，可以自动指示执行一段代码（触发器）。
例如，一名新学生加入了一所学校。学生正在上2节课：数学和科学。学生将被添加到”学生表”中。一旦学生被添加到学生表中，触发器就可以将他添加到相应的主题表中。
测试的常用方法是首先独立执行触发器中嵌入的 SQL 查询并记录结果。接下来，将触发器作为一个整体执行。比较结果。
这些测试在黑盒和白盒测试阶段进行。
- 白盒测试：存根和驱动程序用于插入、更新或删除会导致触发器被调用的数据。基本思想是，即使在与前端（UI）集成之前，也只需单独测试数据库。
- 黑盒测试:
a） 由于 UI 和 DB，集成现在可用;我们可以以调用触发器的方式从前端插入/删除/更新数据。之后，Select 语句可用于检索数据库数据，以查看触发器是否成功执行了预期的操作。
b） 测试这一点的第二种方法是直接加载将调用触发器的数据，并查看它是否按预期工作。
4、 存储过程
存储过程或多或少类似于用户定义的函数。这些语句可以通过调用过程/执行过程语句调用，并且输出通常采用结果集的形式。
它们存储在 RDBMS 中，可用于应用程序。
这些也在以下时间进行测试：
- 白盒测试：存根用于调用存储过程，然后根据预期值验证结果。
- 黑盒测试：从应用程序的前端 （UI） 执行操作，并检查存储过程的执行及其结果。
5、字段约束
默认值、唯一值和外键：
- 执行执行数据库对象条件的前端操作
- 使用 SQL 查询验证结果。
检查某个字段的默认值非常简单。它是业务规则验证的一部分。您可以手动执行此操作，也可以使用QTP等工具。您可以手动执行一项操作，该操作将从前端添加字段默认值以外的值，并查看它是否会导致错误。
数据库测试活动
#1） 确保数据映射：
数据映射是数据库中的关键方面之一，每个软件测试人员都应该对其进行严格的测试。
确保AUT与其数据库的不同表单或屏幕之间的映射不仅准确，而且符合设计文档（SRS / BRS）或代码。基本上，您需要验证每个前端字段与其相应的后端数据库字段之间的映射。
对于所有 CRUD 操作，请验证当用户从应用程序的 GUI 中单击”保存”、”更新”、”搜索”或”删除”时，是否更新了相应的表和记录。
您需要验证的内容：
- 表映射、列映射和数据类型映射。
- 查找数据映射。
- 在 UI 上为每个用户操作调用正确的 CRUD 操作。
- CRUD 操作成功。
#2）确保事务的ACID属性：
DB Transactions的ACID属性是指”原子性”，”Consistency”，”Isolation“和”Durability“。在数据库测试活动期间，必须对这四个属性进行适当的测试。您需要验证每个事务是否都满足数据库的 ACID 属性。
让我们通过下面的SQL代码举一个简单的例子：
1 |
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100)); |
ACID测试表将有两列 - A和B。存在一个完整性约束，即 A 和 B 中的值之和应始终为 100。
原子性测试将确保在此表上执行的任何事务都是全部或无，即如果事务的任何步骤失败，则不会更新任何记录。
一致性测试将确保每当更新列 A 或 B 中的值时，总和始终保持为 100。如果总和不是 100，则不允许在 A 或 B 中插入/删除/更新。
隔离测试将确保如果两个事务同时发生并尝试修改ACID测试表的数据，则这些牵引力是孤立执行的。
耐久性测试将确保一旦提交了此表上的事务，即使发生断电、崩溃或错误，它仍将保持这种状态。
如果您的应用程序正在使用分布式数据库，则需要进行更严格、彻底和敏锐的测试。
#3） 确保数据完整性
考虑应用程序的不同模块（即屏幕或表单）以不同的方式使用相同的数据，并对数据执行所有CRUD操作。
在这种情况下，请确保在各处都反映最新的数据状态。系统必须在所有表单和屏幕上显示更新和最新的值或此类共享数据的状态。这称为数据完整性。
验证数据库数据完整性的测试用例：
- 检查是否所有触发器都已就位以更新引用表记录。
- 检查每个表的主要列中是否存在任何不正确/无效的数据。
- 尝试在表中插入错误的数据，并观察是否发生任何故障。
- 检查在插入父级之前尝试插入子项会发生什么情况（尝试使用主键和外键）。
- 测试在删除仍由任何其他表中的数据引用的记录时是否发生任何故障。
- 检查复制的服务器和数据库是否同步。
#4）确保已实现的业务规则的准确性：
如今，数据库不仅仅用于存储记录。事实上，数据库已经发展成为非常强大的工具，为开发人员在数据库级别实现业务逻辑提供了充分的支持。
强大功能的一些简单示例包括”参照完整性”、关系约束、触发器和存储过程。
因此，使用 DB 提供的这些功能和许多其他功能，开发人员可以在 DB 级别实现业务逻辑。测试人员必须确保实现的业务逻辑正确且工作准确。
