软件测试基本概念

什么是软件测试

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

早期，人们更多的将测试看成是对软件产品“检验”，检查软件的每个功能是否运行正常

1983年，Bill Hetzel将软件测试定义为：软件测试就是一系列活动，这些活动是为了评估一个程序或者 软件系统的特性或能力，并确定是否达到了其预期的效果。从这话我们可以看出以下两点： 测试试图验证软件是“工作的”，也就是验证软件功能执行的正确性测试的活动是以测试人员“预期的结果”为依据，这里的“预期结果”指的是需求定义

软件测试的特点：

软件测试只是一个样本试验，具有不可穷尽性

软件测试与调试的区别：

目的不同

-调试(Debug)：确保程序做了程序员想它做的事情,同时也是为了发现并解决软件中的缺陷

-测试(Testing)：确保程序解决了它该解决的问题,同时也是为了发现软件中的缺陷

参与角色不同

-测试由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行

-调试由开发人员完成。

执行的阶段不同

–测试贯穿整个软件开发生命周期

-调试一般在开发阶段

需求的概念

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

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

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

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

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

为什么用户需求不能直接作为开发和测试人员工作的依据呢？

因为用户提出的一些需求可能会有一些不合理，所以我们需要对用户的需求进行需求分析，从市场可行性（投入的人力成本和时间成本远大于市场收益）和技术可行性（1.技术能不能实现 2.技术上实现是否有难度）等来进行分析

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

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

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

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

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

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

从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率

对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计

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

测试工程师在需求分析和设计阶段就开始介入（测试应当贯穿于软件的整个生命周期），因为这个阶段是理解和掌握软件的原始业务需求的最好时机

只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集

测试用例的概念

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

测试用例解决了两大问题：测什么，怎么测

下面举一个注册邮箱的测试用例

标题:
注册网易邮箱

测试环境:
win10 Microsoft Edge 版本 121.0.2277.112 (正式版本) (64 位)

测试数据:
邮箱地址:[e-mail]
密码：123456@qAz
手机号：[phone]
验证码：952568

测试步骤：
1.打开edge浏览器，输入网易邮箱的注册网址：https://mail.163.com/register/index.htm?from=163mail&utm_source=163mail#/pn
2.输入邮箱地址、密码、手机号、获取验证码并输入输入验证码，勾选用户协议
3.点击注册

期望结果：展现注册成功的结果页，并且使用账号可以正常登录

测试用例能够解决什么样的问题？

–是否较全面的测试了所有功能

–进行测试的覆盖率衡量

–对新版本的重复测试实施

–解决存在大量冗余测试影响测试效率

为什么要设计测试用例？

围绕着软件需求来设计测试用例，解决了重复测试的问题

比如：

1.测试人员提出的bug，然后开发人员对bug修复完成之后，测试人员对bug进行回归验证

2.软件的版本迭代：对软件的新版本的历史功能也需要进行测试（自动化测试）

原则：测试用例避免用后即弃

软件错误（BUG）的概念

当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配

当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误

软件的生命周期

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

需求分析：

分析用户的需求是否合理（市场上，技术上等进行分析），产出软件需求文档

计划：

指定需求执行计划

设计：

将需求细化成一个个任务，进行技术设计（设计哪些接口，采用哪些技术），产出软件设计文档

编码：

开发人员按照需求文档以及设计文档来进行编码

测试：

测试人员参考测试用例来执行测试

运行维护：

项目上线之后对产品进行线上的维护

（1）修复性维护：对项目中未发现的问题进行修复

（2）完善性维护：对功能进行完善

（3）预防性维护（居安思危）：为了避免产品在线上出现一些其他的问题，进行一些预防的手段

软件开发模型

瀑布模型（Waterfall Model）

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

优点：

–强调开发的阶段性

–强调早期计划及需求调查

–强调产品测试

缺点：

–依赖于早期进行的唯一一次需求调查，不能适应需求的变化

–由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程

–风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会

–测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，

使用场景：

需求固定的小项目

螺旋模型（Spiral Model）

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

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

优点：

–强调严格的全过程风险管理（螺旋模型引入全流程的风险分析，每次分析完成之后都会生成一个新的原型）

–强调各开发阶段的质量

–提供机会检讨项目是否有价值继续下去

缺点：

–引入非常严格的风险识别、风险分析和风险控制（风险分析能力和产品遗留的风险是成反比的），这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入

使用场景：

规模庞大、复杂度高、风险大的项目

增量模型

什么是增量模型？

用户假设给我这个软件三个需求分别是A、B、C

开发完成A之后，我直接上线给用户去使用

开发完成C之后，我直接上线给用户去使用

开发完成B之后，我直接上线给用户去使用

类似于一张画，增量模型是先画头部，再画四肢，再画身体

迭代模型

什么是迭代模型？

用户假设给我这个软件三个需求分别是A、B、C

我们直接开发一个基础版本（包含功能A、B、C），但是A、B、C的功能比较简陋，接下来我会继续在基础的版本上对ABC的功能进行迭代优化

类似于一张画，迭代模型是先画一个轮廓，然后再补充各种细节，再补色

敏捷开发

敏捷宣言

个体与交互重于过程和工具(轻流程,强调人与人之间的面对面的高效沟通)
可用的软件重于完备的文档(轻文档,重产出)
客户协作重于合同谈判
响应变化重于遵循计划(用户提出了需求,再过两天,用户发现我不想要这个功能,我需要再换一个功能)
在每对比对中，后者并非全无价值，但我们更看重前者。

四句宣言想表达敏捷模型的一个特点:轻流程、轻文档、重目标、重产出

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

scrum

三个角色

scrum由product owner(产品经理)：收集用户的需求，编写需求文档，对产品负责的人

scrum master(项目经理)：负责召开各种会议，协调项目，为研发团队服务

team(研发团队)：开发人员，测试人员，ui设计人员等等

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

五个会议

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

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

发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog（产品经理从需求池中选取几个需求，开展发布计划会议）

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

每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题（每日例会通常为站会，快速过一下项目有关的几个问题，每日例会的意义：及时了解项目进度，预知风险，规避风险）

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

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

迭代开发

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

scrum的例子如下：

敏捷中的测试

挑战1：轻文档

挑战2：快速迭代

1、测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主

2、测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同时执行，根据测试结果不断调整测试计划）、自动化测试

3、敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug出现的原因

v模型

V模型目的是改进软件开发的效率和效果。是瀑布模型的变种

特点：

1、明确标注了测试的类型

2、明确标注了测试阶段和开发阶段之间的对应关系

缺点：

仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

W模型（双V模型）

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

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

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

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