问题均由朋友/粉丝提供的真实面试记录,帮大家解答,我义不容辞,但有些问题如果回答的不够仔细和正确,也希望大家能客观的指出改正,轻喷。
问题:发现了线上bug,作为测试,你是如何发挥作用的。
回答:注意,此题背景是已经出现了线上bug了,所以不要回答错时间,那样会让面试官觉得你压根就不仔细审题而判负。
答案要从以下几点来想:
主功能补救:作为测试,其实在补救线上损失方面除了配合开发迅速修复测试上线回归之外,能做的并不多,当然有些设计性事故,也有测试同学瞬间提出了很好的方案并被采用,毕竟头脑风暴是群策群力。
扩散补救:即在开发进行修复的初始,提出可能涉及到的其他相关风险点,比如线上已经产生的脏数据处理,在修复过程中产生的脏数据风险,其他相关功能点等。
流程优化:戏称亡羊补牢,但这里并不是毫无作用,起码可以预防下一次同类型bug出现,属于吸取教训的正确做法。首先是要明确这个bug是漏测还是其他意外出现,然后在流程上改革预防。
问题:toB 和 toC 业务,你在测试时有什么区别?
回答:这题其实需要分三阶段进行回答,主要是测试前,测试中,测试后。
测试前:即回答tob和toc的业务本身差别,和你的测试准备工作。众所周知,tob的业务属于企业服务,所以相比较toc来说其功能,数据量都是特别特别多的,很多时候只有接口,界面都是很对付的,逻辑也是更复杂的多的,自动化的难度会高的很。
测试中:tob相比较toc ,需要更注重接口逻辑测试,每一个参数都要测试,而界面ui和异常操作等,则可以相比较弱化关注。
测试后:即维护/总结,tob需要沉淀更多的技术文档,接口文档,参数说明,脚本统计等。毕竟tob的系统更复杂,很难像toc一样,打眼一看就能理解不少,写出很多用例。
问题:测试组任务你是给组员如何分配,根据什么规则?
回答:这属于管理经验范畴,你作为组长,可以回答的很书面一些,也可以回答的很接地气一些。但毕竟是面试,建议先正式有条理的书面回答,最后再补上一段本地化简化的措施,毕竟很多时候你没有足够时间去考虑所有因素。
经验问题:同一个分类组组员,谁的相关经验更多,理论上更适合来负责对应领域需求的。但并不绝对,你要懂得杀鸡焉用牛刀的道理。
组员性格:越重要的风险越高的项目,越应该让心细,沉稳,可靠的组员来负责。当然,也不能总欺负老实人,有些不太重要的,比如测试某个新出的广告栏这种 就让别人去负责。
组员排期:排期这个东西,作为管理者,你是要自己弄一份表格的,而且这个表格除了你安排的活记录之外,也要让组员自发的在上面维护和更新,毕竟有些okr任务的时间是不固定的。而且还要看看有些任务的饱满度,毕竟有些任务确实是个长期的,而且每天只占用一小会儿而已,领导要熟悉任务的真实压力,而不是被组员随意忽悠任务多难。在所有人都没有空闲排期的时候,只能优先考虑分配给那些压力不大的组员了,或者实在不行就跟上面反馈已经没有空闲人手了。
组员心态:一个真正的好领导,是可以观察到组员最近的情绪变化的,但并不是一味的照顾,要恩威利用。比如有的组员最近想要多拿奖金,想要冲击今年的晋升,你就要给人家机会,多安排一些任务多出成绩。有些组员最近生活中遇到事了,情绪低落,效率低下,你也要适当减少其工作量,否则容易直接压垮对方。而有些组员可能跳槽之心,人尽皆知了,那你的核心任务就尽量不要让其负责了,否则真出了问题找不到人。
公平原则:如果你一碗水端不平,引发组员不满那就不好收场了。但是任务每次都是不同的,人也都不同,要考虑那么多因素分配,你不可能分配的公平。而就算你分配的很公平,组员缺少你的全局观,再加上偏见,也可能会胡思乱想,认为不公平。所以如果到了很难公平的时候,你就要懂得利用信息差来让每个组员自己都觉得受到了照顾,比如小a的活很重,心里不满,你就可以把这个事给所有组员提起,让他们都觉得自己很幸运,然后对于小a,你就要告诉他下一次会很轻松,这样小a心里会平衡一些,而到时候其他人也会觉得小a应该轻松不会反感等等…而有些特别轻松的人,你就不能让他被别的组员知道。
关系问题:你作为领导,分配活的时候不能拍脑袋就分,那样要你何用?随便写个自动分配工作的脚本都比你靠谱。之所以还需要你作为领导存在,那么就是想让你发挥人性的光辉啊。比如某个组员和另一个组员关系很差,甚至有点仇视,那你作为领导就要尽量避免他们共同在一个项目内,有的开发和测试关系也差,同样道理。有的俩个人私下谈恋爱的,你可以尽量让其在一起负责项目,这样出了问题两个人不会互相甩锅,而且也会担心对方受到责备而都努力工作…等等等等。
本次就暂时写这么多。欢迎持续关注下一篇哦~
资源分享
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码,朋友们如果需要可以自行免费领取 【保证100%免费】