年后在Boss直聘上更新了简历，该公司HR看到我的简历，问我是否有兴趣，我回复很感兴趣并投了简历。在经历7天漫长的等待后，终于等来了面试电话，一度以为简历被刷了。后来才知道投简历后公司有发邮件，里面附有链接可以查看投递状态和进度等。
一面
整体难度：☆☆☆
把握程度：☆☆☆☆
持续时间：一个小时
形式：视频面试
一面是个年纪和我相仿的女生，比较亲和有礼貌，简单自我介绍后，开始以下问题：
编程题：从一个数组里找到第二大的数。
冒泡排序并做切片。
sql题：略
问题1、你觉得敏捷开发是什么，敏捷测试对测试意味着什么？
ME：敏捷开发就是把大版本拆成了小版本，快速响应用户需求，迭代速度更快，要求测试能够尽早介入测试，对测试来说是个好事，测试版本变小了，测试会更灵活，但也面临着挑战，需要提高测试效率，这意味着测试人员需要提高自己的技能，特别是编码能力，如果测试人员能看懂代码，那么就可以先进行代码检查，实现测试左移，同时可以编写自动化脚本，提升测试效率。
问题2、如果一个版本预期开发2周，测试一周，到后面开发延期了2天，你应该怎么避免这种情况？
ME：及时了解开发进度，一旦有延迟的苗头就做好对应的措施：
①提前介入测试，比如可以先测试开发好的功能，如果实在测不完可以和项目经理，业务还有测试经理商量，是不是可以先把优先级高的功能先测完，优先级低的排下一个版本；
②如果一定要上，就尽量做好测试，并把风险和遗留问题写上，由业务他们决定是否上线；
③可以让测试经理定一个标准流程，如果提测时间延后2天，那么测试时间也顺延2天；
④向开发了解版本延期的原因，如果是估期不足，那下次排期尽量多留点时间。
问题3、怎么测试如淘宝里面的搜索功能，怎么分模块？比如搜索框是一个模块，按钮是一个模块，展示栏是一个模块，应该怎么测试？
ME：我根据功能性、兼容性、压力测试等方面回答。每个模块的回答都需要尽可能全面一点，局部和全局都需要考虑到。
问题4、怎么测试一支有按键的圆珠笔？
ME：
功能性：笔的出墨是否流畅，能否连续书写，写了一会停顿再写能否可继续写；按键是够能正常使用，包括能否按出笔，且使用时笔不会摇晃，并能收回笔芯。
易用性：长宽高是否符合人的使用习惯，笔的外壳硬度是不是能达到标准，不会被轻易捏碎。
兼容性测试：能否在不同材质的纸上流畅地写。
压力测试：不停书写能否一直正常；不停地按按键看是否会坏。
健壮性：会不会受温度、湿度、风、阳光等因素影响笔的正常使用。
问题5、怎么测试TM机取款功能？
ME：这个就按照场景再细分具体测试细节就好了。
问题6、怎么理解QA，QA的职责是什么？
ME：QA的职责是把控整个测试产品的质量，尽可能找出产品潜在的缺陷，评估产品上线的风险，为产品提供质量保证。
问题7、一页英文需求翻译。
ME：这个题是最后问的，面试官解释说他们有些需求文档是英文的，想考察一下我的英文能力，传了一份英文文档让我翻译。我扫了一下，问题不大，有几个单词不认识，我问了其中一个单词的意思，翻译了一遍。
问题8：你有什么问题想问我的？
ME：这个岗位是新设立的还是原有的？如果我进去大概是什么岗位？
一面总结：面试官很亲和，有时候没想到的时候还会给点提示，我也很快反应过来，会问还有吗？我都尽量想，把所有能想到的点都答了，她也比较有耐心。面试问的问题考察的主要是你怎么设计用例的，看你的思维够不够发散，比较考察平时的功力，不过这对我来说不难，因为我平时测试的时候想的都比较全面。问的问题都能答出来，当时感觉应该有下一面。当时问她多久得面试结果，她说一周到2周。在面完2个小时之后，我等来了我的二面邀约。
二面
因为我有前同事在该家公司，了解到的二面似乎不会问太多，我也预想着这次面试应该不会太难。结果打脸了。
整体难度：☆☆☆☆
把握程度：☆☆☆
持续时间：一个小时
形式：视频面试
二面是个稍有点严肃的男性面试官，应该是经理级别。在简单的自我介绍之后，开始了以下问题。
问题1、介绍一下的你的项目，你的职责是什么？
问题2、你的自动化是怎么做的？
问题3、做一道程序题。
文字较多，英文描述，不过很容易看懂。写一个函数实现功能，需要调用给出的一个函数。由于给的函数没真正实现，运行不了，不知道对错，应该答对了。
问题4、一道智力题，也是英文描述。
问题：你和你的朋友正在玩下面的Nim游戏：桌子上有一堆石头，每次你轮流去除1到3块石头。移除最后一块石头的人将成为赢家。你是第一个取出石块的。大意是2个人玩垒石块游戏，有一堆石块，每人可拿1、2、3个，如果最后那个人拿了最后的石块，这个人赢。如果让你先走第一步，应该怎样才能赢。
ME：这个题我一开始以为要做成程序题，在那写程序，但没什么思路，写了一点面试官说不用写说下实现思路就可以了，我说得不太好，感觉没答上来。
问题5、如果你负责的项目线上出了bug，你怎么解决？
ME：先了解bug发生的根源，看是我理解需求要偏差还是设计用例上有疏漏。如果需求理解有偏差看是需求描述是不是描述得不够准确，如果是的话可以和需求商量定一套比较规范的需求描述文档，看怎样才能把歧义降到最少；如果需求准确但我理解出了问题，那我下次梳理需求的时候会多问，多和需求讨论，争取每个需求都理解得很透彻；如果是设计用例上有疏漏，那我会考虑疏漏这个点的原因，并把这次疏漏的点记下来，避免下次再出现这样的问题。