测试学习笔记（P1-P34教程from凡云教育）
温馨提示：
笔记仅供参考，并非课程全部内容，课程参见https://www.bilibili.com/video/BV13Q4y127ac
另：个人感受，就目前已学部分，讲授不够清晰、精准、易懂（相较于柠檬测试的华华老师）但胜在全面、又白嫖。
P2：
软件测试概念：软件测试是使用人工或自动得的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
P6
MCP：minimal concept principal 最小概念原则
P10
单元测试：对程序的最小单元进行测试的过程，最小单元指函数或者是一个类的代码
集成测试：对模块与模块之间调用的接口进行的测试叫集成测试
系统测试：对完成编译的系统整体进行测试的过程（UI、功能、兼容、性能、安全等）
验收测试：交付给客户或者最终用户时，和客户一起完成的测试
P12
软件测试模型：
传统瀑布模型：测试后置，存在有问题修改成本巨大的风险
V字模型：主要特点是将测试过程细化，分为了单元、集成、系统、验收测试四个阶段，但仍然是测试后置，没有解决风险巨大的问题。
W模型：将测试和开发分离出来，对整个项目过程中的需求文档、设计文档进行测试，将测试工作前置，大大降低整个项目的质量风险
敏捷模式：为了适应现代互联网公司的短频快的开发节奏而设计的一种测试和开发的模型。
迭代：每次迭代叫一个sprint，每个sprint里面选出要实现的需求会安排到sprint backlog里面。每个spring一般是以一个月为周期；
Product owner: 相当于是产品经理。整理出整个项目的所有需求，并且按照需求的优先级来将需求排列到product backlog；
Daily meeting:每日议会，站会形式居多。没人发言不超过一分钟，主要内容是昨天做了什么、今天要做什么、有什么风险和问题；
Spring burndown: 迭代燃尽图，记录剩余工作量有多少。
Sprint review meeting: 迭代回顾会议，回顾本轮迭代中存在的问题，后续如何改进
Scrum Master: 相当于组长，team manager ,统一管理组员。
P16
软件质量模型
P17 水杯测试
功能性、可靠性、易用性、安全性、可移植性、兼容性、性能效率、可维护性
P18
灰盒测试：一般指接口测试
P19
测试流程
分析：需求评审、测试需求分析，得到测试点
计划：测试计划和方案文档编写
设计：测试用例设计
实现：编写测试用例、测试脚本
执行：搭建测试环境，执行测试脚本、报告缺陷
P20
测试需求分析流程：
根据产品需求提取系统测试点
编写需求跟踪矩阵
根据测试点利用适当的测试用例设计方法设计测试用例
测试设计概念：
将测试点转换成测试用例的过程，就叫测试设计。
测试用例概念：
一种用来说明具体如何进行测试操作并验证结果的文档。
P21
世界上最好的测试方法：穷举法
等价类法：某个输入域的集合，在这个集合中每个输入条件都是等效的，如果其中某一个输入不会导致问题，则集合中其他输入条件进行测试也不可能发现问题。
有效等价类：对程序有意义、正确的输入数据
无效等价类：对程序五意义、不正确的输入数据
分类原则：
1.如果输入条件规定了取值范围或值的个数，则可以确定一个有效等价类和两个无效等价类
2.输入条件规定了输入值的集合，或者是规定了必须如何的条件，则可以确定一个有效等价类和一个无效等价类
3.输入条件规是一个布尔值时，则可以确定一个有效等价类和一个无效等价类
4.如果我们确知，已经划分的等价类中个元素在程序中的处理方式不同，则应该将次等价类进一步划分
5.在规定了输入数据必须遵守的规则的情况下，可确定一个有效等价类（遵守规则）和如若干个无效等价类（从不同的角度违反规则）
P22
编写等价类表：
1.编写等价类表，为每个输入划分等价类，得到等价类表，为每个等价类规定一个唯一编号；
2.设计一个测试用例，使其尽可能多的覆盖所有尚未覆盖的有效等价类。重复这一步骤使得有效等价类均被测试用例所覆盖
3.设计一个测试用例，使其只覆盖一个无效等价类。重负这一步骤使得所有无效等价类均被覆盖
P24
边界值法
对程序的输入和输出边界进行测试的一种黑盒用例设计方法，常与等价类设计法结合使用，此时它的用例来自于等价类边界。
边界值分析法的理论基础是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附近的取值不会导致程序出错，那么其他的取值导致程序错误的可能性也很小。
上点：边界上得点
离点：离边界最近得点
内点：取值域内的任意一点
离点是看得见的值。每个点是不同的数字，是上点肯定不是离点了，看例子：
1.18=< age <=60
17,(18,19 59,60),61
2.20<age<80
19,20,(21 79),80,81
例1 中，18、60是上点，17、61是离点；
例2 中，20、80是上点，21、79是离点；
P25
输入项之间有关联关系
判定表法：分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确
条件桩 条件项
动作桩 动作项
判定表法设计步骤：
1.确定规则个数，2的条件个数次幂个规则
2.列出所有条件桩和动作桩
3.填入条件项、动作项
4.简化合并
5.将每条规则转化为测试用例
只有等价类才能得到测试数据，其他测试方法只能给到规则
P26
流程分析法：
（场景设计法）是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。根据流程的顺序依次进行组合，使得流程的各个分支都能走到。这是从白盒测试中路径覆盖分析法中推广到黑盒测试中来的测试分析方法。
流程分析法步骤：
画出业务流程图；
设置功能路径优先级；
确定测试路劲；
选取测试数据；
构造测试用例；
Draw.io在线画流程图工具
P27
错误推断法
P28 测试思路
1.首先检查界面元素的显示是否正确；
2.测试页面的基本功能。如果页面既有表单也有列表，则优先测试表单功能是否正常；
3.针对表单在测试时，需要根据表单里面的每个字段一次进行测试。凡是用户可输入的输入域，都要使用等价类和边界值根据字段的约束来进行考虑；
4.如果多个字段之间有关联关系和制约关系，那么在测试完单个字段的等价类和边界值之后，应该继续使用判定表等方法进行组合的测试；
5.表单测试完后，再测试列表中的功能；
6.当单个页面的内容测试完之后，再结合流程分析法测试流程相关的内容；
7.流程分析测试完之后，再结合错误推断法来确保没有遗漏的测试点。
P29
需求跟踪矩阵
根据产品需求、测试点、测试用例，建立一个需求、测试点、测试用例三者之间的映射关系，方便进行用力需求覆盖率统计；如果发生需求变更，可以根据需求跟踪矩阵快速定位哪些测试用例需要更新。
P30
缺陷的定义：
软件没有实现产品的说明书所描述的功能；
软件实现了产品说明书不应该有的功能；
软件执行了产品说明书不应该有的功能；
软件没有实现产品说明书没讲但应该有的功能；
从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。
P31
缺陷报告编写：
缺陷编号、用例编号、测试模块、预置条件、BUG标题、测试步骤、预期结果、实际结果、缺陷状态、严重程度、优先级、重现率、指派人、环境、软件版本、测试日期、测试人、附件
P32
缺陷的严重程度分类：
缺陷状态迁移表
如何处理不能重现的缺陷：一定要提出来
1.一定要详细地描述遇到缺陷的过程和环境配置；如果有日志，一定要附上相关的操作日志或者系统运行日志
2.对于不可重现的缺陷，一定要尽量描述清楚复现率多大；
3.对于不可重现的缺陷，开发修复后，测试在验证时，不能只在一个版本上验证缺陷是否修复，必须至少在三个以上版本上验证后没有重现过，才能将缺陷关闭。
P33
回归测试与验收测试
回归测试（regression test）是指修改了旧代码后，重新进行测试以确认修改有没有引入新的错误或导致其他代码产生错误。回归测试可以发生在任何一个阶段，包括单元测试、集成测试、系统测试。
回归测试流程：
1.在测试策略制定阶段，制定回归测试策略；
2.确定需要回归测试的版本version，在哪个版本修改在该版本回归；
3.回归测试版本发布，按照回归测试策略执行回归测试；
4.回归测试通过，关闭缺陷报告单；
5.回归不通过，缺陷报告单返回开发，开发人员重新修改问题，再次提交给测试人员回归测试
完全回归：重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响
选择性回归：有选择性地重新执行部分前期测试阶段建立的测试用例，来测试被修改的程序
选择性回归测试策略：
覆盖修改法：针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。
周边影响法：该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它们没有受到不良影响。该方法比覆盖修改法更充分一些。
指标达成法：这是一种类似单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改相关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。
验收测试：
在通过内部测试后进行，是以用户为主的测试，验收组由项目组成员、用户代表组成；原则上在用户所在地进行，但如果经用户同意也可以在公司内模拟用户环境进行；根据合同、需求规格说明书、验收测试计划对成品验收；对产品型项目，验收测试一般又分为α和β测试。
α测试（内测）
用户在开发开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试；
软件在一个自然设置状态下使用。开发坐在用户旁，随时记下错误情况和使用中的问题。这是在受控环境下的测试
该测试目的是评价软件的FLURPS（功能性、局域化、可用性、可靠性、性能和技术支持等）
β测试（公测）
软件的多个用户在一或者多个用户的实际使用环境（生产环境）下进行的测试；
该测试开发不在场，在不受控制的环境下进行；
目前很多互联网公司也称为灰度测试；
