黑盒测试
黑盒测试又称正确性测试，或功能测试，是对产品的各功能进行验证，用于检查产品是否达到用户要求的功能或者说检查软件的功能是否符合规格说明。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。
黑盒测试主要测试的方面：
- 不正确或遗漏的功能；
- 接口、界面错误；
- 性能错误；
- 数据结构或外部数据访问错误；
- 初始化或终止条件错误等等。
等价类划分
等价类划分是一种典型的黑盒测试方法，该方法完全不考虑程序的内部结构，只根据对软件的要求和说明，即需求规格说明书，把程序输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据为作测试输入。
有效等价类和无效等价类
等价类划分分为两种情况，有效等价类和无效等价类
| 分类 | 介绍 |
|---|---|
| 有效等价类 | 是指对程序规格说明，是有意义的，合理的输人数据所构成的集合。利用有效等价类，可以检验程序是否实现了规格说明预先规定的功能和性能。 |
| 无效等价类 | 是指对程序规格说明，是不合理或无意义的输入数据所构成的集合。利用无效等价类，可以检查程序功能和性能的实现是 否有不符合规格说明要求的地方 |
示例：假设存在一个三角形判断程序：输入三个正整数，根据输入的数判断组成的三角形类型。
当输入为:a = 10,b = 10,c = 10时,为有效等价类
当输入为：a = -1,b = 5,c = 9时，由于a=-1不满足，三个都为正整数的条件，因此为无效等价类。
等价类划分
划分等价类需要满足划分的集合为互不相交的一组子集，且这些子集的并是整个集合。
以上面的三角形判断程序为例：
边界值分析
大量的故障发生在输入或输出范围的边界上，而不是在输入范围的内部。使用边界值分析方法设计测试用例时首先应确定边界情况。
边界值分析测试数据的选取（也要考虑无效值）：
- 选取正好等于边界的值
- 刚刚大于边界的值
- 刚刚小于边界的值
边界值分析的不足：
边界值分析要求输入的变量是独立的，否则这类方法不能产生令人满意的测试用例。例如，月份和日期就不是独立的，日期的最大值随月份的变化而变化。
边界值分析与等价划分的区别：
- 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
- 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
决策表测试
决策表（也叫判定表）是所有的黑盒测试方法中最严格，最具有逻辑严格性的测试方法。 决策表最突出的优点是，它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。
决策表的原理：
在一些数据处理问题当中，某些操作的实施依赖于多个输入条件的组合。判定表能够将复杂问题按照各种可能的情况全部列举出来，避免遗漏。
白盒测试
白盒测试（White Box Testing）又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试只测试软件产品的内部结构和处理过程，而不测试软件产品的功能，用于纠正软件系统在描述、表示和规格上的错误，是进一步测试的前提。
白盒测试遵循的四大原则:
- 保证一个模块中所有路径至少被测试一次；
- 所有逻辑值都要测试真(true)和假(false)两种情况
- 检查程序的内部数据结构是否有效；
- 检查上、下边界及可操作范围内运行所有循环
静态白盒测试
白盒测试分静态和动态两种,静态测试是指不运行程序，通过人工对程序和文档进行分析与检查。下面是静态白盒测试检查的故障模式。
- 内存泄漏的故障（Memory Leak Fault， MLF）
- 数组越界故障的故障（Out of Bounds Array Access Fault OBAF）
- 使用未初始化变量故障（Uninitialized Variable Fault，UVF）
- 空指针使用故障（NULL Pointer Dereference Fault NPDF）
- 非法计算类故障（Illegal Computing Fault ILCF）
- 死循环结构(Dead Loop Fault DLF)
- 资源泄漏（RLF）
- 并发故障 （Concurrency Fault）
- 安全漏洞故障
- 疑问代码故障
简单来说，静态白盒测试就是看代码找bug
动态白盒测试
白盒测试分静态和动态两种，动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能。
动态白盒测试流程：
- 选取定义域有效值，或定义域外无效值；（等价类划分思想）
- 已选取值决定预期的结果；
- 用选取值执行程序；
- 执行结果与对已选取值决定预期的结果对比，不吻合程序有错
逻辑覆盖测试
为了满足白盒测试的四大原则，需要使用逻辑覆盖测试法来设计测试用例。逻辑覆盖测试是以程序内部的逻辑结构为基础设计测试用例的方法，首先需要就行代码的结构分析，绘制流程图。
代码如图所示：
对应结构图如下：
注意：圆圈中的数字代表代码的行数
之后进行逻辑覆盖，由于覆盖测试的目标不同，逻辑覆盖又可分为：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
| 覆盖方法 | 介绍 |
|---|---|
| 语句覆盖 | 选择足够多的测试用例，使得程序中的每个可执行语句至少执行一次。 |
| 判定覆盖 | 通过执行足够的测试用例，使得程序中的每个判定至少都获得一次“真”值和“假”值， 也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次，也称为“分支覆盖”。 |
| 条件覆盖 | 设计足够多的测试用例，使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满足一次。 |
| 判定/条件覆盖 | 设计足够多的测试用例，使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。满足判定/条件覆盖的测试用例一定同时满足判定覆盖和条件覆盖 |
| 条件组合覆盖 | 通过执行足够的测试用例，使得程序中每个判定的所有可能的条件取值组合都至少出现一次。满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定/条件覆盖 |
| 路径覆盖 | 设计足够多的测试用例，要求覆盖程序中所有可能的路径 |
从表中的介绍可知，从上到下，该方法覆盖的路径越多。其他方法覆盖的路径不全面，那为什么不直接使用路径覆盖？这是由于如果程序中出现了多个判断和多个循环，可能的路径数目将会急剧增长，以至实现路径覆盖不可能。
为了解决上面的问题，出现了基本路径覆盖，它在程序控制流图的基础上，通过分析程序控制流图的环路复杂性，导出基本可执行路径(独立路径)的集合，然后据此设计测试用例。
各个覆盖方法的优缺点：
在实际测试中，即使对于路径数很有限的程序已经做到路径覆盖，仍然不能保证被测试程序的正确性，还需要采用其他测试方法进行补充。
数据流测试
数据流测试分析常常集中于定义/引用异常的缺陷，用于如下三方面测试。
- 变量被定义，但是从来没有使用(引用)
- 所使用的变量没有被定义
- 变量在使用之前被定义两次
早期的数据流测试主要用于检测程序编写时出现的一些警告信息，如“所定义的变量未被使用等”问题，这些问题光靠简单的语法分析器或者是语义分析器是无法检测出来的。
程序插桩
在程序的特定部位插入记录动态特性的语句，最终是为了把程序执行过程中发生的一些重要的历史事件记录下来。例如，记录在程序执行过程中某些变量值的变化情况，变化的范围等。这些插入的语句常常被称为“探测器”或者“探测点”。
总结
- 白盒测试方法基于被测程序的源代码开发测试用例。常见的白盒测试方法有逻辑覆盖、数据流测试、路径分析以及程序插装等。
- 逻辑覆盖以程序内部的逻辑结构为基础设计测试用例，要求对被测程序的结构作到一定程度的覆盖，如语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖及路径覆盖。路径覆盖是最强的逻辑覆盖准则，实际上我们只能有选择地测试程序中某些有代表的性路径。
软件测试流程
软件测试流程如下：
- 测试计划
- 测试设计
- 测试执行
- 单元测试
- 集成测试
- 确认测试
- 系统测试
- 验收测试
- 回归测试
- 验证活动
测试计划
测试计划由测试负责人来编写，用于确定各个测试阶段的目标和策略。这个过程将输出测试计划，明确要完成的测试活动，评估完成活动所需的额时间和资源，进行活动的安排和资源分配。 测试依据主要是项目开发计划和测试需求分析结果而制定。
测试设计
根据测试计划设计测试方案，测试设计过程输出的是各测试阶段使用的测试用例，为每一个测试需求确定测试用例集，并且确定执行测试用例的测试过程。
根据软件测试计划、软件需求、软件构架设计、软件详细设计等文档内容，设计测试用例具体如下：
- 对每一个测试需求，确定其需要的测试用例。
- 对每一个测试用例，确定其输入及预期结果。
- 确定测试用例的测试环境配置、需要的驱动程序。
- 编写测试用例文档
- 对测试用例进行同行评审（peer review）
测试执行
如图所示，测试执行过程分为以下测试阶段：单元测试、集成测试、确认测试、系统测试、验收测试等。
单元测试
单元测试是在软件开发过程中进行的最低级别的测试活动，其测试的对象是软件设计的最小单位，单元测试又称为模块测试
很多人将单元的概念误解为一个具体函数或一个类的方法，这种理解并不准确。作为一个最小的单元应该有明确的功能定义、性能定义和接口定义，而且可以清晰地与其他单元区分开来。一个菜单、一个显示界面或者能够独立完成的具体功能都可以是一个单元。从某种意义上单元的概念已经扩展为组件（component）。
单元测试的环境：
由于每个模块在整个软件中并不是孤立的，在对 每个模块进行单元测试时，需要考虑它和周围模块的 相互联系。为模拟这一联系，在进行单元测试时，必 须设置若干个辅助测试模块。这些辅助模块分为两种：
- 驱动模块（driver）: 用以模拟被测模块上级模块，相当于被测模块的主程序。
- 桩模块（stub）: 用以模拟被测模块的下级模块，相当于被测模块调用的子模块。
单元测试完成方式
单元测试可以由两种方式完成：
单元测试的不足：
- 模块相互调用时引入了新的问题；
- 几个子功能组合起来不能实现主功能；
- 误差不断积累达到不可接受的程度；
- 全局数据结构出现错误等。
集成测试
确定测试
集成测试完成以后，分散开发的模块被联接起来，构成一个完整的程序。其中各模块之间接口存在的种种问题都已消除。于是进入了确认测试阶段。
确认测试，是对照软件需求规格说明书，对软件产品进行评估以确定其是否满足需求规格的过程。 它决定最后的软件产品是否正确无误。
确定测试的策略：
- 基于需求的测试：采用黑盒测试策略，在不知道详细设计规格说明或代码的情况下对用户需求进行测试。基于需求的测试根据功能设计规格说明设计测试用例。
- 基于功能的测试：采用黑盒策略，根据功能设计规格说明，采用等价类划分、边界值分析和故障猜测等方法设计测试用例。
- 基于内部的测试：只能采用白盒测试策略，但可采用功能设计规格说明制订测试计划。一但采用白盒测试，便可通过一系列的技术确保系统的内部各部分获得充分的测试并且达到足够的逻辑覆盖。
系统测试
系统测试实际上是针对系统中各个组成部进行的综合性检验，很接近我们的日常测试实践。 系统测试的目标不是要找出软件故障，而是要证明系统的性能。
注意：系统开发人员和组织不能负责系统测试，系统测试最好由独立的测试机构完成。
验收测试
验收测试是将最终产品与最终用户的当前需求进行比较的过程，是软件开发结束后，软件产品向用户交付之前进行的最后一次质量检验活动，回答开发的软件产品是否符合预期的各项要求，用户是否接受等问题。
验收测试不只检验软件某方面的质量，还要进行全面的质量检验并决定软件是否合格。因此验收测试是一项严格的正规的测试活动，并且应该在生产环境中而不是开发环境中进行。
回归测试
回归测试则是对程序进行测试以确定是否因故障修复而引入了新的故障。 回归测试不是一种新的测试活动，它是为检查是否因修复故障引入了新的故障而重新执行某些或所有测试用例的过程。
验证活动
验证活动存在测试生存周期中的每一个阶段，包括需求验证、功能设计验证、详细设计验证和代码验证。在每个验证活动中，测试的目的都是为了发现尽可能多的故障，测试人员应积极参与软件审查和走查工作，并开展验证工作。
性能测试
性能测试是指在一定条件下系统行为表现是否符合需求规格的性能指标。 例如，通过测试传输的最长时限、传输的错误率、计算的精度、响应的时限和恢复时限等性能指标，验证了软件系统是否能够达到需求规格说明中所提出的性能指标，发现了软件系统中所存在的性能瓶颈，达到了优化软件系统的目的。
性能测试指标
-
并发数
- 系统用户数：该系统的注册用户数。例如，QQ有100个注册用户。
- 在线用户数：即登录的用户数。例如，100个人里面有60个人为在线状态。
- 并发用户数：是对服务器产生压力的用户。例如，这60个人里面只有20个人在进行通信或其他操作。这20个人就是并发用户数。
-
响应时间（请求响应时间）请求响应时间通常会被称为“TTLB”(Time to last byte),意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。对请求做出响应所需要的时间一般为：网络请求的时间 + 服务器处理的时间 + 网络响应的时间
-
每秒事务数（TPS）是指每秒系统能够处理的事务数。它是衡量系统处理能力的重要指标。
-
吞吐量是单位时间内系统处理的客户请求的数量。直接体现软件系统的性能承载能力，一般来说用请求数或页面数来衡量。从业务角度，吞吐量也可以用访问人数/天或是处理的业务数/小时来衡量；从网络角度，吞吐量可以用字节/天来衡量。
-
资源利用率 不同系统资源的使用情况。CPU，网络，磁盘，网络。
性能测试分类
性能测试分为狭义性能测试、基准测试、强度测试、安全性测试、恢复测试、安装测试、可靠性测试、配置测试、可用性测试、兼容性测试和文档资料测试。
| 测试 | 介绍 |
|---|---|
| 狭义性能测试 | 狭义性能测试通过模拟生产运行的业务压力和使用场景组合，测试系统的性能能否满足生产系统要求。是一种常见的测试方法。 |
| 基准测试 | 基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试。 |
| 强度测试(负载测试) | 在被测系统上不断增加压力，直到性能极致。测试当负载逐渐增加时，系统各项性能指标的变化情况;找系统的负载极限，为系统调优提供数据;检查系统在超负荷情况下的运行情况。 |
| 安全性测试 | 测试系统对非法侵入的防范能力 |
| 恢复测试 | 测试系统的容错能力。可以采取各种人工干预方式，比如将一些软件故障故意注入到操作系统中，制造通讯线路上的干扰，引用数据库中无效的指针等，使软件出错而不能正常工作，进而检验系统的恢复能力。 |
| 安装测试 | 找出在那些安装过程中出现的错误，而不是软件故障。 |
| 可靠性测试 | 测试平均无故障时间是否超过规定时限和因故障而停机的时间 |
| 配置测试 | 配置测试是用各种硬件和软件平台以及不同设置检查软件操作的过程，以保证测试的软件可以使用尽量多样化的硬件组合。 |
| 可用性测试 | 可用性测试检测用户使用软件是否满意。 |
| 兼容性测试 | 测试软件是否向前向后兼容，是否兼容不同版本 |
| 文档资料测试 | 检测文档资料 |
性能测试步骤
- 制定目标和分析系统
- 选择测试度量的方法
- 采用相关技术和工具
- 制定评估标准
- 设计测试用例
- 运行测试用例
- 分析测试结果
我是小北一个陪你成长,实实在在分享 测试干货职场经验的人,欢迎关注!!!
下面是配套资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！
软件测试面试小程序
被百万人刷爆的软件测试题库！！！谁用谁知道！！！全网最全面试刷题小程序，手机就可以刷题，地铁上公交上，卷起来！
涵盖以下这些面试题板块：
1、软件测试基础理论 ，2、web,app，接口功能测试 ，3、网络 ，4、数据库 ，5、linux 6、web,app，接口自动化 ，7、性能测试 ，8、编程基础，9、hr面试题 10、开放性测试题，11、安全测试，12、计算机基础
编辑资料获取方式 ：xiaobei_upup，添加时备注“csdn alex”
