一、测试用例要素
测试ID，用例名称，测试目的，测试级别，测试环境，前提条件，参考信息，测试步骤，预期结果，设计人员
二、测试用例设计方法
1、等价类，2、边界值，3、错误推测法，4、因果图法，5、正交实验设计方法，6、判定表驱动分析方法，7、功能图分析方法
三、提交bug后开发不承认如何处理
首先将之前操作的步骤检查重新测试一遍，确认后再次告知，可以找测试经理练习开发
四、转测晚了怎么处理
首先每天开会时会有进度汇报，可以先核实是否可以加快进度，无法加快的话，可以咨询是否晚发布，确实不可以的话，就自己加班尽快完成
五、测试流程
评审通过后，查看评审需求描写测试用例，开会讨论测试步骤，参会的人员一般有：产品经理、开发、测试。测试讲述过程中，随时有人提出不合理的部分（没有出现过或是不合理的场景），可以当场记录会后自行补充和修改合理，完成后发送群内@参会人员，一般测试主管会查看修改后的内容
六、对前一任公司的评价
一般分2点回答，1、学习到了东西，2、同事之间相处融洽
七、API动态参数（postman和jmeter）
postman
1、首先通过接口auth，登录成功后，在响应数据中显示相关信息
2、登录成功后，在响应数据中返回认证授权
3、在接口链接的请求中添加请求头
4、先执行登录授权的接口/auth
5、必须是在collection中执行
jmeter
1、先在Jmeter的测试工具里面加一个添加的测试用例
2、测试用例添加后，发送请求，在响应数据中获取它的动态参数，获取的方式具体为：
1）在该测试用例中，右键添加后置处理器中的JSON提取器或者是正则表达式提取器
2）以JSON提取器为例，定义一个变量来获取动态参数的值
3、在后续的查看修改删除中，使用到这个动态参数的ID，通过调用变量的方式
具体为：${变量的值}
八、http请求流程
1、客户端与服务端建立TCP连接
2、客户端向服务端发送request请求
3、服务端返回response响应
4、客户端与服务端断开TCP连接
九、常用业务状态码
200 请求成功
201 添加成功
204 删除成功
301 永久重定向
302 临时重定向
400 请求错误（请求参数或请求头不对）
401 无权限访问系统
403 有权限但禁止访问系统
404 请求的资源不存在（请求的地址不存在，所以导致请求资源不存在）
405 不被允许的请求方法
500 服务器内部错误
1、空指针，2、堆栈溢出，3、OOM，4、其他异常
504 网关超时
十、接口测试动态流程
一般上个接口的输出是下个接口输出的输入（auth与index都需要access token）
1)首先定义一个变量来存储服务端返回的响应数据，然后定义一个变量，来存储access_token的值
2)key为Authorization value为:jwt 获取到的授权的令牌，如Authorization:jwt {{token}}
十一、session、cookie、token流程
cookie主要是存储用户操作行为的数据，session是把登陆成功后的数据存储在服务端，token本质是cookie的原理，可以理解为一个令牌
cookie与session流程基本一致，只是cookie保存在本地，session保存在服务端
session请求流程
1、客户端输入账户和密码，点击登录
2、登陆成功后，服务端把用户登陆成功的信息生成一个sessionID的凭证，并且存储在服务端
3、服务端会通过响应头中的set-cookie把生成的sesson返回给客户端
4、客户端再次查看个人主页，客户端通过请求头中的cookie，把set-cookie返回来的sessionID带上，发送给服务端
5、服务端接收到客户端发送的sessionID，和存储在服务端的sessionID做一个对比
6、如果对比一致，用户可以继续访问系统的任何功能，如果结果不一致，立刻跳转到登录的页面
token请求流程
1、客户端输入账户和密码，点击登录
2、登陆成功后，服务端把用户登陆成功的信息生成一个Token的凭证，同时存储在服务端
3、服务端会通过响应数据或者响应头中的set-cookie返回给客户端
4、客户端再次向服务端发送请求，会在请求参数或者请求头中的Authuration中带上返回来的token发送给服务端
5、如果对比一致，用户可以继续访问系统的任何功能，如果结果不一致，立刻跳转到登录的页面
十二、性能测式流程
测试前期准备，如测试场景的梳理、测试目标的制定、设备的准备；
性能测试计划的制定，如人员分配、时间安排、用什么技术等；
测试设计与开发，如代码如何写、具体的脚本书写、测试目标如何实现思路，配置场景；
测试执行与管理，按照配置的场景进行执行即可；
数据收集，如响应时间、吞吐量等的数据的收集；
测试分析，根据收集的数据进行分析，书写测试报告
十三、聚合报告中的数据
Label、样本、平均值、中位数、90%请求响应时间，95%请求响应时间，99%请求响应时间，min、max、异常、吞吐量
十四、性能测试目的
目标一般由测试主导，根据服务面向的用户群体的需求来制定目标，然后与开发、架构师、测试等相关人员进行讨论，最后决定具体的目标
十五、详细说下之前印象中最深的bug
有三个点：1、非常难测，2、开发不承认是bug，3、排查能力问题
十六、对最近几年的计划
首先表示目前还是初中级测试，后续会在编程语言、性能测试和自动化测试能里3方面提高
十七、
注意事项
1、BUG标题一定要表达出问题的核心，看了标题就知道是什么问题
2、BUG步骤要清晰明了，通俗易懂，步骤要非常详细
3、提交BUG最好有问题截图
4、提交BUG最好有详细的日志信息(主要针对的是后台服务)
提交方式
1、在测试过程中发现的问题，我们进行提交
2、提交给开发后，开发会进行确认，如果是bug，开发进行修改，如果不是bug，开发会反馈给测试
3、如果开发确认是bug，那么开发修改完成后，再反馈给测试，测试进行回归验证bug是否解决
4、如果bug回归测试通过，关闭该问题，如果回归测试不通过，问题依然存在，那么继续反馈给开发
十九、负载测试、压力测试区别？
负载测试：在被测系统上持续不断的增加压力，直到性能指标(响应时间等)超过预定指标或者某种资源(CPU&内存)使用已达到饱和状态。核心是找到系统的处理极限， 为系统调优提供数据，从而达到了解系统性能的容量
压力测试：该方法是指系统在一定饱和状态下，具体如CPU，内存等饱和使用的情况下，系统能够处理的会话能力，以及系统是否会出现错误，比如TimeOut，OOM， OverStackExpection（堆栈异常）
质量管理
沟通 推动能力（催促开发尽快处理BUG） 风险把控（开发与测试转测时间）
效率提升
使用测试技术来提高工作效率
二十二、个人优势和劣势
优势与劣势可以随意转化
二十三、移动端测试如何查看实时日志
二十四、如何做移动端测试
1、功能性：程序功能是否ok，呈现程序基本的业务状态
2、非功能性：
二十五、测试用例编写注意事项
测试步骤需要简单易懂，清晰明了
二十六、需求文档里面有什么
1、本次迭代的页面交互图
2、业务逻辑流程图
3、关于业务逻辑的描述
二十七、一个功能，实际测试5天，给你3天的时间，你是否接受
可以接受，但是我会评估工作量，如果评估下来，认为是4天的工作，那么我会找你说出详细的理由
二十八、一个迭代多少天，具体每天的内容是什么
2周一迭代
第一周：
周一：熟悉需求，评审需求，列计划
周二：编写测试用例
周三：评审测试用例，完善测试用例
周四&周五：编写自动化测试case,等开发转测试，以及冒烟测试验证
第二周：
周一：开始第一轮的测试
周二：回归所有的bug,开始第二轮的测试
周三：开启系统测试，准备提交验收测试
周四：编写测试报告，准备上线前的工作
周五：跟踪上线后的产品情况，然后项目内部复盘
版本更新是持续改进的一个过程
二十九、一个团队多少人
一般是：pm:1、test:4、前端：2 后端：5、产品：1——总人数：13
UI自动化测试&元素方法
UI自动化测试流程
查看资源
查看实时日志
印象最深的BUG
突出要点任意两个：
（1）很难测
（2）开发不承认
（3)突出排查问题的能力