2021-10-16

1、介绍一下上家公司的测试流程？
首先进行需求评审，在会议上提出需求不合理和自己不明白的地方。
之后根据需求文档进行测试计划编写，测试计划主要包含，测试模块、测试优先级、测试时间以及测试人员分配。
然后根据需求文档用xmind进行测试点的提取
下一步根据测试点进行测试用例的编写
测试用例编写完成后等待开发人员提交测试，验证自测报告是否通过，当自测报告不通过时，将自测报告打回去，当自测报告通过时，正式开始测试
然后就按照用例执行测试，将缺陷记录在jiar中。
一轮测试完成后与开发人工员沟通缺陷修复完成时间，等开发人员修复完成发版后，开始回归测试
一般要经历三轮测试，等到bug全部解决并且关闭后，代表测试完成。
然后我们就开始编写测试报告，用户手册等文档，到达上线时间，完成系统上线。
2、之前编写测试用例都用到哪些方法，每种方法都是怎么用的？
之前编写测试用例主要用到等价类，边界值，错误推测法，场景法，流程分析法。
对于一些文本框的测试，主要采用等价类的方法进行用例的设计；当需求中出现最大，最小等字眼的时候，主要采用边界值的方法进行用例的设计，然后根据我们的测试经验，判断系统容易出问题的地方采用错误推测法进行用例的设计，当系统出现流程的时候，采用场景法和流程分析法进行用例的设计。
不常用的方法还有判定表、因果图等测试方法。判定表主要用于当条件与条件之间的组合比较多，并且条件与条件之间的组合会影响结果的时候，采用判定表的方法。因果图主要用于当条件与条件之间组合比较多，条件与条件之间存在制约关系，条件与条件之间的组合会影响结果的时候采用因果图的方法。
3、测试用例的八大要素？
用例编号、测试模块、优先级、前置条件，操作步骤，测试数据，预期结果，实际结果。
4、如何设计一个好的测试用例？
首先我们要对我们的系统和业务，以及各个模块之间的关联有详细的了解
其次我们要数量掌握设计测试用例的方法
然后在设计测试用例的时候，要考虑用例的完整性，设计的用例要覆盖全部的等价类以及所有边界值。
5、用例设计的核心思想是什么？
我们要站在用户的角度，把用户可能输入到程序中的情况进行分类，并且全部考虑到我们的用例中。
6、你们公司用的测试模型是什么？
我们公司一般采用v模型，但也不完全按照v模型进行测试，一般是开发一个模块测试一个模块，等开发完了，测试也完成了。
7、测试计划主要包含哪些内容？
1）首先第一部分是我们的项目介绍：主要包含项目背景，测试目的，参考引用文档，术语专业语
2）第二部分是我们的测试说明，主要包含测试环境，测试内容，优先级，测试人员以及时间分配
3）第三部分是我们的风险控制，主要包含风险评估和应急措施
4）第四部分是我们的质量评估标注，主要包括测试模块通过标准，验收测试通过标准
8、软件测试中的“5w1h”你能说出其中明确内容和过程吗？
什么人，什么时间，在哪里，做什么，为什么做，怎么做
利用5w1h原则创建测试计划，能够帮助测试团队理解测试目的，明确测试测试范围和内容，确定测试开始和结束时间，指出测试的方法和工具，给出测试文档和软件的存放位置。
9、测试报告包含哪些内容？
首先第一部分是我们的测试目标：包含测试背景，测试目的，引用文档。
第二部分是我们的测试过程：主要包含自测通过率、测试环境，测试人员与时间
第三部分是我们的测试模块与通过率
第四部分是我们的缺陷统计与遗留bug清单
第五部分是我们的测试结果，说明本次测试是否通过
第六部分是我们的风险分析
10、冒烟测试是什么：冒烟测试是正式开始测试之前的预测试，主要由测试人员验证基本功能和流程是否存在严重缺陷。当存在严重缺陷时，与开发人员沟通，等待开发人员修改，提交后，再次进行验证，没有问题后正式开始测试。
11、你们公司项目上线一般测试几次？
一般会测试三轮左右。
第一轮测试在冒烟测试完成后，覆盖全部用例进行测试。当所有A类bug修复，B类bug大部分修复后，进入二轮测试
二轮测试，根据兼容性，采用不同的浏览器或者手机进行用例全覆盖测试。当所有Ab类bug修复，大部分c类bug修复后，进入三轮测试
三轮测试对系统主功能主流程以及二轮bug比较多的模块进行测试。当全部bug解决回归后，编写测试报告。
12、能说一下bug的状态有哪些吗？
打开、已解决未测试、测试通过、重新打开、遗留、无需修正
bug的生命周期：测试人员发现bug后记录到缺陷管理工具jiar中，此时bug的状态为打开状态，打开状态的bug，开发人员有三种处理方式，第一种开发人员若bug修复后，bug状态变为已解决未测试，第二种：开发人员若觉得不是问题，则会将bug状态修改为不予解决，第三种，若开发人员下个版本解决此问题，会将bug状态修改为遗留。测试人员对这三种状态的bug进行回归时，已解决未测试的bug，验证已修复好，则将bug状态修改为测试通过；验证不予修正的bug，首先查看需求文档是否有明确规定，有明确规定则与开发人员沟通，将bug状态变更为重新打开，若没有明确规定，则分析此问题带来的影响，与开发人员沟通，尝试说服开发人员，若说服不了则找项目经理和测试经理评估此bug是否进行修改，如果需要修改，则将此bug状态修改为重新打开，若判定为不需修改，则记录到测试报告中。对于遗留的bug，记录到测试报告中。
13、假如线上出现了bug，你是怎么解决的？
一般情况，经过测试后线上出现bug的情况比较少，如果线上出现bug的话，我会先验证一下测试环境是否存在
此问题，对问题进行定位，找到相应开发人员，等待开发人员修改，修改后对bug进行验证，并且对相应用例进行补充。
14、说一下你印象深刻的bug？
有一个bug是这样的，有一个查询列表先进行全查询，然后翻页到第二页进行查询，根据特定字段进行筛选，实际有数据，但是没查询出来。当时开发人员进行复现的时候，没有复现出来。然后我在我这边复现的时候，发现也没问题了，就觉得有点奇怪，之后，我又尝试翻页到第三页和第四页进行查询，发现还是存在此问题，后来定位到了，当翻页进行查询时，当过滤出来的数据比当前页少的时候，查询不到。
还有一个bug是测试访客接通客服的时候，访客呼叫客服电话，系统页面没有弹出接电话按钮。开发人员在他的电脑上验证没有问题，在我这边确实存在问题，我就考虑可能是浏览器版本的问题，后来我把浏览器版本下载成了与开发人员一致的，还是没有弹出按钮。最后在开发人员电脑演示了一遍，发现我们两个人登录的工号不一致，用开发人员的工号在我电脑上试了一下可以登录，最后确定为工号问题。
15、说一说你觉得最难找的bug是什么?
偶现bug，不确定什么时间能出现。
解决：在linux 下用 tail -f 查看日志，把日志截图给开发，让开发去解决。
首先对问题进行截图，并且查看日志，将日志截图给开发，
然后将问题记录到bug库，想想自己的操作步骤，尽可能按照原来的操作步骤去复原。
16、如何区分前后端bug？
对于某些难以定位的问题，pc端一般用开发者工具，app则用抓包工具进行抓包，分析请求的数据来判断是前端问题还是后台问题。
1）首先看发的请求是否有问题，请求接口的url是否错误，参数是否错误，如果url或者参数有问题则判断为前端bug。
2）如果请求没有问题，看下后台返回的数据是否有问题，状态码5开头的一般为后台问题，状态码为200，响应数据与预期不一致的，也判断为后台bug.
3）当请求参数，url和返回参数都没有问题的时候，那可能是前端代码是否转换有问题，那就是前端bug。
17、说一下单元测试、集成测试、系统测试的区别？
单元测试（软件底层源代码中的最小的结构，具体是类、对象、组件等）单元测试一般是由开发人员进行
集成测试（一般是接口测试）将不同的单元组合在一起，验证之间的接口是否正常
系统测试：对软件当前的整体使用进行测试，从宏观上把控系统运行。
18、验收测试主要包含哪几种？
α测试：内测（在公司内部展开全面性测试）
β测试：公测（在正式环境中进行部分测试），让特定的用户使用，并提出建议
y测试：候选版本的测试
uat测试：第三方派出专业的人员进行测试并且进行验收。
19、能说一下你们公司bug的严重程度吗？
A类bug：影响测试流程或者导致系统瘫痪的bug
B类bug：需求未实现或者功能不可用
C类bug：相对独立的功能bug，对其他模块没有影响
D类bug：优化建议类的bug
20、能说一下你们公司bug 的优先级吗？
A类bug影响系统正常运行的bug优先级最高
B类bug需求未实现或者功能不可用的bug优先级高
C类bug相对独立的功能bug，对其他模块没有影响优先级中
D类bug优化建议优先级低，在时间和资源允许情况下进行修改
21、软件缺陷的定义：
1）未实现需求规格说明书中规定的功能
2）出现需求中明确规定不该出现的问题
3）出现难以理解、不易使用、运行速度慢等问题都可以认定为缺陷。
22、如果认为你提的bug不是bug，你应该怎么办
开发人员认为不是bug有两种情况
第一种：需求没有确定，我会找到产品经理进行确认，需不需要改动，三方商量后确定需不需要改
第二种：开发人员认为此问题不可能出现，我会尽可能的说出bug的依据是什么？分析此问题如果被用户发现后带来的后果，尝试说服开发人员。如果开发人员还是不改的话，我会找到相应的项目经理和测试经理，开会讨论此问题带来的后果及影响，并且由项目经理确定此问题是否修改。
23、如果bug要修改，但是上线很紧急，开发人员没有时间去改，你怎么办？
首先找到项目经理和产品经理，开会评审遗留这些问题会带来的风险，如果项目经理和产品经理接收风险，那就可以发布。发布后如果在下一版本中解决，则应该对问题继续跟踪
24、测试用例的定义：为了高效率的发现软件的缺陷精心设计的测试数据
25、测试人员在软件开发过程中的任务是什么？
1）尽可能早的找出系统中的bug
2）保证系统质量
3）关注用户的需求，保证系统符合用户需求