软件测试知识面试题:测试计划关键、BUG流程、BUG描述、测试的整体覆盖率

文章目录

做好测试计划工作的关键是什么?

1 明确测试的目标,增强测试计划的实用性

2 用"5W"规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)

3 采用评审和更新机制,保证测试计划满足实际需求

4 采用评审和更新机制,保证测试计划满足实际需求

公司的BUG流程是什么?

1 当测试工程师发现了一个bug而且在bug tracking tool里面没有相同的bug, 他需要填写所有需要的bug信息并且把这个bug分配给test leader

2 如果这个bug不是一个真正的bug, test leader需要close这个bug

3 test leader需要审查bug的各种信息都完备,如果有信息不完整,他需要把状态改成"feedback" 并重新assign给提交者

4 如果这个bug是一个真正存在的bug, test leader需要把这个bug分配给相关的开发团队的PM, 并且把bug状态改成Assigned

5 如果这个bug属于另外一个开发团队,PM需要把这个bug重新分配给那个开发团队的PM

6 PM审查bug,并且分配给相应的开发人员去改正

7 开发人员收到bug以后,对相关的缺陷进行改正,并且重新分配给提交bug的测试人员并且把状态改成"Fixed"

8 测试人员需要对这个bug进行重新测试,保证相关的缺陷已经改正,测试人员可以reopen这个bug如果缺陷依然存在并且重新分配给相关的开发人员或者close这个bug如果缺陷已经改正

如何提交一个好的bug?

对bug有一个清晰明了的描述,详细描述bug重现的步骤,对于产生bug的环境进行描述,提交bug相关的图片和日志,定位好bug的等级,将预期结果和实际结果进行对比

BUG描述包含哪些内容?

BUG 标题:简短地描述 BUG 的核心问题,以便其他团队成员快速了解。

BUG 描述:详细阐述 BUG 的现象,包括出现问题的具体步骤、操作顺序、输入数据等。

重现步骤:列出重现该 BUG 的具体步骤,以便其他人员能够按照步骤重现问题。

预期结果:描述在正常情况下应该出现的结果或期望的行为。

实际结果:描述实际观察到的结果或行为,与预期结果进行对比。

影响范围:说明该 BUG 对系统、功能或用户的影响程度。

严重程度:评估 BUG 的严重程度,如高、中、低,以便开发团队根据优先级进行修复。

相关截图或日志:如果可能,提供与 BUG 相关的截图、日志文件或错误堆栈信息,以便更直观地展示问题。

环境信息:说明出现 BUG 的环境,如操作系统版本、浏览器类型、网络状况等。

附加说明:提供任何额外的信息或上下文,有助于理解和解决问题。

报告人信息:包括报告人的姓名、联系方式等,以便开发团队在需要时与报告人沟通。

修复状态:记录 BUG 的修复状态,如待修复、已修复、正在修复等,以及修复的版本号。

讲述自己在项目中发现最有意义的一个 BUG,是什么导致出现这个问题?(例子)

在项目中,我发现最有意义的一个 BUG 是由于某个功能模块的逻辑错误导致的。具体来说,在一个电商网站的购物车页面,用户点击"结算"按钮后,系统应该根据购物车中的商品数量和单价计算出总价,并显示在页面上。然而,由于我在测试过程中发现了一个逻辑错误,导致系统在计算总价时出现了错误。经过仔细分析,我发现是因为在处理购物车数据时,我没有正确地处理商品的库存数量,导致系统误将库存为 0 的商品也计入了购物车。这个错误可能会导致用户在结算时发现商品已经售罄,从而影响用户体验和交易成功率。

对于无法重现的bug,应该如何处理?

首先多测几次,测了多次后依然无法重现的话就先将bug挂起, 并且留意一下,看看往后的测试中,如果在后面的测试中重现bug就激活,如果经工几个版本都还没发现的话就关闭bug

如何保证测试的整体覆盖率?

  1. 制定全面的测试计划:在测试开始前,根据需求文档和项目特点,制定全面的测试计划,包括测试范围、测试方法、测试用例等,确保覆盖所有可能的场景和功能。
  2. 执行有效的测试用例:按照测试计划中的测试用例进行执行,确保每个测试用例都被执行到,并且检查结果符合预期
  3. 持续进行回归测试:在项目开发过程中,定期进行回归测试,确保新功能或修改不会引入新的缺陷或影响已有功能
  4. 监控和跟踪缺陷:对发现的缺陷进行跟踪和管理,确保缺陷被及时修复,同时对未修复的缺陷进行优先级排序,优先解决高优先级缺陷。
  5. 定期进行代码审查:组织团队成员定期进行代码审查,发现潜在的缺陷和改进点,提高代码质量和测试覆盖率。

把需求了解通透,引用用例评审机制,然后编写测试用例的时候用边界值,用等价类补充一些用例,根据过往经验用错误推断法来追加一些用例,如果存在组合情况的话我会用因果图或者判断表来编写,如果业务场景清晰的情况下我会用流程分析法,如果状态有发生改变的话我就会用状态迁移法。编写用例是一个极其考研耐心的事情,要考虑到各种场景,全面覆盖到会出现的场景。

相关推荐
随遇而安622&50816 小时前
分布式微服务项目,同一个controller方法间的转发导致cookie丢失,报错null pointer异常
分布式·微服务·架构·bug
测试小小怪下士19 小时前
单元测试、集成测试、系统测试、验收测试、压力测试、性能测试、安全性测试、兼容性测试、回归测试(超详细的分类介绍及教学)
功能测试·单元测试·测试用例·集成测试·压力测试·模块测试·安全性测试
南东山人2 天前
使用pktgen进行高吞吐发包
linux·测试工具·udp·wireshark·压力测试
灭掉c与java2 天前
软件测试第二篇软件测试技术
压力测试
三劫散仙3 天前
vue3 + naive ui card header 和 title 冲突 bug
ui·vue·bug
老汉忒cpp3 天前
测试概念以及测试bug
bug
互联网杂货铺4 天前
外包干了两年,快要废了。。。
自动化测试·软件测试·python·功能测试·面试·职场和发展·压力测试
Fan_web5 天前
Node.js——fs模块-相对路径的bug与解决
开发语言·前端·node.js·bug
送个祝福给小豪5 天前
这是一个bug求助帖子--安装kali 遇坑
bug·安装kali·kali bug·kali安装中文输入法·kali换源
嵌入式Linux,5 天前
BUG: scheduling while atomic
linux·运维·服务器·bug