首先要做的是确定当前已知的风险。当前出现的问题是否会带来风险，以及会有什么风险。如果自己无法确定，可以找其他测试、产品或者开发同学一起评估。
有的测试同学一看到实际结果和预期不一致就觉得这是风险，但是又说不出会带来的影响，以及这样的业务逻辑是否真的不合理，是否有解决方案。“风险”这个词变成了一个借口，测试同学可以不去评估不去思考这背后的逻辑，也不提出解决方案，上来就甩出一系列“风险”，这是对业务理解不够深入，没有主动思考的体现。
其次，明确功能的优先级和重要性。针对待测需求，心里要有一把称，明确哪些功能优先级高，哪些比较重要，哪些是这次可以忽略的。
在时间不充裕的情况下，我们可以从优先级和重要性入手，优先确保重要的功能和场景，再一步步往外蔓延，确保上线风险在可控范围。
最后，列出待测试checklist。因为形势的变化，我们一开始设计的测试用例可能不是这么合适，这时候需要及时调整测试计划和测试用例，在时间不充足的情况下，可以直接列简单的checklist，可以快速确认测试点即可。
结合前面分析的风险级别高的问题以及优先级和重要性高的功能，我们将这些梳理成可执行的checklist，然后一个个进行测试和验证。
推荐阅读：
sales@spasvo.com
