测试面试题

1.B/S架构和C/S架构区别

B/S 只需要有操作系统和浏览器就行，可以实现跨平台，客户端零维护，但是个性化能力低，响应速度慢

C/S 响应速度快，安全性强，一般应用于局域网中，因为要针对不同的操作系统，需要针对性的开发，并且维护成本高

 

 2.HTTP协议

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据

 

3.GET与POST区别

1、GET使用URL或Cookie传参。而POST将数据放在BODY中。

2、GET的URL会有长度上的限制，则POST的数据则可以非常大。

3、POST比GET安全，因为数据在地址栏上不可见。

4、一般get请求用来获取数据，post请求用来发送数据。

 

 4.Cookie和Session的区别与联系

1. 存储位置不同

Cookie 的数据信息存放在客户端浏览器上

Session 的数据信息存放在服务器上

1. 存储容量不同

单个cookie 保存的数据 <=4KB,一个站点最多存放20个cookie

对于session 来说没有上限，但出于对服务器端的性能考虑，

Session 内不要存放过多的东西，并且设置session删除机制

3.存储方式不同

Cookie 中只能保管ASCII 字符串，并且通过编码方式存储为Unicode 字符或者二进制

Session 中能够存储任何类型的数据，包括并且不限于string，integer，list,map等

4.隐私策略不同

Session比cookie安全

1. 跨域支持不同

Cookie 支持跨域名访问

Session 不支持跨域名访问

cookie和session的联系

1、cookie对象和session对象一样是用来保存特定的用户相关的数据

2、通过cookie/session的名称来区分不同的cookie/session

3、有生命周期，cookie最大可设置为50年，session默认周期为20分钟，可以手动设置更短或更长的时间

4、使用范围，都是特定用户（如有些软件需要登陆，不一定所有人都会使用到）

 

 5.测试的目的

1.测试是程序的执行过程，目的在于发现错误

2.一个成功的测试用例在于发现至今未发现的错误

3.一个成功的测试是发现了至今未发现的错误的测试

4.确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明。

5.确保产品满足性能和效率的要求

6.确保产品是健壮的和适应用户环境的

 

6.软件测试原则

1. 测试显示软件存在缺陷

2. 穷尽测试是不可能的

3. 测试尽早介入

4. 缺陷集群性（2/8原则）

5. 杀虫剂悖论

6.测试活动依赖于测试内容

7.没有错误是好是谬论

 

7.软件测试分为哪几个阶段？

一般来说分为5个阶段：单元测试，集成测试，确认测试，系统测试，验收测试

 

8.单元测试与集成测试的侧重点

单元测试：是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括程序的正确性炎症等

集成测试：也叫组装测试或联合测试，在单元测试的基础上，讲所有模块按照设计要求，组装成为或系统，进行集成测试

系统测试：是将经过测试的子系统装配成一个完整系统来测试，它是检验系统是否确实能提供系统方案说明中指定功能的有效方法，测试重点是整个系统的运行以及其他软件

 

9.系统测试范围

黑盒测试。不接触代码，只对整个系统做功能的测试和性能的测试。

 

10.a测试与ß测试的区别

Alpha,Beta测试

а测试 软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试。

ß测试 软件开发公司组织各方面的的典型客户在日常工作中实际使用，并要求用户报告异常情况、提出改进意见，然后公司再进行完善。

 

11.验收测试怎么做？

用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。

用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。

由于验收测试不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测

 

12.白盒、黑盒和灰盒测试区别

黑盒测试：指的是把被测试的软件看成一个黑盒子，我们不去关心盒子里面的数据结构什样子，只关心软件的输入数据和输出结果

白盒测试：指的是把盒子盖打开，去研究边源代码和程序结构

灰盒测试: 灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能。

 

13.冒烟测试的目的

冒烟测试其实就是确保该版本的系统基本功能能正常运行。如果冒烟测试不通过，测试人员是不会进行测试，打回给开发

 

 14.回归测试怎么做？

回归测试是指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误

 

15.全量回归与部分回归的区别？

全量回归：对软件的新版本测试时，重复执行上一个版本测试时的用例，防止以前没有的问题现在出问题了

部分回归：当开发修复某个Bug时，我们需要去检查该Bug是否被修复，还需要检查与之相关的模块是否受到影响

 

16.需求分析的目的

澄清需求，提取测试点

 

17.测试计划的目的

规范软件测试内容，方法和过程

 

18.什么时候开始写测试计划

需求分析后

 

19.由谁来编写测试计划

一般都是由测试经理或者测试组长来编写

 

20.测试计划的内容

1. 测试背景
2. 测试目的
3. 确定测试范围
4. 制定测试策略
5. 测试资源安排
6. 测试时间安排
7. 测试人员分配
8. 风险评估

 

21.结束条件（项目上线的条件）

需求的覆盖率，用例的执行和缺陷的遗留率达到质量目标

通常来说，需求覆盖率和用例执行率需要达到100%

致命/严重的缺陷需要当天解决，轻微/一般遗留率不得超过30%

 

22.常见的测试风险

进度风险，质量风险和需求变更

 

23.测试用例的要素

用例编号，所属模块，用例描述，前置条件，优先级，输入数据，操作步骤，预期结果，实际结果，测试人员，测试时间

 

24.测试用例级别的划分

一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定

 

25.怎样保证覆盖用户需求？

项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都要覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏，用例编写完之后，在进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全

 

26.写好测试用例的关键 /写好用例要关注的维度

1. 覆盖用户的需求
2. 从用户使用场景出发，考虑用户的各种正常和异常的使用场景
3. 用例的颗粒大小要均匀，通常，一个测试用例对应一个场景
4. 用力拉各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行
5. 做好用例评审，及时更新测试用例

 

27.测试用例的状态

通过，失败，未执行，无效，阻塞，不适用

 

28.常见的测试用例设计方法

等价类划分，边界值，错误推测，因果图，场景法，正交表

 

应用的场景

等价类划分

多用于输入框：注册/登录

边界值（掌握上点和离点的取值）

多和等价类划分结合使用，有边界限制的:注册的密码长度，，

场景法

从基本流开始，再将基本流和备选流结合起来，可以确定用例场景   银行取钱

正交表

用于多个下拉框之间的组合，可以通过正交助手生成测试用例

错误推测

错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。

一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充

因果图

因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出

        自动贩卖机  

 

29.判定表用在哪些时候/哪些功能

判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判断表

 

30.什么时候用到场景法

使用场景法通常是在冒烟测试中或者一些流程性比较强的软件/功能（比如安装，卸载等等）

 

 31.测试环境怎么搭建的？

搭建环境前，开发都会给我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，Mysql版本是5.7，程序是Java编写的，首先我们向开发拿到编译好的安装包，然后用xshell（或CRT）远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了

 

32.偶然性问题的处理

1.发现Bug之后，我们会先截图，如果确定是偶然性的问题，会将日志和截图一起提单给开发定位

 

2.如果缺陷在当前版本无法修复，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本如果后三个版本都无法修复，就可以关闭缺陷

 

 33.当我们认为某个地方是bug，但开发认为不是bug，怎么处理？

1.首先，将问题提交到缺陷管理库里面进行备案

2.然后，根据需求文档说明，确认实际结果是否与计划不一致的地方

3.与设计人员，开发人员和客户代表相关人员探讨，确认是否是缺陷

4.像开发人员说明自己的判断理由

5.等待测试经理做出最终决定  

 

34.产品在上线后用户发现bug，这时测试人员应做哪些工作？

首先要做的是重现这个问题并反馈给研发人员，尽快出patch或者解决方案。

当BUG解决且上线没有问题之后，我们再看后续的处理。

追查原因及处理方法：这个BUG出现的原因是什么。这有分为几种情况：

1）测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟的情况。

解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。

2）漏测：

a.测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例

解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。

b.测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏。

解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为偷懒漏测，还是因为负责模块过多漏测，还是有其他原因，对该名测试人员发出警告，对相关测试主管，项目经理，产品经理发出警告。

c.测试用例覆盖不全：由于用例评审的不严格造成的；中途需求变更造成的；由于某些其他因素造成的

 

35.二八定理

80%的缺陷出现在20%的代码中；80%的BUG发现在20%的时间中；80%的花费在20%的错误代码上。

 

36.如何跟踪缺陷

1.过程描述

测试人员按照测试用例依次进行，并针对缺陷整个生命周期进行跟踪

2.角色的定义

测试人员:负责具体测试执行及跟踪人员

测试组长:负责测试执行机跟踪包括bug单的一次审阅

项目经理:对测试人员的bug进行审核及分配

开发人员:对分配到个人的bug进行解决

3.状态的定义

新建，确认，解决，重新验证，关闭，重新打开

 

37.缺陷的状态

一个Bug由测试人员发现并提交,我们将状态标注为新建;开发人员接收了该

Bug,将Bug的状态修改为已分配(Assigned),表示已经认可;开发人员解决了该

Bug后,就将Bug的状态修改为解决,并发给测试人员回归测试;测试人员对Bug

进行回归测试，如果确实已经解决,就将Bug的状态修改为关闭,否则的话则发给

开发人员重新修改。还要说明的是,Bug是可以“死而复生”的,以前版本已经关闭

的Bug,如果新版本中重新出现,我们就需要将其状态修改为重新打开。

 

38.缺陷的等级

1.轻微缺陷

轻微缺陷是指对产品外观和下道工序可能会有轻微影响的缺陷

2.一般缺陷

一般缺陷是指不影响产品的运转和运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷

3.严重缺陷

严重缺陷是指可以引起易于纠正的异常情况、可能引起易于修复的故障或对产品外观造成难以接受的缺陷。

4.致命缺陷

致命缺陷是指会造成安全问题的各类缺陷

 

39.缺陷单应该包含这些要素

所属产品，所属模块，当前指派（重要），

bug类型，操作系统，重现步骤(重要)，

验证程度(重要),优先级(重要)，附件等

 

40.测试报告的主要内容

测试目标，测试的范围，测试环境，测试结果分析(多少轮测试，测试多少，失败多少，成功占比)，遗留缺陷，测试结论（本次测试涉及xxx个功能点，发现xx个缺陷，其中，xx个已修复，xx个遗留。）测试过程完整有效，系统测试通过

 

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的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。

2、 工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急，来不及修改、开发不关注名下的bug、开发认为目前的实现比产品需求好等情况

3、 当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因

4、 另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等

 

43.软件测试流程

立项--编写需求--需求评审 -----开发：编写概要和详细设计--- 编码并自测                                                -----测试: 测试用例--测试用例评审

----部署环境---冒烟测试--提交bug---回归测试试--验收测试--上线

 

44.项目介绍

1、对项目进行基本介绍

• 最近测试的项目是一个电商平台系统，运营模式类似于天猫，京东这些网站。

• 项目系统由前台和后台两部分构成。

前台面向购物用户，包括会员、商品展示、购物车、订单、支付、用户中心等系统模块。

后台面向经营商家，包括商品管理，会员管理，订单处理等系统模块。

2、说明自己负责测试的模块

• 我在项目中主要负责订单及后台订单处理相关模块测试。

• 购物车-----

• 订单处理

– 我们项目后台订单处理主体流程是：

用户支付成功--商家确认订单--发货--用户确认物品无误，确认收获--订单结束--后续有售后和评价相关流程。

– 其他：

商家除了确认用订单，还可以对订单进行取消操作

用户如果未确认收货，系统可以设置超时自动收货（7天）

收货异常或其他情况下还可以进行退款操作。

 

 45.对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计

1.功能测试：

圆珠笔按下是否能正常书写。

2.性能测试：

笔芯弹出弹回的快慢。

3.负载测试：

连续按，看弹簧能经受多少次伸缩。

4.兼容性测试：

看是否可以使用其他笔芯。

5.强度测试：

用力过度会有什么影响

6.可恢复性测试：

长时间按住弹簧，松开后看弹簧是否可以恢复

7.界面测试：

笔的外观，舒适度

8.安全性测试：

是否会对使用者造成伤害

 

 

 46.在项目中发现哪些经典bug？什么原因导致的？

Jmeter连接数据库进行压测的时候 （报错无法创建拒绝用户的访问，密码正确）

解决方法：禅道与mysql数据库端口冲突，服务中关闭mysqlzt，就好了

注册信息中的错误提示信息：如手机信息栏应填入11位有效电话号码，但提示信息却为“13位电话号码”，这是因开发人员粗心大意造成的

接口bug：传的字段值为空，但是开发没给默认值设个0导致接收不到数据

 

47.一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

测试是对软件的质量进行的把关，如果一个项目任然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重，致命Bug的遗留，轻微和一般的Bug遗留率不超过30%

 

48.在需求文档不太详细的情况下，如何开展测试？

1.首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来

 

2.提取测试点，然后再叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的，然后再编写测试用例，再评审，评审通过后，再进行后续的测试

 

49.如何尽快找到软件中的bug?

1.尽快熟悉软件的需求和业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷

2.把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗？

3.善于怀疑，不要开发人员的能力

 

50.什么是bug？

1.软件未实现需求和规格要求的功能

2.软件未实现需求和规格未明确提及但应该实现的内容

3.软件难以理解，不易使用，运行缓慢，或者最终用户认为不好

4.测试用例执行中发现的与预期结果不符的现象

 

51.ATM机吞卡的吞卡现象是不是BUG?

不一定，看是什么情况下吞卡，如：输入三次密码错误吞卡是正常的，不属于Bug，若输入一次密码错误吞卡则是不正常的，属于Bug

 

52.如何减少非问题单的提交？

熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；

跟产品确认该问题是否属于非问题单。

 

53.有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？

1. 检查系统是否有重度的特征
2. 检查软件或硬件的配置是否符合软件的推荐标准
3. 确认当前的系统是否独立，既没有对外提供什么消耗CPU资源的服务
4. 如果C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的
5. 在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU内存的访问情况

 

54.你们发现bug会怎么处理。

1.项目经理通过和客户的交流，完成需求文档

2.开发人员根据需求文档完成需求分析文档，测试人员进行评审

3.测试人员根据修改好的需求分析文档开始写测试用例

4.测试用例完成后，测试和开发需要进行评审。

5.测试人员搭建环境

6.开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提 交给bugzilla。

7.开发提交第二个版本，包括bugfix以及增加了部分功能，测试人员进行测试。

8.重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。

9.如果有客户反馈的问题，需要测试人员协助重现以及回归测试。