一.按照测试阶段分类：单元测试、集成测试、系统测试、验收测试1.单元测试（模块测试）：
（1）定义
对软件中的最小的可测试单元进行检查和验证的过程（单元：根据实际情况判定）
（2）原则
a.尽可能保证各个测试用例是相互独立的（无依赖）
b.一般由代码的开发人员来实施，用以检验所开发的代码功能是否符合设计要求
（3）单元测试的优点
a.尽早发现缺陷（敏捷研发强调TDD测试驱动开发，先编写单元测试代码，再编写功能代码）
b.为代码的重构提供保障，快速识别重构时出现问题的点
c.简化集成（单元测试保证最小单元模块的稳定性、正确性，为集成测试奠定了基础）
d.减少文档的修改
e.用于设计
f.具有回归性，避免代码出现回归
（4）.单元测试的限制
a.不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误
b.每一行的功能代码需要3~5行的测试代码才能完成单元测试，所以存在投入和产出的平衡
单元测试框架：XUnit（JUnit、nunit、PHPUnit、Cppunit）
2.集成测试
（1）定义
在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程 中各部分工作是否达到或实现相应技术指标及要求的活动（单元测试的基础上，针对已经完成单元测试模块，组装成更高级的模块和子系统，针对子系统进行集成，测试对象是已经经过单元测试的单元模块之间的接口）
（2）实施方案（集成方法）
a.Big Bang
b.自顶向下
c.自底向上
d.核心系统集成
e.高频集成
集成测试与单元测试的区别：测试的对象、依据、方法
3.系统测试
（1）定义
将经过集成测试的软件作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统正常运行。（单元测试、集成测试多在模拟环境下运行，系统测试则在真实运行环境中来做，需要功能测试、性能测试、安全测试、稳定性测试等多种类型的测试）
（2）关注点
a.关注系统本身的使用
b.关注系统与其他相关系统间的连通性
c.关注系统在不同使用压力下的表现
d.关注系统在真是使用环境下的表现
（3）系统测试与集成测试的区别：
a.测试对象（集成测试：由通过了单元测试的各个末班所集成起来的构件
系统测试：除软件外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统）
b.测试时间：集成测试结余单元测试和系统测试之间测试
系统测试在集成测试之后
c.测试内容：集成测试：各个单元模块之间的接口
系统测试：整个系统完整的功能和性能
d.测试角度：集成测试：偏于技术角度的验证
系统测试：偏于业务角度的验证
4.验收测试
（1）定义
也称交付测试。针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权机构决定是否接受系统
（2）分为：用户验收测试、运行验收测试（从运维角度）、合同和规范验收测试、alpha测试（在开发者提供的场所或环境中运行，一般由用户执行）、Beta测试（脱离开发者环境，在用户提供的场所或环境下进行测试）、release版本 （正式的可供交付的版本）、（敏捷研发理论里一种验收测试：验收测试驱动开发）
二.按照测试的手段分类：黑盒测试、白盒测试、静态测试、动态测试、手工测试、自动化测试
1.黑盒测试：（也称功能测试）
（1）定义
不考虑程序内部结构，检查程序是否满足需求规格说明书的规定
（2）优点
a.容易实施，不需要关注内部的实现
b.更贴近用户的使用角度
（3）缺点
a.测试覆盖率较低，一般只能覆盖到代码量的不到40%
b.针对黑盒的自动化测试，复用率较低，维护成本较高
（4）黑盒测试主要测什么
a.是否有不正确或遗漏的功能
b.在接口上，输入是否能正确的接受？能否输出正确的结果？
c.是否有数据结构错误或外部信息（例如数据文件）访问错误？
d.性能是否能够满足要求
（5）黑盒测试的主要设计方法：
（等价类划分法、边界值分析法、错误推测法、因果图法、正交试验分析法、状态迁移图法、流程分析法）
a.等价类划分法：针对程序输入等价的归成一类，形成若干典型的代表性的输入，通过典型的数据进行测试用例的设计
b. 边界值分析法：特殊的等价类划分，关注的是边界条件（数据的区间）
c.错误推测法：基于经验或者直觉来判断程序中可能出现错误的地方从而针对性的设计用例的方法（特殊字符、文件超载）
d.因果图法：程序需求规格说明书中，针对每一种输入和输出，在因果图中会把输入和输出看做原因和结果，对输入和输出付以特定的标识符，将这些情况形成因果图，最终根据规格语义的说明形成判定表，根据判定表，编写测试用例
e. 正交试验分析法：通过正交性，从一组数据中筛选出典型的有代表性的数据的设计方法，主要用于筛选输入数据，然后来设计测试用例的输入的输出
f.状态迁移图法：通过梳理软件功能点里的状态迁移关系来设计测试用例（状态迁移：例审批状态），根据状态关系设计测试用例
g. 流程分析法：通过梳理程序的逻辑执行的路径，来设计测试用例
2.白盒测试
（1）定义
内部结构了解，结构化测试/透明盒测试，针对程序的逻辑结构设计测试用例，用逻辑的覆盖率来衡量测试的完整性，
（2）主要的逻辑单位：语句、条件、条件组合、分支、路径，不通的逻辑单位有不同的覆盖方法判定和条件的组合覆盖
a.语句覆盖：测试用例设计出来执行以后，会保证程序的每条语句至少执行一次
b.判定覆盖：保证每个分支至少执行一次
c.条件覆盖：覆盖到条件的表达式，所有的表达式至少计算一次
d.条件组合：覆盖所有各种不同条件的组合情况
e.路径覆盖：程序当中每一条可能的路径会至少执行一次（分支是路径的一部分）
f.条件和判定的组合覆盖
（3）优点
a.迫使测试人员去仔细思考软件的实现，理解原理
b.可以检测代码中的每条分支和路径（覆盖率）
c.解释隐藏在代码中的错误
d.对代码的测试比较彻底
（4）缺点
a.昂贵（覆盖率高，成本高）
b.无法检测代码中遗漏的路径和数据敏感性错误
c.不直接验证需求的正确性
（5）主要测试方法
a.代码检测法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法
b.代码检测法：包括多面检查、代码审查、走查，主要检查代码和设计的执行，对代码本身检查
c. 静态结构分析法：测试者通过使用测试工具来分析源代码的系统结构、数据结构、内部的控制逻辑，通过这样的内部 结构的分析来设计测试用例
d.静态质量度量法：根据标准的质量模型，如ISO的质量标准作为基础，然后构造质量的度量模型用于评估软件的各个方面的要素
e.逻辑覆盖法：6种主要逻辑覆盖
f. 基本路径测试法：白盒测试中主要的测试方法，在程序控制流图的基础上通过分析控制构造的圈复杂度，到导出基本可执行的路径的集合，进而设计测试用例的方法
3.灰盒测试
（1）定义
介于黑、白盒测试之间的、关注输出对于输入的正确性，同时也关注内部表现（结合了白盒测试、黑盒测试的要素，更多的是在系统组件层评价软件的应用）
4.静态测试
（1） 定义
无需执行被测程序、而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率
（2）方式
互审、走查、会议（不正式到正式）
5.动态测试
（1）定义
通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等（黑盒测试中多为动态测试法，白盒测试中代码检查法、静态分析法为静态测试）
6.手工测试：
（1）定义
由专门的测试人员从用户的视角来验证软件是否满足设计要求的行为，更适合针对深度的测试和强调主观判断的测试（例众包测试、探索式测试）
7.自动化测试
（1）定义
使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动化检查（强调利用第三方的测试工具来控制自动的执行及对预期结果的检查）
单元测试、接口测试、性能测试等更多的的利用自动化测试
------------------------------------------------------------------------------------------------------------------------------------------------------
手工测试与自动糊测试的区别：
手工测试：
优点：易于发现缺陷、容易实施、创造性、灵活性、覆盖量化难
缺点：重复测试效率低、不一致性、可靠性低、依赖人力资源
自动化测试：
优点：高效率、速度快、高复用性、覆盖率容易度量、准确、可靠
缺点：机械、发现缺陷率低、一次性投入大
---------------------------------------------------------------------------------------------------------------------------------------------------------
三.按照测试模式分类：
瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等
1.传统的瀑布模型
（1）过程
项目计划---需求分析----软件设计---程序开发----软件测试-----集成维护
（每个阶段都是以上一个阶段的输出作为下一个阶段的输入）
a.项目计划：制定项目总体的研发计划，确定主要里程碑节点，此节点输出项目计划书，
b.需求分析：明确用户的需求定义，并对定义进行清晰的描述，是充分理解客户需求、描述产品功能的重要阶段，输出产品的需求规格书
c.软件设计：根据需求的定义，确定产品实现的方案，包括定义软件、硬件的结构，组建模块的实现方法，接口、界面、数据如何进行组织，此阶段输出概要设计、详细设计、多分设计说明书
d.程序开发：开发团队根据需求和设计具体的实现产品，根据编程规范，构建各类的组建模块，输出产品版本，
e.软件测试：独立的测试小组或QA团队评估产品是否满足需求，输出测试结果、测试报告
f.集成维护：产品经过测试后交付给用户，根据用户的使用情况对产品进行维护及必要的修改、升级
（2）优点
强调了需求、设计的作用；前一阶段完成后，只需关注后续阶段；为项目提供了按阶段划分检查点，里程碑清晰；文档规范
（3）缺点
难以适应需求的频繁变化；项目周期后段才能看到结果（增加了风险）；强制的里程碑、完成时间点（适用能力差）；文档工作量大
2.V模型：瀑布模型的变种
3.W模型（双V模型）
测试伴随整个开发周期，基本开发测试时两个并行的过程，有利于尽早的发现问题，有利于及时了解项目风险，及早的制定相应的应对方案，加快项目的进度，局限性:需求、设计、编码仍串行，测试、开发保持线性的先后关系，上一阶段完成后才能进行下一阶段，所以不支持迭代开发，
4.X模型
对V模型的改进，主要解决交接及频繁集成的周期的问题，左边描述的是对单独的程序片段所进行的相互分离的编码和测试，然后进行频繁交接，在集成，最终形成可执行程序，再对集成的程序进行测试，
5.H模型
6.敏捷测试（Agile Testing）
遵循敏捷宣言的一种测试实践
（1）敏捷宣言：
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划（后者并非全无价值，但更看重前者）
（2） 特点
a.强调从客户角度进行测试
b.重点关注迭代测试新功能，不再强调测试阶段（传统测试中严格的阶段划分敏捷不强调）
c.尽早测试，不间断测试，具备条件即测试
d.强调持续反馈（结果、过程、发现的问题都要快速的通知到相关的人员）
e.预防缺陷重于发现缺陷（给研发提出建设性意见、质量改正的建议，全方位参与到软件研发的各个层面来提升整个团队的工作效率，保证产品的质量）
敏捷测试VS传统的测试：
传统测试：测试是质量的最后保护者、严格变更管理、预先的计划和细节的准备、质量级文档；各个阶段测试严格的入口和出口标准；更多在回归测试时进行重量级的自动化测试；严格依赖流程执行；测试团队和开发团队是相互独立的
敏捷测试：开发和测试人员时紧密合作的，大家都有责任对软件负责；变更是可接受的，拥抱变更；计划随着进展时常调整；只需要绝对必要的文档；各迭代之间已经没有明显的入口和出口标准；所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分；流程不再需要严格执行；团队合作是无缝隙合作
（规则就是用来被打破的，注重测试结果，持续不断质量反馈的过程，更加注重团队的相关角色及时知晓开发过程中的质量现状并及时改正）
四. 按照软件测试类型
（功能测试、性能测试、部署测试、文档测试、安全测试、兼容性测试、易用性测试、本地化测试、无障碍测试、可靠性测试）
1.功能测试
（1）概念
软件测试中主要的一种测试类型，根据产品的特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定他们满足设计需求
（2） 针对的问题（功能测试关注的问题）
功能错误或者遗漏、界面问题、性能错误（软件本身的处理性能，大数据量的加载）、数据及访问错误初始化及终止错误
（3）功能测试工具
a.商用功能自动化测试工具：QTP（web应用）、winrunner系列（QTP的前身，主要在桌面化的软件上面，QTP主要是web应用类的系统上自动化的工具）、silkTest、Rational robot
b.开源自动化测试工具：selenium（流行于敏捷）、Watir（基于web自动化）、Sikuli（基于屏幕截图，测试脚本基本由截图构成）
2.性能测试
（1）概念
验证软件系统的性能可以满足需求规格给定的指标要求，（负载测试、压力测试、稳定性测试等衍生概念）
（2）测试内容
a.负载测试：在测试过程中逐步的增加负载，并且记录下北侧系统相应的性能表现，最终确定出系统在正常的指标范围下的最大的负载
b.压力测试：系统在极限情况下的压力测试，确定系统在什么样的负载压力下会导致系统的失效，确定出系统所能承受的最大极限
c.稳定性测试：稍大于正常业务量的负载，对系统进行持续的长时间的测试，以确定系统在较长运行时间的情况下系统的稳定性
（3）性能指标
a.并发用户数vu（同一时间访问系统的用户数）
b.每秒事物数TPS（每秒钟系统能够处理的业务数）
c.系统响应时间（系统响应请求所耗费的时间）
d.设备性能（运行系统的服务器相关资源的性能，如CPU、内存的使用情况、磁盘IO情况、网络IO情况）
（4）性能测试工具：loadrunner、silkperformer、jmeter、webload、Apache bench（负载生成工具）、loadUI（主要针对http类的接口的性能测试）
（5）静态性能评估
开发web应用时，基于一系列web应用页面性能优化的最佳时间对web应用的页面进行静态分析，并给出评估结果的性能分析方法
两种评估标准：YSlow、PageSpeed、
（6）应用性能管理
APM（Application performance management）提供对系统的实时监控以实现性能管理、故障管理的解决方案 （APM产品：听云）
3.安全测试
（1）概念
对软件产品进行测试以确保其符合产品安全需求和质量标准（着重防御、在防御面上考虑安全、较渗透测试难）
（2）渗透测试
模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试（着重点攻击攻破系统，证明系统存在问题；选择点攻破系统）
OWASP:Open Web Application Security Project（www.owasp.org）关注：top 10 、 test guide
（3）安全测试工具
Appscan（针对web应用的漏洞扫描工具）
Webinspect、Nessus（主要针对服务器、主机类的漏洞检查工具，有免费版本）
Namp（著名的端口嗅探的工具，通过扫描主机看开放了哪些端口可以进行下一步的攻击）
MetaSploit（非常著名的攻击框架包含有大量的插件，可通过此框架对目标系统进行检测、渗透测试）
webscarab（基于代理劫持的分析进行攻击路径的检测）
fortify（白盒测试工具，针对开发的源代码的静态的分析，分析出源码中可能存在的问题）
W3AF（开源，主要在针对web应用）
4.兼容性测试
（1）兼容性分类
软件本身的兼容性（新开发的版本对历史版本功能及配置、相应的数据进行兼容）
不同平台下的兼容（软件在多个平台上运行）
软件对运行设备的兼容性（软件在不通类型设备上运行）
软件互操作性
浏览器兼容性
（2）浏览器兼容性测试工具
BrowserShots（browsershots.org基于真实浏览器进行截图比对的工具）
Browser Sandbox（通过不通插件实现浏览器模拟测试）
Google浏览器兼容测试插件（http://www.w3help.org/）（从页面代码层面对浏览器兼容性进行分析）
5.文档测试
（1）概念
针对软件产品的交付品，配套的文档类部件的测试。如用户手册、使用说明、用户帮助文档等
（2）文档测试关注点
完整性、正确性、一致性、易理解性、易浏览性
6.可靠性测试
软件系统在规定的时间内或规定的条件下能够完成规定功能的能力
7.易用性测试
指用户使用软件时是否感觉方便，是否能保证用户使用体验的测试类型（针对UI)
8.部署测试
主要验证系统部署过程，并确保软件经过安装测试后可以正常使用
9.无障碍测试
Accessibility Test 也称可访问性测试，是指软件需要提供便于特殊人群使用的功能，包括视障、听障、老年人、身体残疾用户等，无障碍测试则是针对这部分功能的测试
五.其他测试
1.基于脚本的测试（SBT）
（Script-based Testing）先做测试设计，再执行测试（script：手工测试中指测试用例，自动化测试中指自动化测试脚本），遵照测试计划，属于传统的测试
2.脚本测试（Scripted Testing）ST
3.探索式测试（Exploratory Testing）ET
（1）定义
探索式测试，完全抛开测试脚本，是一种测试风格、思维而不是一种测试技术
ET 与 ST 互补
ST：系统性强；容易管理、控制；设计在先、执行在后；主要是验证自己的思路；可预见性
ET：自由灵活；和ST互补；执行和设计（思考）并行；不断和系统交互，带着问题测试；对系统深入学习的过程
（2）优点
更能激发测试人员的创造性和工作乐趣，
增加了发现新的或较深入BUG的可能性，
在较短的时间内找到更多的bug以及对SUT（software and test） 做一个快速的评估 ，
有利于更加有效的实施自动化，
更加适用于敏捷项目，
减少了在简单、繁复上用例的无谓编写时间，
（3） 缺点
测试管理上有局限性，较难协调和控制
对于bug的重复利用和重现上作用有限，
对测试人员的测试技能和业务知识深度依赖较大，
只有在SUT（被测系统）已完全可用的前提下才更有作用，
ET的生产率很难定义
ET难以进行自动化，更多靠创造性技能来完成
（4）分类
局部探索式测试：从被测系统的五大要素（输入、状态、代码路径、用户数据、执行环境）着手
全部探索式测试：漫游测试法（商业区、旅馆区、历史区、旅游区、娱乐区、破旧区）
4.基于风险的测试（Risk-based Testing）
（1）概念
一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型
（2） 风险有哪些
a. 质量风险：被测系统质量问题（软件的功能、易用性、性能、软件功能的缺失、数据转换导致的问题等），
b.管理风险：人员的技能、项目人力不足，测试环境不具备，被测系统的需求不清晰，被测系统关联的第三方的系统有问题无法进行联调，
（3）具体的风险程度可以用风险级别描述：风险级别=风险的可能性*风险的严重度
识别风险可能性（复杂性、时间压力、高变更率、技能水平、地理分散度）
严重程度（使用频率、失效可视性、商业损失、组织负面影响和损害、社会损失和法律责任）
（4） RBT：测试工作量与风险关系、质量信心与测试完成率关系
5. 回归测试
软件功能修改后，对软件进行重新测试以确认修改没有引入新的错误或导致其他部分产生错误，测试重点在关键模块、重点功能组件
6. 冒烟测试
来自于硬件板卡的验证术语，软件上则用于确认代码中的更改是否会按照预期运行，且不会破坏整个版本的稳定性（重点在全流程）
“每日构建”中用冒烟测试来确认合入的代码没有影响主要功能的正常
的版本后，通过嵌入分析脚本就可以收集到一系列的分析数据）
7.Alpha 测试
在公司内部系统开发接近完成时对软件的测试，测试后仍然会有少量的设计变更。 α测试时，开发者坐在用户旁边，随时记录用户发现的问题
8.Beta 测试
当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。 β测试时开发者不在测试现场，故是在开发者无法控制的环境下进行的测试，通常是由软件开发者向用户散发β版软件，然后
收集用户的意见