真题解析
面试宝典
一、功能测试
1、开篇
1.1、 自我介绍
面试官您好， 我叫某某
来自于 河南(省份就可以了)
毕业于 某某大学
目前从事软件测试行业有 X年 左右了
最近是做 某某 项目
在其中 主要负责XX功能 等等测试
1.2、 项目介绍
先要熟悉 项目背景
业务流程
人员结构 （开发有多少、测试有多少、是做的产品 还是项目） 一般 开发：测试 = 3:1
你在其中主要负责那一块 对谁进行一个汇报
迭代周期
项目介绍尽量遵循STAR法则进行描述（背景-任务-行动-结果）
参考链接：STAR
1.3、你的优点是什么， 你的缺点是什么？
说一些无关痛痒的缺点，可选择带有两面性的缺点为佳。
两面性是指：用在好的方面，它就是优点，用在坏的方面，它就是缺点。明白了吗？其实不是在说缺点，还是在隐晦的展示自己的优点。
传统意义上的缺点包含：不负责任、不关心同学、懒惰、不好学、睡懒觉、不团队、不积极、没激情、孤僻、冷漠、偏激、好玩、没进取心等等。
这些典型的缺点在面试中是不可取的，可以说是见光死。请务必记住！
举例：我有的时候遇到问题，会喜欢执着/较真——其实就是说自己的优点：我有刻苦专研的精神。（对待bug的态度也是一样，需要认真仔细，不能开发说啥就是啥，要找项目经理或产品确认清楚）
1.4、你上家工资多少，你的的离职原因？
-
上家公司的工资是多少
- 目标预期的工资降低20~30%左右为上一份工作的工资水平
-
离职原因
-
对于在职跳槽的人，尽量就这一句话“追求更好的事业发展”，官话为主；
对方如果问你“王先生，请问你离职的原因是什么呢？”你直接回答“追求更好的职业发展”，-- （因为尝试不同的业务形式可以开阔自己的眼界也可以提升自己知识的广度，有利于提升自己职业技能的提升；）
-
原则：不说前雇主坏话
-
1.5、你现在住在哪里？
如实说；如果应聘公司确实有点远，可以考虑后期搬家或者租房。看个人情况
1.6、我看你不是这个专业的，当初怎么进入的这个行业啊？
身边同学或朋友接触到的（举个例子），描述一下软件测试行业和自身的匹配度，尽量表现的很适合该岗位的工作
1.7、你的汇报对象是谁啊？
汇报对象：测试组长（选择直属上级汇报）--（如果是独立负责项目需要抄送项目相关开发和产品经理等）
汇报的形式：日报，周报 （邮件发送）
汇报的内容：测试项目的进度和风险等
1.8、你们有多少测试，多少开发？
一般开发测试比 3：1左右。即：一个测试对3个开发
2、概念基础问题
2.1、 你的测试职业发展是什么？
测试经验越多，测试能力越高。所以我的职业发展是需要时间积累的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前2年积累测试项目经验，按如何做好测试工程师的要点去要求自己，不断更新自己改正自己，做好测试任务。然后学习自动化测试，编程语言，测试开发技术，能够为测试圈带来一些贡献
2.2、你认为测试人员需要具备哪些素质？
做测试应该要有一定的协调能力，因为测试人员经常要与开发接触处理一些问题，如果处理不好的话会引起一些冲突，这样的话工作上就会不好做。还有测试人员要有一定的耐心，有的时候做测试很枯燥乏味。
持有一颗怀疑的心，不能轻易相信开发自测过
耐心加技术是测试人员在企业中生存之道
掌握基本的测试基础理论
本着找出软件存在的问题的态度进行测试，不要以挑刺的形象出现
可熟练阅读需求规格说明书等文档
以用户的观点看问题
有强烈的质量意识
细心和责任心
良好的有效的沟通方式(与开发人员及客户)
具有以往的测试经验能够及时准确的判断出高危险区在何处
2.3、软件测试的目的是什么？
提高软件的质量 软件测试的首要目的就是提高软件的质量,也就是让用户对产品有更好的体验,保证软件的高质量。
软件测试的目的并不是证明软件没有错误，
而是找出软件产品中尽可能多的漏洞，使软件尽可能的符合用户的要求。
测试是不可穷尽的，测试人员不可能发现系统中所有的缺陷。
一个成功的测试是发现了至今未发现的错误的测试。
2.4、测试分为哪几个阶段？
一般来说分为4个阶段：单元测试、集成测试、系统测试、验收测试 然后就上线
2.5、你认为如何做好测试，做好软件测试的一些关键点
具备较强的需求分析能力，测试人员必须非常熟悉系统功能和业务
测试要有计划，而且测试方案要和整个项目计划协调好
必须实现编写测试用例，测试执行阶段必须根据测试用例进行
易用性，功能，分支，边界，性能等功能性和非功能性需求都要进行测试
对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据
定位bug要尽量准确，提高与开发人员协调的效率，尽早的解决bug
充实自己的技能：不仅熟练掌握软件测试基础知识和理论，还要学习编程语言、数据库、linux脚本，自动化测试、性能测试技术。
2.6、谈谈你之前测试的项目流程，在每个阶段的输出有哪些？
a 新功能：首先会召开需求分析会议，参加人员有产品、开发和测试，主要是探讨需求主要的一些功能点；(开发输出：数据库表设计；接口设计，需求文档,提测时间)
b.然后开发就排期进行开发，主管开始编写测试计划，对我们进行任务分配。(输出：测试计划)
c.我们参考需求规格说明书及原型图编写测试用例，写完之后会进行用例评审，有评审修改的就修改整理形成最终的用例版本；（输出：测试用例）
d.提测（测试去Jenkins部署构建）：开发人员版本编译完成后，我们会先对需求进行冒烟测试（主流程），主要对主功能业务进行主流程测试
如果主业务流程不通过，直接返回给开发进行修改。冒烟测试通过，依据测试用例进行系统测试。测试过程中，提交bug，跟踪bug，进行回归测试直至不存在严重bug，满足用户需求，（输出：测试报告）
e.产品发布上线后，关注web是否正常运行，要进行常规的维护性测试。回归测试
（输出：上线回归记录，上线的新功能）
2.8、为什要在一个团队中开展测试工作？
因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量认证，这个时候就需要在团队中开展软件测试的工作。在测试的过程中发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。
2.9、你所熟悉的软件测试类型有哪些?
测试类型有：功能测试、性能测试、界面测试
功能测试在测试工作中占有比例最大，功能测试也叫黑盒测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行
界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象
区别在于，功能测试关注产品的所有功能，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注产品整体的多用户并发下的稳定性和健壮性。界面测试则关注与用户体验相关内容，用户使用该产品的时候是否已用，是否易懂，是否规范(用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告)。做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没有问题的，然后再考虑性能的问题。
2.10、黑盒测试，编写测试用例方法有哪些？
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
常用的黑盒测试方法有：等价类划分法；边界值分析法；因果图法；场景法；正交实验设计法；判定表驱动分析法；错误推测法；功能图分析法。
2.11、请说一下白盒测试是什么，编写测试用例方法有哪些？
白盒测试也称为结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试法检查程序内部逻辑结构，对所有的逻辑路径进行测试，是一种穷举路径的测试方法，但即使每条路径都测试过了，但仍然有可能存在错误。因为：穷举路径测试无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序；穷举路径测试不可能检查出程序因为遗漏路径而出错；穷举路径测试发现不了一些与数据相关的错误。
白盒测试需要遵循的原则有：1. 保证一个模块中的所有独立路径至少被测试一次；2. 所有逻辑值均需要测试真（true）和假（false）；两种情况；3. 检查程序的内部数据结构，保证其结构的有效性；4. 在上下边界及可操作范围内运行所有循环。
常用白盒测试方法：
静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进行。
动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。
2.12、Beta测试与alpha测试的区别？
alpha测试是公司内部在模拟实际操作环境下进行的一种验收，公司内部会组织内部员工进行的测试，alpha测试不能由程序员或者测试完成。
Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试，beta测试不能由程序员或测试员完成。
2.13、UAT测试 与 SIT测试区别
SIT(SystemIntegrationTesting)系统集成测试，也叫做集成测试，是软件测试的一个术语，在其中单独的软件模块被合并和作为一个组测试。它在单元测试以后和在系统测试之前。集成测试在已经被单元测试检验后进行作为它的输入模式，组织它们在更大的集合，和递送，作为它的输出，集成系统为系统测试做准备。集成测试的目的是校验功能、性能和可靠性要求，配置在主设计项目中。
UAT(UserAcceptanceTesting)用户验收测试，通常是由最终软件的用户（通常这些用户不了解软件的具体逻辑，而对业务逻辑却相当熟悉）进行的测试，因此是面向最终用户的测试，结束之后通常就可以发布生产环境了。
SIT是集成测试UAT是验收测试从时间上看，UAT要在SIT后面，UAT测试要在系统测试完成后才开始。从测试人员看，SIT由公司的测试员来测试，而UAT一般是由用户来测试。
2.13、你们的验收标准是什么，你怎么样判断可以通过上线了
验收标准：
以产品经理的需求文档为依据（需求评审通过后，任何需求上的变更都需要产品经理同步到需求文档上），充分设计测试用例（功能、非功能的测试用例），并通过产品，开发，测试三方的测试用例评审会议
如何判断是否可以通过上线：
-
“功能覆盖率达到100％”--已评审通过的测试用例100%执行完成
-
“不存在致命、严重等级的缺陷”的bug处在未修复状态。所有严重影响用户使用的bug，都需要开发修复，测试验证完成并关闭问题单状态
-
一般类型的bug一般不超过3个，建议类型的bug不超过5个。核心原则--需要同产品经理和项目经理沟通确认，确认遗留问题不影响用户使用，并同意允许遗留问题上线（因为我们测试无法准确评估遗留问题对于生产的准确影响）
-
产品经理在UAT(预发布)环境对需求已经验收通过
2.14、作为测试工程师对需求分析的理解？（用户场景）
a.了解需求背景及商业价值
明确了解背景，为什么要做这个需求，明白需求存在什么样的商业价值后，才更明确该站在用户哪个角度去判断考虑该需求
b.站在用户角度去分析需求
产品提出的功能，站在真实的用户角度判断该需求使用对用户来说使用起来是否顺畅，操作路径是否多且复杂存在冗余，有什么风险
显性需求：产品明确提出的需求
隐性需求：明确需求背后可能存在的需求（异常场景）
功能性需求：显性及隐形需求里面相关业务
非功能性需求：用户体验，性能，可靠性，安全性，可维护性，可继承性
c.站在产品的实现角度去分析该需求
该需求对继承性需求在逻辑上是否存在冲突，原有逻辑是否存在冲突，遗漏
d.站在项目的角度去分析该需求
需求拆解的是否足够细，是否可再拆解，是否可测试，优先级如何，有什么风险
2.15、你在浏览器打开一个web项目网址，中间发生了什么？
参考回答：
网络请求，域名解析、请求后端接口，获取接口响应值，根据数据展示，关闭请求
1、DNS解析
2、TCP连接
3、发送HTTP请求
4、服务器处理请求并返回HTTP报文（apach，tomcat。nginx）
5、浏览器解析渲染页面
6、连接结束
2.16、V模型和W模型
参考回答：
测试和开发应该按照W模型的方式进行结合，测试和开发同步进行，能够尽早发现软件缺陷，降低软件开发的成本。
在V模型中，测试过程被加在开发过程的后半部分，单元测试所检测代码的开发是否符合详细设计的要求。集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。而验收测试则检测产品是否符合最终用户的需求。V模型的缺陷在于仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证，因此需求阶段的缺陷很可能一直到后期的验收测试才被发现，此时进行弥补将耗费大量人力物力资源。
相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。
W模型中测试的活动与软件开发同步进行，测试的对象不仅仅是程序，还包括需求和设计，因此能够尽早发现软件缺陷，降低软件开发的成本。
2.17、请回答集成测试和系统测试的区别，以及它们的应用场景主要是什么？
参考回答
区别：
1、计划和用例编制的先后顺序：从V模型来讲，在需求阶段就要制定系统测试计划和用例，HLD的时候做集成测试计划和用例，有些公司的具体实践不一样，但是顺序肯定是先做系统测试计划用例，再做集成。
2、用例的粒度：系统测试用例相对很接近用户接受测试用例，集成测试用例比系统测试用例更详细，而且对于接口部分要重点写，毕竟要集成各个模块或者子系统。
3、执行测试的顺序：先执行集成测试，待集成测试出的问题修复之后，再做系统测试。
应用场景：
集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；可以是整个产品的集成测试，也可以是大模块的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。
系统测试：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏，是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使用黑盒测试法。
2.18、请你说一说web测试和app测试的不同点？
系统架构方面：
web项目，一般都是b/s架构，基于浏览器的
app项目，则是c/s的，必须要有客户端，用户需要安装客户端。
web测试只要更新了服务器端，客户端就会同步会更新。App项目则需要客户端和服务器都更新。
性能方面:
web页面主要会关注响应时间
而app则还需要关心流量、电量、CPU、GPU、Memory这些。
它们服务端的性能没区别，都是一台服务器。
兼容方面：
web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容
app测试则要看分辨率，屏幕尺寸，还要看设备系统。
web测试是基于浏览器的所以不必考虑安装卸载。
而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件 。
此外APP还有一些专项测试：如网络、适配性。
2.19、请你说一说简单用户界面登陆过程都需要做哪些分析？
参考回答：
一、功能测试
1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。
2.输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。
3.登录成功后能否能否跳转到正确的页面
4.用户名和密码，如果太短或者太长，应该怎么处理
5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况
6.记住用户名的功能
7.登陆失败后，不能记录密码的功能
8.用户名和密码前后有空格的处理
9.密码是否非明文显示显示，使用星号圆点等符号代替。
10.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使 用者），刷新或换一个按钮是否好用
11.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确
12.输入密码的时候，大写键盘开启的时候要有提示信息。
13.什么都不输入，点击提交按钮，检查提示信息。
二、界面测试
1.布局是否合理，testbox和按钮是否整齐。
2.testbox和按钮的长度，高度是否复合要求。
- 界面的设计风格是否与UI的设计风格统一。
- 界面中的文字简洁易懂，没有错别字。
三、性能测试
1.打开登录页面，需要的时间是否在需求要求的时间内。
2.输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。
3.模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。
四、安全性测试
1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)。
2.用户名和密码是否通过加密的方式，发送给Web服务器。
3.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript 验证。
4.用户名和密码的输入框，应该屏蔽SQL注入攻击。
5.用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）。
6.防止暴力破解，检测是否有错误登陆的次数限制。
- 是否支持多用户在同一机器上登录。
- 同一用户能否在多台机器上登录。
五、可用性测试
1.是否可以全用键盘操作，是否有快捷键。
2.输入用户名，密码后按回车，是否可以登陆。
3.输入框能否可以以Tab键切换。
六、兼容性测试
1.不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
2.同种浏览器不同版本下能否显示正常且功能正常。
2.不同的平台是否能正常工作，比如Windows, Mac。
3.移动设备上是否正常工作，比如Iphone, Andriod。
4.不同的分辨率下显示是否正常。
七、本地化测试
1.不同语言环境下，页面的显示是否正确。
2.20、如果做一个杯子的检测，你如何测试？
参考回答：
1.功能
（1）水倒水杯容量的一半
（2）水倒规定的安全线
（4）水杯容量刻度与其他水杯一致
（5）盖子拧紧水倒不出来
（6）烫手验证
2.性能
（1）使用最大次数或时间
（2）掉地上不易损坏
（3）盖子拧到什么程度水倒不出来
（4）保温时间长
（5）杯子的耐热性
（6）杯子的耐寒性
（7）长时间放置水不会漏
（8）杯子上放置重物达到什么程度杯子会被损坏
3.界面
（1）外观完整、美观
（2）大小与设计一样（高、宽、容量、直径）
（3）拿着舒服
（4）材质与设计一样
（5）杯子上的图案掉落
（6）图案遇水溶解
4.安全
（1）杯子使用的材质毒或细菌的验证
（2）高温材质释放毒性
（3）低温材质释放毒性
5.易用性
（1）倒水方便
（2）喝水方便
（3）携带方便
（4）使用简单，容易操作
（5）防滑措施
6.兼容性
（1）杯子能够容纳果汁、白水、酒精、汽油等。
7.震动测试
（1）杯子加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。
8.可移植性
（1）杯子在不同地方、温度环境下都可以正常使用。
2.21、请你来说一下购物车的测试用例？
参考回答：
界面测试
• 界面布局、排版是否合理；文字是否显示清晰；不同卖家的商品是否区分明显。
2.功能测试
未登录时：
• 将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加；
• 点击购物车菜单，页面跳转到登录页面。
登录后：
• 所有链接是否跳转正确；
• 商品是否可以成功加入购物车；
• 购物车商品总数是否有限制；
• 商品总数是否正确；
• 全选功能是否好用；
• 删除功能是否好用；
• 填写委托单功能是否好用；
• 委托单中填写的价格是否正确显示；
• 价格总计是否正确；
• 商品文字太长时是否显示完整；
• 店铺名字太长时是否显示完整；
• 创新券商品是否打标；
• 购物车中下架的商品是否有特殊标识；
• 新加入购物车商品排序（添加购物车中存在店铺的商品和购物车中不存在店铺的商品）；
• 是否支持TAB、ENTER等快捷键；
• 商品删除后商品总数是否减少；
• 购物车结算功能是否好用。
3.兼容性测试
• 不同浏览器测试。
4.易用性测试
删除功能是否有提示；是否有回到顶部的功能；商品过多时结算按钮是否可以浮动显示。
5.性能测试
压力测试；并发测试。
2.22、请你进行一下弱网模拟？
参考回答：
方法一：charles弱网模拟
使用chrome的webview调试工具，缺点是只适用于web页面的弱网模拟。
iOS手机自带Network Link Conditioner 弱网模拟
iPhone手机打开开发者选项，具体参考：
设置-开发者选项 > Network Link Conditioner 入口。
系统已经内置常见网络配置，也可以增加自定义配置。
具体配置参数：
in Bandwidth 下行带宽，即下行网络速度
In packet loss 下行丢包率
in delay 下行延迟，单位ms
out bandwidth 上行带宽
out packet loss 上行丢包率
out delay 上行延迟
DNS delay DNS解析延迟
protocol 支持Any，IPV4、IPV6
interface 支持Any，WI-Fi，cellular（蜂窝网）
方法二：Fiddler模拟弱网
-
开启模拟弱网开关 Rules->Performance->Simulate Modem Speeds
-
进入用户自定义规则 Rules ->Costomize Rules 弹框中编辑网络的上行速度和下行速度
// 若网测试参数设置 if (m_SimulateModem) { //m_SimulateModem 弱网开关状态 // Delay sends by 300ms per KB uploaded. oSession["request-trickle-delay"] = "300"; // Delay receives by 150ms per KB downloaded. oSession["response-trickle-delay"] = "150"; }
2.23、测试工作一般从什么阶段开始？
参考回答：我之前工作的单位，在做测试工作的时候，我们一般在拿到需求文档的时候就开始了。
2.24、需求评审的目的是什么？
参考回答: 我觉得需求评审的目的主要是消除歧义，完善细节，最后达成共识，如果不进行评审，就意味着开发人员和测试人员可能会对需求文档的理解存在偏差，最终可能导致产品的质量不符合需求文档要求。
2.25、你们是如何评审需求文档的？
参考回答： 我们公司之前评审需求的时候， 主要是从6个方面进行的...
● 正确性: 对照原始的需求，检查产品人员制定的文档是否偏离了最原始的用户需求。
● 明确性：检查需求文档中是否包含一些含糊其辞的词汇，比如 过多 ， 过少 ， 适量 , 是否 。检查用语是否清晰，无歧义。
● 完整性：对照原始的需求文档，检查产品人员制定的需求文档是否完全覆盖用户所有的需求点。
● 限制性：每个需求中是否清晰描述了这个软件能做什么，不能做什么，什么能输入，什么不能输入。
● 优先级：需求文档中哪些文档比较重要，哪些不重要，要有优先级。
● 一致性： 检查需求文档中的内容是否前后一致，确保不冲突，不矛盾。
基本上，我们会从这6方面来进行评审，当然每个公司的评审机制可能会有一些差异，但是主要目的就是把需求文档的细节理解清楚，达成共识，谢谢。
二、接口测试
2.1、你们接口测试 怎么做的？
- 由开发提供接口文档或抓包确认
- 明确接口所需要实现的业务功能
- 对接口请求入参和返回入参的字段含义进行确认
- 确认接口所使用的相关数据库表（查询或修改）
- 确认接口调用方是否对接口是否有性能上的要求（可选）
- 基于对接口的业务的理解，运用测试用例设计方法进行测试用例的设计
- 评审测试用例
- 执行用例-提交bug-修复bug-验证bug-关闭bug
2.2、接口请求方式有哪些？
主要有：
-
GET
-
POST
-
UPDATE
-
DELETE
工作中最常用的是GET和POST请求
2.3、post请求和get请求有什么区别？
-
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
-
GET请求在URL中传送的参数是有长度限制的，而POST么有。
-
GET比POST更不安全，因为参数直接暴露在URL上，所以一般不会用来传递敏感信息。
-
GET参数通过URL传递，POST放在Request body中。
-
GET请求，天然幂等，POST请求幂等需要后端开发特殊处理
-
GET与POST都有自己的语义，最好不要随便混用（一般情况下GET请求：用户从服务器获取数据，POST请求：向服务器提交修改或创建数据）
2.4、测试接口你主要关注哪些点？OR 接口测试用例有写过 你怎么写的？
参考答案：一般写接口测试用例我都会考虑以下几点：
-
每个入参字段的异常传参（类型/长度/null 等）
-
异常入参，接口返回提示信息的合理性
-
不同参数之间的组合传参，结果返回检查
-
正常传参，接口数据返回结果的正确性
-
POST请求的接口幂等性
-
写接口的数据落库数据检查
-
接口的非功能性要求（性能、安全）
2.5、http和https 什么区别？
HTTP协议传输的数据不安全 - HTTP协议传输的数据都是未加密的，也就是明文的。
HTTPS：HTTPS协议是由SSL安全套接层+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTP和HTTPS使用的默认端口不一样。HTTP是80端口，HTTPS是443端口。
2.7、如何从上一个接口获取相关的响应数据传递到下一个接口？
使用Jmeter工具：
- 在上一个请求的上面，设置后置处理器
- 提取接口返回的字段值到变量中（JsonPath或正则表达式）
- 后面的接口引用该变量。即可实现接口间数据依赖的问题
2.8、常见的状态码有哪些？
1xx Informational（信息性状态码） 接受的请求正在处理
2xx Success（成功状态码） 请求正常处理完毕
3xx Redirection（重定向） 需要进行附加操作以完成请求
4xx Client error（客户端错误） 客户端请求出错，服务器无法处理请求
5xx Server Error（服务器错误） 服务器处理请求出错
200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
301 （重定向） 请求的网页已永久移动到新位置。
404 （未找到资源） 服务器找不到请求的接口或网页
405 （方法禁用） 请求方法不被允许（比如：服务器只允许post访问，客户端用了GET访问）
500 服务器内部错误
502 网关错误
504 网关超时
三、缺陷bug
3.1、一个缺陷包括哪些内容？
bug的标题
bug具体描述内容 ：如执行那条用例 ，bug的截图 复现步骤
bug严重程度
bug优先级
bug指派给那个人
bug的状态，激活 or 关闭 or 待验证 等等
3.2、你印象最深的一个缺陷是什么？
3.3、你们缺陷管理平台用的什么？
参考回答
禅道、jira、
大一点公司一般会自研，如平安自己 开发 神兵
3.4、你知道bug的声明周期吗？
参考回答：
Bug的生命周期，就是一个bug被发现到这个bug被关闭的过程，生命周期中一般缺陷状态：新建、指派、已解决、待验、关闭
如果待验证的bug在验证是没有解决好，我们需要重新打开（激活）→指派→已解决→待验，循环这个过程，中间其他状态：重新打开、拒绝、延期等
1.19、说一说bug的类型？
参考回答：
Bug类型
代码错误 界面优化 设计缺陷 配置相关 安装部署 安全相关 性能问题 标准规范 测试脚本 其他
1.20、当你提了一个bug，开发认为这不是bug，怎么处理？
参考回答：
首先，确认在测试环境能否重现，如果确认是缺陷跟开发保持有效沟通，如果是级别较低的建议性bug，可以先记录到bug平台，先保留沟通。如果是bug级别较高的问题，对应需求文档的预期结果跟开发说明，更有说服力；耐心讲解BUG的危害，不行就找产品确认，确实是BUG注明情况并再次指派给开发
1.21、有没有你印象深刻的bug，bug的原因？
参考回答：
身份证末尾X结尾的， 实名认证显示成功，但是在后面提现的时候，会报错，后面发现是保存到库里面的，都是小写X的，导致提现这边不识别，印象深刻的原因是因为花了一定的时间去找到这个bug，并且自己尝试定位到原因，所以印象深刻。
1.17、对于重现率不高的BUG怎么处理？
参考回答：
先在出现问题的环境上尽量重现，保持浏览器环境、出现问题的特定账号等的一致，多次尝试仍然不能重现，也要记录到bug平台，将出现问题的特征步骤尽量描述清楚，附带问题截图及日志截图、注明偶现；如果项目时间允许，bug等级高，需要开发协助重现；如果时间不允许，记录到BUG平台后续在跟进。
同时建议开发在关键地方添加日志，下次出现可以通过日志方便定位问题
1.24、如何分析一个bug是前端还是后端的问题？
参考回答：
检查接口，前端和后台之间是通过接口文件相互联系的，需要查看接口文件
检查请求的数据是什么，反馈的数据又是什么
页面可以直接F12，或者抓包查看。如果发送的数据是正确的，但是后台反馈的数据是不符合需求的，那就是后台的问题；如果前端没有请求接口或请求的时候发送数据与需求不符，那这个时候就是前端的问题了。
四、测试计划 测试用例
4.1、有写过测试计划吗？谁来写测试计划
4.2、测试计划包括哪些内容？
4.3、写过测试计划或者是测试报告么？测试计划包括哪些主要步骤和信息？测试报告包括哪些内容？测试报告交付文档有哪些？
参考回答：写过；
1、测试计划包括：项目信息、参与文档、测试范围、测试策略、测试时间人员安排、测试环境；
2、测试报告包含：项目背景、参考资料、测试范围、测试结果及缺陷分析、测试结论与建议，风险评估；
3、交付文档：主要是测试用例、测试计划、测试报告。
4.4、怎样写测试计划和编写测试用例？
参考回答：
简单点，测试计划里应有详细的测试策略和测试方法，合理详尽的资源安排等，至于测试用例，那是依赖于需求(包括功能与非功能需求)是否细化到功能点，是否可测试等。
1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础
2、如果以前有类似的需求，可以参考类似需求的测试用例，然后还需要看类似需求的bug情况
3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑，通过等价类、边界值、判定表等方法找出大部分用例
4、找到需求相关的一些特性，补充测试用例
5、根据自己的经验分析遗漏的测试场景
6、多总结类似功能点的测试点，才能够写出质量越来越高的测试用例
7、书写格式一定要清晰
