• 软件测试面试必知丨这3个经常会被问到的问题要熟记


    在面试过程中,我们如何更好的体现出自己的真实实力?

    面试时,面试官经常会拿下面 3 个问题开场:

    1、请做个简短的自我介绍;

    2、简单介绍一个自己参与度比较高的项目,以及自己在项目中的职责;

    3、简单描述下你在项目中发现的最有成就感的 Bug;

    下面松勤程老师分别针对这 3 个问题逐一做下说明。

    1请做个简短的自我介绍?

    大部分的鸡汤文或者面经给出的建议可能是这样:

    面试官你好,我叫张三,出生于 2018 年 8 月 31 号,女,属狗,我喜欢爬山、读书、游泳、跑步、下棋、写代码、做测试,非常高兴能获得今天的面试机会,谢谢。

    恩,说的好不好,好,没毛病,但好像少了点什么,少了啥?少了我需要的信息,面试不是聊天,一问一答之间都是有目的的,所以我建议的回答方式可以是这样:

    面试官你好,我叫张三,2016 年毕业,最近的一份工作是在特斯拉公司,最近做的一个项目是特斯拉线圈的测试,我在项目中担任测试负责人的角色,本次换工作是因为公司业务调整,准备投入资源做超级高铁,砍掉了特斯拉线圈的业务,本次想找一个团队氛围好,技术上更有挑战的工作。

    这个回答我比较满意的原因有这么几点:

    主动告知一些必问的信息,比如公司和项目信息,比如换工作的原因,以及个人预期,这样做一方面减少了面试官来回问的时间,同时会让面试官感觉到这个人做事比较周到,或者说叫眼里有活。

    虽然是回答,但是在主导话题,或者说制造话题,比如他提到了公司和项目,但是没有详细介绍自己作为测试负责人的角色职责,如果我作为面试官肯定会继续问下去。

    能给面试官制造话题的面试者都是好的面试者(但是别把自己带沟里去了),如果在第一个问题上给面试官留下好的印象,对后面的沟通会非常有帮助。

    如果是你,你会怎么回答?

    2简单介绍一个自己参与度比较高的项目,以及自己在项目中的职责?

    如果第一个问题,面试者没有主动告知这些内容,第二个问题仍然跑不掉。

    针对这个问题,有的同学回答的重点会有点跑偏,比如会花费不少的时间去介绍自己项目的详细情况:

    我最近有参与一个 App 的测试,这个 App 有首页模块、好友模块、核心传输模块和个人中心模块,并且又分为 IOS 端和 Android 端,Android 端又分国内版和海外版,我主要负责 Android 端国内版的测试。

    看,说了这么一堆,只回答了项目信息的部分内容,我还是不知道「你」具体都做了啥,那我就需要再继续重复问一下这个问题。

    注意面试过程中的重点是面试者本人,项目信息算是背景信息,主要信息应该是面试者做的事情,那么只需要把能衬托面试者能力的地方凸显出来就行啦,比如:

    我最近参与一个 App 的测试,周期是两周,一共有 10 个开发和 4 个测试参与,我主要负责带领其他 3 个测试人员一起保证项目所有版本的质量。我的主要工作内容是包括需求评审、用例编写、测试分工以及自动化脚本编写。

    这样的话,信息是不是一下就丰富多了?多提供人员信息有助于面试官了解自己在团队中的位置,特别是关键角色的时候,一定重点突出一下,提供具体的工作内容是为了后面的沟通可以进一步展开。

    比如这个话题中的需求评审、用例编写、自动化脚本编写都是我想展开的,还是那句话,能够给面试官制作话题的面试者都是好的面试者,不过要记住,不要给自己挖坑,比如上面提到了自动化脚本编写,结果自己只是改改配置参数而已,并没有啥技术含量,这样的话问下去会很失望的。

    所以前面那句话可以完善下:主动把话题引导到自己的优势的面试者都是好的面试者。

    如果是你,你会怎么回答?

    3简单描述下你在项目中发现的最有成就感的Bug?

    这个问题几乎各个面经中都会提到,所以有很多面试者提前准备,那先说下回答的注意事项:

    要的是自己发现的,不是别人发现的;

    同样的,不要把别人发现的,冠名到自己头上,很容易出破绽的;

    最好不是常规用例执行中出现的 Bug;

    先看一个例子:

    「有一个项目新增了本地搜索功能,我把特殊字符作为输入时,程序发生了崩溃,然后和开发一起用 windbg 调试定位,最后发现是程序没有对异常进行处理。」

    「特殊字符输入不是常规用例就覆盖了么?这样的话任何人都能发现吧?」

    「恩,是用例执行时发现的。」

    「windbg 调试需要 pdb 吧,这个只有开发那有,所以实际就是开发给定位的呗?」

    「恩,开发定位的,我是提供了重现环境和 dump 文件。」

    前面说的关键点全部命中,常规用例能覆盖到的测试点,我们认为是大部分人都能考虑到的,既然这样,发现这样的 Bug,不应该是件很有成就感的事情吧?

    再来看一个例子:

    「因为一个需求,业务需要拦截注入的操作,开发提测后,确实满足了本次的需求场景,经过和开发沟通,了解到实现逻辑是处理了 API SetWinEventHook 的调用,但是经过研究发现 API SetWindowsHookExW 也可以达到同样的效果,但是开发没有处理,鉴于换个 API 就被绕过的成本太低,开发又新增了对这个 SetWindowsHookExW 的处理。」

    「怎么想到这个测试点的?」

    「Windows 系统 API 很多,而且繁复,所以碰到的时候都格外小心,之前也一直有查 MSDN 的习惯,所以在研究具体的实现方式时就发现了这个测试点,其他类似的情况还有很多。」

    「测试工具是开发帮忙写的么?」

    「不是,我自己写的。」

    这个例子中:

    自己发现的问题;

    不是常规用例覆盖的范围,搞清楚开发的详细逻辑,并做针对性的全面性测试,不是所有人都能做到;

    还有一个重点是,问题定位过程完全是自己完成。

    如果你是面试官,面对这两个面试者你会选谁?

    好了,我要说的就这些了,等等,我好像听到有同学有问题。

    「上面这些道理我都知道,但是我确实没有拿的出手的东西可讲啊,怎么办?」

    还能怎么办,赶紧回去补呗。记住,做每个项目的过程,都是我们成长和收获的过程。

  • 相关阅读:
    Ubuntu 下Apache安装和配置
    MariaDB二进制包简单安装部署
    Ubuntu下MongoDB的安装和使用
    Linux文件类型及目录配置
    centos7下挂载U盘和移动硬盘
    详解 比特(位,bit),字节(Byte),字符的区别 *(转)
    Socket使用及简单实例
    缓存
    字体小图标记录
    大流量下的兜底容灾方案
  • 原文地址:https://www.cnblogs.com/vvvviptest/p/13204218.html
Copyright © 2020-2023  润新知