课程目标

如下图:

• 课程学完可以到达中高级测试工程师
• 到达第二部分,基础入门非常重要.
  

1. 入门前的7个基础问题

1. 什么是软件测试？

软件测试是验证用户产品死否满足用户需求. 是否满足用户需要关乎公司盈利.

2.调试和测试区别？

目的:

• 调试:发现解决软件中的缺陷.
• 测试:发现软件中的缺陷.

参与角色:

• 调试: 开发人员
• 测试:开发人员,测试人员等 单元测试和集成测试主要由开发人员完成.

执行阶段:

• 调试:编码阶段.
• 测试: 贯穿整个软件生命周期.

3.软件测试的岗位

测试工程师:

• 测试开发工程师
• 测试工程师

职能:

• 测试开发工程师 :
• • 测试产品质量;
• • 开发效能工具:
• • • 自动化工具,代码覆盖工具,数据构造工具.
• 测试工程师:
• • 测试产品质量

软件研发工程师和测试开发工程师的区别:

• 研发工程师: 开发为主.
• 测开工程师: 测试为主,开发为辅.

4.软件测试的发展前景

如下图:

• 测试管理工具: 禅道开源软件.
• selenium : 界面自动化工具
• appium:移动平台上主流的自动化测试工具
• jenkins:自动化工具
• loadrunner,jmeter : 界面的性能工具,
• jmeter: 接口性能工具
• 安全测试: sql注入,xss,白帽子 这些都要求测试人员具备的基础安全测试.
• 探索性测试: 依靠测试人员的经验.
• 职位路线: 初中高 到 管理
  

5.软件测试的薪资如何

职友集

• 低级测试泛滥,俗称 点点点.
• 高级测试稀缺 : 每个阶段按年算.
• 高级测试与研发岗薪资差不多.

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

难易程度

• 开发专业度高;
• 测试人员掌握内容广度大。

工作环境办公用品:

• 笔记本+显示屏
• 开发环境:完全一致。

薪水:

• 中小企业测试人员薪资比开发要低一点。
• 中大型企业测试人员和开发人员薪资相当。
  发展前景
• 发展前景和开发一样

繁忙程度:

• 执行测试一项目上线完成
• 项目上线也需要测试人员跟进

技能要求:
+

7.测试人员具备的素质

2. 软件测试基本概念

2.1 需求的概念

2.1.1需求的基本概念

概念:

• 满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。
• IEEE定义：软件需求是 (1)用户解决问题或达到目标所需条件或权能(Capability)。 (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制.

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

用户需求:

• 可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成
  的任务。该需求一般比较简略
• 假如我要给同学们开发一个声控灯，同学们能够提出哪些需求?
• • 灯亮的时间、灯何时亮、灯安装的位置
• • 灯的颜色
• • 灯的形状
• • 五花八门的用户需求
• • 灯的材质
• • 灯的亮度
• • 灯可以联网
• • 灯支持语音识别

软件需求:

• 或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
• 大多数公司在进行软件开发会把用户需求转化为软件需求。
• 用户需求不能够直接作为开发和测试人员工作的依据。
• 原因是需要对用户的需求进行分析:
• • 市场可行性(成本）
• • 技术可行性（技术上是否能实现，技术上实现死否有难度，投入的人力和时间成本是否远远大于市场收益。

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

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

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

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

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

• 测试需求点到测试用例的产出，都是对需求进行分析发现的。
• 测试需求点关乎到测试用例的测试覆盖率。

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

• 在产品分析阶段或设计阶段开始时介入,因为软件测试贯穿软件的整个生命周期。
• 只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集。

2.2 bug的概念(了解)

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

2.3测试用例的概念

2.3.1 概念

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

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

例如如下图,编写注册网页邮箱的测试用例:

2.3.2 为什么要设计测试用例?

两点原因:

• 围绕着软件需求来设计测试用例。
• 解决了重复测试问题。- - 可以避免测试用例用后即弃。

2.4 软件生命周期

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

• 需求分析 : 分析用户需求是否合理( 市场分析,软件需求上的技术分析) ,编写出软件需求文档
• 计划 : 指定需求执行计划, 即确认需求要执行多久,什么时候开始,什么时候结束,安排多少人力,投入成本,产出计划文档
• 设计 : 将用户需求细化成一个个任务,进行技术设计(设计那些接口,采用那些技术).产出设计文档
• 编码 : 开发人员按照需求文档以及设计文档进行编码
• 测试 : 测试人员参考测试用例来执行测试
• 运行维护 : 项目上线之后对产品进行线上的维护:
• • 修复性维护 : 对项目中未发现的问题进行修复
• • 完善性维护:对功能进行完善
• • 预防性维护(居安思危):为了避免产品在线上出现一些其他的问题，进行一些预防的手段

2.5 开发模型

2.5.1 瀑布模型（Waterfall Model）

特点 ：

• 线性的开发流程、不能够应对需求的变化

缺陷：

• 测试被后置
• • 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会
• • 需要有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接造留给用户

主要缺陷：

• 可以运行的产品很迟才能被检测。风险往往被后至发现，因而失去及时纠正的机会。

使用场景：

• 需求固定的小项目。 - -

2.5.2 螺旋模型 （Spiral Model)

简介：

• 一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
• 这对于那些规模庞大、复杂度高、风险大的项目尤其适合。
• 这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。
• 因此，回归测试的重要性就不言而喻了。

如下图、

• 在瀑布模型基础上，每个阶段都给予一次风险分析，每次分析完成之后都会生成一个新的原形。
• 例如下图：从中心开始看，需求计划生成原型1，风险分析到原型2。
• 计划需要用户需求转变软件需求，开始计划，风险分析产出原型3。
• 软件产品设计指软件需求转变接口，风险分析产出原型4。
• 详细设计包含编码，单元测试，等等。
• 客户评估，客户提出新的需求，我们在按照原型4进行迭代。

螺旋模型的使用场景：

• 规模庞大，软件复杂度高，风险大的项目。

缺陷：

• 时间拉长，人力，资金。
• 风险分析能力与产品遗留的风险成正比。- - 需要有专业的风险分析的人，成本增高。

2.5.3 增量、迭代模型

注意事项：

• 需要区分增量模型和迭代模型。

简介：

• 增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。
• 增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。
• 因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。
• 增量通常和迭代混为一谈，但是其实两者是有区别的。
• 增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

详细讲解：

• 如下图、假设用户有一个需求，功能包含ABCD…
• 增量模型完成的流程:
• • 开发完A我就直接上线提供给用户使用
• • 开发完B我就直接上线提供给用户使用
• • 开发完C我就直接上线提供给用户使用
• 迭代模型完成的流程:
• • 先开发一个基础版本(包含共A,B,C,D),但是ABCD功能比较简陋。
• • 接下我们会继续在基础版本上对比功能进行迭代优化。
• 生活例子理解：一个人物画
• • 增量模型：
• • • 先画头、在画身体、再画四肢
• • • 逐渐建造
• • 迭代模型：
• • • 先画一个轮廓、在细化、再补色…
      

2.5.4 迭代式开发和瀑布模型的区别

• 瀑布模型是完成一个阶段才到下一个，如果出现测试问题需要回到上阶段进行修改。
• 增量式开发基础了瀑布模型，将软件的生命周期划分为多个阶段，每个阶段都会完成所有的阶段。
• 每轮迭代结束后，开始新一轮迭代，直到软件项目被终止，整个生命周期才会结束，其核心思想是，每次只完成软件中最迫切需要的一部分功能，并且随时关注用户的反馈信息。
• 它弥补了传统开发方式中的一些缺点，具有更高的成功率和生产率。

2.5.4 敏捷模型

简介:

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把“敏捷”(Agile)作为新的过程家族的名称。

在会议上，他们提出了《敏捷宣言》（http://agilemanifesto.org/）： 我们通过身体力行和帮助他人来
揭示更好的软件开发方式。

经由这项工怍，我们形成了如下价值观:

• 个体与交互重于过程和工具 解释: 轻流程,强调人与人之间面对面的高效沟通.
• 可用的软件重于完备的文档 解释: 轻文档,重产出.
• 客户协作重于合同谈判 解释: 多于用户沟通
• 响应变化重于遵循计划 解释: 用户需求可能发生变化,需要我们能快速变化.
• 在每对比对中，后者并非全无价值，但我们更看重前者。

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

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

2.5.4.1 scrum 敏捷模型

三个角色和五个会议。

三个角色：

• 产品经理： 收集用户的需求，编写需求文档，对产品负责的人。
• 项目经理：负责召开各种会议，协调项目，为研发团队服务。催工.
• 研发团队：开发人员，测试人员，ui设计人员等等。

五个会议：

product Backlog : 需求代办列表 （需求池）
Sprint Backlog : 周期内需要实现的用户需求.
daily scrum meeting : 每日会议

Potentially Shippable Product Increment : 可交付的软件

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

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

具体案例：