软件测试知识面试题:测试计划关键、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. 定期进行代码审查:组织团队成员定期进行代码审查,发现潜在的缺陷和改进点,提高代码质量和测试覆盖率。

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

相关推荐
晋阳十二夜11 小时前
【压力测试之_Jmeter链接Oracle数据库链接】
数据库·oracle·压力测试
一入JAVA毁终身21 小时前
处理Lombok的一个小BUG
java·开发语言·bug
SeaTunnel1 天前
SeaTunnel 社区月报(5-6 月):全新功能上线、Bug 大扫除、Merge 之星是谁?
大数据·开源·bug·数据集成·seatunnel
紫璨月1 天前
nginx反向代理的bug
运维·nginx·bug
从后端到QT1 天前
SRS流媒体服务器之本地测试rtc推流bug
bug·实时音视频
Java知识库12 天前
MySQL RC隔离级别惊现间隙锁:是bug吗?
数据库·mysql·bug
安卓机器12 天前
rom定制系列------红米note11 5G版 MTK芯片强解bl锁修复bug 官方系统 面具root批量线刷版
5g·bug
剽悍一小兔12 天前
一个小BUG引发的对Mybatis-Plus的模糊查询的思考
bug·mybatis
Gazer_S14 天前
【前端隐蔽 Bug 深度剖析:SVG 组件复用中的 ID 冲突陷阱】
前端·bug
电手15 天前
Win11用户尽快删除更新!微软6月又推Bug
microsoft·bug