1、介绍公司的测试流程？如果没有做过测试的话，也是按照他理解的说一下。
分析需求--->分解需求--->制定测试计划--->设计测试用例--->评审测试用例--->执行测试用例--->提交bug--->验证bug--->测试报告--->测试总结/项目总结。
大部分都是这样，说流程主要是看测试人员的参与感。如果能细化流程里的内容， 会有更好的效果。比如可以多说下每个阶段做了什么，怎么做的，产出的内容是什么样的。
不过一般面试官也会挑出一两个内容详细问的。
至于详细内容， 这里不再一一列出来，需要的同学可以在网上搜下，最好是自己根据实际工作来总结下，百利而无一害~
当然不是每个公司的流程都一定是这样，但是都差不太多少
有时候这个问题也会延伸到开发模型(w模型或者V模型）之类，毕竟测试流程也是融入其中的。
2、测试用例设计的方法有哪些？
（1）等价类划分法
（2）边界值法
（3）错误推测法
（4）因果图法
（5）判定表法
（6）正交实验法
（7）场景法
可以再简单描述下，每种方式可以得出什么测试用例，在什么场景下使用。
主要是看出当从不同的切入点进行分析时，是不是得体。毕竟这些方法基本上都是会交叉使用的，不同的角度和粒度会选用不同的方法。
3、给你一个模块或者一个案例，让你设计下测试用例。
设计出来的用例的可能很简单，但是关键点不在这里。主要是看面试者会不会主动询问下其他的信息。比如了解这个案例或者模块的背景，应用场景，用户角色等等相关的需求信息。
这点比较重要，毕竟有这些信息，设计出来的用例更有针对性和更接地气，也能反应出一个测试人员思路和沟通能力。
4、说下公司的bug流程。
这个也是每个公司不一样（大同小异)，按照个人理解或者实际操作的来了.
发现bug--->确认是否是bug--->(定位bug)--->提交bug--->验证bug--->测试报告--->bug总结
其中定位bug也不是必须的，如果做过这个内容可以说下, 没有做过的，也不要提这个。定位bug也是比较讲究的事情，有实操经历的可以在流程结束后，单独提一下。定位的过程是一系列分析的结果，也比较考验测试人员，对整体系统和业务的了解能力和分析问题的能力。
5、上次发现的最有意思的bug或者最深刻的bug是什么？
主要侧重评估测试人员对bug的敏感度。一般感兴趣的bug，相对的对那块可能比较感兴趣，也有可能是之前没意识到，突然出现了，然后自己发现原来这里也会有问题，导致记忆比较深刻。
有的话，都可以说，有的可能是业务bug， 有的可能是设计bug， 有的可能是部署时出现的bug. 有的可能是自己分析了好久定位了好久才出现的bug. 根据实际情况来回答即可。
一般来说，这个回答会进一步展开的，会有更多关联的来回问答。
题外：在发现的bug的时候，多试试分析和定位bug, 也可以跟研发那边了解下，是如何修复的，边聊边自己思考，说不定修复的时候，也有可能导致其他的问题。对bug理解的越多，测试起来就更得心应手。
6、用过的测试工具有哪些？
可以按实际情况来回答。一般分为测试管理工具和测试工具。
测试管理工具一般是需求以及测试用例的管理工具，比如jira,禅道，Mantis等等，如果能自己搭建的话，也可以顺带说下。
7、自己测试的时候，对哪方面比较感兴趣？
比如说对界面比较感兴趣，对业务比较感兴趣，对数据库感兴趣，对服务器感兴趣，对服务感兴趣等等，
这个是要是看面试人员有没有自己的偏好。
如果回答了，会有进一步的交流，比如数据库的内容、服务器的内容、服务的知识等等。如果有了解的话，可以进一步延伸。
8. 平时用的多的软件或者app是什么？
不一定都会问。只是个人比较喜欢问这个问题。
如果有的话，一般会追问为什么喜欢这个，而不是喜欢有相同功能的另外一款。
主要是看面试人员的审美标准是什么?有没有自己的见解。其中也会了解面试人员一些有意思的想法。事实也证明，这个问题聊的多的人，都是很有自己想法的，在实际工作中也是会思考很多的人。
其他的很多就是在这个八个问题里发散的，也主要是根据回答的情况来。假如对业务很有想法或者感兴趣的，会给到一个简单的需求，看看怎么设计业务流程，不一定要真答对，只是看下应变能力和真实的想法。诸如此类等等。毕竟测试转行做需求、做业务、做研发都是有可能的，即使不转，偏向对应的工作能容也是可以的。
以上就是概括了下面试的一些内容，细说就很长了。整理的一些点，不管是刚进入测试的或者已经做过一两年的，都可以用里面的关键字内容去找资料学习和加深下。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
