一、你们的测试流程是怎么样的?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、如果是因为开发没办法重现Buga、我会看去看下是不是自己的操作步骤不够详细或者有问题首先自己再反复复测下然后重新提交Bug,并保留好截图和日志详细写明步骤再跟开发沟通。b、也有可能是测试环境或者测试数据问题导致没办法重现尝试在不同的环境进行测试或者确认下数据库的数据。然后再与开发沟通。4、如果是其他问题比如开发对我的测试场景不认可开发认为这个场景没有必要测而我们是站在用户角度考虑的一般会再去让身边的同事看看听下他们的意见然后自己先再三去复测并且保存好截图和日志确定这是一个bug 之后我就去跟开发说明白并且给他看bug 重现的截图以及日志。如果开发还是不认可的话我就跟产品或项目经理说明白情况九、测试工作完成后你没有发现一个bug该怎么办?这种情况碰到的比较少吧有可能项目版本迭代比较多Bug 隐藏得比较深而我们用例都是一些常规用例。这个时候需要跟多去从其他的异常场景站在用户的角度去完善用例。检查我的测试环境是不是用错了(测试环境预生产环境验收环境是不是有问题) 再看需求分析有没有问题用例有没有覆盖到位用例设计得好不好多补充一些覆盖无效等价类的测试用例然后用例在评审一下组内让老员工或者同事帮忙审核一下再不行就开会议评审一下需求和用例看看用例有没有覆盖完全或者需求理解到位没预期结果有没有遗漏可以让其他测试人员帮忙检查下用例看有没有覆盖不全的。十、碰到一些偶发性bug开发也不认为这是bug 该怎么办?1、首先我会反复复测想办法重现(换测试环境换数据让其他测试帮忙测下)一旦出现马上截图2、实在重现不了先提交挂起标准为偶现(以便后期关注跟进)。3、跟开发沟通并向开发说明情况我当时是做了什么操作导致这个问题的出现。看开发根据自己的经验是否可以找到具体的原因。4、先执行完其他用例功能测完再说后面有时间话再回过头重现如果还是重现不了。5、后期会跟进1-2 个版本如果1-2 个版本都没出现那就关闭这个Bug。