首页 > 其他分享> > 第六讲缺陷管理工具

第六讲缺陷管理工具

2022-08-11 20:33:34 作者：互联网

6.1 禅道安装

◆注意事项：

1、安装的目录不能带有中文或者空格等其他字符，尽可能选择盘符的根目录，会自动生成sampp的目录

2、访问禅道的时候提示输入账号和密码，账号和密码在禅道集成运行环境框底下(账号：zentao密码： )

3、登录之后，选择开源版，默认账号admin/123456

4、如果出现禅道启动失败，是因为默认端口80的问题，在禅道控制面板-服务-配置端口-修改端口号

5、如果出现打不开网页等异常，在禅道控制面板-服务-卸载服务，然后再将禅道的所有安装包删除，再重新安装

◆禅道作用：

禅道：用例管理，bug管理

市面上常见的用例和bug管理工具，禅道、QC、鸡爪(jira)、pingcode、公司自研产品

◆使用流程：

1、产品经理添加产品，并且管理需求

2、项目经理创建项目，设置团队，产品关联，创建任务

3、测试经理在测试模块导入测试用例文件(也可以在模块中批量添加)测试经理在测试单子的模块中创建测试任务--关联测试用例--指派给测试人员

4、在测试过程中，对用例进行标注、通过、失败、阻塞、忽略

5、在测试过程中发现bug以及提交bug

◆面试题1：一条bug包含哪些内容？(bug生命周期是什么)

bug编号 bug标题 bug描述--实际结果-预期结果

Bug复现步骤--必现bug和偶现bug Bug所属版本和模块

Bug指派人员 Bug类型--功能-代码-UI-性能-易用性-安全

Bug级别致命的严重的一般的建议的()

添加附件

◆面试题2：bug流程/bug的生命周期

发现bug--创建bug--提交bug--验证bug--关闭bug

◆面试题3：如果你发现一个bug，开发认为不是bug，你怎么处理？

根据开发人员说不是bug，有2种情况：

一是若需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。

二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

可以看到上面的答案明显是偏向测试人员的，但有时开发说的并没错，测试要站在对方的角度换位思考。所以回答这个问题还可以从开发人员的角度延伸。

分析什么Bug会让开发认为不是bug
Ø测试人员描述不清晰
工作中也有测试人员把某些“Bug操作步骤”描述的只有自己看得懂，开发人员按照步骤复现Bug不知所云，搞错了问题所在。
Ø解决方法：
修改Bug操作步骤：清晰描述、无歧义、无冗余步骤，要达到即使给一个不懂的人去重现这个Bug，也能按照你的操作步骤复现。
（重要的是：有图有真相，带有清晰说明的截图比一大推描述来得直观，易懂。注意对问题区域以强调色（如红色）标识，并配以名字说明）
Ø难以复现的Bug
不是所有的问题都能用同样的操作步骤来复现的，有的Bug概率出现甚至偶现，或者是只在测试环境里出现。
Ø解决办法：
针对难以复现的Bug，需要保存截图或者记录log保留证据；对于只在测试环境下才会出现的，找研发在测试环境进行确认。这类Bug要慎重对待，规避风险。
Ø有争议的Bug
有争议的Bug多发生于建议类型的Bug：与同类软件不符、易用性、美观性等类型的Bug。
Ø解决办法：
这种问题是否要修改需要根据公司的项目类型进行讨论。开Bug评审会，在开发能实现的情况下说出自己的理由，改善产品。
（在时间允许的情况下，在项目测试接近收尾时开一个bug清除会议，对于剩余bug是否修复做明确处理）
Ø功能性Bug
与需求不符、与原型设计不符。有时候开发对需求没有深入了解可能会忽略或者搞错个别功能。
Ø解决办法：
拿证据（需求、设计说明书）给他看，这种bug自然合情合理。（最好在提bug时，就把需求、设计截图带上，自然省去了大多争议，除非开发确实觉得设计有问题，需要重新进行讨论设计的）