测试基础理论：面试
1、bug完整的生命周期/bug流程
- 情况1.测试过程中发现问题提交给开发，开发确认是问题，修改后我们验证通过，结束
- 情况2.开发拒绝，测试同意不是问题，关闭
- 情况3.开发拒绝，测试任然认为是问题，重新打开让开发修改，验证完成后结束。
流程：
1、风险问题后提交问题给具体的开发人员
2、开发人员核对问题后，如果是问题，进行修改
3、开发把修改后的问题反馈给测试，测试这边验证，如果通过。就关闭问题
4、开发人员核对问题不是问题，反馈给测试，拒绝修改，测试这边核对确实不是问题，撤销该问题
5、开发把修改后的问题反馈给测试，测试这边验证还是没通过，再次反馈给开发
2、编写测试用例的要素是什么？
- 共10个，⽤例ID；⽤例名称；测试⽬的；测试级别；参考信息；测试环境；前提条件；测试步骤；预期结果；设计⼈员
- 其中测试标题、测试步骤、测试前提条件、测试期望结果最重要
3、怎么理解黑合测试，白盒测试、灰盒测试
黑盒测试：测试对象看成黑色盒子，看不到内部结构，是对软件的一种功能性测试，即手工测试，是功能测试的一种形式
白盒测试：测试对象看成白色盒子，看得到内部结构，是针对程序内部代码的一种测试，是单元测试的一种形式
灰盒测试：介于黑白之间，测试工程师可以看开发的代码进行代码的走查和参与开发代码的评审
4、测试按阶段划分，主要分为那几个阶段
软件测试可分为
1，单元测试：是针对程序最小离度的测试，他主要应用于白盒测试，针对程序方法或者函数的测试。
2，集成测试：是把单个模块的程序集成到一起后测试，来验证各个模块集成后模块与模块之间的功能性，集成测试主要是通过测试发现与模块接口有关的问题。
3，系统测试：系统测试是基于需求文档的黑盒类测试，主要的目的是验证被测程序的整体性的功能。它是整个测试阶段中最重要的环节，因为系统测试前单元测试盒集成测试都已完成，这时的测试是针对整个产品系统的测试，能够验证程序满足需求文档的要求。
4，验收测试：验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。
5、怎么理解等价类和边界值
等价类 是针对被测对象的输入数据分为有效数据和无效数据
边界值是针对等价类测试用例方法的补充，因为等价类测试用例的方法只考虑到了输入数据的有效数据和无效数据，但是没有考虑到边界的情况。
6、请描述一个完整的测试流程
- 评审需求文档
- 开发这边编写代码来实现需求，测试这边编写测试计划和测试用例
- 测试这边编写完测试用例后，进行测试用例的评审（评审参与人：产品经理，开发，测试，项目经理等）
- 开发完成后，进行转测，测试这边进行冒烟测试，冒烟测试通过后，进入到测试阶段
- 测试阶段测试完成后，会向产品经理提交验收测试，验收测试通过后我们会写测试报告，准备产品上线
7、列举常用的测试用例设计方法，请结合具体的产品说明它的使用
1）等价类
针对被测对象的输入数据分为有效数据和无效数据，是功能测试的一种测试用例设计方法。如电话号码，那么有效数据就是符合运营商电话号码的规则，无效就是不符合，如连续的11个同样的数字以及非11的数字。
2）边界值
边界值是针对等价类测试用例方法的补充，如电话号码，需要考虑到11位，以及12位，和0位，也就是边界的情况
3）判定表驱动分析方法
列出被测对象可能存在的不同条件，如招聘类网站筛选出的结果排序，可能会存在多个条件来筛选出结果，如年限，薪资，地区等等，需要先列出来
4）因果图
在判定表的基础上，根据被测对象列出的条件，来使用排列组合的方式来验证各个不同条件下（并且以及或者关系）程序的结果情况
5）正交实验分解法（都用）
在因果图的基础上，使用排列组合下来的测试用例个数是非常多，导致测试用例的个数是非常多的，那么使用正交实验分解法可以优化 测试用例的个数，选择有代表性的数据来进行测试
6）场景设计方法
主要考虑的是一个产品的完整的业务流程，从输入流开始一直到输出流，比如淘宝，从一个商品上架一直到商品的出售
7）错误推测法
针对被测产品的非功能性的测试用例，主要使用探索性测试的方法，来验证被测产品可能存在问题
8）功能图分析⽅法
针对程序非功能性的测试，主要考虑的是被测程序的内部结构代码的测试
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、如果转测延迟，你怎么处理？
向测试负责人或者P反馈，沟通解决方案
13、那么公司开发转测试的依据是什么？
开发代码写完了，功能都可以实现且冒烟测试通过
14、怎么理解冒烟测试？
对程序正常流程的测试。正常流程能运行不出故障，新代码无问题
15、怎么理解回归测试？
旧代码修改后的测试，确认修改后没有新的问题，准备上线时的回归测试. 回归测试：产品已经测试完成,在准备上线的情况下，针对产品进行第n次测试，由大量自动化承担
1.测试阶段,对昨天提交的bug进行回归测试（对象是bug）
2.上线前开发把代码合并后，净现一次系统测试（对象是之前功能加新的功能）
3.测试阶段，需要正对系统已有的功能进行测试（对象是之前的功能）
4.上线后，针对系统所有功能的测试（对象是之前功能加新的功能）
16、你怎么看待加班？
当前任务需要加班的话会加班，不做无意义的加班
17、提交BUG你一般是怎么提交的
- BUG步骤一定要具备可操作性（操作步骤要清晰，通俗易懂）
- 提交的BUG最好有错误的截图信息、URL地址以及日志信息
18、BUG的级别你怎么理解？
- 严重问题： 1、逻辑问题 2、影响流程功能
- 一般： 1、页面交互 2、浏览器兼容性 3、错误提示信息不合理
- 故障： 1、系统崩溃 2、数据丢失 3、系统雪崩
19、如果一个任务实际5天，但是我给你安排3天，这个时候你会怎么办？
- 1.拿到任务细化拆分，每个任务按照自己的能力实际分配时间——任务的计划
- 2.约领导，给他详细说明为什么不是3天，而是需要5天
20、针对淘宝购物车请列举出测试点？
- 功能性测试：可以加购多少，什么商品可以？（最多加多少，上架的才可以
- 非功能性测试：比如一万个用户使用，是否可以运行
- 性能测试：在不同的网页是否可以正常使用
- 兼容性测试：
- 场景测试：
功能性
1.是否有全选，全不选的功能
2.是否能删除商品，批量删除功能
3.每件商品是否是有对应商品图片展示
4.失效的商品是否还会出现在购物车的历史纪录中
非功能性
1.页面布局是否合理
2.界面是否有错别字
3.文字是否清晰
性能测试
1，打开购物车到购物车界面显示响应时
2.用户过多会不会造成服务器崩溃
3.点击结算按钮后，跳转到确认订单页面的响应时间
兼容性测试
1.购物车在不同手机系统中是否兼容（ios 和 安卓）
2.购物车在不同 pc 端是否兼容
3.购物车在不同浏览器是否兼容
4.购物车在不同分辨率下是否兼容
场景
21、在公司你是怎么评审测试用例的
1、编写完测试用例后，预定会议室，同时和大家约这个开会的时间是否都能够参加
2、开始评审，描述每个测试点，描述的过程中，如果有问题，需要把别人提出的问题立刻记录下
3、评审结束，做最后的总结
22、你怎么理解验收测试？你们之前的验收测试流程是怎样的？
测试完成后，发送邮件给产品经理，产品经理这边会进行验收测试，产品经理这边验收测试完成后，会回复邮件说明验收测试已经完成，下来测试团队编写测试报告，准备产品的上线。
23、如果你负责的产品上线后有bug，你第一时间怎么做？
- 先在测试环境验证问题是否存在（排查是开发的责任还是测试的责任）
- 测试环境验证问题存在，那么就说明测试环境测试这边没测试出来，那么在群里面反馈给大家，然后再次评估今天晚上上线是否继续？要的话，是否第二天要发一个hotfix紧急版本
- 测试环境验证问题不存在，也需要反馈出来，下一步@开发，让开发检查各个中间件(RabbitMQ,Kafka,Redis等)的配置参数以及其他的配置
- 开发在3的基础上更新代码解决问题后，测试协助开发验证，然后把验证的结果反馈出来
- 复盘： 1、测试问题，复盘怎么说？ 2、开发问题，复盘怎么说？
复盘：
1、测试问题，复盘怎么说？
A、这个问题首先测试这边是责任的，之前设计测试用例不仅仅测试没考虑到，评审的时候大家也没考虑到，所以导致这个场景没有测试到
B、所以下次编写测试用例，测试这边会增加XX维度的测试点，评审的时候大家也需要沿着这个维度来考虑
2、开发问题，复盘怎么说？
A、建议开发这边每次上线前专门写一个关于上线的checklist，这样防治下次也犯同样的问题
序号 检查项 负责人
1 Redis 参数修改为... 赵四
24、如果你的直属主管一直很为难你，你会怎么处理二者之间的关系
首先思考一下，是自己工作中出现问题，还是平时与同事交往中出现的问题，然后去约时间和测试主管沟通，主动说出自己在工作中存在错误，这边希望领导能指点一下，加以改正，自己以后也会再接再厉
25、描述下你们一个迭代多少时间，这期间你的工作是怎么安排的？你们团队是多少人?
2周一个迭代，需要明确
- 需要明确本次新迭代需要测试的内容，
- 本次新迭代是否需要测试性能测试，
- 本次迭代是否需要测试系统之前的功能，如果需要时间是多久（系统已有功能是需要测试的，但是不会给很多时间）
一般迭代是多久一次：2周
人员结构有哪些： PM（项目经理）：1 开发：4-5 前端：1-2 测试：3-4 产品经理：1 13
2周工作内容（一个迭代）：
第一周：
周一：熟悉需求文档以及参与需求的评审，和拆分任
周二：继续熟悉需求，编写测试用例
周三：继续编写测试用例，评审测试用例，以及完善测试用例
周四：编写自动化测试代码（学习/应用）
周五：继续编写自动化测试代码，开发转测后，进行冒烟测试验证
第二周：
周一：测试被转测试的产品
第二：继续测试，以及验证回归问题(Issue)
周三：继续测试，以及进行验收测试
周四：编写测试报告，做最后的探索性测试，准备上线前的资料，以及晚上上线后的回归测试验证
周五：参加项目迭代复盘会议，以及针对本地迭代进行总结，准备下一个迭代的工作内
26、怎么理解story?
敏捷里面的术语，任务的意思 有开始有结束 即有时间限制。有明确开始和结束时间的任务
27、详细的描述下测试计划和测试报告是那个阶段写，里面你具体写哪些内容的
需求评审完成后编写测试计划，bug验收通过验收测试通过后写测试报告
28、你怎么理解风险控制？
遇到风险时及时反馈给测试负责人pm相关的人，一起沟通解决。ag,昨天转测但是出了状况延迟转测，需要及时向上反馈沟通解决
29、你测试过最难的bug是什么？详细的描述下它的过程，以及你的排查思路？
支付回调、内存泄漏oom
30、你期望薪资是多少？
期望薪资是~当然你们可以根据经验能力等评估~
