第8天

【因果图】
因果图的步骤：
1.把大的系统规格划分解成可以测试的规
格片段
2.分析分解后待测的系统规格，找出哪些
是原因，哪些是结果
3.画出因果图
4.把因果图转换成判定表
5.简化判定表
6.用判定表中的每一列生成测试用例
因果图：（有三种关系）
原因(输入条件)    结果(输出条件)
一、原因与结果之间的关系
C ==》原因
E  ==》结果
恒等： ==   等于   equal     一个=叫赋值，两个==叫恒等(恒等一般用来做判断)
a = 1
b = 1
a == b
非：不   否   not    don't   ≠  ~
或：or   /    ||    |    v
与：and   和   ^   &&   且   +
二、原因与原因之间的关系
异：选择框（非必选框），比如选择男和女，可以都不选，选的话只能选一个。
或：可以同时选，也可以选一个
唯一：男和女（必选框），只能选一个，且必选一个
要求：当我选择了四川省，市区就必须选择四川省下面的城市
三、结果与结果之间的关系
强制：投保成功和投保失败只能出现一次
面试题：
你对因果图是怎么理解的？
我们公司之前对有因果需求的地方，首先会把因果图中的原因转换为判定表中的条件桩。把因果图中的结果转换为动作桩，从而把因果图转换位判定表，以防止用例的覆盖不全面。
因果图转换判定表的方法：
1. 将因果图中的所有条件（因）填
入判定表 的条件桩中；
2. 将因果图中的所有动作（果）填
入判定表 的动作桩中；
3. 根据因果图确定各个条件组合对
应的动作， 并且确定判定表中
各个规则的条件项和动 作项，
在需要时优化判定表。
ØE约束(异)：a和b中最多有一个可能为1，即a和b不能 同时 为1。
ØI 约束(或)：a、b、c中至少有一个必须为1，即 a、b、 c不能同时为0。
ØO约束(唯一)：a和b必须有一个且仅有一个为1。
ØR约束(要求)：a是1时，b必须是1，即a为1时，b不能 为0。
ØM约束(强制)：若结果a为1，则结果b强制为0。
1、市面上有哪些bug管理工具，每个bug管理工具的特点是什么？
禅道：项目、用例和bug管理工具
JIRA
Bugzilla
EasyBUG、
QC(Quality Center)
2、bug的级别有哪些？
bug的级别：致命、严重、一般、建议
致命：app闪退、系统崩溃、蓝屏、死机等
严重：主体功能受损，root用户登录只有普通用户的权限。
一般：发朋友圈界面点击左上角返回键按钮需要点击3次才能返回。
建议：字体大小、图片格式颜色、页面布局杂乱等
bug的等级：1级   2 级  3级   4级
bug的等级：L1     L2     L3     L4  ==》level等级
1级bug，必须优先要改
致命错误：
1、常规操作引起的系统崩溃、死机、死循环
2、造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露
3、涉及金钱，如支付类软件，金钱计算错误
2级bug
严重错误：
1、重要功能不能实现（例如：微信没有实现语音聊天、朋友圈，等）
2、错误的波及面广，影响到其他重要功能正常实现
3、非常规操作导致的程序崩溃、死机、死循环 (非常规操作：用户使用软件时不会进行的操作）
4、外观难以接受的缺陷（例如：直播平台的封面图片的失真、压缩，完全变形）
5、密码明文显示
3级bug，
一般错误：
不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷
1、次要功能不能正常实现
2、操作界面错误（包括数据窗口内列名的定义，含义不一致）
例如：列名与列名下的内容不一致
3、bug的管理流程是怎么样的？
测试人员在执行SIT测试过程中，发现bug，提交到禅道并指派给某个开发。开发人员收到指派自己的bug之后，会进行评估，如果认为不是一个bug，则会直接打回给测试，然后测试人员再次确认并跟进打回的bug。如果开发认为是一个bug，则进行修复，修复之后再将bug指派给测试人员进行回归，回归通过则关闭bug。
4、一条完整的bug应该包含哪些信息？
Bug标题
Bug描述
Bug出现步骤
附件（可以附上出现的缺陷截图更有说服力）
Bug严重程度和优先级《一般严重等级分为;致命，严重，一般，建议四个等级和优先级分为高中低三级》
指派给谁（一般指派给开发者或者不知道是某个开发者就指派给测试经理或项目经理）
5、bug的状态有哪些？
1、New:（新的）
当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New。
2、Assigned（已指派的）
当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”。
3、Open（打开的）
一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”。
4、Fixed（已修复的）
当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组。
5、Pending Reset（待在测试的）
当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”。
6、Reset（再测试）
测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”。
6、禅道这款bug管理和用例管理工具的结构有哪些，介绍一下？