数据库（数据）测试教程

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

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

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

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

用户界面测试和数据测试之间的差异

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

数据库测试的类型

数据库测试的三种类型是

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

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

什么是模式测试？

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

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

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

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

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

例如，如果开发人员想要更改或删除表结构，测试人员将希望确保使用该表的所有存储过程和视图都与特定更改兼容。另一个例子是，如果测试人员想要检查两个数据库之间的架构更改，他们可以使用简单的查询来实现。

数据库表、列测试

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

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

• 数据类型
• 字段长度

后端数据库列与应用程序前端的列的比较。

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

键和索引测试

对键和索引的重要检查 –

1. 检查是否需要

• 首要的关键
• 外键

已在所需表上创建约束。

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

• Cluster编目索引
• 不刻字 Cluster编目索引

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

存储过程测试

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

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

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

触发测试

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

数据库服务器验证

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

功能数据库测试

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

以下是数据库验证需要遵守的基本条件。

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

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

反之亦然，即测试人员首先在用户界面执行操作，然后从后端进行验证。

检查数据完整性和一致性

以下检查很重要

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

登录和用户安全

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

1. 如果出现以下情况，应用程序是否会阻止用户继续使用应用程序：

• 用户名无效但密码有效
• 用户名有效但密码无效。
• 用户名无效且密码无效。

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

非功能测试

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

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

最低系统设备要求– 最低系统配置，使系统能够满足利益相关者正式提出的性能期望。这样可以最大限度地减少无关的硬件、软件和相关的拥有成本。这一特定要求可归类为整体业务优化要求。

负载测试

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

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

重要的负载测试工具是 LoadRunner 专业版，赢得亚军和 JMeter.

重要的压力测试工具是 LoadRunner 专业版 和 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.

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

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

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 测试是必要的。

最佳实践

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

还要检查 数据库测试面试问题与答案