标签：测试工程师 外部 模式 接收 公司 共享 关闭 方案 很多
软件测试基础 复习笔记 编辑&整理：Xu An
一、基本概念
1、软件=程序+文档+数据+服务
2、软件的特点：依托具体的硬件设备运行
3、软件测试定义：确保被测系统满足要求
4、测试目的：不是发现缺陷，而是满足用户需求
5、软件测试过程（流程） 计例搭测评
（1）制定测试计划
（2）设计和生成测试用例（编写测试用例的过程中是没有源代码的，根据需求写）
（3）搭建测试环境
（4）执行测试
（5）测试总结与评估
6、 （1）测试工作应该具备的素质：细心，耐心，沟通，能力，编程基础
（2）原则：
从需求阶段尽早介入
贯穿于整个声明周期
标准是用户需求
测试前准备好试数据和结果
包含合理输入与不合理输入
程序提交测试后，由专门的测试人员进行测试
严格执行测试计划，排除随意性
对每一个测试做全面的检查
注意测试中的群体现象
（3）误区：
测试等于调试
软件需求规格说明详细包含所有用户需求
软件测试可以提高软件质量
7、测试分类
（1）执行时是否需要人工干预
人工测试
自动化测试（性能测试，测并发）：通过测试工具、测试脚本手段对软件产品进行自动测试，适用于长期的项目，需求稳定，对测试人员有编码能力的要求
a、自动化可以处理：单元测试（CodeReview，数据处理层）、服务测试（模块接口测试，web接口测试，业务逻辑层）、UI测试（功能，性能，安全，UI界面层）
b、自动化测试适用场合：回归测试、频繁测试、跨平台测试、测试过程和验证点比较稳定的 c、不适用的场合：随机测试、时间短、一次性项目、需求变化多的项目，软件版本不稳定、涉及与物理设备交互
（2）是否看代码（关心内部结构）
黑盒测试：功能测试
白盒测试：逻辑驱动测试
灰盒测试：接口测试
（3）测试对象不同（软件开发过程）
单元测试
集成测试
系统测试
验收测试
（4）实施方不同
开发测试：自己测
用户测试：用户测
第三方测试：别人测
（5）是否运行被测试程序
静态测试：不运行程序
动态测试：需要运行程序
7、测试用例
（1）定义：一组测试输入、执行条件和预期结果，目的是满足一个特定目标（输入+预期输出+测试环境）
（2）测试环境：真实、干净、独立、无毒
（3）用例设计：正常数据、错误数据、边界数据
（4）基本原则：数量少，典型性高，对缺陷定位强
二、黑盒测试
1、等价类（分为无效等价类、有效等价类）输入输出可以用等价类思想
（1）产生的原因
对系统进行穷尽测试是不可能的，所以使用少量有限的测试用例进行测试以达到完备和没有冗余的测试
（2）基本原理：等价划分（约束：分而不交，合而不变，类内等价）：根据需求对输入/输出的范围进行细分，然后分出每一个区域没选取一个有代表性的测试数据开展测试。
（3）等价类的分类
<1>有效等价类：输入域中一组合理、有意义（符合需求说明）的数据集合，用于检验特定功能和性能是否能正确实现
<2>无效等价类：输入域中一组不合理、无意义（不符合需求说明）的数据集合，用来检验系统容错性
（4）等价类划分的原则
<1>如果规定了范围，且趋势范围上下限之间数据有意义，则：
有效等价类1：取值范围内
无效等价类1：小于下限
无效等价类2: 大于上限
<2>输入条件规定“必须如何”，则：
有效等价类1：满足必须条件
无效等价类1：其他数据
<3>输入条件规定布尔量：
有效等价类1：真值
无效等价类1：假值
<4>输入条件是逻辑量（即规定了输入数据是一组值，且系统分别要对每个量进行处理）
有效等价类*n：每一个输入值n
无效等价类1：所有不允许输入的值的集合
<5>用户需求规定必须遵守某种规则
有效等价类1：满足用户规则
无效等价类*n:不同角度违反规则
（5）设计等价类测试用例的步骤
<1>按照常用方法划分等价类
<2>为等价类表中的每一个等价类分别规定一个唯一编号
<3>设计一个新用例，使它能够尽可能 多的覆盖尚未覆盖的有效等价类，重复该步骤，直到所有有效等价类用例均被覆盖
<4>设计一个新用例，使它仅能覆盖一个尚未覆盖的无效等价类，重复该步骤，直到所有的无效等价类用例均被覆盖。
（6）输出域等价类测试的流程
确定有几类输出结果
划分每类输出结果的等价类
设计测试用例
2、边界值（边界值关键：刚好等于、刚好大于、刚好小于）
（1）产生的原因：在输入域的边界或边界附近，会有大量的缺陷。所以选择系统边界或者边界附近的数据来设计测试用例
（2）边界值的确定：
<1>规定了值的范围：选取刚达到这个范围的边界值、刚刚超过这个范围的边界值
<2>规定了值的个数：选取最大个数、最小个数、比最大个数多一个、比最小个数少一个
<3>给出输入域和输出域的有序集合（有序表、顺序文件）：选择第一个或最后一个
<4>使用内部数据结构:选取这个内部数据结构边界值上的值
3、决策表（判定表）：输入输出的依赖关系。如果动作项和条件项只用一个不同，可以合并
（1）基本原理：分析和表达多种逻辑条件下执行不同操作情况的工具。
（2）适用问题：对不同的逻辑条件的组合值，分别执行不同的操作
（3）决策表的4部分组成
<1>条件桩：列出问题的所有条件（与次序无关）
<2>动作桩：列出问题可能采取的操作（操作排列顺序无关）
<3>条件值：条件项的各种取值情况下采取的动作
<4>规则：任何一个条件组合的特定取值及其相应之星的操作
条件桩
条件项1 规则
条件项2
...
动作桩
动作项1 规则
动作项2
...
（4）决策表的分类
有限条目决策表：所有条件都是二叉条件（T/F）
扩展条目决策表：条件可以有多个
（5）决策表的使用范围
<1>规格说明书以决策表形式给出，或者容易转化为决策表
<2>条件、规则的排列顺序不会执行操作
<3>当某规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
<4>若某一规则要执行多个操作，这些执行顺序无关
（6）建立决策表的步骤
<1>确定规则的个数，若有n个条件，每个条件有两个取值(T/F)，则有2^n种规则
<2>列出所有的条件桩、动作桩
<3>填入条件项和动作项
<4>化简，合并相似规则或相似动作
（7）特点
<1>最严格、最有逻辑性的测试方法
<2>输入输出多、且相互制约条件多，使用决策表合适
<3>不是专门用于测试用例的设计方法，也可用在需求分析等方面
（8）优缺点
优点：复杂的问题按照各种情况一一列举，简明易于理解，可避免疏漏
缺点：不能表达重复执行的动作，如循环结构
4、因果图：输入（出）与输出（入）的约束，输出与输入的依赖关系，符合表示得到决策表
（1）产生背景：等价类和边界值都着重输入条件，没有开率输入条件的各种组合、输入条件之间的互相制约关系，多个输入条件组合起来可能出错
（2）概念：利用图解发分析输入的各种组合情况，适用于检查程序中输入条件的各种组合情况
（3）优点：将自然语言转化为形式语言规格说明的一种严格方法，可以指出规格说明存在的不完整性和二义性。
缺点:测试用例数目过大，不利于维护
（4）因果图的4中基本关系
在基本符号中，左节点ci表示输入状态（原因），右节点表示输出状态（结果），ci与ei取值为0或者1，0表示状态不出现，1表示状态出现
<1>恒等（没有标记）：若 c1 是1，则 e1 也为1，否则 e1 为0
<2>非（~）：若c1是1，则e1为0，否则e1为1
<3>或（∨）：若 c1 或 c2 或 c3 是1，则 e1 为1，否则 e1 为0
<4>与（∧）：若 c1 和 c2 都是1，则 e1 为1，否则 e1 为0
（5）因果图中的约束
输入状态相互之间，输出状态相互之间存在某些依赖关系，对于输入状态有E、I、O、R四种约束，对于输出条件只有M约束
<1>E约束（exclusive OR，异或）a,b不能同时为1
<2>I约束（In,或）a,b,c不能同时为0
<3>O约束（Only，唯一）a和b必须有一个且仅有一个为1
<4>R约束（recommand，要求）a为1时，b不能为0
<5>M约束（must，强制）若结果a为1，则结果b强制为0。
（6）因果图是决策表的前置过程，步骤为
<1>根据需求，列出输入和输出
<2>找出输入和输出的关系
<3>用约束表明输入和输出关系
<4>转化为决策表
<5>为每一列设计一条测试用例
5、正交实验：有效缩减测试用例的方法
查询、配置测试（硬件）
兼容性测试（软件）
（1）产生原因：决策表得到的测试数目大，利用正交实验可以减少测试用例。
（2）基本原理：从全面实验中挑选部分具有代表性的实验点，求出最佳工艺参数和工艺条件
（3）特性：均匀分散，整齐可比
直观印象：数据点均匀分布，每个面3个点，每条线1个点
（4）正交表的结构
L（n）（q^s）
n:实际测试用例的个数，对应正交表的行数
q：每个输入条件取测试数据的个数，对应正交表中每个 输入条件的取值个数
s：输入条件的总个数，对应正交表的列数
q^s:理论上全组合方式的测试用例个数，基于正交表的测试效率为n与q^s的比值
（5）等水平正交表的特点
<1>表中任一列，不同的数字出现的次数相同
<2>表中任意两列，各种同行数字对（水平搭配）出现的次数相同
（6）常用的标准表（相同水平正交表）
2水平：L4(23）,L8 (27）,L16 (215），…
3水平：L9 (34），L27（313），L81(340），…
4水平：L16 (45）,L64 (421）,L256 (485），…
5水平：L25（56）,L125(531）,L625 (5156），
各列中出现的最大数字相同 的正交表称为相同水平正交表
（7）混合水平正交表的性质
<1>表中任一列，不同数字出现次数相同
<2>每两列，同行两个数字逐层的各种不同水平搭配出现的次数是相同的，单不同列间组成的水平搭配种类和出现次数是不完全相同的
（8）正交表测试用例的步骤
<1>分析需求，找出相应的因子和水平
<2>选择合适的正交表
<3>把变量映射到表中
<4>加上可疑且没有在表中出现的组合
<5>正交表的每行作为一条测试用例
（9）全面实验和正交实验设计
全面实验：每个因素的每个水平都相互搭配进行实验（e.g 3因素4水平实验次数为4^3=64）
正交实验设计：利用正交表安排，（e.g 3因素4水平实验次数为16）
（10）选择正交表
<1>考虑变量的个数
<2>考虑变量取值的个数
<3>考虑正交表的行数
<4>取行数最少的一个，但不应小于最少测试用例数量
最少测试用例数量=∑（每列水平数-1）+1（e.g. 5个3水平的因子和一个2水平因子，表示为3^5*2^1，实验次数为5*（3-1）+1*（2-1）+1=12）
<5>因素数（变量），水平数（变量值）相符，因素数不相同，水平数不相同
（11）设计正交表的情况
因素数不同：在正交表公式中找到包含该情况的公式，如果有N个符合条件的公式，则选取行数最少的公式
水平数不相同：采取包含和组合的反射光hi选取合适的正交表
6、场景法：适合流程类的软件（ATM）基本流只有一个，备选流有多个
（1）基本思想
通过分析同一事件的不同触发顺序和处理结果，构成各个事件流，并基于这些时间的触发控制业务流程，形成多个不同场景，最终基于场景设计测试用例
（2）基本流和备选流
基本流:从系统的某个状态开始，经过一些列的状态变化后达到终止状态过程的最主要的一个业务流程
备选流：以基本流为基础，经过基本流的每个判定节点（包括条件判定和循环判定）÷满足不同的触发条件，导致的其他事件流（业务流程中的错误输入操作，可选的备选流）
（3）使用步骤
<1>根据业务流程创建基本流和备选流
<2>基于这些事件流构建场景，以满足测试完备和无冗余的要求
<3>根据场景设计测试用例
（4）基本流和备选流的对比
基本流 备选流
数目 1 1或多
初始节点位置 系统初始状态 基本流或其他备选流
结束节点位置 系统默认终止状态 基本流或系统其他终止状态
是否完整业务流 是 否，是执行片段
（5）场景设计的基本原则
1、最少的场景数等于事件流的总数（基本流+备选流）
2、基本流唯一
3、对应某个备选流，至少应该有一个场景覆盖，且在场景中应该避免覆盖其他备选流
7、状态迁移图：多个状态的场景（e.g. 电商订单）
（1）定义：一种基于产品规格分析，对系统的每个状态与状态相关的函数进行测试，通过不同的状态验证程序的逻辑流程。测试对象的输出和行为方式不仅手当前输入数据的影响，同时与测试对象之前执行情况或之前的输入数据或事件有关。一个系统，如果对同一个输入根据状态不同可以得到不同的输出，就是一个有限状态系统
（2）有限状态机
表示有限个状态以及在这些状态之家的转移和动作等行为的数学模型，可以用状态图，状态表，状态树表示
（3）状态迁移使用的场合：多状态的变化
（4）状态图的使用步骤
<1>根据需求得到主要的状态
<2>绘制状态迁移图
<3>画出状态迁移树
根据分支抽取规则，每个叶子节点形成一条测试用例
<4>抽取测试用例规则（每个状态至少到达一次）
（e.g.1.网上订票，此时订单处于“待支付”
2.顾客付款后，订单处于“已支付”
3.火车站取票后，订单处于“已出票”
4.检票后，订单处于“已使用”
5.上车前任何时间都可以取消自己的订票信息，如果已经支付了车票的费用，则可以退款，订单处于“已取消”）
8、错误猜测（探索性测试）
（1）概念：基于经验和直觉推测成语中存在的错误，从而针对性的设计测试用例
（2）基本思想：列举出程序中说有可能的错误和容易发生错误的特殊情况，选择测试用例。（比如：以前产品测试中曾经发现的错误，输入数据和输出数据为0的情况、输入表格为空格、输入表格只有一行等）
（3）错误猜测举例：输入字符文本框空格是否过滤，区分全角半角空格，html标签是否转换，需要二次密码验证时粘贴，密码加密显示，数据库中插入相同的记录是否有提示
（4）随机测试
测试中所有输入数据都是随机产生的，目的是模拟用户的真实操作，并发现一些边缘性的错误
（5）探索性测试
强调测试人员的主管能动性，抛弃繁杂的测试计划和测试用例，在碰到问题时及时改变测试策略
9、总结
（1）等价类：任何情况都要使用，可以对输入域或者输出域等价划分，尽量保证测试的完备性和无冗余性
（2）边界值:等价类测试的有效补充
（3）场景法：业务流程清晰的系统
（4）正交实验法：参数配置，兼容性测试，输入输出条件过多，减少测试用例的恕不，保证测试的均匀分布
（5）因果图、决策表：输入输出组合条件
（6）因果图：多状态变化
（7）错误推断法：后期追加测试用例
三、白盒测试——使用源代码做判定
（一）白盒测试概述
（1）白盒测试关注的对象
<1>源代码:直接查看源代码的规范性，并对照函数功能查找代码的逻辑缺陷，内存管理缺陷、数据定义和使用缺陷
<2>程序结构：通过函数调用图、算法流程图等找到程序设计的缺陷，或评价程序的的执行效率，以利于程序结构的优化
（2）优势
<1>针对性强，便于快速定位缺陷
<2>有助于代码优化和缺陷预防
<3>测试效率高，通过不同的白盒覆盖指标有助于衡量被测对象的覆盖程度
<4>在函数级别开始测试工作，缺陷修复成本低
（3）局限性
<1>对测试人员的技术要求高，需要有一定的编码能力
<2>成本高，白盒测试准备时间长
（4）适用阶段
<1>当被测对象为函数时
a.完成对函数代码的结构测试
b.主要关注函数源代码是否符合功能要求，是否有典型的编程缺陷，或优化的角度分析是否过于复杂
c.对应单元测试阶段，主要由开发人员完成测试工作
<2>被测对象为功能时
a.完成对业务流程的覆盖测试
b.对应集成测试或系统测试阶段，主要由测试人员完成测试工作
（5）测试方法的评价
<1>关注源代码中不同类型的结构，侧重点不同，对应原码覆盖程度也不同
<2>引入白盒测试覆盖指标来评估黑盒测试方法的测试覆盖率
（二）静态测试（不需要设计测试用例）
1、代码检查
2、静态结构分析
（1）基本原理
通过引入多种形式的图表（函数调用关系图、模块控制流图）帮助人们更好了解程序结构，找到优化方向
（2）函数调用关系图
<1>测试重点
函数之间调用关系是否符合要求
是否存在递归调用
函数调用层次是否太深
是否存在孤立的函数
<2>一般原则
优先测试根节点、叶子节点、接口数量多的节点
（3）函数控制流图
<1>测试重点
是否存在多出口情况
是否存在孤立语句
环复杂度是否太大
是否存在非结构化设计
3、代码质量度量
（1）模型:外部质量和内部质量模型
4、静态结构分析特点
（1）在原代码的条件下对程序进行分析
（2）通过代码评审、后续动态白盒测试来进一步对源代码进行测试覆盖，来找到更多潜伏的软件缺陷
（三）动态测试（需要测试用例）
1、基于判定的覆盖：
（1）语句覆盖（条件最弱）
<1>保证程序的每一条可执行语句至少执行一次（对程序流程图所有节点都进行覆盖）
<2>局限性：关注语句而非判定表达式，对隐式分支无效
（2）判定覆盖（分支覆盖）
<1>保证程序中每个判定节点的真假分支至少执行一次
<2>局限性：没有彻底分析每个简单判定条件的取值情况，会导致部分缺陷遗漏
（3）条件覆盖
<1>保证测试用例的每个符合判定表达式中每个简单判定 条件取真和取假的情况至少执行一次
<2>局限性：条件覆盖不能保证100%的判定覆盖
区分：判定覆盖和条件覆盖
判定覆盖只关心判定表达式的值（真/假），而条件覆盖涉及到判定表达式的每个条件的值（真/假）
（4）判定条件覆盖
<1>测试用例满足判定节点的真假至少执行一次，且每个简单判定条件的取真假至少执行一次，既满足判定覆盖+条件覆盖
<2>局限性:没有考虑条件组合的情况
（5）条件组合覆盖
<1>满足每个判定节点中所有的简单判定条件的所有可能的取值组合情况至少执行一次
<2>实质：通过列出真值表的方式来的到完全的覆盖，以冗余换取方法的简单性
<3>局限性：当判定表达式复杂却存在多个判定 节点串联，覆盖的测试用例规模大
（6）修正条件/判定覆盖
<1>在满足判定/条件覆盖的基础上每个简单判定条件都应独立底影响到整个判断表达式的取值
<2>实质：利用简单判定条件的独立影响性消除测试用例的冗余
（7）测试用例优化
尽量选择边界测试数据、尽量避免与或关系的屏蔽现象
2、基于路径的覆盖（独立路径覆盖）：控制流图（唯一的入口、唯一的出口，保证每个判定节点的出度为2）
（1）程序图
<1>压缩的控制流图
剔除注释语句
剔除数据变量的声明语句
所有连续的串行语句压缩为一个节点
所有循环次数压缩为一次循环
（2）计算环路复杂度（程序的环路复杂度应该不超过10）：
<1>封闭的区域+1
<2>边数-节点数+2（e-n+2）
<3>独立判定节点（两分支的判定）+1
（a.符合条件表达式需要转换为单个条件表达式
b.如果判定节点是n分支（n>2）,则该判定节点视为（n-1）个独立判定节点
c.若判断中条件表达式是由逻辑运算符(or,and)连接的符合条件表达式，则需要改为只有单条件嵌套的判断）
（3）基本复杂度
<1>概念：对程序图中的结构化设计节点进行不断压缩后得到一个无法压缩的程序图，该图的还复杂度 称为基本复杂度
<2>关注点：程序中所有非结构化的设计代码，包含测试优化的设计思想
<3>即使程序的环复杂度高，但是基本复杂度不高，说明程序多为结构化的设计，设计优，缺陷风险度低
（4）测试用例设计
<1>难点：确定独立测试路径集合的规模
从整个路径集合中抽取独立路径集合，以确保路径的独立性和独立路径集合的完备性
确保每条独立路径的可行性
从独立路径设计测试用例
<2>独立路径集合规模的确定
对路径的测试中所需独立路径结合大小等于程序图的环复杂度
<3>独立路径的抽取
a.确定主路径：包含尽可能多的判定节点、包含尽可能复杂的判定表达式、尽可能高执行概率、包含尽可能多语句
b.根据基础路径抽取其他独立路径
<4>不可行路径的处理（程序设计缺陷）
原因：构成判定表达式的多个简单判定条件之间存在一定关联，体现在多个简单判定 条件的取值互相约束，从而使得部分路径不可行。如果完全根据程序设计图来进行测试用例设计，会发现不可行路径，从而导致测试失败。
<5>测试用例设计
a.根据源代码生成程序图
b.计算程序图的环复杂度，确定独立路径集合的大小
c.一将最复杂的路径作为基础路径，通过覆盖所有判断分支确定其他路径，抽取独立路径集合
d.剔除不可行路径，必要时补充其他重要路径
e.根据得到的路径集合设计对应的测试用例
<6>测试分析
<1>独立路径测试保证了测试的完备性和无冗余性
<2>适用于多个判定节点串联和存在循环的情况
<3>避免引入不可行的节点
<4>基于程序图和环复杂度的独立路径测试仅关注测试的覆盖
（5）总结
对路径的测试可以用于任何动态模型
单元测试阶段：对程序源代码的执行测试
集成测试&系统测试：对业务流、页面跳转等动态执行路径的测试
3、基于循环的测试：
（1）基本原理
重点关注循环过程的正确性，在循环的边界和运行界限内对循环体之星过程的测试
（2）循环结构的分类
循环的串联、循环的嵌套、非结构化的循环
（3）难点
单个循环节点->循环次数的边界，保证循环的完整性
串联的循环节点->测试的全面性
非结构化循环->进行测试
（4）单个循环节点循环次数的测试
0次，1次，2次，正常次数（通常为最大次数的一半），n-1次，n次
（5）单个循环节点循环过程的测试
初始化、迭代、终止
（6）多个循环结构的测试
节点的串联
节点的嵌套：内min\max，外min\max
非结构化的循环
（7）总结
<1>循环测试一方面是对过程的静态检查，另一方面是对控制循环边界来观察执行结构是否与预期保持一致
<2>重点在于观察循环过程是否符合设计，并不考虑循环体所涉及的相关变量有何实际意义。
单个循环（0，1，2，···m(中间值)····n，n+1）
多个循环：串联、嵌套、非结构化循环
基于变量的测试：静态测试方法
四、单元测试：又称模块测试，主要是白盒的方法
（一）重点内容
1、主要依据：详细设计说明书
2、五个方面（静态&动态）
3、驱动模块和桩模块
4、单元测试自动化测试，需要单元测试框架
（二）概述
1、定义：对软件中最小可测试单元或基本组成 单元进行检查和认证
2、单元选取的原则
（1）面向过程的开发语言：一个函数或子过程
（2）面向对象：一个类
（3）图形化：一个窗口或一个菜单
（三）测试的内容
1、静态测试：走查、审查等会议方式，看代码是否符合要求
2、动态测试：模块接口、模块边界条件、模块独立路径和错误处理
<1>模块接口测试：考虑数据是否可以正确输入输出（主要关注单元中的输入和输出）
输入的实参形参在个数、属性等是否匹配
被测模块调用其他模块时，传递的参数属性是否匹配
是否存在当前入口点无关的参数引用
是否修改了只读形参
全局变量在各模块中的定义是否一致
<2>模块边界条件测试：在被测模块的输入/输出域边界或其附近设计测试用例
<3>独立路径测试：主要关注程序的逻辑分支问题
<4>所有错误处理路径：主要关注程序的逻辑分支问题。
3、驱动模块和桩模块的设计
（1）驱动模块（Driver）：模拟被测单元的上级模块，用于接收测试数据、启动被测模块和输出结果
（2）桩模块（Sub）模拟被测单元所调用的模块，有时需要使用子模块的接口，才能做少量的数据操作，并验证和打印入口出的信息，然后返回。桩模块不包含原模块的所有细节。
（3）适用条件：被测单元所调用的模块简单，不需要专门设计桩模块，直接与被测单元放在一起执行测试
（4）设计原则
<1>测试用例执行满足所有的环境因素
<2>使驱动模块和桩模块尽量能不经修改直接使用，提高重用性，提高回归测试效率
其体现在：结合已有的测试用例设计测试数据、驱动被测单元，将测试数据和测试脚本分离
（5）驱动模块的功能要求
<1>利用已有的测试用例接收测试的输入数据
<2>将测试数据传送给被测单元
<3>输出测试用例的相关结果，判断失败还是通过
<4>通过测试日志文件记录过程 ，便于后续数据的保存和分析
（6）桩模块的功能要求
<1>在特定 的条件下完成原单元测基本功能
<2>能够被正确调用
<3>有返回值
<4>不包含原单元的所有细节
4、测试需求分析
（1）测试需求是系统需求和测试用例之间的桥梁 系统需求->测试需求->细化的测试需求?->测试用例
（2）测试需求的属性
ID、所属功能模块、评审状态、重要性、稳定性、工作量、优先级、需求版本、功能点描述、业务规则描述、创建人、创建日期
（3）测试需求的分析
用户定义业务需求
系统分析师提取系统需求
测试人员提取测试需求
测试工程师设计测试用例
（4）测试需求：测试分析活动的产物
可测试性需求：需求分析活动的产物
（5）单元测试过程
计划（重在计划，不在于文档，即使更新）、设计（进度、测试粒度、测试密度）、实施阶段->执行阶段->评估阶段
5、日创建：自动完整的构建整个代码库的代码，在构建的同时完成单元测试执行的软件研发工作模式
优势：进度可见、可控、适用于多环境下的团队研发、便于尽早发现、修复和验证缺陷、增量测试
五、集成测试：又称组装测试，主要是黑盒+白盒测试
（一）概述
1、主要依据：概要设计说明书
单个集成测试用例设计
成对集成、邻居集成、独立测试路径集成
2、集成测试的遍历顺序
大爆炸集成，自顶向下，自底向上，三明治集成
3、集成测试是在单元测试的基础上，将所有已经通过的单元测试模块按照概要设计说明书的要求组装为子系统或系统，并进行测试的过程
4、集成测试的目的：确保各个单元模块组合在一起后能够按照既定的意图协作运行，并确保增量的行为正确
（二）集成测试的内容
1、将各个具有相互调用关系的模块组合起来，检查穿越模块接口的数据是否丢失
2、判断各个子功能组合起来是否可以达到预期的父功能
3、检查一个模块的功能时候会对其他模块的功能产生不利影响
4、检查全面数据结构是否正确，和在完成模块功能的过程中是否会被异常修改
5、单个模块的误差累积起来是否会放大到不可接受的程度
（三）集成测试的评价
1、单个集成测试用例设计
（1）成对集成思想：将每个集成 测试用例限定在一对调用单元上，每个集成测试用例 都是最小的集成单元，仅涉及一对接口的调用
优点：便于缺陷定位
（2）邻居集成思想：将每个集成 测试用例限定在某个节点的邻居上，针对某个模块的集成测试用例同时应该包括该模块和其邻居
（邻居：某个指定模块及其所有直接调用该模块的上层模块和下层模块）
（3）基于独立路径的集成：将函数调用图看作程序的控制流图或程序图，每个从根节点到叶子节点的调用形成了路径，每条独立路径即可构成一个集成测试用例
2、集成测试遍历顺序的设计
（1）大爆炸集成：将所有经过单元测试的模块一次性组装到被测系统中进行测试，不考虑模块之间的依赖性和可能的风险
（2）自顶向下的集成：从主控模块（主程序即根节点）开始，按照系统程序结构，按照控制层次从上而下，逐渐将各模块组装起来
优势：避免主控程序缺陷，确保开发进度
单个测试用例包含多个模块，可从整体上降低测试用例规模
采用递增方式展开测试，每个新的测试用例仅能增加一个新的模块，便于缺陷定位
不足：桩模块的开发和维护的工作量大
难以发现底层模块中复杂的算法缺陷
不利于测试的并行
（3）自底向上的集成：从底层模块（叶子节点）开始，按照调用图的结构，从下而上，逐层调用模块。
优势：从叶子节点开始测试有利于提前发现算法错误，降低了测试用例的规模，并行行好
缺点：驱动模块的开发维护工作量大，难以发现早期上层模块的逻辑控制缺陷，知道最后一个模块加入才能看到整个系统框架，难以早期发现时序问题和资源竞争问题
（4）三明治集成：将自顶向下和自底向上集成方法结合起来的集成策略。在调用图上按照一定的策略，分别自顶向下和自底向上展开集成，并在子树上进行大爆炸集成
<策略1>将系统划分为三层，中间层为目标层，测试时对目标层上面的层使用自顶向下的集成策略，对目标层下面的层使用自底向上的集成策略。
<策略2>基于策略1并对目标层采用独立测试策略，确保目标层模块在集成测试之前得到充分的测试
<策略3>对包含读操作的子系统自底向上集成测试直至根节点，然后对包含写操作的子系统自顶向下集成测试直至叶子节点
优势：结合了自顶向下和自底向上的集成的优势
不足：中间的目标层可能得不到充分的测试，需要同时开发桩模块和驱动模块，任务量大，子树进行大爆炸集成时当接口多时难以进行缺陷定位
六、系统测试：主要是黑盒测试
（一）概述
1、主要依据：需求说明书
2、测试方法：功能测试：对功能控件的测试
性能测试
安全测试
界面测试：统一性
安装测试：易用性测试、文档测试
3、概念：将经过良好集成测试的软件系统作为计算机系统的一部分，与硬件、外部设备、支持软件、数据和人员等其他系统元素结合在一起，在实际环境中对计算机系统进行一系列的严格测试。
4、系统测试与集成（单元）测试的区别：系统测试不仅限于软件，且系统测试不能够省略
（二）功能测试（系统测试中最基本的测试）
1、主要针对系统的功能需求，确认系统是否满足用户的使用要求
2、设计测试用例：系统输入、系统内部处理、系统输出
3、以数据为中心的系统，其核心是数据处理（从实体关系模型（1对1，1对多。。）、对数据的操作（增加、删除、查找、修改））结合黑盒（考虑所有输入输出的覆盖测试）、白盒的设计思想（有线状态机、由主业务所得到的业务流程图）
4、以活动为中心的系统，核心是活动序列（系统输入、输出、状态、出发状态的变迁事件）
（三）性能测试
1、对软件性能指标进行测试，判断系统集成使用环境知否稳定
2、主要考虑系统的时间（具体事物 相应时间）和空间性能（运行时消耗的系统资源）
3、主要内容：常规性能测试、压力测试（最大压力）、负载测试（侧重压力持续时间）、可靠性测试（平均 错误时间间隔越大，系统越稳定）、大数据量测试
（四）安全性测试
用于检验系统对非法侵入的防范能力
（五）兼容性测试 检验被测软件与其他软、硬件相互是否能够正确交互和实现信息共享
七、验收测试（交付测试）
（一）
1、主要依据：用户需求
2、测试方：用户
3、测试阶段
ahpha测试：请用户到公司内测试
beta测试：大规模不受控制测试
4、概念：在产品完成系统测试之后、产品发布之前所进行的软件测试活动，它是技术测试的最后一个手段
5、目的：确保产品准备就绪，并且可以让最终用户将其用于执行产品的既定功能和任务。
6、常用策略：
<1>项目软件的验收
<2>产品软件的验收
7、alpha（内部）测试
（1）软件开发公司组织内部人员模拟各类用户对即将面世的软件产品（称为α版本）进行测试，试图发现错误。由用户、测试人员、开发人员等共同参与的内部测试。
（2）关键：尽可能逼真模拟实际运行环境和用户对软件产品的操作，尽最大努力涵盖所有用户操作。
8、beta（公测）
完全交给最终用户测试。软件开发公司组织各方面的典型用户在日常生活中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
9、常用技术：黑盒测试、易用性测试、静态测试
八、测试管理
1、开发模型
（1）开发模型：软件开发的任务结构框架，给出了各个阶段之间的关系（从构思到公开发行）
（2）分类：
<1>软件需求完全确定为前提的第一代过程模型
<2>在开始阶段只提供基本需求的渐进式模型
<3>以体系结构为基础基于构建组装的开发模型
（3）常见开发模型
<1>大棒开发
优点：思路简单，通常可能是开发者的“突发奇想”
缺点：开发过程是非工程化的，随意性大，结果不可预知
测试：开发任务完成后，修复较困难
<2>边写边改法
优点：简单考虑到了软件的需求，产品周期短
缺点：没有计划和文档的编制
测试工作： 由于新的版本不断产生，测试工作长期循环
<3>快速原型法
根据客户需求在较短的时间内解决用户最迫切解决的问题。在得到用户的更加明确的需求之后，原型将丢弃。
（4）瀑布开发模型（适用于需求明确的软件，如操作系统、数据库管理软件）
<1>流程:如同瀑布流水，逐级下落
需求分析（需求说明书）
系统设计（系统设计书）
程序设计（程序设计书）
编码（程序清单）
测试（测试报告）
运行和维护（维护报告，改进的系统）
<2>特点：将软件生存周期各活动规定为线性顺序连接的若干阶段模型
<3>优点：易理解、阶段性、强盗需求分析、明确测试阶段、提供模板（文档驱动）
<4>缺点：
线性严格——成果晚出——风险
阶段固定——反复&迭代——灵活性
单次需求——需求变更——适应性
测试滞后——缺陷晚查——代价
（5）螺旋模型
每个开发阶段包括5个步骤
确定目标，选择方案
评估方案，解决风险
本阶段的开发和测试
计划下一阶段
确定下阶段方法
优点：严格的全过程风险管理；强调各开发阶段的质量；提供机会评估项目是否有价值继续下去。(发现问题早)
（6）敏捷开发
以人为核心、迭代、循序渐进的开发方法
2、测试模型
（1）测试的基本流程
制定测试计划：测试工作的整体规划
设计和生成测试用例：生成测试用例文档（测试输入、测试步骤、预期结果等内容）
搭建测试环境：真实、无毒、独立、干净
实施测试（提交缺陷报告）：初测、细测、回归期（复查已知错误的纠正情况）
测试评估和总结
（2）测试过程模型
<1>V模型：动态测试行为与开发行为对应，每个测试阶段的基础是对应开发阶段的提交物，通过低层测试确保源代码正确，满足整个系统的需求。（开发过程自顶向下，测试过程自顶向上）
局限性：测试滞后，测试与开发文档难以一一对应，缺少静态测试
<2>W模型：静态测试和动态测试伴随整个开发过程，并与开发行为对应，有助于早期发现缺陷/了解项目难度/评估测试风险
局限性：串行活动、不支持迭×××发、不具有测试流程的完整性
<3>H模型：测试流程独立于其他流程，与其他流程并发进行，只要测试准备工作完成就可以进行测试
<4>X模型：清晰地体现了单元测试→集成测试→系统测试的过程，该模型还能处理开发中包括交接、频繁重复的集成等工作，更加贴合实际的项目开发流程
<5>综合策略：
宏观:W模型（开发测试并行过程）
微观：H模型（独立测试）
存在不确定因素：X模型（分离编码与测试）
3、用例管理
（1）用例报告的书写
标题、优先级、输入、操作步骤、输出预期、测试环境
根据需求来写用例，没有代码
（2）测试结果
Pass、Fail、Warning、block、skip
（3）测试用例的组织和跟踪
整理模块需求、撰写测试计划、设计测试思路、编写测试用例、评审测试用例、修改更新测试用例、执行测试用例、分析评估测试用例质量
（4）测试用例更改更新策略
<1>若新版本特性无变化，只是出现缺陷被用户发现的情况，此时可以修改测试用例，并给出变更记录。且当前修改的测试用例，对目前和以前的版本都有效 <2>若新版本中原有的功能取消，此时需在新版本上将对应测试用例设置为无效 <3>若新版本中原有的产品特性发生变化，但属于功能增强，则原有测试用例仅对原版本有效，此时不能修改测试用例，只能增加新的测试用例，新增测试用例仅对当前版本有效
4、测试管理工具：bugfree
5、缺陷管理
（1）定义（5个）
<1>出现未达到需求规格说明书中指明的功能
<2>出现需求规格说明书中指明不会出现的错误
<3>功能超出规格说明书的范围
<4>未达到规格说明书中没要求但应该达到的要求
<5>测试人员认为软件难以理解、不易使用、运行速度慢、用户体验不佳。
（2）缺陷报告组成
优先级、指派、严重程度、可重现性
（3）注意事项：保证重现
（4）缺陷报告的生命周期（流程）
（测试人员、项目经理、程序员）
提交测试报告 测试人员
|
处理缺陷报告 开发人员
|
返测？ 测试人员
|
关闭测试报告
九、冒烟测试和回归测试（两者都在新版本发布之前进行）
冒烟测试：主要测试功能（在回归测试之前完成）
回归测试：任何阶段都会有，新版本发布时做
十、测试文档
测试计划
测试用例
缺陷报告
测试总结报告
十一、测试能力
1、软件测试的发展阶段（TMM(Testing Maturity Model)，测试成熟度模型）：
第一阶段：初始阶段
措施：测试是完全混乱无序的，测试等同与调试，编码完成后随意测试调试，目标是表明软件奏效的。
优势：省力
弊端：开发出的产品没有质量保证，存在很多弊端
第二阶段：定义阶段
措施：测试不同于调试，将测试定义为编码后的阶段和工作，所有测试都是依赖于代码的执行，只有当编码完成后才进行测试
优势:掌握了一定的测试技术和方法，可以取得一定的效果
弊端：在需求和设计中没有测试，大量缺陷扩散到代码中，开发出的产品依然会有较多的缺陷
第三阶段：集成阶段
措施：将测试集成到整个软件的生存周期，开始考虑客户和用户的需求来建立测试目标，将测试看做专业化的活动，成立专门的测试组织，有基本的测试工具
优势：基于技术的测试，效果更好
弊端：在整个软件生存周期中没有建立正式的评审程序，没有开展评审活动，测试组应付
第四阶段：管理、测量
措施：测试成为一个可以测量和量化的过程，开发过程引入评审机制，测试用例过程被管理起来
优势：基于规范的测试，拥有流程控制，出现质量管理活动
弊端：缺陷寻找过于被动
第五阶段：最佳化
措施：建立缺陷预防的思想，通过统计抽样的方式不断改进测试，自动工具完全支持
优势：机制完善，不断改进测试，可以度量和优化产品质量
2、CMM：能力成熟度模型 (Capability Maturity Model)
是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
五级模型：
（1）初始级
特点是软件过程无秩序，有时甚至是混乱的。软件过程定义几乎没有章法和步骤可循，软件产品所取得的成功往往依赖极个别人的努力和机遇
（2）可重复级
已建立了基本的项目管理过程，可用于对成本，进度和功能特性进行跟踪。对类似的应用项目，有章可循，并能重复以往所取得的成功。
（3）定义级 （标志着软件能力“成熟”）
用于管理的、工程的软件过程均已实现文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均已采用与实际情况相吻合的、适当修改的标准软件过程来进行。
（4）定量管理级（有明确的度量指标）
软件过程和产品质量有详细的度量标准，软件过程和产品质量得到了定量的认证和控制。
（5）优化级
通过对来自过程、新概念和新技术等方面各种有用信息的定量分析，能够不断地、持续性的对过程进行改进。
十二、软件测试停止的依据
（一）缺陷修复率标准
一、二级：100%
三、四级：80%
五级以上：60%
（二）覆盖率
语句覆盖率大于80%
用例执行覆盖率100%
需求执行覆盖率100%
参考资料： [1]Paul Ammann，软件测试基础[M]，机械工业出版社，2017.1
标签：测试工程师 外部 模式 接收 公司 共享 关闭 方案 很多
原文地址：http://blog.51cto.com/xuan97916/2063156
