# 带有示例测试案例的数据库（数据）测试教程 > 原文： [https://www.guru99.com/data-testing.html](https://www.guru99.com/data-testing.html) ## 什么是数据库测试？ **数据库测试**是一种软件测试，用于检查被测数据库的架构，表，触发器等。 它还检查数据的完整性和一致性。 它可能涉及创建复杂的查询以对数据库进行负载/压力测试并检查其响应能力。 ## 为什么要进行数据库测试？ 测试和开发团队成员通常最重视 GUI，因为图形用户界面恰好是应用程序中最可见的部分。 但是，同样重要的是验证作为应用程序（即数据库）核心的信息。 让我们考虑一个用户进行交易的银行应用程序。 现在，从数据库测试的角度来看，以下几点很重要： 1. 该应用程序将交易信息存储在应用程序数据库中，并将其正确显示给用户。 2. 在此过程中，不会丢失任何信息。 3. 应用程序不会保存部分执行或中止的操作信息。 4. 未经授权的个人不得访问用户信息。 为了确保上述所有目标，我们需要使用数据验证或数据测试。 在本教程中，我们将研究 * [GUI 和数据库测试之间的区别](#1) * [数据库测试的类型](#2) * [模式测试](#3) * [数据库表，列测试](#4) * [存储过程测试](#5) * [触发测试](#6) * [数据库服务器验证](#7) * [功能数据库测试](#71) * [登录名和用户安全性](#8) * [负载测试](#88) * [压力测试](#9) * [与数据库测试有关的误解或误解](#10) * [最佳做法](#11) ## 用户界面和数据测试之间的根本差异  | **用户界面测试** | **数据库或数据测试** | | 这种测试也称为图形用户界面测试或前端测试。 | 这种测试也称为后端测试或数据测试。 | | 这种类型的测试主要处理所有可供用户查看和交互的可测试项目，例如表单，演示文稿，图形，菜单和报表等。（通过 VB，VB.net，VC ++，Delphi-前端工具创建） ） | 这种类型的测试主要处理通常向用户隐藏以供收看的所有可测试项目。 这些包括内部过程和存储（如程序集），DBMS（如 Oracle）， [SQL](/sql.html) Server，MYSQL 等。 | | 这种类型的测试包括验证 文本框， 选择下拉列表， 日历和按钮， 从一页导航到另一页， ] 图像显示以及 整个应用程序的外观。 | 这种测试涉及验证 模式， 数据库表， 列， 键和索引， 存储过程 ， 触发器， 数据库服务器验证， 验证数据重复， | | 测试人员必须对业务需求以及开发工具的使用以及自动化框架和工具的使用有全面的了解。 | 为了能够执行后端测试，测试人员必须在数据库服务器和结构化查询语言概念方面具有深厚的背景。 | ## **数据库测试的类型**  数据库测试的 3 种类型是 1. 结构测试 2. 功能测试 3. 非功能测试 让我们逐一研究每种类型及其子类型。 ## 结构数据库测试 结构化数据测试涉及验证数据存储库中的所有那些元素，这些元素主要用于存储数据，并且不允许最终用户直接操作。 在这些类型的测试中，数据库服务器的验证也是一个非常重要的考虑因素。 测试人员成功完成此阶段需要精通 SQL 查询。 ## 模式测试 模式测试的主要方面是确保前端和后端之间的模式映射相似。 因此，我们也可以将模式测试称为**映射测试。** 让我们讨论用于模式测试的最重要的检查点。 1. 验证与数据库关联的各种模式格式。 很多时候，表的映射格式可能与应用程序的用户界面级别中存在的映射格式不兼容。 2. 对于未映射的表/视图/列，需要进行验证。 3. 还需要验证环境中的异构数据库是否与整个应用程序映射一致。 让我们也看看一些验证数据库模式的有趣工具。 * 与 Ant 集成的 DBUnit 非常适合映射测试。 * SQL Server 允许测试人员通过编写简单查询而不是通过代码来检查和查询数据库的架构。 例如，如果开发人员想要更改表结构或将其删除，则测试人员将要确保使用该表的所有存储过程和视图都与特定更改兼容。 另一个例子可能是，如果测试人员想要检查 2 个数据库之间的架构更改，则可以使用简单的查询来完成。 ## 数据库表，列测试 让我们研究一下数据库和列测试的各种检查。 1. 后端中数据库字段和列的映射是否与前端中的那些映射兼容。 2. 验证需求指定的数据库字段和列的长度和命名约定。 3. 验证是否有未使用/未映射的数据库表/列。 4. 验证的兼容性 * 数据类型 * 场长 后端数据库列与应用程序前端中存在的列。 5. 数据库字段是否允许用户根据业务需求规范文档的要求提供所需的用户输入。 键和索引测试 重要检查键和索引- 1. 检查是否需要 * 首要的关键 * 外键 在所需表上创建了约束。 2. 检查外键引用是否有效。 3. 检查两个表中主键和对应的外键的数据类型是否相同。 4. 检查所有键和索引是否都遵循必需的命名约定。 5. 检查必填字段和索引的大小和长度。 6. 是否要求 * 聚集索引 * 非聚集索引 已在业务需求指定的必需表上创建。 ## 存储过程测试 将为存储过程验证的最重要的事物的列表。 1. 开发团队是否采用了要求的 * 编码标准约定 * 异常和错误处理 测试中应用程序所有模块的所有存储过程。 2. 开发团队是否通过将所需的输入数据应用于被测应用程序来覆盖所有条件/循环。 3. 每当从数据库中的所需表中获取数据时，开发团队是否正确地应用了 TRIM 操作。 4. 手动执行存储过程是否可以为最终用户提供所需的结果 5. 手动执行存储过程是否可以确保表字段按照被测试应用程序的要求进行更新。 6. 执行存储过程是否启用所需触发器的隐式调用。 7. 验证是否有未使用的存储过程。 8. 可以在数据库级别完成的 Allow Null 条件验证。 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. 检查诸如密码，信用卡号之类的敏感数据是否已加密并且没有以纯文本格式存储在数据库中。 确保所有帐户都应使用复杂且不容易猜到的密码，这是一个好习惯。 **非功能测试** 根据业务需求，可以将数据库测试环境中的非功能测试分为各种类别。 这些可以是负载测试，[压力测试](/stress-testing-tutorial.html)，[安全测试](/what-is-security-testing.html)，[可用性测试](/usability-testing-tutorial.html)和[兼容性测试](/compatibility-testing.html)等。 可以在[性能测试](/performance-testing.html)范围内进行分组的负载测试和压力测试在达到非功能测试的作用时有两个特定的目的。 **风险量化**-风险量化实际上可帮助涉众确定所需负载水平下各种系统响应时间的要求。 这是任何质量保证任务的初衷。 我们需要注意的是，负载测试并不能直接减轻风险，而是通过风险识别和风险量化过程提供纠正机会，并提供了可以减轻风险的补救措施。 **最低系统设备要求**-我们通过正式测试所观察到的理解，即最小的系统配置，它将使系统满足涉众的正式陈述的性能期望。 这样就可以最小化无关的硬件，软件和相关的拥有成本。 可以将此特定要求归类为总体业务优化要求。 ## **负载测试** 任何负载测试的目的都应该清楚地理解和记录。 以下类型的配置是负载测试所必需的。 1. 如果其他用户事务效率不高，则它们可能会影响所有其他事务的性能。 2. 最终测试套件中至少应包含一个非编辑用户事务，以便可以将此类事务的性能与其他更复杂的事务区分开。 3. 应该包括有助于系统核心目标的更重要的事务，因为根据定义，这些事务在负载下的失败具有最大的影响。 4. 应该包括至少一个可编辑的事务，以便可以将此类事务的性能与其他事务区分开。 5. 在满足所有预期需求的情况下，在大量虚拟用户的情况下观察最佳响应时间。 6. 对获取各种记录的有效时间的观察。 重要的负载测试工具是负载运行程序，获胜运行程序和 JMeter。 ## 压力测试 压力测试有时也称为弯曲测试，因为它在巨大的工作量下给被测应用程序施加压力，从而导致系统出现故障。这有助于确定系统的故障点。 重要的压力测试工具是负载运行程序，获胜运行程序和 JMeter。 数据库测试期间最常见的问题 1. 为了确定数据库事务的状态，可能会涉及大量开销。 2. 解决方案：应该组织整个过程的计划和时间安排，以免出现基于时间和成本的问题。 3. 在清除旧测试数据之后，必须设计新的测试数据。 4. 解决方案：应该准备用于测试数据生成的事先计划和方法。 5. 需要 SQL 生成器来转换 SQL 验证器，以确保 SQL 查询易于处理所需的数据库测试用例。 6. 解决方案：维护 SQL 查询及其连续更新是整个测试过程的重要组成部分，应作为整个测试策略的一部分。 7. 上述先决条件确保了数据库测试过程的设置可能既昂贵又耗时。 8. 解决方案：质量和总体项目进度持续时间之间应该保持良好的平衡。 [ ](/images/truth.png) **与数据库测试有关的神话或误解。** 1. 数据库测试需要大量的专业知识，这是一项非常繁琐的工作 * 现实：有效的数据库测试为整个应用程序提供了长期的功能稳定性，因此有必要在其后面进行艰苦的工作。 2. 数据库测试增加了额外的工作瓶颈 * 现实：相反，数据库测试通过发现隐藏问题来为整体工作增加更多价值，从而主动帮助改进整体应用程序。 3. 数据库测试减慢了整个开发过程 * 现实：大量的数据库测试有助于整体提高数据库应用程序的质量。 4. 数据库测试可能会过于昂贵 * 现实：数据库测试上的任何支出都是一项长期投资，这会导致应用程序长期稳定和健壮。 因此，用于数据库测试的支出是必要的。 ## 最佳实践 * 包括元数据和功能数据在内的所有数据都需要根据需求规范文档的映射进行验证。 * 由/与开发团队协商创建的测试数据的验证需要进行验证。 * 通过使用手动和自动化程序来验证输出数据。 * 部署各种技术（例如因果图技术，等效划分技术和边界值分析技术）以生成所需的测试数据条件。 * 所需数据库表的参照完整性的验证规则也需要进行验证。 * 选择默认表值以验证数据库一致性是一个非常重要的概念，是否已为所有必需的登录事件成功将日志事件添加到数据库中 * 计划的作业是否及时执行？ * 及时备份数据库。 结帐-[数据库测试面试问题&答案](/database-testing-interview-questions.html) * [下一个](/software-testing.html)