這兩周產品線加速bug收斂速度以來，開發和測試人員陸續的反饋了一些問題，大部分都屬溝通類或者細節類。對幾種典型問題，測試人員也經過了組內討論，希望能在細節方面，大家都能注意互相提醒一下，提高產品線的運作效率。
一、resolve的bug，驗證不通過，然后把bug進行reject操作----------這個處理過程，會出現一些疑義。
目前測試組進行約定，測試人員驗證resolve的bug，未通過驗證后，首先要做的是和開發人員進行溝通，而不是直接把bug進行reject操作。（讓開發人員給出原因 這樣不是更好嗎）
bug驗證不通過，可能存在很多方面的問題：
1.1 版本編譯問題（版本控制）
1.2 多封閉版本提交錯誤問題
1.3 模塊編譯和整體編譯時間不一致問題
1.4 測試人員版本未更新（指定專人更新測試服務器 或者持續化集成）
1.5 測試人員驗證條件不滿足，實際bug未得到有效驗證。
1.6 開發人員resolve為模塊提交時間，和實際版本可獲取時間有提前性。
很多時候，bug驗證未通過，不是開發人員或者測試人員的問題，流轉環節的問題，需要大家一起溝通討論，才能定位，從而提高團隊的運作效率。
同時，針對resolve的bug，特別是很難復現的bug，也希望開發人員能夠說明解決的問題點，給出建議的測試方法。
針對必現或者很容易復現的bug，測試人員知道驗證方法，按照原來的操作步驟進行多次驗證，如果未出現問題，那么就認為解決。
針對很難復現的問題，如果沒有開發人員的指導，測試人員去驗證此類的問題，只能依靠拷機，大規模的覆蓋測試，一段時間后沒有出現此bug，再進行關閉。實際上，這種驗證方式，效率很低，而且不一定真正的驗證到了問題點。
所以這是一個雙向溝通的過程：開發人員主動的說明問題原因、解決方案和相關測試建議；測試人員主動去詢問問題原因、解決方案和相關測試建議。
二、一個較難復現的問題出現，bug打出去，開發人員要求復現，到底要不要做？（先分嚴重性，然后按步驟復現）
針對這個問題，開發人員和測試人員每天都要糾結好一陣。從產品線現狀而言， 也不可能做到一刀切，按照嚴格的要求去必須復現或者必須不去復現。
無論是開發人員或者測試人員，大家都有自己的任務指標。很多時候，就需要動態的把握具體的工作。
是否要復現某問題，給測試人員提出幾個判斷的標準：
1、開發人員是否沒有相關測試設備、測試環境，必須要使用測試環境來復現。
高清項目以來，很多設備單價都很高，產品線的設備不多，或者新產品的demo板卡不多，針對這種情況，測試肯定是需要協調資源，提供給開發人員自行復現，或者幫忙復現問題的。還有，比如大容量的測試，長考，mcu的三級級聯適配邏輯等，都可以根據實際的bug情況，很直觀的判斷是否需要在測試環境進行復現。
2、如果要復現問題，開發人員是否提供捕獲信息的要求，提供新版本進行復現？
一個bug出現，大家在測試環境查了半天沒有定位，然后重啟，回頭給測試人員說，再復現一下。--------這種表現，是效率很低的體現。
如果一定要復現問題，希望能大致判斷幾個問題點，然后和測試人員溝通下，需要如何捕獲信息，捕獲那類信息？是不是提供debug版本進行復現，或者根據預判的點增加打印信息版本進行復現？
一個很淺顯的認識： 一個bug，如果出現問題后，根據結果狀態無法定位，那么再復現出現問題，我們認為依然無法定位。那么我們就嘗試捕獲問題出現前，問題發生過程中的一些狀態、邏輯。那么肯定就涉及到對一些信息進行捕獲，對一些過程態進行打點、跟蹤和反饋。
這也是希望開發人員能積極和測試人員溝通的點。
如果一定要復現問題，那么，讓我們大家的工作更有價值，有效率。
3、問題或者項目優先級。