测试面试总结

一、测试流程

  首先拿到需求开发和测试这边进行需求评审,之后开发这边设计评审技术方案开始编写代码实现需求,编写完正常运行后转测同时测试这边编写测试计划和方案根据需求点编写测试用例。编写出来后约产品经理、开发负责人、测试负责人评审用例。评审通过后等待开发转测,开发转测后进行冒烟测试,冒烟测试通过后进入测试阶段,通过测试把bug提交给开发,开发这边改良,改良后反馈给测试,测试通过后编写测试报告和探索性测试,约产品经理(PM)、开发、和测试负责人(leader)进行验收测试,验收测试后准备上线,上线后回归测试验证,最后进行复盘。

二、测试阶段:

  大概通过四个维度:(单元测试、集成测试、系统测试、验收测试)

    1.单元测试:是指对软件中最小可测试单元进行检查和验证。

    2.集成测试:在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成为子系统或系统,进行集成测试。也是一个接口测试

    3.系统测试:EndToEnd Test---》端到端的测试)包括恢复测试、安全测试、压力测试、健壮性测试。是对整个系统的测试。将硬件、软件、操作人员看作一个整体,来检验它是否有不符合系统说明书的地方。为了发现系统分析和设计中的错误。

    4.验收测试:在软件产品完成了单元测试集成测试系统测试之后,产品发布之前所进行的软件测试活动。

测试策略:(白盒测试、黑盒测试、灰盒测试)

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

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

  灰盒测试:它是介于黑盒测试与白盒测试中间,具体的来说就是测试开发工程师(测试工程师)能够看开发的代码,进行代码的走查,和参与开发代码的评审。

测试用里的要素:

  逻辑结构清晰,通俗易懂。

测试用例的方法:(大概有五个维度)

  1.功能测试

    等价类测试、边界值测试、因果图、正交实验分解法、判定表驱动分析法

  2.非功能测试

    错误推测法、功能分析图法

  3.场景

    场景设计方法

  4.性能测试

  5.兼容性测试

冒烟测试:开发转测后,对程序的正常流程进行测试。

1.等价类测试:

  把输入的数据可以分为有效的数据和无效的数据

2.边界值测试:

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

3.因果图测试:

  是根据输入的不同条件来根据排列组合来设计不同条件下的测试用例

4.正交实验分解法:

  因果图根据输入的N个不同条件组合下来导致测试用例的个数是呈指数级的增加,这样导致测试的资源(人力,时间资源)上根本无法满足测试的时间要求。那么这个时候只需要测试有代表性的数据。

5.判定表驱动分析方法:

  从多个输入条件组合的角度来满足测试的覆盖率要求,是黑盒测试方法中最严格、最有逻辑的测试方法

6.错误推测法:

  针对被测产品的非功能性的测试用例,主要使用探索性测试的方法,来验证被测产品可能存在问题

7.功能图分析法:

   针对程序非功能性的测试,主要考虑的是被测程序的内部结构代码的测试

8.场景测试方法:

  指的是针对一个系统从输入流开始一直到输出流的完整性的测试,主要考虑的是被测对象的业务流程,也就是各个不同场景方法的测试。

9.兼容性测试:

  主要是检查软件在不同的硬件、软件平台上是否可以正常的运行。

10.性能测试:

  通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。

11.探索性测试:

  强调测试人员的主观能动性,探索之前未发现的bug

12.回归测试:

  产品都已经测试完成了,在准备上线的情况下,针对产品进行第N次的测试。测试系统已有的功能和上线的新功能。

13.测试用例的组成元素(10个)

  用例ID;用例名称;测试目的;测试级别;参考信息;测试环境;前提条件;测试步骤;预期结果;设计人员;

14.测试用例元素的最核心的部分

  用例名称;前提条件;测试步骤;预期结果;

15.测试用例步骤:

  拿到测试需求 -> 分析需求(画思维导图) -> 编写⽤例 -> 划分⽤例优先级

16.你之前写了多少个测试用例?

  这个之前还真没有数过,我个人认为数这个没多大意义,更多应该考虑的是把测试的对象的测试点考虑周全

17.给开发提交的bug流程:

  把风险问题提交给开发,开发核对后如果是问题就修改,修改后反馈给测试,测试这边通过关闭问题。验证没通过继续更改反馈知道测试通过关闭问题。如果不是问题,反馈给测试,测试这边核对不是问题,撤销该问题。

18.bug级别:

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

  严重:操作性错误、结果错误、功能遗漏。

  ⼀般:⼩问题、拼写错误、页面交互、罕⻅错误。

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

19.缺陷的优先级:

  紧急:影响进⼀步测试,需要⽴即修复。

  ⾼:必须在版本发布前修复。

  中:必须要修复,不⼀定⻢上修复,可以讨论确定在某个时间节点修复好。

  低:对产品影响⽐较少,不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。

20.bug的要素:

  前提条件:

    首页可以访问

  测试步骤:

    在登录的手机号输入框里面输入了11111111111

    输入后就自动获取验证码

  实际结果:

    输入不规范的手机号码依然能够获取验证码

  期望结果:

    输入不规范的手机号码,不能自动获取手机验证码

21.bug的注意事项:

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

  提交的Bug最好有错误的截图信息以及日志信息。

22.团队的人员结构大概13个:

PM项目经理(1)、开发(5)、前端(2)测试(4)产品经理(1)

23.迭代:两周工作内容(一个迭代):

 第一周:

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

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

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

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

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

第二周:

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

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

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

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

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

24.验收测试流程:

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

25.风险控制

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

面试问题:

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

在测试环境中运行进行定位看是什么问题是否能正常运行,bug对产品的影响大不大,并上报测试经理。不大的话出一个hotbase补丁。

2、你测试过最难的bug是什么?详细的描述下它的过程,以及你的排查思路?

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

支付回调(钱扣了,状态:待支付!)

 

3、你期望薪资是多少?

 

7000,你也可以根据我这边的叙述、经验提出薪资。

 

 

 

 

  

  

posted @   LaraCroft  阅读(92)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· 易语言 —— 开山篇
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
点击右上角即可分享
微信分享提示