前言

本文章为软件测试基础-概念篇课程的笔记记录。

1-1 软件测试概要

什么是软件测试？

早期定义：
软件测试是对程序能够按预期运行建立起一种信心。 —— Bill Hetzel,1973

经典定义：
测试是为发现错误而执行程序的过程。 —— Myers,1979

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

软件测试的测试对象

测试对象是贯穿整个测试过程的：

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

五大要素和两个目标

• 要素
  质量、人员、资源、流程、技术
• 目标
  测试覆盖率、测试效率

软件测试所遵循的原则

• 测试显示缺陷的存在，但不能证明系统不存在缺陷；
• 穷尽测试是不可能的，应设定及时终止的条件；
• 测试应该尽早进行；
• 缺陷具备群集特性；
• 测试的杀虫剂悖论；
• 测试的二八原则(80%的时间花在20%的重点功能上)；
• 测试活动依赖于测试背景

1-2 软件测试阶段

按测试阶段来分类：单元测试、集成测试、系统测试、验收测试

单元测试

什么是单元测试

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

单元测试的原则

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

单元测试的益处

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

单元测试的限制

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

单元测试框架

Xunit，如：Junit、nunit、PHPUnit、CppUnit

集成测试

定义

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

集成测试的主要实施方案

• Big Bang（全部组装好，再进行集成测试）
• 自顶向下（从主程序开始，控制层逐层测试）
• 自底向上（从程序模块的最底层开始向上组装；最常用）
• 核心系统集成
• 高频集成（持续集成）

集成测试 VS 单元测试

• 测试的对象不同
• 测试的依据不同：详细设计 VS 概要设计
• 测试的方法不同：接口测试 VS 程序内部

系统测试

定义

是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其它部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。

关注点

• 关注系统本身的使用
• 关注系统与其他相关系统间的联通
• 关注系统在不同使用压力下的表现
• 关注系统在真实使用环境下的使用

系统测试 VS 集成测试

• 测试对象不同
  • 集成测试：由通过了单元测试各个模块所集成起来的构件
  • 系统测试：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统
• 测试时间不同
  • 集成测试：介于单元测试和系统测试之间
  • 系统测试：在集成测试之后
• 测试内容不同
  • 集成测试：各个单元模块之间的接口
  • 系统测试：整个系统的功能和性能
• 测试角度不同
  • 集成测试：偏于技术角度的验证
  • 系统测试：偏于业务角度的验证

验收测试

定义

也称交付测试。针对用户需求、业务流程的正式测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统。

细分

• 用户验收测试
• 运行验收测试
• 合同和规范验收测试
• Alpha测试（开发者提供的场景，用户运行）
• Beta测试（用户提供的场景下测试）

2-2 软件测试手段

按测试时对象的可见度：黑盒测试、白盒测试
按状态：静态测试、动态测试
按测试执行的方式：手工测试、自动化测试

黑盒测试

过程

输入 ——> 用户需求/事件驱动 ——> 输出

优点

• 容易实施，不需要关注内部的实现
• 更贴近用户的实用角度

缺点

• 测试覆盖率较低，一般只能覆盖到代码量的不到40%
• 针对黑盒的自动化测试，复用率较低，维护成本较高

黑盒测试主要测试什么？

• 是否有不正确或遗漏的功能？
• 在接口上，输入是否能正确的接受？能否输出正确的结果？
• 是否在数据结构错误或外部信息（例如数据文件）访问错误？
• 性能上是否能够满足要求？

黑盒测试的主要设计方法

• 等价类划分法
• 边界值分析法
• 错误推断法
• 因果图法
• 正交试验分析法
• 状态迁移图法
• 流程分析法

白盒测试

过程

输入 ——> 逻辑覆盖 ——> 输出

主要的逻辑单位

语句、条件、条件组合、分支、路径

优点

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

缺点

• 成本高，昂贵
• 无法检测代码中遗漏的路径和数据敏感性错误
• 不能直接验证需求的正确性

白盒测试的主要设计方法

• 代码检测法：多面检查，代码审查和走查
• 静态结构分析法：通过测试工具分析代码结构逻辑
• 静态质量度量法：质量标准
• 逻辑覆盖法：语句、条件、条件组合、分支、路径覆盖
• 基本路径测试法：非常主要的方法

灰盒测试

介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现。

静态测试

定义

静态测试是指无需执行被测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合变成标准，借以发现编写的程序的不足之处，减少错误出现的概率。

方式

互审 —— 走查 —— 会议（不正式 —— 正式）

动态测试

动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等。

手工测试

由专门的测试人员从用户视角来验证软件是否满足设计要求的行为，更适用针对深度的测试和强调主观判断的测试。
例如：众包测试、探索式测试

自动化测试

定义

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

手工测试 VS 自动化测试

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

2-3 软件测试模式

按测试模式来分类：敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。

传统的瀑布模型

流程

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

瀑布模型的优缺点

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

V模型

流程

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

局限性

• 仅仅将测试放在后半段，忽视了测试对需求的分析和验证
• 违背了测试需要尽早进行的原则

W模型

W模型

X模型

X模型

H模型

H模型

2-4 软件测试模式—敏捷测试

敏捷测试

定义

Agile Testing，遵循敏捷宣言的一种测试实践。

敏捷宣言

我们通过身体力行和帮助他人来揭示更好的软件开发方式，借由这种工作，我们形成了如下的价值观：
个人与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比较中，后者并非全无价值，但我们更看重前者。

特点

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

敏捷测试 VS 传统测试

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

基于脚本的测试—SBT

• Scirpt-based Testing
• Scripted Testing（ST） 脚本测试
• Exploratory Testing （ET） 探索式测试

探索式测试

完全抛开测试脚本的测试，是一种测试风格、思维而不是测试技术。

ST vs ET

• ST
  • 系统性强
  • 容易管理、控制
  • 设计在先，执行在后
  • 主要是验证自己的思路
  • 可预见性
• ET
  • 自由灵活
  • 和ST是互补的
  • 执行和设计（思考）并行
  • 不断和系统交互，带着问题测试
  • 学习的过程

探索式测试的优点

• 更能激发测试人员的创造性和工作乐趣
• 增加了发现新的或较深入Bug的可能性
• 在较短时间内找到更多Bug以及对SUT做一个快速的评估
• 有利于更加有效地实施自动化
• 更加适用于敏捷项目
• 减少了在简单、繁复上用例的无谓编写时间

探索式测试的缺点

• 测试管理上有局限性，较难协调和控制
• 对于Bug的重复利用和重现上作用有限
• 对测试人员的测试技能和业务知识深度依赖较大
• 只有在SUT已完全可用的前提下才更有作用
• ET的生产率很难定义
• ET本身较难进行自动化

局部探索式测试

五大要素：

• 输入（接受输入，产生输出，存储数据，进行运算）（测试要点：输入顺序，输入内容，输出异常）
• 状态（临时状态，永久状态）（测试要点：运行时有效，阶段有效，数据库保存，文件保存）
• 代码路径（对代码的覆盖）
• 用户数据（尽量使用真实的数据）
• 执行环境

全局探索式测试

漫游测试法

• 商业区：软件从启动到关闭之间客户可能使用到的主功能
• 旅馆区：软件休息或未运行时的功能，一般在后台
• 历史区：历史遗留代码或问题
• 旅游区：新用户使用或比较关注的功能
• 娱乐区：系统主要功能之外的一些辅助功能
• 破旧区：已废弃或隐藏的功能

基于风险的测试—RBT

定义

Risk-based Testing，一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型。

哪些是风险？

• 质量风险
• 管理风险
  风险级别 = 风险可能性 * 风险严重度

识别风险

• 可能性：复杂度、时间压力、高变更率、技能水平、地理分散度
• 严重程度：使用频率、失效可视性、商业损失、组织负面影响和损害、社会损失和法律责任
  风险要素分 = Sum(单项权重 * 得分)

基于模型的测试—MBT

定义

Model-based testing is software testing in which test cases are derived in whole or in part from a model that describes some (usually functional) aspects of the system under test (SUT).

主要的MBT工具

• Spec Explorer (Microsoft)
• GraphWalker (OpenSource)
• Tcases (OpenSource)
• Modeljunit (OpenSource)

3-1 软件测试类型

按测试类型来分类：
功能测试，性能测试，部署测试，文档测试，安全测试，兼容性测试，易用性测试，本地化测试，无障碍测试，可靠性测试

功能测试

定义

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

针对的问题

功能错误或遗漏、界面问题、性能错误（软件本身的性能）、数据及访问错误、初始化及终止错误

功能测试工具

• 商用：QTP、Winrunner、silk Test、Rational robot
• 开源：selenium(Web)、Watir(Web)、Sikuli(基于屏幕截图)

性能测试

细分

• 负载测试：在测试过程中，逐步增加负载，并记录下被测系统的性能表现，最终确认出系统在正常指标下的最大负载
• 压力测试：测试系统在极限负载下的压力情况，确定系统在什么压力下会导致系统失败，不能正常运行，测试系统所能承受的极限。
• 稳定性测试：一般是稍大于业务量的负载，进行长时间的测试。

性能指标

并发用户数VU、每秒事务数TPS、系统响应时间、设备性能

性能测试工具

Loadrunner、Silkperformer、JMeter、WebLoad、Apache Bench、LoadUI

静态性能评估

• 定义：开发Web应用时，基于一系列Web应用页面性能优化的最佳实践对Web应用的页面进行静态分析，并给出评估结果的性能分析方法。
• 工具：YSlow、PageSpeed

应用性能管理(APM)

Application performance Management，提供对系统的实时监控以实现性能管理、故障管理的解决方案。

安全测试

定义

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

渗透测试

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

渗透测试 VS 安全测试

• 渗透测试：攻、点
• 安全测试：防、面

OWASP (Open Web Application Security Project)

• OWASP Top10
• Test Guide

兼容性测试

多维度

• 软件本身的兼容性（版本之间）
• 不同平台下的兼容性（如底层系统）
• 软件对运行设备的兼容性（如硬件设备）
• 软件互操作性（同一个厂商或者其他主流应用）

浏览器内核

• Trident4-6：IE6-8、9、10
• Gecko：Firefox
• WebKit：Safari、Chrome
• Presto：Opera

浏览器兼容性测试工具

• BrowserShots（截图对比）
• Brower Sandbox
• Chrome插件：w3help

文档测试

定义

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

文档测试关注要点

完整性、正确性、一致性、易理解性、易浏览性

可靠性测试

软件可靠性、硬件可靠性（主要）

易用性测试

易用性测试是指测试用户使用软件时是否感觉方便，是否能保证用户使用体验的测试类型。

本地化测试

定义

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

主要测试内容

• 语言、书写习惯
• 时区、日期格式、货币
• 当地习俗、法律法规
• 政治敏感内容

部署测试

定义

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

主要测试内容

• 在不同环境下的部署验证
• 参照部署文档执行，过程的合理、正确性
• 基础数据

无障碍测试

Accessibility Test，也称可访问性测试。是指软件需要提供便于特殊人群使用的功能，包括视障、听障、老年人、身体残疾用户等，无障碍测试则是针对这部分功能的测试。

4-1 其他测试分类

其他的一些测试类型概念
回归测试、冒烟测试、Monkey测试、AB测试

回归测试

定义

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

回归测试的中心在关键模块和重点功能组件。

软件研发周期中会进行多次回归测试，且尽量实现自动化。

冒烟测试

定义

来自于硬件板卡验证术语。软件上则用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

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

Monkey测试

定义

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

A/B测试

定义

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

A/B测试实施要点

• 多个方案并行
• 每次测试仅改动一个变量
• 按照某种规则进行优胜劣汰

A/B测试工具

• Google Analytics Content Experiments
• Visual Website Optimizer