首先要做的是確定當前已知的風險。當前出現的問題是否會帶來風險，以及會有什么風險。如果自己無法確定，可以找其他測試、產品或者開發同學一起評估。
有的測試同學一看到實際結果和預期不一致就覺得這是風險，但是又說不出會帶來的影響，以及這樣的業務邏輯是否真的不合理，是否有解決方案。“風險”這個詞變成了一個借口，測試同學可以不去評估不去思考這背后的邏輯，也不提出解決方案，上來就甩出一系列“風險”，這是對業務理解不夠深入，沒有主動思考的體現。
其次，明確功能的優先級和重要性。針對待測需求，心里要有一把稱，明確哪些功能優先級高，哪些比較重要，哪些是這次可以忽略的。
在時間不充裕的情況下，我們可以從優先級和重要性入手，優先確保重要的功能和場景，再一步步往外蔓延，確保上線風險在可控范圍。
最后，列出待測試checklist。因為形勢的變化，我們一開始設計的測試用例可能不是這么合適，這時候需要及時調整測試計劃和測試用例，在時間不充足的情況下，可以直接列簡單的checklist，可以快速確認測試點即可。
結合前面分析的風險級別高的問題以及優先級和重要性高的功能，我們將這些梳理成可執行的checklist，然后一個個進行測試和驗證。
推薦閱讀：
sales@spasvo.com
