测试概念篇

文章目录

• 目录
• • [1. 什么是测试](#1. 什么是测试)
  • • [1.1 生活中的测试场景](#1.1 生活中的测试场景)
    • [1.2 为什么需要软件测试](#1.2 为什么需要软件测试)
    • [1.3 软件测试定义](#1.3 软件测试定义)
  • [2. 测试的岗位有哪些](#2. 测试的岗位有哪些)
  • [3. 软件测试和开发的区别](#3. 软件测试和开发的区别)
  • • [3.1 工作内容](#3.1 工作内容)
    • [3.2 难易程度上](#3.2 难易程度上)
    • [3.3 其他不同](#3.3 其他不同)
  • [4. 需求的概念](#4. 需求的概念)
  • • [4.1 用户需求](#4.1 用户需求)
    • [4.2 软件需求](#4.2 软件需求)
  • [5. 开发模型](#5. 开发模型)
  • • [5.1 软件的生命周期](#5.1 软件的生命周期)
    • [5.2 常见开发模型](#5.2 常见开发模型)
    • • [5.2.1 瀑布模型](#5.2.1 瀑布模型)
      • [5.2.2 螺旋模型](#5.2.2 螺旋模型)
      • [5.2.3 增量模型、迭代模型](#5.2.3 增量模型、迭代模型)
      • [5.2.4 敏捷模型](#5.2.4 敏捷模型)
  • [6. 测试模型](#6. 测试模型)
  • • [6.1 V模型](#6.1 V模型)
    • [6.2 W模型(双V模型）](#6.2 W模型(双V模型）)

目录

• 什么是测试
• 测试的岗位有哪些
• 软件测试和开发的区别
• 需求的概念
• 开发模型
• 测试模型

1. 什么是测试

测试在生活中处处可见。

1.1 生活中的测试场景

举一个日常生活案例，商场买衣服，买衣服的整个过程中都伴随着测试行为：

• 外观测试：初筛选，走进门店，先挑衣服，测试是否存在符合个人审美的衣服
• 试穿测试：选择尺码，测试试穿之后衣服对个人的外观是否有提升
• 面料测试：纯棉、涤纶、布料...
• 价格测试：询价，心理预期是300以下
• 购买衣服，交易完成

1.2 为什么需要软件测试

企业最终的目的是"盈利"，互联网企业借助软件/系统来跟用户交互从而获得盈利，也就是说企业的受众群体主要是广大的使用用户，而用户的使用感受将直接影响企业的盈利，若产品质量太差将导致大量用户的流失，所以企业非常重视测试。

1.3 软件测试定义

软件测试就是验证软件产品特性是否满足用户的需求

2. 测试的岗位有哪些

测试的岗位主要分为以下两个方面：

1. 软件测试开发工程师

工作重心为可测试性以及通用测试基础框架；编写单元测试框架和自动化测试框架。软件测试开发工程师关注质量提升和测试覆盖率。

2. 测试工程师

与软件测试开发工程师关系密切，但把用户放在第一位来思考。测试工程师组织整体测试实践，并进行分析总结，驱动测试执行，构建端到端的自动化测试。

3. 软件测试和开发的区别

3.1 工作内容

开发人员：

1. 通过一些编程语言，如C，C++，C#，Java，Python，PHP实现软件的特性
2. 修改BUG

测试人员：

1. 编写测试用例，执行测试用例，发现软件的缺陷，验收缺陷...
2. 利用测试工具保障软件的质量

3.2 难易程度上

开发：

1. 应届生要求掌握语言基础、开发框架、数据库、数据结构、Linux等课程
2. 在职人员还需掌握更多中间件如：Redis、rabbitMQ、ES等

测试：

1. 应届生要求掌握语言基础、开发框架、数据库、数据结构、Linux等课程
2. 掌握测试技能：测试概念、设计测试用例、执行测试等
3. 在职人员还需掌握更多中间件如：Redis、rabbitMQ、ES等

总结： 开发广度小，专业度高；测试广度大，专业度相对较低，大型互联网企业对测试人员的专业要求可能跟开发差不多。

3.3 其他不同

测试人员经常会进行测试动作，而开发人员进行调试动作，调试和测试是同一个含义吗？

4. 需求的概念

在多数软件公司，会有两部分需求，一部分是用户需求，一部分是软件需求。

4.1 用户需求

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

4.2 软件需求

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

在工作中我们实际见到的软件需求文档类似于下面的表述：

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

5. 开发模型

5.1 软件的生命周期

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

生命周期指的是从生命的开始到生命结束的一段时间。以人为例，人类的生命周期是从生命孕育的开始，中间会经历幼年，童年，少年，青年，老年，最终直至死亡。

而软件/产品的生命周期也是如此，需求的开始是软件生命的起点，中间会经历需求的计划、设计，程序开发，程序测试等阶段，直至软件不再进行维护便到了生命的终点。

案例：假如我想要建造一套房子，房子的生命周期（流程）是什么样的？

因此，我们就得到了软件（开发）的生命周期：

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

对于软件的生命周期中，每个阶段都在做什么呢？

5.2 常见开发模型

5.2.1 瀑布模型

瀑布模型优缺点总结：

瀑布模型的适用场景：需求固定的小项目

5.2.2 螺旋模型

螺旋模型优缺点总结：

适用场景：规模庞大、复杂度高、风险大的项目

5.2.3 增量模型、迭代模型

与此类似的有一个迭代开发，增量开发和迭代开发往往容易被人认为是相同的，但是其实两者是有区别的。增量是逐块建造的概念，迭代是反复求精的概念。

例如画一幅人物画：

增量模型是先画人的头部，再画身体，再画手脚......

迭代模型是先画整体轮廓，再勾勒出基本雏形，再细化、着色......

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

5.2.4 敏捷模型

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

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

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

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

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划

宣言中主要运用了对比的手法，然而，在每对比对中，后者并非全无价值，但我们更看重前者。

通过敏捷宣言可以总结出敏捷模型的四个特点：轻文档，轻流程，重目标，重产出。

敏捷开发有很多种方式，其中 Scrum 是比较流行的一种。

Scrum 是敏捷模型中的一种，又称为迭代式增量软件开发模型。

在 Scrum 模型中，主要有三个角色和五个重要会议。

三个角色：

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

• 其中 product owner 负责整理 user story(用户需求)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
• scrum master 负责召开各种会议，协调项目，为研发团队服务。
• 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

迭代开发：

与瀑布不同，Scrum 将产品的开发分解为若干个小 sprint(迭代)，其周期从1周到4周不等，但不会超过4周，参与的团队成员一般是5到9人。每期迭代要完成的 user story 是固定的，每次迭代会产生一定的交付。

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

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

敏捷中的测试：

• 轻文档和快速迭代

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

6. 测试模型

测试模型中有两个非常重要且具有标志性的测试模型：V模型和W模型

6.1 V模型

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

优点：

• 明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系，有效提升测试的质量和效率。
• V模型指出：

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

缺点：

• 仅仅把测试作为在编码之后的一个阶段，未在需求阶段就介入测试，缺点同瀑布模型。

6.2 W模型(双V模型）

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

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

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

优点：

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

缺点：

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