总结自老师的PPT，不只有知识点，还有一些相关内容的介绍顺便复制进来了，自己感兴趣就想多了解一些。 如有问题请多指教
定义：
开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。
经验：
以会议的形式，制定会议目标、流程和规则，结束后要编写报告。相关资料要在会议前下发并阅读。
参加人员
由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表、本模块开发者回答问题并记录
检查要点
对等技术评审是由与工作产品开发人员具有同等背景和能力的人员对工作产品进行的一种评审，
目的是早期和有效的消除软件工作产品中的缺陷，并可对软件工作产品和其中可预防的缺陷有更好的理解。
基于代码的测试
白盒测试-基本逻辑覆盖技术
选择足够的测试用例，使得程序中每一条可执行语句至少被执行一次。
语句覆盖率＝（至少被执行一次的语句数量）/（可以执行的语句总数）
例
选择足够的测试用例，使得程序中每一个判断的每一种可能结果都至少被执行一次。判定覆盖也叫分支覆盖。
判定覆盖率＝（判定结果被评价的次数）/（判定结果的总数）
例
选择足够的测试用例，使得程序中每一个判断中的每一个条件的可能结果都至少被执行一次
条件覆盖率＝（条件操作数值至少被评价一次的数量）/（条件操作数值的总数）
例
选择足够的测试用例，使得同时满足判定覆盖和条件覆盖。
判定条件覆盖率＝（条件操作数值或者判定结果至少被评价一次的数量）/（条件操作数值总数+判定结果的总数）
例
选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的每一种可能组合（分支条件组合）结果都至少被执行一次
条件组合覆盖率＝（被评价的分支条件组合数量）/（分支条件组合总数）
条件组合覆盖是前述几种覆盖标准中最强的。满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。
但是，条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到。（测试数据都没有测试到1453 ）
选择足够的测试用例，使得程序中所有的可能路径都至少被执行一次。
路径覆盖率=（至少被执行一次的路径数）/（总的路径数）
判断（决策）到判断（决策）的路径
判断（决策）：一个序列语句
DD路径覆盖率=（至少被执行一次的决策路径数）/（系统中总的决策路径数）
E.F.Miller发现：
DD-路径覆盖可以发现全部缺陷的85%
线性独立路径数：V(G)=e-n+2
规则1 :A rel B:Rel为<、＝、>
A <B 、 A =B 、 A >B分别出现一次 （检查rel错误）
规则2 :A rel C:Rel为< 、 >; A 是变量，C是常量
Rel为<时,适当选择A,使A= C-M
Rel为>时,适当选择A,使A= C+M
M为距C最小的允许正数。（检查差1错误）
规则3 :对外部输入变量赋值,使其每一测试用例均有不同的值和符号，并与同一组测试用例中其它变量的值与符号不一致。
IF (I=0) 错写为IF (I>0)
IF (I > 1) 错写为IF (I > 0)
IF (I=X) 错写为IF(I＝0)
需求1
程序的入口点和出口点都必须至少执行一次，程序的判断结果至少被覆盖一次。
需求2
程序的判断被分解为基本的布尔条件表达式，每个条件独立的作用于判断的结果，覆盖所有条件的可能结果。
例
基于需求的测试
需求的覆盖率=（被验证的需求的数量）/（总的需求的数量）
测试原理
例：一个程序输入变量为X1和X2，其取值范围分别为：a<=X1<=b ，c<=X2<=d
边界值
边界值
多缺陷假设
两变量函数的最坏情况测试用例：
两变量函数的健壮最坏情况测试用例
所谓等价类，是输入条件的一个子集合，该输入集合中的数据对于揭示程序中的错误是等价的。
等价类又分为有效等价类和无效等价类。有效等价类代表对程序有效的输入，而无效等价类则是其他任何可能的输入（即不正确的输入值）。
有效等价类和无效等价类都是使用等价类划分法设计用例时所必须的。因为被测程序若是正确的，就应该既能接受有效的输入，也能接受无效输入的考验。
例如：三角型测试
｛5,5,5｝与｛10,10,10｝是一个等价类
(1) 若输入条件规定了取值范围或值的个数的情况下，可划分为一个有效等价类和两个无效等价类；
Eg.设置风控指标，其中权重设置范围在[-1000,1000]
(2) 若输入条件为布尔表达式，可划分为一真一假的有效等价类与无效等价类；
Eg.设置产品信息，其中产品份额必填
(3) 若规定了输入数据必须要遵循的原则，可划分为一个有效等价类（符合规则）和若干个无效等价类；
Eg.系统的初始资金只可输入数字
(4)若只要求输入数据符合某几个原则，这时可能存在多个有效类和若干个无效等价类；
Eg. 交易用户登录密码只可输入数字、字母及部分特殊符号，不能输入单/双引号及汉字
(5)若规定了输入数据的一组值（假定n个），且程序对不同输入值做不同处理，则可划分为n个有效等价类（每个允许的输入值为一个有效等价类）和一个无效等价类（所有不允许的输入值的集合）。
Eg. 设置资金账户时，必须选择是否检查自成交
Eg.输入条件规定学历可为:本科、硕士、博士三种之一
(6)在确知已划分的等价类中各元素在程序中的处理方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
(1) 划分等价类后，建立等价类表，并为每一个等价类规定一个唯一的编号；
(2) 设计一个测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步骤，直到所有的有效等价类都被覆盖为止；
(3)设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止。（因为用单个测试用例覆盖无效等价类，是因为某些特定的输入错误会屏蔽或取代其他输入错误检查）
例：三角形等价类划分。
弱：代表单缺陷假设；
强：代表多缺陷假设；
一般：代表只包含有效等价类；
健壮：代表除包含有效等价类，还包含了无效等价类。
例如：函数F实现一个程序，它有两个输入变量X1和X2，
则，变量X1和X2的无效等价类分别为：
单缺陷假设
多缺陷假设
单缺陷假设
无效输入
多缺陷假设
无效输入
根据相关规范描述来设计测试用例
例如一个计算平方根函数的规格如下：
测试用例
在经验的基础上，测试设计者猜测错误的类型以及特定的软件中的错误的位置，并设计用例来发现他们。
例：
年龄：应该是大于0的数字
点数:应该是〔0,12〕的数字
证明某个规定的故障不存在于代码中。
例如： 对初始参数进行错误配置
测试例子
第一个字符A或者B，第二字符是数字，则更新文件；如果第一个字符不正确，则产生X12信息；如果第二字符不正确，则产生X13信息
因（输入）
1：第一字符A
2：第一字符B
3：第二字符是数字
果（输出）
70 ：更新文件
71 ：产生信息X12
72 ：产生信息X13
.通过决策表也可以设计测试用例进行黑盒测试
此时，将条件理解为输入，将动作理解为输出
例：NextDate函数
所谓场景就是事务流，主要用在于事件触发流程中，当某个事件触发后就形成相应的的场景流程，不同的事件触发，不同顺序和不同的处理结果，就形成一系列的事件流结果。
通过分析设计模拟出设计者的设计思想，即整理出充分的场景，同时也较紧密地体现了被测系统的业务关系。
事务流分为：基本流和备选流，
例子
例
ATM取款例子-基本流
用例开始： ATM 处于准备就绪状态。 准备提款 - 客户将银行卡插入 ATM 机的读卡机。.
验证银行卡 - ATM机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。
输入 PIN - ATM 要求客户输入 PIN 码（6 位）
验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN
对该帐户来说是否正确。对于此事件流，帐户是有效的而且 PIN 对此帐户来说正确无误。
ATM 选项 - ATM显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。
输入金额 - 要从 ATM中提取的金额。对于此事件流，客户需选择预设的金额（100元、200元、500元、1000元、2000元）。
授权 - ATM 通过将卡ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。
出钞 - 提供现金。
返回银行卡 - 银行卡被返还。
收据 - 打印收据并提供给客户。ATM 还相应地更新内部记录。
用例结束： ATM 又回到准备就绪状态。
ATM取款例子-备选流
备选流 1 - 银行卡无效
备选流 2 - ATM 内没有现金
备选流 3 - ATM 内现金不足
备选流 4 - PIN 有误
备选流5 - 帐户不存在
备选流 6 - 帐面金额不足
备选流 7 - 达到每日最大的提款金
备选流8- 记录错误
备选流 9 -退出客户可随时决定终止交易（退出）。
备选流 10 - “翘起”ATM包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。
ATM取款列子—场景
场景 1 - 成功的提款：基本流
场景 2 - ATM 内没有现金：基本流、备选流 2
场景 3 - ATM 内现金不足：基本流、备选流 3
场景 4 - PIN 有误（还有输入机会）：基本流备选流 4
场景 5 - PIN 有误（不再有输入机会）：基本流、备选流4
场景 6 - 帐户不存在/帐户类型有误：基本流、备选流 5
场景 7 - 帐户余额不足：基本流、备选流 6
ATM取款列子—测试用例
测试用例一经认可，就可以确定实际数据值。
电话接续UNI信令基本流程
如何设计电话呼叫处理流程的测试用例？
局内正常呼叫基本流
测试过程按测试级别（有小到大）进行；
测试过程和开发过程是一个相反的过程
静态分析
定义：
对软件基本组成单元进行的测试，检验程序最小单位有无错误。
单元测试的角度
任务1、模块接口测试
任务2、模块局部数据结构测试
任务3、模块边界条件测试
任务4、模块独立执行路径测试
任务5、模块内部错误处理测试
测试设计：
原则：
逻辑覆盖测试方法
单元测试证明每个独立的模块没有问题，但所有模块组合在一起可能会出现问题。
定义
灰盒测试方法（白+黑）
常用技术：
前期测试可以保证软件功能正确，但不能确认在实际运行时，是否满足用户需求，是否会出现错误。
定义：系统测试是将集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对系统进行一系列的组装测试和确认测试。
目的
为了发现缺陷并度量产品质量，按照系统的功能和性能需求进行的测试
1、功能测试
目标：对产品的功能进行测试，检验是否实现、是否正确实现
方法：覆盖产品的功能
2、协议一致性测试
目标：监测实现的系统与标准协议的符合程度
方法：
3、性能测试
目标：对产品的性能进行测试，检验是否达标、是否能够保持
方法：覆盖系统的性能需求，一般和负载测试结合使用
4、压力测试
目标：在人为设置的系统资源紧缺情况下，检查系统是否发生功能或者性能上的问题
方法：人为减少可用的系统资源，包括：内存、硬盘、网络、CPU占用、数据库反应时间…
5、容量测试
目标：在人为设置的高负载(大数据量、大访问量)的情况下，检查系统是否发生功能或者性能上的问题
方法：人为生成大数据量，并利用工具模拟频繁并发访问
6、安全性测试
目标：检查集成在系统内的保护机制是否能够在实际中保护系统不受非法的侵入。
方法：一般与功能测试结合使用
7、恢复测试
目标：验证系统从软件或者硬件失败中恢复的能力。
方法：在人为使发生系统灾难(系统崩溃、硬件损坏、病毒入侵等)的情况下，检查系统是否能够恢复被破坏的环境和数据。
8、备份测试
目标：验证系统从软件或者硬件失败中的事件中备份数据的能力。
方法：参考恢复测试方法
9、GUI测试
目标：界面实现与界面设计的吻合程度，确认界面处理的正确性。
方法：
10、兼容性测试
目标：测试应用对其他应用或者系统的兼容性
方法：
11、可用性测试
目标：检查系统界面和功能是否容易学习、使用方式是否规范一致，是否会误导用户或者使用模糊的信息
一般与功能测试结合使用
方法：可以采用用户操作、观察(录像)、反馈并评估的方式
12、安装测试
目标：验证成功安装系统的能力。
方法：在不同的硬件配置下，在不同的操作系统和应用软件环境中，检查系统是否发生功能或者性能上的问题。
13、文档测试
目标：验证用户文档是正确的并且保证操作手册的过程能够正确工作。
方法：一般由单独的一组测试人员实施
规范导出
14、在线帮助测试
目标：检查系统的实时在线帮助的可用性和正确性
方法：规范导出法
15、数据转换测试
目标：验证已存在数据的转换并载入一个新的数据库是否有效
方法：规范导出法
当系统测试完成之后，可以确信已经满足了需求规格说明书的要求，那用户是否满意呢？
以用户为中心进行测试，是用户自己完成测试并评估的过程。必要时，开发人员给予支持。
分为：
定义测试需求，测试策略，测试资源和进度计划等。
详细说明被测软件的工作情况，指出测试范围和任务。
人力资源–测试经理
人力资源–测试工程师 (设计者/开发者)
人力资源–测试工程师 (测试执行者)
人力资源–测试系统管理员
系统资源
定义测试的具体方案，设计测试用例、构造测试过程
构造测试过程
覆盖的度量标准
对在测试设计阶段已被定义的测试案例进行创建或修正的阶段（例如：脚本编写以及注意事项）。
创建测试脚本
创建测试脚本应注意：
创建外部数据集
调试测试脚本
使用外部数据集的好处：
对被测软件进行一系列的测试并记录日志结果的阶段（环境准备、意外处理、结果分析）。
针对不同的测试目的构造不同的测试环境；
测试环境的构造应最大程度上有利于自动化；
测试环境应能够很好的接受测试的输入；
测试环境应能够把测试执行的结果反馈给测试人员；
配置输入条件；
按用例执行步骤执行用例；
仔细观察每个可能的输出结果，与期望结果比较，记录差异点；
发现可能的缺陷；（由于用例不可能遍历每个可能的输出，因此不同的人在执行同一个测试用例的时候，可能会得到不同的结果，这是一个经验的积累）
避免用例之间的干扰，排除人为产生的错误；
隔离缺陷，协助开发人员定位问题；
如实的记录每个缺陷，缺陷信息应当详尽，避免歧义，并利于问题的重现；
正常：所有的测试过程或测试标准按计划结束
不正常：测试失败或未达到预期的测试覆盖
如何从失败中恢复：
记录缺陷
追踪缺陷
记录测试事件或用户问题，进行调查研究，提出解决它们的方案并进行修改的阶段。
在测试执行过程中，每天都应当记录测试执行日志，一般测试执行日志应当包含下列内容：
工具：例如Buggit
分析测试结果并判断测试的标准是否被满足的阶段。
覆盖判定：
确保100%的测试用例全部成功地执行
制定测试覆盖标准，考虑：
常用的缺陷分析标准：
确定标准：
软件测试过程的文档
测试生命周期
测试文档
