一，测试流程相关也是面试常问的，常见问法有：
1，发布流程是什么样的，或者公司测试流程，工作是怎么开展的
产品那边会提需求，进行需求评审，针对需求有不明确的地方及时跟产品开发沟通，还要注意与其他模块或功能会不会有冲突，注意细节，之后呢会对这个需求进行下拆分，工时的预估，然后把任务分配好，开始写测试用例，测试用例评审，评审通过后就会准备一些测试素材，数据之类的，开发完成后产品会先简单看一下功能是否符合预期，可以的话就会提测，测试这边先冒烟一下，流程跑通了就按照测试用例开始测试，然后发现bug记录在平台上，设置合理的优先级和严重程度，分配给对应开发，跟踪bug情况，回归问题，一轮测试完成后会提交到release环境，进行二轮测试，确保新功能不影响之前的功能，测试通过，整理测试报告，部署到线上，测试会进行线上的一个简单的配合测试，确保功能都在，上线成功，之后就可以对外公布，发布成功了，最新版本号，更新的主要内容这些和相关人员同步，相关人员确认后，就可以把用户账号切入新版本，发布过程中如果有问题，可能需要开发来做一个紧急修复，那如果在一定时间比如两个小时还是不能处理好的话，那就撤掉有影响的这个功能或者设置开关发布，如果是线上问题的话，就安排进行版本回滚
2，延期怎么处理，测试怎么赶进度：
我们一般在第一轮测试完成后如果bug比较多的情况下，就会考虑延期风险，告知项目中的成员，调整进度。如果在临近上线时候，严重等级高的bug还没有解决完，那就会考虑延期。
测试能够做的是提前预防吧，合理的进度规划是项目如期推进的一个前提，
项目的延期也有各种可能性，：第一个呢就是需求范围模糊，任务拆解不合理，导致预估工时与实际出现偏差，第二个呢有可能是多项目并行或者临时插入其他任务，导致资源冲突，第三个呢就是需求频繁的变更，团队沟通不及时，第四个呢，需求复杂，需要跟其他项目组进行联调，等接口等，两边排期需要协调
那么针对不同的情况我们能做的就是在需求评审阶段，细心仔细，有不明确的地方要及时提出疑问，可能会影响其他模块的改动也要提出影响范围，还有工时的确定也要在会上进行讨论，项目进行中有问题的话也要及时沟通调整，需要跟其他项目联调的需求也提前规划好，测试中发现的问题排好优先级，先处理影响流程的，避免block住。然后处理严重程度高的，一些比如界面显示这类的或者优化类的p4bug，影响范围可控，实在来不及缓缓也可以
3，你在项目中的角色，重要性体现在哪里？
稳定性对于软件来说还是很重要的，那么测试就是尽可能的去提高测试覆盖率，减少后期问题的发生，而且测试工作也是贯穿在整个项目流程中的，比如需求评审阶段，产品，开发，测试考虑问题的切入点都会有差别，从测试思维的话我们就能够去补充一些没有考虑到的场景，或者是跟其他模块功能的冲突这些，完善需求。再者我们写测试用例，进行评审，这个过程也会给开发补充一下思路，还会标注自测用例，这样开发在提测前自己简单跑一下，可以提高功能的质量。然后线上bug，测试也能先筛选一下，判断是用户操作问题，前端问题，后端问题，帮助开发节省时间，快速定位问题
4，版本迭代周期，一个版本写多少测试用例，有多少个bug
两周一个版本，周四发版，一个版本有十多需求，每个需求一般20-30条用例，可能有的模块相对简单一些就会少点儿,业务逻辑复杂的话，可能70-80条也是有的，整个版本比较好的情况下大概也就二十来个bug，问题比较多的时候5，60个也是有的，这样的情况下跟踪bug以及回归测试的工作量就比较大了
5，你觉得你们公司流程中不好的地方
我上家公司秉持最好的流程就是以客户为导向，这也不是不好吧，毕竟公司生存的补给来源都是来自客户,没有客户的维系不会有有任何一家公司可实现正常的运转，但这确实是给流程中带来了很多压力，比如有时候会临时加需求什么的，很考验团队的应急应变能力。遇到这种情况，一般产品那边先梳理出需求，拉上大家评审，完善下影响范围，如果项目中有不太紧急的需求就更换一下排期，如果不行的话就只能大家紧急赶工，测试这边就列下功能要点直接测试，过程中有疑问的也会直接跟产品开发沟通，测试完成后上线，发布紧急版本，
6，怎么保证测试覆盖率
现场环境总是会比我们的测试场景要复杂的多的，所以说不可能进行完全测试的，我们只能说是尽可能的提高测试覆盖率：
第一从需求阶段开始，尽量理清楚功能，有不明确的地方及时跟产品开发沟通，还要注意与其他模块或功能会不会有冲突，注意细节
第二测试用例设计科学，覆盖面广一些，设计完之后要进行用例评审，产品开发他们从不同的角度考虑问题，有补充的点及时加上
第三就是在测试执行的时候要认真，特别是回归的时候，要注意下bug的修复会不会对前面已经测过相关的功能点的影响
7，紧急需求怎么处理
因为我们的项目直接面向客户，所以难免会有用户设计师或者合作方突然有很紧急的需求，那么一般先由产品经理去梳理出大致需求，然后向上发邮件和OA呈批项目经理，通过的话就会马上加急处理这个需求，测试完成直接上线，发布紧急版本，当然紧急需求的弊端就是很容易需求设计不完善，或者测试场景覆盖不全，那我们只能说尽量仔细，但最好还是提前规划好时间或者调整下项目中其他需求的排期，保证系统稳定性。
8，敏捷测试，敏捷开发
敏捷测试其实就是“ 快速迭代 ”。敏捷测试就是持续地对软件质量问题进行及时地反馈。可以在项目开始时就开始进行,而开发和测试之间会不断进行集成，也就是说是连续的。测试驱动产品，开发，提前预防缺陷，而不是等开发完成了才发现很多问题，从而尽快地交付高质量的软件，这就是质量内建。
9，上家公司的上线标准
第一，测试用例执行完成，第二，剩余bug数量和严重等级，要达到一定的标准，比如说不能存在一二级严重程度的bug，遗留的3，4级bug数量，影响范围小或者是优化类的，当然这需要产品去协同判断决定，第三，上线前回归测试，确保不影响之前的功能
二，测试文档方面考察较少，若考察到问的也会比较浅
①测试计划
内容：
测试目标，测试范围，测试环境的说明，测试方法，测试工具，模块的划分，测试负责人，测试执行的时间安排，测试风险
其中模块的划分 需要根据测试人员对于业务的熟悉程度以及个人能力进行分配，工作量的估算也需要根据以往的项目经验，结合本项目的需求情况进行评估
②测试报告
内容：
测试用例的覆盖率，用例执行情况，功能实现清单，bug分布情况，bug遗留清单，缺陷分析，测试风险