理论

测试基础理论:

1、bug完整的生命周期

测试发现问题提交BUG给开发,开发核对是BUG,进行修改,修改完后发给测试,测试进行回归测试没问题后,关闭BUG

测试发现问题提交BUG给开发,开发核对是BUG,进行修改,修改完后发给测试,测试进行回归测试后,发现还有问题,继续提交BUG

测试发现问题提交BUG给开发,开发核对不是BUG,测试这边进行核对发现还是有问题,继续提交BUG给开发并携带操作步骤,错误截图,错误日志的上下文。

测试发现问题提交BUG给开发,开发核对不是BUG,测试这边进行核对发现确实没有问题,测试这边关闭BUG

2、编写测试用例的要素是什么?

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

工作中我们一般聚焦于用例名称,前提条件,测试步骤和预期结果这几个要素

3、怎么理解黑盒测试,白盒测试

黑盒测试:就是把被测系统放到黑色的盒子,看不见里面的结构,主要是对软件的功能测试

白盒测试:就是把被测系统放在一个白色透明的盒子里,能看到里面的结果,是单元测试的一种,主要是对程序内部代码的一种测试的形式

4、测试按阶段划分,主要分为那几个阶段

单元测试:最小离度的测试,主要用于白盒测试

集成测试:把单个测试的模块集成到一块来测试,来验证模块与模块之间的功能性,主要是测试模块接口有关的问题

系统测试:主要测试的是系统整体性的功能,来验证是否符合需求文档

验收测试:也可以叫交付测试,测试的最后一个环节

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

等价类:意思是输入数据的有效性和无效性

边界值:是对等价类的补充等价类只考虑到了数据的有效性和无效性,没有考虑到边界的问题

6、请描述一个完整的测试流程

产品经理发送需求评审会议,进行需求评审,开发这边编写代码实现需求,同时测试这边编写测试计划和测试用例,测试这边编写测试用例完后进行用例评审,开发这边写完代码后进行转测,测试这边进行冒烟测试,冒烟测试没问题后进入正常流程测试,测试结束后,进行验收测试,验收测试结束后编写测试报告,准备上线

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

等价类:意思是对输入数据的有效性和无效性

输入电话号码,有效性是输入正常的运营商的电话号码,无效性是输入11个同样的数字

边界值:对等价类的补充,

电话号码最长只能是11位

判定表驱动分析法:列出被测对象可能存在的不同条件,

招聘网站会有多个条件来筛选信息

因果图:根据判定表驱动分析法列出的条件来使用排列组合的方式来验证不同条件下程序的结果情况

招聘网站各个筛选条件排列组合的结果

正交实验法:因果图的基础上,因为因果图方法导致测试用例太多,所以正交实验就是选取具有代表性的来进行测试

招聘网站选择具有代表的条件来进行测试

场景设计方法:考虑的是一个产品的完整测试流程,

淘宝 产品上架到售出

错误推测法:产品非功能的测试,使用到的是探索性测试方法,来验证产品可能会发生的问题

淘宝页面波浪式操作,一直往下滑动会不会卡死

功能图分析法:程序非功能的测试,主要是程序内部代码的测试

8、测试用例的要素有哪些?

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

9、请描述一下你理解的测试流程

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

我会从功能测试,兼容性测试,性能测试,安全性测试这几个方面去写测试用例

  1. 功能测试: 主要关注水杯基本功能 1.1 水杯是否可以正常装水 1.2 水杯是否可以正常喝水 1.3 水杯是否有盖子,盖子是否可以正常盖住 1.4 水杯是否有保温功能,保温功能是否正常保温 1.5 水杯是否会漏水,盖住盖子拧紧后是否会漏水

  2. 性能测试: 2.1 水杯装满水时,是否会露出来 2.2 水杯最大使用次数 2.3 水杯的保温性是否达到要求 2.4 水杯的耐寒性是否达到要求 2.5 水杯的耐热性是否达到要求 2.6 水杯掉落时时,是否可以正常使用 2.7 水杯长时间放置时,是否会发生泄露

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

  4. 安全性测试: 主要关注水杯外观和各种异常条件下是否释放有毒物质等 4.1 当水杯装满热水时,水杯是否会烫手 4.2 当水杯装上水后,是否会产生有毒物质 4.3 把水杯放在零下环境时,是否会产生有毒物质 4.4 把水杯放在高温环境时,是否会产生有毒物质

正常功能 异常功能 兼容性 性能测试 稳定性 场景

1.界面测试:是否美观; 2.功能测试:能否装水,能否喝水,会不会漏水; 3.安全测试:水、瓶子是否含有有毒物质; 4.易用性:喝水是否方便,有无防滑设计,是否烫手; 5.兼容测试:能否装其他液体,酒精果汁汽油等; 6.压力测试:放24小时是否泄漏

11、测试计划你是怎么写的

测试计划是一个项目的领导性纲领,主要有概述(参与人员及周期)测试任务(把具体任务分到具体人上,即开始时间和结束时间)风险控制,(依赖关系和资源)

列出功能点 拆分任务

12、测试报告你是怎么写的

试报告需要包含的有本次参与的人员以及测试的周期,本次迭代测试的结果,对系统已有功能的测试结果,核心流程测试的结果,bug的情况(总共有多少bug,解决了多少bug,如果有遗留的bug我会和管理层进行沟通),以及测试风险,最后将测试的结论描述出来就可以了。

本次迭代所有功能 系统已有 系统核心流程 本次迭代问题解决情况 测试结果

bug遗留 有 解决思路 和开发沟通 说没影响 和产品经理 pm 反馈 在测试报告风险中也列出来

13、如果提交的BUG开发不承认,你怎么办?

首先我会再次测试一遍,看是否真的存在问题,如果真的存在,然后我会再次提交BUG,再次提交的时候我会把测试的步骤,错误的截图以及错误日志的上下文让BUG看起来通俗易懂,和开发友好交流

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

我会及时上报上级,让测试负责人去协调

早会会提出来 看日期是否往后推迟一下

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

1.转测这个功能逻辑以实现

2.冒烟测试通过

16、怎么理解冒烟测试?

对转测程序正常流程的测试

17、怎么理解回归测试?

测似阶段 对昨天提交的BUG开发修改后的测试

上线前代码合并后系统测试

测试阶段 对已有功能的测试

上线后 对所有功能的测试

18、你怎么看待加班?

看当前工作是否需要加班,避免无意义加班

19、提交BUG你一般是怎么提交的

1.BUG的步骤具备可操作性,通俗易懂

2.提交BUG最好有错误截图和日志信息

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

BUG一般分为奔溃,严重,一般和建议

奔溃:系统奔溃,数据毁坏,数据丢失,安全性被破坏

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

一般:小问题,ui布局,罕见错误,拼写错误

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

21、简述下对回归测试的理解,以及回归测试时候需要考虑的因素

测试阶段对昨天BUG开发修改的后的测试

上线之前系统性的测试

测试阶段对已有功能测试

上线后对多有功能的测试

考虑因素

代码合并的时候出现代码冲突,导致之前产品功能的缺失

可能由于不同的环境(测试环境,线上环境),而导致新的bug的出现;

22、列举出常用的测试用例设计方法,请举例说明每个测试用例设计方法的使用

等价类

边界值

判定表驱动法

因果图

正交实验

场景设计

错误推测法

功能图分析法

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

首先我会拆分任务,根据个人能力划分每个任务所需要的时间,再约领导说明为什么3天不够的原因

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

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

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

2.开始评审,描述每个测试点,描述过程中,如果有问题,需要把别人的问题记录下来

3.评审结束,修改后的发给相关人员

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

测试结束后,我们会发送邮件给产品经理,产品经理这边会进行验收测试,产品经理验收测试完完成后,会回复邮件说明验收测试以完成,下来测试这边就是编写测试报告,准备上线

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

1.在测试环境上进行排查(查看是开发责任,还是测试责任)

2.测试环境验证问题存在,那么就说明测试环境测试这边没有测试出来,下来在群里反馈给大家,然后再次评估晚上要不要上线,如果要上线,第二天需不需要发一个hotfix紧急版本

3.测试环境问题不存在,线上环境有问题,和开发也与要反馈粗来,@开发 让开发看一下是不是有什么问题,

4.开发处理完问题后,测试协助验证问题,最后把结果反馈在群里

你负责的产品上线前出问题你是怎么处理的?

和开发一起评估这个问题是否可以解决,如果不能,将相关的问题反馈给测试主管,看是否可以上线,再下来反思一下,自己当时为什么没能定位出bug。

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

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

一般一个迭代是两周,我们团队有13人 项目经理1个 产品经理1个 前端 2个 开发5个 测试4个

第一周:

周一 熟悉需求 需求评审 拆分任务

周二 熟悉需求 编写测试计划

周三 编写测试用例,用例评审

周四 编写自动化代码

周五 编写自动化代码 开发转测后进行冒烟测试

第二周:

周一 测试转测产品

周二 继续测试,做回归测试

周三 继续测试 测试完成后进行验收测试

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

周五 参加项目迭代复盘会议 针对对本次迭代的总结 准备下次迭代的工作内容

30、怎么理解story?

story一个故事,敏捷里面的术语,有开始有结束即有时间限制

31、详细的描述下测试计划和测试报告是那个阶段写,里面你具体写哪些内容的

测试计划:需求评审完编写测试计划 同步发给相关人员对一下

测试报告:验收测试后编写测试报告 发邮件给产品经理

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

必须是客观事实 我测试的模块依赖开发 我们会造数据,

当有风险的时候,我会及时上报给我的上级,即pm相关人员,一起沟通解决风险

33、你们一般多久一个迭代?你是怎么规划每天的工作任务的?

转测之后几轮测试?

三轮测试 1.开发转测后我们针对系统所有功能的测试目标是发现90%多的错误

2.开发修改完后在进行测试还一遍 把所有的BUG关闭

3.开发合并代码后,最后进行一遍系统的测试

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

内存泄漏

支付回调

35、你期望薪资是多少?

7k+ 根据面试结果给个薪资结果

上线依据是什么?

1.本次迭代所有功能都已实现并且测试都已通过

2.系统已有功能测试通过

3.本次迭代问题都已解决

4.本次迭代验收测试都已通过

5.如果有性能测试 性能测试也要通过

这几个都通过情况下就可以上线了'

36.你负责的项目上线前出现问题怎么办?

和开发一起评估这个问题是否可以解决,如果不能,将相关的问题反馈给测试主管,看是否可以上线,再下来反思一下,自己当时为什么没能定位出bug。

你是怎么保证产品的质量的?

a、对需求的熟悉度,我会梳理清楚需求文档中存在的所有业务逻辑,以及找产品,开发把自己理解不是很透彻或者是理解存在歧义的需求,都会和他们进行讨论,通过这样的方式,让需求理解上和开发产品都理解一致,因为它是设计测试用例以及测试过程中逻辑沟通的唯一依据。

b、测试用例的覆盖度,以下4个维度:产品的正常业务逻辑,正常测试点设计;异常逻辑, 脏数据程序的这部分容错性;本次迭代关联之前的业务模块和之前团队关联的业务模块都会考虑;产品的兼容性、易用性、稳定性以及性能等方面都会考虑进去。

c、通过评审测试用例,让多个部门坐在一起来讨论设计的用例是否符合需求。

d、交叉测试(探索)和验收测试来保障产品质量。

e、技术手段,ui、接口自动化,这样可以对产品有一个更加全面的把控。

回归测试考虑的因素?

代码合并过程中,会不会导致之前产品功能的缺失和代码冲突;

可能由于不同的环境(测试环境,线上环境),而导致新的bug的出现;

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

你是怎么保证产品的覆盖点?

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

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

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

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

5)最后,设计测试点需要考虑测试对象被依赖的测试点的场景,主要使用到的测试用例方法是场景设计方法。

 

 

你负责的产品上线前出问题你是怎么处理的?

和开发一起评估这个问题是否可以解决,如果不能,将相关的问题反馈给测试主管,看是否可以上线,再下来反思一下,自己当时为什么没能定位出bug。

回归测试考虑的因素?

代码合并过程中,会不会导致之前产品功能的缺失和代码冲突;

可能由于不同的环境(测试环境,线上环境),而导致新的bug的出现;

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

你是如何保障质量?(如何保障产品质量?)

以下5个维度:

a、对需求的熟悉度,我会梳理清楚需求文档中存在的所有业务逻辑,以及找产品,开发把自己理解不是很透彻或者是理解存在歧义的需求,都会和他们进行讨论,通过这样的方式,让需求理解上和开发产品都理解一致,因为它是设计测试用例以及测试过程中逻辑沟通的唯一依据。

b、测试用例的覆盖度,以下4个维度:产品的正常业务逻辑,正常测试点设计;异常逻辑, 脏数据程序的这部分容错性;本次迭代关联之前的业务模块和之前团队关联的业务模块都会考虑;产品的兼容性、易用性、稳定性以及性能等方面都会考虑进去。

c、通过评审测试用例,让多个部门坐在一起来讨论设计的用例是否符合需求。

d、交叉测试(探索)和验收测试来保障产品质量。

e、技术手段,ui、接口自动化,这样可以对产品有一个更加全面的把控。

 

面试题

你之前是怎么部署环境的?

我们之前部署环境都是由开发布置的,但是我说一下我i理解的部署环境的方式,

1,java语言为例,通过maven把SpringBoot的程序构建成war包,然后通过然后通过scp把它上传到Linux服务器,部署在tomcat下的webapps目录下启动tomcat,部署,然后在浏览器中访问,比如jenkins就是这样的一种方式

2,java为例 开发的是一个服务 通过maven把springBoot的程序的程序构建成jar。war 然后在Linux服务器通过命令来启动,具体命令是: java -jar .war java -jar .jar

3,通过docker的方式来部署环境,把开发写好的代码通过dockerfile文件构建成image 的镜像 然后启动这个镜像后是一个容器,那么环境也就部署好了

如果贵司是测试来部署环境的,这点您放心,我加入公司后,能够很快速的掌握这部分并且承担起这部分的任务

你是怎末来保障质量的?

我是通过这几个维度来保障的

1、对需求的熟悉度,我会梳理清楚需求文档中存在的所有业务逻辑,以及找产品,开发把自己理解不是很透彻或者是理解存在歧义的需求,都会和他们进行讨论,通过这样的方式,让需求理解上开发产品都理解一致,因为它是设计测试用例以及测试过程中逻辑沟通的唯一依据

2 测试用例的覆盖度 ,我会考虑以下几个维度

1.产品的正常流程的产品点的设计,以及异常逻辑 脏数据 容错性的处理、

2.本次迭代关联之前的业务逻辑,以及其他团队的业务逻辑和关联

3.产品的兼容性,易用性 稳定性,及兼容方面的测试点会考虑进去

3.通过评审的方式看一下有没有考虑进去

4 通过交叉测试 验收测试 来

5.通过技术手段 用自动化测试,接口测试 来看一下没有考虑到的维度

你之前写测试计划和测试报告吗?

会 我们是两周一个迭代都会写测试计划和测试报告

测试计划我们写

1.这个迭代的工作的工作内容

2.参与需求的评审,

3.编写测试用例以及评审

4.产品功能的测试

5测试报告的梳理,及上线

通过测试计划可以看出这个产品时候可以上线

测试报告我会写

1.本次迭代所有功能的测试结果

2.系统已有功能的测试结果

3,系统核心功能的测试结果

4,系统本次迭代所有bug的解决情况

5,如果有性能测试 那么就要加上性能测试的结果

6.本次迭代的测试结论

你是怎末理解水仙花数的?

你是怎末理解冒泡排序的?

1、列表每两个相邻的数,如果前面比后面大,则交互这两个数 2、一趟排序完成后,则无序区减少一个数,有序区增加一个数 ''' import random

def bubble_sort(li): '''时间复杂度:O(n*n)''' for i in range(len(li)-1): #标记位 exchange=False for j in range(len(li)-i-1): #如果是降序,那么就是>修改为<号 if li[j]>li[j+1]: li[j],li[j+1]=li[j+1],li[j] exchange=True #能够详细的展示出排序的过程 # print(li) if not exchange:break return li

if name == 'main': li=[random.randint(0,1000) for i in range(10)] print(bubble_sort(li=li))

给你一个产品你怎么测?

1.尽快融入团体,熟悉业务流程

2.梳理测试流程 把控各个的关键点 具体什么时候转测 什么时候上线 如果有分线我会和我的leder沟通

3.产品质量的把控

你是怎末评估每个测试的时间点的?

1.根据每次迭代的难易度

2.以往的工作经验

可能会有问题我会和我的直属领导和pm对一下

如果给你三天时间给你测,你发现时间不够怎末办?

我会根据每个任务进行时间划分

如果还是要三天时间 我会表我的理由

如果时间多了 我会用剩下的时间去做探索性测试

你在工作中和同事发生冲突你会怎末办?

发生冲突我肯定有不对的,我会给他道歉 然后和同事之间说清楚,下次遇到克制自己

1、你是如何保证产品质量的

我是通过这几个维度来保障的

1、对需求的熟悉度,我会梳理清楚需求文档中存在的所有业务逻辑,以及找产品,开发把自己理解不是很透彻或者是理解存在歧义的需求,都会和他们进行讨论,通过这样的方式,让需求理解上开发产品都理解一致,因为它是设计测试用例以及测试过程中逻辑沟通的唯一依据

2 测试用例的覆盖度 ,我会考虑以下几个维度

1.产品的正常流程的产品点的设计,以及异常逻辑 脏数据 容错性的处理、

2.本次迭代关联之前的业务逻辑,以及其他团队的业务逻辑和关联

3.产品的兼容性,易用性 稳定性,及兼容方面的测试点会考虑进去

3.通过评审的方式看一下有没有考虑进去

4 通过交叉测试 验收测试 来确定

5.通过技术手段 用自动化测试,接口测试 来看一下没有考虑到的维度

2、之前公司多少人 多少开发 多少测试 和你对接的开发是多少人?

 

3、用什么样的监控

针对Java程序,使用的监控工具是jvisualvm

针对系统的资源(CPU,内存,平均负载),使用的监控工具是prometheus

针对jmeter性能测试过程中的数据(响应时间,吞吐量),那么会把数据写到influxdb里面,最后展示在grafana的平台中

4、为什么你的接口要用这么多的工具

charles主要使用它来抓取网络请求 在工作里面,和开发这边的联调以及验证一般的API,使用的是postman 接口自动化测试最初开始使用的是jmerer的测试工具,后面我的直属领导要求使用代码级别来做借口自动化测试,也就使用了requests

5、如何做多接口的

 

6、公司架构

技术 研发 开发测试产品

我们公司产品使用的是微服务架构,微服务就是根据业务形态会拆分成一个微小的服务,每个微服务都有自己独立的数据库,微服务中,服务与服务之间的通信会采用轻量级的REST API和gRPC的协议来进行通信

7、项目中哪些是做了接口测试 在整个过程中你印象最深的bug是什么

内存泄露,支付回调,多支付请求

8、linux如何部署环境的

 

9、你对于如何单独负责一个产品是如何看待的

 

10、匿名函数

lambda

11、水仙话术

 

12、冒泡排序

1、列表每两个相邻的数,如果前面比后面大,则交互这两个数 2、一趟排序完成后,则无序区减少一个数,有序区增加一个数 ''' import random

def bubble_sort(li): '''时间复杂度:O(n*n)''' for i in range(len(li)-1): #标记位 exchange=False for j in range(len(li)-i-1): #如果是降序,那么就是>修改为<号 if li[j]>li[j+1]: li[j],li[j+1]=li[j+1],li[j] exchange=True #能够详细的展示出排序的过程 # print(li) if not exchange:break return li

13、测试时遇到不可复现的BUG如何处理

我测试10点后边怎末测都不出来

到服务的查看10点日志 用服务的日志和现象交给开发

我会给自己提交bug 等再次出现的时候再提及给开发

14、怎么编写用例才能覆盖所有的需求

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

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

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

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

5)最后,设计测试点需要考测试对象被依赖的测试点的场景,主要使用到的测试用例方法是场景设计方法。

15、简单介绍下装饰器

 

 

posted @ 2022-09-19 19:38  刘乐乐liu  阅读(55)  评论(0)    收藏  举报