當收到開發(fā)的提測后，你是二話不說立刻進行測試呢，還是先找開發(fā)溝通確認清楚再開干呢。磨刀不誤砍柴工，有些準備工作是可以達到事半功倍的效果的。

首先需要和開發(fā)確認實現(xiàn)的功能和實現(xiàn)方式，這是確保開發(fā)的設(shè)計和需求是一致的。從開發(fā)描述的實現(xiàn)功能和實現(xiàn)方式中可以挖掘開發(fā)可能遺漏的特殊場景，以及對異常情況是否有處理，如果沒有的話開發(fā)同學可以立馬回去優(yōu)化，而不必等到一輪測試之后再去修改已經(jīng)有些遺忘的代碼。同時，結(jié)合開發(fā)的實現(xiàn)方式我們可以補充被遺漏的測試點?？赡苣銜婀衷跍y試用例評審的時候不是已經(jīng)確認過了嗎，為什么現(xiàn)在還要再確認。因為評審一般是在開發(fā)階段或者開發(fā)前的階段進行，而coding非常受開發(fā)主觀因素的影響，所以有必要在開發(fā)完成并提測之后進行再次確認。
“這個是在接收到報備請求的時候，判斷是否需要過人審，是的話就去發(fā)送消息通知?！?br> “是同步還是異步處理的，發(fā)通知時出現(xiàn)異常會影響該請求的正常返回嗎？”
“異步處理，發(fā)消息異常不會影響后續(xù)邏輯?！?/p>

過一遍提交的代碼。這是確保開發(fā)設(shè)計的和真實提交的代碼一致?？梢灾苯由习姹究刂葡到y(tǒng)比如Git去看開發(fā)提交的記錄，或者在IDE（如IDEA）中將此分支的代碼和其他分支的代碼進行比對，找到改動點。
“你這塊功能應(yīng)該需要改到vue吧？”
“是啊?！?br> “但是我沒看到你在這個版本提交過vue的代碼，你要不再檢查一下？”
“哎，真的忘記提交上去了”

檢查相關(guān)配置，需要執(zhí)行的sql、需要添加的定時任務(wù)、其他配置等。檢查sql、配置等不合理的地方，以及確保正式測試之前測試環(huán)境已經(jīng)ready。
“這個發(fā)送人員是配置在Nacos上的。”
“我看到你配的權(quán)限是FKZG，但是FKZG是風控主管的意思，需求里不是說要發(fā)給風控專員嗎？”
“噢原來這樣，我以為FKZG是風控專崗的意思呢，我改一下?！?br> “需要滿足的產(chǎn)品是員工貸，但是我看你配置的僅僅是001這個產(chǎn)品編號，002和003也是屬于員工貸大類下吖”
“我去確認下僅001員工貸還是員工貸大類下的都需要哈”

檢查代碼是否部署測試環(huán)境。如果是用Jenkins進行部署，可以結(jié)合提交記錄和構(gòu)建記錄確認開發(fā)代碼是否已經(jīng)部署到測試環(huán)境，如果已經(jīng)部署上去了就可以進行測試了，如果還沒有則需要先部署再進行測試，避免出現(xiàn)造好數(shù)據(jù)要測試時發(fā)現(xiàn)和預(yù)期不符，排查了半天之后才發(fā)現(xiàn)代碼并沒有部署成功的情況。

進行冒煙測試。這是確保產(chǎn)物和需求一致。先執(zhí)行冒煙測試，確保主流程和主要改動功能是可以走通的，再繼續(xù)執(zhí)行其它測試用例，注意要先關(guān)注優(yōu)先級高的用例，避免前期花過多時間在和業(yè)務(wù)邏輯關(guān)聯(lián)性不高的地方。

通過這些方式，在正式測試之前就可以發(fā)現(xiàn)一些隱含的問題，同時避免出現(xiàn)無效測試，縮短開發(fā)提交版本到收到問題反饋的時間。測試的目的不是為了測試而測試，而是要基于風險盡早去挖掘可能存在的問題。