软件测试面试题与答案【一】

软件测试面试题与答案【一】

1、怎样判断一个bug是不是缺陷？
根据需求和用户故事来判断原则来甄别发现的问题是不是一个缺陷

1. 软件未达到产品说明书标明的功能
2. 软件出现了产品说明书指明不会出现的错误
3. 软件功能超出产品说明书指明范围
4. 软件未达到产品说明书虽未指出但应达到的目标
5. 软件测试员具体问题具体分析，认为软件难以理解，不易使用，运行速度缓慢或者最终用户认为不好。

2、缺陷产生的原因有哪些？

1. 需求频繁变更
2. 沟通不良
3. 不了解客户的需求
4. 项目期限的压力
5. 需求分析或设计投入的时间和精力不够
6. 开发人员疲劳、压力过大或受到干扰，缺乏足够的知识、技能和经验、缺乏动力等。
7. 最主要的原因：需求方面的原因。

3、项目版本执行过程中，测试人员如何把控测试进度
在项目的测试过程中，我们要及时了解测试进度，跟踪bug提交、修复及验证情况。
若发现有较多的bug未解决，则应主动联系产品经理以及研发人员开bug分析会，确定问题的解决时间，若发现有较多bug未验证，则应提醒项目组的其他同事及时进行验证。

4、软件测试的原则是什么？

1. 尽早的不断地进行软件测试
2. 测试用例应有测试输入数据和对应的预期结果这两部分组成
3. 程序员应避免测试自己的程序
4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件
5. 严格执行测试用例，排除测试的随意性
6. 应当对每一个测试结果做全面检查
7. 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

5、测试计划格式是什么？内容是什么？怎么写的？

1. 概述（测试目的、参考文档、缩略语）
2. 测试范围（测试范围，要测试哪些模块）
3. 测试组网图（系统架构图、组网图）
4. 资源需求（硬件资源需求、软件资源需求、人员需求）
5. 测试条件（测试版本启动、测试版本停止、测试版本挂起）
6. 测试时间（测试所有活动的时间安排，是测试需求分析、测试用例、测试轮次的时间安排）
7. 测试准则（测试用例通过、测试用例失败、回归的准则、培训计划）
8. 测试风险分析（可能存在哪些风险，如何解决）
9. 测试策略（使用测试那种测试方法，如何测试、测试的优先级、用例的设计选择）
   10.测试功能点（具体的测试功能点，相当于测试用例标题）
10. 工作交付件（什么时候完成测试计划的编写？提交测试计划）

6、测试用例格式内容

1. 所属产品
2. 所属模块
3. 用例编号
4. 用例名称
5. 用例优先级
6. 前置条件
7. 操作步骤
8. 预期结果
9. 实际结果
   10.测试人员

7、bug组成部分（缺陷报告）

1. 所属产品
2. 所处模块
3. 影响版本
4. bug类型
5. bug标题
6. 严重程度
7. bug状态
8. bug优先级
9. 重现步骤
10. 附件

8、bug生命周期

1. 发现bug
2. 提交bug
3. 分配bug
4. 修改bug
5. 回归验证bug（当回归不通过时，则将bug重新分配给相关的研发人员）
6. 关闭bug

致命：
一般会引发蓝屏、死机、需求未正确实现
严重：
重要功能没实现或出现错误、接口出错
一般：
常用功能没实现或者出现错误，界面错误
出错不提示，输入限制不在前台实现
轻微：
界面不规范，长时间操作不提示、文字不适用专业术语
必输项与可输项没有明确区分

9、产品上线前发现的bug，你是怎么处理的
（根据bug严重程度来决定，也可以举相应的例子来说）

1. 重大bug本版本更新的主要功能出现崩溃
2. UI展示页面问题，或者可以说对于用户操作流程没有问题，可以考虑下次更新版本的时候再说。

解决方法：

1. 如果出现重大bug，严重影响用户使用，或者是本次版本更新的主要功能出现bug，我会第一时间找到开发领导，问一下能不能在半天内修复bug，开发修改完，我们也是需要重测是，如果说一天活着了两天之内都无法修复bug，可能会延期上线，最终结果需要各部分讨论决定。
2. 如果不是很严重，不影响用户使用的话基本上都是放在下一个版本，进行优化的时候再调整。

10、测试报告格式

1. 简介（产品、版本号、参考文档）
2. 测试资源描述（地点、人物、软件测试资源、硬件测试资源、测试组网图、测试仪器）
3. 测试时间统计（测试任务的时间，这里面的时间是详细的每个版本的细分时间统计）
4. 测试用例分析（测试用例执行情况分析，哪些用例通过了，哪些发现问题了）
5. 缺陷情况分析（分布情况、严重程度、遗留问题）
6. 测试版本质量分析（测试版本的质量怎么样，描述一下）
7. 测试活动评估（测试活动以及写测试用例、脚本方面的质量方面描述一下）
8. 测试过程改进（改进的建议）