如何应对项目上线前出现Bug?
本帖最后由 草帽路飞UU 于 2022-12-9 16:38 编辑当你在测试阶段最后两天，发现测试执行情况不理想，和预估的进度相差较大时，是否会焦虑到不知所措？
当你在上线前发现一个严重的问题，修复后需要重新执行一些验证测试及增加回归测试，此时你是否会惊慌？
当最后一轮测试/最后一天测试时测试环境突然出现问题，导致测试阻塞，测试进度受到影响，你是否会急躁？
问题描述
即使前期测试准备工作都做的非常充分，测试设计和测试阶段都比较稳，也有可能会出现评估不准确或者中后期才发现重要问题的情况。
因为测试执行工作毕竟是在项目的下游阶段，不稳定因素较多，临时状况也是无法避免，并且项目时间都比较匆忙，在这一阶段出现临时状况往往没有太多缓冲时间给我们。
遇到这些情况，需要及时向项目组反馈当前情况及项目风险，而不是拖延到最后一两天再处理。但是当项目不允许延期，组内也无其他测试同学支持时，我们还能怎么做呢？周围有的同学在这个时候就焦
虑的不行了，越焦虑效率越低，效率越低就越焦虑，时间一分一秒的过去了，除了增加血压和心率，项目上线风险并没有任何改变。
测试同学要做的不仅是提出问题，反馈风险，更重要的是提出解决方案，应对风险。越是这种情况下，越是要沉着冷静、条理清晰，结合我们的经验和业务能力去降低上线风险。
解决方法
首先要做的是确定当前已知的风险。当前出现的问题是否会带来风险，以及会有什么风险。如果自己无法确定，可以找其他测试、产品或者开发同学一起评估。
有的测试同学一看到实际结果和预期不一致就觉得这是风险，但是又说不出会带来的影响，以及这样的业务逻辑是否真的不合理，是否有解决方案。“风险”这个词变成了一个借口，测试同学可以不去评
估不去思考这背后的逻辑，也不提出解决方案，上来就甩出一系列“风险”，这是对业务理解不够深入，没有主动思考的体现。
其次，明确功能的优先级和重要性。针对待测需求，心里要有一把称，明确哪些功能优先级高，哪些比较重要，哪些是这次可以忽略的。
在时间不充裕的情况下，我们可以从优先级和重要性入手，优先确保重要的功能和场景，再一步步往外蔓延，确保上线风险在可控范围。
最后，列出待测试checklist。因为形势的变化，我们一开始设计的测试用例可能不是这么合适，这时候需要及时调整测试计划和测试用例，在时间不充足的情况下，可以直接列简单的
checklist，可以快速确认测试点即可。
结合前面分析的风险级别高的问题以及优先级和重要性高的功能，我们将这些梳理成可执行的checklist，然后一个个进行测试和验证。
总结
出现临时情况不可怕，甩锅和抱怨解决不了问题。作为职场人，我们遇事还是要理性一些，不要上来就焦虑发怒，而是要分析当前问题和矛盾，以及思考作为测试我们可以如何应对。
关于测试环境出现问题，包括业务组件和中间件的组件故障都会带来的用例无法执行的情况，作为测试人员应该有一定的定位能力和恢复能力，在日常的工作不能依赖别人来维护业务环境从而测试用例能顺利执行，这个不是一个协同合作的关系而是应该有一定的技术能力解决问题。
在平常我们应该主动去熟悉业务的框架，业务使用到的组件，比如了解组件的启动方法，定位方法，部署方法，进阶到组件的原理，实现逻辑，业界类似组件等。通过这样的反复学习后就不太会产生焦虑了，毕竟自己就可以解决问题。
针对说出现严重问题，建议先从问题本身的原因出发去评估之前测试的用例的正确性，只有知己知彼才能更好的去分析。当然风险上报和分等级是一个很好的手段，优先使用相同的时间解决重要的事情。
分析出现原因，是漏测，还是代码合并问题等
页:
[1]
