04_软件测试入门.md

软件测试入门

软件测试理论

什么是软件测试

在规定条件下对程序进行操作, 从而发现错误, 对软件质量进行评估的一个过程.

软件测试的目的

是想以最少的人力，物力和时间找出软件中潜在的各种错误与缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患以及带来的商业风险。

软件测试的定义

使用人工或自动手段来运行或测试某个系统的过程, 其目的在于检验它是否满足规定的需求或是弄清预期结果和实际结果之间的差别

公司分类

• 自研公司 (有公司主营自主研发产品) 需求：公司自己制定的
• 外包公司
  • 项目外包 (产品是客户的，给客户研发定制产品) 需求：客户
    • 项目组：公司内部
  • 人力外包 (产品是客户的，给客户研发定制产品) 需求：客户
    • 项目组：客户的公司

测试分类

• 软件测试
• 硬件测试
• 嵌入式测试
• 游戏测试

嵌入式测试：

• 方案公司
  • 项目组客户：集成公司客户
• 集成公司
  • 项目组客户：客户
  • 测试

常见公司项目组，组织架构

软件项目组

• 项目经理 (1)
• 产品
• 研发部
  • 技术总监/经理/主管
  • 开发
• 测试部
  • 测试总监/经理/主管
  • 测试
• A 项目组
  • 项目经理
  • 产品经理
  • 开发
  • 测试
• B 项目组

项目经理（1 个）：掌控整个项目（需求，进度，人员）
产品（ 12 个）: 确定产品需求，产品经理会将需求转化为《产品原型图》, 产品需求规格书（需求文档） （墨刀, 蓝湖, Axure）
UI 设计师（女）12 个：产品原型图，ui 设计
前端工程师（开发）：前端页面 Web（1 ~ 2 人），Android（1 ~ 2 人），IOS（1 ~ 2 人），小程序/H 5 (12)
后端工程师（开发）：数据接口 （34 人）
测试工程师（2~3 人）：软件质量一般和开发比例 1:3, 2:5 , 1:5(工资高，成长快)
运维工程师（1 人）：上线，维护，服务器
研发部：技术总监（经理）（主管）
测试部：测试总监（经理）（主管）
财务，人事，市场，硬件，QC，运营（推广，后期数据统计，转化率）

软件开发模型

• 瀑布模型
• 快速原型模型
• 增量模型 (迭代模型)
• 螺旋模型

1. 瀑布模型

瀑布模型将软件生命周期划分为制定计划、需求分析、系统设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型核心思想

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改

优缺点

优点:

1. 为项目提供了按阶段划分的检查点, 软件开发的每个阶段都很清晰明了
2. 当前阶段完成后, 只要去关注后续阶段
3. 可在迭代模型中每轮迭代很类似于一个小的瀑布模型
4. 它提供了一个模版, 这个模版使得分析、设计、编码、测试可以在该模版下有一个共同的指导

缺点:

1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量
2. . 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险
3. 突出缺点是不适应用户需求的变化
4. 软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心

使用范围

用户的需求非常清楚全面，且在开发过程中没有或很少变化；开发工作对用户参与的要求很低。

2. 快速原型模型

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

核心思想

快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量

优缺点

优点:

• 克服瀑布模型的缺点, 适应需求的变化, 能够开发出更加让用户更满意的需求

缺点:

• 所选用的开发技术和工具不一定符合主流的发展；
• 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
• 使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

使用范围

• 不适合大型项目的研发
• 对所开发的领域比较熟悉而且有快速的原型开发工具

3.增量（迭代）模型

介绍

增量模型（迭代模型），是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交

基本思想

迭代模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险

优缺点

优点：

• 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展
• 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
• 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。

缺点：

• 要求待开发的软件能给进行增量式的开发, 否则会很麻烦
• 在软件开发过程中需求变化是不可避免的, 增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性.

使用场景

进行已有产品升级或新版本开发

4.螺旋模型

螺旋模型沿着螺线进行若干次迭代，四个象限代表了以下活动：
（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3） 实施工程：实施软件开发和验证；
（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

优缺点

优点:

• 设计灵活可以在项目各个阶段进行变更
• 风险驱动, 每个项目上线前都要进行风险分析

缺点:

• 螺旋模型强调风险分析, 需要相当丰富的风险评估经验和专业知识, 在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失；
• 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，

使用场景

适合使用大规模，大型的软件项目

测试模型

V 模型

V 模型和瀑布模型有一些共同的特性，V 模型中的过程从左到右，描述了基本的开发过程和测试行为

单元测试

是模块测试，验证软件的基本组成单位的正确性，是白盒测试
（代码层测试，逻辑覆盖）(代码中添加 unittest 模块，代码扫描工具）

集成测试

是模块间的测试，测试接口
（软件各模块之间的接口和软件与硬件之间的接口）是否正确，是灰盒测试（白盒和黑盒结合)

系统测试

系统测试包括：冒烟测试、系统测试、回归测试 ^d0091e

冒烟测试

主干流程测试，确认软件的基本功能正常，可以进行后续的测试工作

系统测试

是检测系统的功能、质量、性能能否满足系统的要求，包括
功能
界面
易用性
安全性：数据传输安全性、用户安全性、服务器安全性
兼容性：不同设备、不同环境
性能：服务端性能、客户端性能
等等，是黑盒测试 ^04d731

回归测试

开发修改了旧代码之后重新进行测试 （需求改变了，修改错误之后），确认修改后的代码没有引入新的错误或导致其他代码产生新的错误。分为
功能回归： 不只验证当前出问题的功能是否修复，还要验证功能相关模块是否有新的问题；
系统回归（测试 2~3 轮）： 包括功能回归测试，当系统测试完成后，针对之前经常出问题的功能模块和系统流程进行测试，避免遗漏

验收测试

是确保软件的实现能否满足用户的需求或合同的要求
（客户，测试，第三方）

优缺点

优点:

• 每一个阶段都清晰明了、便于控制开发的每一个过程
• 既包含单元测试又包含系统测试

缺点:

• 测试介入的较晚, 对于前期的一些缺陷无从发现和修改
• 测试和开发串行

w 模型

优点
测试伴随软件的整个生命周期, 例如, 在需求分析结束后就可以进行需求分析测试
测试与开发是并行独立进行
缺点
对需求和测试技术要求高
适用于大中型企业

h 模型

优点
开发的 H 模型揭示了软件测试除测试执行外，还有很多工作；
软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；
软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；
缺点:
管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；
技能要求高：H 模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；

软件测试分类

按阶段划分

单元测试

由开发工程师进行测试，代码走查、评审、代码扫描
测试方法：白盒测试（语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖）
测试依据：代码和注释 + 设计文档

集成测试

接口测试
在单元测试之后，冒烟测试之前
测试方法：灰盒测试
测试依据：单元测试模块 + 接口文档

系统测试

对整个系统进行测试，包括冒烟测试、系统测试、回归测试
测试方法：黑核测试
测试依据：需求文档

按是否覆盖源码划分

黑盒测试

功能测试
性能测试

白盒测试

测试代码

灰盒测试

测试接口

按是否执行程序划分

静态测试

白盒测试
需求文档、设计文档、源码

动态测试

灰盒测试、黑盒测试

按是否自动化划分

手工测试

优点：探索性测试、发散性思维
缺点：效率慢，量大易错

自动化测试

在性能测试之后，依靠脚本或者工具
优点：效率高
缺点：无法替代探索性测试，只能完成既定代码和流程，对测试人员技术要求高，维护成本高

测试步骤：

1. 完成功能测试，版本基本稳定
2. 根据项目，选择合适工具
3. 提取手工测试的测试用例转化为自动化测试用例
4. 通过工具、代码实现测试
5. 生成测试报告
6. 持续改进优化

其他 *

冒烟测试

回归测试

随机测试

随机抽查，没法保证准确性

验收测试

部署软件之前的最后一个测试，在系统测试之后
按照需求文档进行验收
验收方：用户/需求方
验收依据：用户需求，验收标准
测试方法：白盒、黑盒、灰盒，以黑盒为主
测试内容：功能测试为主

验收测试分为 α 测试与 β 测试：

α 测试

由内部用户在开发环境下进行的测试

β 测试

区别

测试场所不同：α 测试在开发方场所，β 测试在用户场所
α 测试环境受开发方控制，用户数量少，时间集中，β 测试环境不受开发方控制，用户数量较多，时间不集中
α 测试比 β 测试早