测试-1月13日

今日学习视频：
共学习了《软件测试第一篇_测试理论_Linux数据库_超详细教程》中的P23-P44共计 22 集内容
今日学习时间：
一天，慢慢的耗

今日所学知识点：
1、解决穷举测试点覆盖问题
2、解决边界限制测试点覆盖问题
3、解决多条件组合依赖测试点覆盖问题
4、解决项目业务场景测试点覆盖问题
5、能够知道软件缺陷判断标准

今日收获：
之前学过的等价类、边界、判定表，现在能通过举例子更清楚了。
今日疑惑：
目前无

解决穷举问题

方法：等价类可以实现
分类：
有效等价：所有有效数据集合，取一个即可
无效等价：所有无效数据集合，取一个即可

步骤
明确需求
确定有效和无效等价类
提取数据编写用例

场景：
针对：需要有大量数据测试输入，但是没法穷举测试的地方
输入框
下拉列表
单选复选框
典型代表：界面级的输入框类测试

解决边界限制问题

方法：边界值设计问题
上点：边界上的点（绿色）
离点：离边界最近的点（黄色）
内点：范围内的点（蓝点）

边界值可以覆盖等价类的长度，但是无法覆盖类型。
所以设计用例时，必须两者结合

优化：
边界上的点：开内闭外
开区间：不包含（）
闭区间：包含[]

上点：必选（不考虑区间开闭）
内点：必选（建议选择中间范围）
离点：开内闭外（考虑开闭区间，开区间选择内部离店，闭区间选择外部离店）

使用场景：
常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语
典型代表：有边界范围的输入框类测试

解决多条件依赖问题

方法：判定表
定义：是一种以表格形式表达多条件逻辑判断的工具

组成：
条件桩：列出问题的所有条件，列出条件的次序无关紧要
动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
条件项：列出条件对应的取值，所有可能情况下的真假值
动作项：列出条件项、各种取值情况下应该采取的动作结果。

规则：
判定表中贯穿条件项和动作项的一列就是一条规则
假设有n个条件，每个条件的取值就两个（0，1），全组合有2的n次方种规则

步骤
1、明确需求
2、画出判定表
（1）列出条件桩和动作桩
（2）填写条件项、对条件进行全组合
（3）根据条件项的组合确定动作项
（4）简化、合并相似规则（有相同的动作）
3、根据规则编写测试用例

应用场景
有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系
判定表一般适用于条件组合数量较少的情况（比如4个条件以下）
提示：如果碰到项目中多条件组合大于4个相互依赖，可以使用（正交表和因果图来实现）

场景法

提示：流程图主要用来解决业务用例问题

介绍

说明：
场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。

意义：
用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能点的组合测试

错误推荐法

定义：
通过经验推测系统可能出现的问题

思想：
根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷

场景：
1、时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试
2、实践宽裕通过该方法列举之前出现问题较多的模块再次测试

缺陷介绍

定义
软件中使用中任何问题都为缺陷，简称bug

衡量是否为缺陷的标准
1、少功能
2、功能实现错误
3、多功能
4、隐性功能错误
5、不易使用

缺陷产生的原因

扩展：it行业常见岗位及作用
1、前端：写页面
2、后端：后端服务程序
3、测试：找缺陷
4、UI：设计图（美工）
5、运维：管理服务器（安装软件项目的电脑）
6、产品：梳理需求、设计原型图
7、运营：上线运营策划

软件缺陷的生命周期

注入bug->发现bug->修复bug

缺陷描述的核心内容