1、什么是软件测试？其目的是什么？你怎么看待软件测试？
是为了发现错误而执行程序的过程。在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。目的是暴露程序中的错误。发现测试对象与预期的差异。具体地不同测试阶段对应不同测试目的。
软件测试工作者要站在用户的额角度思考问题，从用户的实际使用环境、习惯着手验证被测对象应用表现。与软件开发的创造性思维不同，软测活动的思维模式则是破坏性的通过构建正常、异常输入去考验被测对象的健壮性。测试工作是一项极其重要的质量保证活动。因为测试部门是软件发布质量把控的出口，又可能是用户意见反馈的入口。
2、软件测试的生命周期？各阶段对应的工作？
测试周期是指从测试项目计划建立到BUG提交的整个测试过程，包括软件项目测试计划，测试需求分析，测试用例设计，测试用例执行，BUG提交五个阶段。软件测试周期与软件生命周期并行，存在于软件生命周期的各个阶段。
需求分析阶段：测试人员了解需求、对需求进行分解、分析，得出测试需求。
测试设计、测试开发阶段：测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例。输出测试方案文档。
测试执行阶段：测试执行阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试。
测试评估阶段（BUG提交）：在执行的过程中记录、管理缺陷，测试完成后编写测试报告，进行测试评估。
3、测试计划和测试方案的内容和区别？
测试方案确定测试的方法、类型；确定用例设计的方法，缺陷管理流程；缺陷严重程度的划分、用例格式等。
测试计划一般由测试经理、测试主管或项目测试负责人制定，属于管理文档，解决的是做什么的问题。测试方案由测试工程师设计，属于技术文档，解决的是怎么做的问题。
4、需求评审的内容？参与人员？测试人员为什么要参与需求评审？
内容：同步产品对于需求的详细设计,收集大家对于需求的各种反馈。
参与人员：产品、设计、研发、运营，测试等其他岗位的人
当面同步需求，对于需求的合理性、全面性的反馈。
5、测试用例的设计方法有哪几种，分别对应什么典型业务功能？
等价类划分
边界值分析
判定表驱动分析
判定表通常由四个部分组成。
1)条件桩（ConditionStub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
2)动作桩（ActionStub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
3)条件项（ConditionEntry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
4)动作项（ActionEntry）：列出在条件项的各种取值情况下应该采取的动作。
因果图法
采用因果图法设计测试用例的步骤：
1)分析软件规格说明描述中,那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件),并给每个原因和结果赋予一个标识符。
2)分析软件规格说明描述中的语义，找出原因与结果之间,原因与原因之间对应的关系，根据这些关系,画出因果图。
3)由于语法或环境限制,有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况,在因果图上用一些记号表明约束或限制条件。
4)把因果图转换为判定表。
5)把判定表的每一列拿出来作为依据,设计测试用例。
场景设计
错误推测法
6、缺陷的级别及管理流程？
致命（Uregent）：主流程无法跑通，系统无法运行，崩溃或业务中断，应用模块无法启动或异常退出，主要功能模块无法使用。如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循环报错，无法正常退出。
严重（veryhigh）：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。如：1.功能未实现；2.功能存在报错；3.数值轻微的计算错误
一般（Medium）：界面、性能缺陷。如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条
提示（Low）：易用性及建议性问题。如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。
1、测试人员填写bug并（Assign）给测试负责人，状态为New；
2、测试负责人（review）缺陷。主要检查报告规范，以及确认bug。若是有效的bug，状态变化为open，并分配给开发人员；若bug无效则指派（Assign）回给测试人员，bug状态依旧为new
3、开发人员根据缺陷描述确认是否时缺陷，若是则进行修复，修改完成并进行单元测试后，将bug的状态变为fixed，在comment中说明修改方法，并指派给缺陷发现人。若不是缺陷或者延期修改的，将bug状态变化为Rejected，同时也在comment中注明原因。
4、测试人员每天查看自己提交的bug的状态变化，应该成为每个测试人员的例行行为；
5、当bug的状态变为fixed时，测试人员打开该bug，开始对该bug进行回归测试；如果该bug回归测试通过，则状态变为closed。否则bug的状态变为reopen（必须说明reopen、closed状态变化原因或者操作过程）；
6、若对（Reject）的缺陷进行再次确认后测试人员认为是缺陷，则需（Reopen）缺陷至开发人员出，并comment原因。
8、只有当所有的bug状态为closed，才可发布版本。
注：每当bug状态改变后，必须给出相应的注释和说明，以便查看bug生命周期的变化情况。
7、测试准入和通过的标准？
8、测试模型有哪些？
缺点有：测试介入较晚，滞后于研发，如果发现前期问题，修复成本非常高；不利于需求的变更；用户只能在项目交付时才能拿看到成品
缺点：需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。
解决滞后于开发的问题
缺点：管理型要求高、要求能够很好的定义每个迭代的规模、测试就绪点分析困难
9、如何保证测试覆盖率？测试用例评审方式，如何组织，为什么要评审，评审内容？
10、敏捷模型？瀑布模型？
详见题8
11、测试报告的内容有哪些？
12、测试过程中如果发现不可重现的缺陷怎么处理？
不可重现的原因主要有：测试环境不一致，测试配置不一致、内存泄露、数据接口不一致等
解决：1.测试环境配置充分细致：严格核对要求，充分考虑环境变化。另外可以使用Ghost对硬件或某个分区进行镜像备份。
2.捕获系统日志，分析异常信息：测试人员应养成记录系统错误日志的习惯，保留系统在出错时的真实状态。比如将IE浏览器高级选项设置为“显示每个脚本错误的通知”。
3.监测系统状态，异常及时告警：系统运行监测的一个重要内容是需要及时反馈系统运行异常，并提供异常报告。
4.测试数据翔实，易于追溯：软件测试开始前，必须制定完整的测试用例，辅以详细的测试数据，并明确测试数据的操作步骤和每一步的预期结果，这样，当软件出现问题，方便重现和定位。
13、测试流程是什么？
即测试周期，详见第二题
14、测试方法有哪些？
15、测试类型有哪些？
功能测试：也叫黑盒测试，主要验证软件业务需求实现与否的一项测试活动。其意义是便于用户理解。
主要检查被测对象是否存在以下3种错误：1、是否有不正确、遗漏或多余的功能。2、是否满足用户需求和系统设计的隐藏需求。3、是都对输入做出正确的响应，输出结构能否正确展示。
其意义是因为现实情况中资源总是有限的。目的是验证系统是否具有宣称的能力
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
界面测试：界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。
另外有兼容性测试、安全测试、可靠性测试、可用性测试、移植测试、维护测试、确认测试、回归测试等
16、α测试和β测试的区别？
两者都属于验收测试，以用户为主、有用户参与
α测试：在开发环境下进行，测试环境受控，开发在场
β测试：在实际使用环境下（生产环境）进行，测试环境不受控、开发不在场
17、什么是敏捷测试？什么是探索性测试？
探索性测试：强调测试过程中要有更多的发散思维，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略。是用户故事测试和自动化回归集的重要补充。由于没有测试脚本，可以使你的测试超出各种明显已经测试过的场景。探索测试将学习，测试设计和测试执行整合在一起，形成一种测试方法。探索性测试的最大特色是在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。其基本过程如（环节间无绝对顺序）：
识别软件系统的目的;
识别软件系统提供的功能;
识别软件系统潜在的不稳定的区域;
在探索软件系统的过程中记录关于软件的消息和问题;
创建一个测试纲要，使用它来执行测试。
18、V模型和W模型的区别？
v模型：测试往往被加在开发过程的后半部分，测试对象只有程序本身，前期面向程序，后期面向用户。适合工程量小、人力投入少的情况
w模型：测试和开发是同时进行的，测试对象除程序外还有需求、设计等。
19、何为上线？之前工作中上线是怎么做的？
上线：软件具备正式运行生产的所有必要条件，并且完成发布工作
流程：上线前准备：1、确定上线策略（上线顺序、修复数据策略、旧数据分析）
2、写上线申请邮件（数据配置、上线注意点）
3、配置线上环境数据
上线：一般上线的权限只有几个人有，所以上线的人员是固定的，上代码时需要先将线上环境的job停掉，我们也是用jenkins进行自动化部署，只是需要人为的打版号、标签，部署版本，停Djob任务，上线完全之后，启动Djob任务等。
上线后：1、灰度测试
2、监控线上数据
20、测试用例的内容、优先级定义、以及如何编写？
内容：
+用例编号（用例id）+一般使用系统-测试级别-模块-001---例子：CRM-ST-客户管理-新增客户-001+测试标题（用例标题）----验证XXXX通过/不通过---肯定的语气+测试项（所属模块）+用例属性（测试类型）--一般为功能测试+重要级别（优先级）----1-4级或者极高-高-中-低
优先级定义：
+极高----冒烟（主业务流程）+高----流程类，稍重要的流程+中----一般流程，界面中比较常用的可能+低----界面中异常情况，或者很少出现的
如何编写：
1、划分功能模块
2、正向功能验证：正常操作功能是否实现
3、单个功能项验证：正向+异常
4、功能之间交互验证：模块之间的数据传递
5、隐形需求：熟悉业务
+只要是涉及到输入框的首先考虑输入为空的情况+一条用例只测试一个功能点+测试正常和异常的遵循二八原则+操作步骤和预期结果一一对应+如果条件有多个，在实际测试某一个的时候，默认其他条件都满足+在对一个模块编写用例时，首先先对模块整体的业务走一条冒烟+对一个界面编写用例时，可以先给页面一个界面的用例----针对有界面原型的+优先级为高的在这个模块一般只占5%左右
21、如何测试一个水杯？
22、拆分需求注意事项？
需求是一个整体，整体拆成模块，模块拆成小需求，小需求拆成功能点，需求点。测试时，分成整体测试，功能点测试，需求点测试。对于每个需求点根据等价类、边界值划分等去分析。一个需求就分成了一个树结构。一层一层的对应。
总体来说主要注意事项如下：
23、项目组成员包括哪些？
项目经理{开发经理{UI，开发工程师，系统架构师}，测试经理{测试设计、测试工程师}}
24、回归测试回归几轮？
回归测试是对已被测试过的程序在修复缺陷后进行的重复测试，目的是验证修复缺陷有没有引发新的缺陷或问题。简单来说就是看有没有引入新bug。回归策略有选择性回归（一般指针对bug进行回归，在开始几轮时候，bug比较多，包括基于风险、基于操作、基于缺陷）和完全回归（一般在最后一轮回归的时候，执行所有用例）。
-一般回归3轮（如果3轮还未回归还未修复完bug，再继续回归）
25、什么情况下使用自动化测试？
比如：基础性代码、接口，比较独立的API、没有业务依赖，适合自动；
有角度依赖、较复杂的业务逻辑，场景多、类型不一致、因子数多、重度需要人交互，适合手动；
6.版本稳定后才进行自动化
26、scrum模型中的一些特殊术语？
scrum模型中主要有产品负责人（ProductOwner）、ScrumMaster、团队（Team）。
它由Productbacklog开始，经过sprint会议从Prdouctbacklog挑选出一些优先级最高的故事（story）形成迭代的sprintbacklog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。
ProductBacklog：在项目开始的时候，ProductOwner要准备一个根据商业价值排好序的客户需求列表。这个列表就是ProdctBacklog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。Scrumteam会根据这个来做工作量的估计。Productbacklog应该涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。对于那些以后将要实现的特性可以不够详细。
SprintBacklog：SprintBacklog是Sprint规划会上产出的一个工作成果.当Scrumteam选择并承诺了Productbacklog中要递交的一些高优先级的产品功能点后，这些功能点就会被细化成为SprintBacklog:一个完成ProductBacklog功能点的必需的任务列表.这些点会被细化为更小的任务，工作量小于2天。Sprintbacklog完成后，Scrumteam会根据它重新估计工作量，如果这些工作量和原始估计的工作量有较大差异，Scrumteam和ProductOwner协商，调整合理得工作量到Sprint中，以确保Sprint的成功实施。
SprintPlanningMeeting（Sprint规划会）、DailyScrumMeeting（每日站会）、SprintReviewMeeting（Sprint评审会）
27、把你熟悉的一个游戏简单分析如何进行测试？
28、如何搭建测试环境？
29、app和web的测试环境有什么区别？
web项目，b/s架构，基于浏览器的；web测试只要更新了服务器端，客户端就会同步会更新
app项目，c/s结构的，必须要有客户端；app修改了服务端，则客户端用户所有核心版本都需要进行回归测试一遍
30、系统项目的构成？
前端、UI界面、客户端、后端、系统服务端代码、WEB服务器（Apache）、应用服务器（Tomcat轻量级的应用服务器）、数据库服务器
31、如何构造测试数据？构造测试数据的方式有哪些（接口测试内容）？
1、通过charles工具拦截请求之后，修改响应数据，构造许多数据，模拟mock查看列表及翻页展示
2、如果有数据库权限，可以与开发同学协调，让开发同学帮忙编写sql语句进行数据添加(当然如果有数据关联，需要查看下关联的表结构及关系)。
3、通过UI自动化脚本，录制或循环运行，进行数据添加。
当然Mock方式还是最简单和有效验证的方式。
比如：有些字段返回错误，返回异常的字段类型，空的校验等等，客户端是否有崩溃，异常产生。
接口端的测试只能保证数据格式和字段是否正确，那么Mock+Selenium/Appium则可以配合进行，验证我们客户端的展示是否正确。
一般创建测试数据的方法分为手动创建和采用程序的自动化创建两种方法
32、如何确认测试数据的正确性？
33、你们测试是否与开发共用一个环境？如果是，如何保证测试结果不受影响？
34、什么是接口测试？为什么要做接口测试？怎么做接口测试？
35、接口是否通过测试怎么判断你？
36、接口测试用例怎么设计？
37、接口自动化是什么？
38、发现缺陷后怎么定位？
ps：夹板思路：先夹大黑盒,再夹小黑盒,逐渐缩小问题发生范围,也就是三层前端服务数据来夹.就是大夹板是最大的黑盒也就是只管前端和数据库落地的输入和输出,如果这个大夹板没问题,输入也对,落地数据也对,那就基本说明,整个处理链路是通的.
39、提交的bug研发不认怎么办？
在确保缺陷提交流程是已经得到开发认可的前提下，先从自身入手：
然后与开发确认：
如果还是没有解决的话找权威裁决：
40、怎么提交一个高质量的缺陷记录？（缺陷报告有哪些内容？）
在编写缺陷记录前检查问题是否可重现（如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bugreport之前反复尝试3次）。
尝试编写bugreport之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
若问题是已隔离，可重现的，则应对其进行归纳。（同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？）
检查该问题是否是回归错误。
在缺陷报告的第一行写上错误的总结。（已发现的错误对客户有何影响）
缺陷报告初稿完成后进行精简、消除歧义、（集中剔除那些没有关系的步骤或词语，隐含的或模糊的说明、对没有任何关系的细节的描述或者那些在重现错误过程中不需要的步骤。同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。）
缺陷报告的内容有：+测试的结果
+针对本次测试的一个总结---所用的人力，物力，项目介绍+本次用例情况+缺陷的情况+本次测试的遗留问题
41、各类工具的工作原理是什么？工具都可以用来干什么为什么要用？
42、禅道如何提交缺陷的？缺陷都有哪些状态？除了管理缺陷以外还能做些什么？