软件测试词典

首页

A

验收测试 可访问性测试 主动测试 实际结果 临时测试 老化测试 敏捷测试 全对测试 Alpha 测试 API 测试 Arc 弧测试 异常测试 断言测试 审计测试 自动化软件测试

B

向后兼容性测试 基线工件 基础路径测试 基础测试集 调试 行为测试 基准测试 Beta 测试 大爆炸测试 二进制可移植性测试 黑盒测试 自下而上测试 边界测试 分支测试 广度测试 Bug测试 构建验证 业务流程 业务需求

C

能力成熟度模型 捕获/重放工具 因果图 代码覆盖率 代码冻结 代码检查 代码审查 代码演练 基于代码的测试 代码驱动测试 无代码测试 比较测试 兼容性测试 合规性测试 并发性测试 条件覆盖测试 配置测试 一致性测试 上下文驱动测试 控制流路径 转换测试 正确性 覆盖项目 循环复杂度

D

数据完整性测试 数据驱动测试 数据流测试 数据库测试 调试 决策覆盖测试 缺陷 缺陷记录和跟踪 缺陷生命周期 Delta 发布 依赖性测试 深度测试 破坏性测试 开发环境 文档测试 域测试 耐久性测试 动态测试

E

模拟器 端到端测试 耐久性测试 准入标准 等价分区测试 错误 错误猜测 错误植入 详尽测试 退出标准 预期结果 探索性测试

F

故障转移测试 失败 故障 故障注入测试 可行路径 功能测试 功能分解 功能要求 功能测试 模糊测试 前端测试

G

玻璃盒测试 全球化测试 Gorilla 测试 灰盒测试 GUI 测试

H

测试工具 启发式测试 混合集成测试

I

实施测试 增量测试 独立测试 不可行路径 检查 安装/卸载测试 集成测试 接口测试 国际化测试 系统间测试 互操作性测试 隔离测试 问题

K

关键字驱动测试 关键绩效指标 已知问题

L

LCSAJ 测试 负载生成器 负载测试 本地化测试 逻辑覆盖率测试 循环测试

M

可维护性 手动测试 大型机测试 基于模型的测试 修改条件测试 模块化驱动测试 猴子测试 突变测试

N

负面测试 非功能性测试 非破坏性测试

O

操作测试 正交阵列测试

P

配对测试 成对测试 并行测试 部分测试自动化 被动测试 路径测试 同行评审 渗透测试 性能测试 试点测试 可移植性测试 积极测试 后置条件 前提条件 预测结果 优先级 流程周期测试 渐进式测试 原型测试

Q

质量保证 质量控制 质量管理

R

随机测试 恢复测试 回归测试 候选版本 发布说明 可靠性测试 需求测试 基于需求的测试 需求可追溯性矩阵 结果 重新测试 Review 审查 风险测试 风险管理 根本原因

S

安全性测试 健全性测试 可扩展性测试 场景测试 时间表 Scrum 测试 脚本 安全测试 模拟 冒烟测试 浸泡测试 峰值测试 软件需求规范 稳定性测试 状态转换 静态测试 统计测试 存储测试 压力测试 结构测试 结构化演练 存根 符号执行 语法测试 系统集成测试 系统测试 被测系统

T

技术评审 测试方法 测试自动化 测试基础 测试平台 测试用例 测试用例设计技术 测试套件 测试完成标准 测试完成报告 测试完成矩阵 测试数据 测试数据管理 测试驱动开发 测试驱动程序 测试环境 测试执行 测试管理 测试成熟度模型 测试计划 测试步骤 测试策略 测试工具 线程测试 自上而下的集成测试 全面质量管理 可追溯性

U

单元测试 无法访问的代码 可用性测试 用例测试 用户验收测试 用户界面测试

V

V 模型 验证测试 验证测试 虚拟用户 容量测试 漏洞测试

W

Web 应用程序测试 白盒测试 工作流测试

有用的资源

有用的资源 讨论


软件测试 - 测试用例

软件测试是借助一系列工件进行的,即测试计划、策略、场景和测试用例。它不仅用于检测错误,还用于验证软件是否按预期运行。为此,遵循特定模板来验证每个功能。它被称为测试用例。

什么是测试用例?

测试用例是测试中遵循的标准格式,用于检查软件是否按要求运行。它包含一组需要验证的条件,以验证软件的实际结果是否与预期结果相匹配。

测试用例的各个部分列在下面 −

  • 功能名称 − 它指向已验证的功能。
  • 测试用例标识符 −它指向分配给每个测试用例的唯一 ID。
  • 测试人员姓名 − 将执行测试的测试人员的姓名。
  • 测试场景名称 − 将转换为测试用例的场景的名称。
  • 测试用例描述 − 将在测试用例中验证的需求或标准。
  • 测试步骤 − 要对软件执行的操作以验证测试条件。
  • 先决条件 − 开始测试步骤之前需要满足的先决条件。
  • 测试优先级 − 测试优先级分配给测试用例以决定需要执行的顺序。
  • 测试数据 −完成测试所需的输入和数据。
  • 预期结果 − 根据要求的预期结果。
  • 测试设置 − 运行测试前需要设置的设置和参数。
  • 实际结果 − 软件产生的实际结果。
  • 环境 − 执行测试的环境配置,包括操作系统、配置、安全性等。
  • 测试状态 − 测试状态应反映为通过、失败、未执行和阻止。
  • 注释 −针对每个测试用例添加的注释。

测试用例和测试场景之间的差异

测试用例和测试场景之间存在多个差异 −

Sr.No 测试用例 测试场景
1 它包含有关要测试的内容、需要执行的测试步骤、实际结果和预期结果等所有详细信息。 它是一份高级文档,涉及所有功能的所有功能和用户故事。
2 创建它是为了使测试人员和开发人员能够协同工作。 它指导测试团队执行任务。
3 它是根据测试场景文档创建的,并在回归或重新测试阶段再次使用。 它是根据需求直接创建的,但只要有任何需求发生变化或增加,就需要更新。

我们什么时候编写测试用例?

在软件开发开始之前,当需求准备好时,就会编写测试用例。测试人员在软件开发完成时完成测试用例的设计。

它也是在完成软件开发(生产部署之前)或根据需要实施新功能之后立即创建的。

测试用例创建是整个软件开发过程中的一个持续过程,一旦模块或模块的一部分准备就绪,就可以立即进行并行测试。

为什么要编写测试用例?

编写测试用例的原因如下 −

  • 检查软件是否按要求运行。
  • 检查软件是否在指定条件下运行。
  • 它有助于限制软件更新和其他需求。
  • 它确保涵盖并记录所有可能场景和用例的所有需求,从而提高测试覆盖率。
  • 它有助于实现测试执行的均匀性。精心设计的测试用例可让任何测试人员开始验证软件。
  • 好的测试用例需要最少的维护工作。

测试用例的基本格式是什么?

组件 目的
测试用例 ID 它指向分配给每个测试用例的唯一 ID。
测试用例描述 简要描述测试用例的设计原因。
先决条件 开始测试前需要满足的先决条件步骤。
测试步骤 详细描述测试步骤。
测试数据 完成测试所需的输入和数据。
预期结果 根据要求的预期结果。
后置条件 测试用例成功运行后需要满足的条件。
实际结果 软件上产生的实际结果。
测试状态 与实际和预期进行比较后的测试状态结果。
项目名称 项目名称。
模块名称 模块名称。
参考资料 参考资料所在的位置。
创建者 设计测试用例的测试人员姓名。
创建日期 创建测试用例的日期。
审核日期 审核测试用例的日期。
执行者 执行测试用例的测试人员姓名。
执行日期 测试用例的日期执行。
注释 针对测试用例添加的注释。

下图显示了测试用例格式。

软件测试测试用例

设计测试用例的最佳实践

设计测试用例的最佳实践如下 −

  • 它不应该复杂、清晰且易于理解。
  • 每个测试用例都应该是不同的。
  • 只有在清楚了解需求、输入、数据并且没有任何假设的情况下才能设计它。
  • 每个测试用例都应该映射到至少一个可追溯性的要求。
  • 每个测试用例都应使用所有可能的输入、条件和数据进行验证。
  • 测试用例描述、名称等应该是不言自明的,但可以用几句话来解释。
  • 每个测试用例都应涵盖客户要求。
  • 测试用例的设计不应产生相同的结果。
  • 设计时应考虑最终用户的要求和观点。
  • 每个测试用例都应具有唯一的 ID。
  • 应具有明确定义的先决条件和后置条件。
  • 应以可在其他地方重复使用的方式编写。
  • 应纳入测试用例的精确预期结果。

测试管理工具

不同的测试管理工具列于下方 −

  • TestRail −它是一个测试管理工具。
  • Jira − 它是一个项目管理工具。
  • ALM/HP QC − 它是一个项目管理工具。

正式和非正式测试用例

  • 正式测试用例 − 它遵循上面讨论的测试用例模板或格式。
  • 非正式测试用例 − 它不遵循任何测试用例模板或格式。

不同类型的测试用例

不同类型的测试用例如下所示 −

  • 功能测试用例 − 它们用于验证软件的功能是否按预期运行。
  • 单元测试用例 − 它们由开发人员编写,用于验证他们开发的软件单元是否正常运行。
  • GUI 测试用例 −它们用于验证软件的图形用户界面。
  • 集成测试用例 − 它们用于验证软件的不同组件在与其他组件集成后是否正常工作。
  • 性能测试用例 − 它们用于验证软件的响应时间和整体性能。
  • 数据库测试用例 − 它们用于验证后端以及所有数据是否反映在数据库中的正确表中。
  • 安全测试用例 − 它们用于验证软件的安全功能。
  • 可用性测试用例 − 它们用于验证软件是否可用且用户友好。
  • 用户验收测试 −它们是为了验证软件在现实场景和环境中是否正常工作而编写的。

测试用例的实际示例

以下是功能测试用例的示例,旨在验证是否只有在用户拥有最低账户余额时才能处理付款。

模块名称 Payment
测试用例 ID 10
创建者 Ram
测试用例描述 验证付款功能
前提条件 1. 用户应该能够登录。
2. 用户的帐户中应该有一些余额。
环境 Windows,最新的 Chrome 浏览器 UAT 环境
场景名称 验证是否仅在用户拥有最低帐户余额时才能处理付款。
测试用例 ID 测试步骤 测试数据 预期结果 实际结果 状态 评论
10 启动浏览器 用户凭据 应启动浏览器 已启动浏览器 通过 N/A
打开 URL 应打开应用程序 URL 应用程序 URL 是打开
单击"余额"选项卡 应打开"余额"页面,并且用户应有一些余额。 已打开"余额"页面,并且用户有一些余额
单击"付款"选项卡 应打开"付款"页面,并且用户应使用余额成功处理付款。 已打开"付款"页面,并且用户使用余额成功处理付款。
单击注销 应注销应用程序。 应用程序已注销

在上面的例子中,用户首先启动浏览器并在那里打开一个应用程序。然后检查用户帐户余额,然后使用该余额付款。

结论

至此,我们对软件测试用例教程的全面介绍就结束了。我们首先描述了什么是测试用例,测试用例的基本特征是什么,什么时候编写测试用例,为什么要编写测试用例,测试用例和测试场景有什么区别,有哪些不同的测试管理工具,什么是正式和非正式的测试用例,有哪些不同类型的测试用例,以及测试用例的实际示例。

这将使您对软件测试测试用例有深入的了解。明智的做法是继续实践您所学到的知识,并探索与软件测试相关的其他知识,以加深您的理解并拓展您的视野。