测试理论（3）
Axure RP 9
实例：
分析需求 编写用例
实付金额 = 订单数× 客单价
订单数=客单数
总业绩概况中的实付金额=成交订单数 ×客单价
订单数=客单数
月份 （28天的、30天的、31天的）
当前日期 会员
-
定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从?有针对性的设计测试?例的?法。
假设----》验证---》结论来验证假设是否正确
场景1：
针对电商类的产品，我们打开首页后只加载能够看见的资源信息，随着往下滑动的过程中资源都会加载出来，这个过程可能会出现页面卡住或者卡死。
针对翻页的组件： 只展示当前页面的数据，后面的数据是随着翻页的过程中逐步加载的，那么可能就会出现页面卡死或者卡住
上传文件组件： 上传1G的文件，那么可能就会导致上传的问题缺失，或者是文件上传成功后，文件内容是乱码，还有可能是出现内存泄露（OutOfMemory --->OOM）
针对底层服务：（性能测试）
1、超时
2、堵塞
3、假死
1、定义：判定表是分析和表达多逻辑条件下执?不同操作的情况的?具。
2、优点：能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利?判定表能够设计出完整的测试?例集合。
缺点：不能表达重复执行的动作、例如循环结构。
3、应用场景：在?些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执?不同的操作。判定表很适合于处理这类问题。（适用于有多个输入和多个输出，输入和输出之间有相互的组合关系、制约和依赖关系。
1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序?关紧要。
2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
5、规则
任何一个条件组合的特定取值及其相应要执行的操作称为规则。
在判断表中贯穿条件项和动作项的一列就是一条规则。显然判定表中列出多少组条件取值，也就有多少条规则，即条件项和动作项有多少列。
6、步骤
①明确规则个数
②列出所有条件项和动作项
③填入条件项
④填入动作项，等到初始判定表
⑤简化，合并相似规则
7、小结
因果图法是通过判定表法的一个中间过程，我们经常会将因果图法和判定表分析法结合起来使用。
对于业务逻辑比较复杂的我们建议先使用因果图法进行分析，然后再转化为判定表法，最后写测试用例，这样思路比较清晰。
对于简单的可以直接使用判定表法分析，然后写测试用例。
判定表驱动分析法：划分测试的范围和边界，列出需要测试的各种不同的条件。（列表的方式去列出因果图的输入和输出结果，是因果图的简化版）
因果图：在划分测试范围的基础上，列出各个不同条件的排列组合的测试。（分析输入条件、条件之间的关系组合、对应的输出结果）
正交实验分解法：在因果图的基础上，选择有代表的数据进行测试。
项目管理工具
jira；TAPD (腾讯)
面试：工作用的项目管理工具？
tapd。早上上班登录tapd工具，接收自己今日的任务，并且把任务状态改为实现中/进行中，完成之后状态改为已完成/已实现。
场景设计方法：
这种在软件设计??的思想也可以引?到软件测试中，可以?较?动地描绘出事件触发时的情景，有利于测试设计者设计测试?例，同时使测试?例更容易理解和执?。
大多数业务软件由后台管理（比如：用户管理、角色管理、权限管理等等各种管理）和工作流等几个部分组成。终端用户，期望软件能够实现业务需求，而不是简单的功能的组合。对于单点功能利用等价类、边界值、判定表用例设计方法能够解决大部分问题。涉及业务流程的软件系统，采用场景法比较合适。
总之，对于多个功能组合测试的场景适合使用场景法，所以场景测试，也是业务场景组合测试。
-
基本流：表示通过业务流程时输入都正确，正达到目标的流程。
-
备选流：表示通过业务流程时输入错误（或者操作错误）导致流程存在反复，但经过纠正后能达到目标的流程(插卡→输入错误密码→输入正确密码→输入金额→取款→取卡)
-
异常流：表示通过业务流程时输入错误（或者操作错误）产生异常终止流程
步骤:
-
分析需求，确定基本流程、备选流程、异常流程
-
绘制流程图
- 根据流程图提取测试路径：基本流、备选流、异常流（从开始到结束的路径）
- 利用等价类和边界值，为每条路径设计测试用例。
开始 、过程、结束 （产品从无到有，和用户使用的过程）
例：网购商品
开始：商品通过审核，商品上架。
过程：用户搜索产品关键字，浏览挑选产品，查看产品详情，加入购物车，填写收货信息，完成支付，收货，评价。
结束：商品下架，商品搜索不到。
小结：场景流程比较适合于涉及到业务需求的场景，能够多个功能联合进行测试，不是单个功能进行测试
功能图分析方法（状态迁徙图）
?个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输?数据的次序或转移的次序.静态说明描述了输?条件与输出条件之间的对应关系.对于较复杂的程序,由于存在?量的组合情况,因此,仅?静态说明组成的规格说明对于测试来说往往是不够的.必须?动态说明来补充功能说明.功能图?法是?功能图FD形式化地表示程序的功能说明,并机械地?成功能图的测试?例.
测试?例则是由测试中经过的?系列状态和在每个状态中必须依靠输?/输出数据满?的?对条件组成.功能图?法其实是是?种?盒?盒混合?例设计?法。
适用场合：软件的状态会根据某些内容，条件，操作的变化而变化。
目标：尽可能覆盖软件的状态，状态——条件组合、状态变迁路径。（分析状态有哪些，是怎么变化的）
产品测试，快速建立全局思维：
1、使用场景设计方法快速梳理出被测产品的核心业务逻辑。
2、使用判定表驱动分析方法列出流程中可能的逻辑判断条件。
3、使用功能图列出产品的输入输出，完善每个不同条件下的业务场景。
条件不同代表着场景不同。就会出现正常业务流程和异常业务流程。
例如：拿电商产品的商品上架为例：
1、上架审核通过，那么就可以搜索购买
2、审核拒绝，商品搜索不到
3、库存位0，商品未下架
面试题：
一共有多少种设计方法，分别是什么？举例说明使用场景？