全国咨询热线：136-9172-9932
一、你们的测试流程是怎么样的?
1、需求交接
需求下来之后，我们会首先熟悉下，然后公司会做一个'需求交接',这个过程中一般会开一个简单的'需求澄清会',在会议上把自己对需求不清楚，不理解，或者有异议的地方都提出来，由产品给我们解答。
2、编写测试计划，需求分析，提炼测试点，编写用例，评审澄清会结束然后就写测试计划，测试计划前期一般都是有我们主管写的，后期基本上是由我们各个测试人员轮流细的，测试计划主要就是安排进度以及任务，分配完之后各自领取自己负责的模块，做需求分析，挖掘，同时写测试点，测试点写完后,就编写测试用例。'测试点，我们用的xmind 的写的，用例当时用的Excel 表格管理的'，等测试用例编写完，一般会有评审，对于评审，有时候就是简单组内评审下，如果大的功能可能会组织会议评审，如果是会议评审，相关的开发，跟产品基本都会到场，其实主要就是看下用例的覆盖率这块，例外就是看检查点有没有检查到位。
3、提测，冒烟测试，全量跑用例(系统测试)
评审了之后，然后会等项目版本出来，开发那边一般会先做单元测试(UT)，之后就开始提测，我们首先会搭建测试环境，做项目部署，之后做冒烟测试，然后去执行用例做系统测试，测试过程中发现bug 就指派给对应的开发，待开发修复完成之后，我们测试需要做复测，复测没有问题就关闭Bug,如果还是有问题，重新开启Bug，直到改好了复测完没问题才可以关闭这个bug。一般系统功能测试我们需要测试2-3 轮，保证所有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。
需要更多软件测试相关面试资料可以联系我们，大家加油!
