测试面试基础题

1.B/S架构和C/S架构区别
B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题(浏览器的内核不同)
C/S 架构需要考虑系统在不同平台的安装、卸载、升级
2.HTTP协议
超文本传输协议，应用层协议，由请求与响应组成。
常见的请求方式有POST/GET,常见的状态码200ok，301永久移动，302临时移动，404找不到资源，500服务器内部错误。
3.POST与GET区别
get请求常用在获取数据，post常用于发送数据
get请求速度比post稍快
get请求的数据是跟随请求地址一起发送，而post是在请求体中单独发送。
4.Cookie和Session的区别与联系
cookie是存放在浏览器上而session是存放在服务器上的。
cookie不是很安全，涉及到用户隐私方面尽量存放在session中。
当访问量增多时，session会更加占用服务器资源。
5.测试的目的
发现软件的缺陷与漏洞，对软件的质量进行评估，提升软件质量。
6.软件测试原则
所有的软件测试都应追溯到用户需求。
尽早地和不断地进行软件测试
完全测试是不可能的，测试需要终止。
充分注意测试中的群集现象。
程序员应避免检查自己的程序。
尽量避免测试的随意性
7.软件测试分为哪几个阶段？
单元测试、集成测试、系统测试、验收测试。
8.单元测试与集成测试的侧重点
单元测试是对程序最小可测试的模块进行测试
集成测试是把各个模块连接起来时，穿越模块接口的数据是否会丢失。
9.系统测试范围
功能测试、ui测试、性能测试、容错测试、可用性测试、异常问题测试、稳定性测试、系统稳定性测试、兼容性测试、接口测试、安全性测试、登录权限测试。
10.a测试与ß测试的区别
а测试 软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试。
ß测试 软件开发公司组织各方面的的典型客户在日常工作中实际使用，并要求用户报告异常情况、提出改进意见，然后公司再进行完善。
11.验收测试怎么做？
在UAT测试之前，我们会制定测试方案，选择基线用例，即级别高的用例，在UAT测试环境上进行测试，如果测试通过，验收测试就通过了。
12.白盒、黑盒和灰盒测试区别
白盒测试：对程序的内部结构与算法进行的测试
黑盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
灰盒测试：关注系统接口所实现的功能，是否和需求一致。
13.冒烟测试的目的
为正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug。检查程序的基本功能是否正常
14.回归测试怎么做？
首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。
15.全部回归与部分回归的区别？
全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
16.需求分析的目的
第一、把用户需求转化为功能需求：1）对测试范围进度量 2）对处理分支进行度量 3）对需求业务的场景进行度量 4）明确其功能对应的输入、处理和输出 5）把隐式需求转变为明确。
第二、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。（澄清需求，提取测试点）
17.测试计划的目的
1.尽早地明确测试工作内容（范围）、测试工作的方法以及测试工作所需要的各种资源。
2.所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实。
3.测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。（规范软件测试内容、方法和过程）
18.什么时候开始写测试计划
测试计划时在需求整理完成，和开发计划一起制定的一份计划书，它属于项目计划中其中的一个计划。（需求分析之后）
19.由谁来编写测试计划
项目经理（从项目角度考虑）
测试经理（从测试组角度考虑）
测试人员（编写具体测试计划）
一般都是由测试经理或者测试组长来编写
20.测试计划的内容
1、 测试目标：对测试目标进行简要的描述。
2、 测试概要：摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。
3、 测试范围：测试计划所包含的测试软件需测试的范围和优先级，哪些需要重点测试、哪些无需测试或无法测试或推迟测试。
4、 重点事项：列出需要测试的软件的所有的主要功能和测试重点，这部分应该能和测试案例设计相对应和互相检查。
5、 质量目标：制定测试软件的产品质量目标和软件测试目标。
6、 资源需求：进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。
7、 人员组织：需要多少人进行测试，各自的角色和责任，他们是否需要进行相关的学习和培训，什么时候他们需要开始，并将持续多长时间。
8、 测试策略：制定测试整体策略、所使用的测试技术和方法。
9、 发布提交：在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。
10、 测试进度和任务人员安排：将测试的计划合理的分配到不同的测试人员，并注意先后顺序.如果开发的Release不确定，可以给出测试的时间段.对于长期大型的测试计划，可以使用里程碑来表示进度的变化。
11、 测试开始/完成/延迟/继续的标准：制定测试开始和完成的标准；某些时候，测试计划会因某种原因(过多阻塞性的Bug)而导致延迟，问题解决后测试继续。
12、 风险分析：需要考虑测试计划中可能的风险和解决方法。
测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束条件、进度安排，测试组织，以及与测试有关的风险等方面的内容。
21.结束条件(项目上线的条件)
需求的覆盖率、用例的执行率和缺陷的遗留率达到质量目标。
通常来说：需求覆盖率和用例执行率需要达到100%
致命/严重的缺陷需要当天解决，轻微/一般遗留率不得超过30%
22.常见的测试风险
1.需求风险、2.测试用例风险、3.缺陷风险、4.代码质量风险、5.测试环境风险、6.测试技术风险、7.回归测试风险、8.沟通协调风险、9.研发流程风险
23.测试用例的要素
1.用例编号、2.测试模块、3.用例的标题、4.测试级别、5.测试目的和条件、6.测试输入、7.操作步骤、8.预期结果
24.测试用例级别的划分
测试用例优先级的目的：测试用例优先级可以用来方便地基于测试策略来筛选用例。比如某块功能改动小，就只用测高或中高优先级的用例。 比如冒烟测试的时候我们只需要筛选优先级最高的用例执行即可。
根据我们测试用例优先级目的：那么优先级越高的测试用例覆盖的测试点应该是用户最关心的， 比如一个注册功能， 能够注册成功这个用例的优先级就是最高的（但是不是所有的注册成功的case都是优先级最高，只需要挑选一个即可）， 其他各种异常校验都是次要优先级的， 还有一些场景覆盖的测试点很难出现，或者叫就算有问题影响也不大， 可以放到低优先级。（一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定）
25.怎样保证覆盖用户需求？
1.确认需求、2.梳理需求，确认测试范围、3.制定测试计划、4.根据测试计划编写测试用例、5.执行测试步骤
项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。
26.写好测试用例的关键 /写好用例要关注的维度
覆盖用户的需求；
从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
做好用例评审，及时更新测试用例。
27.测试用例的状态
排队（In Queue）、进行中（IP）、阻塞（Block）、跳过（Skip）、通过（Pass）、失败（Fail）、警告（Warn）、关闭（Close）

28.常见的测试用例设计方法
等价类划分、边界值分析、错误推断法、判定法表、正交实验法
29.判定表用在哪些时候/哪些功能
判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判定表
30.什么时候用到场景法
场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。
使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。
场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。
Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。
//使用场景法通常是在冒烟测试中或者 一些流程性比较强的软件/功能(比如安装，卸载等等)
31.测试环境怎么搭建的？
搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。
32.偶然性问题的处理
发现bug之后，我们会先截图，如果确定是偶然性的问题，会将日志和截图一起提单给开发定位；
如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
如果是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！
33.当我们认为某个地方是bug，但开发认为不bug，怎么处理？
1.先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
2.如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。
34.产品在上线后用户发现bug，这时测试人员应做哪些工作？
1、测试人员复现问题后，提交问题单进行跟踪；
2、评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
3、问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
4、总结经验，分析问题发生的原因，避免下次出现同样问题。
35.二八定理
缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。
36.如何跟踪缺陷
当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。
37.缺陷的状态
1、 初始化：缺陷的初始状态；
2、 待分配：缺陷等待分配给相关开发人员处理；
3、 待修正：缺陷等待开发人员修正；
4、 待验证：开发人员已完成修正，等待测试人员验证；
5、 待评审：开发人员拒绝修改缺陷，需要评审委员会评审；
6、 关闭：缺陷已被处理完成。
38.缺陷的等级
轻微缺陷、一般缺陷、严重缺陷、致命缺陷
39.缺陷单应该包含这些要素
缺陷标题、缺陷类型、重现步骤、预期结果、实际结果、缺陷优先级、附件备注
40.测试报告的主要内容
测试报告包括哪些内容: 测试模块（每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、追后对这个模块总结一下）。
BUG的统计，根据时间轴来统计BUG的数量，例如：XXXX年X月X日，发现BUG多少，关闭BUG多少，剩余BUG多少，高级的BUG有多少，中级的BUG有多少，低级和建议的BUG有多少，一直罗列到项目完结。
项目总结，汇报一下测试的大致结果。
遗留和风险，该软件还有什么遗留问题，还有什么风险，都要一一说明
最后评判该软件是否符合上线标准，日期，签字，加盖章等。
41.如何定位bug：
1、发现bug，首先要查看bug的详细信息，根据描述初步分析是哪个模块哪段代码的问题
　　2、检查引发bug的测试环境、测试代码段和测试数据，排除测试人员的误操作导致的程序异常
　　3、确认测试代码、测试环境和数据都正确后，再进一步分析bug根源。这里就需要看具体的测试业务了，可借助相关的工具进行分析，比如firebug插件等
　　4、如果产品或业务有相关的日志记录，可通过分析日志来确认bug
　　5、当测试人员经过一系列的分析，可以基本确认bug产生的原因后，就可以直接找开发提bug了（注意沟通技巧）
　　6、如果各方面都分析完还不能确认bug的原因，可以找开发一起定位（注意保留bug现场或者可以复现bug场景）
　　7、确认bug后，提单给开发进行bug跟踪。
　　问题单上要描述清楚以下信息：
　　　 具体的测试时间、测试环境、测试场景、测试的具体业务和功能、使用的测试代码和测试数据、测试执行步骤、测试结果、bug现象（最好截图）、日志记录、预期结果、bug确认相关人员等
　　8、跟踪bug，等开发人员修复bug后进行回归测试。（关注bug是否完全修复、有没有对其他功能造成影响、有没有引入新的问题）
42.开发没时间修复，如何推进bug的修复：
1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点
a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性
b) 可以和开发人员列举一个之前的类似问题，为开发提供参考
c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。
2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改
3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案
4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方的工作人员，反馈问题，尽量推动应用解决问题
小结
总之，bug修不修，测试应该有一个自己的原则，同时也要权衡利弊。不能因为推不动开发，就放弃，由着bug上线，也不能揪着一个小bug不放，影响上线时间。
43.软件测试流程
了解用户需求–》参考需求规格说明书–》测试计划（人力物力时间进度的安排）–》编写测试用例–》评审用例–》搭建环境–》测试包安排预测（冒烟测试）-正式测试-bug-测试结束出报告–》版本上线–》面向用户
44.项目介绍
参考思路：项目叫什么名字，什么架构，有哪些模块，用来干什么的，主要的操作流程
45.对一支圆珠笔进行测试，要从哪些方面进行测试？ 三角形测试用例设计
性能测试
能否正常书写 是否有笔油泄露 笔帽是否能正常按下弹起来
功能测试
一支笔可以用多少时间、写出的字是否褪色
易用性测试
笔的长短粗细是否顺手 一根笔芯用尽是否方便更换
界面测试
外形是否美观 时尚有趣
安全性测试
笔油是否含有有害物质 笔尖是否容易伤到人 笔油或者墨水保质期多长 过期是否产生有害物质、
兼容性测试
在不同的温度、气压、和重力下能否正常使用 在不同的纸质和力度下书写结果如何
三角形测试用例设计：
1、当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。
2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
3、若是等边三角形，则打印：“等边三角形”。
4、画出程序流程图并设计一个测试用例。
因果图、等价类划分（推荐测试方法）
46.在项目中发现哪些经典bug？什么原因导致的？
编码的问题
接口限流防刷的时候，通过计数器限流，如果超过某个阈值，向前端返回一个codeMsg对象用于显示的时候，显示的是String是乱码的问题，之前由于一直返回都是json 格式，都是封装好在data里。
这次返回是直接通过输出流直接写到response直接返回字节数组的，而不是spring controller 返回数据（springboot 默认utf-8），出现乱码问题，用utf-8编码，解决。
比较难解决的bug无非就两种，一种就是程序的逻辑出现问题，导致得不到正确的结果，第二种就是一些中间件，开发环境的问题。
（1）如果是逻辑出现了问题，你项目比较大的话，那只能是通过单步调试，或者用System.out.println()打印出来想要得到的数据看看是哪步出了问题。
（2）如果是开发环境或者是中间件的问题，那只能是通过网上查阅资料来解决问题。如果你英语阅读能力还可以的话，我推荐使用Stack Overflow来查阅资料。
47.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
测试是对软件的质量进行的把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重、致命bug的遗留，轻微和一般的bug遗留率不超过30%。
48.在需求文档不太详细的情况下，如何开展测试？
1.首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来；
2.提取测试点，然后再叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的，
然后再编写测试用例，再评审，评审通过后，再进行后续的测试。
49.如何尽快找到软件中的bug?
1.尽快熟悉公司的产品业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷；
2.把自己当成用户，把自己当成是用户去使用该系统
3.善于怀疑，不要过于相信开发人员的能力；
50.什么是bug？
1.软件未实现需求和规格要求的功能 ；
2.软件未实现需求和规格未明确提及但应该实现的内容 ；
3.软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好；
4.测试用例执行中发现的与预期结果不符的现象
51.ATM机吞卡的吞卡现象是不是BUG?
不一定，看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于BUG；若输入一次密码错误吞卡则是不正常的，属于BUG。
52.如何减少非问题单的提交？
1、 缺陷的概要描述要清晰准确，要使相关开发负责人员能够一目了然问题是什么。
　　2、 一个完整的缺陷报告单，必须包含其必要的元素信息，例如：概要描述，缺陷发现人，测试环境，浏览器，缺陷重现步骤，严重等级，指派人，所属功能模块等等，必要元素信息必须描述全面清楚。
　　3、 缺陷的重现步奏必须描写清晰明了，使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷，使其定位缺陷的原因所在。
　　4、 指派给人一定要明确，如知道缺陷是所属具体的某一个开发人员时，应该直接指派给对应的负责人，这样就能减少中间分配环节的时间。
　　5、 测试数据，测试的数据作为重现缺陷的一个重要元素信息，一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。
　　6、 附件截图信息，附件或截图信息能让开发人员能够一目了然的清楚问题的所在，所以必要的时候提供附件或者截图信息也非常的重要。
　　7、描述缺陷内容的语气，在进行缺陷单书写时，尽量使用专业术语（体现测试的专业性），其次注意书写缺陷报告单时不要带有个人客观的语气内容，以免影响开发和测试人员之间的关系。
53.有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
1、检查系统是否有中度的特征，如：浏览器窗口连续打开，系统中文件图标改成统一图标，CPU使用率保存90%以上等
2、检查软件/硬件的配置是否符合软件的推荐标准
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务，如：虚拟机运行
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。（将程序放在其他的windows上运行，如果运行的还是很慢则是程序的问题。）
54.你们发现bug会怎么处理。
提交bug、指派bug、确认bug、解决bug、重测bug、关闭bug、bug存档
发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。