前言
每个系统的成型，上线都离不开测试，这段时间陆陆续续的学习测试，在这里总结一番；作为学习交流之用；
正文
软件测试概述
软件测试的历史：
什么是软件测试：
早期定义：软件测试是对程序能够按预期运行建立起一种信心。
经典定义：测试是为了发现错误而执行程序的过程。
IEEE定义（ISO/IEC/IEEE 29119）：使用人工或者自动的手段来运行或测量软件系统的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。
软件测试≠程序测试
五大要素和两个目标：
五大要素有：质量、人员、资源、流程、技术。
其中最主要的是软件质量，其他四个要素都是为质量服务的。
其次是人员，决定了技术，资源，流程，以及配置和使用。
技术包含了：软件测试技术、软件测试方法、使用的工具。技术是手段。
流程：测试计划，测试用例，测试执行，测试报告。有一些进入进出的标准（规范性，对软件测试做一个规范的要求）。
资源：测试所需要的硬件设备、网络环境、测试设备、测试时间（周期）。
注意：人不是资源。
目标：
①提升测试覆盖率-> 能够有效的保证软件的质量
②提升测试效率->能够使我们更好地完成软件测试
软件测试所遵循的原则
一、测试显示缺陷的存在，但不能证明系统不存在缺陷。
经过软件测试，可以发现软件中的故障；但是经过软件测试，不能保证软件就没有故障了。
二、穷尽测试是不可能的，应设定及时终止的条件。
三、测试应该尽早进行
四、缺陷具备群集特性
越是发现问题多的模块，越是需要重点测试的对象
五、测试的杀虫剂悖论
在测试中，如果采用同样的测试用例，同样的测试方法。多次重复的测试某一个模块，最后就不能再发现新的缺陷。所以说，测试用例和测试方法应该不定期的评审修改，并且增加不同的测试方法和用例来测试不同的部分，从而更多的发现软件的缺陷。
六、测试的二八原则
测试时间和资源往往是有限的，要找出所有的缺陷是不可能的，这时我们需要遵循二八原则。
把80%的时间或者资源用在20%的重点模块上，重点测试模块中20%的重要模块。来达到测试效率和资源配置的最佳的比例。
七、测试活动依赖于测试背景
针对不同的测试背景针对的活动是不同的，比如：电信级的软件对性能、大并发量的访问会有更高的要求。而金融，银行系统相关的软件，对安全性能要求更高。
软件测试阶段，手段，模式
按测试阶段来分类
单元测试、继承测试、系统测试、验收测试
单元测试
什么是单元测试
对软件中的最小可测试单元进行检查和验证
单元测试的原则：
1.尽可能保证各个测试用例是相互独立的；
2.一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求。
单元测试的益处：
1.能尽早发现缺陷；收益最高；
2.有利于重构；
3.简化集成；
4.文档；
5.用于设计；
单元测试的限制
1.不可能覆盖所有的执行路径，所以不可能保证捕捉到所有路径的错误；
2.每一行代码，一般需要3-5行测试代码才能完成单元测试。所以存在投入和产出的一个平衡；
单元测试框架：
Xunit，JUnit，nunit，PPUnit，CppUnit
集成测试：
定义:
在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统过程中各部分工作是否达到或实现相应技术指标及要求的活动
集成测试的主要实施方案
1.Big Bang 全部完成，测试
2.自顶向下
3.自底向上 从最低层测试，逐步组装测试；（常用测试）
4.核心系统集成
5.高频集成
集成测试&单元测试
1.测试的对象不同；
2.测试的一举不同；
3.测试的方法不同；
系统测试
定义：是将经过集成测试的软件，作为计算机系统的一个部分，系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。
关注点
关注系统本身的使用
关注系统与其他相关系统间的连通
关注系统在不同使用压力下的表现
关注系统在真实使用环境下的表现
系统测试&集成测试
测试环境：
集成测试：由通过了单元测试的各个模块所集成起来的构件
系统测试：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统；
测试时间：
集成测试介于单元测试和系统测试之间测试
系统测试在集成测试之后
测试内容：
集成测试：各个单元模块之间的接口
系统测试：整个系统的功能和性能
测试角度：
集成测试：偏向于技术角度的验证
系统测试：偏向于业务角度的验证
验收测试
定义：也称交付测试，针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户、或其他授权机构决定是否接受系统。
细分
用户验收测试
运行验收测试
合同和规范验收测试
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传统测试
探索式测试（ET）
完全抛开测试脚本的测试
它是一种测试风格、思维而不是一种技术
优点：
更能激发测试人员的创造性和工作乐趣
增加了发现新的或较深入Bug的可能性
在较短时间内找到更多Bug以及对SUT作一个快速的评估
有利于更加有效地实施自动化
更加适用于敏捷项目
减少了在简单、繁复上用例的无谓编写时间
测试管理上有局限性，较难协调和控制
对于Bug的重复利用和重现上作用有限
对测试人员的测试技能和业务知识深度依赖较大
只有在SUT已完全可用的前提下才更有作用
ET的生产率很难定义
ET本身较难进行自动化
局部探索式测试
输入、状态、代码路径、用户数据、执行环境
全局探索式测试
探索式测试的流程
基于风险的测试-RBT
Risk-based Testing
一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评估的软件测试类型
那些是风险？
质量风险、管理风险
风险级别=风险可能性X风险严重度
未完待续。。