软件测试培训中有哪些高频面试题？

软件测试培训，这个让新人快速入门的捷径，面试题可是其中的重点。你是不是也好奇，软件测试培训中都有哪些高频面试题呢？别急，今天我们就来为你盘点一下，从基础知识到实战经验，让你对软件测试面试题有个全面的了解，轻松应对面试挑战！

一、你们的测试流程是怎么样的?

1、需求交接

需求下来之后，我们会首先熟悉下，然后公司会做一个'需求交接',这个过程中一般会开一个简单的'需求澄清会',在会议上把自己对需求不清楚，不理解，或者有异议的地方都提出来，由产品给我们解答。

2、编写测试计划，需求分析，提炼测试点，编写用例，评审澄清会结束然后就写测试计划，测试计划前期一般都是有我们主管写的，后期基本上是由我们各个测试人员轮流细的，测试计划主要就是安排进度以及任务，分配完之后各自领取自己负责的模块，做需求分析，挖掘，同时写测试点，测试点写完后,就编写测试用例。'测试点，我们用的xmind的写的，用例当时用的Excel表格管理的'，等测试用例编写完，一般会有评审，对于评审，有时候就是简单组内评审下，如果大的功能可能会组织会议评审，如果是会议评审，相关的开发，跟产品基本都会到场，其实主要就是看下用例的覆盖率这块，例外就是看检查点有没有检查到位。

3、提测，冒烟测试，全量跑用例(系统测试)

评审了之后，然后会等项目版本出来，开发那边一般会先做单元测试(UT)，之后就开始提测，我们首先会搭建测试环境，做项目部署，之后做冒烟测试，然后去执行用例做系统测试，测试过程中发现bug就指派给对应的开发，待开发修复完成之后，我们测试需要做复测，复测没有问题就关闭Bug,如果还是有问题，重新开启Bug，直到改好了复测完没问题才可以关闭这个bug。一般系统功能测试我们需要测试2-3轮，保z所有Bug基本都修复完成，

4、编写测试报告，发版上线

之后写测试报告，然后看是否达到上线标准，达到了上线标准的话，由SE组织时间进行产品上线，上线一周之后就是做总结。

二、等价类与边界值怎么理解?

等价类分为，有效等价类，无效等价类，有效等价类其实就从正向去考虑，正常的场景，无效等价类，就是站异常的场景角度去考虑用例。一般主要用在对文本编辑框的用例设计，比如：注册用户名，用户名规定在3-5个字符之间，那么我们在设计用例的时候就要考虑有效等价类：3-15中随机取一个值，无效等价来就是：<3,>15。

边界值其实是对等价类的一种补充，它其实不能当成主要的用例方法，但是一定要考虑，因为很多问题都发生在边上。边界值一般有上点，离点，内点，比如刚才说的用户名，边界值就要考虑3,5,2,16这几个点。

三、怎么'写'好用例?

1.用例名称不能重复，

2.用例名称里面不能出现歧义的字语

3.用例标题能一眼看出来你测试的是什么场景，指的是你测试场景不重复，不一样就行，

其他的预置条件啊，步骤啊，预期结果啊，都可以重复,测试用例简单，明了

4.预置条件：就是测这个用例需要达到的条件

5.步骤相对详细,要指导测试人员能够执行用例

6.这个场景影响到点，都做为预期结果检查， 的详细，相关模块检查，前后台检查，

数据库检查都要到位

四、bug怎么管理的，bug的生命周期或者是bug的状态

原来bug是用禅道来管理的

测试过程中发现bug，首先提交bug直接给对应的开发人员，对应开发人员修复完成，交给测试复测，复测通过关闭bug，不通过打回给对应开发

提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成-标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活

五、提Bug需要注意哪些问题?

1、不要急着提交，先做一下复现，进行证实，如果需要的话，也可以使用不用的版本测试

对比一下

2、Bug标题要简明扼要的表述清楚，操作步骤(一定要描述清楚，以便开发可以复现),预期结果，实际结果一定要写清楚，比较好，把截图，日志相关的信息一并的提交(方便开发定位)

3、Bug的级别(严重级别，优先级别)尽量要定得合理

4、在不能确认该情况是否为bug的时候，可以请其他测试人员帮忙看看。

5、提交完bug以后，后面还要跟进bug。

6、对于致命，严重Bug比较的情况，比较好跟开发沟通下，让开发尽量先修复，验证下，不要盲目提交。

六、提交bug包含哪些内容

1、这个Bug所属产品，所属模块，所属项目，以及影响的版本，

2、指派人员

3、严重程度，优先级，

4、bug类型，以及bug产生的环境

5、Bug标题，描述，

6、Bug的详细重现步骤，预期结果，实际结果，

7、附件(包括截图，日志等)

七、致命Bug跟严重Bug的区别?

致命Bug:导致系统崩溃，数据丢失，卡死，闪退，数据库死锁，一般这种类型的，我们都会标准为致命Bug

严重Bug:功能没有实现，主流程走不通，功能有严重问题不能正常使用，这种，我们一般会标注为严重Bug

八、你提交的Bug开发不认可的话，如何解决?

1、这个肯定首先找开发沟通，搞清楚开发不认可的原因

2、如果是需求问题，可能是开发与我们对需求理解不一致，首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug，如果还是觉得没有问题，那就找产品确认需求，然后再与开发沟通

3、如果是因为开发没办法重现Bug

a、我会看去看下是不是自己的操作步骤不够详细或者有问题，首先自己再反复复测下，然后重新提交Bug,并保留好截图和日志，详细写明步骤，再跟开发沟通。

b、也有可能是测试环境或者测试数据问题，导致没办法重现，尝试在不同的环境进行测试，或者确认下数据库的数据。然后再与开发沟通。

4、如果是其他问题，比如开发对我的测试场景不认可，开发认为这个场景没有必要测，而我们是站在用户角度考虑的，一般会再去让身边的同事看看听下他们的意见，然后自己先再三去复测，并且保存好截图和日志，确定这是一个bug之后我就去跟开发说明白，并且给他看bug重现的截图以及日志。如果开发还是不认可的话我就跟产品或项目经理说明白情况

九、测试工作完成后，你没有发现一个bug，该怎么办?

这种情况碰到的比较少吧，有可能项目版本迭代比较多，Bug隐藏得比较深，而我们用例都是一些常规用例。

这个时候，需要跟多去从其他的异常场景，站在用户的角度，去完善用例。检查我的测试环境是不是用错了(测试环境预生产环境验收环境是不是有问题)再看需求分析有没有问题用例有没有覆盖到位，用例设计得好不好，多补充一些覆盖无效等价类的测试用例，然后用例在评审一下，组内让老员工或者同事帮忙审核一下，再不行就开会议评审一下需求和用例，看看用例有没有覆盖完全或者需求理解到位没，预期结果有没有遗漏

可以让其他测试人员帮忙检查下用例，看有没有覆盖不全的。

十、碰到一些偶发性bug，开发也不认为这是bug该怎么办?

1、首先，我会反复复测，想办法重现(换测试环境，换数据，让其他测试帮忙测下)，一旦

出现马上截图

2、实在重现不了，先提交，挂起，标准为偶现(以便后期关注跟进)。

3、跟开发沟通，并向开发说明情况，我当时是做了什么操作导致这个问题的出现。看开发根据自己的经验是否可以找到具体的原因。

4、先执行完其他用例，功能测完再说，后面有时间话再回过头重现，如果还是重现不了。

5、后期会跟进1-2个版本，如果1-2个版本都没出现，那就关闭这个Bug。