软件测试词典

首页

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 应用程序测试 白盒测试 工作流测试

有用的资源

有用的资源 讨论


软件测试 - 业务需求

软件是根据其功能和业务需求开发的。业务需求是指从软件开发生命周期 (SDLC) 开始收集和描述用户(即供应商、客户和员工)的业务需求的过程。它们是软件未来开发的指南,主要由组织的业务分析师制定。

什么是业务需求?

业务需求是软件应能够执行的基本要求和假设,以实现组织的战略目标。它们还描述了业务目标、业务应如何运行以及软件将如何帮助业务运作并实现其目标。它们在 SDLC 的初始阶段定义,并指导构建软件架构和设计的过程。

软件业务需求包括什么?

软件业务需求包括以下列出的项目 −

  • 软件业务需求包括业务环境、范围、背景、组织目标、行业模式等。
  • 软件业务需求列出了项目中的业务利益相关者,即监管机构、客户、高管、业务分析师等。
  • 软件业务需求包括定义项目是否成功的标准。这些标准是根据组织目标决定的,包括提高生产力和成本、增强最终用户体验以及遵守标准和法规的措施。
  • 软件业务需求包括在软件开发时应考虑的各种约束和限制。
  • 软件业务需求包括概念数据模型,例如数据实体、关系、属性。它还描述了软件中要使用的各种数据集的数据字典。

软件业务需求的优势

软件业务需求的优势如下 −

  • 软件业务需求给出了准确的目标,并协调了组织希望通过开发软件实现的目标。这主要有助于让所有利益相关者达成共识。
  • 软件业务需求改善了业务利益相关者和项目内技术团队之间的沟通方式。
  • 软件业务需求有助于制定项目计划、预算、时间表等,这些都是成功项目管理的关键要素。
  • 通过从 SDLC 的各个阶段识别业务需求,软件中的大部分潜在风险都得到了缓解。
  • 业务需求有助于提高客户满意度和使用软件时的体验。
  • 业务需求有助于有效利用资源、时间、精力和成本,方法是有效地将它们分配给软件的关键特性和功能。

谁定义软件业务需求?

软件业务需求由下面列出的人员定义 −

  • 业务分析师
  • 产品所有者
  • 项目经理
  • 利益相关者
  • 客户
  • 赞助商
  • 主题专家

软件业务需求的格式

软件业务需求的格式如下所述 −

标题页 − 它由项目名称、文档标题、作者和日期组成。

目录 − 它描述了不同的部分及其页码。

摘要 − 它描述了项目及其目标以及业务需求的范围。

目标 − 它详细描述了项目的业务目标和目的。

范围 − 它叙述了项目范围内和范围外的特性和功能。

利益相关者 − 它列出了所有利益相关者的姓名以及他们的角色和职责。

业务需求 −它包括功能性(软件的特性和功能)和非功能性需求(软件的性能、可靠性、可用性、安全性等)。它们应该具有需求 ID、描述、优先级、依赖关系、验收标准等。

监管和合规性要求 − 它包括软件应遵循的法律、监管和合规性。

用例 − 它们描述了用户应如何与软件交互以实现特定目标。每个用例都应该有一个用例 ID、描述、参与者、先决条件、后置条件、步骤等。

假设和约束 − 它们描述了项目中可能出现的各种假设和约束,即成本、技术、时间表。

验收标准 −它描述了为了满足需求而应满足的标准。

可追溯性矩阵 − 它由一个表格组成,该表格将每个需求映射到其测试用例、设计因素和项目目标。

批准和签字 − 它由项目利益相关者和赞助商的签名组成。

附录 − 它包括已引用的重要术语、文档、支持项目等的词汇表。它主要是为了使业务需求更加紧凑、准确、详尽等。

软件业务需求中的原型设计

软件业务需求中的原型设计出于以下原因 −

  • 原型设计有助于通过可视化来解决需求中的疑问。其主要目的是收集利益相关者的反馈,以便业务需求清晰,并符合组织的业务目标。
  • 原型设计有助于改善技术团队和业务利益相关者之间的沟通,使他们都对需求有相同的理解。它提供了一个交流想法和观点以改进需求的平台。
  • 原型设计通过在受控环境中验证需求来验证需求。因此,它可以在开发过程开始时识别任何需求中的缺陷。
  • 原型设计有助于确定需求的范围。因此,特性和功能会根据其关键性进行优先排序。
  • 原型设计是一种节省成本和时间的活动,因为它可以在早期而不是在开发的后期确定差距。经过原型设计阶段的需求使开发过程更加系统化和高效。
  • 原型设计从 SDLC 的早期阶段验证软件,因此,软件变得更加可用。在原型设计阶段收集的反馈使其更接近最终用户的期望。

软件业务需求的挑战

软件业务需求的挑战如下所列 −

  • 软件业务需求有时含糊不清、不完整、不清楚且记录不全,这会导致误解和项目混乱。
  • 业务需求的修改和添加可能会导致交付延迟,从而影响项目成本。需求的优先级也可能会在中途发生变化。
  • 利益相关者的缺席可能会延长需求收集阶段。
  • 软件业务需求复杂且相互关联,难以描述和记录。此外,业务需求应符合法规和标准。
  • 不同的利益相关者可能对首先解决哪些需求有不同的看法。资源的不可用性也会影响需求的选择。
  • 如果要将新需求与遗留软件合并,业务需求有时会面临技术挑战。此外,由于技术限制,某些要求无法满足。
  • 软件业务需求的文档可能非常差。
  • 业务需求可能会受到项目利益相关者的错误假设的影响。跨越国界的全球项目可能会受到文化差异的影响,从而导致混乱。
  • 验证和确认最终软件是否按照项目的业务需求构建并不容易。

结论

这就是我们对软件业务需求教程的全面介绍。我们首先描述了软件业务需求是什么,软件业务需求包括什么,软件业务需求的优势是什么,谁定义软件业务需求,软件业务需求的格式,软件业务需求中的原型是什么,软件业务需求的挑战是什么。这使您具备了对软件业务需求的深入了解。明智的做法是继续实践你所学到的知识,并探索与软件测试相关的其他知识,以加深你的理解并拓宽你的视野。