51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 1028|回复: 0
打印 上一主题 下一主题

测试管理工具在面试中的重要性

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2022-9-9 17:04:21 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
本帖最后由 草帽路飞UU 于 2022-9-16 16:53 编辑

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时,就把需求、设计截图带上,自然省去了大多争议,除非开发确实觉得设计有问题,需要重新进行讨论设计的)

◆说一个你认为是bug,开发人员认为不是bug的例子?

答:在测试某一软件时,我找到一个bug,但是软件需求说明书里并没有明确要求或提到,但是和这款软件相类似的产品中,别的软件有一些固定的规范或者标准。比如:MyQQ中添加好友,对方同意后,发送方不会收到信息提示;而在

QQ中好友添加成功后,双方都会收到消息提示。

6.2◆禅道里面缺陷处理的基本流程
1、禅道里面缺陷处理的基本流程是:测试提交bug => 开发解决bug => 测试 验证bug => 测试关闭bug;

2、如果bug验证没有通过,可以激活:测试提交bug => 开发解决bug => 测试验证bug => 测试激活bug => 开发解决bug => 测试验证 => 测试关闭。

3、在创建bug的时候,必填的字段是:影响版本,bug标题,重现步骤,所属模块。

4、创建bug的时候,可以直接指派给某一个研发人员去处理,他可以来验证解决这个bug。

5、开发解决bug后,可以直接指派给对应测试员去验证,他可以来验证通过后关闭这个bug。

6.3★测试点内容:
测试点主要包括功能测试、界面测试、易用性测试、兼容性测试、安全性测试、性能测试、中断测试、网络测试,可靠性测试

登录测试点:


微信点赞功能测试点


微信发红包测试点


微信发朋友圈测试点


共享单车扫码功能测试点




本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-8 07:43 , Processed in 0.065341 second(s), 25 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表