1、软件测试的定义：
1.1认识软件及测试1.2测试主流技能1.3就业方向如何选择1.4常见的测试分类（7种测试用例）1.5测试模型（质量模型的重点五项）1.6软件测试流程（6个步骤）1.7测试用例
用例设计编写格式：（用例执行的八大要素）
1、能对穷举场景设计测试点：2、能对限定边界规则设计测试点（例6-8位）3、对多条件依赖关系进行设计测试点4、能对项目业务进行设计测试点错误推荐法 1、软件测试的定义： 1.1认识软件及测试
1、什么是软件：控制计算机硬件工作的工具
2、软件基本组成：客户端、服务器、数据库
3、软件产生过程：需求产生->需求文档->设计效果图（UI设计师）
->产品开发->产品测试（看与需求文档是否一致）
4、什么是软件测试：使用技术手段验证软件是否满足用户需求
5、软件测试的目的： 发现软件中的错误，减少软件测试的缺陷。
1、功能测试：验证程序的功能是否满足需求
2、自动化测试：使用工具或代码代替手工，对项目进行测试
3、接口测试：使用代码或工具对服务端提供的接口进行测试
4、性能测试：模拟多人使用软件，查找服务器的缺陷。
1、功能测试+接口测试
2、功能测试+性能测试
3、功能测试+web自动化测试
1、按阶段划分
单元测试：争对程序源代码进行测试集成测试：又称接口测试，针对模块之间的访问地址进行测试（争对接口）系统测试：对整个系统包括功能、兼容、文档等测试验收测试：主要分为内测、公测，使用不同任人群来发掘项目缺陷
2、按代码可见度划分
黑盒测试（系统测试）：源代码不可见、UI功能可见灰盒测试:(集成测试、接口测试)部分源代码可见。功能不可见白盒测试：（单元测试）全部代码可见，功能不可见专项：性能测试安全测试
注：UI：User Interface
1.5测试模型（质量模型的重点五项）质量模型： 功能性、性能性、兼容性（浏览器，操作系统，其他软件）、易用性、安全性、可靠性（无响应，卡顿，死机）、可移植性、可维护性
1.6软件测试流程（6个步骤） 1、需求评审：各部门需求理解一致、知道有哪些功能（产品经历、开发人员、测试人员）
2、计划编写：测什么、谁来测、怎么测（功能、性能）
3、用例设计：验证项目是否符合需求的操作文档
4、用例执行：项目模块开发完开始执行用例文档实施测试
5、缺陷管理：对缺陷进行管理的过程
6、测试报告：实施测试结果文档
什么是用例：用户使用的案例
什么是测试用例：为测试项目而设计的执行文档
测试用例的作用：防止漏测、实施测试的标准
1、用例编号：项目_模块_编号
2、用例标题：期望结果（测试点）
3、项目：所属项目模块
4、优先级：表示用例重要程度P0~P4（P0最高）
核心功能：用户使用频率最高的功能
5、前置条件：要执行此条用例，有哪些前置操作
6、测试步骤：描述操作步骤（可以简化操作步骤）
7、测试数据：操作的数据，没有可以为空
8、预期结果：期望达到的结果+不同角色隐形结果（卖家、买家、平台）
例：QQ登录
测试点：要验证的点
实现：等价类划分法说明：在所有的测试数据中具有某种特征数据的集合进行划分（性别、年龄）分类：（找到代表） 有效等价类：满足需求的数据集合 无效等价类：不满足需求的数据集合步骤： 1、明确需求（长度、类型、规则） 2、确定有效和无效 3、提取数据编写测试用例
例1：qq合法性
长度类型验证
步骤：
例2：
电话：
等价类适用场景
针对：需要有大量数据测试输入，但是没法穷举测试的地方输入框下拉列表单选复选框典型代表：页面的输入框类测试
总结：先正向，再逆向，完整的用例应该是等价类和边界值一起写
2、能对限定边界规则设计测试点（例6-8位） 实现：边界值分析法
注：使用边界值解决边界位数限制问题，不能解决类型问题，要结合等价类
1、边界范围节点（有关范围限制，最多7条用例）
选取正好等于、刚好大于、刚好小于边界的值作为测试数据上点：边界上的点（正好等于2）离点：距离上点最近的点（刚好小于、大于4）内点：范围内的点（区间范围内的点1）
2、边界值法设计用例需求：
1、明确需求2、确定有效和无效等价类（考虑类型）3、确定边界范围值4、提取数据编写测试用例
例：
1、明确需求
通过边界值法验证标题长度的合法性
标题长度大于0小于等于30个字符
4、提取数据编写用例
例2：
1、明确需求
通过边界值验证qq号码的合法性
6-10位自然数
2、确定有效和无效等价类
3、确定边界范围值
4、提取数据编写 用例
结论：
1、7个优化为5个点2、上点和内点必选3、离点 开内闭外（开区间选包含的点，闭区间选不包含的点）
使用场景
注：单个输入框，常用的方式 边界+等价
最常用的用例方法：等价类，边界值
1、在等价类的基础上针对有边界范围的测试数据输入的地方2、常见词语描述：大小，尺寸，重量，最大，最小，至多，至少等修饰词语3、典型代表：有边界范围的输入框类测试
3、对多条件依赖关系进行设计测试点 实现：判定表法（输入条件与输出结果之间有相互制约关系的测试）
判定表：一种以表格形式表达多条件逻辑判断工具
组成条件桩：列出问题中所有条件，次序无关紧要动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束条件项：列出条件对应的取值，所有可能情况下的真假值动作项：列出条件项，各种取值情况下应该才取的动作结果
例：验证”若用户欠费或者关机，则不允许被叫“功能测试
规则判定表中贯穿条件项和动作项的一列就是一条规则假设有n个条件，每个条件的取值有两个（0，1）全组合有2的n次方种规则。
步骤：1、明确需求2、画出判定表1）、列出条件桩和动作桩2）、填写条件项，对条件进行全组合3）、根据条件项的组合确定动作项4）、简化、合并相似规则（有相同动作）3、根据规则编写测试用例
例：
1、明确需求：
2、画出判定表
3、编写测试用例
判定表使用场景：1、有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系2、判定表一般适用于条件组合数量较少的情况（四个条件以下）
提示：
1.多条件之间有依赖关系，使用判定表来进行测试覆盖。
2.判定表一般适合四个以内条件依赖关系
3.条件超过四个，应采用正交法来解决
实现：场景法
测项目先测业务，基本保证项目能跑通，再测试单功能、单模块
流程图：使用标准图形和箭头来表达程序或业务的走向
提示：业务用例是根据流程图来梳理的，需要先了解流程图
开始，结束：椭圆
判断：菱形
执行语句：圆角长方形
作用：1.能看懂流程图，设计测试用例2.当需求文档不全时，能够根据需求，梳理出流程
离线工具：visio、excel
网页版工具：网页画图工具
案例：ATM机
1、需求分析
2、画流程图
3、编写测试用例
1.定义：通过经验推测系统可能出现的问题2.思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷3.场景：1）时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试2）实践宽裕通过该方法列出之前出现问题较多的模块再次测试使用场景：当项目用例都执行完毕，且BUG修复完毕，离上线还有 一段时间，在这段时间中使用错误推荐法复测主要业务或未覆盖的功能。
面试问题：当时间少，只有自己时，需要测试如何回答 1、先与产品人员确定哪些时是重要业务 2、再验证主功能 正向和逆向 3、加班