理论面试题

面试题：

1，bug完整的生命周期（过程）

流程：

1、风险问题后提交问题给具体的开发人员

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

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

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

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

2，编写测试用例的要素

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

但是在实际工作中，我们编写测试用例的时候，一般主要聚焦于测试名称、前提条件、测试步骤和预期结果这四个要素。

3，怎么理解黑盒测试，白盒测试

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

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

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

软件测试可分为

1，单元测试：是针对程序最小离度的测试，他主要应用于白盒测试，针对程序方法或者函数的测试。

2，集成测试：是把单个模块的程序集成到一起后测试，来验证各个模块集成后模块与模块之间的功能性，集成测试主要是通过测试发现与模块接口有关的问题。

3，系统测试：系统测试是基于需求文档的黑盒类测试，主要的目的是验证被测程序的整体性的功能。它是整个测试阶段中最重要的环节，因为系统测试前单元测试盒集成测试都已完成，这时的测试是针对整个产品系统的测试，能够验证程序满足需求文档的要求。

4，验收测试：验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。

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

等价类 是针对被测对象的输入数据分为有效数据和无效数据

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

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

 

 

1、评审需求文档

2、开发这边编写代码来实现需求，测试这边编写测试计划和测试用例

3、测试这边编写完测试用例后，进行测试用例的评审（评审参与人：产品经理，开发，测试，项目经理等）

4、开发完成后，进行转测，测试这边进行冒烟测试，冒烟测试通过后，进入到测试阶段

5、测试阶段测试完成后，会向产品经理提交验收测试，验收测试通过后我们会写测试报告，准备产品上线。

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

等价类

针对被测对象的输入数据分为有效数据和无效数据，是功能测试的一种测试用例设计方法。

 如电话号码，那么有效数据就是 符合运营商电话号码的规则，无效就是不符合，如连续的11个同样的数字以及非11的数字。

边界值

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

判定表驱动分析方法

列出被测对象可能存在的不同条件，如招聘类网站筛选出的结果排序，可能会存在多个条件来筛选出结果，如年限，薪资，地区等等，需要先列出来

因果图

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

正交实验分解法

在因果图的基础上，使用排列组合下来的测试用例个数是非常多，导致测试用例的个数是非常多的，那么使用正交实验分解法可以优化 测试用例的个数，选择有代表性的数据来进行测试

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

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

淘宝页面在波浪式的交互过程中，一直往下滑动，可能会出现浏览器的卡死

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

功能图分析⽅法针对程序非功能性的测试，主要考虑的是被测程序的内部结构代码的测试

8，如果给你一个水杯，请设计他的测试用例，你会怎么测试它？

功能性

1，水杯是否可以正常装水

2，水杯是否可以正常喝水

3，水杯是否有盖子，盖子是否可以正常盖住

4，水杯是否有保温功能，保，温功能是否正常保温

5，水杯是否会漏水，盖住盖子拧紧后是否会漏水

非功能性

1，外观是否完整

2，杯子外观大小是否适中

3，杯子是否有图案，图案是否易磨损

性能测试

1，水杯装满水时，是否会漏出来

2，水杯最大使用次数

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

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

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

6，水杯长时间放置时，是否会发生泄露

兼容性测试

水杯是否可以装其他液体，如果汁、汽油、酒精等

场景

1，将水杯放在常温环境中，使用是否正常

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

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

9，测试计划你是怎么写的、

软件测试计划是指导测试过程的纲领性文件，包含了项目背景、测试策略、测试方法、测试范围、组织形式、测试对象、测试配置、测试周期、测试资源、风险分析等内容

三个方面，测试概述（参与人员，及周期）测试任务（把具体任务分到具体人员即完成开始时间和结束时间） 风险控制（依赖关系和资源）

10，测试报告你是怎么写的

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

1、测试概述：版本，测试时间，测试参与人，备注

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

3、系统已有功能测试结果

4、系统核心流程测试结果

5、缺陷分析（总共有多少个BUG，解决了多少个，解决率是多少，未解决多少个）

6、测试风险分析

7、测试结果

11，如果提交的bug开发不承认，你该怎么办？

首先我会再次检查问题是否存在，如果问题存在，那么提交的BUG步骤一定要非常清晰，通俗易懂，同时要在提交的BUG里面附加上错误信息的日志上下文，以及尽可能的提供错误的截图信息，调整后，可以再找开发，比如打扰下，麻烦看看这个问题，是否是我的姿势不对等等，总之友好沟通，让对方来解决问题

12，如果转测延迟，你会怎么处理

及时反馈上级，让测试负责人去协调，

13，那么公司开发转测试的依据是什么

1，实现所有功能测试通过

2，冒烟测试通过

14，怎么理解冒烟测试

针对转测的程序进行正常流程的测试

15，怎么理解回归测试

1.测试阶段,对昨天提交的bug进行回归测试（对象是bug）

2.上线前开发把代码合并后，净现一次系统测试（对象是之前功能加新的功能）

3.测试阶段，需要正对系统已有的功能进行测试（对象是之前的功能）

4.上线后，针对系统所有功能的测试（对象是之前功能加新的功能）

16，你怎么看待加班

看当前工作任务是否需要加班，避免无意义的加班

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

1、BUG步骤一定要具备可操作性（操作步骤要清晰，通俗易懂）

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

18、BUG的级别你怎么理解？

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

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

⼀般：小问题、拼写错误、UI布局、罕见错误。

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

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

1.测试阶段,对昨天提交的bug进行回归测试（对象是bug）

2.上线前开发把代码合并后，净现一次系统测试（对象是之前功能加新的功能）

3.测试阶段，需要正对系统已有的功能进行测试（对象是之前的功能）

4.上线后，针对系统所有功能的测试（对象是之前功能加新的功能）

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

1，拿到任务，先拆分任务，然后每个任务你能根据自己的能力以及实际情况分配时间---------》 任务计划

2，约领导给他详细说明为什么三天完不成

22、针对淘宝购物车请列举出测试点？

功能性

1.是否有全选，全不选的功能

2.是否能删除商品，批量删除功能

3.每件商品是否是有对应商品图片展示

4.失效的商品是否还会出现在购物车的历史纪录中

非功能性

1.页面布局是否合理

2.界面是否有错别字

3.文字是否清晰

性能测试

1，打开购物车到购物车界面显示响应时

2.用户过多会不会造成服务器崩溃

3.点击结算按钮后，跳转到确认订单页面的响应时间

兼容性测试

1.购物车在不同手机系统中是否兼容（ios 和 安卓）

2.购物车在不同 pc 端是否兼容

3.购物车在不同浏览器是否兼容

4.购物车在不同分辨率下是否兼容

场景

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

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

2、开始评审，描述每个测试点，描述的过程中，如果有问题，需要把别人提出的问题立刻记录下

3、评审结束，做最后的总结

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

测试完成后，发送邮件给产品经理，产品经理这边会进行验收测试，产品经理这边验收测试完成后，会回复邮件说明验收测试已经完成，下来测试团队编写测试报告，准备产品的上线。

25、如果你负责的产品上线后有bug，你第一时间怎么做？

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

2、测试环境验证问题存在，那么就说明测试环境测试这边没测试出来，那么在群里面反馈给大家，然后再次评估今天晚上上线是否继续？要的话，是否第二天要发一个hotfix紧急版本

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

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

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

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

一般迭代是多久一次：2周

人员结构有哪些： PM（项目经理）：1 开发：4-5 前端：1-2 测试：3-4 产品经理：1    13

2周工作内容（一个迭代）：

第一周：

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

周二：继续熟悉需求，编写测试用例

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

周四：编写自动化测试代码（学习/应用）

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

第二周：

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

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

周三：继续测试，以及进行验收测试

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

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

28、怎么理解story?

story 敏捷里面的术语，任务的意思 有开始有结束 即有时间限制。

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

测试计划是在需求评审完之后写的

测试报告是验证测试通过后编写的

30、你怎么理解风险控制？

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

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

32、你测试过最难的bug是什么？

内存泄漏 OOM

支付回调

详细的描述下它的过程，以及你的排查思路？ 33、你期望薪资是多少？

我期望的工资是8k，当然你也可以根据我的技术，工作年限以及我现在面试的情况来定我的工资