测试面试：某个版本／模块问题很多，但上线时间紧迫怎么办？
测试工程师技术面试，除了考核技术基础外，面试官通常也会抛出几个开放性问题，考察应聘者的测试实战经验、测试思路等综合实力。本文整理了资深测试专家刘晓光老师对两个测试面试经典问题的点评，供参考。
某个版本／模块问题很多，但上线时间紧迫怎么办？
又被面试啦，简要答一下：
通用的思路：基于风险的测试。测试的本质是抽样，时间资源总是有限的。要把资源用在刀刃上。先看看那个模块是干嘛的，是不是重要，如果出问题，影响面有多大？然后具体问题具体分析。
如果是核心模块，会造成重大损失，那质量一定是不能丢的，抽调别的力量加强这块儿投入，把风险明确的传递给主要干系人，必要时延期项目。
如果是非关键模块，识别出问题，可以做：设定一个最小实现目标，砍 Feature，用运营/客服的手段补足。长效方法：自动化防护网建立，让回归的时间成本、人力投入成本低下来；
在项目的初期就要能够一定程度的识别这种风险，早加资源，别让这种事儿变成 —— 到了最后：一坨毛病，而 DeadLine 不变。QA 最大的一个价值就是：像探照灯一样很早的预期到风险，并同步给主要干系人。
其实这类问题，主要是看看你以前在项目里怎么做的。实战经验非常重要，能积累很多“土方法”。自动化搭建的最大成本和难度是什么？
结合你工作中的感悟和思考回答会好一些。没有标准答案。
通用的来说：最大的成本其实是编写成本和维护成本。最大的难度就是遇到困难，觉得没收益，然后就废了。
自动化的实施跟被测物技术架构，开发模型，测试、开发人员能力，项目的类型都有很大关系。所以不结合上下文，没有标准答案。建议多看或者多经历一些实施案例，特别是成功了的实施案例。
这种面试问题，最好能够给出三种以前的解决方案，而不是光秃秃的一个加班或者自动化。
比如方案一：加班。
方案二：自动化
方案三：部分提测
方案四：重新梳理测试点
一下子给出4个方案，说明这个人思考问题挺全面的
页:
[1]
