一，测试理论

1、测试流程

市场调研、需求采集>>产品经理发出需求评审的会议邀请>>产品需求设计评审>>开发设计方案，编写代码，测试同步进行编写测试计划>>编写测试方案>>依据梳理的需求点吧编写测试用例>>测试用例评审>>转测后进行冒烟测试>>冒烟测试无问题后进行测试阶段>>提交BUG以及验证BUG>>测试通过后编写测试报告，同步进行验收测试>>准备上线前的准备工作>>上线后的回归测试验证

2、测试阶段

单元测试：单元测试框架主流的有:Java(Junit,TestNG),Python(unittest,Pytest)单元测试又可以说是白盒测试；测试内容：模块接⼝测试，程序内部逻辑，路径分⽀测试，局部数据结构测试，错误处理测试，边界测试。

集成测试：核心是API测试，也就是接口测试。接口测试主流的测试工具是PostMan,JMeter。集成维度具体为①，前端与后端的集成 ②，后端与后端的集成

系统测试：（End To End Test 端到端的测试）针对一个系统的业务流程的测试，也就是说从一个流程开始一直到一个流程的结束。针对系统中各个不同模块（集成测试里面的模块）集成到一起后的测试，目的是验证各个独立的模块集成到一起后，是否能够完整的调用通系统的各个链路。其实是功能测试

验收测试：（外包型：验收测试客户到场一块验收 自研型：测试完成后，发送邮件给产品经理，产品经理这边会进行验收测试，产品经理这边验收测试完成后，会回复邮件说明验收测试已经完成，下来测试团队编写测试报告，准备产品的上线。）

3、测试策略：

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

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

4、测试用例方法

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

非功能测试方法（错误推测法、功能图测试方法）

场景法（场景设计方法）

二，面试题

你怎么保障你设计的测试用例的测试点是全的？

1、功能测试（等价类{针对被测对象的输入数据分为有效数据和无效数据;如：如电话号码，那么有效数据就是 符合运营商电话号码的规则，无效就是不符合，如连续的11个同样的数字以及非11的数字。}、边界值{针对等价类测试用例方法的补充；如：如电话号码，需要考虑到11位，以及12位，和0位，也就是边界的情况}、因果图{在判定表的基础上，根据被测对象列出的条件，来使用排列组合的方式来验证各个不同条件下（并且以及或者关系）程序的结果情况；如：例如招聘网站上的同时选取地区、学历、薪资等出现的结果的测试。}、正交实验分解法{在因果图的基础上，使用排列组合下来的测试用例个数是非常多，导致测试用例的个数是非常多的，那么使用正交实验分解法可以优化 测试用例的个数，选择有代表性的数据来进行测试。如：招聘网站的地区过多，选择有代表性的城市进行测试}、判定表驱动分析方法{出被测对象可能存在的不同条件；如：招聘类网站筛选出的结果排序，可能会存在多个条件来筛选出结果}）

2、非功能测试（错误推测法{针对被测产品的非功能性的测试用例，主要使用探索性测试的方法，来验证被测产品可能存在问题；如：在波浪式的交互过程中，一直往下滑动，可能会出现浏览器的卡死}、功能图测试方法{针对程序非功能性的测试，主要考虑的是被测程序的内部结构代码的测试}）

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

4、性能测试

5、兼容性测试

三，测试术语

冒烟测试：转测后对程序的基本功能的测试

回归测试：相当于重复性之前的测试并验证

1、测试阶段，针对昨天提交的BUG进行回归测试（对象是BUG）

2、测试阶段，需要针对系统已有功能进行的测试（对象是之前的功能）

3、上线前开发把代码合并后，进行一次系统的测试（对象是之前功能加新的功能）

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

探索性测试：发挥主观能动性、创造性思维，目的是看是否能够发现之前没发现的BUG

四，BUG问题总结

BUG流程：发现BUG，提交BUG给开发，开发这边恢复后会进行回复，然后关闭提交单。

BUG注意事项：

1、BUG步骤一定要具备可操作性。（程序员根据步骤中的信息可以复现BUG）

2、提交的BUG一定有错误的截图信息以及日志信息。

不认可BUG怎么办？

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

印象最深的BUG（内存泄漏OOM、支付回调{银行扣费后淘宝界面仍显示待支付}）

五，关于加班

你对加班怎么看？

首先承认公司加班制度，但不做无用加班。

六，测试计划

测试计划的要素：⼀个叙述了预定的测试活动的范围、途径、资源及进度安排的⽂档。它确认了 测试项、被测特征、测试任务、⼈员 安排以及任何偶发事件的⻛险。

story:敏捷的术语，译为任务

如果一个工作，实际任务量是5天，但是我让你3天干完，此时你会？

1、拿到任务，先对任务进行拆分，然后每个任务根据自己的能力以及实际情况分配时间。

2、约上你的领导，给他详细的说明为什么不是3天，而是5天。分析后果后在进行商量。

3、需要注意的是到一个团队内，你的角色以及定位是什么？

七、测试报告

你写过没？内容是什么？

写过，内容：测试概述（版本、测试时间、测试参与人、备注）、功能测试结果（新功能测试结果、系统已有功能测试结果、系统核心流程测试结果）、缺陷分析（多少BUG、解决多少、解决率多少、未解决多少、缺陷状态分布图、缺陷严重级别分布图）、测试风险分析（缺陷风险分析{BUG描述、BUG链接、BUG解决方案、解决时间、负责人、备注}、风险量化{风险描述、影响范围、解决时间、负责人{产品经理}、备注}）、测试结果（本次测试结果通过，可以上线！）