一．基本概念类：
1 什么是软件测试
采用人工或者自动化手段运行或检测被测系统的过程。其目的是检验其是否符合规定的需求，或者被测系统的预期结果和实际结果是否相同。
2 软件测试的目的
(确保软件满足用户的需要，衡量软件产品是否符合预期)和对象（源程序 目标程序 数据和相关文档）
3.什么是测试用例
是一组测试输入、执行条件和预期结果，目的是要满足一个特定的目标，比如执行一条特定的程序路径或检验是否符合一个特定的需求
测试用例=输入+输出+测试环境
测试用例设计的基本原则：
数量越少越好
典型性越高越好
对缺陷的定位性越强越好
4 什么是黑盒测试：
仅需知道被测对象的输入和与其输出，不需要了解程序内部实现的细节
什么是白盒测试：
对代码的测试，关注程序的内部结构针对性强，便于快速定位缺陷
在函数级别开始测试工作，缺陷修复成本低
有助于了解测试覆盖程度
有助于代码优化和缺陷预防
5 什么是单元测试，什么是集成测试，什么是系统测试，集成测试和系统测试的关系
6 怎样评价测试方法（或者说测试用例设计水平的评价）
对被测对象的覆盖率高
测试用例的冗余低
在无漏洞和无冗余的前提下，测试用例的数量少
对缺陷的定位能力高和快速
复杂度简单低
7 驱动模块和桩模块
8软件缺陷
软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好
软件未达到需求规格说明书SRS中指明的功能
软件出现了需求规格说明书中指明不会出现的错误
软件功能超出需求规格说明书中指明的范围
软件未达到需求规格说明书中虽未指出但应达到的目标
二．核心知识类：
1 黑盒测试方法的七大类方法
1）等价类划分法 （注意首先划分两个大类：有效等价类和无效等价类，然后分别在这两个类别中设计测试用例）
定义：依据需求对输入的范围进行细分，然后再分出的每一个区域内选取一个有代表性的测试数据开展测试
适用场景：适用有输入输出的
原理：分而不交，合而不变，类内等价
如何进行等价类测试：a.确定被测对象：根据被测对象的特性，针对整体输入域或输出域进行等价划分b.划分有效等价类（对于SRS而言，合理、有意义的输入数据构成的集合，即被测对象能接受的数据）和无效等价类
怎样进行有效等价类划分？
强组合：覆盖所有输入条件的所有有效等价类的所有组合
测试用例个数：m*n
弱组合：覆盖所有输入条件的有效等价类即可
测试用例个数：参数输入条件中最大的那个
怎么样进行无效等价类划分？单缺陷假设，覆盖一个输入条件的无效等价类
c.针对有效等价类和无效等价类分别设计测试用例
判断等价类中所有数据是否完全等价的简便原则：被测对象对输入数据的处理方式是否一致
为什么引用等价类测试：避免测试工作量大，测试不合理
2）边界值分析法（注意上下两个边界）（通常作为等价类测试的补充）
原因：大量研究表明，边界附近容易出现问题
适用条件：适用于有输入输出的
基于：独立性假设和单缺陷假设
定义和基本原理：对被测对象的边界和边界值附近设计测试用例
边界点：被测系统内部处理机制发生变化的点
数据选择：穷举法：每个边界点的邻域范围内的所有数据
优点：边界点和边界附近的数据都可以测到
缺点：测试数据量太多，测试负担重
典型值法：边界点，左邻近 右邻近
优势：测试数据包含了边界点本身以及最远离该边界点的邻域 数据，具有典型性，且数据量大大降低
组合方式： 强边界法：所有输入条件的所有边界的组合
可以测试到边界的所有组合，但不利用缺陷的定位
弱边界法：单缺陷假设，某个输入条件的单个边界点
将调试的思想引入测试，快速定位和隔离缺陷，降低测试用例的数量
全边界组合法：强边界+弱边界
典型值+弱边界法：（计算）
3）因果图和决策表法（适用条件）
因果图：
使用条件：原因和结果有相互制约的关系
局限性：测试用例数量可能会很大，不便于维护
定义：是一个用表格形式来整理逻辑关系的工具，由横向的条件（因）和动作（果）和纵向的规则（测试用例）组合而成
符号：（非 与 或）
步骤：
- 分析需求，找出原因和结果
- 找出原因和结果之间的关系，画出因果图
- 将因果图转换成决策表，并且合并
- 写出测试用例
决策表：
使用条件：输入输出较多，制约条件较多
定义：是一个用表格形式来整理逻辑关系的工具，由横向的条件（因）和动作（果）和纵向的规则（测试用例）组合而成
条件桩（Condition Stub）：列出了问题的所有条件（输入区）左上
动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束（输出区）左下
条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。（输入取值区）右上
动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作（输出取值区）右下
规则（Rule）：决策表中右部的每一列（条件项和对应的动作项）都是一条规则
步骤：
- 分析输入域。对输入域进行有效等价类的划分，分析输出域，对输出结果进行细分
- 找出条件项和动作项，进行0 1设置
3.设计决策表
4.输出结果相同，输入条件相似进行合并
5.转成测试用例（包括输入条件和预期结果）
4）场景法（测试用例的书写方法，可以使用表格的方式，书上80——81页的写法）
适用条件：某一场景有适用的流程（没有太多填写项，所有的操作都是通过鼠标的点击、双击、拖拽等完成）
定义：通过分析不同事件的触发顺序和处理结果，构建各个事件流，并基于这些事件的触发控制业务流程，形成多个不同场景，最终基于场景设计测试用例
基本流：是从系统的某个初始状态开始，经一系列状态变化后到达终止状态的过程中最主要的一个业务流程
备选流：是以基本流为基础，在经过基本流上每个判定节点(包括条件判定和循环判定)处满足不同的触发条件，而导致的其他事件流
步骤：
1.分析需求（流程图）
2.分析基本流和备选流
3.根据基本流和备选流设计测试用例
V：该条件必须有效才可以执行该测试用例
I : 触发对应的备选流的条件
N/A：该测试用例中不需要设置该输入条件
5）状态转换法
定义：对系统的每个状态及状态相关的函数进行测试，任何一个系统，如果对同一个输入，根据不同的状态，可以得到不同的输出
使用: 画状态树，然后转换成测试用例
6）正交实验法
适用条件：多个输入条件，每个输入条件s有多个测试数据q
特点：均衡分散，整齐可比
定义：根据正交性原理，从全面试验中挑选部分有代表性的试验点，并能求出最佳工艺参数和工艺条件
正交表：Ln(qs)
n：实际测试用例的个数，对应正交表的行数；
q：每个输入条件所取测试数据的个数，对应正交表中每个输入条件的取值个数；
s：输入条件的总数，对应正交表的列数；
qs：理论上全组合方式的测试用例个数，基于正交表的测试效率为n与qs的比值；
如何设计测试用例：
1.确定输入条件s
2.每个输入条件的测试数据个数q
3.编号（为每个输入条件的每个取值编号）
4.选取正交表（常用正交表和混合正交表）
常用：
混合：混合水平正交表Ln(q1s1 * q2s2)
q1s1 :表示在所有输入条件中，有s1个输入条件的取值个数均为q1
q2s2 :表示在所有输入条件中，有s1个输入条件的取值个数均为q1
改造正交表：接近
5.写测试用例
7）错误推测法
优点：能够覆盖其他测试用例设计方法覆盖不到的功能
缺点：过分依赖于个人经验
2 白盒测试方法
1）静态白盒测试：测试内容，形式（评审会及评审会中的细节）
静态白盒测试怎么做：1.代码检查：
同行评审（发现特定类型的缺陷，有助于开发早期发现需求和缺陷）、评审会议 记录未达成共识的缺陷，标记为TBD
五种角色：评审员 作者 讲解员 主持人 记录人
评审流程：（入口和出口标准）
2.静态结构分析
对静态结构的分析：
函数之间的调用关系是否符合要求；
是否存在递归调用（对内存消耗大，长时间运行容易导致崩溃）
函数调用层次是否太深，过深的调用层次容易导致数据和信息传递错误和遗漏，并增大测试的负担
是否存在孤立函数
确定测试重点：
根节点需要优先测试
叶子节点需要优先测试
接口数量多的节点需要优先测试
对函数控制流图分析：
是否存在多出口情况，多出口容易导致空指针，内存未释放这类缺陷
是否存在孤立语句
环复杂度是否太大
是否存在非结构化设计
3.代码质量度量
静态白盒测试的总结：静态白盒测试通过对比标准和规范，检查程序逻辑，直接定位缺陷，从而加快测试进度，降低测试工作量
静态白盒测试还基于缺陷预防的思想
2）代码质量度量：软件质量模型，代码质量度量模型，代码质量的自动度量
3）补充软件能力成熟度模型CMM：初始化级、可重复级、定义级、定量管理级、不断优化级
4）环复杂度度量：如果是填空或选择题中出现，没有特别强调是强联通图，则使用 V（G）= e - n + 2的计算方式；
如果是大题，需要画图并计算，则标清楚每个节点的编号，然后写出V(G)的计算过程。（尽量用V(G）= P+1的方式，减少争议；
直接观察法：外部的开放区域也要算
公式计算法：适用条件：不存在孤立节点、是强连通图
判定节点法：
a:P代表独立判定节点，即两分支的判定
b:如果判定节点是n分支（n>2），该判定节点应视为(n-1)个独立判定节点
c:若判断中条件表达式是由逻辑运算符 (OR, AND) 连接的复合条件表达式，则需改为一系列只有单条件的嵌套的判断
5）动态白盒测试方法：查看代码功能和实现方式
对判定的测试：
a:语句覆盖：程序中的每一个可执行语句都能够被执行一次
b:判定覆盖：使程序中每个分支都至少取一次真值和假值
c:条件覆盖：使程序中每个判定的每个条件都至少取一次真值和假值
测试用例表中包括：编号、输入、预期输出、判定条件TF、通过路径、条件覆盖率、语句覆盖率
d:判定/条件覆盖：每个判定节点至少一次真值和假值，每个简单判定中的条件至少一次真值和假值
e:条件组合覆盖：在每个判定节点中，所有简单条件的可能的所有取值组合
如果第一个判定节点中有两个判定条件，则2的2次方组合，第二个判定节点中有2个判定条件，则2的2次方种，所以共有4*4=16种
f:修正的判定/条件覆盖：适用于A AND B 的情况，列出真值表
6）独立路径测试：
a:计算环复杂度——确定独立路径数量；
b:找出独立路径
独立路径的抽取：
1、确定主路径
该路径应包含尽可能多的判定节点
应包含尽可能复杂的判定表达式
应对应尽可能高的执行概率
应包含尽可能多的语句
2、根据基础路径抽取其他独立路径
c:分析不可行路径（去掉或修改）
d:分析高概率路径应该出现而没有出现的，做补充；
e:根据得出的路径转换成相应的测试用例，写出；
测试用例设计步骤
1.根据程序源代码生成程序图
2.计算程序图的环复杂度，确定独立路径集合的大小
3.以最复杂的路径为基础路径，通过覆盖所有判定分支确定其他路径，抽取独立路径集合
4.注意剔除不可行路径，必要时补充其他重要的路径
5.根据得到的路径集合对应设计测试用例（编号 输入 输出 对应场景）
7）对循环的测试（防止内存的泄露）
循环结构分类：单节点的循环 循环的串联 循环的嵌套
单节点循环测试的过程：
循环节点的嵌套测试：
当循环节点为嵌套形式，且判定节点相互独立时：先测试最内层循环体，然后逐步外推，直至测试到最外层的循环体测试每层循环体时，仍根据单个循环体的测试原则进行测试：考虑4种特殊组合：
1）内层最小循环次数，外层最小循环次数组合，计算结果
2）内层最小循环次数，外层最大循环次数，计算结果
3）内层最大循环次数，外层最小循环次数，计算结果
4）内层最大循环次数，外层最大循环次数，计算结果
8）对变量的测试（定义清除路径不测试）
变量的3种缺陷定义：从未定义过、从未使用过、被多次定义
定义节点：某个变量在某条语句中发生改变，则该语句为此变量的定义节点
使用节点：某个变量在某条语句中被使用，则该语句为此变量的使用节点
定义/使用节点对：一对定义节点和使用节点构成的一个二元组（一条语句中既有该变量的定义，又有使用）
定义/使用路径：从一个定义节点开始，到某个使用节点结束构成的一条路径
定义/清除路径：若一条定义使用路径中，不包括该变量的其他定义节点，称为定义清除路径
9）对黑盒、白盒测试的总结和评价
白盒测试的对象是代码，分为静态白盒测试和动态白盒测试，运用于单元测试和集成测试，目的是提高代码质量和产品质量；优先进行静态白盒测试，选用合理的测试覆盖指标；针对变量的测试，应选择合理的数据流的测试方法补充对路径的测试；对边界值进行测试时，注意判定节点的边界，循环的边界和取值范围的边界。
黑盒方法设计的测试用例的可能存在冗余和漏洞，可以利用白盒测试用例的覆盖指标来衡量黑盒测试的漏洞和冗余。
10）单元测试的内容及方法
定义：对软件中的最小可测试单元和基本组成单元进行检查和验证
内容：静态测试：主要是通过走查、审查等会议方式，依据模块的详细设计，将 代码与缺陷检查表进行对照，查看代码是否符合标准和规范
动态测试：主要包括对模块接口、模块边界条件、模块独立路径和模块错误处理路径进行测试
步骤：第一步：做静态和动态检查
第二步：编写测试用例做相应测试(借鉴黑盒测试用例设计方法如：等价类、边界值)
第三步：使用判定覆盖或独立路径覆盖进行测试（有时会与黑盒测试用例重合，则选其一即可）
11）集成测试的内容及方法
定义：集成测试就是在单元测试的基础上，将所有已通过单元测试的模块按照概 要设计的要求组装为子系统或系统，并进行测试的过程，目的是确保各单元模 块组合在一起后能够按既定意图协作运行，并确保增量的行为正确
内容：将各个具有相互调用关系的模块组装起来时，检查穿越模块接口的数据是否会丢失
判断各子功能组合起来能否达到预期要求的父功能
检查一个模块的功能是否会对其他模块的功能产生不利影响
检查全局数据结构是否正确，以及在完成模块功能的过程中是否会被异常修改
单个模块的误差累积起来，是否会放大到不可接受的程度
驱动模块：模拟被测单元的上级模块
桩模块：模拟被测单元的调用模块
集成测试的方法：（依次比较下去，测试用例数量在减少，定位能力在减弱，桩模块和驱动模块的数量在相对减少）
成对集成：共m个模块，n条边，因每条边对应一对调用接口，确定一个成对测试用例，因此包含n个测试用例 ND3->GD ND3->ID等等
邻居集成：邻居是指某个指定模块及其所有直接调用该模块的上层模块以及所有被该模块直接调用的下层模块ND3->GD->VD ND3->ID->IDOM等等
基于独立路径的集成：找流程图中共有多少条路径
12）系统测试的内容和方法
内容：功能测试、性能测试、兼容性测试、用户界面测试、可安装性测试、易用性测试
三．需要掌握的其他知识：
1）软件开发过程
需求调研分析-概要设计（系统设计）-详细设计-编码-测试-软件交付准备-验收
2）软件开发模型
软件开发模型是软件开发的全部过程、活动、任务和管理的结构框架。它给出了软件开 发活动各阶段之间的关系。
大爆炸模式：优点：思路简单， 通常可能是开发者的“突发奇想”
缺点：开发过程是非工程化的，随意性大，结果不可预知
测试：开发任务完成后，修复较困难
边写边改模式：优点：简单考虑到了软件的需求，产品周期短
缺点：没有计划和文档的编制
测试工作： 由于新的版本不断产生，测试工作长期循环
瀑布模型：需求分析-系统设计-程序设计-编码-测试-运行和维护
优点：如同瀑布流水，逐级下落——样式
将软件生存周期各活动规定为依线性顺序联接的若干阶段的模型
易理解，阶段明显，强调需求分析，明确测试阶段，提供了一套模板
缺点：线性严格——成果晚出——风险大
阶段固定——反复&迭代不适合——灵活性差
单次需求——需求变更多——适应性差
测试滞后——缺陷晚查——代价大
适用场合：功能、性能明确完整
需求固定，无重大变动（操作系统,数据库管理系统）
螺旋模型：加入了“风险分析”“软件阶段性”概念
敏捷开发模型： 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行 软件开发
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征
3）软件测试模型
V模型：特点：是软件开发模型中瀑布模型的变种，体现动态测试的过程，开发是自顶向下的，测试是自下而上的。
策略：动态测试过程与开发过程一一对应，每个测试阶段的基础是对用开发阶段的提交物，低层测试保证代码的正确性，高层测试保证整个系统满足用户的需求。
局限性：测试滞后、缺少静态测试（评审，代码检查等）
W模型：特点：增加与开发阶段同步进行的测试过程（两个V叠加）
策略：动态测试与静态测试伴随整个开发阶段，并且与开发阶段一一对应，有助于早期发现缺陷
局限性：开发与测试保持着线性的前后过程，不支持迭代的开发模型，未体现测试过程的完整性
H模型：策略：测试过程保持完整性
X模型：特点：针对每个单独的片段进行单独地编码和测试，类似敏捷开发模型，强调测试先行，清晰地体现了单元测试-集成测试-系统测试的过程。
4）软件测试流程
需求分析
拟定测试计划（对资源、时间、风险、测试范围和预算等方面的综合分析）
测试计划评审（不通过，重新拟定测试计划）
设计和生成测试用例
测试用例评审
搭建测试环境
实施测试（提交缺陷报告）
测试评估和总结
5）测试文档的书写：测试计划，测试用例，缺陷记录及流转过程，测试报告（测试总结报告）
Step1:了解基础知识（测试方法和测试覆盖率）
Step2:查阅并熟悉标准
Step3:书写说明（包含简单的摘要、目标、范围、时间表等）
Step4:定义目标定义哪些测试哪些不测试常见的包括：模块测试、集成测试、系统测试等等
Step5:写出需要的资源（人力物力 时间）
Step6:写出测试过程中可能的风险和依赖
Step7:写出你将如何测试以及测试完成后会有哪些可交付成果
Step8:列出哪些功能不测试，以及不测试的原因
Step9:写出测试策略和将要使用的工具以及收集的信息
Step10:制定通过或失败的标准
Step11:列出在测试期间将产生的文件清单
6）缺陷探测率=（已发现bug总数/总共bug数）*100%
7）软件测试过程管理
对测试用例的管理、对软件缺陷的管理、对测试团队的管理
8）软件测试的分类：
从是否运行被测程序：静态测试和动态测试
从是否关心内部结构：黑盒测试，白盒测试，灰盒测试
从软件开发的过程的角度：单元测试，集成测试，系统测试，验收测试
从执行时是否需要人工干预：人工测试和自动化测试
从测试实施组织的角度划分：开发方测试，用户测试，第三方测试
10）补充测试
回归测试：旨在检验软件原有功能在修改后是否正确，并且其他功能有没有受到影响
验收测试：是指确认系统是否符合需求规格说明的测试
α测试：是指确认一系统是否符合设计规格或契约之需求内容的测试
β测试：用户方试用测试（可以找第三方，也可以找正式的用户）
冒烟测试：是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程
做法：选取重要功能进行测试
适用场景：发布上线之后
扫一扫
2962
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
