本文是我秋招复习过程中，发散思维，胡思乱想面试关于测试可能会问的一些问题，所有的回答都是用自己的语言，不严谨的地方有大佬看到了还望指正，大家相互学习，最后祝大家都能拿到好offer~
下面开始正文 ，这里是美丽的分割线~
1、什么是软件测试？
答：我认为，通俗的来说，软件测试就是找BUG
详细一点来说，我认为软件测试是一种过程
是证明软件不存在错误的过程，也是证明程序能够正确运行的一种过程
2、我们为什么要做软件测试？（软件测试的作用/软件测试的重要性）
答：其实我认为软件测试是整个软件生命周期中十分重要的一个环节
我们做软件测试，最好在软件生命周期中的每个阶段都有测试的参与，有如下几点
1、我们可以尽早发现缺陷，提高该阶段对缺陷的遏制能力，提高测试效率，降低成本，提高质量
2、软件测试工作到位了，可以增强用户对产品质量的信心，同时，对我们自己来说，合格严谨的测试工作也是一针强心剂
3、为开发过程提供信息，为评估质量、评估进度提供重要的数据输入
4、可以预防缺陷，改进开发和测试过程，避免出现相同的缺陷，从而提高软件产品的质量
3、你为什么要做软件测试？
答：我认为软件测试是一份对个人能力有一定的要求，能让我有满足感的职业，我喜欢找BUG。而且行业前景比较好，属于朝阳行业，可持续发展。人才缺口较大，据我所知国外以及一些大厂内测试开发基本上人数是持平的，而国内显然距离这样的境界还有待发展。同时，随着国内市场对软件质量的逐步重视，该行业发展空间很大。同时，软件测试的职业寿命较长，资深的软件测试人员很受欢迎。不过，最大的原因还是我喜欢找BUG哈哈哈
4、研发与测试的区别？
答：我是这样理解的
研发人员的工作是实现用户需求，生产产品
而测试人员的工作是为了验证产品是否合格
5、什么是缺陷？
答：缺陷：程序中和用户合理期望不一致的地方就属于缺陷
程序中、软件中出现了说明书致命的不应该出现的错误
又比如程序中实现了产品说明书中未提到的功能
软件难以理解，用户体验差
以上几点都可以算在缺陷中。
在这里我要补充说一点，缺陷不等于BUG
举例：一只虫子引发的计算机短路事件。
我认为这件事里面的缺陷是计算机工程师提出来的问题：在主机散热孔加装金属网，既不影响散热，也可以防止虫子爬进主机。这个是计算机设计人员疏忽的地方，是产品真正的缺陷。
而虫子爬进去造成的故障只是这个权限导致的故障的其中一种表现形式
也就是说，BUG是缺陷的一种表现形式，而一个缺陷是可以引起多种BUG的。
也有这样一种理解：
通常在产品release之前发现的问题，可以称之为缺陷；
而在release之后由最终用户发现的问题，则称之为Bug
6、什么是测试用例？
答：测试用例就是执行测试过程的一些记录，包括测试环境、操作步骤、测试数据、预期结果等
7、软件测试模型是否了解？
软件测试V模型：
改进软件开发的效率和效果，属于瀑布模型的变种
清楚地阐述了测试阶段和开发过程期间阶段的对应关系
- 单元测试和集成测试检测程序的执行是否满足软件设计的要求；
- 系统测试检测系统功能、性能的质量特性是否达到系统要求的指标；
- 验收测试确定软件的实现是否满足用户的要求
V模型有一定的局限性，它仅仅把测试作为编码后的一个阶段，未在需求阶段就引入测试
软件测试W模型：
W模型增加了软件个开发阶段中应该同步进行的验证和确认活动。W模型由两个V模型组成，代表了测试和开发的并行关系
特点：
1、需求、设计也要经过测试。
2、测试与发开同步进行
优点：尽早地，全面的发现问题，早早找出缺陷所在。即时了解项目难度和测试风险，尽早制定措施，显著减少总体测试时间，加快项目进度。
局限性：
需求、设计、编码等活动被视为串行的；测试开发保持一种线性的前后关系，上一阶段完全结束，才能到下一阶段。无法支持敏捷开发，无法适应当前软件开发复杂多变的情况
8、软件测试的流程？
答：我认为软件测试的流程大体上分为五个步骤
需求分析
测试计划（测试方案、测试策略）
测试用例编写（需求测试）
测试执行（冒烟测试、系统测试、回归测试、交叉测试、自由测试）
测试报告
9、软件测试的目的和原则？
目的：验证软件有没有问题
原则：以客户为中心，遵循软件测试的规范、流程、标准与要求
10、什么是需求？
据我所知，多数软件公司需求会分为两种
用户需求：一般是甲方提出的需求，或者是终端用户使用产品时必须完成的任务（一般较为简略）
软件需求/功能需求：详细描述开发人员必须实现的软件功能
软件需求是测试人员工作的基本依据
11、谈一谈软件的生命周期？
软件生命周期是指：从软件产品设想开始到软件不再使用而结束的时间
分为六个阶段：需求分析、计划、设计、编码、测试、运行维护
12、谈一谈软件测试的生命周期？
需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估
-
在需求阶段，测试人员了解需求、对需求进行分解，得出测试需求
-
计划阶段，根据需求编写测试计划/测试方案
-
设计阶段，测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例
-
编码阶段，测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案。
-
测试阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理缺陷，测试完成后编写测试报告。
-
运行维护，测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人。
13、如何描述一个BUG？
答：我觉得合格的BUG描述应该具备以下几点
1、发现问题的版本
2、出现问题的环境
3、错误重现的步骤
4、预期行为的描述
5、错误行为的描述
6、BUG的级别
注意：不要将多个BUG放在一起提交
14、BUG的生命周期
● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed
15、和研发人员产生争执怎么办？
我认为，这种时候首先要先检查自身，看自己是不是对bug的描述不清晰
其次，站在用户角度考虑问题，让开发人员了解到bug对用户可能造成的困扰，这样可以让开发人员更积极高效的修改bug
还有bug的定级要有理有据
最好可以提升自己的技术和业务水平，尽量能在提出问题的同时提出解决方案
一定不要和开发人员争吵，实在沟通不了可以发起bug评审。
吃完饭回来接着写
