目录
1. 身份证年龄问题 3
2. 自我介绍 3
3. 工资结构问题 3
4. XX测试项目介绍 4
5. 说一下你们功能测试的工作流程 4
6. 说一下你们如何做性能测试的 6
7. 说你一下你们为什么要做自动化测试？是如何做自动化测试的？ 6
8. Selenium介绍 7
9. 项目团队相关介绍 7
10. 在测试过程中遇到的问题 8
11. 测试计划的编写 9
12. 测试报告的编写 9
13. 兼容性测试 9
14. 禅道软件，缺陷的生命周期 10
15. 购物车测试 10
16. 支付测试 11
17. 抓包工具 12
18. Jmeter介绍 12
19. 面试官问，你还有什么问题要问的么？ 13
20. TPS的计算公式 14
21. 部署java代码的war包到Tomcat服务器 14
22. 你的测试职业发展目标是什么？ 15
23. 你自认为测试的优势在哪里？ 15
24. 如何测试一个纸杯？ 16
25. 什么是CMMI模型 16
26. 你的职业规划是什么（你对未来的规划） 16
27. 产品上线后出现bug，如何进行回归测试？ 16
28. 从上一家公司离职的原因 17
29. 你认为功能测试的关键是什么，怎么做好功能测试 17
30. 计算机科学与技术专业课程 17
31. 常见的Linux操作系统 17
1.身份证年龄问题
以下仅供参考，大家要加入自己的话术，不要完全一样
身份证问题：我家在某某的小山村，小时候由于计划生育问题迟了X年上户口，当时上初中都是从村委会打的证明才上的，如果您对我年龄还有疑惑，我看能不能让家里人从公安局打一个证明（这也需要时间，等到证明到估计你早入职了，到时有没有另说了）。
躲计划生育，老爸老妈出去躲了X年
农村当时老人上报的，上报的时候写错了
父母是老师，上学跳级
直接读的专升本3+2
2.自我介绍
以XXX简历来举例（参照下面的案例，编写你的自我介绍）：
面试官您好，我叫XXX，现年XX岁，来自XX，平时比较喜欢看书和上网浏览信息，性格也比较随和开朗，和身边的朋友能融洽的相处。大学毕业之后进入河北东软软件有限公司从事java开发方面的工作，一开始从底层做起，慢慢的积累经验，也学习到了很多的东西，在这个公司后期慢慢接触到了软件测试方面的工作，工作了一年之后，为了得到更多的锻炼并且获得更好的发展机会，我来到了北京，在北京望时高科科技有限公司做软件测试工程师的工作。
在此期间我一共参与了多个项目，有电商类型的，也有信息管理系统，主要是以功能测试为主，依据软件需求来编写用例，执行测试用例并提交缺陷，除了功能测试，也做了一些自动化测试，性能测试和接口测试方面的工作。
经过这么长时间的积累，我从自身的能力和发展出发，在功能测试基础上，主要想往自动化测试方向发展，一个是因为自动化测试可以提高测试的效率，再有就是目前很多公司也把自动化测试作为比较重要的发展方向。
通过这几年的工作我自身的能力有了很大的提升，工作认真细致，团队协作能力比较强，能够很快的适应新的工作岗位和工作内容。
这就是我的基本信息。谢谢！（告诉面试官介绍完毕）
3.工资结构问题
一般公司公积金缴额个人交工资的12%，公司交工资的12%，但是有好多公司交的基准是当地工资的最低标准，比如，你的工资10000，当地最低工资标准3000，如果是全额交公积金公司和个人都会交1200，但是如果按最低标准交那么公司和个人都会交360。如果五险一金按全额交的话工资到手差不多有总额的75%作业，如果按最低标准到手在85%左右。
当然，我们具体回答的时候可以圆滑一点，比如他如果说交了那么多到手还有那么多啊，那你可以说平时加班、绩效什么的有一些补偿。
有一个概念叫做绩效考核，面试有可能会被问到，一般公司除了给你发工资外会有一个绩效工资，绩效工资的分配不同公司不一样，同一个公司不同人绩效也不一样，绩效工资就是公司对员工这个月的工作表现（工作完成情况、工作完成质量、有没有出现什么事故等等）而发的工资，比如我上个公司绩效分为ABCD几个等级，等级A绩效奖励1000元，等级B绩效奖励500元，等级C绩效奖励200元，等级D绩效没有奖励。
4.XX测试项目介绍
以XXX最近一个项目举例（其他人除了项目功能以外，皆可以套用，包括数据）：
XXXX是个电商的项目，主要涵盖食品，服装，数码家电，百货饰品，母婴玩具等产品，主要功能有会员注册及登录，商品的分类展示，购物车，订单查询，积分兑换，留言管理，订单管理，促销管理等模块，我在其中担任测试工程师的职务，主要负责注册登录、购物车、订单查询、订单管理等模块的测试工作。
我们依据产品经理提供的需求文档编写测试用例，开发提交测试版本后，我们先进行冒烟测试，冒烟测试通过后，再分模块进行具体的功能测试，执行测试用例，通常第一轮测试会重点关注功能细节方面的测试，比如页面的显示，链接是否正常跳转，输入框的数据校验，操作的操作能够正常提示等，执行用例的过程中发现bug使用禅道进行提交，在测试用例执行完成后我们会进行随机测试，目的是更多的寻找bug，每轮测试完成后我们会提交测试结果给开发人员，开发人员会进行缺陷的修改，修改完成后再次提交测试，我们会进行回归测试和bug验证。
这个项目大概进行了四轮的回归测试，发现的缺陷中严重级别以上都得到了修复，一般级别以下的修复率也达到了90%，也没有新的缺陷产生，由于项目紧急并且剩余的10%缺陷对各功能模块的正常使用没有影响，因此对这部分缺陷做了遗留，后续再进行修复，项目的测试工作结束，我们就开始编写测试报告，提交给项目经理。在这个项目中我们一共编写了大概700多条测试用例，一共发现大概200多个缺陷，除了进行功能测试，也做了一部分接口测试，还有性能和自动化测试，这些测试我都有参与，这是这个项目的情况。（接口、性能、自动化测试可以不在项目介绍的时候展开，面试官问到的时候再进行单独的回归，参考相应的话术）
5.说一下你们功能测试的工作流程
（注意：这里说的是功能测试流程）
测试申请提交——测试计划编写——测试需求分析——测试环境搭建——测试用例编写——测试执行——测试缺陷管理——测试报告编写——测试用例维护
（每个点展开进行一些突出点说明，比如测试执行中我们可以加入冒烟测试过程、版本配置管理）
（可以结合项目来介绍，参照2.项目介绍）
我的实例（比较口语化，不适合笔试题的答案）：
好的，我上一家公司的工作流程、制度是比较完善的，下面我根据我们一个项目的测试流程来给您说一下我们测试的工作流程：
首先，项目需要测试时，研发项目经理会给测试部门提交一个测试申请，测试申请中包括测试内容、测试环境要求、注意事项等，测试负责人根据实际情况确定是否开展测试工作。 如果测试申请通过，接下来由测试负责人进行测试计划的相关工作，包括时间安排、人员任务分配等等
然后是进行测试需求分析，一般我们从三个方面去考虑：
1、功能需求--产品应该完成哪些功能，即向用户提供的功能，一般单个模块的需求分析是比较简单的，对于比较难的是在模块之间的需求点分析；
2、非功能性需求-比如说性能达到什么要求，可靠性方面，响应时间，扩展性，性能方面等；
3、限制条件--在需求分析中需要考虑一些条件约束，规则等，比如客户的约束，行业的约束，法律的约束以及自己的约束等
为了保证需求分析足够全面，我们测试组内部会进行需求分析讨论，包括：测试人员、测试经理、研发人员。需求分析编写后会进行需求评审，参与人员一般为测试人员、测试经理、研发人员。
需求评审通过后接下来就是测试环境搭建和测试用例的编写。测试环境一般是由我们测试人员来搭建的。需求分析到位后测试用例编写是水到渠成的，用例编写完毕后我们会进行测试用例评审，以保证用例的正确性，我们公司在QC（或者禅道）上进行测试需求和测试用例的维护，刚来公司的时候我们用例库中有600多条测试用例，每轮测试完毕会对测试用例进行维护，离开公司的时候我们用例库中的用例差不多翻倍，1200来条吧。
用例编写完毕后就是测试执行了，为了保证测试质量，测试版本和测试人员交叉进行测试，上一家公司包括我一共三个测试人员，期间有动态的变化，之所以安排三个人员一是为了缩短测试周期；二是提高测试效率，防止功能测试用例漏测，具体到这个项目我们是这样安排的，比如：第一轮我们进行全功能测试，我测试主菜单下的十个子模块，另外两位同事测试其他模块，第一轮我们会发现大量的缺陷，测试结束后返回开发进行修改；第二轮我们仍然进行全功能测试，在这个版本上我们会先把第一轮发现的缺陷进行回归，然后进行全功能测试，这时候我们测试的模块进行一个互相，以防止功能测试枯燥、惯性思维等原因带来用例漏测的现象；从第三轮后的多个版本我们进行回归测试直到前两轮测试出来的缺陷全部修改（除了拒绝和遗留缺陷）；之后我们再进行一轮全功能测试，这轮全功能的目的是用来验证前面多个版本的回归测试是否引入了新的缺陷，如果没有发现新的缺陷，那这个项目我们就算测试结束了，如果发现了新的缺陷，我们又进入回归测试的流程，直到缺陷全部修复，如果回归测试的版本少于3个我们认为项目测试通过，测试结束，如果回归测试版本大于等于3个，那我们又会回到全功能测试，如此反复直到达到我们的测试标准。
我们的缺陷也是通过QC（或者禅道）进行管理的，测试过程中如果发现重大缺陷我会直接找研发人员，让他们尽快进行修复然后再提交缺陷管理工具，在研发人员进行敏捷开发快速提交测试版本阶段我当时是对出版本的频率进行了一个控制，我的做法是等待测试的缺陷（也就是已修复待回归的缺陷）达到十个左右通知研发人员提交版本提交，这样做的目的是为了减少缺陷修复影响其他模块引入新的缺陷。
项目测试结束后就是测试报告的编写和测试用例的维护，测试结束我们会将测试用例进行用例的补充和反例补充。
以上就是我们之前的公司的功能测试流程。
6.说一下你们如何做性能测试的
还是以一个项目举个例子吧，XXX是个电商的平台（OA平台，在线教育，互联网金融等web系统都可以），公司这边预估的日访问量可能在几万人次吧，并发量我们测到大概300用户左右，我们主要是针对几个重点页面和功能做了测试，主要对比一下在不同并发用户下的响应时间，还有极限并发用户的情况下系统运行状况，我们选了首页，商品搜索页和注册登录等功能作为测试目标，工具我们选用的开源性能测试工具jmeter（如果被问到为什么没选Loadrunner，就说Loadrunner是商业软件，需要破解，jmeter可以完成中小网站的性能测试），先使用badboy工具录制脚本，然后转换成jmeter可用的脚本，在jmeter中打开，将线程组分别设置为50，100，150，200，300，分别进行测试，因为测试并发，需要设置集合点，在jmeter中使用同步定时器来同步虚拟用户，使用聚合报告和一些图表信息来获取测试结果，最后编写报告，主要对比分析在不同并发用户数的情况下，这几个测试项目的响应情况。我们也会监控服务器的资源情况，比如cpu，内存，网络IO，磁盘IO等（Linux下可以使用top命令查看服务器的资源占用情况）
JMeter进行性能测试操作步骤：
1.badboy录制脚本
2.导入到JMeter
3.JMeter配置，包括：添加线程组、取样器、参数化、断言、监听器、集合点等
4.运行脚本（测试点包括系统吞吐量、用户并发量、响应时间等）----完善指标
5.查看报告，分析报告
7.说你一下你们为什么要做自动化测试？是如何做自动化测试的？
项目中后期，项目软件版本比较稳定，需求也基本不会频繁变更，这个阶段是在进行特定缺陷修复，版本快速迭代，为了验证此阶段某个缺陷修复后是否会影响其他功能模块，我们引入了自动化测试，减少回归测试中重复的工作，提高测试效率，可以比较精准的获得测试结果（脚本的执行不依赖于人的主观情绪）
我们的自动化测试主要是web UI的自动化测试，使用的是selenium+Python，主要用于冒烟测试和主要功能的回归测试，作为手工测试的一种补充，提高测试效率，减少一些重复性的测试工作，自动化测试通常是在UI页面完成和稳定之后开始进行的，依据功能测试用例编写自动化测试用例，主要是加入一些元素的定位说明和验证功能是否完成的操作，然后依据自动化测试用例，使用Python编写自动化测试脚本，驱动火狐浏览器，用Selenium提供的API进行页面元素的定位，并对元素进行操作，比如点击，输入内容，下拉框选择等来模拟手工的操作。
脚本编写调试完成之后，我们在每次开发提交测试版本后用它来进行冒烟测试，也会用它来做主要功能的回归测试。
Selenium元素定位的八种方法：
ID，name，className，LinkText，partialLinkText，xpath，CSS，tagName
使用哪些浏览器：
通常我们会使用火狐或者谷歌浏览器作为自动化测试使用的主要浏览器，因为这两个浏览器对大多数的web网站支持比较好，只有在兼容性测试的时候才会使用IE浏览器的驱动。
我们这个项目进行周期比较长，在中后期的时候部分功能引入了自动化测试，这个自动化处于功能自动化阶段，比如冒烟测试，用来大致缺陷版本功能是否能运行正常；另外比如回归测试，我们会把测试过程中发现的大部分缺陷都编写自动化测试脚本，虽然这个缺陷在以前的版本中解决了，但是不能保证后续可能的版本管理问题重新引入之前的缺陷，经过这样的处理，每个版本出来基本能保证以前的缺陷不会重新再次出现。我们使用的自动化测试工具是selenium+python，对于功能自动化来说，我认为很简单，总的来说就是两点：元素识别和容错处理。元素识别比较简单常用的方法：ID，name，className，LinkText，partialLinkText，xpath，CSS，如果元素识别出现问题我们也会在后续的容错处理中进行处理；对于自动化测试容错处理非常重要，我在测试过程中采取了如下四种手段：1.对于每个自动化测试用例的执行结果我把它输出到了一个文档中，通过这个文档我可以看到每个用例的执行结果，如果出错，错误在什么地方，这个文件可以给领导和相关责任人查看；2.如果出错，python自身可以获取到错误编号、错误类型、错误描述，我将这些信息单独保存在另外一个文件中供我自己来排查错误；3.python自身有一套容错机制，通过try-except来处理错误，保证一个用例执行出现问题，不会影响下一个测试用例的执行；4.最后，我们的自动化一般都是在晚上执行，我会采取一个录像操作，用来进行错误排查。
8.Selenium介绍
Selenium 是一个基于浏览器的自动化工具，它提供了一种跨平台、跨浏览器的端到端的web自动化解决方案。Selenium主要包括三部分：Selenium IDE、Selenium WebDriver 和Selenium Grid：
• Selenium IDE：Firefox的一个扩展，它可以进行录制回放，并可以把录制的操作以多种语言（例如java，python等）的形式导出成测试用例。
• Selenium WebDriver（selenium 2.0）：提供Web自动化所需的API，主要用作浏览器控制、页面元素选择和调试。不同的浏览器需要不同的WebDriver。
• Selenium Grid：是用来对测试脚步做分布式处理，即在多台机器上运行Selenium的脚本。
使用Selenium+Python进行自动化测试需要的环境搭建：
安装JDK1.8，配置Python运行环境。
脚本开发工具：Pycharm
9.项目团队相关介绍
（这些可以标注到自己的B简历当中。）
项目团队的人数：通常10~20人左右，自己选择一个数量，测试人员通常2~4个人左右，测试人员和开发人员的比例1:4左右。
迭代周期：通常第一个版本时间会比较长一些，一两个月吧，后续新功能的迭代和缺陷修改的版本迭代周期会短一些，通常是一两周左右，甚至在项目后期只做缺陷的修改的时候，几天就会发布一个测试版本。
一个测试人员通常一天可以执行几十条（100条以内）测试用例，这个还要看具体的用例复杂度
10.在测试过程中遇到的问题
1. 提测质量差
问题描述：提测版本差，有些均未通过冒烟测试
如何解决：
通常需要测试的负责人去和项目经理或研发负责人沟通，要求开发人员在提交测试版本之前要进行必要的自测，提高冒烟测试通过率。
提高冒烟测试的效率，可以采用自动化测试的方法，快速验证提测版本，遇到不合格的及时打回重新提测
2. 功能反复
问题描述：在上一个版本是OK的功能，在新版本中功能失常
解决方式：
对大功能反复，是这么处理：冒烟测试由开发来完成，冒烟通过后，再交由测试
对小功能反复，没有有效的处理方式，测试这边可以做的是，加强测试，这个问题，在发布前夕好了很多，但问题仍然存在
3. 需求不明确，前后不一致
问题描述：需求不明确，特别在一些边界，不统一
解决方式：
由于项目已提测，因此在整个周期里，对于交互需求方面的疑问直接找相关人员去确认。
4. 测试和开发信息不对称
问题描述：测试获取到的消息，与产品实现的方式不一致，如：有的功能定义了，但产品并未实现或实现方式与定义不一致
解决方式：
强调消息需要通知到测试，通常有关需求变更的会议都要有测试人员参加
5.你发现的一个bug，开发人员认为不是bug，你会如何处理？
首先需要自己先去查看需求和被测程序，反复验证，确认是缺陷后，和开发人员进行沟通，从影响用户使用的角度去说服开发人员，如果还是不能达成一致，在确保是bug的前提下需要提交给测试经理或项目经理进行解决。
6. 测试的过程中，突然发现时间不够，应该如何去解决？
遇到这种情况在测试过程中很常见的，通常我们采用三种措施，一是通过加班来增加测试时间，二是和项目经理或测试经理沟通，从其他部门借调人员来临时帮助执行测试用例，三是与项目经理沟通，能否通过与客户协调，延长测试时间以保证软件的质量。
11.测试计划的编写
通常测试计划是由测试组长/测试主管/测试经理来编写，但测试组或测试部内的主要测试人员也会参与编写，因此所有人都需要知道测试计划的主要内容。
测试计划包含的主要内容：
测试目的，测试范围，测试策略和方法，测试的软件硬件环境，测试的进度安排，测试风险分析等。
12.测试报告的编写
测试报告包含的主要内容：项目背景、测试环境及组网图、测试内容、测试方法、人员安排、时间安排、测试覆盖率、缺陷分析、测试结论、意见建议等。
测试报告主要用来统计和分析测试过程中的数据，主要包括测试用例的数量，执行了多少，通过了多少，未通过的有多少；缺陷的总数，缺陷的等级分析，缺陷的高发点分析（哪些模块的bug比较，通常选2~3个左右，并分析原因），缺陷的错误类型，缺陷的报告人，缺陷的修改人等
13.兼容性测试
兼容性测试通常是指同一个软件在不同的软硬件环境下的运行状况，通常在做兼容测试的时候主要关注软件系统的显示和主要功能的操作正确性，而不再关注功能的细节。
Web系统（B/S）主要关注软件系统在不同的浏览器下的运行状况，通常会考虑主流的浏览器如火狐，谷歌，IE，360，QQ，搜狗等浏览器，也可以同时考虑主流浏览器的不同版本，通常会依据项目客户提出的要求或者根据软件产品的用户所使用的浏览器调查数据来决定测试哪些浏览器的兼容性。
IE浏览器的兼容性测试我们主要使用IETester工具来模拟不同的IE版本来进行兼容性测试，比如IE5~IE10，不过我们的系统目前只支持IE9和IE10，其他的IE低版本不再支持
手机APP端的兼容性主要考虑手机的品牌，操作系统（如都是安卓系统，但小米，华为，魅族等都有所不同），分辨率（或屏幕大小）等，要记住苹果操作系统的软件和安卓系统的软件是两个不同的软件。
14.禅道软件，缺陷的生命周期
缺陷的生命周期（也就是缺陷状态）：新建-已分配-等待测试-测试通过-测试不通过-遗留。
禅道是一个项目管理软件，分为开源版和专业版，可以用来管理整个项目的过程，我们公司用的是开源版本，主要用来管理测试用例和缺陷，我们会依据产品需求编写需求文档，使用禅道来编写测试用例，待开发人员提交测试版本后，开始执行测试用例，在执行测试用例的过程中如果发现缺陷就在禅道中进行报告并提交给开发人员，开发人员接收到bug后进行修改，修改完成后标注缺陷为已修改状态，提交新的版本后，我们进行回归测试和bug验证，如果bug确认已经修改完成，就关闭，如果没有验证通过就置成未修改状态再次指派给开发人员进行修复。
15. 购物车测试
购物车的测试主要考虑以下几个方面（掌握思路即可）：
界面测试：
购物车中的商品信息显示是否正常，加入购物车后的商品价格是否显示正常
功能测试：
从商品详情页面是否可以加入商品到购物车
购物车页面打开的同时，在其他页面添加了商品，购物车刷新后，新的商品能否显示
若未登录，点击加入购物车，是否可以添加进购物车（缓存方式）或者会直接提示登录
在商品未选择的状态下，结算是否按钮为灰色无法点击
勾选商品后，结算按钮为可点击状态，
勾选商品后，自动计算商品的总价，价格是否正确
勾选商品后，点击结算按钮，进入确认清单的页面
在购物车中，可以修改商品的数量
在购物车中，可以将已加入的商品移除购物车
在购物车中，可以讲商品移入收藏夹，移入收藏夹后，商品在购物车中不显示
购物车中的商品是否显示优惠或促销信息
批量添加商品到购物车
在购物车中批量移除商品
性能测试
打开购物车页面要多久
最多可以添加多少商品到购物车中
批量添加商品和移除商品的速度如何
兼容性测试
如果是web商城，测试在不同的浏览器上功能是否正常
如果是app，测试在不同手机品牌，不同操作系统版本和不同分辨率下的功能是否正常
16.支付测试
从金额上：包括正常金额的支付，最小值的支付，最大值的支付，错误金额的输入（包括超限的金额、格式错误的金额、不允许使用的货币等等）；
从流程上：包括正常完成支付的流程，支付中断后继续支付的流程，支付中断后结束支付的流程，支付中断结束支付后再次支付的流程，单订单支付的流程，多订单合并支付的流程等等；
从使用的设备上：包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
从支付接口上：包括POSE终端机支付、银行卡网银支付、支付宝支付、微信支付、手机支付等；
从产品容错性上：包括支付失败后如何补单或者退单、如何退款等；
从后台的账务处理上：成功订单的账务处理、失败订单的账务处理、退款订单的账务处理、差错账处理等等。
17.抓包工具
抓包工具做什么用？
抓包工具主要是拦截查看网络数据包内容的软件，分析页面的请求方式,内容,以及cookie，还可以用来检测页面的返回状态码设置是否正确，检测网页的跳转。
常用的抓包工具：
fiddler， wireshark等
Fiddler介绍：
Fiddler是一个http协议调试代理工具，它能够记录并检查所有你的电脑和互联网之间的http通讯，设置断点，查看所有的“进出”Fiddler的数据。可以将网络传输发送与接受的数据包进行截获、重发、编辑、转存等操作。也可以用来检测网络安全。
如何抓取手机app端请求包：
Fiddler还可以对手机的请求操作进行抓包，需要将手机和电脑连接在同一个网络环境下，设置代理服务器，使得手机的请求通过fiddler发送到服务器端，这样就可以通过fiddler抓取手机客户端请求的数据包。
18.Jmeter介绍
JMeter 是 一个非常优秀的开源的性能测试工具。性能测试是一个系统必不可少的测试环节，特别是对于web系统，而JMeter 是 一个非常优秀的开源的性能测试工具，我理解的是通过不断的增加用户并发量来进行系统压力测试，通过循环次数来进行系统负载测试。
优点：安装简单，轻量级，免费开源，基于Java编写，多平台…