软件开发之评审
本文最后更新于 145 天前,其中的信息可能已经有所发展或是发生改变。

🧩 一、认识需求:什么是需求分析?

1. 定义

  • 准确定义系统“做什么
  • 描述软件的功能、性能、限制、接口等
  • 定义软件的有效性需求

2. 为什么重要?

  • 50%–65% 的缺陷在需求阶段引入
  • 其中一半因需求文档不明确导致,另一半因需求遗漏
  • 越早发现错误,修复成本越低

📄 二、需求来源与分析过程

1. 需求来源

  • 用户需求调研
  • 需求规格说明书
  • 以往系统应用经验

2. 需求分析过程

  1. 收集用户需求
  2. 编写需求定义文档
  3. 编写软件功能说明
  4. 编写需求跟踪矩阵
  5. 审核软件需求文档

3. 测试人员在需求阶段的工作

  • 理解需求,参与评审
  • 了解项目目标、限制、用户背景
  • 编写测试计划,准备资源

📑 三、需求规格说明书

1. 定义(IEEE)

  • 用户解决问题所需的条件或能力
  • 系统为满足合同、标准等所需的条件
  • 反映上述条件的文档说明

2. 作用

  • 便于用户与开发方理解与交流
  • 作为开发与测试的基础和依据
  • 作为验收测试的基准

3. 组成要素

要素 内容
产品概述及目标 目的、背景、术语、目标用户
产品描述 功能/非功能需求概述、整体流程图
功能需求 逐项详细说明功能、界面、操作等
非功能需求 性能、安全、兼容性、易用性等

4. 好的需求规格说明书应具备:

  • 格式清晰、内容正确完整
  • 可行、必要、优先级明确
  • 明确无歧义、可测试、可追踪
  • 及时更新

🔍 四、需求评审(测试)

1. 评审方法

方法 特点
复查 合作者检查,最不正式
走查 较宽松,需准备数据
审查 正式会议,记录缺陷,最有效

2. 评审内容(检查列表)

  • 是否符合格式要求?
  • 需求是否正确、完备、兼容?
  • 是否可实现、合理、可测试?
  • 是否描述了“真正的”需求?

3. 需求测试的其他方式

  • 通过编写测试用例反推需求完整性
  • 用户调查
  • 利用现有产品对比验证

🧪 五、测试需求分析

1. 什么是测试需求?

  • 识别哪些内容需要测试
  • 将用户需求转化为可测试的明确需求
  • 包括测试周期、人员、环境、技能等

2. 测试需求说明书的依据

  • 需求规格说明书
  • 软件研制任务书
  • 行业标准

3. 测试需求说明书内容

  • 目的和范围
  • 系统说明
  • 功能性与非功能性测试需求
  • 环境需求(硬件/软件)
  • 完成标准

4. 测试需求的要点

  • 正确性、必要性、优先级
  • 明确性、可测性、完整性
  • 一致性、可修改性

🔁 六、需求跟踪矩阵

  • 确保每项需求都有对应的:
    • 设计
    • 代码
    • 单元测试 & 集成测试
  • 实现需求→设计→代码→测试的双向可追溯性

🛠️ 七、测试需求分析的流程与方法

1. 测试需求分析步骤

  1. 获取最新需求文档
  2. 阅读并理解所有需求项
  3. 对照检查列表测试并记录
  4. 讨论、修订、迭代直至通过

2. 案例分析方法

  • 理解测试对象:界面、功能、操作、数据、输出
  • 途径:需求文档、用户调查、与设计人员沟通


✅ 总结要点

  • 需求是项目的起点,需求错误是最高成本的错误
  • 需求规格说明书是开发与测试的共同基准
  • 测试应尽早介入需求评审,识别模糊、不可测、遗漏的需求
  • 使用需求跟踪矩阵确保需求被完整实现与测试
  • 测试需求说明书是测试计划的依据,决定测试范围和深度
感谢大家参观我的毛坯房。
暂无评论

发送评�? 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇