整理不易，如果有帮助，还望点个♥
第二章 黑盒测试
黑盒测试的优点：
1.人员独立，测试人员不用懂代码
2.详细需求说明完成后便可以进行，做到了“早”，“勤”
3.角度不同，站在用户的角度测试，使结果更让人接受
划分等价类
分合理等价类和不合理等价类
来一个例子
设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定
日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检
查功能"。（不考虑2月的问题）
边界值分析：
- 不是健壮性测试(要合理覆盖正确和错误的测试)
测试值都在合理范围内部边界 - 边界值分析是对等价类划分的一个补充。输入输出的等价类的边界是着重测试的情况
- 基于单缺陷假设：
由于一个变量引起的错误。，说白了不考虑变量间相互关系 - eg:
1 <= a <= 200,测试取{1，2，100，199，200 }
等价类和边界值都是检验独立的变量，说白了变量之间相互独立
决策表：
- 决策表法被称为“最严格、最具有逻辑性”的黑盒测试方法，能够复杂逻辑关系和多条件组合情况表达的较为明确。适用于：输入输出较多且相互制约条件较多的问题。
- 四部分：由条件桩、动作桩、条件项、动作项四个部分组成
条件桩是指问题中的限制条件；
动作桩是指要执行的操作；
条件项其中条件桩中各个条件组合；
动作项是一个条件组合的特定取值后相应要执行的动作； - 规则合并（判定表的简化）:
有两条或多条规则具有相同动作且他们的条件项之间存在可化简关系就可以将规则合并。
那么，什么是可化简关系？
即条件桩中仅有一个条件的值不一样，而执行的动作却是一致的。 - 决策表的冗余
- 扩展条目决策表：非此即彼，等价类划分的条件数各自相乘
决策表创建步骤
例子
因果图
因果关系：
约束：
判定表：
- 能用图解决的方法，肯定能用表解决
- 因果：4种 约束：5种
单因子测试
正交测试
场景测试 scenario testing
- 测试有复杂性
- 组成部分：基本流 备选流
FSM 测试
有限状态机测试
第三单元 白盒测试
白盒测试分为静态测试和动态测试。
静态白盒测试方法：代码检查法、静态结构分析法、静态质量度量法等。
动态白盒测试是基于覆盖的测试，尽可能覆盖程序的结构特性和逻辑路径。
白盒测试主要用于单元测试。
这就是我们在白盒测试的时候也不能进行穷举测试的原因？
因为即使是每条路径都测试了仍然可能有错误。
1、不能查出程序违反了设计规范，及程序本身是个错误程序。
2、不能查出程序中因遗漏路径而出错。
3、可能发现不了一些与数据相关的错误。
逻辑覆盖：
1.语句覆盖。“语句覆盖”是一个比较弱的测试标准，它的含义是：选择足够的测试用例，使得程序中每个语句至少都能被执行一次。
路径： a-> c ->e
2.判定覆盖。比“语句覆盖”稍强的覆盖标准是“判定覆盖”(或称分支覆盖)标准。含义是：执行足够的测试用例，使得程序中的每一个分支至少都通过一次。
路径：a->c->e a->b->d
3.条件覆盖。“条件覆盖”的含义是：执行足够的测试用例，使得判定中的每个条件获得各种可能的结果。
4.判定条件覆盖。它的含义是：执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个判定取到各种可能的结果。
5.条件组合覆盖。执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。显然，满足“条件组合覆盖”的测试用例是一定满足“判定覆盖”、“条件覆盖”和“判定/条件覆盖”的。
6.路径覆盖。指覆盖被测程序中所有可能的路径，这个就比较彻底了。
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
https://blog.csdn.net/weixin_36708477/article/details/53320876
NS 图
最少测试用例计算方法
使用N-S图：
为了实现测试的高逻辑覆盖，必须设计足够的测试用例并执行。
我们关心的是，对于某一具体程序来说，至少要设计多少测试用例。这里给大家介绍一种估算最少测试用例的方法——使用N-S图。
个人小技巧总结：测试用例数 = 并列矩形格子相乘，水平矩形格子相加，
下图是 5 * 3 +1 = 16
控制流图
基本上是相似的，节点变成圆圈。注意两点：
1、节点合并：原则，若一个节点序列没有分支则可以把这一系列节点合并为一个节点。
2、一条边一定要终止于一个节点，即使该节点不代表任何语句。
比如：图中添加9和10节点，if-then-else语句会出现这样的情况。
基路径测试法
圈复杂度：
概念：
1、它就是提供一种对软件程序逻辑复杂性的定量性的量度。
2、它的值就是可执行路径基本集合中独立路径的数目，是确保程序中所有可执行语句和所有条件的值都至少执行一次的测试数目的上界。
3、独立路径的概念：一条独立路径是指程序中至少引入一个新的处理语句的集合或者一个新条件的程序通路。
采用控制流图的术语就是独立路径至少包含一条在本次定义路径之前不曾用过的边或者不曾包含的节点。
有三种计算圈复杂度的方法：
1.E（边的数）-N（节点数）+tv（源节点汇接点）
2.PN（判定节点）+1
3.控制流图中区域的数量对应圈复杂度（图形外也算一个区域）
循环测试
第四章 单元测试
单元测试应考虑的部分：
1.模块接口，2.边界条件 3.独立路径 4.错误处理 5.局部数据结构
什么是单元测试？
单元测试是软件开发的过程的一部分，它是对应用的最小的可测部分——单元，进行逐一的独立的审查的各种操作。
单元测试的概念，我们知道两个要点：1、一个单元就是软件设计的最小单位。2、软件单元必须同其它部分分离出来进行单独的测试。
具体说来单元可以是一个具体的函数或者是一个类的方法，还可能是更大的单元——模块或者组件。
在java语言，单元可能是一个类或者是一个类的方法。
C语言，单元通常是一个函数或者子过程。
单元必须具备下面的属性：
1、明确的功能
2、规格定义
3、与其他部分明确的接口
为什么要具备这样的属性，因为一般情况下，被测单元能够实现一个特定的功能，并与其他单元有明确的接口定义，这样才可以与其他单元隔离开来进行单独的审查。
单元测试的目标就是确保模块被正确的编码。
使用详细的规格说明作为指南，对重要控制路径进行测试以发现模块内的错误，要不在白盒测试的时候我们就讲白盒测试主要应用与单元测试。
单元测试有下面四个目的：
1、验证代码是否与设计相符；
2、跟踪设计与需求的实现；
3、发现设计与需求中存在的错误；
4、发现编码过程中引入的错误。
为什么要进行单元测试？
单元测试隔离程序部件并证明这些单独部件的的正确性
单元测试能够提供了代码片段需要满足的严密的书面的规约。
它是在软件开发的早期就能发现问题。
1、单独进行，一起进行，降低软件质量成本，缩短开发周期；
2、便于跟踪错误；
3、集成后错误会放大，集成后复杂性高，很难发现问题；
4、无需额外的设备和人员。
单元测试要从下面这五个方面考虑：
1、模块接口：如果数据不能正常的输入输出，那么谈不上其他的测试；
2、局部的数据结构：这是常见的错误来源
3、独立路径测试：对基本的执行路径和循环路径进行测试；
4、异常处理：比较完善的模块设计要能够预见异常的条件并设置适当的异常处理，异常处理也是模块功能的一部分。
5、边界条件：边界上最容易出错。
断言到底是什么：
http://www.cnblogs.com/moondark/archive/2012/03/12/2392315.html
第五章 集成测试
什么是集成测试
集成测试位于从单元到系统的过渡阶段，对应开发的概要设计。
软件测试方法可以划分为白盒和黑盒两大阵营，而集成测试位于两大阵营的边缘，可以说是结合了白盒和黑盒两者的特点。
越来越多的学者把其定义为灰盒测试。
集成测试概念：
它是一个测试阶段，把独立的模块组装起来分组进行测试。
集成测试在单元测试之后，在系统测试之前完成。
集成测试与单元测试，系统测试的对比
在集成测试之前，单元测试已经完成。
集成测试所集成的单元是经过单元测试保证的单元。
如果不经过单元测试的保证集成测试的效果受到影响，并且付出更大代价。
单元测试与集成测试所关注的范围不同，所发现问题的集合包含不相交区域，不能相互代替。
系统测试和集成测试所站的角度不同。
系统测试对象是整个系统以及与系统交互的硬件软件平台，对系统能够做各种功能性和非功能性的验证
集成测试测试对象是模块与模块之间的接口，包括整体架构的问题。
集成测试的根本目的
就是根据系统的高层设计，或者叫架构设计验证模块组装后是否满足功能、性能、可靠性是否满足需求。
集成测试的优点在于：
同单元测试一样，它也有开始得早，容易锁定缺陷。
我们可以对独立的模块和整个系统的宏观有一个质量的反馈和把握。
缺陷的发现和修改都是很灵活的，并且可以和开发过程相协调。
集成测试的必要性
实践表明，一些模块虽然能够单独工作，但并不能保证连接起来也能正常工作。
程序在某些局部反应不出来的问题，在全局上就有可能暴露出来，影响功能的实现。
把各模块连接起来的时候，穿越模块接口的数据是否会丢失。
各个子功能组合起来，能否达到预期要求的父功能。
一个模块的功能是否会对另一个模块的功能产生不利影响。
因此单元测试之后，有必要进行集成测试，发现并排除在模块连接过程中可能发生的问题，最终构成要求的软件子系统或系统。
集成测试主要关注于：
1.模块的接口和组件的接口，
2.集成后功能的特性，
3.交互协议和信息，
4.系统整体的架构。
集成测试可以考虑增量的方法来制定一系列严密的测试循环
每一次测试循环要跟现有的已测的模块集合成更大的模块进行测试
直到系统已经建成，通过一次一次的测试循环达到系统级别的测试
集成测试循环的数目和总体需要的时间有下面这些参数确定：
1、系统内模块的数目；
2、模块的相对复杂度（圈复杂度）
3、模块之间接口的相对复杂度
4、每一次测试循环需要集成的模块数目，
5、模块集成前是否经过单元测试
6、测试-调试-定位周期的长度
什么时候系统测试已经完成？
整个系统已经充分的集成
所有测试用例都已执行并通过
各种错误都发现到并锁定
集成测试的特征：
1、单元测试具有不彻底性，对模块间接口信息内容的正确性，相互调用关系是否符合设计无能为力，只能靠集成测试来保障。
2、同系统测试相比，由于集成测试测试用例的生成是从程序的结构性出发，目的性和针对性更强，测试发现问题的效率更高，定位问题的效率也较高。
3、能够较容易地测试到系统测试测试用例难以模拟的特殊异常流程，从纯理论的角度来讲集成测试能够模拟所有的实际情况。
4、定位问题较快，由于集成测试具有可重复性强，对测试人员透明的特点，发现问题后容易定位，所以能够有效地加快进度，减少隐患。
下面我们来看一下，集成测试和开发之间的关系
集成测试与概要设计相对应，概要设计中的体系结构是集成测试的基础。
Booch认为集成是面向对象开发中关键的活动。
在结构化设计和开发中，集成测试也同等的重要。
我们认为集成测试和架构设计之间存在强烈的依赖关系，如果集成测试做得不好不充分那么程序会在结构上出现问题，如果架构设计的不好那么集成测试难以开展。
那么相应的集成测试也可以划分成两类：
增量型的集成测试逐步的把模块组装在一起进行测试的方法
非增量型的集成测试随机的把模块组装并进行测试的方法。
集成测试策略
● Big bang（大爆炸） integration （一次性组装或者整体拼装）
● Top-down （自顶向下）integration
● Bottom-up （自底向上）integration
● Sandwich（三明治） integration
● Layers（分层） integration
● High-frequency （高频）integration
● Event-based（基于事件） integration
系统测试
系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试.
目的是通过与系统的需求比较发现所开发系统与用户需求不相符，或者不完善的地方，从而提出更完善的方案。
系统测试属于黑盒测试的范畴，因此他不需要了解系统内部的代码或者逻辑。
系统测试是在整个系统的层面上完成的，主要的依据是功能需求说明书和或系统需求说明书。
测试是分层次进行的：
单元测试：是验证分离的软件单元；
集成测试：是验证软件单元间的接口；
系统测试：验证整个系统的性能。
为什么要进行系统测试？
1、有一些属性只有到了系统测试阶段才能验证
例如：可安装性、可用性、兼容性和可维护性等等。
2、在这个阶段用户也可以参与测设。
用例图画不出任何具体的集成单元
3、系统的运行环境也被考虑在内。
系统测试的方法有很多，因为系统级别的性能，指标有很多，这里可大家列举了19种，重点介绍红笔写出的8种。
GUI软件测试 冒烟测试
可用性测试 探索测试
性能测试 随机测试
兼容性测试 回归测试
负载测试 可靠性测试
容量测试 恢复测试
压力测试 安装测试
安全性测试 维护测试
可扩展性测试 可访问性测试
理智测试
