软件测试面试题-测试基础篇

软件测试是什么？

在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，评估软件是否符合用户需求。 

 

软件测试有哪些分类？

1、按测试方法：黑盒测试，灰盒测试，白盒测试

2、按测试方向：功能、性能、安全、UI、兼容、稳定性、易用性

3、按测试阶段：单元测试、集成测试、系统测试、验收测试、回归测试

 

测试用例由哪些内容组成？

用例编号，用例名称，前置条件，优先级，重要级，测试步骤，测试数据，预期结果，实际结果

 

测试计划的设计方法是什么？

白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖

黑盒测试：边界值分析法、等价类划分法、错误猜测法、场景法

 

SIT测试和UAT测试是什么？灰度测试是什么？

SIT(System Integration Testing)：系统集成测试，也叫集成测试，测试的就是两个模块之间能否正常进行对接。

UAT(User Acceptance Testing)：用户验收测试，通常是由最终软件的用户（通常这些用户不了解软件的具体逻辑，而对业务逻辑却相当熟悉）进行的测试，因此是面向最终用户的测试，结束之后通常就可以发布生产环境了。

灰度测试：在某项产品或应用正式发布前，选择特定人群试用，逐步扩大其使用者数量，以便及时发现和纠正其中的问题。

 

软件的开发模型有哪些？这些模型分别有什么内容？

1、瀑布模型：强调产品定义，各步骤是分离的，前一阶段完成后才能开始后一阶段。 

    缺点：无法回溯，测试在最后运行，惧怕需求变更。

2、V模型：是瀑布模型的变种，把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段，从左到右，描述了基本的开发过程和对应的测试行为。（需要记住开发各阶段与测试的对应关系）

 

 

    优点：自上而下逐步求精，每个阶段分工明确，便于整体项目的把控。

    缺点：忽视了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试。

3、W模型：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试。有利于尽早地发现问题。

    缺点：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

4、敏捷开发：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

 

请简述单元测试、集成测试、系统测试和验收测试分别是什么？

单元测试：测试软件的代码中的函数、方法、类等代码单元。

集成测试：测试两个模块间能否正常进行对接，主要是对接口进行测试。

系统测试：对整个软件的整体进行测试，主要是对系统的功能、性能、UI、兼容、可靠性、易用性进行测试。

验收测试：通常是由最终使用软件的用户进行的测试，检验软件是否符合用户需求，结束之后通常就可以发布生产环境。

 

Bug的生命周期是什么？

指一个Bug从发现到关闭的整个过程。测试发现bug，新建bug，开发对bug进行判断，是就确认bug，进行处理，修改完成后测试对新版本进行回归测试，测试通过就关闭bug，否则就交给开发重新修改。如果在测试过程中以前被关闭的bug又出现了，则重新打开bug。如果开发认为不是bug，就和测试确认，讨论后若不是Bug就关闭bug，是bug就修复bug。

 

Bug的组成部分是怎样的？

1、发现问题的版本

    开发人员需要知道出现问题的版本，才能获取对应版本的代码来重现故障，并且版本的表示也有利于统计和分析每个版本的质量。

2、问题出现的环境

    环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器品牌、版本，客户机操作系统等，如果是app项目，需要描述机型、版本号、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3、错误复现的步骤

    描述问题重现的最短步骤

4、预期行为的描述

    要让开发人员知道怎样的表现才是正确的，尤其要以用户的角度来描述程序的行为是怎样的，如果是依据需求提出的故障，能写明需求的来源是最好的。

5、错误行为的描述

    描述错误的现象，错误界面截图，报错日志等。

 

禅道上提bug包含哪些内容？

编号，名称，优先级，严重级别，复现步骤，附件（一些截图，视频证明为bug）。

 

在以往的工作中，如何区别bug的优先级和重要程度？

优先级：紧急、高、中、低、无关紧要。

    1、通常来说：优先级的定义依赖于严重程度，在大多数情况下，重要程度越高，bug的优先   级越高；

    2、小部分情况：阻碍后续测试；策划开发那边要优先处理的；一些被项目组长定义好的。

重要级：致命、严重、一般、轻微。

    1、致命：和钱有关的任何bug；导致软件崩溃，完全不能使用的；

    2、严重：导致软件的核心业务流程无法进行的；重要级高的用例的正向场景出问题的；

    3、一般：逆向场景出问题的；

    4、轻微：UI上的，易用性的bug。

 

上家公司用的什么软件管理bug？

禅道。

优点：1、开源免费，能够根据企业自身需求在源码的基础上进行修改，节省项目管理成本。

           2、功能完备，具有可扩展性。

 

在测试中发现一个bug，但开发认为不是一个bug，你会怎么解决？

首先自己再去确认一下是不是bug，然后和开发沟通，交流彼此的想法，确认测试环境是否一致，和对方说明这是属于哪一种bug，如果不修复会产生什么影响，如果是不满足需求的bug，和开发指出需求的来源，如果沟通了仍然没有结果，就交给项目组长进行判断。

 

你是如何对bug进行跟踪管理的？

使用禅道对bug进行跟踪管理。发现bug后，在禅道上新建bug，然后交给开发确认并修改，开发修改完成后点击解决，并将新版本交给我，我对新版本进行回归测试，测试通过就关闭bug，如果在新版本中曾经关闭的bug又出现了，则重新打开bug，通知开发进行处理。

 

上线后发现了bug应该怎么处理？

首先确认bug的紧急程度，如果是紧急的bug，马上找开发修改并做回归测试，然后马上更新这个版本，并对用户进行反馈和说明；如果不紧急的话，可以作为优化项到后面版本迭代的时候再进行修复。问题处理完毕后，反思bug遗漏的原因，吸取经验教训，避免下次再犯。

 

遇见了不可复现/随机bug应该怎么处理？

1、遇见问题就要提，在提交的bug描述中需要加上复现概率，即尝试10次，出现1次之类，开发会根据bug的复现概率，调整bug的优先级；

2、尽量回想起发生问题时的复现步骤，不要漏掉任何一个细节，按照步骤的组合尝试复现；

3、保留发生bug时的log，附加到提交的bug中，希望可以通过log找到一些蛛丝马迹；

4、与开发人员配合，让开发同学对相应地方的代码进行检查，看一下是否可以通过代码层面检查出问题；

5、在截下来的测试中，时刻保持关注，每次执行同样或者相近的步骤时，看下是否能够修复之前的Bug；

6、通过上述的办法，仍然无法复现的话，则根据bug的优先级，在上线之前对该bug进行处理，严重级别的bug，要召集项目组的成员，集合大家的力量尽可能的复现bug，不严重的bug，也不要关闭，上线后及时的关注用户的使用反馈，如果持续3或者4个版本没有出现，那么可以将bug暂时关掉，同时要进行说明并不是因为修复了bug，而是因为经过x个版本后不复现了。

 

需求分析是如何开展的？

首先产品经理提出需求，发出需求文档和产品原型，然后测试人员梳理出整个项目的业务逻辑，画出业务流程图，然后找出每个最小功能点及其相关规则，对需求不明确的地方，做到及时询问沟通，最后编写需求分析说明书。

 

给你一个网站，你如何开展测试工作？

1、确认需求

首先，查看需求文档，原型图等，确认需求，然后制定测试计划，确定测试范围和测试内容，一般包括功能、性能、UI、数据库、兼容、稳定性、安全性、易用性测试。

2、设计测试用例：

功能测试：链接测试，链接是否能正常跳转，是否存在空白页和无效页面，是否有不正确的出错信息返回等；各种按钮功能的测试；

界面测试：风格是否统一、美观，页面布局是否合理，显示文字是否出错；

安全性测试：基本的密码验证功能的检查，个人权限是否正确，输入密码次数的限制，sql注入等；

兼容性测试：浏览器品牌、版本兼容性，操作系统兼容性；

性能测试：压力测试（网页最多可以容纳多少人同时操作，模拟用户数量来发现网页瓶颈）；负载测试（系统在最大访问量情况下的承载时间）；

数据库测试：数据的存取操作，数据的验证。

 

上家公司的测试覆盖率是多少？

100%。测试覆盖率=已经测试的用例数量/总的用例数量，前提是用例对需求为100%覆盖。

 

上家公司的测试工作流程？

1、产品经理提出需求，发出需求文档和原型图；

2、测试先看一遍，进行需求分析。测试组长编写测试计划，并分配任务给测试人员（2天）；

3、产品经理进行需求评审，开发、测试可提出一些需求上的问题（0.5天）；

4、需求评审完，测试进行测试场景的梳理和测试用例的编写（xmind和excel，5天）；

5、进行案例评审，项目组各成员对测试用例提出修改意见（0.5天）；

6、修改完后，有两种处理情况：

6.1、对大项目有时候需要进行案例的第二次评审。

6.2、对小项目，在事件紧的时候，一般不会二审，但是要以邮件的形式把修改或者新增后的案例发出来，给领导看，并抄送给其他同事（案例评审0.5天，修改案例0.5天，案例二审0.5天）；

7、用例评审完就要开始测试了，一般测试环境开发搭建好；

7.1、中型版本的测试一般分2轮：第一轮5天，第二轮3天，回归测试2天（共10个工作日）；

7.2、中型版本一个月更新一个版本

 

请简述app测试和web测试的区别

本质是一样的，只是app使用场景比较复杂，所以需要额外对app进行专项测试。

首先在兼容性测试上，web测试只需要考虑浏览器的品牌、版本以及操作系统，app测试需要考虑手机的品牌、版本、分辨率、屏幕尺寸、操作系统等。（分辨率主流：1920*1080,720*1280）

app专项测试还包括：弱网测试，离线测试，下载安装更新测试，电量测试，场景交互测试等。

 

请简述app的弱网测试需要考虑哪些因素，以及怎么测？

主要考虑软件在2g，3g，4g，5g，wifi，有网，无网，弱网情况下的使用；

需要注意的问题：数据交换失败是否有提示；有网到无网再到有网时，数据是否可以自动恢复，正常加载；无网络时，各种提示信息是否友好，数据本地化是否正确。

测试方法：

1、使用真实的SIM卡、运营商网络来进行测试（移动无线测试中存在一些特别的bug必须在特定的真实的运营商网络下才会发现）；

2、通过代理的方法模拟弱网环境进行测试（charles硬延迟）

在fiddler和charles中可以设置网络，fiddler可以在rule中调，charles可以在proxy的延迟设置中设置网络速度；

3、连接模拟弱网的热点进行测试，比如360wifi助手可以设置。

 

测试报告有哪些内容？

1、工作总结（干了什么，做了哪些工作，完成的结果，遇到的问题，问题的反思等）；

2、bug的统计分析：按照模块分，按照版本分，按照开发人员分，按照测试人员分；

3、质量评估：说明当前软件的质量的一个情况，比如功能的完成情况，bug的修复情况。所有的需求已经完成，并且全部通过测试，已发现的bug的一二三级全部关闭。

 

给你一个杯子/电梯/笔，你觉得应该如何测试？

• 杯子：首先了解需求

功能：1、能否装水或者其他液体；2、能装多少ml的水；3、是否有刻度表；4、能否放冰箱，做冰块；

性能：1、最高能装多少度的水，最低能装多少度的水；2、装满水，放几天会不会漏水；3、杯子的涂料是否容易脱落；

界面：1、外观好不好看；2、颜色、形状；3、是否有异味；

安全性：1、制作杯子的材料是否有毒；2、放微波炉是否为爆炸、融化；3、从多少米高的桌子掉到地上是否会碎；4、是否容易长细菌；5、是否有缺口，会造成割伤；

易用性：1、是否好握持；2、杯子是否好端、好拿；3、是否容易烫手；4、杯子的水是否容易喝到；5、会不会很重；

• 电梯：首先看电梯使用说明书、安全说明书

功能：1、开门关门、上升下降；2、电梯按钮是否可以使用；3、报警装置是否可用；4、电话信号；5、通风状况；

性能：1、速度；2、反应时间；3、开门、关门时间；4、最多能承载多少人；

安全：1、停电情况；2、有人扒门电梯是否会异常；

易用性：1、按键高度，按键是否好按；2、操作是否方便、舒适程度；

界面：1、电梯外观；2、光滑程度；3、形状、材料质感；

• 笔：首先确定笔的需求

功能：1、笔筒开合；2、是否需要换笔芯；3、出墨快慢、粗细；4、能否成功写出字；

性能：1、写得是否流畅；2、墨水容量大不大；3、笔芯寿命；4、是否会晕开；5、最大可承受多大压力笔芯不会折断；6、长时间不盖笔套会不会写不出；

安全性：1、笔墨是否易燃；2、笔墨和气味对人体是否有伤害；3、笔会不会割手；

易用性：1、结构合不合理，能否拆卸；2、重不重；3、是否好握、好写；

兼容性：1、笔芯是否适用于市面上主流笔芯尺寸；

界面：1、笔是否好看；2、笔芯颜色是否符合需求；

 

黑盒测试是功能测试吗？

不是，黑盒测试是一种思想方法，可以用在功能测试上，只关心输入输出；

 

没有需求的话，如何进行测试？

1、可以参考市面上已成熟的同类型的产品做参考，根据这些产品的需求确定我们产品的需求；

2、测试人员可以把自己当作用户来思考产品的功能、操作、流程、页面等；

 

项目快上线，可是开发bug还没解决，怎么办？

1、尽力按照上线计划做，通过分析前几个版本的测试结果，制定新的方案，评估上线风险，提出解决方案；

2、分析bug紧急程度，尽可能的处理bug，严重的要报告领导，建议性的可以等到下一个版本迭代时进行修改，至少做到1/2级bug全部改完，3/4级bug修复到80%以上；