总结
作者：互联网
你怎么保障你的测试用例的测试点是全的？
1.功能测试 2. 非功能测试 3.场景 4.性能测试 5.兼容性测试
测试术语
冒烟测试
回归测试
1.测试阶段，针对昨天提交的BUG进行回归测试 （对象是BUG） 2.上线前开发吧代码合并后的，镜像一次系统的测试（对象是之前功能加新的功能）3.测试阶段，需要这对系统已有功能进行的测试（对象是之前的功能）4.上线后，针对系统所有红能的测试（对象是之前功能加新的功能）
探索性测试（主观能动性，创造性思维，目的是看是否能够发现之前没发现的BUG）
问题总结
BUG流程
1、发现BUG
2、提交BUG
3、开发修改BUG
4、开发吧问题修复后反馈给测试
5、测试验证如果通过，就关闭，如果没有通过，继续反馈给开发
BUG注意事项 （不认可怎么办?)
1、很清晰的测试步骤
2、需要尽可能地带错误日志信息、截图
印象最深的BUG： 内存泄露（OOM）、支付回调
测试计划
测试计划的要素
Story故事有开始有结束，任务也要有开始有结束
如果一个工作，实际任务量是五天，但是让你三天完成，你会怎么做？
1、拿到任务，先对任务进行拆分，然后每个任务根据自己的能力以及实际情况分配时间--->任务计划
2、约上你的领导，给他详细的说明为什么不是3天，而是4天（领导能力比我强，我需要更多时间，时间太短任务质量也可能会有问题，到时候或许对双方都有影响）
测试报告
（你写过没？内容是哪些？）
1、测试概述：版本，测试时间，测试参与人，备注
2、新功能测试结果：本次迭代新功能测试的结果(只有一个结果就是通过/pass)
3、系统已有功能测试结果
4、系统核心流程测试结果
5、缺陷分析（总共有多少个BUG，解决了多少个，解决率是多少，未解决多少个）
6、测试风险分析
7、测试结果
测试基础理论：
1、bug完整的生命周期（流程）？
发现BUG
提交BUG
开发修改BUG
开发吧问题修复后反馈给测试
测试验证如果通过，就关闭，如果没有通过，继续反馈给开发
2、编写测试用例的要素是什么？
测试标题 测试步骤 前置条件 期望结果 （需要注意的点：测试步骤要非常清楚）
3、怎么理解黑合测试，白盒测试
黑盒是把测试的对象看成是一个黑色的盒子的，看不到里面内部的结构，是对软件的一种功能性的测试。
白盒就是把测试的对象看成是一个透明的盒子，能够看见被测软件的内部结构，是单元测试的一种形式，是针对程序的内部代码的一种测试形式。
单元测试、集成测试、系统测试、验收测试
4、测试按阶段划分，主要分为那几个阶段
单元测试、集成测试、系统测试、验收测试
5、怎么理解等价类和边界值
等价类是针对被测对象的输入数据分为有效数据和无效数据，是功能测试的一种测试用例设计方法，边界值测试用例是针对等价类测试用例方法的补充
6、请描述一个完整的测试流程
产品经理发出需求评审的会议邀请 产品需求设计评审 编写测试计划 依据梳理的需求点编写测试用例 组织相关人评审测试用例（产品经理、开发、测试团队） 开发转测后先进性冒烟测试 冒烟测试通过进入到测试阶段 提交BUG以及验证BUG 测试通过后编写测试报告 验收测试 准备上线前的准备工作 上线后的回归测试验证
6、列表常用的测试用例设计方法，请结合具体的产品说明它的使用
等价类
针对被测对象的输入数据分为有效数据和无效数据，是功能测试的一种测试用例设计方法。如电话号码，那么有效数据就是符合运营商电话号码的规则，无效就是不符合，如连续的11个同样的数字以及非11的数字。
边界值
边界值是针对等价类测试用例方法的补充，如电话号码，需要考虑到11位，以及12位，和0位，也就是边界的情况
判定表驱动分析方法
列出被测对象可能存在的不同条件，如招聘类网站筛选出的结果排序，可能会存在多个条件来筛选出结果，如年限，薪资，地区等等，需要先列出来
因果图
在判定表的基础上，根据被测对象列出的条件，来使用排列组合的方式来验证各个不同条件下（并且以及或者关系）程序的结果情况，比如在boss直聘上年限加上薪资之后筛选出来的结果
正交实验分解法
在因果图的基础上，使用排列组合下来的测试用例个数是非常多，导致测试用例的个数是非常多的，那么使用正交实验分解法可以优化测试用例的个数，选择有代表性的数据来进行测试，比如京东中的商品分类有很多种类型，比如生食品中我们可以挑选生活中最常用的大米和面食类的
场景设计方法
主要考虑的是一个产品的完整的业务流程，从输入流开始一直到输出流，比如淘宝，从一个商品上架一直到商品的出售
错误推试法
针对被测产品的非功能性的测试用例，主要使用探索性测试的方法，来验证被测产品可能存在问题，比如在网页打开被测软件后进行滑动式翻页
功能图分析⽅法
针对程序非功能性的测试，主要考虑的是被测程序的内部结构代码的测试，
8、测试用例的要素有哪些？
请描述一下你理解的测试流程 产品经理发出需求评审的会议邀请 产品需求设计评审 编写测试计划 依据梳理的需求点编写测试用例 组织相关人评审测试用例（产品经理、开发、测试团队） 开发转测后先进性冒烟测试 冒烟测试通过进入到测试阶段 提交BUG以及验证BUG 测试通过后编写测试报告 验收测试 准备上线前的准备工作 上线后的回归测试验证
10、如果是一个水杯，请设计它的测试用例，你会怎么测试它？
功能性
非功能性
性能
兼容性
场景
11、测试计划你是怎么写的
测试概述（测试人员 测试时间）
测试任务（任务模块 任务明细 任务负责人 测试任务的时间）
风险控制（风险项 负责人 是否解决）
12、测试报告你是怎么写的
测试概述
测试功能
缺陷分析
测试风险分析
测试结论
13、如果提交的BUG开发不承认，你怎么办？
1、BUG步骤一定要具备可操作性（操作步骤要清晰，通俗易懂）
2、提交的BUG最好有错误的截图信息以及日志信息
14、如果转测延迟，你怎么处理？
向测试负测人或者PM反馈情况
15、那么公司开发转测试的依据是什么？
首先要开发自己进行检测1.所有的功能全实现2.冒烟测试通过
16、怎么理解冒烟测试？
开发把编写好的程序转给测试的时候，程序首先需要做的是针对转测的程序进行正常流程的测试，这个过程叫冒烟测试。针对被测程序的正常流程的测试，目的是验证程序正常流程可以执行通的情况下继续测试被测程序的其他功能。
17、怎么理解回归测试？
产品都已经测试完成了，在准备上线的情况下，针对产品进行第N次的测试。
18、你怎么看待加班？
看当前的任务，如果需要就会加班，但不会做无意义的加班
19、提交BUG你一般是怎么提交的
20、BUG的级别你怎么理解？
紧急：影响进⼀步测试，需要⽴即修复。
⾼：必须在版本发布前修复。
中：必须要修复，不⼀定⻢上修复，可以讨论确定在某个时间节点修复好。
低：对产品影响⽐较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。
21、简述下对回归测试的理解，以及回归测试时候需要考虑的因素
产品都已经测试完成了，在准备上线的情况下，针对产品进行第N次的测试。
22、列举出常用的测试用例设计方法，请举例说明每个测试用例设计方法的使用
等价类:针对被测对象的输入数据分为有效数据和无效数据，是功能测试的一种测试用例设计方法。
边界值:边界值是针对等价类测试用例方法的补充
判定表驱动法:列出被测对象可能存在的不同条件
因果图:在判定表的基础上，根据被测对象列出的条件，来使用排列组合的方式来验证各个不同条件下（并且以及或者关系）程序的结果情况
正交实验分解法:在因果图的基础上，使用排列组合下来的测试用例个数是非常多，导致测试用例的个数是非常多的，那么使用正交实验分解法可以优化测试用例的个数，选择有代表性的数据来进行测试
场景法：主要考虑的是一个产品的完整的业务流程，从输入流开始一直到输出流
错误推测法：针对被测产品的非功能性的测试用例，主要使用探索性测试的方法，来验证被测产品可能存在问题
功能图分析方法：针对程序非功能性的测试，主要考虑的是被测程序的内部结构代码的测试
23、如果一个任务实际5天，但是我给你安排3天，这个时候你会怎么办？
领导能力比我强，我需要更多一点的时间，时间太短任务质量也可能会有问题，到时候或许对双方都有影响
24、针对淘宝购物车请列举出测试点？
从五个方面来考虑：功能性、非功能性、性能测试、兼容性、场景
25、在公司你是怎么评审测试用例的
功能测试和非功能测试来讲述，在听大家有什么建议，然后进行记录
26、你怎么理解验收测试？你们之前的验收测试流程是怎样的？
在产品完成了功能测试和系统测试之后、产品发布之前所进行的产品测试
测试完成后，发送邮件给产品经理，产品经理这边会进行验收测试，产品经理这边验收测试完成后，会回复邮件说明验收测试已经完成，接下来测试团队编写测试报告，准备产品的上线。
27、如果你负责的产品上线后有bug，你第一时间怎么做？
验证测试环境，如果测试环境不存在问题，那么就是开发那边的问题，如果测试环境有问题，那就找跑PM来协商要不要上线，并在第二天发布一个紧急的版本
28、如果你的直属主管一直很为难的，你会怎么处理二者之间的关系
去约他去会议室，然后问自己是不是哪方面工作没做好
29、描述下你们一个迭代多少时间，这期间你的工作是怎么安排的？你们团队是多少人?
一个迭代的时间是2周
人员结构有为：
PM（项目经理）：1
开发：4-5
前端：1-2
测试：3-4
产品经理：1
一共13人
两周工作内容：
第一周：
周一：熟悉需求文档以及参与需求的评审，和拆分任务
周二：继续熟悉需求，编写测试用例
周三：继续编写测试用例，评审测试用例，以及完善测试用例
周四：编写自动化测试代码（学习/应用）
周五：继续编写自动化测试代码，开发转测后，进行冒烟测试验证
第二周：
周一：测试被转测试的产品
第二：继续测试，以及验证回归问题(Issue)
周三：继续测试，以及进行验收测试
周四：编写测试报告，做最后的探索性测试，准备上线前的资料，以及晚上上线后的回归测试验证
周五：参加项目迭代复盘会议，以及针对本地迭代进行总结，准备下一个迭代的工作内容
30、怎么理解story?
Story故事有开始有结束，任务也要有开始有结束
31、详细的描述下测试计划和测试报告是那个阶段写，里面你具体写哪些内容的
测试计划在评审需求文档之后 测试报告项验收测试通过后
32、你怎么理解风险控制？
当存在风险的时候，需要及时的吧风险反馈给我的leader以及pm等相关的的
人，然后一起沟通解决风险。
33、你们一般多久一个迭代？你是怎么规划每天的工作任务的?
两周一个迭代
两周工作内容：
第一周：
周一：熟悉需求文档以及参与需求的评审，和拆分任务
周二：继续熟悉需求，编写测试用例
周三：继续编写测试用例，评审测试用例，以及完善测试用例
周四：编写自动化测试代码（学习/应用）
周五：继续编写自动化测试代码，开发转测后，进行冒烟测试验证
第二周：
周一：测试被转测试的产品
第二：继续测试，以及验证回归问题(Issue)
周三：继续测试，以及进行验收测试
周四：编写测试报告，做最后的探索性测试，准备上线前的资料，以及晚上上线后的回归测试验证
周五：参加项目迭代复盘会议，以及针对本地迭代进行总结，准备下一个迭代的工作内容
34、你测试过最难的bug是什么？详细的描述下它的过程，以及你的排查思路？
内存泄露（OOM）、支付回调
35、你期望薪资是多少？
圆滑
标签：总结,被测,功能测试,测试用例,测试,编写,BUG 来源： https://www.cnblogs.com/yinxiaowen/p/16479923.html