除了测试工作之外，其他流程并行
优点：
软件测试出测试执行外，还有很多工作
软件测试完全独立，其他流程并发进行
具有很强的灵活性
缺点：
管理型要求高
技能要求高
测试就绪点分析困难
测试用例的定义
测试用例（test case）是为特定的目的而设计的一组测试输入、执行条件和预期的结果，一边测试是否满足某个特sing的需求
测试用例的八要素
包括用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤、预期结果
测试常见方法
等价类划分法
划分为：
有效等价类：满足要求的
无效等价类：不满足要求的
设计步骤
1、明确需求
2、确定有效和无效等价类
3、编写测试用例：对于所有的无效等价类，测试用例要尽量全覆盖，一条测试用例尽可能地覆盖多有有效等价类
ps：测试是无法穷尽的，可以输入具有代表性的子集。
例子
地区码：空白或者三位数字
有效等价类：空白或者三位数字
无效等价类：非空白或者不是三位数字或者非数字
前缀：非‘0’或非‘1’开头的三位数字
有效等价类：非‘0’或非‘1’开头的三位数字
无效等价类：‘0’或‘1’开头的三位数字或者不是3位数字或者非数字
后缀：4位数字
有效等价类：4位数字
无效等价类：非4位数字或者非数字
案例
注册新用户
用户名（昵称）长度为3-19：以字母开头（可能需求文档存在错误）
有效等价类：长度为3-19：以字母开头后面位数字
无效等价类：<3或者>19位 不是以字母开头3-19位，中文，空格，空，特殊字符，小数，敏感词汇
登录名称：非空
有效等价类：非空
密码：非空
有效等价类：非空
确认密码:值和密码相同
有效等价类：值和密码相同
边界值分析法
上点：边界上的点（正好等于）
离点：距离上点最近的点
内点：范围内的点
判定表法
定义
有多个输入和多个输出，而且输入与输入之间有相互的组合关系，输入和输出之间有相互的制约和依赖关系
四个组成部分
条件桩、动作桩、条件项、动作项
判定表的设计步骤
1、明确条件桩
2、明确动作桩
3、对条件桩进行组合
4、明确每个组合对应的动作桩
5、设计测试用例，每列数据对应一条测试用例
案例
订购单的检查，如果金额大于500元，又未过期，则发出批准单和提货单；如果金额大于500元，但过期了，则不发批准单；如果金额小于等于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。
因果图法
A、恒等
B、非恒等（不是a则不是结果b）
C、或者（多个条件a1、a2、a3，有一个条件出现就出现b）
D、与（多个条件a1、a2、a3，全部条件出现就出现b）
基本步骤
用数字标识输入和输出
画出因果图
将因果图转换为判定表
生成测试用例
适用范围
题目中有多个输入和多个输出，而且输入和输入之间有相互组合关系，输入和输出之间有相互的制约和依赖关系
案例
如想对文件进行修改，输入的第一列字符必须是A或者B，第二列字符必须是一个数字，如果第一列字符不正确则给出信息L，如果第二列字符不正确，则给出信息M
场景法
模拟用户正常操作流程
基本流
按照正确的业务流程来实现的一条操作路径
备选流
导致程序出现错误的操作流程（模拟错误的流程）
场景法基本操作步骤
1、确定基本流和备选流
2、依据基本流和备选流确定场景
3、一条场景就是一条测试用例
案例
用户进入一个在线购网站进行购物，选购物品后，进行在线购买，这时需要使用账号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。
流程图法
圆角矩形 开始/结束
箭头符号 路径 流程进行方向
平行四边形 数据 数据的输入或输出
长方形 处理 表示执行或者处理某项工作
菱形 判定 表示对某个条件做判断
流程图法步骤
1、画出业务流程
2、写用例，覆盖所有的路径分支
错误推测法
使用场景
项目紧任务急、时间不够，这时就不要按部就班的测试了，根据之前项目的经验，找到之前出错过的类似模块进行重点测试；所有正常测试结束后，通过错误推断法再测试一些之前出过问题的模块。
正交法
一种特制的表，一般的正交表标记为:Ln(mk)
n表示行数，也就是需要测试组合的次数
k是表的列数，表示控件的个数（因素的个数，或是因子个数）
m是每个控件包含的取值个数(各因素的水平数，即各因素的状态数)
举例如：L9（3 4）4因素3水平（4个控件3个取值）有9条测试用例
正交法设计测试用例步骤
1、根据需求形成因子状态表----->因子：控件名称状态：每个控件对应的取值
2、确定所采用的正交表
3、将正交表中的字母用文字代替
4、一行就是一条测试用例
因子状态表
见连接：http://support.sas.com/techsup/technote/ts723_Designs.txt
例子
假设查询某个人时有三个查询条件（查询条件仅考虑填写和不填写两种情况）：
根据“姓名”进行查询
根据“身份证号码”查询
根据“手机号码”查询
工具
正交设计助手
allpairs工具
软件缺陷
定义：bug或者defect（软件缺陷指的是存在于软件中那些不符合用户需求的问题）
表现形式
1、软件为达到需求说明书标明的功能
2、软件出现了需求规格说明书中指明不会出现错误的地方
3、软件的功能超出了需求规格说明书指明的范围
4、软件出现了需求规格说明书虽未指明，而应该达到的目标
5、软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好
软件缺陷产生的原因
1、需求解释、记录或者定义错误
2、设计文档说明存在错误或者拼写错误
3、编码说明、程序代码有误
4、硬件或者软件系统上存在错误
软件产生的根源
1、需求的变化
2、交流不充分
3、软件的复杂性
4、开发人员的错误
5、进度压力
软件缺陷的信息
缺陷id
⭕️缺陷状态 - new：新建缺陷 - open：打开缺陷 - fixed ：修复缺陷 - close：关闭缺陷 reopen：再次打开 postpone：推迟修复 rejected拒绝
⭕️缺陷标题
⭕️缺陷的严重程度（5-critical 致命缺陷 4-veryhigh 严重缺陷 3-high 一般缺陷 2-medium 一般缺陷 1-low 细微缺陷）
⭕️缺陷的优先级（根据公司的规定的优先级标准）
⭕️缺陷所属模块
缺陷记录者
缺陷提交时间
缺陷的处理人
处理结果描述
缺陷处理时间
缺陷验证人
验证结果描述
⭕️缺陷详细描述
缺陷环境说明
必要的附件
缺陷的分类
系统缺陷
数据的缺陷
数据库的缺陷
接口缺陷
功能缺陷
安全性缺陷
兼容性缺陷
性能缺陷
界面缺陷
建议
注意事项
1、尽量确保缺陷可以重现
2、简洁、准确、完整
3、一个缺陷一条记录（禅道或者其他bug管理平台）
缺陷的跟踪
研发修改完bug后进行回归测试，如果还是存在bug激活bug让研发继续修复，注意回归不仅仅只是测试研发改的bug而是系统性的测试（可以选择执行自己测试用例的12级用例，因人而异），避免研发改完其他模块或者功能出现bug。
缺陷的统计
1、缺陷按活动分布
用例评审-第一轮-第二轮-第三轮-用户手册评审-验收测试-其他
2、缺陷按严重程度分布
致命-严重-一般-提示
3、缺陷按引入源分布
产品需求-系统设计-软件设计-概要设计-详细设计-代码-测试
缺陷的数据分析
正在测的软件哪个模块的问题最多
测试人员中谁报告的软件缺陷最多
各类缺陷所占的数量百分比分别是多少
开发人员能及时修复软件缺陷吗
开发人员一次正确修复缺陷的百分比是多少
正在开发的软件能否在计划的时间内正常发布
作为一个软件测试的过来人，我想尽自己最大的努力，帮助每一个伙伴都能顺利找到工作。所以我整理了下面这份资源，现在免费分享给大家，有需要的小伙伴可以关注【公众号：开心螺蛳粉】自提！
软件测试面试文档
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群：1150305204，里面有各种测试开发资料和技术可以一起交流哦。
