什么是建设网站的主题,如何申请微信企业号,厦门网站建设680元,上海高品质网站建设公司## 测试用例学习路线 startmindmap * 测试用例 ** 黑盒测试方法论 *** 等价类 *** 边界值 *** 因果图 *** 判定表 *** 场景法 *** 基于模型的测试 ** 白盒测试方法论 ** 测试用例基础概念 ** 测试用例设计 ** 面试测试用例设计 ** 常用测试策略与测试手段 endmindmap
**测试用…## 测试用例学习路线 startmindmap * 测试用例 ** 黑盒测试方法论 *** 等价类 *** 边界值 *** 因果图 *** 判定表 *** 场景法 *** 基于模型的测试 ** 白盒测试方法论 ** 测试用例基础概念 ** 测试用例设计 ** 面试测试用例设计 ** 常用测试策略与测试手段 endmindmap
**测试用例设计** * 设计方法的选择 * 测试用例编写步骤 * 需求分析 * 测试用例编写 * 测试用例的粒度 * 测试用例评审
## 等价类划分法
* 等价类划分是一种重要的、常用的黑盒测试方法 * 不需要考虑程序的内部结构只需要考虑程序的输入规格即可 * 它将不能穷举的测试过程进行合理分类从而保证设计出来的测试用例具有完整性和代表性 * 用户所有可能输入的数据划分成了若干个子集然后从每一个子集当中选取少数具有代表性的数据作为测试用例 * 在有限的测试资源的情况下用少量有代表性的数据得到比较好的测试效果 ## 等价类分类
* 有效等价类指符合《需求文档》输入合理的数据集合 * 无效等价类指不符合《需求文档》输入不合理的数据集合 有效等价类无效等价类等价类
## 等价类划分原则
1. 规定输入的取值范围或个数时划分一个有效和两个无效 2. 规定了输入的集合或规则必须要遵循的条件则划分一个有效和一个无效 3. 输入条件是一个布尔值则划分为一个有效和一个无效 4. 输入条件时一组数据并且每一个输入的值做不同的处理则划分若干个有效和一个无效 5. 输入条件规定了必须要遵循的某些规则下则划分为一个有效和若干个无效 6. 不是所有的等价类都有无效等价类 ## 等价类设计步骤
1. 先划分等价类找出所有可能的分类 2. 确定有效等价类需求中的条件 3. 确定无效等价类与条件相反的情况再找到特殊情况 4. 从各个分类中挑选测试用例数据 ## 等价类总结
* 长度 * 类型 * 组成规则 * 是否为空 * 是否重复 * 是否去除空格 ## 边界值分析法
* 大量的软件测试实践表明故障往往出现在定义域或值域的边界上而不是在其内部 * 为检测边界附近的处理专门设计测试用例通常都会取得很好的测试效果 * 边界值分析法是一种很实用的黑盒测试用例方法它具有很强的发现故障的能力 * 边界值分析法是作为对等价类划分法的补充测试用例来自等价类的边界
## 边界值确定
* 上点边界上的点 * 离点离上点最近的点 * 内点在输入域内任意一个点 * 选取正好等于、刚好大于或刚好小于边界值作为测试数据 ## 边界点划分规则
* 如果规定了输入域的取值范围 * 选取刚好在范围边界的点 * 刚好超过边界的点 * 如果规定了输入值的个数 * 最大个数 * 最小个数 * 比最小个数少 1 * 比最大个数多 1 * 如果规定了输入是一个有序的集合 * 选取集合的第一个元素 * 选取集合的最后一个元素
## 边界值总结
* 确定边界情况 * 选取正好等于、刚刚好大于或刚刚好小于边界值作为测试数据 * 确定各个值的等价类
## 因果图定义
* 因果图法是一种利用图解法分析输入的各种组合情况从而设计测试用例的方法 * 它适合于检查程序输入条件的各种组合情况 * “因” —— 输入条件 * “果” —— 输出结果 ## 因果图适用场景
* 描述多种条件的组合 * 产生多个动作 ## 因果图中的基本符号
* 恒等若原因出现则结果出现若原因不出现则结果也不出现 * 非若原因出现则结果不出现若原因不出现则结果出现 * 或有多个原因。若几个原因中有一个出现则结果出现若几个原因都不出现则结果不出现 * 与有多个原因。若几个原因都出现则结果才出现若其中一个原因不出现则结果不出现 ## 因果图中的约束条件
* 互斥 Ea、b、c 只能有一个成立但是可以都不成立 * 包含 Ia、b、c 中至少有一个成立 * 唯一 Oa、b、c 有且仅有一个成立 * 要求 R如果 a 成立则要求 b 必须也成立其他的不约束 * 屏蔽 M如果 a 成立的时候强制 b 不成立其他的不约束
## 因果图法基本步骤
* 找出所有的输入条件因 * 找出所有的输出条件果 * 明确所有输入条件之间的制约关系以及组合关系 * 明确所有输出条件之间的制约关系以及组合关系 * 找出什么样的输入条件组合会产生哪种输出结果 * 把因果图转换成判定表 * 为判定表中的每一列表示的情况设计测试用例
## 判定表法
* 因果图只是一种辅助工具通过分析最终得到判定表再通过判定表编写测试用例 * 画因果图非常麻烦影响测试效率可以直接写判定表进而编写测试用例
## 场景法概述
* 场景法就是模拟用户操作软件时的场景主要用于测试系统的业务流程 * 基本流按照正确的业务流程来实现的一条操作路径 * 备选流导致程序出现错误的操作流程 ## 场景法用例设计步骤
* 根据需求规格说明画出功能模块流程图 * 根据流程图描述出程序的基本流及备选流 * 根据基本流和备选流生成不同的场景构造场景列表 * 对每一个场景生成相应的测试用例 * 对生成的所有测试用例重新复审去掉多余的测试用例 * 测试用例确定后为每一个测试用例确定测试数据值
## 确定基本流购物网站
1. 进入淘宝首页 2. 浏览商品 3. 进入单品页 4. 选择商品规格和数量 5. 加入购物车 6. 前往购物车 7. 选择商品 8. 结算进入确认订单页 9. 提交订单 10. 付款成功 11. 等待收货 12. 确认收货
## 确定备选流
* 备选流 1加入购物车时不选择商品规格和型号返回基本流第 4 步 * 备选流 2加入购物车时商品库存不足返回基本流第 4 步 * 备选流 3加入购物车时未登录登录后返回基本流第 3 步 * 备选流 4加入购物车后继续选购返回基本流第 4 步 * 备选流 5加入购物车未选择商品结算返回基本流第 7 步 * 备选流 6支付失败返回基本流第 8 步 * 备选流 7未选择商品加入购物车退出购物结束
## 构造场景
* 场景 1: 登录后成功购物基本流 * 场景 2: 未选择商品规格和型号就添加购物车基本流 备选流 1 * 场景 3: 选择的商品库存不足基本流 备选流 2 * 场景 4: 未登录添加购物车基本流 备选流 3 * 场景 5: 商品添加购物车后继续购物基本流 备选流 4 * 场景 6: 进入购物车未选择商品直接结算基本流 备选流 5 * 场景 7: 支付过程出错基本流 备选流 6 * 场景 8: 没有添加商品到购物车基本流 备选流 7
## 设计方法的选择
* 任何情况下都需要采用等价类划分法将无限测试变成有限测试 * 在规定了数据范围的情况下必须采用边界值分析法 * 如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现考虑使用场景法 * 如果含有输入条件的组合情况考虑选用因果图和判定表法 * 采用错误推断法再追加测试用例
## 测试用例编写步骤
1. 划分功能模块 2. 正向功能验证 3. 单个功能项验证 4. 功能之间交互验证 5. 隐形需求
## 需求分析
* 帐号是手机号 * 手机号仅限制为国内常用的号段 * 密码必须为 数字英文 的形式字段为 8-12 个字符 * 账号密码都为空时登录按钮置灰不可点击 * 点击登录按钮发起登录请求 * 请求成功跳转到首页 * 点击忘记密码跳转到找回密码页 ## 测试用例编写 startmindmap * 登录功能 ** 正向功能验证 ** 界面验证 ** 单个功能验证 *** 手机号输入框 **** 长度等价类结合边界值分析测试数据 **** 类型等价类分析测试数据 **** 是否必填等价类分析测试数据 **** 数据约束是否符合真实手机号的规则 *** 密码输入框 **** 长度等价类结合边界值分析测试数据 **** 类型等价类分析测试数据 **** 是否必填等价类分析测试数据 **** 匹配性等价类分析测试数据 *** 登录按钮 **** 不同的网络 **** 异常操作 *** 忘记密码按钮 **** 点击忘记密码跳转忘记密码页
left side
** 功能之间交互验证场景分析 *** 使用判定表分析手机号与密码填写组合场景是否覆盖完全 **** 手机号与密码都为空 *** 从登录业务逻辑角度使用场景法补充场景 **** 手机号未注册 ** 隐性需求 *** 密码密文展示 *** 账号互踢 *** 登录有效时间 *** 退出登录 *** 不同设备登录数据是否同步 endmindmap ## 测试用例的粒度
* 测试用例可以写的很简单也可以写的很复杂 * 最简单的测试用例是测试的纲要仅仅指出要测试的内容 * 测试用例写的过于简单则可能失去了测试用例的意义 * 测试用例写得过于复杂或详细会带来两个问题 * 效率问题 * 维护成本问题
## 测试用例评审
* 测试用例的本身的描述是否清晰是否存在二义性 * 测试用例内容是否正确是否与需求目标相一致 * 测试用例的期望结果是否确定、唯一 * 测试用例是否覆盖了所有的需求 * 测试用例是否具有可执行性 * 是否从用户层面来设计用户使用场景和业务流程的测试用例 * 场景测试用例是否覆盖最复杂的业务流程 * 用例设计是否包含了正面、反面的用例
## 思路
* 需求分析 * 界面 * 功能 * 易用性 * 兼容性 * 性能 * 安全性
startmindmap * 面试测试用例设计思路 ** 需求分析 *** 明确需求 *** 和面试官交流需求细节 ** 界面测试 *** 页面布局设计和产品原型图一致 *** 页面文案正确 ** 功能测试 *** 正向功能验证 *** 单个功能项验证 *** 功能之间交互验证 *** 接口验证 ** 易用性测试 *** 功能操作是否简便 *** 页面布局是否美观合理 *** 提示语相关信息是否易于理解 ** 兼容性测试 *** APP **** 平台 **** 厂商 **** 系统版本 **** 屏幕大小与分辨率 *** WEB **** 浏览器 **** 操作系统 **** 分辨率
left side
** 性能测试 *** 服务器性能测试 *** APP 客户端性能测试 ** 安全性测试 *** 注入攻击 *** 加密 *** 权限 ** APP 测试要点 *** 网络 *** 中断 *** 系统权限 ** WEB 测试要点 *** 链接测试 *** 多个浏览器同时访问 endmindmap
## 软件测试流程
* 完成软件测试工作的必要步骤 需求分析-测试计划-测试设计-测试执行-测试总结 ## 测试计划模板
* 测试计划模版https://docs.qq.com/doc/DV2hTamxJWnNDaUFF ## 测试计划编写要点
* 5W H 原则 * why为什么要进行这些测试 * what测试哪些方面不同阶段的工作内容 * when测试不同阶段的起止时间 * where相应文档缺陷的存放位置测试环境等 * who项目有关人员组成安排哪些测试人员进行测试 * how如何去做使用哪些测试工具以及测试方法进行测试 ## 业务架构分析工具
* 思维导图 * plantuml startmindmap * 登录 ** 账号密码登录 *** 账号输入框 *** 密码输入框 *** 登录按钮 ** 第三方登录 endmindmap startuml actor 用户
用户 - 客户端: 点击账号密码登录 客户端 -- 用户: 登录界面 用户 - 客户端: 输入帐号、密码点击登录按钮 客户端 - 客户端: 前端校验帐号和密码规则
alt 校验通过 客户端 - 服务端: 传递帐号和密码 else 客户端 -- 用户: 返回校验后的提示信息 end
database 数据库
服务端 - 数据库: 查询用户登录信息 数据库 -- 服务端: 返回查询结果 服务端 -- 客户端: 返回登录结果
alt 登录成功 客户端 -- 用户: 登录成功返回我的页面展示登录后的信息 else 客户端 -- 用户: 提示登录失败信息 end enduml
## Bug 判定标准 程序错误、程序漏洞、程序不完善
* 软件未达到客户需求文档的功能和性能 * 软件出现客户需求不能容忍的错误 * 软件的使用未能符合客户的习惯和工作环境 * 软件超出需求文档的范围
## 严重程度和优先级的关系
* 一般地严重性程度高的软件缺陷具有较高的优先级 * 有时候严重性高的软件缺陷优先级不一定高甚至不需要处理 * 有时候一些严重性低的缺陷却需要及时处理具有较高的优先级 # Bug 处理流程 ## 不同角色的对 Bug 的职责  ## Bug 处理流程  ## Bug 处理意见: 
## Bug 报告
* 记录 Bug * 跟踪 Bug * 更好的和开发人员交流 ## Bug 报告模版: 
## Bug 报告要素 1. Bug 编号 2. 所属产品 2. 发现的版本 3. 所属的模块 4. 提交人 5. 错误类型 6. 复现概率 7. 严重级别 8. 优先级 9. 标题言简意赅说明是什么 bug 10. 内容描述 - 测试环境 - 前提条件 - 复现步骤 - 预期结果 - 实际结果 11. 附件截图、出错的 log 日志、测试用的数据 # 测试总结 ## 测试报告作用
* 把测试的过程和结果写成文档 * 对发现的问题和缺陷进行分析 * 为纠正软件的存在的质量问题提供依据 * 为软件验收和交付打下基础
## 测试报告模板 * 测试报告模版https://docs.qq.com/doc/DV3NTVGhtdUN0cVRw ## 总结要点
* 人力投入 * 用例覆盖情况 * Bug 的分类及数量统计 * 遗留 Bug 情况 * 测试风险 * 测试结论
# 业务架构分析工具 plantuml ## plantuml 介绍
* UML统一建模语言 * plantuml第三方插件工具 * plantuml 官网https://plantuml.com/zh/ * plantuml 中文文档https://ceshiren.com/t/topic/4530 * plantuml 在线绘图地址https://plantuml.ceshiren.com/
