5.29
三、场景法用将软件的某个流程看成路径，用路径分析的方法来设计测试用例。根据流程的顺序依次进行组合，使得流程的各个分支都能走到。
场景法的运用：对需求的业务流程进行梳理。先梳理一个正常的业务流程，再通过分析这个正常的流程中可能出现的问题（可能出现的其他分支流程），最终得到测试用例。
如人事考勤系统的离职流程：
1.登录考勤系统
2.进入离职模块，申请离职（创建离职申请），填写离职原因
3.提交
4.上级领导审核
（1）通过---工作交接---离职成功
（2）不通过--拒绝申请--重新申请
异常的情况：
1.使用其他员工的账号登录
2.进入其他模块
3.填写离职申请后，取消--流程结束
4.填写离职申请后，提交给其他领导--不通过--重新申请
5.填写离职申请后，提交给自己--重新申请
6.上级审批通过后，用户取消离职流程--结束离职流程，重新在职。
网购流程：
D:\YUNJI\weixinobU7VjhWZ3EbBzkoz-CMgyRKG-zM\6e9d1a7f49ff4a7ab479d845675f6e7b\clipboard.png
场景法一般是输出一个基本流（可以通过XMind画流程），分析这个基本流中可能出现的多个备选流程（分支流程或者异常流程），对每个流程进行测试，以覆盖所有可能出现的测试场景，提高测试的覆盖率
ATM取款流程：
基本流（一个正常流程）
1.插入卡片
2.验证卡片有效
3.输入正确密码，验证通过
4.输入取款金额
5.取款
6.取卡
备选流（分支流程，取款中可能出现的其他各种操作）
1-1.插入无效卡片；1-2.插入被冻结卡片。
3-1 密码错误（没有超过最大错误次数）；3-2 密码错误（超过最大错误次数）；3-3 不输入密码
4-1 输入金额超过卡内余额；4-2 输入超过ATM机的余额；
4-3 输入金额超过限额；4-4 输入金额不是100的整数倍
5-1 没有成功取款；5-2 取部分；5-3 取了之后又放进去
6-1 没有取走卡片
结合系统异常分析法：
1.取款过程断电、断网
2.取款过程暴力破坏ATM机
------------------------------------------------
四、状态迁移法（和场景法非常像，一般是结合场景法使用）
通过描述系统的状态及引起系统状态转换的事件，来描述系统的行为。
验证不同的操作会引起对应的状态转换情况。
等价类、边界值测试方法：对单一功能点的测试
场景法、状态迁移法测试方法：一般做业务类型的测试，一个业务场景是由多个单一功能点组合而成
————————————————————————————————————————————
基于经验的三种测试方法：
错误推测法：根据自己对系统的了解，根据以往出现过的BUG，根据以前的经验，进行设计测试用例
系统异常分析法：模拟系统可能出现的故障，确保软件的容错能力。
例一：电商的主备切换，模拟主服务器出现异常情况，备用服务器能不能快速进行业务切换，相关的订单数据会不会丢失
随机测试：模拟用户随机的操作
-----------------------------------------------------------------
测试点的分析思路？测试用例的分析思路？
面试题：你给我讲一下XXX的测试点？
思路：这种面试题主要是看你的测试思路是否清晰
一、偏实际应用的思路：
1.从外观页面讲起，检查页面元素是否美观、齐全，信息的描述是否准确，页面的功能按钮是否正常，操作是否简洁友好
2.接着从各个功能进行逐一的展开描述，讲一个正常的 后面接多个异常的（如购物车加入商品：正常--商品有库存时是否能加入购物车；异常--商品库存为0时加入购物车、选择数量大于商品库存量是否能加入购物车等等）
3.接着从性能上思考，多人同时操作（并发）、快速的连续提交的操作。
4.从网络状态思考，弱网（网络环境差），无网络情况
5.如果设计安全的，也要考虑安全方面的问题，一般时接口信息篡改的问题，有没有涉及到一些敏感信息（有没有做加密处理）
6.考虑兼容性的问题。软件是否适配不同的系统，不同的浏览器，各种不同的网络状态的适配。软件不同版本的兼容
面试题：拿到一份需求之后，你会怎样设计测试用例？怎么保证测试覆盖率？
二、偏理论的思路：
拿到需求文档之后，我会先分析需求中说明的基本功能，然后对这些基本功能进行业务流程的梳理，进行设计测试用例，包括正常的主体流程和异常的分支流程（涉及场景法）
如果涉及到状态转换的场景，那么也会对这些场景进行涉及测试用例，用于提高业务流程的覆盖情况（涉及迁移法）
对涉及到边界值的场景会使用边界值分析法涉及测试用例。然后会根据自己对业务或者系统的了解来设计测试用例（涉及错误推测法）。
如果需求里面的功能涉及到系统故障恢复能力、容错能力，那么会使用系统异常法进行设计一些系统异常情况的测试用例。
如果需求中功能涉及到性能和安全方面的测试，也会涉及相关的性能测试用例和安全测试用例。
每一条测试用例就是执行测试的最小维度的文档，测试用例包含的一些基础内容：
（1）用例编号：对多条用例进行唯一的编号
（2）用例标题：简述本条测试用例的测试场景和测试目的，
要求尽可能唯一，要求是陈述句，要做到和预期结果的首尾呼应
（3）前置条件：描述测试执行之前需要准备的东西
（4）用例步骤：对执行测试的步骤进行描述（一般不超过6步）
（5）预期结果：对测试执行之后的结果进行预知描述，假设在执行测试步骤没有达到预期结果，
就可以判断这条用例有BUG
（excel单元换行：alt+enter）
1.不要把前置条件和用力步骤搞混了。前置条件的内容是供测试准备使用的，
不能是需要验证的内容。用例步骤是测试时需要执行的动作，每一步都是必要的。
2.前置条件、用例步骤、预期结果，如果使用了序号（如123），
那么需要使用统一的标点符号。（1， 2， 3，）
3.千万不要在用例标题中使用序号
4.不要把自己预想的结果写在步骤中，应该写在预期结果中。
步骤是执行的，结果用来核对。
5.测试过程使用到的测试数据或者需要说明点击的一些按钮，用引号括起来，做好区分。
6.用最少的测试用例覆盖最多的有效等价类
7.一个无效等价类就是一条测试用例，一条测试用例不能同时包含覆盖多个无效等价类的情况。
8.对于“不输入”的情况，也要考虑无效等价类
9.预期结果的编写，如果没有要求必要的返回，那么要简单描述对应的预期返回，就要进行逐一的验证，目的是确保每个结果都得到覆盖测试
10.边界值使用需要考虑最小单位
11.先把一条可以覆盖所有正常的流程的测试用例放在最前面，然后再去编写其他的异常情况，注意需要按照相同的模块进行划分
12.每一种枚举值都是一个测试用例
用例文档的格式注意点：
1.如非必要请勿在excel单元格中换行
2.在有多项信息的单元格（使用了1，2，3...序号标明信息点）要进行内容换行，千万不要使用加空格的方式换行
3.表格尽可能的顶行顶格开始编辑
4.不要随便合并单元格
需求分析的思路：
需求：微信发红包最大是200元
1.显性需求：作为冒烟测试的测试场景
就是直接体现在需求文档上的内容
2.隐形需求：通过阅读需求之后进行发掘，一般异常测试点就是通过挖掘隐形需求得到
（利用自己的发散性思维去思考可能出现的异常情况）
验证超过200元的情况
验证金额的最小单位0.01元
红包是怎么发的
红包发出后，怎么收、怎么退款的情况
不同的系统、不同的版本能不能收
最小发多少元
3.关联需求：考虑关联系统的需求情况。我方系统修改后会不会影响到相关联的上下游系统，
其他上下游系统修改后会不会影响到我方系统
发红包实在微信的即时通信系统（聊天系统）做的，红包的金额关系着微信钱包系统，微信
钱包关联着外部的银行系统，外部银行系统限额会不会影响发红包的功能
4.特殊需求：考虑用户的需求，在用户的角度使用该功能，用户的关注点。
例如一些特殊的日子，可以发520金额的红包
测试用例的编写流程：
阅读分析需求文档==》梳理基本的业务流程==》对业务流程过程中出现的功能点进行提炼测试点==》输出测试用例。
写测试点用XMind思维导图，写测试用例用excel或XMind
页:
[1]