1、一般迭代是多久一次,人员结构有哪些?

答:一般迭代是2周一次;

人员结构: PM(项目经理):1人

     开发:4-5人

     前端:1-2人

     测试:3-4人

     产品经理:1 人

     共计13人

2、2周工作内容(一个迭代)是什么?

第一周

周一:熟悉需求文档以及参与需求的评审,和拆分任务;

周二:继续熟悉需求,编写测试用例;

周三:继续编写测试用例,评审测试用例,以及完善测试用例;

周四:编写自动化测试代码(学习/应用);

周五:继续编写自动化测试代码,开发转测后,进行冒烟测试验证。

第二周

周一:测试被转测试的产品 ;

二:继续测试,以及验证回归问题(Issue);

周三:继续测试,以及进行验收测试;

周四:编写测试报告,做最后的探索性测试,准备上线前的资料,以及晚上上线后的回归测试验证;

周五:参加项目迭代复盘会议,以及针对本地迭代进行总结,准备下一个迭代的工作内容。

3、验收测试流程的流程是什么?

答:测试在周三下午测试完成,发送邮件让产品经理进行验收测试,产品经理会在周三下午以及周四的早上进行验收测试, 验收测试完成后会回复邮件,反馈本次验收测试的

结果;测试报告的前提因素:在产品经理验收测试通过的情况下,测试才能够发测试报告,如果验收测试不通过,开发测试继续修改存在的问题。

周五复盘会议:

1)总结本次迭代有哪些优点,以及哪些缺点;

2)针对本次迭代的缺点,提出对应的解决方案,在下个迭代中执行。

4、常用的测试用例方法有哪些?举例说明?

1)等价类:针对被测对象的输入数据分为有效数据和无效数据,是功能测试的一种测试用例设计方法。如电话号码,那么有效数据就是 符合运营商电话号码的规则,无效就是不符合,如连续的11个同样的数字以及非11的数字。

2)边界值 :边界值是针对等价类测试用例方法的补充,如电话号码,需要考虑到11位,以及12位,和0位,也就是边界的情况。

3)判定表驱动分析法:列出被测对象可能存在的不同条件,如招聘类网站筛选出的结果排序,可能会存在多个条件来筛选出结果,如年限,薪资,地区等等,需要先列出来。

4)因果图 :在判定表的基础上,根据被测对象列出的条件,来使用排列组合的方式来验证各个不同条件下(并且以及或者关系)程序的结果情况。

5)正交实验分解法 :在因果图的基础上,使用排列组合下来的测试用例个数是非常多,导致测试用例的个数是非常多的,那么使用正交实验分解法可以优化,测试用例的个数,选择有代表性的数据来进行测试,比如招聘网站搜索互联网岗位时,筛选条件,选择城市时,可选择热门的城市如:北京、上海、广州、深圳、杭州、西安等城市。

6)场景设计法 主要考虑的是一个产品的完整的业务流程,从输入流开始一直到输出流,比如淘宝,从一个商品上架一直到商品的出售。

7)错误推测法 针对被测产品的非功能性的测试用例,主要使用探索性测试的方法,来验证被测产品可能存在问题,举例如下:

①在波浪式的交互过程中,一直往下滑动,可能会出现浏览器的卡死;

②在列表中翻页可能也会存在浏览器的卡死;

③Java语言编写的应用程序,大概率可能存在内存泄露(Java.lang.OutOfMemory,简称:OOM);

④一码通,对该应用程序进行大量的扫描二维码并且一直在进行扫描,那么很有可能存在扫描二维码后出现不了结果或者是导致结果一直加载中。

8)功能图分析法 :针对程序非功能性的测试,主要考虑的是被测程序的内部结构代码的测试。主要用于白盒测试。

5、编写测试用例的依据是什么?

1)需求文档以及系统的产品业务逻辑

2)开发的技术方案,在技术方案里面会有程序内部的设计原理和逻辑流程图

3)个人的工作经验,比如任何一个产品都需要考虑异常的逻辑下程序的容错能力,以及产品的性能测试

6、你一天能够编写多少个测试用例?

我们之前编写测试用例都是使用思维导图的方式来编写的,我主要考虑的是把测试的产品测试点考虑周全

7、你怎么确保你编写的测试用例把测试点都包含进去了?

1)我首先会把系统中可能存在的各个业务逻辑使用思维导图都列出来,使用到的测试用例方法是判定表驱动分析方法

2)产品的正常功能,使用到的测试用例方法主要是等价类,边界值以及因果图

3)产品的非正常功能下系统的容错能力,主要使用到的测试用例方法是错误推测法

4)同时也会考虑被测产品的性能测试,以及它的安全性的测试(脚本注入)

5)设计测试点需要考测试对象被依赖的测试点的场景

8、测试对象的分类有什么?

1)大数据类的产品:好好的熟悉底层的设计以及数据之间的流转

2)交易类的公司(淘宝,美团,字节)

3)通信类的产品,需要懂底层的通信协议

9、测试的对象使用到的具体方法有哪些?

1)有需求文档的产品,并且有交互

2)底层的服务测试(没有需求文档,也没有交互),比如测试一个支付类的产品,使用到的测试用例方法具体总结如下:

①功能性:等价类以及边界值,和因果图 price:针对金额测试需要考虑数字(有效数据)和非数字的(无效数据)

以及针对金额需要测试最大金额和最小金额,以及 金额小数点的位数----》等价类以及边界值的方法

price and goods:需要测试支付的时候同时带金额和商品,如果缺少一个,支付服务有没有错误的处理。

②非功能性:错误推测法 连续不断的支付,是否会出现支付卡死(支付时间长,或者暂时不能支付,得到一会支付)

10、测试用例的评审的流程是什么?

1)自己编写完测试用例后,预定会议室,同时和大家约这个开会的时间是否都能够参加

2)到约定的时间,组织相关的人到会议室(那么这个时候会议的主持人就是你自己,会议的气氛以及氛围营造都是你自己来控制的)

3)开始时候的评审,你给大家描述每个测试点,大家都在听

    A、当大家没有问题的时候,可能会回应你,也可能不会

    B、当你描述的过程中,如果那个有问题,别人会立刻提出来,会议主持人需要把别人提出的问题立刻记录下

4)评审结束,做最后的总结

11、评审测试用例都有哪些人参与?

1)开发

2)产品

3)测试

4)PM(leader)

12、评审测试用例注意事项:

1)评审的过程中,如果别人提出疑问,针对有的疑问需要不同角色(产品,开发,测试)讨论决定结果

2)评审的过程中,某些测试场景以及测试结果可能存在问题,别人提出来,需要直接在现场修改自己的测试用例

3)有的疑问需要挑战的地方比较多,不需要现场调整,那么就需要在现场记录在本子上

4)评审结束,总结性的发言: A、针对别人提出来的疑问,做一个汇总

5)评审结束之后,根据别人提出的疑问,调整(完善)测试用例,调整结束后,再次把测试用例发送到工作群里面,同时@相关的人

13、每个版本(迭代)测试这边的文档:

1)测试计划

2)测试用例

3)测试报告

4)测试技术方案

14、编写测试用例的技巧:

1)在一个新的环境里面,首先确认什么地方编写测试用例,以及什么方式编写

2)确认清楚后,编写一小部分,然后让对方去看下颗粒度,再对方的建议上继续调整

15、测试用例的设计方法分类:

功能测试用例方法: 等价类 边界值 因果图 正交实验分解法 判定表驱动分析方法

非功能性的测试用例方法: 错误推测法 功能图分析方法

场景: 场景设计方法

16、测试综合策略:

1)使⽤各种测试⽅法的综合策略

①在任何情况下都必须使⽤边界值分析⽅法,经验表明⽤这种⽅法设计出测试⽤例发现程序错误的能⼒最强。

②必 要时⽤等价类划分⽅法补充⼀些测试⽤例。

③⽤错误推测法再追加⼀些测试⽤例。

④对照程序逻辑,检查已设计出 的测试⽤例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充⾜够的测试⽤例。

⑤如果程序的功能说明 中含有输⼊条件的组合情况,则⼀开始就可选⽤因果图法。

2)测试⽤例的设计步骤

①构造根据设计规格得出的基本功能测试⽤例;

②边界值测试⽤例;

③状态转换测试⽤例;

④错误猜测测试⽤例;

⑤异常测试⽤例;

⑥性能测试⽤例;

⑦压⼒测试⽤例。

3)优化测试⽤例的⽅法

①利⽤设计测试⽤例的8种⽅法不断的对测试⽤例进⾏分解与合并;

②采⽤遗传算法理论进化测试⽤例;

③在测试时利⽤发散思维构造测试⽤例。

边界值,等价类,因果图--->所有的都必须要考虑的

17、如果你刚到公司是一个新人,你发现了之前测试过一个产品有一个bug未向上提交,这时你会怎么做?

应该遵循以下的基本原则:

1、是问题必须反馈(提交BUG),这是一个价值观的问题

2、如果像这样的问题,大家都认为没有必要(包含测试负责人也是这样认为),那么你以后提单就需要注意:

  A、不管后面是否遇到同样的问题,即使遇到也是提单,修改不修改问测试负责人

  B、针对每次这样的事最好有记录

3、质量是公司所有的人来负责的,但是现实生活中,遇到问题,测试肯定得有责任

18、如果一个开发比较难搞,你怎么处理和他之间的关系?

1、在公司有的事情你是不能够改变的,你唯一能够改变的就是自己做事的风格

2、该是问题还是问题,你继续提交BUG,至于不修改的情况下,问题再找人解决

3、再职场里面,不要和人去计较一些东西

19、当你提了一个 bug,开发认为这不是 bug,该怎么处理?

该问题主要考核的是推动解决问题的能力以及定位问题的能力,找领导是最次的解决方案,如果因为一个开发不承认就找领导,那领导一天就什么都不需要干了,这个时候领导还是领导嘛。

所以可以这样说:首先我会再次检查问题是否存在(也存在你测试的时候问题存在,但是开发偷偷的解决了的情况),如果问题存在,那么提交的BUG步骤一定能要非常清晰,通俗易懂,同时要在提交的BUG里面附加上错误信息的日志上下文,以及尽可能的提供错误的截图信息。首先开发不承认不是和测试作对,也不是为难测试的,可能就是反馈的问题让对方看不清楚,或者看不懂,当然也存在某些开发很差劲,但是我建议不要这样去想开发,毕竟是一个团队的,信任,认可是很重要的。这样调整后,可以再找开发,比如打扰下,麻烦看看这个问题,是否是我的姿势不对等等,总之友好沟通,让对方来解决问题 如果真的发生是问题,并且提供的信息都是非常全的,但是开发不是不承认,各种不配合,这个时候需要思考下,对方为什么不承认,难道专门为难自己还是自己的沟通方式存在问题。比如你这代码差劲的,开发大概率就会很反感,也就不会配合了。所以这个时候也自己需要反思,然后改变沟通的策略和方式方法。

20、新功能晚上上线,结果上线后就有了问题,此时你会?

1、先在测试环境验证问题是否存在(排查是开发的责任还是测试的责任)

2、测试环境验证问题存在,那么就说明测试环境测试这边没测试出来,那么在群里面反馈给大家,然后再次评估今天晚上上线是否继续?

3、测试环境验证问题不存在,也需要反馈出来,下一步@开发,让开发检查各个中间件(RabbitMQ,Kafka,Redis等)的配置参数以及其他的配置

4、开发在3的基础上更新代码解决问题后,测试协助开发验证,然后把验证的结果反馈出来

21、产品上线后处理问题,之后如何复盘?

1、测试问题,复盘怎么说?

A、这个问题首先测试这边是责任的,之前设计测试用例不仅仅测试没考虑到,评审的时候大家也没考虑到,所以导致这个场景没有测试到

B、所以下次编写测试用例,测试这边会增加XX维度的测试点,评审的时候大家也需要沿着这个维度来考虑

2、开发问题,复盘怎么说?

A、建议开发这边每次上线前专门写一个关于上线的checklist,这样防治下次也犯同样的问题,格式如下:

 

序列号 检查项 负责人
1 Redis参数修改为... 赵四

 

22、从测试开始到测试结束,测试总共测试几轮? 在一个迭代中,你是怎么保障质量的?你是怎么测试保障本次迭代是没问题的?

1、第一轮的测试:主要是测试本次迭代转测的所有功能,包含了正常,异常,性能,容错,等等(周一)

2、第二轮的测试:先回归验证所有的问题单,问题单验证完毕后,再针对本次迭代的核心流程再次测试(周二)

3、第三轮的测试:再次回归问题,以及进行系统测试(周三)

4、下来接着就是验收测试以及探索性的测试

23、版本合并后,测试还需要测试吗?为什么?

版本代码合并后,测试需要针对系统的所有功能(新的功能+系统之前已有的功能)都需要进行测试;开发在合并代码的时候,可能会出现冲突,也可能会出现代码的丢失。

24、每次迭代所有BUG必须要解决吗?

1、每个迭代的BUG不一定所有要解决的

2、不能解决的的情况:

  A、很难解决,需要很长时间 

  B、可以解决也可以不解决,不是紧急的

3、针对必须要解决但是又影响范围很大,这个时候作为测试的操作行为:

  A、你需要把实际情况反馈给测试负责人

  B、由来你主持会议(会议参与人,产品经理,开发,开发负责人,测试,测试负责人,pm,pmo)

25、开发这边转测经常冒烟测试不通过,你这边有什么改进的方式和方法?

把冒烟测试用例发给开发,在转测之前,开发先执行冒烟测试用例,测试通过后,再转测,进行冒烟测试。

 26、请描述一个完整的测试流程(请描述一下你理解的测试流程)

先进行需求的评审,需求评审通过后,开发设计编码,测试这边开始编写测试计划、设计测试用例,然后进行测试用例评审,用例评审通过、开发完成后转测,进行冒烟测试,冒烟测试通过进入到测试阶段,测试执行测试用例,提交BUG以及验证BUG,测试完成后,编写测试报告,进行验收测试(测试报告和验收测试可同时进行),之后,做上线前的准备工作,上线后的回归测试验证,至此迭代测试结束。

27、你是怎么理解story的?

在敏捷项目管理里面,会把每个任务按照一个task来看,那么这个task也可以叫story,具体指的就是任务有开始有结束。可以安排很多的task,每个task具体到story。

28、你是怎么理解探索性测试的?

根据自己的主观意愿来产品进行随机的,无目的性的来测试产品,目的是发现产品中可能存在的其他问题。

29、描述一下bug完整的生命周期(bug的流程)。

1)分析问题后提交问题给具体的开发人员

2)开发人员核对问题后,如果是问题,进行修改

3)开发把修改后的问题反馈给测试,测试这边验证,如果通过,就关闭问题

4)开发人员核对问题不是问题,反馈给测试,拒绝修改,测试这边核对不是问题,撤销该问题

5)开发把修改后的问题反馈给测试,测试这边验证还是没通过,再次反馈给测试。

30、编写测试用例的要素是什么,编写时要注意什么?

①⽤例ID;②⽤例名称;③测试⽬的;④测试级别;⑤参考信息;⑥测试环境;⑦前提条件;⑧测试步骤;⑨预期结果;⑩设计⼈员。

编写用例是要注意操作步骤清晰,通俗易懂,让其他人能看得懂。

31、怎么理解黑合测试,白盒测试?(测试策略有哪些?)

黑盒测试:把测试的对象看成是一个黑色的盒子的,看不到里面内部的结构,是对软件的一种功能性的测试。

白盒测试:就是把测试的对象看成是一个透明的盒子,能够看见被测软件的内部结构,是单元测试的一种形式,是针对程序的内部代码的一种测试形式。

32、测试按阶段划分,主要分为那几个阶段,在集成测试阶段需要注意什么?

单元测试、集成测试、系统测试、验收测试;集成测试的核心API测试,也就是接口测试。

33、怎么理解等价类和边界值?

等价类:把输入的数据可以分为有效的数据和无效的数据。测试一个产品,需要考虑它的正确场景,也需要考虑它的异常场景。

边界值:边界值测试用例是针对等价类测试用例方法的补充,因为等价类测试用例的方法只考虑到了输入数据的有效数据和无效数据,但是没有考虑到边界的情况。

34、列举常用的测试用例设计方法,请结合具体的产品说明它的使用。

1)等价类:针对被测对象的输入数据分为有效数据和无效数据,是功能测试的一种测试用例设计方法。如电话号码,那么有效数据就是 符合运营商电话号码的规则,无效就是不符合,如连续的11个同样的数字以及非11的数字。

2)边界值 :边界值是针对等价类测试用例方法的补充,如电话号码,需要考虑到11位,以及12位,和0位,也就是边界的情况。

3)判定表驱动分析法:列出被测对象可能存在的不同条件,如招聘类网站筛选出的结果排序,可能会存在多个条件来筛选出结果,如年限,薪资,地区等等,需要先列出来。

4)因果图 :在判定表的基础上,根据被测对象列出的条件,来使用排列组合的方式来验证各个不同条件下(并且以及或者关系)程序的结果情况。

5)正交实验分解法 :在因果图的基础上,使用排列组合下来的测试用例个数是非常多,导致测试用例的个数是非常多的,那么使用正交实验分解法可以优化,测试用例的个数,选择有代表性的数据来进行测试,比如招聘网站搜索互联网岗位时,筛选条件,选择城市时,可选择热门的城市如:北京、上海、广州、深圳、杭州、西安等城市。

6)场景设计法 主要考虑的是一个产品的完整的业务流程,从输入流开始一直到输出流,比如淘宝,从一个商品上架一直到商品的出售。

7)错误推测法 针对被测产品的非功能性的测试用例,主要使用探索性测试的方法,来验证被测产品可能存在问题,举例如下:

①在波浪式的交互过程中,一直往下滑动,可能会出现浏览器的卡死;

②在列表中翻页可能也会存在浏览器的卡死;

③Java语言编写的应用程序,大概率可能存在内存泄露(Java.lang.OutOfMemory,简称:OOM);

④一码通,对该应用程序进行大量的扫描二维码并且一直在进行扫描,那么很有可能存在扫描二维码后出现不了结果或者是导致结果一直加载中。

8)功能图分析法 :针对程序非功能性的测试,主要考虑的是被测程序的内部结构代码的测试。主要用于白盒测试,例如对学生成绩60-70分进行评级,那么针对60分的处理可以用到功能图分析法。

35、如果是一个水杯,请设计它的测试用例,你会怎么测试它?

1)功能测试:主要关注水杯基本功能:   

✨水杯是否可以正常装水   

✨水杯是否可以正常喝水   

✨水杯是否有盖子,盖子是否可以正常盖住   

✨水杯是否有保温功能,保温功能是否正常保温   

✨水杯是否会漏水,盖住盖子拧紧后是否会漏水

2)界面测试:主要关注水杯外观、颜色、设计等方面:   

✨外观是否完整   

✨外观是否舒适   

✨颜色搭配及使用是否让人感到舒适   

✨杯子外观大小是否适中   

✨杯子是否有图案,图案是否易磨损

3)易用性测试:主要关注水杯使用是否方便:   

✨ 水杯喝水时否方便   

✨水杯拿起放下是否方便,这里会衍生到水杯形状的测试   

✨水杯装水是否方便   

✨水杯携带是否方方便   

✨水杯是否有防滑功能   

✨水杯装有低温或者高温水时,是否会让手感到不适

4)性能测试:   

✨水杯装满水时,是否会漏出来   

✨水杯最大使用次数   

✨水杯的保温性是否达到要求   

✨水杯的耐寒性是否达到要求   

✨水杯的耐热性是否达到要求  

✨水杯掉落时,是否可以正常使用   

✨水杯长时间放置时,是否会发生泄露

5)兼容性测试:主要关注水杯是否可以装其他液体,如果汁、汽油、酒精等

6)可移植性测试:主要关注水杯放置环境等   

✨将水杯放在常温环境中,使用是否正常   

✨将水杯放在零下的环境中,使用是否正常   

✨将水杯放在高于正常温度的环境中,使用是否正常

7)安全性测试:主要关注水杯外观和各种异常条件下是否释放有毒物质等   

✨当水杯装满热水时,水杯是否会烫手   

✨当水杯装上水后,是否会产生有毒物质   

✨把水杯放在零下环境时,是否会产生有毒物质   

✨把水杯放在高温环境时,是否会产生有毒物质

36、测试计划你是怎么写的(测试计划的内容)

制定测试策略(也就是说思考一下采取何种技术手段来测试),然后进行资源安排,包括人力资源和环境资源,接下来进行进度安排,针对测试的边界(范围),给每个story完成任务的具体时间范围,需要精确到小时(每个任务具体开始的时间和具体结束的时间),还有发布标准(往往是主观的,大家都是认可的),最后是风险控制,考虑测试过程出现的风险(包括风险描述、负责人和跟踪人)。

37、你是怎么编写测试报告的?(测试报告的内容)

测试概述:版本,测试时间,测试参与人,备注

新功能测试结果:本次迭代新功能测试的结果(只有一个结果就是通过/pass)

系统已有功能测试结果

系统核心流程测试结果

缺陷分析(总共有多少个BUG,解决了多少个,解决率是多少,未解决多少个)

测试风险分析

测试结果

38、如果转测延迟,你怎么处理?

每天和产品经理和测试负责人反馈进度,注明开发转测延迟, 协调产品和他相关Leader,考虑解决办法。

39、公司开发转测试的依据是什么?

1)产品功能实现;2)冒烟测试通过

40、怎么理解冒烟测试?

开发把编写好的程序转给测试的时候,程序首先需要做的是针对转测的程序进行正常流程的测试,这个过程叫冒烟测试。针对被测程序的正常流程的测试,目的是验证程序正常流程可以执行通的情况下继续测试被测程序的其他功能。

41、怎么理解回归测试?

1)测试阶段,针对昨天的提交的BUG进行回归测试(对象是BUG)

2)上线前开发把代码合并后,进行一次系统的测试(对象是之前功能加新的功能)

3)测试阶段,需要针对系统已有功能进行的测试(对象是之前的功能)

4)上线后,针对系统所有功能的测试(对象是之前功能加新的功能)

42、你怎么看待加班?

项目业务繁忙需要加班的时候,偶尔加班是可以理解的,只要不是无理由加班我都能接受,当然我能做的就是提高工作效率,避免不必要的加班。再问一句,加班有加班费吗?

43、提交BUG你一般是怎么提交的(注意事项)

1)BUG步骤一定要具备可操作性(操作步骤要清晰,通俗易懂)

2)提交的BUG最好有错误的截图信息以及日志信息

44、BUG的级别你怎么理解?

致命:系统崩溃、数据丢失、数据毁坏、安全性被破坏。

✨严重:操作性错误、结果错误、功能遗漏。(一般指逻辑问题和影响流程功能问题)

✨⼀般:⼩问题、拼写错误、UI布局、罕⻅错误。(一般指页面交互 浏览器兼容性、错误提示信息不合理的问题)

建议:对产品的改进建议。

45、如果一个任务实际5天,但是我给你安排3天,这个时候你会怎么办?

1)拿到任务,先对任务进行拆分,然后每个任务根据自己的能力以及实际情况分配时间->任务的计划

2)约上你的领导,给他详细的说明为什么不是3天,而是4天。

46、针对淘宝购物车请列举出测试点?

针对以下5个维度考虑:功能性、非功能性、性能、兼容性、场景。

功能性:1)基本功能:

①购物车商品排序:按添加购物车的时间倒序。

②购物车页⾯的链接是否都能正确跳转。

③购物车店铺的名称、商品的名称、商品数量、继续增加数量是否正确。

④添加商品操作:添加同⼀种商品、添加不同商品、添加商品数量是否有限制。

⑤删除商品操作:能否通过滑动和勾选删除两种方式删除商品。

⑥修改商品信息:能够通过下拉选择修改选择商品的信息(比如颜色、尺码等)

⑦下单:单件商品下单、同⼀店铺多个商品下单、不同店铺多个商品下单:商品总额、份数等信息正确。下单后进⼊订单确认页⾯,页⾯的信息是否正确等。

⑧没有选择商品的时候,下单按钮应该是置灰不可操作的。

⑨下单使⽤优惠券,

⑩失效商品是否可操作,状态是否正确。

2)业务功能 :

①⽤户未登录时,添加商品到购物车,操作下单操作:有没有提⽰要登录、登录后添加的商品是否还在 。

②商品价格更新,⽐如定时活动打折等情况,已经添加购物车的商品价格也会同时更新

③同⼀账号不同设备登录,添加商品,购物车⾥⾯的商品能否

非功能性:界面性:验证购物车界面的美观,排版和是否有错别字等。

性能:添加购物车的时长、进⼊购物车页⾯的时长、下单等待的时长等待。

兼容性:不同浏览器(包括edge、chrome、firefox等)、不同⼿机品牌(华为、小米、苹果等)。

场景:从输入到输出一个完整的流程测试:加入商品到购物车,并进入购物车,可以选择商品提交订单,跳转到订单页面。

47、在公司你是怎么评审测试用例的?

1)自己编写完测试用例后,预定会议室,同时和大家约这个开会的时间是否都能够参加

2)到约定的时间,组织相关的人到会议室(那么这个时候会议的主持人就是你自己,会议的气氛以及氛围营造都是你自己来控制的)

3)开始时候的评审,你给大家描述每个测试点,大家都在听

  A、当大家没有问题的时候,可能会回应你,也可能不会

  B、当你描述的过程中,如果那个有问题,别人会立刻提出来,会议主持人需要把别人提出的问题立刻记录下

4)评审结束,做最后的总结。

48、你怎么理解验收测试?你们之前的验收测试流程是怎样的?

测试在周三下午测试完成,发送邮件让产品经理进行验收测试,产品经理会在周三下午以及周四的早上进行验收测试, 验收测试完成后会回复邮件,反馈本次验收测试的。

49、如果你负责的产品上线后有bug,你第一时间怎么做?

1)先在测试环境验证问题是否存在(排查是开发的责任还是测试的责任)

2)测试环境验证问题存在,那么就说明测试环境测试这边没测试出来,那么在群里面反馈给大家,相关人员评估今天晚上上线是否继续,如果上线,在第二天通过hotfix紧急修复,发布版本。

3)测试环境验证问题不存在,也需要反馈出来,下一步@开发,让开发检查各个中间件(RabbitMQ,Kafka,Redis等)的配置参数以及其他的配置

4)开发在3的基础上更新代码解决问题后,测试协助开发验证,然后把验证的结果反馈出来

50、如果你的直属主管一直很为难你,你会怎么处理二者之间的关系?

在上班时间和领导约个时间谈一下,找一下领导为难自己的原因是什么,如果是工作做得不到位引起引导的不满,要及时承认自己问题,向领导表达自己的态度,保证自己在之后的工作中会弥补不足,争取更好。

51、描述下你们一个迭代多少时间,这期间你的工作是怎么安排的?你们团队是多少人?

第一周

周一:熟悉需求文档以及参与需求的评审,和拆分任务;

周二:继续熟悉需求,编写测试用例;

周三:继续编写测试用例,评审测试用例,以及完善测试用例;

周四:编写自动化测试代码(学习/应用);

周五:继续编写自动化测试代码,开发转测后,进行冒烟测试验证。

第二周

周一:测试被转测试的产品 ;

周二:继续测试,以及验证回归问题(Issue);

周三:继续测试,以及进行验收测试;

周四:编写测试报告,做最后的探索性测试,准备上线前的资料,以及晚上上线后的回归测试验证;

周五:参加项目迭代复盘会议,以及针对本地迭代进行总结,准备下一个迭代的工作内容。

人员结构: PM(项目经理):1人

     开发:4-5人

     前端:1-2人

     测试:3-4人

     产品经理:1 人

     共计13人

52、你怎么理解风险控制?

当风险存在时,需要及时的把风险反馈给我的leader以及相关pm,然后一起沟通解决。

53、你印象最深刻的bug是什么?

内存泄漏、支付回调。

54、你期望薪资是多少?

我期待的薪资是15k。当然,我相信贵公司会根据我的工作能力、工作经验给出一个客观、合理的薪酬。

55、我注意到你说的,你有遗留的几个bug,但是测试结论又是测试通过,可以上线,所以我很不理解,你详细的解释下。

1、首先不是每个版本所有的BUG都是需要解决的,这在每个公司都存在这个情况

2、我们之前针对遗留的BUG,测试这边会叫上相关的人(pm,pmo,cto,测试经理,项目内部相关的人)进行讨论评估,针对这个遗留的bug在下个版本进行专门的解决。

56、你的测试计划中开始测试的时间的依据是什么?

测试开始的时间是开发转测的时间,比如在测试计划中安排的测试时间开始日期。

57、我刚才注意到你说的BUG,步骤很清晰,有日志以及截图,我想问的是这个时候开发还是不承认?你会怎么办?

首先我会分析开发不承认的原因,检查提交的日志和截图是否完整和正确,比如日志是否有上下文。