软件测试学习入门

软件测试入门学习

• 软件测试/li>
• 软件测试的测试对象
• 软件测试五大要素和两个目标
• 软件测试所遵循的原则
• 软件测试的分类
• • 单元测试
  • • 单元测试的原则
    • 单元测试的益处
    • 单元测试的限制
  • 集成测试
  • • 集成测试的主要实施方案
  • 系统测试
  • • 系统测试的关注点
  • 验收测试
  • 黑盒测试
  • • 黑盒测试主要测试什么
    • 黑盒测试的主要设计方法
  • 白盒测试
  • • 主要的逻辑单位
  • 静态测试
  • 动态测试
  • 手工测试
  • 自动化测试
  • • 手工测试与自动化测试的区别
  • 瀑布模型
  • • 瀑布模型的优缺点
  • V模型
  • • V模型优缺点
  • W模型
  • • W模型优缺点
  • X模型
  • H模型
  • 敏捷测试
  • • 敏捷测试的特点
    • 敏捷测试优缺点
  • 功能测试
  • • 功能测试工具
  • 性能测试
  • • 性能指标
    • 性能测试工具
    • 静态性能评估
    • 应用性能管理
  • 安全测试
  • • 安全测试工具
  • 兼容性测试
  • • 兼容性测试工具
  • 文档测试
  • 可靠性测试
  • 易用性测试
  • 本地化测试
  • • 主要测试内容
  • 部署测试
  • • 主要测试内容
  • 无障碍测试
  • 回归测试
  • Monkey测试
  • 冒烟测试
  • A/B测试
  • • A/B测试工具
• 回归总结

软件测试学习入门

软件测试/h2>

1、什么是软件测试/p>

• 使用人工或自动的手段来运行或测量软件系统的过程，以体验软件系统是否满足规定的要求，并找出与预期结果之间的差异。

软件测试的测试对象

2、软件测试的测试对象

• 软件需求
• 软件概要设计
• 软件详细设计
• 软件源码
• 可运行程序
• 软件运行环境

软件测试五大要素和两个目标

3、软件测试五大要素和两个目标

• 软件质量 人员 技术 流程 资源
• 测试覆盖率 测试效率

软件测试所遵循的原则

4、软件测试所遵循的原则

• 测试能显示缺陷的存在，但不能证明系统不存在缺陷
• 穷尽测试是不可能的，应设定及时终止的条件
• 测试应该尽早进行
• 缺陷具备群集特性
• 测试的杀虫剂悖论
• 测试的二八原则（百分之八十的时间或资源用在百分之二十的重点模块，重点测试这个软件百分之二十的重要模块，来达到测试的效率和资源配置最佳的比例）
• 测试活动依赖于测试背景

软件测试的分类

5、软件测试的分类

• 按照测试阶段分类（单元测试、集成测试、系统测试、验收测试）
• 按照测试手段分类
  （根据测试对象的可见度：黑盒测试、白盒测试；
  根据状态：静态测试、动态测试；
  执行方式：手工测试、自动化测试）
• 按照测试模式来分类（瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等）
• 按照测试类型分类（功能测试、性能测试、部署测试、文档测试、安全测试、兼容性测试、易用性测试、本地化测试、无障碍测试、可靠性测试）
• 其他的一些测试类型概念（回归测试、冒烟测试、Monkey测试、A/B测试）

单元测试

1、什么是单元测试

• 对软件中的最小可测试单元进行检查和验证。

单元测试的原则

单元测试的原则：

• 尽可能保证各个测试用例是互相独立的。
• 一般由代码的开发人员来实施，用以检验所开发的代码功能能符合自己的设计要求。

单元测试的益处

单元测试的益处：

• 能尽早发现缺陷、有利于重构、简化集成、文档用于设计

单元测试的限制

单元测试的限制：

• 不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误
• 每一行代码，一般需要3~5行测试代码才能完成单元测试，所以存在投入和产出的一个平衡。

集成测试

2、什么是集成测试

• 是在单元测试的基础上，测试将所有团建单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。

集成测试的主要实施方案

集成测试的主要实施方案：

• Big Bang：一次性集成，主要做法把大部分的开发模块都耦合起来形成一个完整的软件系统或者系统的主要组成部分，并把他们拿来做集成测试，即把所有的东西组装好，一起来做测试。
• 自顶向下：递增的组装软件结构的方法，一般来说从主程序开始沿控制层逐层的向下集成，通过这种方式逐层的测试，覆盖到所有的模块。
• 自底向上：最常用的集成测试，从程序模块的最底层模块开始，逐层的向上组装并逐层的测试。好处：针对我们已经组装的测试，不需要对上一层组装模块，比较好的锁定软件故障的位置
• 核心系统集成：先把核心的软件部分挑选出来，并对这些部件进行集成测试，在测试通过的基础上再逐步的扩展的外围的部件，直到最后形成稳定的软件产品
• 高频集成：同步软件开发过程，每隔一段时间研发团队就对现有的代码进行一次集成测试

系统测试

3、系统测试：

• 真实运行环境，主要包括功能测试、性能测试、稳定性测试、多种类型的测试。（偏于业务角度的验证）

系统测试的关注点

关注点：
①关注系统本身的使用；
②关注系统与其他相关系统的连通；
③关注系统在不同使用压力下的表现。

验收测试

4、验收测试（交付测试）：
用户验收测试（开发方）、运行验收测试（运维）、合同和规范验收测试、α/alpha测试（开发者提供的环境测试、用户执行）、β/beta测试（脱离开发者环境，由用户提供测试环境）、release版本即为可交付版本。

黑盒测试

5、黑盒测试：
不考虑程序内部结构和内部特性下，通过相关暴露出的接口，对程序进行测试。
只检查程序的功能是否按照需求规定，正常使用；
程序是否能适当的输入输出数据，并产生正确的输出信息；
一般针对软件外面的界面，可见的功能；
从用户的视角，通过不同数据事件，通过输出结果进行判断；

优点：
1．容易实施，不需要关注内部的实现
2．更贴近用户的使用角度

缺点：
1．测试覆盖率较低，一般只能覆盖到代码量的不到40%
2．针对黑盒的自动化测试，复用率较低，维护成本较高。因：产品活动增/删（更新）

黑盒测试主要测试什么

黑盒测试主要测试什么
1．是否有不正确或遗漏的功能br> 2．在接口上，输入是否能正确的接受否输出正确的结果br> 3．是否有数据结构错误或外部信息（例如数据文件）访问错误br> 4．性能上是否能够满足要求/p>

黑盒测试的主要设计方法

黑盒测试的主要设计方法：

• 等价类划分法：针对程序的输入条件进行分类，输入典型的数据
• 边界值分析法：特殊的边界数据，测试代码的边界状态
• 错误推测法：基于经验，直觉，判断错误的地方；特殊字符，文件不存在
• 因果图法：根据输入输出看做原因和结果，形成因果图。（因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。）
• 正交试验分析法：选出代表性的数据，作为输入数据
• 状态迁移图法：软件审批的过程，各种状态迁移
• 流程分析法：处理程序逻辑执行的路径

白盒测试

6、白盒测试：

• 内部逻辑代码对开发人员是透明的，也叫透明测试，主要看逻辑覆盖率，语句覆盖、条件覆盖、条件组合覆盖、分支覆盖、判定覆盖、条件判定组合覆盖、路径覆盖。白盒测试会迫使测试人员去思考软件的实现原理，可以检测代码中的每条分支和路径、可以揭示隐藏在代码中的错误、对代码的测试比较彻底，比较昂贵。白盒测试的主要测试方法有代码检测法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法。

主要的逻辑单位

主要的逻辑单位：
语句覆盖：保证每条语句执行一次
分支（判定）：保证每条分支至少执行一次
条件：条件表达式，至少计算一次
条件组合：所以不同条件下的组合情况
路径：程序中，每个可能的路径至少执行一次

优点
1．迫使测试人员去仔细思考软件的实现，理解原理
2．可以检测代码中的每条分支和路径
3．揭示隐藏在代码中的错误
4．对代码的测试比较彻底

缺点
1．昂贵。
2．无法检测代码中遗漏的路径和数据敏感性错误
3．不能直接验证需求的正确性

静态测试

静态测试：

• 无需执行被测程序，看文档或代码。互审–>走查–>会议

动态测试

动态测试：

• 运行被测程序，检查结果与预期结果的差异。

手工测试

手工测试：

• 深度测试和强调主观判断的测试。众包测试、探索式测试等。

自动化测试

自动化测试：

• 使用单独的测试工具控制测试的自动化执行以及对预期和结果进行自动检查。单元测试、接口测试、性能测试。

手工测试与自动化测试的区别

手工测试vs自动化测试：

手工测试	自动化测试
易发现缺陷	高效率、速度快
容易实施	高复用性
创造性、灵活性	覆盖率易度量
覆盖量化难	准确、可靠
重复测试率低	不知疲劳
不一致性，可靠性低	机械，发现缺陷率低
人力资源依赖	一次性投入较大

瀑布模型

瀑布模型：

• 项目计划->需求分析->软件设计->程序开发->软件测试->集成维护

瀑布模型的优缺点

优点	缺点
强调需求、设计的作用	难以适应需求的频繁变化
前一阶段完成后，只需要关注后续阶段	项目周期后段才能看到成果
为项目提供了按阶段划分的检查点，里程碑清晰	强制的里程碑、完成时间点
文档规范	文档工作量大

V模型

V模型（最广泛）：

• 需求分析->概要设计->详细设计->软件编码->单元测试->集成测试->系统测试->验收测试

V模型优缺点

优点：
描述了测试与软件开发过程的对应关系。
强调了软件开发的协作与速度，反应测试活动和分析设计的关系，并且将软件实现和验证有机的结合起来，明确界定测试过程存在不同阶段的，明确了不同测试阶段和研发过程每个阶段的对应关系。

缺点：
把测试当做软件编码后的阶段，忽视了测试对需求的分析和验证，对需求与概要的验证要到后期才能进行，不符合软件测试需要尽早进行的感念。

W模型

w模型：开发与测试并行，可以尽早发现问题

• 用户需求->需求分析->概要设计->详细设计->编码->集成 ->实施->交付（开发）
  验收测试设计->系统测试测试->集成测试设计->单元测试设计->单元测试->集成测试->系统测试->验收测试（测试）

W模型优缺点

软件开发过程中，各个阶段测试都参与，测试伴随软件开发的整个开发周期；
优点：
能尽早的发现软件的缺陷；有利于尽早的发现软件的风险，及早的制定相应的应对方案，加快项目的进度

缺点：
需求设计编码还是串行的关系，测试开发保持着一种线性的关系，在上一个阶段完成后才能进行以一个阶段，不能很好的支持迭代场景。

X模型

X模型：

• 把软件测试当做一个独立的流程，贯穿在整个软件测试周期当中，与其他流程并发进行，将测试准备活动和测试执行活动清晰地体现出来。只要具备了测试条件，就可以开始测试；尽早准备，尽早执行。

敏捷测试

敏捷测试（Agile Testing）–遵循敏捷宣言的一种测试实践
敏捷宣言（价值观）：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比较中，后者并非全无价值，但我们更看重前者

敏捷测试的特点

敏捷测试的特点：
强调从客户角度进行测试
重点关注迭代测试新测试，不在强调测试阶段
尽早测试，不间断测试，具备条件即测试
强调持续反馈
预防缺陷重于发现缺陷

敏捷测试优缺点

敏捷测试VS传统测试

传统测试	敏捷测试
测试是质量的最后保护者	开发和测试人员是紧密合作，大家都有责任对软件负责
严格的变更管理	变更是可接受的，拥抱变更
预先的计划和细节的准备	计划随着进展时常调整
重量级文档	只需要绝对必要的文档
各阶段测试严格的入口和出口标准	各迭代之间已经没有明显的入口和出口标准
更多在回归测试时进行重量级的自动化测试	所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分
严格依赖流程执行	只需要绝对必要的文档
重量级文档	团队合作是无缝隙合作

功能测试

功能测试：

• 根据产品特性、操作描述金额用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。

针对的问题：功能错误或遗漏、界面问题、性能错误、数据及访问错误、初始化及终止错误。

功能测试工具

功能测试工具：

商用：QTP（基于关键字，web应用）winrunner（桌面端的软件）、silkTest、Rational robot

开源：selenium（敏捷开发）、Watir（web应用）、Sikuli(基于屏幕截图)

性能测试

性能测试：（负载测试、压力测试、稳定性测试）

• 负载测试：在测试过程中，逐步的增加负载，来观察系统的表现，最终确定出系统在正常的指标范围下的最大负载。
• 压力测试：测试系统在极限情况下的压力情况，最终系统在什么样的压力环境下会导致失效，不能正常运行，确定出我们这个系统所能承受的最大极限。
• 稳定性测试：一般是以稍大于正常业务量的负载进行持续的、长时间的测试，比如：24*5，连续5天的对这个系统进行24小时的施加压力，以确定系统在较长时间的运行情况下，我们这个系统地稳定性情况。

性能指标

性能指标:

• 并发用户数VU，同时访问系统的用户数量；
• 每秒事务数TPS，每秒系统处理业务的数量；
• 系统响应时间；
• 设备性能，CPU，磁盘等

性能测试工具

性能测试工具：LoadRunner ,Silkperformer , Jmeter(java开源的有效的测试工具) ,WebLoad , Apache Bench, LoadUI(专门针对http接口的性能测试)

静态性能评估

静态性能评估：

• 开发Web应用时，基于一系列Web应用页面性能的最佳实践队Web应用的页面进行静态分析，并给出评估结果的性能分析方法。

评估的标准/工具（YSlow，PageSpeed）

应用性能管理

应用性能管理(APM):
提供对系统的实时监控以实现性能管理、故障管理的解决方案。
www.tingyun.com

安全测试

安全测试：对软件产品进行测试以保证其符合产品安全需求和质量标准

渗透测试：通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试

兼容性测试工具

浏览器兼容性测试工具：
BrowserShots（www.browsershots.org）、Browser Sandbox、Google浏览器兼容测试插件（http://www.w3help.org）

文档测试

文档测试：

• 针对软件产品的交付品，配套的文档类部件的测试。如用户手册，使用说明、用户帮助文档等。

文档测试关注要点：完整性、正确性、一致性、易理解性、易浏览性

可靠性测试

可靠性测试：

• 可分为软件可靠性、硬件可靠性，但一般指的是硬件、环境方面的可靠性。

易用性测试

易用性测试：

• 易用性测试是指测试用户使用软件时是否感觉方便，是否能保证用户使用体验的测试类型。针对用户的交互界面，比如说业务流程的逻辑是否过于复杂、有没有误导用户的指引、包括 站的布局和样式。

本地化测试

本地化测试：

• 针对软件的本地化版本实施的针对性测试

主要测试内容

主要测试内容：语言、书写习惯；时区、日期规格、货币的转换；当地风俗、法律法规；政治敏感内容；

部署测试

部署测试：

• 也称安装测试，主要验证系统部署过程，并确保软件经过安装测试后可以正常使用。

主要测试内容

主要测试内容：

在不同环境下的部署验证，产品会有跨平台的特性，需在不同的环境下验证程序的编译是否有误。

参照部署文档执行，过程的合理、正确性。考虑一些在安装过程中出现的一些常见问题，比如 络中断，突然重启。

基础资料的准备非常重要，可用客户的线上资料

无障碍测试

无障碍测试：

• Accessibility Test
  也称可访问性测试。是指软件需要提供便于特殊人群使用的功能，包括视障、听障、老年人、身体残疾用户等，无障碍测试则是针对这部分功能的测试，虽然不是主流的测试方法，但是会越来越重视这一部分人的用户体验。

回归测试

回归测试

• 软件功能修改后，对软件进行重新测试以确认修改没有引入新的错误或导致其他部分产生错误。

回归测试的重心在关键模块和重点功能组件。
软件研发周期中会进行多次回归测试，且尽量实现自动化。

Monkey测试

Monkey测试：

• 也称搞怪测试。就是用一些随机、稀奇古怪的方式来操作软件，以测试系统的健壮性和稳定性。

冒烟测试

冒烟测试：

来自于硬件板卡验证术语。软件上则用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。与回归测试有些相似，但冒烟测试更对的是针对全流程的关键业务流程的验证，而回归测试重点在关键模块、关键功能。

“每日构建”中用冒烟测试来确认合入的代码没有影响主要功能的正常使用。

A/B测试

A/B测试

多用于互联 行业，通过为页面提供2个版本给用户使用并记录相关的用户行为数据，来确定更优化设计的一种测试方案。

A/B测试实施要点

多个方案并行，保证统计结果的有效性

每次测试仅改动一个变量，能更加确定用户的选择差异

按照某种规则进行优胜劣汰

A/B测试工具

A/B测试工具：
Google Andlytics Content Experiments 主要通过向用户提供不同页面的版本之后，通过嵌入我们的分析脚本，就可以收集到一系列分析数据。

Visual Website Optimizer

回归总结

PS：以上为慕课 课程中的总结。 址为：https://www.imooc.com/learn/700