测试及其相关概念

---

一、什么是测试？

软件测试就是验证产品的特性（功能、性能、界面等等）是否满足用户的需求。也就是说软件测试就是执行和运行软件的过程，其目的是为了发现软件功能和需求不相符合的地方，或者寻找实际输出和预期输出之间的差异。

其实生活中处处都藏着测试的例子，接下来小编通过这个买水杯这个例子对测试的概念进行讲解

也就是说，杯子已经生产出来了对应的就是一个项目已经完成了，程序编码生成了一个产品，测试的任务就是对那个产品进行一些使用测试，测试产品的特性是否符合用户的需求。

---

二、测试岗位的分类

测试工程师与开发工程师的区别

岗位	工作重点	特点
软件测试工程师	业务测试，开发测试效率工具（自动化、性能测试等等）	测试广度大，专业度小。
软件开发工程师	业务代码开发	开发广度小，专业度高。

所谓的广度就是所学的范围包含广，专业度就是学习的内容的精通程度。

软件测试工程师和测试工程师的区别：

• 相同点：

• 1、 都称为测试人员

• 2、对产品质量负责，保证产品的质量

• 3、两个工作重点都是业务测试

• 不同点：

• 测试开发需要额外进行开发效率工具，通过效率工具来提升测试效率和测试的质量，比如自动化测试、性能测试就是属于效率工具。

走测试岗位为什么还需要学习开发知识
1、测试人员是对开发人员写的代码进行测试，需要了解看懂代码及其框架，才能进行自动化测试，性能测试、以及开发效率工具等。
2、学好开发知识能够更深层次的了解代码。提高软件测试的质量，通过代码中数据的走向，能够更好的从代码方面去发现问题。

二、优秀测试人员需要具备的素质

1. 良好的沟通能力
2. 快速的学习能力
3. 具备良好的开发能力：测试人员不仅要对软件进行测试，还要针对当前业务开发效率工具提高测试的质量与效率。
4. 文字能力：测试人员需要编写各种测试文档：测试计划、测试用例、测试报告等
5. 掌握自动化测试技术。
6. 具备探索性思维
7. 对测试感兴趣
8. 具备责任感和能够承受压力的能力

测试与开发产生争执该怎么办？

• 先检查自身，是否bug描述的不清楚。
• 站在用户角度考虑并抛出问题。
• BUG定级要有理有据
• 提⾼自身技术和业务水平，做到不仅能提出问题，最好也能给出解决⽅案
• bug评审

---

三、需求篇

3.1 需求的概念

分类：用户需求和软件需求

用户需求：也就是使用者或者甲方的要求。通常就是一句话。比如给我做一个水杯，给我画一幅画等等。

软件需求：该需求会详细描述开发⼈员必须实现的软件功能。软件需求可以作为开发和测试的依据

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

3.2 开发模型

软件的生命周期其实就是软件的开发模型。
在软件测试领域，‌开发模型（Development Model）‌ 指软件开发过程中采用的‌方法论框架‌，定义了需求分析、设计、编码、测试等阶段的组织方式和协作流程。不同的开发模型直接影响测试介入时机、测试策略和质量管理模式。

3.2.1 瀑布模型

瀑布模型主要结构为：

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

1. 首先拿到用户的需求，得对需求进行分析，检验需求的合理性。

假设拿到用户的需求建设一套房子，那么就得对用户的需求进行分析，建设多少层，建设什么样的风格的等等。总不能用户给我一百块，让我去建筑一套别墅吧。那么进行项目前拿到用户需求进行需求分析，如果可行，则可以将他转换成软件需求文档记录具体需要怎么样子的房子。

2. 然后根据需求进行计划安排，生成一系列计划书，一个整体的框架。

什么时候开始建房子，耗时多久，什么时候结束。

3. 根据概要设计，对框架进一步完善，在计划的时间内，什么人做什么事情，需要多少人，需要做什么事情等等。这就是设计阶段，明确每个时间段什么人需要干什么事情，怎么去干，什么时候完成。

根据交房的时间，第一阶段需要做什么，第二阶段需要做什么…最后交房

4. 后面根据设计需求一步步执行。对应的则是编码阶段

开始建造房子

5. 测试阶段：对于程序中进行测试，找到软件功能和需求不同的地方。

对应房子交付，开发商对于建造好的房子进行测试

6. 运行与维护

交付给住户，住户在住房子的过程中出现一些房屋问题还得去找开发商进行维护。

特点：
每个流程只执行一次，线性的开发流程。

缺点：
1、运行的产品很迟才能被看到。
2、测试后置：因为瀑布结构是线性的开发流程，一步完成才进行下一步。假设到产品开发已经来到了测试的部分，测试的过程中发现某个功能模块不符合预期要求，那么就得从需求分析进行更改重头再来一遍（也就是所谓的全盘返工）。所以一般瀑布模型只适合一些需求固定的小项目。

3.2.2 螺旋模型

与瀑布模型相比，螺旋模型中各个阶段都引入了风险分析和原型（第一象限内）。能够更好的把控风险，避免从头再来的局面。原型就是每个阶段需求在开发完成之后的模型，然后参考原型来分析考核一下是否是符合预期标准的，符合预期然后进行下一步。

适用场景
需求复杂、规模大、风险大的项目。

3.2.3 增量模型

将一个大需求拆分成许多个小需求，对每一个小需求分别进行独立的开发上线。

例如：
购物软件：先上线商品部分，没有购买部分，后面再接着上线购买部分，再增加搜索部分，再增加一些其他部分例如评价等部分

3.2.4 迭代模型

迭代模型会上线一个基础版本，基础版本所有的功能都有只不过功能比较简陋，后期会继续迭代优化上线。

例如
购物软件：先整体上一个购物的框架，什么功能都有，但是只是一些基础的操作没有系统完好的功能，后面再对前面部分进行完善。每次完善都是一次迭代版本。在原有的框架上再进行优化、细致。

3.2.5 敏捷模型

在项⽬开发期间会存在来自客户的变更请求以及合并这些变更，但是所需的成本高和时间大，于是就有了敏捷模型。敏捷模型旨在帮助项目快速适应变更请求。而所谓的敏捷模型就是由迭代模型和增量模型共同完成的。

在敏捷模型中，用户的需求被分解成一个个功能，这就是增量模型。然后根据每个小型的功能进行开发迭代。所以敏捷模型又叫增量迭代模型。

在这里根据每个需求完成开发生成一个版本，如果后续还有什么模块需要更新，找到对应的需求中对应的版本进行，其他的保持不变即可。这样就避免了全盘重写。

Scrum模型
Scrum模型属于使用广泛的敏捷模型，它主要包含三个角色和五大会议：
三个角色：产品经理、项目经理、研发团队。
五大会议：需求发布会议、计划发布会议、每日会议（昨天做了什么，今天做什么，遇到什么问题【进度、目标、风险把控】）演示会议（主要由测试人员进行演绎）、回顾会议

---

四、测试模型

4.1 V模型

V模型因图形结构形似字母“V”得名，将软件开发与测试活动分为左右两翼，左侧为需求分析、设计及编码，右侧为逐层对应的测试阶段（如单元测试、系统测试等）‌。

V模型中明确的标注了测试过程中存在不同类型的测试。

1. 单元测试：单个函数/方法或者代码模块的测试。主要由开发人员进行测试。需要参考详细设计。
2. 集成测试：多个模块组合后的接口交互功能测试，检测程序的执行是否满足软件设计的要求。主要由开发人员和测试人员共同完成。需要参考概要设计。
3. 系统测试：检测系统功能、性能的质量特性是否达到系统要求的指标。需要参考需求分析，保证功能是否符合用户需求。
4. 验收测试：验证产品特性是否符合用户需求。需要参考用户需求。

缺点

• 测试滞后于开发，需求阶段的错误可能在后期才暴露‌。
• 难以适应需求频繁变更的场景‌。
• 质量依赖开发阶段的输出准确性，缺乏并行验证机制‌

4.2 W模型

特点

• 测试和开发并行：每个开发阶段均同步执行对应的测试活动。

例如：需求分析完成后，测试人员立即验证需求文档的完整性与可实现性，而非等待编码完成后介入‌。

• 标准化流程‌

明确每个阶段的输入输出标准，例如需求文档需通过评审才能进入设计阶段，确保流程可追溯‌

缺点

• 不适合敏捷开发模式。开发与测试仍被视为线性流程，难以适应敏捷开发中频繁迭代的场景‌。
• 对人员的要求高：需测试团队深度参与各阶段评审，对人员综合能力（如需求理解、设计审查）要求较高‌。