1.什么是测试用例 完成某项特定功能的测试，测试过程中的步骤及测试数据，产生一个实际结果，与我们的预期结果进行比较 预期结果：是我们从需求文档上得出的结果 实际结果：就是执行用例时产生的结果 如果预期结果与实际结果对不上，这就是一个bug 2.测试用例，越详细越好。相当于一个说明书，拿到用例就知道怎么执行。 用例存在交叉执行的情况，写的用例精良都可以看得懂。是一个可交付文档 3.测试用例评审 项目正式进入系统测试阶段前，测试组内评审，项目组内评审 主要目的：完善测试用例，就是在评有没有漏测，详细与否。如果不通过，继续完善，直到通过为止 测试用例核心8大要素 用例编号 就是测试用例的编号：每一个项目组，用例编号的的命名规则不一样,每一个编号都是唯一的 测试项目 就是项目中所属的一个模块 用例标题 看到标题就知道本条用例是测试什么功能的 优先级 根据测试功能的优先级去判断，一般核心业务用例的优先级最高，涉及到金钱用例优先级也很高。。。 高、中、低 p0,p1,p2,p3 高：核心业务功能，会影响到数据的用例 中：一些辅助功能，核心流业务失败的用例 低：一些文案错误 预置条件 测试过程中不会执行的步骤，会影响测试结果 执行步骤 测试过程中执行的步骤，越详细越好 测试数据 测试过程中使用的数据，输入的数据 预期结果 从需求文档方面，得出得到一个期望结果。 其他要素： 实际结果：执行测试用例后产生的一个结果 编写人员：编写本条测试用例的人员 每一个公司，用例管理工具可能都不一样，每一个工具都很简单。一般公司都会用excel来编写测试用例（每一个公司的用例模板都不一样） 4.写用例的好处有哪些： 1.防止漏测:(用例评审方向，对遗漏点进行补充) 2.正式进入系统测试阶段，思路比较清晰（只需要根据编写的用例执行就可以了） 3.提高测试效率 4.突出测试重点 5.监控测试进度 6.度量指标（用例执行方面,可以判断出，开发完成情况，也可以判断出模块逻辑的复杂程度） 5.测试用例设计方法 提高测试覆盖率 1.等价类： 有效等价类：有效的数据 存在多个条件时，可以覆盖多个有效等价类条件 无效等价类：无效的数据，不能使功能正式执行 存在多个条件时，设计测试用例时，只能覆盖一个无效等价类条件 2.边界值：作为等价类的一个补充（一般bug就会产生在内点、离点、上点这里面） 内点：边界内的点 离点：离上点最近的点（无效的数据） 上点：边界上的点，边界最外的点 需要单独设计测试测试用例覆盖 3.流程分析法：不需要去考虑功能的细节，将复杂的问题简单化，只需要去判断每个流程的是否执行下一步，一些备选流功能。 4.判定表：多个条件组成，产生多个结果，将其中无意义的用例删除（存在一定的漏测风险） 当动作桩一致时，条件项有n-1个相同的情况下，可以进行用例合并，将多余的用例删除 条件项：包含所有的条件桩 条件桩：测试的每个条件 动作项：测试执行的所有结果 动作桩：测试执行的每个结果动作 5.状态迁移法：（最适用与游戏测试） 当程序存在多个状态的情况下，每个状态切换之间没有规律，要确保每个状态之间能够正常切换 线上：#离线 #隐身 #请勿打扰 #离开 #发言 离线：#线上 #隐身 #请勿打扰 #离开 隐身：#线上 #离线 #请勿打扰 #离开 #发言 请勿打扰：#线上 #离线 #隐身 #离开 #发言 离开：#线上 #离线 #隐身 #请勿打扰 #发言 发言：#线上 —#离线 #隐身 #请勿打扰 #离开 线上-离线-线上-隐身-线上-请勿打扰-线上-离开-线上-发言-线上 离线-隐身-离线-请勿打扰-离线-离开-离线 隐身-请勿打扰-隐身-离开-隐身-发言-隐身 请勿打扰-离开-请勿打扰-发言-请勿打扰 离开-发言-离线-发言-离开 1.找出可以转换的所有状态 2.分析各个状态之间的转换关系 3.设计测试用例时，尽可能减少重复，做没到所有状态切换全部覆盖 练习：跳跃-前进-后退-下蹲-射击-冲刺 跳跃不能冲刺、射击 6.错误推断法（异常分析法）： 由服务器，客户端，硬件，网络、数据库之类导致功能失效，需要提示用户，提升产品的易用性。 7.正交实验法： 不是专门的测试用例设计方法。有多种条件共同组合的情况。 微信发红包： 红包类型 支付方式 密码方式 表 其他 手气红包 零钱 面容 a a 普通红包 零钱通 指纹 b b 专属红包 银行卡 密码 做到全覆盖是27种 水平：影响结果的条件数量 因子：每个因子的可选项 标准正交表：每个水品下面的因子数一致 用例数=（水平-1）*因字数+1 用例数=2*3+1=7 111aa 122ab 211ba 223aa 332bb 333ab 123ba 211bb 332ab 9条 设计测试用例时：各种组合，尽可能让每个因子出现的概率一致 混合正交表： 用例数=（相同因子水平数-1）*因字数 +(其他相同因子水平数-1) *因字数 +1 如果只存在一个水品不需要减1 8.因果图：（了解，工作中一般不会碰到）难点：就是通过条件项找出输入条件 通过动作项找出输出结果 最终还是转换为判定表 （场景法）：站在用户的角度去考虑更多的场景，需要我们对业务很熟悉，提炼测试点出发 易用性：没有一个标准的定义，只能是站在用户角度，使用产品，有无引导性，简单易上手 借款用途 还款周期 抵押 还款方式 短期周转 按天 有 等额本息 购房借款 按月 无 每月付款，到期还本 装修借款 到期还本息 婚礼筹备 本金均摊，利息固定 投资创业 医疗支出 用例条数：6+2+4+1=13 掌握情况的优先级：等价类、边界值、流程分析法、错误推断法、正交实验法、判定表（存在一定的漏测风险）、状态迁移法（一般适用于游戏行业）、因果图（了解） bug的收敛性： 测试用例一般会执行3-4轮才会上线 bug只会一轮比一轮少 第一轮发现的bug最多，用例执行最为详细。 第二轮bug相对少一些，用例执行相对较为详细 第三轮伦测试bug更少，用例执行只会选择一些用县级最高的用例执行 如果bug一轮比一轮多怎么办。 临近上线进行风险评估。 你人开发和测试是对立的码？ 一般不是，共同出出发点优化项目。 如果公司存在绩效制度，尽量找出平衡点，（会影响到团队和谐） 测试绩效制度：一般是和用例数，与生产环境报障挂钩。 6.什么是bug(缺陷)? 项目存在的缺陷 bug的生命周期：潜在bug-发现bug-确认bug-提交bug-修复bug(解决bug,开发处理)-回归bug-关闭bug bug的分类：功能错误，没有实现的功能 功能缺失，需求文档存在的功能未作 功能多余，多做了需求文档上不存在的功能 潜在功能未作，不存在需求文档上的功能 易用性不好的功能：功能不好用户，感觉不合理（没有一个标准的定义） bug的等级： 1.致命bug 会导致整个程序无法运行的功能，会导致整个程序崩溃 2.严重bug 会造成数据丢失的功能 3.一般bug 一些备选流、辅助功能未实现 4.提示bug 界面检查的一些错别字 一般bug与提示bug是最多的 bug包含哪些内容 修改人员，bug标题（一定要详细，看到这个标题就知道这个是出现什么功能的错误） 重现步骤一定要写出来 bug的状态：激活状态、解决状态、关闭状态（碰到bug首先截图） 挂起状态：针对不能重现的bug,会在某些特殊情况下产生的bug，不知道怎么的bug。 首先判断bug的严重等级，找对应的开发查看日志，一直挂着 ，后期再次出现，截图查找原因 后期未出现，根据bug等级判断是否上线。 用例的状态：未执行（没有执行的用例） 通过（执行已经通过的用例） 失败（执行未通过的用例） 阻塞（出现阻塞状态比较严重，受其他用例影响，导致该用例不能正常执行） 如果你提交的bug开发不认为这是一个bug怎么处理：首先确认需求这是不是一个bug,如果不是则关闭，如果是，再次打开，对应的需求发给他。 如果还是不认为这是一个bug，可以找对应产品处理。 项目上线的标准： 1.测试用例达到百分之百 2.bug全部修复完成 （有的公司：致命bug、严重bug修改率百分之百。一般bug，提示bug,修改率95%）