文章目录
做好测试计划工作的关键是什么？
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_20">如何提交一个好的bug？
对bug有一个清晰明了的描述，详细描述bug重现的步骤，对于产生bug的环境进行描述，提交bug相关的图片和日志，定位好bug的等级，将预期结果和实际结果进行对比
BUG描述包含哪些内容？
BUG 标题：简短地描述 BUG 的核心问题，以便其他团队成员快速了解。
BUG 描述：详细阐述 BUG 的现象，包括出现问题的具体步骤、操作顺序、输入数据等。
重现步骤：列出重现该 BUG 的具体步骤，以便其他人员能够按照步骤重现问题。
预期结果：描述在正常情况下应该出现的结果或期望的行为。
实际结果：描述实际观察到的结果或行为，与预期结果进行对比。
影响范围：说明该 BUG 对系统、功能或用户的影响程度。
严重程度：评估 BUG 的严重程度，如高、中、低，以便开发团队根据优先级进行修复。
相关截图或日志：如果可能，提供与 BUG 相关的截图、日志文件或错误堆栈信息，以便更直观地展示问题。
环境信息：说明出现 BUG 的环境，如操作系统版本、浏览器类型、网络状况等。
附加说明：提供任何额外的信息或上下文，有助于理解和解决问题。
报告人信息：包括报告人的姓名、联系方式等，以便开发团队在需要时与报告人沟通。
修复状态：记录 BUG 的修复状态，如待修复、已修复、正在修复等，以及修复的版本号。
讲述自己在项目中发现最有意义的一个 BUG，是什么导致出现这个问题？（例子）
在项目中，我发现最有意义的一个 BUG 是由于某个功能模块的逻辑错误导致的。具体来说，在一个电商网站的购物车页面，用户点击“结算”按钮后，系统应该根据购物车中的商品数量和单价计算出总价，并显示在页面上。然而，由于我在测试过程中发现了一个逻辑错误，导致系统在计算总价时出现了错误。经过仔细分析，我发现是因为在处理购物车数据时，我没有正确地处理商品的库存数量，导致系统误将库存为 0 的商品也计入了购物车。这个错误可能会导致用户在结算时发现商品已经售罄，从而影响用户体验和交易成功率。
bug_39">对于无法重现的bug，应该如何处理？
首先多测几次，测了多次后依然无法重现的话就先将bug挂起， 并且留意一下，看看往后的测试中，如果在后面的测试中重现bug就激活，如果经工几个版本都还没发现的话就关闭bug
如何保证测试的整体覆盖率？
- 制定全面的测试计划：在测试开始前，根据需求文档和项目特点，制定全面的测试计划，包括测试范围、测试方法、测试用例等，确保覆盖所有可能的场景和功能。
- 执行有效的测试用例：按照测试计划中的测试用例进行执行，确保每个测试用例都被执行到，并且检查结果符合预期。
- 持续进行回归测试：在项目开发过程中，定期进行回归测试，确保新功能或修改不会引入新的缺陷或影响已有功能。
- 监控和跟踪缺陷：对发现的缺陷进行跟踪和管理，确保缺陷被及时修复，同时对未修复的缺陷进行优先级排序，优先解决高优先级缺陷。
- 定期进行代码审查：组织团队成员定期进行代码审查，发现潜在的缺陷和改进点，提高代码质量和测试覆盖率。
把需求了解通透，引用用例评审机制，然后编写测试用例的时候用边界值，用等价类补充一些用例，根据过往经验用错误推断法来追加一些用例，如果存在组合情况的话我会用因果图或者判断表来编写，如果业务场景清晰的情况下我会用流程分析法，如果状态有发生改变的话我就会用状态迁移法。编写用例是一个极其考研耐心的事情，要考虑到各种场景，全面覆盖到会出现的场景。
