测试理论5
作者：互联网
测试用例设计方法分类：
功能测试用例方法：
等价类
边界值
因果图
正交实验分解法
判定表驱动分析方法
非功能性的测试用例方法：
错误推测法
功能图分析方法
场景：场景设计方法
测试⽤例设计综合策略
1/综合策略
1)在任何情况下都必须使⽤边界值分析⽅法，经验表明⽤这种⽅法设计出测试⽤例发现程序错误的能⼒最强。
2)必要时⽤等价类划分⽅法补充⼀些测试⽤例。
3)⽤错误推测法再追加⼀些测试⽤例。
4)对照程序逻辑，检查已设计出 的测试⽤例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充⾜够的测试⽤例。
5)如果程序的功能说明 中含有输⼊条件的组合情况，则⼀开始就可选⽤因果图法。
2、测试⽤例的设计步骤
1)构造根据设计规格得出的基本功能测试⽤例；
2)边界值测试⽤例；
3)状态转换测试⽤ 例；
4)错误猜测测试⽤例；
5)异常测试⽤例；
6)性能测试⽤例；
7)压⼒测试⽤例。
3、优化测试⽤例的⽅法
1)利⽤设计测试⽤例的8种⽅法不断的对测试⽤例进⾏分解与合并；
2)采⽤遗传算法理论 进化测试⽤例；
3)在测试时利⽤发散思维构造测试⽤例。
边界值，等价类，因果图--->所有的都必须要考虑的
编写测试用例的依据是什么？
1、需求文档以及系统的产品业务逻辑
2、开发的技术方案，在技术方案里面会有程序内部的设计原理和逻辑流程图
3、个人的工作经验，比如任何一个产品都需要考虑异常的逻辑下程序的容错能力，以及产品的性能测试
你一天能够编写多少个测试用例？
我们之前编写测试用例都是使用思维导图的方式来编写的，我主要考虑的是把测试的产品测试点考虑周全
你怎么确保你编写的测试用例把测试点都包含进去了？
1、我首先会把系统中可能存在的各个业务逻辑使用思维导图都列出来，使用到的测试用例方法是判定表驱动分析方法
2、产品的正常功能，使用到的测试用例方法主要是等价类，边界值以及因果图
3、产品的非正常功能下系统的容错能力，主要使用到的测试用例方法是错误推测法
4、同时也会考虑被测产品的性能测试，以及它的安全性的测试（脚本注入）
5、设计测试点需要考测试对象被依赖的测试点的场景
测试的对象：
1、大数据类的产品：好好的熟悉底层的设计以及数据之间的流转
2、交易类的公司（淘宝，美团，字节）
3、通信类的产品，需要懂底层的通信协议
测试的对象：
1、有需求文档的产品，并且有交互
2、底层的服务测试（没有需求文档，也没有交互），比如测试一个支付类的产品，使用到的测试用例方法具体总结如下：
功能性：等价类以及边界值，和因果图 price:针对金额测试需要考虑数字（有效数据）和非数字的（无效数据），以及针对金额需要测试最大金额和最小金额，以及
金额小数点的位数----》等价类以及边界值的方法
price and goods：需要测试支付的时候同时带金额和商品，如果缺少一个，支付服务有没有错误的处理
非功能性：错误推测法 连续不断的支付，是否会出现支付卡死（支付时间长，或者暂时不能支付，得到一会支付）
测试用例的评审的流程：
1、自己编写完测试用例后，预定会议室，同时和大家约这个开会的时间是否都能够参加
2、到约定的时间，组织相关的人到会议室（那么这个时候会议的主持人就是你自己，会议的气氛以及氛围营造都是你自己来控制的）
3、开始时候的评审，你给大家描述每个测试点，大家都在听
A、当大家没有问题的时候，可能会回应你，也可能不会
B、当你描述的过程中，如果那个有问题，别人会立刻提出来，会议主持人需要把别人提出的问题立刻记录下
4、评审结束，做最后的总结
评审测试用例都有哪些人参与？
1、开发
2、产品
3、测试
4、PM(leader)
评审测试用例注意事项：
1、评审的过程中，如果别人提出疑问，针对有的疑问需要不同角色（产品，开发，测试）讨论决定结果
2、评审的过程中，某些测试场景以及测试结果可能存在问题，别人提出来，需要直接在现场修改自己的测试用例
3、有的疑问需要挑战的地方比较多，不需要现场调整，那么就需要在现场记录在本子上
4、评审结束，总结性的发言：
A、针对别人提出来的疑问，做一个汇总
5、评审结束之后，根据别人提出的疑问，调整（完善）测试用例，调整结束后，再次把测试用例发送到工作群里面，同时@相关的人
每个版本（迭代）测试这边的文档：
1、测试计划
2、测试用例
3、测试报告
4、测试技术方案
编写测试用例的技巧：
1、在一个新的环境里面，首先确认什么地方编写测试用例，以及什么方式编写
2、确认清楚后，编写一小部分，然后让对方去看下颗粒度，再对方的建议上继续调整
标签：测试点,理论,评审,测试用例,测试,编写,边界值 来源： https://www.cnblogs.com/wu199916/p/16465291.html