每道面试题，看似简单，其实都包藏祸心~ 来从不同角度体验一下，无间道一样的面试问答吧~
问题均由学员/粉丝提供的真实面试记录，帮大家解答，我义不容辞，但有些问题如果回答的不够仔细和正确，也希望大家能客观的指出改正，轻点黑我。
已征得记录者放到公众号的同意，问题和答案我会脱敏，不会泄露当事人信息。
开始正文...
现在还会做功能测试么？
注意，面试官的这个问法，有三层意思在。
一：还有能力做功能测试么？你需要回答功能测试的基础理论，用例设计方法，流程等。
二：你之前还在负责一些功能测试么？你需要回答是，毕竟哪怕测开自动化也几乎没有能完全脱离功能测试的，如果有，那也不会坐在这种面试场所了。而且你要回答，你心甘情愿去做功能测试，因为这样才能让自动化/测开工具更接地气。
三：你还能不能接受未来的功能测试安排？你同样需要回答yes，一来是告诉面试官自己不怕苦不怕脏，一切为了质量服务。二来是告诉面试官自己听安排，不会顶撞。三来是告诉面试官为什么要做功能测试，是为了找出痛点，做出更像样的自动化。
功能测试与自动化测试的比例大概是多少？
这个问题我劝大家慎重回答。如果突然被问到这个问题，那么此次面试有点危险了。
因为无论你是照实回答，还是根据这次面试发挥回答，自动化比例高还是低，都有很大风险。风险来自于，和面试官公司测试组内的比例不同。假如面试官这边同事自动化占比20%，而你回答了自己之前80%，那么面试官就会产生严重担心，你之后受不了自动化的低比例而不稳定。反之亦然，面试官会担心你自动化经验不足。所以如果到了这个时候，只能看运气了。
所以在面试官抛出这个问题之前，你最好先下手为强，在前面某个问题的结尾随口反问一句面试官，他们的自动化比例大概多少。一来是堵死了面试官给你挖这个坑的可能，二来是自己之后也可以顺着面试官的话来说一个贴近的比例。
你们用例脚本写了多少条大概。
注意，这种问题，新手很容易陷入陷阱。尤其是没有真正统管过自动化项目的人儿，随口蒙了一个数，几十条太少，几万条太多，所以一般都会说几百-几千条之间。
其实，这并不是什么专业的回答，只能算勉勉强强。
真实的情况是，很少有人清楚自己测试组一共多少条脚本，虽然大概蒙的也差不多，但这并不是一个专业面试官想听到的答案。
应该回答一个推测的过程，比如我们多少个端，多少个大模块，多少功能，按照什么优先级来做用例脚本，最终推测出一个靠谱的脚本数。
我们身为测试，是纯理性的代表，所以对任何事务都不能张口就猜，要有理有据 让人信服才行。
（api自动化）你们api自动化的成功率高吗？成功率大概多少？
这种题一样有陷阱，不能张嘴直接答。
首先，api的自动化成功率，是一个动态的数据。不同端，不同时期，新旧功能，甚至不同人负责的结果都不可能完全相同。
所以要回答这个题，一定要分端，分业务，分模块，分时期来回答。当然成功率肯定不能太低，也不能保证完全100%正确。但是你也不能光回答说 95%这样。应该立即给面试官说明那5%错误是什么可能原因。是网络问题？是断言问题？还是脚本稳定性，测试环境原因等等。
（ui自动化）那你们的这一套，支持多环境吗（测试环境、正式环境、预发布环境）？这一套脚本，我怎么切换到其他环境上去跑？那你们每次切换环境测试就要去改代码么？
对于尚未形成平台化的自动化来说，环境是可以放在配置文件中设置的，所以并不用修改代码。而体现在ui自动化的代码脚本中，则是在一开始跳转到主页url中的host不同来实现。
而如果是形成了平台化之后，这个问题则很幼稚，对于平台级自动化来说，切换环境是个小儿科。实现的方法多种多样，要多方便有多方便。在执行任务前，页面上选中环境即可。而配置环境也可以在页面上直接进行。
不过面试官恐怕还有更深层的问题，就是切换环境后，数据怎么办？
众所周知，不同环境的数据是极有可能不同的，比如线上和测试环境。那么环境的url虽然很好改变，但是具体的数据缺难度提高，数据涉及到脚本中具体的每一句代码。而这里的数据显然是要跟环境所匹配，最好是绑定的。虽然在设计上很好设计，但是实现的难度颇高，无论是自动化脚本，还是平台级。
而我的ui自动化测试平台，数据是存储在数据库的，页面执行任务前选中本次要使用的数据json组。然后脚本会根据选中的组从数据库拿到完整数据，替换到脚本中的变量上。这个过程结合一些进程控制的自动化框架上来实现，并不简单。如果面试官追问，则可以继续细说。
本次就暂时写这么多。欢迎持续关注下一章哦~
