软件测试的分类

软件测试的分类

按测试阶段来分类

单元测试，集成测试，系统测试，验收测试

单元测试：
队软件中的最小可测试单元进行检查和验证。
单元测试的原则：
1.尽可能保证各个测试用例是互相独立的。
比如测试某个class方法，方法里不要调用另外的方法。否则出错的时候不知道是测试的class出错还是调用的方法出错。
2.一般由代码的开发人员来实施，用以检验所开发的代码功能复合自己的设计要求。

单元测试的益处：
1.能尽早发现缺陷
2.有利于重构
3.简化集成
4.文档 （代码即文档）
5.用于设计

单元测试的限制：
1.不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误
2.每一行代码，一半需要3~5行测试代码才能完成单元测试。所以存在投入和长处的一个平衡。

单元测试框架:
Xunit
JUnit
nunit
PHPunit
CPPunit

集成测试

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

集成测试的主要实施方案
1.Big Bang
把大部分的模块都耦合起来，形成一个完整的系统或系统的主要组成部分，然后再进行测试。即把所有的东西都组装起来，然后测试。
2.自顶向下
这是一个递增的组装软件的方法，一般从主程序开始，延控制层逐层向下集成，然后通过这种方式逐层测试，覆盖到所有模块
3.自底向上
从程序模块的最底层模块开始，逐层向上组装，逐层测试
4.核心系统集成
5.高频集成

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

系统测试&集成测试
系统测试的关注点：
关注系统本身的使用
关注系统与其他相关系统间的联通
关注系统在不同使用压力下的表现
关注系统在真实使用环境下的表现

测试时间：
集成测试介于单元测试和系统测试之间测试
系统测试在集成测试之后

测试内容
集成测试：各个单元模块之间的接口
系统测试：整个系统的功能和性能

测试角度：
集成测试：偏于技术角度的验证
系统测试：偏于业务角度的验证

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

细分：
用户验收测试
运行验收测试
合同和规范验收测试
alpha测试
Beta测试

按测试手段来分类
黑盒测试，白盒测试 （按照测试时对象的可见度）
静态测试，动态测试 （根据状态）
手工测试，自动化测试 （根据测试执行的方式）

黑盒测试
在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

黑盒测试的优缺点
优点
1.容易实施，不需要关注内部的实现
2.更贴近用户的使用角度
缺点
1.测试覆盖率较低，一般只能覆盖到代码量的不到40%
2.针对黑盒的自动化测试，复用率较低，维护成本较高

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

黑盒测试的主要涉及方法
等价类划分法
边界值分析法
错误推测法
因果图法
正交试验分析法
状态迁移图法
流程分析法

白盒测试（结构测试，透明盒测试）
针对程序的逻辑结构设计测试用例

主要的逻辑单位
语句，条件，条件组合，分支，路径

白盒测试的优缺点
优点
1.迫使测试人员去仔细思考软件的实现，理解原理
2.可以检测代码中的每条分支和路径
3.揭示隐藏在代码中的错误
4.对代码的测试比较彻底
缺点
1.昂贵
2.无法检测代码中遗漏的路径和数据敏感性错误
3.不能直接验证需求的正确性

白盒测试的主要测试方法
代码检测法
静态结构分析法
静态质量度量发
逻辑覆盖发
基本路径测试法

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

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

方式
互审>走查>会议

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

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

自动化测试
使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。
比如 单元测试，接口测试，性能测试等基本都是用自动化测试来做。

手工测试VS自动化测试
手工测试-优点
易发现缺陷
容易实施
创造性，灵活性
手工测试-缺点
覆盖量化难
重复测试效率低
不一致性，可靠性低
人力资源依赖

自动化测试-优点
高效率，速度快
高复用性
覆盖率容易度量
准确，可靠
不知疲劳
自动化测试-缺点
机械，发现缺陷率低
一次性投入较大

按测试模式来分类
瀑布模型，敏捷测试，基于脚本的测试，基于风险的测试，探索式测试等。

传统的瀑布模型
项目计划-需求分析-软件设计-程序开发-软件测试-集成维护
瀑布模型的优缺点
优点
强调需求，设计的作用
前一阶段完成后，只需关注后续阶段
为项目提供了按阶段划分的检查点，里程牌清晰
文档规范
缺点
难以适应需求的频繁变化
项目周期后段才能看到成果
强制的里程牌，完成时间点
文档工作量大

V模型
W模型
X模型
H模型

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

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

敏捷测试VS传统测试
传统测试：
测试是质量的最后保护着
严格的变更管理
预先的计划和细节的准备
重量级文档
各阶段测试严格的入口和出口标准
更多在回归测试时进行重量级的自动化测试
严格依赖流程执行
测试团队和开发团队是相对独立的

敏捷测试：
开发和测试人员是紧密合作，大家都有责任对软件负责
计划随着进展时长调整
只需要绝对必要的文档
各迭代之间已经没有明显的入口和出口标准
所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分
流程不在需要严格执行
团队合作是无缝隙合作

基于脚本的测试-SBT

探索式测试（ET）
完全抛开测试脚本的测试
它是一种测试风格，思维而不是一种测试技术

ＳＴ　ＶＳ　ＥＴ
ＳＴ：
系统性强
容易管理，控制
设计在先，执行在后
主要是验证自己的思路
可预见性

ET：
自由灵活
和ST是互补的
执行和设计（思考）并行
不断和系统交互，带着问题测试
吻戏的过程

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

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

基于风险的测试-RBT
一种基于对软件失效的风险评估并以此知道测试计划，设计，执行，结果评价的软件测试类型

那些是风险？
质量风险
管理风险
风险级别

识别风险
可能性：
复杂性
时间压力
高变更率
技能水平
地理分散度
严重程度：
使用频率
失效可视性
商业损失
组织负面影响和损害
社会损失和法律责任

功能测试
根据产品特性，操作描述和用户方案，测试一个产品的特性和可操作行为以确定他们满足设计需求
针对的问题：
功能错误或遗漏，界面问题，性能错误，数据及访问错误，初始化及终止错误
功能测试工具：
商业：QTP，winrunner，silkTest，Rational，robot
开源：selenium，Watir，Sikuli

性能测试
包括 负载测试，压力测试，稳定性测试
性能指标：并发用户数VU，美妙事务数TPS，系统响应时间，设备性能
性能测试工具：
LoadRunner，Silkperformer,Jmeter,WebLoad,Apache Bench,LoadUI

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

安全测试：
对软件产品进行测试以确保其符合产品安全需求和质量标准
渗透测试：
通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试
工具：Appscan，webinspect，nessus,Nmap,Metasploit,webScarab,Fortify,W3AF

兼容性测试：
软件本身的兼容性，不同平台下的兼容性，软件对运行设备的兼容性，软件互操作性，
浏览器内核 兼容
工具：BrowserShots，Browser Sandbox

文档测试
针对软件产品的交付品，配套的文档类部件的测试，如用户手册，使用说明，用户帮助文档等。
文档测试关注要点：
完整性，正确性，一致性，易理解性，易浏览性

可靠性测试：软件可靠性，硬件可靠性

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

本地化测试：
针对软件的本地化版本实施的针对性测试
主要测试内容：
语言，书写习惯
时区，日期格式，货币
当地风俗，法律法规
政治敏感内容

部署测试：
也称安装测试，主要验证系统部署过程，并确保软件经过安装测试后可以正常使用。
主要测试内容：
在不同环境下的部署验证
参数部署文档执行，过程的合理，正确性
基础数据

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