因果图判定表项目管理工具

判定表：列出条件桩和动作桩0代表假 1代表真。然后再根据判定表写测试用例。
因果图中的基本符号：左边的ci 表示的一个状态（原因）
右边的ei 表示的输出的状态（结果）
ci 和 ei 的取值是0和1， 0表示状态不出现，
1表示状态出现

约束符号
原因与原因之间的关系、结果与结果之间的关系
异（E）    a和b最多有一个可能出现，a和b不能同时出现
或 I       a b  c 至少有一个出现，abc不能同时出现
唯一  O    a和b必须有且仅有一个出现
要求  R    a出现，b必须出现
强制 M    a出现，b强制出现或者不出现

因果图怎么转换判定表？
1、将因果图中的所有条件（因）填入判定表的条件桩
2、将因果图的所有动作（果）填入判定表的动作桩
3、根据因果图确定各个条件组合对应得动作，
并且确定判定表中各个规则的条件项和动作项.面试题
您在上家公司是怎么用因果图用例设计方法？
我在上家公司一般都不会去画因果图，
但是对于需求文档当中有因果关系的需求，我们会把
因果图当中的原因放入判定表中的条件桩当中，
把因果图中的结果放入到判定表的动作桩当中
从而把因果图转换为了判定表，
可以防止用例的漏写和漏测。

你对因果图是怎么理解的？
我们公司之前对有因果需求的地方，
首先会把因果图中的原因转换为判定表中的条件桩
把因果图中的结果转换为动作桩，
从而把因果图转换为判定表，以防止用例的漏测。

JIRA：优点：界面、安全、扩展性、可以定制

缺点：不符合中国人使用逻辑，部分页面显示英文

Bugzilla

优点：检索功能、数据库强大、免费、安全性高

缺点：英文版，需要配置Perl和配置Mysql、不支持切图。

EasyBug

优点：web在线、不用配置、界面简单、拥有切图功能、统计表、国产免费、bug解决流程图

缺点：需要手动录入bug标题，保存bug切图提交

QC

优点：功能强大，接口笔记好，数据可以共享，手动自动化功能

缺点：需要安装数据库，英文版，收费

你之前公司的bug管理流程：

多名测试人员发现bug 提交bug到管理工具，测试经理对提交的bug进行规范审核，如发现重复bug直接丢弃，如果规范审核通过，通过开发经理分配给具体的开发人员，开发人员会根据项目进度，项目的情况对提交的bug进行修复（会根据bug的严重程度进行修复），开发人员把修复好的bug给到测试经理测试经理部署环境后分配给具体的测试人员进行回归测试，如果是严重bug则直接给到测试人员。测试人员进行回归测试，验证bug是否修复修复了就关闭这个bug（如果未修复就直接改bug状态）

提单：测试人员提交bug到bug管理工具

规范审核：测试经理对bug进行审核

Id：每一个bug都有一个id

Bug级别：

致命：app闪退，系统崩溃，蓝屏、主体功能受损

严重的：功能受损root登录用户只有普通用户的权限，次功能受损

一般bug：返回按钮需要点击三次才能返回

建议性bug：字体的大小不同，按钮的颜色

一条完整的bug 应该包含那些信息?

Bug标题 bug编号bug复现步骤 bug相关的附件，bug的严重程度，bug的优先级，bug指派给谁的（开发），bug预期结果、bug的实际结果、bug所属的那个模块和那个版本

Bug的类型：（前端还是后端的）bug的状态、bug的创建人（me）bug的创建时间。

Bug状态