按测试阶段分类
单元测试
对软件中最小可充实单元进行检查和验证
单元测试的原则
- 尽可能保证各个测试用例是相互独立的
- 一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求
单元测试的益处
- 能尽早发现缺陷
- 有利于重构
- 简化集成
- 单元测试一定程度替代文档
- 用于设计，单元测试体验设计思路，设计本身可以用来验证设计
单元测试的限制
- 不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误
- 每一行代码，一般需要 3-5 行测试代码才能完成单元测试，所以存在投入和产出的一个平衡
单元测试框架
- JUnit
- NUnit
- PHPUnit
- CppUnit
集成测试
是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动
集成测试的主要实施方案
-
Big Bang
所有的东西都组装好，然后在进行测试
-
自顶向下
递增组装软件结构的方法，一般来说从主程序开始，沿控制层逐层向下来集成
-
自底向上
最常用的集成方法，从程序模块最底层的模块开始，逐层向上组装，并逐层的测试；好处是，针对我们已经集成的测试，不需要再针对上一层编写装模块
-
核心系统集成
先把核心的部分挑选出来，并对这些部分进行集成测试，在测试通过的基础上，在向外围拓展进行测试
-
高频集成
同步软件开发过程，每过一段时间，就对软件进行集成测试，常说的持续集成
系统测试
是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，已发现软件潜在的问题，保证系统正常运行
关注点
- 关注系统本身的使用
- 关注系统与其他相关系统间的连通
- 关注系统在不同使用压力下的表现
- 关注系统在真实使用环境下的表现
验收测试
也称交付测试，针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统
细分
- 用户验收测试 - 一般由开发方交付前自己做的测试
- 运行验收测试 - 从运维层面看系统是否能够正常运行，比如系统上线后备份、容灾
- 合同和规范验收测试
- alpha 测试 - 开发者提供的环境进行的测试，一般由用户来执行
- beta 测试 - 完全脱离开发环境，由用户提供的环境进行测试
按测试手段分类
- 黑盒测试、白盒测试
- 静态测试、动态测试
- 手工测试、自动化测试
黑盒测试
着眼于外部结构，不考虑内部逻辑，一般针对于软件外部的界面、可见的功能来测试，一般是从用户的视角通过不同的数据和事件来驱动系统，通过输出结果来进行判断
优点
- 容易实施，不需要关注内部的实现
- 更贴近用户的使用角度
缺点
- 测试覆盖率比较低，一般只能覆盖到代码量的不到 40%
- 针对黑盒的自动化测试，复用率较低，维护成本较高
黑盒测试主要测试什么
主要（更多）应用于 系统测试 阶段
- 是否有不正确或遗漏的功能
- 在接口上，输入是否能正确的接受，能否输出正确的结果
- 是否有数据结构错误或外部信息（例如数据文件）访问错误
- 性能上是否能够满足要求
黑盒测试的主要设计方法
- 等价类划分法
- 边界值分析法
- 错误推测法
- 因果图法
- 正交实验分析法
- 状态迁移图法
- 流程分析法
白盒测试
测试人员对内部结构是非常了解的，又称为结构化测试或透明盒测试；
白盒测试是通过程序的逻辑结构设计测试用例，用逻辑的覆盖率来衡量测试的完整性
主要的逻辑单位
- 语句
- 条件
- 条件组合
- 分支
- 路径
优点
- 迫使测试人员去仔细思考软件的实现，理解原理
- 可以检测到代码中的每条分支和路径
- 可以揭示隐藏在代码中的错误
- 对代码的测试比较彻底
缺点
- 昂贵 - 因为要做到较高的覆盖率，所以成本高
- 无法检测代码中遗漏的路径和数据敏感性错误
- 不能直接验证需求的正确性
白盒测试的主要测试方法
- 代码检测法
- 静态结构分析法
- 静态质量度量法
- 逻辑覆盖法
- 基本路径测试法
灰盒测试
介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现
静态测试
静态测试是指 无需执行 被测程序，而是通过评审软件文档或代码，度量程序，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率
特点就是，程序是不被运行的，直接看我们的文档或者代码，可以人工也可以通过自动化工具来做，通过静态的检查代码或者文档的测试手段
测试方式
- 互审 - 程序员相互检查相互的代码
- 走查 - 一个小组集体走查程序或文档
- 会议 - 召开会议
动态测试
是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等
手工测试
由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适用针对深度的测试和强调主观判断的测试
常见的：众包测试、探索式测试，都是用手工测试完成的
优点
- 容易发现缺陷
- 容易实施
- 创造性、灵活性
缺点
- 覆盖量化难
- 重复测试效率低
- 不一致性、可靠性低
- 人力资源依赖
自动化测试
使用单独的测试工具软件控制测试的自动化执行以及对于其和结果进行自动检查
常见的：单元测试、接口测试、性能测试等，都是用自动化测试完成的
优点
- 高效率、速度快
- 高复用性
- 覆盖率容易度量
- 准确、可靠
- 不知疲劳
缺点
- 机械、发现缺陷率低
- 一次性投入较大
按测试模式分类
传统的瀑布模型
最早出现的软件开发模型，每一个阶段都是按顺序的向下，到下一个阶段，就像瀑布下落一样
瀑布模型每一个阶段都是以上一个阶段的输出作为下一个阶段的输入
- 项目计划 ——> 需求分析 ——> 软件设计 ——> 程序开发 ——> 软件测试 ——> 集成维护
优点
- 强调需求、设计的作用
- 前一阶段完成后，只需要关注后续阶段
- 为项目提供了按阶段划分的检查点，里程碑清晰
- 文档规范
缺点
- 难以适应需求的频繁变化
- 项目周期后段才能看到成果
- 强制的里程碑、完成时间点
- 文档工作量大
V 模型
- 需求分析 ——> 概要设计 ——> 详细设计 ——> 软件编码 ->
- 验收测试 <—— 系统测试 <—— 集成测试 <—— 单元测试 <-
是瀑布模型的变种，是目前使用最广泛的一种模型，在 V 模型中，明确表明了测试过程的不同级别或者不同阶段，并且描述了这些阶段和开发过程各个阶段的对应关系
局限性是：仅仅把测试过程作为需求分析和编码之后的阶段，所以对于需求分析的测试只有到最后的验收测试才会发现问题
W 模型
也称为 双 V 模型，是对 V 模型的改进模型
增加了软件开发各个阶段同步进行验证和确认的活动，测试时伴随整个开发周期进行，测试的对象也不仅仅是程序，他要对需求和设计都要进行相应的测试，开发和测试是两个并行的流程
W 模型 有利于及时了解项目的测试风险，及早确定应对方案
W 模型 也有其局限性，该模型中，需求、编码、测试仍然是串行的，测试和开发保持着一个线性的关系，只有在上一阶段完成之后才能进入下一阶段
X 模型
针对 V 模型 提出的改进
主要解决交接和频繁集成的周期的问题
敏捷测试
Agile Testing —— 遵循 敏捷宣言 的一种测试实践
敏捷宣言：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户合作 重于 合同谈判
响应变化 重于 遵循计划
- 在以上每对比较中，后者并非完全无价值，但我们更看重前者
敏捷测试的特点
- 强调从客户角度进行测试
- 重点关注迭代测试新功能，不再强调测试阶段
- 尽早测试，不间断的测试，具备条件即测试
- 强调持续反馈
- 预防缺陷重于发现缺陷
敏捷测试 VS 传统测试
| 传统测试 | 敏捷测试 |
|---|---|
| - 测试时质量的最后保护者 | - 开发和测试人员是紧密合作，大家都有责任对软件负责 |
| - 严格的变更管理 | - 变更是可接受的，拥抱变更 |
| - 预先的计划和细节的准备 | - 计划随着进展时常调整 |
| - 重量级文档 | - 只需要绝对必要的文档 |
| - 各阶段测试严格的入口和出口标准 | - 各迭代之间已经没有明显的入口和出口标准 |
| - 更多在回归测试是进行重量级的自动化测试 | - 所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分 |
| - 严格依赖流程执行 | - 流程不再需要严格执行 |
| - 测试团队和开发团队是相对独立的 | - 团队合作是无缝隙合作的 |
基于脚本的测试
Script-based Testing
Scripted Testing (ST)
Exploratory Testing (ET)
基于风险的测试 - RBT
Risk-based Testing
一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型
哪些是风险？
- 质量风险
- 管理风险
- 风险级别 = 风险可能性 x 风险严重度
识别风险
风险要素分 = Sum（单项权重 * 得分）
可能性
- 复杂性
- 时间压力
- 高变更率
- 技能水平
- 地理分散度
严重程度
- 使用频率
- 失效可视性
- 商业损失
- 组织负面影响和损害
- 社会损失和法律责任
基于探索式的测试 - ST
完全抛开测试脚本的测试
它是一种测试风格、思维，而不是一种测试技术
ET 和 ST 使用
- Pure Scripted
- Vague Scripted
- Fragmentary test cases
- Charters
- Roles
- Freestyle ET
ST vs ET
| ST | ET |
|---|---|
| - 系统性强 | - 自由灵活 |
| - 容易管理、控制 | - 和 ST 是互补的 |
| - 设计在先，执行在后 | - 执行和设计（思考）并行 |
| - 主要是验证自己的思路 | - 不断和系统交互，带着问题测试 |
| - 可预见性 | - 学习的过程 |
探索式测试的优点
- 更能激发测试人员的创造性和工作乐趣
- 增加了发现新的或者较深入 Bug 的可能性
- 可以在较短时间内找到更多 Bug 以及对 SUT 做出一个快速的评估
- 有利于更加有效地实施自动化
- 更加适用于敏捷项目
- 减少了再简单、繁复上用例的无谓编写时间
探索式测试的缺点
- 测试管理上有局限性，较难协调和控制
- 对于 Bug 的重复利用和重现上作用有限
- 对测试人员的测试技能和业务知识深度依赖较大
- 只有在 SUT 已完全可用的前提下才更有作用
- ET 的生产率很难定义
- ET 本身较难进行自动化
执行探索式测试
- Know You Mession
- Learning Session
- Coverage Session
- Deep Session
- Close Session
基于模型的测试 - 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).
按测试类型分类
功能测试
根据产品特性、操作描述和用户反感，测试一个产品的特性和可操作性为已确定他们满足设计需求
针对的问题
- 功能错误或遗漏
- 界面问题
- 性能错误
- 数据及访问错误
- 初始化及终止错误
功能测试工具
- QTP winrunner
- silkTest
- Rational robot
- selenium
- Watir
- 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 Top 10
- Test Guide
安全测试工具
- Appscan
- Webinspect
- Nessus
- Nmap
- MetaSploit
- WebScarab
- Fortify
- W3AF
兼容性测试
- 软件本身的兼容性 - 向后兼容
- 不同平台下的兼容性 - 运行在多个平台
- 软件对运行设备的兼容性 - 32位、64位、手机、电视盒子
- 软件互操作性 - 软件之间的联动
浏览器内核
- Trident 4 - 6 —— IE 6 - 8 ，9，10
- Gecko —— FireFox
- WebKit —— Safari、Chrome
- presto —— Opera
浏览器兼容性测试工具
- BrowserShots
- Browser Sandbox
- Google 浏览器兼容测试插件
文档测试
针对软件产品的交付品，配套的文档类部件的测试
如：用户手册、使用说明、用户帮助文档等
文档测试关注要点
- 完整性
- 正确性
- 一致性
- 易理解性
- 易浏览性
可靠性测试
- 软件可靠性
- 硬件可靠性
易用性测试
易用性测试是指测试用户使用软件时是否感觉方便，能否保证用户使用体验的测试类型
一般针对：用户界面、用户交互、网站布局
本地化测试
针对软件的本地化版本实施的针对性测试
主要测试内容
- 语言、书写习惯
- 时区、日期格式、货币
- 当地风俗、法律法规
- 政治敏感内容
部署测试
也称为安装测试，主要验证系统部署过程，并确保软件经过安装测试后可以正常使用
主要测试内容
- 在不同环境下的部署验证
- 参照部署文档执行，过程的合理、正确性
- 基础数据
无障碍测试
Accessibility Test 也称为访问性测试
是指软件需要提供便于特殊人群使用的功能，包括视障、听障、老年人、身体残疾用户等，无障碍测试则是针对这部分功能的测试
其他的一些测试类型概念
回归测试
软件功能修改后，对软件进行重新测试以确认修改没有引入新的错误或导致其他部分产生错误
回归测试的重心在 关键模块 和 重点功能 组件
软件研发周期中会进行多次回归测试，且尽量实现自动化
Monkey 测试
Monkey 测试，也称搞怪测试
就是用一些随机、稀奇古怪的方式来操作软件，以测试系统的健壮性和稳定性
冒烟测试
来自于硬件板卡验证术语
软件上则用于确认代码中的更改会按照预期运行，且不会破坏整个版本的稳定性
“每日构建”中用冒烟测试来确认合入的代码没有影响主要功能的正常
A/B 测试
多用于互联网行业，通过为页面提供 2个版本给用户使用并记录相关的用户行为数据，来确定优化设计的一种测试方案
A/B 测试实施要点
- 多个方案并行
- 每次测试仅改动一个变量
- 按照某种规则进行优胜劣汰
A/B 测试工具
- Google Analytics Content Experiments
- Visual Website Optimizer