1.bug的定义，bug的周期
软件bug是指软件程序的漏洞和缺陷，测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等
生命周期中缺陷状态：新建–>指派–>已解决–>待验–>关闭
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG
2. 怎么判断是前端bug还是后端bug
界面相关，排版错乱，文案错误等问题都属于前端bug
出现样式问题的都是css的bug
出现文本问题的都是html的bug
出现交互有问题的都是js的bug
功能相关，抓包分析，从接口 请求url 参数 接口响应来分析
未发送请求，属于前端bug
接口请求url错误，传参错误，属于前端bug
接口返回数据错误，属于后端bug
性能相关
页面加载慢或者提交表单慢，抓包查看请求耗时，如果耗时长，就属于后端bug
3. postman接口测试怎么做strong>
接口测试就和普通功能测试没什么区别，区别就是功能测试是在页面上输入值，提交数据看结果，而接口测试没有页面，通过接口规范文档上的调用地址，请求参数，拼接 文，然后发送请求，检查返回结果。
步骤
打开postman，填写接口信息
结合测试用例，组合变换参数信息后，查看返回的json数据与prd（产品需求文档）是否一致
功能测试
单接口测试
正常参数
全部必填参数
全部参数（必填+非必填）
全部参数（必填+ 部分非必填）
异常参数
数据异常：长度，类型是否为空，不满足业务等
参数异常：多参，少参，无参，错误参数（password写成pass）等
多接口测试（业务场景测试，用在冒烟测试里）
4. 测试 告的组成
概述（包括项目背景，需求分析）
测试时间，测试环境
测试过程（评审记录，测试范围，测试用例）
功能实现清单（列出是否已经按照测试计划实现功能）
缺陷统计（测试缺陷统计，测试用例执行情况统计）
测试统计情况（资源统计，执行情况，问题统计，问题列表，遗留的问题）
测试总结（测试结论（是否通过），测试内容，测试用例的覆盖程度，bug的解决程序）
测试风险
5. 测试用例设计方法
黑盒（等价类划分，边界分析，因果图和错误猜测）
白盒（逻辑覆盖，循环测试路径选择，基本路径测试）
6. 软件测试通过的标准是什么
测试用例完全执行，测试用例覆盖到所有的测试点，并且缺陷的密度达到客户的需求
7. 什么是bugstrong>
没有实现的功能
完成了用户需求的功能，但是运行时会出现一些功能或性能上的问题
实现了用户不需求的多余功能
8. 简述软件测试的流程
阅读相关技术文档
参加需求评审会议
根据最终确定的需求文档编写测试计划
编写测试用例
用例评审
开发提交代码
执行测试用例，记录发现的问题
验证bug与回归测试
编写测试 告
产品上线
9. 自动化测试脚本开发的主要步骤
通过某些方式定位到我们要执行的对象，目标
对这个对象进行什么操作
通过操作对定位到的对象赋值
添加断言操作
10. 什么是冒烟测试
冒烟测试就是在每日构建版本后，对系统的基本功能进行简单的测试，这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试
11. app测试和web测试不同的地方
web项目是b/s架构，基于浏览器的，web测试只要更新了服务器端，客户端就会同步更新
app项目，c/s架构， 必须要有客户端，app修改了服务端，客户端用户所有核心版本都需要进行回归测试
web项目需要监测响应时间，cpu ，内存
app项目除了监测响应时间，cpu，内存外，还需要监测流量，电量
web基于浏览器，一般选择不同浏览器内核进行测试，app必须依赖于手机或者pad，分辨率，尺寸，设备系统
12. 一条bug记录都包含了哪些内容，如何提交高质量的bug记录
一条bug记录最基本应包含：编 ，bug所属模块，bug描述，bug级别，发现日期，发现人，修改日期，修改人，修改方法，回归结果
要有效的发现 Bug 需参考需求以及详细设计等前期文档设计出高效的测试用例，然后严格执行测试用例，对发现的问题要充分确认肯定，然后再向外发布如此才能提高提交 Bug 的质量。
13. 如何使用jmeter进行压力测试
添加请求
线程组配置—–设置线程组——–设置循环次数————–设置压测持续时间
添加聚合 告
执行分析结果—-主要看：请求数，响应时间（越小越好），tps（服务器每秒钟处理的请求数，数值越大越好）
14. 自动化和手动测试的区别
测试效率不同
完成同等数目的测试，启动自动化速度更快，手工测试则需要消费更多的时间，但是自动化测试的脚本开发比用例开发耗时长，包括编写脚本、调试脚本、维护脚本，而手工测试虽然也要对测试用例进行撰写、评审、修订，由于用例编写更多为自然语言，时间上会少
执行可靠性不同
覆盖率不同
在同等时间内，启动自动化测试能够覆盖更多的功能，而手工测试只能覆盖小部分功能。但是自动化测试适合回归测试，开发中的功能不划算。对于开发中功能，需求或者实现的更改，都会导致自动化脚本的变更，开发中的功能更适合手工测试。
15. 项目是如何进行测试的
了解被测系统，被测功能和各个功能的业务逻辑
分析需求文档，整理测试点
测试方法设计，将测试方法用到项目中
编写测试用例
拿到被测软件后，执行测试，提交bug，有效的进行回归测试
测试总结
16. mysql 有AB两个表，A表用户表，B表角色表，C表是关系表，查询用户都是什么角色
17. mysql 查询成绩倒数第三的同学
limit 返回查询条件的前几条或者中间某几行的数据，可接收两个参数， 第一个参数表示从第几行数据开始查，第二个参数表示查几条数据。注：初始记录行的偏移量是 0
用法
SELECT * FROM table LIMIT 5,10; // 检索记录行 6-15
SELECT * FROM table LIMIT 95,-1; // 检索记录行 96-last.
SELECT * FROM table LIMIT 5; //检索前 5 个记录行 相当于limit 0,5
18. 怎么测一个鼠标
界面
形状，大小 是否符合要求
是否有灯光显示
是否有产品logo显示，开关是否显示标识
功能
带线鼠标的话，连接在机箱上是否能使用，连接在笔记本上是否能使用
蓝牙鼠标的话，不插入连接器是否能使用；电脑打开蓝牙，是否能连接成功；鼠标没电，是否还能继续使用
鼠标左键是否能点击，点击后页面是否有反应
鼠标左键是否能选中文本
鼠标右键，是否显示刷新，复制等功能
鼠标滚轴是否可以滑动页面
鼠标点住左键是否可以拖动文件
鼠标是否可以双击
性能
鼠标左右键最多能够使用多久
电池可以支持多久
鼠标摔了之后是否还能正常使用
19. 当开发说这不是一个bug的时候，如何应付
开发人员说不是bug，有两种情况
需求没有明确，这个时候可以找到产品人员进行确认，需不需要改动
这种情况不可能发生，所以不需要修改。这个时候，我可以先尽可能的说出是BUG的依据是什么被用户发现或出了问题，会有什么不良结果员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。
20. 软件测试有哪些类型
测试类型：功能测试，性能测试，界面测试，UI测试、接口测试、安全测试、兼容性测试、易用性测试、压力测试、负载测试
21. 功能测试包含哪些测试
22. 么才能够全面的测试到每一个点strong>
测试的全面性主要需要在设计测试计划的时候考虑，从测试策略，产品需求等等
多个角度考虑从而定义全部的测试点
23.你觉得bugzilla在使用的过程中，有什么问题strong>
界面不稳定；
根据需要配置它的不同的部分，过程很烦琐。
流程控制上，安全性不好界定，很容易对他人的Bug进行误操作；
没有综合的评分指标，不好确认修复的优先级别。
24.eta测试与Alpha测试有什么区别strong>
Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
25. 系统测试阶段低级缺陷较多怎么办strong>
公司有预测试这个流程 会在开展测试活动之前对主要功能点的正常流程做一个测试以判断这个版本是不是可测试版本 如果低级缺陷比较多 严重阻碍测试执行的话 我们会打回开发部 不执行测试
26.什么是安全测试strong>
安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用， 有无漏洞。
力图破坏系统的保护机构以进入系统的主要方法有以下几种： 正面攻击或从侧面、背面攻击系统中易受损坏的那些部分； 以系统输入为突破口，利用输入的容错性进行正面攻击
感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
① 200多本软件测试电子书（主流和经典的书籍应该都有了）
② 零基础，进阶视频，自动化测试视频等等
③ 非常适合新人练手的项目实战
④ 1000道软件测试面试题，
⑤ 软件测试学习路线图（告别不入流的学习）
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！