数据库测试教程

测试和开发团队成员通常最重视 GUI，因为图形用户界面是应用程序最可见的部分。然而，同样重要的是验证作为应用程序核心的信息，即数据库。

让我们考虑一个用户进行交易的银行应用程序。现在从数据库测试或 DB 测试的角度来看，以下几点很重要

1. 应用程序将交易信息存储在应用程序数据库中，并正确地向用户显示。
2. 在此过程中没有信息丢失。
3. 应用程序不会保存任何部分执行或中止的操作信息。
4. 不允许任何未经授权的个人访问用户信息。

为确保以上所有目标，我们需要使用数据验证或数据测试。

用户界面测试与数据测试的区别

用户界面测试	数据库或数据测试
这种类型的测试也称为图形用户界面测试或前端测试。	这种类型的测试也称为后端测试或数据测试。
这种类型的测试主要处理所有向用户开放供查看和交互的可测试项目，如表单、演示、图表、菜单和报告等（通过 VB、VB.net、VC++、Delphi 等前端工具创建）。	这种类型的测试主要处理所有通常对用户隐藏的可测试项目。这些包括内部流程和存储，如汇编、DBMS（如 Oracle、SQL Server、MYSQL 等）。
这类测试包括验证 文本框 选择下拉框 日历和按钮 页面导航 图片显示 整体应用程序的外观和感觉	这种类型的测试涉及验证 模式 数据库表 列 键和索引 存储过程触发器 数据库服务器验证 验证数据重复
测试人员必须全面了解业务需求以及开发工具的使用和自动化框架及工具的使用。	为了能够执行后端测试，测试人员必须在数据库服务器和结构化查询语言概念方面有很强的背景。

数据库测试的类型

数据库测试的 3 种类型是

1. 结构化测试
2. 功能测试
3. 非功能测试

在本数据库测试教程中，我们将逐一探讨每种类型及其子类型。

什么是模式测试？

数据库测试中的模式测试验证与数据库相关的各种模式格式，并核实表/视图/列的映射格式是否与用户界面的映射格式兼容。模式测试的主要目的是确保前端和后端的模式映射相似。因此，它也被称为映射测试。

让我们讨论一下模式测试最重要的检查点。

1. 验证与数据库关联的各种模式格式。很多时候，表的映射格式可能与应用程序用户界面级别的映射格式不兼容。
2. 在存在未映射的表/视图/列的情况下，需要进行验证。
3. 还需要验证环境中的异构数据库是否与整个应用程序映射一致。

我们再来看一些用于验证数据库模式的有趣的数据库测试工具。

• 与 Ant 集成的 DBUnit 非常适合映射测试。
• SQL Server 允许测试人员通过编写简单的查询而不是通过代码来检查和查询数据库的模式。

例如，如果开发人员想要更改表结构或删除它，测试人员需要确保所有使用该表的存储过程和视图都与该特定更改兼容。另一个例子是，如果测试人员想要检查两个数据库之间的模式变化，他们可以通过使用简单的查询来做到这一点。

数据库表、列测试

让我们看一下数据库和列测试的各种检查。

1. 后端数据库字段和列的映射是否与前端的映射兼容？
2. 根据需求规范验证数据库字段和列的长度和命名约定。
3. 验证是否存在任何未使用/未映射的数据库表/列。
4. 验证兼容性

• 数据类型
• 字段长度

后端数据库列的那些与应用程序前端的那些。

5. 数据库字段是否允许用户根据业务需求规范文档提供所需的用户输入。

键和索引测试

键和索引的重要检查 –

1. 检查是否必需

• 主键
• 外键

约束已在所需的表上创建。

2. 检查外键的引用是否有效。
3. 检查两个表中主键和相应外键的数据类型是否相同。
4. 检查所有键和索引是否都遵循了所需的命名约定。
5. 检查所需字段和索引的大小和长度。
6. 是否需要

• 聚集索引
• 非聚集索引

已根据业务需求在所需的表上创建。

存储过程测试

检查存储过程的重要测试是

1. 开发团队是否采用了所需的 A) 编码标准约定，和 B) 异常和错误处理。针对被测应用程序的所有模块的所有存储过程。
2. 开发团队是否通过向被测应用程序应用所需的输入数据来覆盖所有条件/循环？
3. 当从数据库中必需的表中获取数据时，开发团队是否正确应用了 TRIM 操作？
4. 手动执行存储过程是否为最终用户提供了所需的结果？
5. 手动执行存储过程是否确保表字段按被测应用程序的要求进行更新？
6. 存储过程的执行是否能隐式调用所需的触发器？
7. 验证是否存在任何未使用的存储过程。
8. 可以在数据库级别完成的允许空值条件的验证。
9. 当被测数据库为空时，验证所有存储过程和函数都已成功执行。
10. 根据被测应用程序的要求，验证存储过程模块的整体集成。

一些用于测试存储过程的有用的数据库测试工具是 LINQ、SP Test 工具等。

触发器测试

1. 在触发器的编码阶段是否遵循了必需的编码约定？
2. 检查为相应的 DML 事务执行的触发器是否满足了必需的条件。
3. 触发器执行后是否正确更新了数据？
4. 在被测应用程序领域内验证所需的更新/插入/删除触发器功能。

数据库服务器验证

1. 根据业务需求检查数据库服务器配置。
2. 检查所需用户的授权，使其只能执行应用程序所需级别的操作。
3. 检查数据库服务器是否能够满足业务需求规范所规定的最大允许用户事务数的需求。

功能性数据库测试

功能性数据库测试是一种数据库测试类型，用于从最终用户的角度验证数据库的功能需求。功能性数据库测试的主要目标是测试最终用户执行的与数据库相关的事务和操作是否按预期工作。

以下是进行数据库验证需要注意的基本条件。

• 字段是否为必填项，同时允许该字段为空值？
• 每个字段的长度是否足够？
• 所有相似字段在不同表中是否具有相同的名称？
• 数据库中是否存在任何计算字段？

这个特定过程是从最终用户角度验证字段映射。在这种情况下，测试人员将在数据库级别执行一个操作，然后导航到相关的用户界面项，以观察和验证是否已执行正确的字段验证。

反之亦然，即首先由测试人员在用户界面执行操作，然后在后端进行验证，也应该完成。

检查数据完整性和一致性

以下检查很重要

1. 数据是否在逻辑上组织良好？
2. 存储在表中的数据是否正确并符合业务需求？
3. 被测应用中是否存在不必要的数据？
4. 数据是否按照从用户界面更新的数据要求存储？
5. 在将被测数据插入数据库之前，是否对数据执行了 TRIM 操作？
6. 交易是否按照业务需求规范执行，结果是否正确？
7. 如果事务已成功执行，数据是否已正确提交？
8. 如果事务未被最终用户成功执行，数据是否已成功回滚？
9. 如果事务未成功执行且涉及多个异构数据库，数据是否已回滚？
10. 所有事务是否都按照系统业务需求规定的设计程序执行？

登录和用户安全

登录和用户安全凭证的验证需要考虑以下几点。

1. 应用程序是否在以下情况下阻止用户继续操作

• 用户名无效但密码有效
• 用户名有效但密码无效。
• 无效的用户名和无效的密码。

2. 用户是否只被允许执行业务需求指定的特定操作？
3. 数据是否受到保护，免受未经授权的访问？
4. 是否创建了具有不同权限的不同用户角色？
5. 所有用户是否都具有业务规范所要求的指定数据库的必要访问级别？
6. 检查敏感数据，如密码、信用卡号码是否已加密，而不是以明文形式存储在数据库中。确保所有账户都应有复杂且不易猜测的密码是一个好习惯。

非功能性测试

在数据库测试的背景下，非功能性测试可以根据业务需求分为不同的类别。这些可以是负载测试、压力测试、安全测试、可用性测试和兼容性测试等。负载测试和压力测试可以归入性能测试的范畴，在非功能性测试中具有两个特定的目的。

风险量化——风险量化帮助利益相关者确定在所需负载水平下的各种系统响应时间要求。这是任何质量保证任务的初衷。我们需要注意，负载测试并不直接减轻风险，而是通过风险识别和风险量化的过程，提供纠正机会和补救动力，从而减轻风险。

最低系统设备要求– 允许系统满足利益相关者正式声明的性能期望的最低系统配置。这样可以最小化额外的硬件、软件以及相关的拥有成本。这一特定要求可以归类为整体业务优化要求。

负载测试

任何负载测试的目的都应被清楚地理解和记录。对于负载测试，以下类型的配置是必须的。

1. 最常用的用户事务如果效率不高，有可能影响所有其他事务的性能。
2. 最终测试套件中应至少包含一个非编辑用户事务，以便可以将此类事务的性能与其他更复杂的事务区分开来。
3. 应包括促进系统核心目标的更重要的事务，因为这些事务在负载下的失败，根据定义，具有最大的影响。
4. 应至少包含一个可编辑事务，以便可以将此类事务的性能与其他事务区分开来。
5. 在大量虚拟用户下，所有预期需求下的最佳响应时间。
6. 获取各种记录的有效时间。

重要的负载测试工具是 LoadRunner Professional、win runner 和 JMeter。

重要的压力测试工具是LoadRunner Professional 和 JMeter。

数据库测试期间最常出现的问题

A significant amount of overhead could be involved to determine the state of the database transactions

解决方案： 整个流程规划和时间安排应该组织好，以免出现基于时间和成本的问题。

New test data have to be designed after cleaning up of the old test data.

解决方案：应事先准备好测试数据生成的计划和方法。

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

解决方案：维护 SQL 查询及其持续更新是整个测试过程的重要组成部分，应成为整体测试策略的一部分。

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

解决方案： 质量和整体项目进度之间应该有一个良好的平衡。

与数据库测试相关的误解或 misconceptions

Database Testing requires plenty of expertise and it is a very tedious job

现实：在软件测试中，有效且高效的数据库测试为整个应用程序提供了长期的功能稳定性，因此有必要在其背后付出辛勤的努力。

Database testing adds extra work bottleneck

现实：恰恰相反，数据库测试通过发现隐藏的问题，从而主动帮助改进整个应用程序，为整体工作增加了更多价值。

Database testing slows down the overall development process

现实：大量的数据库测试有助于全面提高数据库应用程序的质量。

Database testing could be excessively costly

现实：在数据库测试上的任何支出都是一项长期投资，它会导致应用程序的长期稳定性和健壮性。因此，在数据库测试或SQL测试上的支出是必要的。

最佳实践

• 所有数据，包括元数据和功能数据，都需要根据需求规范文档的映射进行验证。
• 需要验证由开发团队创建或与之协商创建的测试数据。
• 通过手动和自动化程序验证输出数据。
• 部署各种技术，如因果图技术、等价划分技术和边界值分析技术，以生成所需的测试数据条件。
• 所需数据库表的引用完整性验证规则也需要被验证。
• 为验证数据库一致性而选择默认表值是一个非常重要的概念。是否已成功在数据库中为所有必需的登录事件添加日志事件。
• 计划任务是否按时执行？
• 及时备份数据库。

另请查看 - 数据库测试面试问题与答案