---

衡量软件测试结果的依据—需求

---

1. 需求

1.1 什么是需求

需求：我想要做什么事情

用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。

软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

1.2 为什么要有需求

需求是开发人员的一个标准
需求是测试人员编写测试用例的一个依据

1.3 测试人员眼中的需求

1.4 如何深入理解需求

需求评审会议：产品经理会给大家交代清楚软件诞生的背景，软件需求是什么，预期收益，未来软件发展的规划

技术评审会议：研发主要讲需求（围绕着技术来展开）

积极参加各种会议
仔细阅读相关文档（需求文档，技术文档，看 BUG 库）

深入理解需求，目的是为了写出比较完善的测试用例

2. 测试用例的概念

2.1 什么是测试用例

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
测试用例解决了两大问题：测什么，怎么测

2.2 为什么要有测试用例

测试用例是测试人员执行测试的依据
测试用例可以降低测试工作的冗余度
测试用例也是执行自动化的依据

3. 软件错误（BUG）的概念

准确的来说：当且仅当规格说明（软件需求）是存在的并且正确，程序与规格说明之间的
不匹配才是错误。
当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误

4. 开发模型和测试模型

随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。
软件工作的范围不仅仅局限在程序编写，而是扩展到了整个软件生命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件被更新和替换新的版本。
软件工程还包括很多技术性的管理工作，例如过程管理、产品管理、资源管理和质量管理，在这些方面也逐步地建立起了标准或规范

4.1 软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。
如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护

---

• 需求分析：需求要干什么，需求是不是正确的，产品经理产出需求文档
• 计划：开发开始时间，开发结束时间，测试开始时间，测试结束时间，谁开发，谁测试
• 设计：1. UI/UE 设计师将需求转换成图，UI视觉稿；2. 技术人员产出技术设计文稿
• 编码：写代码，实现软件
• 测试：执行测试用例，验收BUG，产出测试报告
• 运行维护：上线，如果上线后，项目有 BUG，需要解决 BUG，重新上线

4.2 瀑布模型（Waterfall Model）

1. 特点：
   线性的
2. 优点：
   在每个阶段应该干什么非常的明确
3. 缺点：
   发现问题的时机太晚，太晚就会导致有些人力，时间资源产生浪费
4. 适用于什么样的项目：
   适用于比较小的项目，风险较低的项目

4.3 螺旋模型（Spiral Model）

1. 特点：
   软件每进入到下一个阶段的时候，都会进行风险分析
2. 优点：
   风险分析可以避免一些问题出现在线上
3. 缺点：
   如果风险分析错误，就会将问题暴露到线上
   风险分析需要具备一定的知识
4. 使用项目：
   适用于大型项目，项目周期持续时间较长
   适用于风险较多的项目

4.4 增量、迭代

增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。
因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作

迭代：先大概开发每个模块，再进行细节上的雕琢
增量：先开发其中一个模块，再开发后面的模块，直到开发完毕

增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……
而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

4.5 敏捷

4.5.1 敏捷宣言（敏捷思想）

个体与交互 重于 过程和工具

过程：测试过程中有一些流程
工具：用什么软件辅助工作

可用的软件 重于 完备的文档

公司中有许多文档（技术文档，测试用例，测试方案…）

客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者

4.5.2 scrum

scrum 重要的角色：
product owner(产品经理)、scrum master(项目经理) 和 team(研发团队) 组成
team 中包含：前端开发，后端开发，测试，设计

• product owner 负责整理 user story（用户故事，需求），定义其商业价值，对其进行排序，制定发布计划，对产品负责
  这里需求非常多，PO 需要把这些需求进行优先级排序，哪个先实现，哪个后实现
• scrum master 负责召开各种会议，协调项目，为研发团队服务
• 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品

scrum 流程是什么？

产品负责人 负责整理user story，形成左侧的 product backlog。

发布计划会议：product owner 负责讲解 user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。

迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。

每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。

演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。

回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果

4.6 软件测试V模型

用户需求：产品经理将用户需求进行收集，形成软件规格说明书

需求分析与系统设计：分析需求能不能做，需求对不对

概要设计：大概设计一下

详细设计：每个模块如何实现

编码：开发

单元测试：每个 class 方法，方法

集成测试：方法和方法之间的调用

系统测试：将项目全部运行起来，黑盒测试，功能测试

验收测试：产品经理、运营验收

---

特点：左边是开发，右边是测试
测试被划分成许多类型

缺点：测试介入太晚

4.7 软件测试W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。

W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的

W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。

局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，
上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑

W模型，不能拥抱变化，也为之不适用于敏捷