第一章 测试是否有必要
有。毕竟成本低
什么是软件的质量？（测试检测的是软件的质量，那么是什么软件的质量）
外部质量：用户可感知的，[功能、可靠、易用、效率]
内部质量：代码风格、内聚性、耦合性【可维护、可移植】
软件质量属性：
静态质量属性：结构化的，可维护的，可测试的代码以及正确的可用性完备的文档
动态质量属性：软件可靠性、正确性、完整性、一致性、可用性及性能
测试只是用来发现缺陷的
debugging才是最终解决问题的，人不可能通过量体重来减肥。
a可能考察到的点：
软件测试的发展走向：
1、以功能验证为导向：测试是为了证明软件是正确的。（正向思维）
2、以破坏性为导向：测试时为了找到软件中的错误（逆向思维）
3、以质量评估为导向：测试是提供产品的评估和质量度量
4、以缺陷预防为导向：测试时为了展示软件符合设计要求，发现缺陷、预防缺陷
1软件测试正确的定义：
1、软件测试是由“验证（Verification）”和“有效性确认（Validation）”活动构成的整体。
2、验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。
3、“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。
b软件测试的其他观点：
1、软件测试被认为是对软件系统中潜在的各种风险进行评估的活动。基于风险的软件测试可以被看作是一个动态的监控过程，对软件开发全过程进行检测，随时发现问题、报告问题
2、测试的经济观点就是以最小的代价获得最高的软件产品质量。经济观点也要求软件测试尽早开展工作，发现缺陷越早，返工的工作量就越小，所造成的损失就越小。
第二章 软件测试覆盖：
图覆盖
代码覆盖
逻辑覆盖
测试覆盖的定义，以及等级如果要考，都得会。
测试路径是是指的单入单出的完整路。经过的点或者路径都会被访问。它【路径】的子集就是游历。
图一
123568
1234
123567
43568
768
343
434
767
676
43567
找到简单路径（大于等于节点小于等于主路径）、主路径，最大简单路径。
主路径来源？
NCC ECC EPCC CPCC SPCC PPCC
根据代码画图。找到对应的边对，和主路径，并找到对应的测试路径
数据流覆盖：
全定义覆盖ADC 带定义的一条
全使用覆盖AUC 带使用的全部
全定义使用路径覆盖ADUPC 定义使用的组合
条件覆盖CC，结果覆盖DC 条件结果覆盖MCDC
图二
第三章 功能测试
等价类 边界值 判定表 因果图 pairwise 正交试验
如何测试？
1、扮演客户做测试
2、基于业务的测试
3、基于需求的测试
4、扮演客户去做测试
5、基于用例的测试方法【基于场景的测试】
等价类
1、做一个表格，对等价类进行划分
2、为每个等价类标号
3、设计一个测试用例覆盖尽可能多的有效等价类，
4、重复3，直到所有的有效等价类都被覆盖
5、设计一个测试用例，只覆盖一个无效的等价类
6、重复5，直到所有的无效等价类都被覆盖
边界值
设计方法：
确定边界情况（输入或输出等价类的边界）
选取正好等于、刚刚大于或刚刚小于边界值作为测试数据
判定表
根据组合就能知道结果的问题，就采用判定表方法/决策表方法（Decision Table）
因果图
1、不能根据输入条件的组合，直接确定所产生的结果，需要进行因果分析
2、因果分析是通过因果图来完成
3、因果图就是逻辑分析的图形化方法
pairwise
因素多个取值时：
下图要会看。
图三
正交试验：
齐整可比
均衡分散
第四章 变异测试
p11
在第二步末尾中，认定k1是被杀死的变异体。(k1<k)
k-k1是存活下来的变异体。
状况一：
k-k1=0：就变异体来说T是充分的。
状况二：
k-k1>0:那我们就来计算变异分数MS：
MS=k1/(k-e)
e是等价变异体的个数，e<=k-k1.
分析：
k-k1>0则T是不充分的。
如果T不充分->有一些突变体就没识别出来，导致杀死的少于真实的
就本图来说：MS=检测出的突变体/真实 不等价变异体
图四
如果MS=1，则T充分。e=k-k1【这是存在的，case1是全部被检测出来，这里面MS=1指的是，活着的都是等价的】增加技术
如果MS<1,则T不充分。增加用例
第五章 回归测试
指在修改了旧的代码以后，有没有引入新的错误，或者导致其他已存在的代码发生错误。
观念：
1、执行以前的全部或者部分相同测试
2、新加入的模组，可能对其他模组产生负作用，故要进行一定程度上的回归。
3、回归测试的重心，以关键性模组为核心。
测试用例库的维护：
1、删除过时的用例
2、改进不受控制的用例
3、删除冗余的测试用例
4、增添新的测试用例
回归测试包的选择：
1、在测试全部用例
2、基于风险选择测试【测试从主要特征到次要特征。最重要的、关键的和可疑的测试】
3、基于操作剖面选择测试【最重要或最频繁使用功能的测试用例，给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。】
4、在测试修改的部分【做到尽量全覆盖】
测试过程：
1、识别出软件中被修改的部分
2、从原基线测试用例库T中，排除不再使用的测试用例，确定那些对新的版本依然有效的测试用例，从而建立一个新的极限测试用例库T0.
3、依据一定的策略，从T0中选择测试用例测试被修改的软件。
4、如果有必要生成新的测试用例集T1用于测试T0无非充分测试的软件部分。
5、用T1执行修改后的软件。
【也许这才是我要找到的点，或许也是那个 “混账程序员”在自习编写代码学到的点。只要能解决问题，倒是不必要太拘泥于现成的风格。比如几天的回归测试，如果按部就班的读ppt可能要很久，既然都是回归测试，百度 上应该也有介绍，那么不妨读一个快的版本，以实现对该部分知识的快速思路厘清。从而在实际中解决一定的问题。】
第六章 测试需求分析概念
什么是测试需求？
1、测试需求，用来解决测什么的问题，指明被测试对象中什么要被测试。
2、通常以软件开发需求为基础，对开发需求进行细化和分解，形成可以测试的内容。
3、测试需求应该全部覆盖已定义的业务流程、功能需求、非功能需求。
测试需求分析做什么？
1、明确需求的范围，整理出测试需求点
2、明确每一个需求点的业务处理过程
3、整理不同的需求点之间业务的组合
4、根据显式需求挖掘隐式需求
【
1、明确测试需求范围，整理出测试点
2、明确测试点的业务逻辑
3、跟据业务逻辑，整理出业务组合
4、根据显示需求发觉隐式需求】
【测试需求结局要测试什么，即要被测试队相中那些内容要被测试
2、根据软件开发需求，对需求进行拆分和细化，行程要测试的内容
3、要测试已定义的全部业务逻辑、功能需求和非功能需求】
第七章 测试需求分析流程
1、需求采集【采集范围：需求规格说明书、项目相关文档、业务背景资料、培训资料、与客户或涉及人员沟通、竞争对手产品、测试经验库、其他】
2、需求分析【
需求要点分析：需求来源分析、继承性分析、需求项整理(细化过大、合并冗余)
质量模型分析：质量特性分析、测试类型分析
用户场景分析：交互性分析、业务场景分析
】
3、需求评审
评审的内容：完整性审查、准确性审查
评审的形式：评审会议、邮件或者即时通讯工具与相关人员沟通。
测试需求跟踪矩阵
测试需求跟踪矩阵需要不断的维护
一方面要同步变更
另一方面要不断扩展
探索式测试
产品功能特性分层：
单个特性测试：
1、联想输入模型
2、互联网测试模型
- 线上Bug模型
- 线下故障模型
3、漫游测试模型
- 基础测试方法
- 卖点测试法
- 恶邻测试法
- 进阶测试方法
- 极限测试法
- 通宵测试法
- 测一送一测试法
交互特性测试：
场景探索模型
1、场景操作模型
- 基于每一个用户可见的操作点，进行全操作
2、漫游探索模型
- 地标测试法 同场景 点击每一个地点
- 快递测试法 先操作 后验证
系统交互测试：
1、正规流程模型
- 确定产品及功能
- 确定潜在的不确定区域
- 测试产品的功能性和稳定性
2、漫游地图模型
- 漫游地图模型简介
- 漫游地图思维框架
3、肥皂剧测试模型
- 肥皂剧测试用例
- 肥皂剧测试特征
功能测试基础用力测试模型
图五