[软件测试_2] 分析需求 | 测试用例 | BUG | 开发和测试模型-CSDN博客

本文链接：https://blog.csdn.net/2301_80171004/article/details/148117839

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

1、需求的概念

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

IEEE 定义：软件需求是：

（1）用户解决问题或达到目标所需条件或权能（Capability）。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

一种反映上面（1）或（ 2）所述条件或权能的文档说明。

它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。
在多数软件公司，会有两部分需求，一部分是用户需求，一部分是软件需求。

（1）用户需求

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

该需求一般比较简略，一般是一句话。
用户的需求是五花八门，往往只是⼀句话，比如：实现⼀个声控灯，实现⼀个软件的登录功能。

（2）软件需求

或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。软件需求是测试人员进行测试工作的基本依据。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求。

用户需求就是一句话，软件需求是一个文档（详细描述用户需求如何实现），日常工作中通常是用软件需求进行开发测试。

软件需求规格说明书
一、用户需求：
平台支持邮箱注册

二、软件需求：
1.1.1.1 注册账号
1.1.1.1.1 功能概述
用户可以通过填写邮箱信息在平台注册个人用户。
1.1.1.1.2 用户角色
匿名用户。
1.1.1.1.3 前置条件
无。
1.1.1.1.4 输入

| **序号** | **栏位名称** | **栏位说明** | **长度** | **类型** | **备注**
|
| ------ | -------- | ------------------- | ------- | ------ | ------ |
| 1 | 姓名 | 必填，录入个人姓名 | 6至15 | 字符型 |
|
| 2 | 电子邮箱 | 必填，录入电子邮箱 | | 字符型 |
|
| 3 | 密码 | 必输，输入的密码隐藏*号显示，最短6位 | 6至15 | 字符型 |
|
| 4 | 确认密码 | 必输，输入的密码隐藏*号显示，最短6位 | 6至15 | 字符型 | |
| 5 | 验证码 | 必填，录入验证码 | | 字符型 |
|
| 6 | 注册 | 注册操作 | | 操作型 |
|

1.1.1.1.5 处理
1.1.1.1.5.1 基本事件流
1、 用户选择注册；
2、 系统展现用户协议界面，并请用户确认是否同意用户协议
1) 若用户不同意协议，系统禁止用户注册。
2) 若用户同意协议，用户进行注册信息填写。
3、 用户填写注册信息。
注册个人，填写：姓名，电子邮箱，密码，确认密码，验证码。
4、 用户提交注册信息；
5、 系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收
到激活邮件，可使用注册的邮箱和密码登录系统后再次发送激活邮件。
6、 用户可执行激活操作，直接跳转至注册邮箱门户页面。
7、 用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。

1.1.1.1.5.2 扩展事件流
1. 用户注册并激活成功后，第一次登录平台时，提示用户完善信息；

1.1.1.1.5.3 异常事件流
1. 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
2. 每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。

1.1.1.1.6 输出
用户注册成功

1.1.1.1.7 后置条件
该模块为用户登陆等的前置模块。

注意：

用户的需求不能直接作为开发和测试的依据。针对用户的需求
产品经理需要进行需求分析（技术可行性、市场可行性、成本投入和收益占比等）后才可转变为软件需求。

为什么要有需求？

有需求才有目标，做事就需要有明确的需求。

2、从软件测试人员角度看需求

需求是测试人员开展软件测试工作的依据。

在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。

过程如下，业务需求—> 软件功能需求点 —> 测试需求点 —> 测试用例

以 “用户登陆” 为例，来阐述下整个过程：

3、为什么需求对软件测试人员如此重要

从软件功能需求出发，无遗漏的识别出测试需求是至关重要的
这将直接关系到用例的测试覆盖率。
对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。

4、如何才可以深入理解被测试软件的需求

测试工程师在需求分析和设计阶段就开始介入 ，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集。

二、测试用例（Case）的概念

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

1、举例

【测试用例：力扣刷题】

测试环境：leetcode 给我们提供的测试环境（Chrome 浏览器）
操作步骤：写代码，接着提交
测试数据：字节输入测试数据，80%
预期结果：通过率为 100%
序号：1、2、3... ...
标题：全部通过，此时展示一个动画效果

【测试用例：ecsp-439】

2、为什么要有测试用例

测试过程中可能会遇到以下问题：

不知道是否较全面的测试了所有功能，测试的覆盖率无法衡量，对新版本的重复测试很难实施，存在大量冗余测试影响测试效率。

测试用例的产生就是为了解决上述的问题。

测试用例可以提高测试人员的工作效率 / 降低测试人员工作的重复性问题。
测试用例是建立自动化的基础。（自动化就是把测试人员的双手解放，让代码代替人员执行测试）

三、软件错误（BUG）的概念

第一个 bug：

1945 年 9 月的某天，在一间老式建筑里，从窗外飞进来一只飞蛾，此时 Hopper 正埋头工作在一台名为 Mark Il 的计算机前，并没有注意到这只即将造就历史事件的飞蛾。
这台计算机使用了大量的继电器（电子机械装置，那时还没有使用晶体管）。
突然，Mark II 死机了。 Hopper 试了很多次还是不能启动，他开始用各种方法查找问题，最后定位到了某个电路板的继电器上。
Hopper 观察这个继电器，惊奇地发现一只飞蛾已经被继电器打死。Hopper 小心地用镊子将飞蛾夹出来，用透明胶布贴到 “ 事件记录本 ” 中，写上 “ 第一个发现虫子的实例 ” 。
Hopper 的事件记录本，连同那只飞蛾，现在都陈列在美国历史博物馆中。

软件错误的一般定义：程序与规格说明之前不匹配。

注意：

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

四、开发模型和测试模型

1、什么是模型

你以为的模型：

实际的模型：

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

2、软件的生命周期

认识具体的开发模型之前先了解软件的生命周期。

什么是生命周期？

生命周期指的是从生命的开始到生命结束的⼀段时间。

以人为例，人类的生命周期是从生命孕育的开始，中间会经历幼年，童年，少年，⻘年，⽼年，最终直至死亡。
而软件 / 产品的生命周期也是如此，需求的开始是软件生命的起点，中间会经历需求的计划、设计，程序开发，程序测试等阶段，直至软件不再进行维护便到了生命的重点。
软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。

假如我想要建造⼀套房子（假设⼀个人造房子），房子的生命周期（流程）是什么样的？

如果把软件看成是有生命的事物，那么 软件的生命周期 可以分成 6 个阶段：

需求分析 —— 计划 —— 设计 —— 编码 —— 测试 —— 运行维护

（1）需求分析

具体内容：分析需求是否合理，分别从市场需求、技术等方面进行分析。
产出：该阶段会输出需求等文档。

（2）计划

具体内容：对成立的需求执行需求执行计划，多长时间内完成该需求，每段时间具体完成哪些功能。
产出：该阶段会输出计划等文档。

（3）设计

具体内容：将需求细化成⼀个个任务，团队成员各司其职领取任务并进行技术设计（如何进行架构设计，设计哪些接口、采用什么技术）。
产出：该阶段会输出技术等文档。

（4）编码

具体内容：开发⼈员参考需求文档、设计文档、交互图等等文件进行代码的编写。
产出：代码文件等文档。

⭕（5）测试

具体内容：测试⼈员需要介入到软件的测试中来，参考测试用例对软件进行测试。
产出：测试用例、测试设计与计划、测试报告等文档。
按照标准流程来说，没有下面这个测试报告的话，该软件是不能上线的。

（6）运行维护

具体产出：项目测试结束之后，项目需要进行上线，并对产品进行线上的维护。线上的维护主要分为三个方面。分别为修复性维护、完善性维护和预防性维护。

修复性维护：对项目中未发现的问题进行修复。
完善性维护：对功能进行完善。
预防性维护：居安思危，为了避免产品在线上出现一些其他不可预料的问题，进行一些防护的手段。

如果出现线上问题，此时测试人员需要协助开发定位问题 + 解决问题。

3、测试模型 —— 瀑布模型（Waterfall Model）

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

需求分析：需求文档。
计划：什么时候开始，什么时候结束。
设计：技术文档（涉及哪些接口、库表、mq、定时任务... ...）、UI 视觉稿。
编码：写代码。
测试：执行测试用例、提交 Bug、验收。

（1）优点

强调开发的阶段性。
强调早期计划及需求调查。
强调产品测试。
每个阶段要做什么、产出什么，非常清晰。

特点：线性结构，每个阶段只执行一次。是其他模型的基础框架。

（2）缺点

测试后置

前面各阶段遗留的⻛险推迟到测试阶段才被发现，可能导致项目大面积返工的情况，失去了及早修复的机会。
必须留有足够的时间给测试活动，否则导致测试不充分，将缺陷直接暴露给用户（产品质量差）。

周期太长，产品很迟才能被看到和使用，可能会导致需求 / 功能过时。
依赖于早期进行的唯一一次需求调查，不能适应需求的变化。
由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程。
风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。

这会给项目带来很大的风险，尤其是集成的风险。

因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，业界流行的说法是：“集成之日就是爆炸之日 ” 。
尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。
但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点已关注的阶段之间掺入迭代的思想。
在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

（3）适用的项目

需求固定的小型项目适用于这种模型。

4、测试模型 —— 螺旋模型（Spiral Model）

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。

螺旋模型 是渐进式开发模型的代表之一。

（1）优点

强调严格的全过程风险管理。
强调各开发阶段的质量。
提供机会检讨项目是否有价值继续下去。
增加风险分析和原型。
每个阶段都会进行风险分析 + 原型，减少各阶段遗留的风险问题，避免一些线上问题发生。

（2）缺点

引入非常严格的风险识别、风险分析和风险控制，项目中可能存在的风险性与风险管理⼈员的技能水平有直接关系，这对风险管理的技能水平提出了很高的要求。
风险分析可能分析错误，而且额外招聘风险分析人员、资金、时间的增加和投入，可能会导致项目的成本太高。

（3）适用的项目

这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。

（相当于就是在线性模型中，加了一层风险把控）

5、开发模型 —— 增量模型、迭代模型

增量模型将一个大的需求修改成多个小功能，每个功能独立开发上线。
迭代模型会上线一个基础版本，基础版本所有的功能都有，只不过功能比较简陋，后期再继续迭代上线。

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。

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

与此类似的有⼀个迭代开发，增量开发和迭代开发往往容易被混为一谈，但是其实两者是有区别的。

增量是逐块建造的概念，迭代是反复求精的概念。

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

随着互联网的发展，现在已经很少的企业会独立使用以上两个模型，而是将两个模型配合着使用。

适用场景：大型项目，需求不明确。

6、开发模型 —— 敏捷模型

在早期，迭代瀑布模型非常流行来完成一个项目。

但是现在开发人员在使用它开发软件时面临着各种各样的问题。
主要困难包括在项目开发期间处理来自客户的变更请求以及合并这些变更所需的高成本和时间。
为了克服瀑布模型的这些缺点，在 1990 年代中期提出了敏捷软件开发模型。

敏捷模型主要旨在帮助项目快速适应变更请求。

因此，敏捷模型的主要目的是促进项目的快速完成。
要完成这项任务，需要敏捷。
敏捷性是通过使过程适应项目，删除对特定项目可能不是必需的活动来实现的。
此外，避免任何浪费时间和精力的事情。

在敏捷模型中，需求被分解成许多可以增量开发的小部分。

敏捷模型采用迭代开发。
每个增量部分都是在迭代中开发的。每次迭代都旨在小而易于管理，并且只能在几周内完成。
⼀次为客户计划、开发和部署一个迭代。没有制定长期计划。

敏捷模型中有⼀个非常重要的《敏捷宣言》，宣言内容：

个体与交互重于过程和工具。（强调高效的沟通）
可用的软件重于完备的文档。（强调轻文档，文档不应该作为工作验收的标准）
客户协作重于合同谈判。（主动及时了解当下的需求）
响应变化重于遵循计划。（能够主动迎接变化）

宣言中主要运用了对比的手法，然而，在每对比对中，后者并非全无价值，但我们更看重前者（强调的是前者，并没有否定后者价值）。

通过敏捷宣言可以总结出敏捷模型的四个特点：轻文档，轻流程，重目标，重产出。敏捷开发有很多种方式，其中 scrum 是⽐较流行的⼀种。

由敏捷宣言可以看出，敏捷其实是有关软件开发的社会工程（Social Engineering）的。
敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。

（1）scrum

敏捷开发有很多种方式，其中 Scrum 是比较流行的一种，Scrum 又称为迭代式增量软件开发模型。在 Scrum 模型中，主要有三个角色和五个重要会议。

a. 三个角色

Scrum 由 product owner（产品经理）、 scrum master（项目经理）和 team（研发团队）组成。

其中 product owner 负责整理 user story（用户故事），定义其商业价值，对其进行排序，制定发布计划，对产品负责。（收集需求）
scrum master 负责召开各种会议，协调项目，为研发团队服务。（产出软件需求文档）
研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。（由很多角色组成：开发人员（前端、后端），测试，交互，设计...）

b. 迭代开发

与瀑布不同， scrum 将产品的开发分解为若干个小 sprint（迭代），其周期从 1 周到 4 周不等，但不会超过 4 周。

参与的团队成员一般是 5 到 9 人。
每期迭代要完成的 user story 是固定的。每次迭代会产生一定的交付。

c. scrum的基本流程

scrum 的基本流程如上图所示：

产品负责人负责整理 user story（用户需求），形成左侧的 product backlog（需求列表）。
发布计划会议：product owner（产品经理）负责讲解 user story（用户需求），对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的 story 列表，sprint backlog（任务列表）。
迭代计划会议：项目团队对每一个 story 进行任务分解，分解的标准是完成该 story 的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
每日例会：每天 scrum master 召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由 po 整理，形成新的 story。
回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

当前主流DevOps实践其实继承了敏捷思想，通过CI/CD工具链将交付周期缩短到小时级别。结合Scrum框架实施，采用双周迭代+自动化测试+持续集成的基础配置。

（2）敏捷中的测试（轻文档和快速迭代）

测试工作的核心内客是没有变的，就是不断地找 Bug

只是要调整好自己的心态，一切以敏捷的原则为主。
敏捷模型中强调轻文档，所以测试人员不应使用传统的 Excel 编写测试用例的方法，不能依赖文档，测试用例作用减弱，更多的是使用思维导图、探索性测试（强调自由度，设计和执行同时进行，根据测试结果不断调整测试计划）、自动化测试等。
敏捷讲求合作，在敏捷项目组中，测试人员应多主动跟开发人员了解需求、讨论设计、一起研究 bug 出现的原因。

7、软件测试 —— V 模型

V 模型最早是由 Paul Rook 在 20 世纪 80 年代后期提出的，目的是改进软件开发的效率和效果。

是瀑布模型的变种。

特点：明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系，有效提升测试的质量和效率。
左边是开发，右边是测试，类似于瀑布模型。

V 模型指出：

单元和集成测试应检测程序的执行是否满足软件设计的要求；
系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
验收测试确定软件的实现是否满足用户需要或合同的要求。

优点：测试被划分成许多类型。
缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试。缺点同瀑布模型，测试人员介入太晚，发现问题的时机太晚。

开发 V 模型不仅仅指编码阶段，而是为产品开发流程而实施的各个阶段。

8、软件测试 —— W 模型（双 V 模型）

V 模型中未将测试前置的问题在 W 模型中得以解决。

W 模型增加了软件各开发阶段中应同步进行的验证和确认活动。
W 模型由两个 V 字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

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

优点：有利于测试人员尽早介入需求，全面的发现问题。
例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。
同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。
缺点：需求、设计、编码等活动被视为串行的；测试人员和开发人员在一定程度上还是串行（线性）的，不能拥抱变化，不能适用于敏捷，两个活动之间保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W 模型并不能解除测试管理面临着困惑。