成都蓉华教育官网

蓉华教育“软件测试面试一指禅”第3期内容分享！

Q1 Bug的等级是怎么定义的

每个公司定义的 bug 级别标准都不一样，我们公司把 bug 分为：提示，一般，严重，致命四类。

提示：比如用户使用上比较繁琐、不够优化等；

一般：比如提示消息不够准确、清晰；

严重：比如主要功能无法正常使用，比如说一个电商平台支付流程有问题；

致命：比如程序无法启动、无法登陆等。

Q2 Bug的生命周期是什么？

新建(测试)—>指派(测试指派给开发)—>解决(开发)—>验证(测试)—>激活(没解决就激活)/关闭(已解决就关闭)

Q3 你怎么判断一个问题是属于前端还是后端的?或者是属于app的?

1）可以通过fiddler/F12抓包分析前后端的交互，如果前端请求参数不对则是前端的问题，如果前端请求参数正确但后端响应不对则是后端的问题；

2）也可以通过看日志，根据日志中的提示信息来判断是前端还是后端的日志；

3）根据经验判断，常见的问题类型如下：

前端问题：界面显示、字体、对齐、展示消息等

后端问题：数据问题、业务逻辑问题等

Q4 你提的问题开发不认为是问题，你会怎么处理？

首先我会根据需求文档来跟开发沟通，说明我认为是问题的理由，如果开发还是不认可，那我会找产品经理去确认这是否属于Bug

Q5 如果版本中做了超出客户需求的功能，你认为是bug吗？

严格意义上算是 bug，比如一个产品卖个几个客户的场景，可能 A 客户的需求对 B 客户就是不需要的，这种情况我们可以考虑在页面上屏蔽掉多余的功能

Q6 你们在测试中发现的所有问题都需要解决吗？

不是，比如：有的问题出现的概念很低、它的影响有限同时解决难度较大，这种问题可以考虑遗留；或者是那种只出现了1次但后面无法复现的问题；在软件版本发布的时候，会考虑把版本的遗留问题放在版本的发布文档(release notes)中。

Q7 你在xx项目中,有没有印象深刻的bug?是怎么解决的?

类似问题提前准备好，想一个有一定技术含量，不容易发现的bug来讲。

Q8 如果版本明天就要上线，你今天晚上测试发现一个严重Bug，你会怎么处理？

首先我会向我的领导汇报这个问题，从技术角度分析问题的影响程度，由领导决策怎么处理；如果需要加班处理，那会加班解决问题，最终保障顺利的上线。

Q9 一个产品在发布前经过了充分的测试，但上线后还是发现有一些问题，你觉得出现这种情况的可能原因是什么，你作为一个测试要怎么避免类似情况？

可能原因是生产环境与测试环境在数据、终端类型、操作系统、网络环境等等各个方面存在一些差异，导致在测试环境上发现不了的问题在生产环境上暴露出来了；规避的方案就是在测试中，要尽可能地考虑到生产环境上存在的各种场景，让测试环境尽可能地模拟生产环境，这样测试的结论才会更加准确。

Q10 web和app的兼容性怎么测试?(有的时候会问,我有一个app要做兼容性,你出一个兼容性测试方案?)

web 系统主要考虑对不同浏览器和操作系统的兼容性，app 主要考虑对不同操作系统以及不同设备(不同的设备的屏幕尺寸、屏幕类型、分辨率等都可能对app的ui展示产生影响)；

web系统要兼容不同的浏览器，主要要考虑不同内核的浏览器的兼容性：

1）Webkit内核的浏览器：谷歌、QQ 浏览器、360极速浏览器

2）Gecko 内核的浏览器：火狐

3）Trident 内核的浏览器：IE

如果需求文档中明确了要兼容哪些版本的浏览器，就按照需求文档对应的来测试；如果需求文档中没有明确要兼容哪些浏览器，可以借助网络统计数据来看当前客户主要使用的版本是哪几个，如果网上找不到相关的统计，那可以测试最近的3个版本。

app 要兼容不同的操作系统、设备类型等，怎么考虑？

可以借助第三方的统计数据来确定测试范围，比如如下统计反映绝大部分iPhone的用户都在使用iOS12和iOS13版本系统，那这两个版本应该是我们测试的重点；iOS系统的兼容性相对简单，Android系统因为厂家定制太多，碎片化严重，所以兼容性测试的工作量很大；可以每个厂家选择几款销量高的设备来做测试。

测试设备的来源：公司采购、员工自己的手机、租设备；也可以考虑购买第三方的兼容性测试服务(WeTest等)

本期内容和大家分享到这里，关于软件测试面试常见内容，我们下期还会和大家继续分享，尽请期待！