产品上线前开会讨论能否上线，统计有哪些方面的BUG，BUG严重程度，是否影响使用。客观分析是否合适，不要夸大，也不要随意。
这里我们将线上问题大致分为三类：
一、临上线发现致命问题。如：流程走不通，某个模块崩溃闪退，某个功能走不通对主流程有影响；这种情况一般不允许上线，最终结果需要各部门讨论
二、影响用户体验，或使用频率较高，可能影响后续流程的。如：电话号码只允许输入八位数，不能输入11位数；或是公司名称只能输入一个字；这类BUG不影响正常功能使用，上线前评估，如果能解决则解决再上线，若花费时间较长，可以先上线再修改
三、轻微BUG。如：页面交互，提示语信息等；这类问题上线后再优化
原则上来说，上线前存在P1、P2级别的BUG，不允许上线，可能之前漏测，可能修改出现的新BUG；当然，具体如何还需结合实际情况，打个比方：如果今天不上线，明天产品会失去作用。那么这就需要与pm和开发分析，解决这个bug需要多久。如果需要两个小时修改，可以上线后同时修改，或延迟2小时上线。
上线时如何做：
测试人员安排上线之后的测试（验收测试、对线上产品进行简单的冒烟测试），线上版本测试通过之后才是大功告成。
上线后需要快速得出结论，从其他部门借调人手配合测试，可能是其他项目组的测试人员，也可能是其他部门的非测试人员。非测试人员需要搭配一个测试人员带领测试
若得出结果，出现重大漏洞，需要紧急下线；
如果问题影响较小，可以维持上线状态，同时紧急修复BUG。
对于兼容性问题，如闪退之类的，需给出具体数据，比如：在现有条件下，哪些型号的手机会出现闪退问题，哪些型号手机没有问题。
如果只有一个产品，则需下线维护，如有web端和APP端互为替代，则可以先上一个产品。
功能影响的是自己公司内部，可以允许上线，比如：审批流程有问题，影响不到客户，可公司内部协调规定，不影响上线。
总结：
1、完整的测试流程，每个环节注意事项，尤其是测试用例和bug。用什么用例，发现什么BUG，印象深刻的BUG怎么发现的，用例数量、BUG数量，计划三要素：工作安排、里程碑、风险分析是怎么考虑的。
2、项目上线后需要对项目的整个过程进行总结。包括对于团队的总结和个人的总结，项目的得失，反思和改进。尽可能的在以后的迭代中避免同样的问题发生。