如果你提的 BUG 开发不认为是 BUG 怎么办？
HTTP 的状态码有哪些？分别代表什么？
你对未来的职业规划是什么？
自动化框架如何搭建，用了多久？
你做自动化过程中，遇见过哪些难题？如何解决的？
你觉得你自己的优缺点？
写一个自动化的用例花多少时间？
执行一个用例花多少时间？
你最近在看什么书？
你平时通过什么途径学习？
11.怎么测试一个水杯？
- 简单描述下你在项目中发现的最有成就感的 Bug？
13.selenium/pytest/jmeter.......的底层是如何实现的？
- 实现了自动化测试为什么还会有 bug 漏测？
有一些不算奇葩吧，比如第一个，实际工作中挺常见的，面试问一下，考察下候选者的沟通能力，也很正常。
这样的问题都认为是 奇葩问题，可想而知，这位面试者应该也挺 “奇葩”
不奇葩的问题例举一二？
那什么问题不奇葩？
这些问题都很常规吧。。
这不都是正常的问题吗？不问这些问啥
看来我挺奇葩的，我就每次都会问最近在看什么书或者涉猎什么新的知识
姚涛
回复
纯个人想法，欢迎探讨。我的想法是软硬兼施：
硬：
1、结合需求文档等资料，明确和预期结果不符，说明是缺陷
2、拉上产品经理一起，从业务角度确认这个不符合预期，不满足实际业务需要，是缺陷
3、还是不行，但认为这个缺陷很重要的，继续上升到 leader 级别，由 Leader 级别确认解决
软：
1、日常和研发多吃饭聊天，打好关系，促进两边在这些事情上多配合，少扯皮
2、不要只提 bug，bug 少的时候也多夸一下研发质量好，绩效 360 评估的时候说说好话
最关键的：定好规则，把缺陷定义和原则明确清楚。
一般出现这种扯皮，说明大家对缺陷的定义理解不大一致，规则机制上不够完善。可以定期收集一些存在分歧的 bad case，一起对齐下，并持续完善相关的规则机制。用机制来明确缺陷定义和识别，减少扯皮。
你最近在看什么书？
答：《中华人名共和国劳动法》
哪个问题奇葩了？
邵晟睿
回复
具体看了什么内容，花了多少时间看了哪些章节？有什么收获跟感触可以分享一下呢？还是单纯的为了回答这个问题胡诌的，如果是这样那我会合理的怀疑你的诚信。你可以拿历史的书籍来忽悠我，但是不能拿假的内容来欺骗我。
反问一下，问什么问题才是正常的？
大家说说看哪些面试问题比较有水平，我蹲个回复
感觉都是挺常见的问题把
7 8 11 13 问题比较没含金量，别的问题都正常。
