面试相关

我在公司一般不用因果图,但是我会把需求当中有因果关系的需求提取出来,

然后把原因放入判定表的条件桩中,把结果放入判定表的动作桩中,从而把

因果图转换为判定表,以防止用例的漏写和漏测。

bug管理流程：从bug被发现到bug被修复并关闭的整个流程。

提单：测试人员发现bug并提交bug给到测试经理；

规范审核：测试经理迪对提交的bug进行规范审核，看提交的bug信息是否正确；

流程：多名测试人员发现bug并把bug提交给测试经理进行规范审核，如发现所提交的bug不规范，则直接打回给到测试人员，并查看是否有与其他的测试人员提交的bug重复，如重复则把提交的bug直接丢弃，如不重复则提交至开发经理，开发经理分配给至具体的开发人员。根据项目的情况和项目的进度，开发人员对分配的bug进行修复（根据bug的严重程度对bug进行处理，越严重的bug优先级越高，越先处理），建议性的bug可以延迟修改，开发人员把bug修复好之后提交至测试经理进行分配给具体的测试人员（如果bug严重可以直接由开发人员提交给至bug的发起人进行验证），所提交bug通过验证则关闭bug，如果发现bug依然存在则重新打开bug。

1）新提交bug（测试人员测试结束后测试报告中测出的bug）（new）新

2）确认分配给开发人员的状态 （open）开放

3）拒绝修改bug状态 （declined）拒绝

4）开发人员已修复bug，等待TE测试的状态 （fixed）修正

5）项目组评审通过的延期处理的bug状态（下一版本修复） （deferred）延期

6）缺陷已被修复状态 ，测试已确认修复 （closed）关闭

7）经过验证发现bug未被修复 reopened 重新打开

3、bug的严重程度和优先级有哪些？ bug的严重程度都是相对的

致命 1 L1 l- level 系统崩溃，电脑死机崩溃，软件无法打开

严重 2 L2 偶尔性系统崩溃，数据库锁死，闪退

一般 3 L3 按钮无法正常点击，比如京东输入框的相机

建议 4 L4 界面排版不美观不符合审美，按钮的大小，二维码人头像被遮挡

偶现 操作一百次 出现1-2次

必现 操作一百次 出现一百次

手机拍摄小视频；直接复现给开发

bug编号、bug标题、bug的重现步骤、bug的严重程度、bug的优先级（bug越严重，bug优先级越高）、bug的预期结果、bug的实际结果、bug的类型（由代码导致、需求文档、数据库、UI设计的bug、测试环境导致）、bug的状态、指派给谁、发起人（创建者）

QC：优点：1)功能很强大，结合有BUG管理，需求管理及用例管理等功能；2)和其它的测试工具，比如Loardrunner测试工具的接口做得比较好，数据可以在它们中共享；3)管理整个质量流程并使其标准化。4)通过手动和自动化功能测试管理应用程序变更影响    缺点：1)需要安装配置IIS和数据库，系统资源消耗比较大；2)纯英文版的且易用性不是很好，且收费；

JIRA

MANTIS

bugzilla：优点: 强大的检索功能，强大的后端数据库支 持, 丰富多样的配置设定等；    缺点：安装须要Perl和配置MYSQL数据库，过程比較繁琐，改动配置文件比較麻烦；英文版的，能汉化可是汉化后easy出现乱 码；

bugfree

禅道：优点：1）禅道开源免费，从下载到使用不需任何费用。开源的软件更能够根据企业自身需求在源码的基础上进行修改，让国内外众多企业节省项目管理成本。2）禅道的功能非常完备，可扩展性，且代码开放可做二次开发。3）禅道价格实惠，售后服务方式选择多且有官方技术服务的保障。   缺点：1）禅道的界面设计稍稍逊色，不够简洁，颜色使用也比较单一，不够丰富。2）虽然禅道有新手入门操作演示，但部分新人上手还是会存在一些问题。

组织：部门-添加下级部门、用户-添加产品经理，项目经理，开发经理，

测试经理，测试和开发

产品：产品-添加产品、模块-维护子模块、计划-创建计划、

需求-提需求（不评审）

项目：项目-添加项目、团队-团队管理、版本-创建版本、

任务-建任务、需求-关联需求

测试：版本-提交测试、用例-导出模板上传用例、bug-提交bug

后台：后台-发信配置邮件发送