测试的基础知识
软件：控制硬件工作的工具。
软件测试 ：使用技术手段验证软件是否满足使用需求。
软件测试目的：减少软件缺陷，保证软件质量。
测试主流技能 ：功能测试、自动化测试、接口测试、性能测试
功能测试：验证程序的功能是否满足需求
自动化测试：使用代码或工具代替手工，对项目进行测试
接口测试：使用代码或工具验证程序中的接口是否访问正常
性能测试：模拟多人使用软件，查找服务器缺陷
软件生命周期： 计划阶段------需求分析------软件设计------软件编码------软件测试------运行维护
测试用例要理解透彻，要看测试重点，满足实际状态，测试的工作不怕问，对用例理解对了，测试才有意义。
测试分类
单元测试 ：也就是白盒测试，测试编码是否符合设计要求。软件中最小的测试单元。
集成测试 ：又称接口测试，对模块之间访问地址进行测试，对程序接口进行测试
系统测试 ：对整个系统进行功能、兼容、文档等测试，也就是对功能进行测试
验收测试 ：就是模拟客户进行测试，确保各部分功能正常运行，确保产品满足合同或用户所规定需求的测试。包括Alpha测试和Beta测试。
Alpha测试：是由用户在开发者的场所来进行的，在一个受控的环境中进行。
Beta测试：不是受控活动，因为它发生在用户身边。在将软件交付给客户之前，它视为最终测试。发布用于beta测试的软件称为测试版软件。
白盒测试 ：又称结构测试、逻辑驱动测试或基于程序本身的测试 ，着重于程序的内部结构及算法，通常不关心功能与性能指标。
黑盒测试 ：又称功能测试、数据驱动测试或基于规格说明的测试 ，站在用户的立场上检验输入输出信息及系统性能是否符合规格说明书中有关功能需求及性能需求的规定。
回归测试 ：验证以前发现和修复的错误是否在新软件版本上再次出现，在缺陷修复之后的检验测试，是软件维护阶段对软件修改后进行的测试，指修改了旧代码后，重新进行测试以确认没有引入新的错误或导致其他代码产生错误。
冒烟测试： 是版本验证测试 ，主要确认新的版本是否存在致命性bug，功能可以正常运行（不会出现跑不通的状况），不会影响下一轮测试的进行，如果上述都符合那么这个版本就可以进行下一轮测试。
确保主功能可以跑通 。确保开发人员修复了 bug 后，这个 bug 的修复没有影响到其他功能模块 。冒烟测试是否通过决定了下一轮系统测试是否可以执行。
黑盒测试方法
等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法
1、对穷举场景设计测试点
2、对限定边界规则设计测试点
3、对多条件依赖关系设计测试点
4、对项目业务设计测试点
等价划分法--->解决穷举场景问题
分类：
有效等价：满足需求的数据集合
无效等价：不满足需求的数据集合
步骤：
1、明确需求：分析需求、拆规则
2、划分有效等价和无效等价
3、根据有效和无效等价提取数据并编写测试用例
适用场景：
需要有大量数据测试输入，但是没法穷举测试的地方
·输入框
· 下拉列表
· 单选复选框
典型代表：页面的输入框类测试
边界值分析法--->解决边界规则问题
边界范围节点：--->两点范围内最多7条案例，可优化为5条
上点：边界上的点（正好等于）【必选】
离点：距离上点最近的点（刚好大于、刚好小于）【开内闭外】开区间选择内部离点，闭区间选择外部离点
内点：范围内的点（区间范围内的数据）【必选】取中间范围
步骤：--->等价划分法与边界值分析法一起使用
1、明确需求
2、确定有效等价和无效等价--->针对类型
3、确定边界范围值--->针对长度
4、提取数据并编写测试用例
典型代表：有边界范围的输入框测试
判定表法--->解决多条件依赖关系测试问题
定义：一种以表格形式表达多条件逻辑判断的工具
组成：条件桩：列出问题中的所有条件，列出条件的次序无关紧要
动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
条件项：列出条件对应的值，所有可能情况下的真假值
动作项：列出条件项在各种取值情况下应该采取的动作结果
规则：
判定表中贯穿条件项和动作项的一列就是一条规则
假设有n个条件，每个条件的取值有两个，全组合有 2 的 n 次方中规则
步骤：
1、明确需求
2、画出判定表
1）列出条件桩和动作桩
2）填写条件项、对条件进行全组合
3）根据条件项的组合确定动作项
4）简化、合并相思规则（有相同的动作）
3、根据规则编写测试用例
使用场景
有多个输入条件，多个输出结果 ，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系。
判定表一般适用于条件组合数量较少的情况（ 4 个条件以下）
如果条件超过4个，就不适合覆盖所有条件，应采用正交法 来解决。
场景法--->对项目业务进行进行测试
定义：场景法也叫流程图法，采用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。
意义
用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试
业务测试覆盖
覆盖业务测试，需使用流程图法
先测试业务，再测试单功能、单模块、单页面
流程图对测试人员的作用
能够看懂流程图，设计业务用例
当需求文档信息不全时，能够根据需求梳理出流程
错误推荐法
定义：通过经验推测可能出现的问题
使用场景
当项目用例都执行完毕，且BUG修复完成，离上线还有一段时间，在这段时间中可使用错误推荐法复测主要业务或测试未覆盖的功能。
PS：提问：时间紧任务量大时会采用的方法---不能回答错误推荐法。正确答案：要先去与产品经理确定哪些是重要业务，先验证主业务，再去验证主任务的正向和逆向，按照时间节点去走。再加班。。。。。
正向是核心业务正确执行，逆向是可能使业务错误的用例