你是否碰到過開發提測速度很快，導致項目排隊，結果介入測試時，第一條用例都跑不通的情況？

你是否碰到過因為開發提測質量差，導致反復修改，反復提測，反復重復驗證的情況？

你是否碰到過因為開發提測質量差，導致一個修改影響了一大票老功能，從而讓項目質量岌岌可危的情況？

你是否碰到過因為開發提測質量差，導致項目後期通過壓縮測試時間來保證項目進度的情況？

你是否碰到過開發拍胸脯承諾這次肯定沒問題，結果測試數據稍一變通就跑不通過的情況？

不管你有沒有碰到過，我反正是全都碰到過。

有人說，這開發太水了，咋不自測呢？

有些確實是沒有自測導致的，但是有一些開發確實自測了，但是自測的結果是沒問題的。

一方面開發自測時都是針對自己修改的內容進行自測，這種情況往往發現不了啥問題，畢竟自己對自己的代碼太熟悉了。

另一方面開發自測時，大部分都是通過調試來看效果，並不是真正的用戶環境，甚至連測試環境都算不上，那麽這種自測的效果就很差。

那有沒有什麽好的解決辦法呢？有。

二

下面提供幾個操作建議供參考：

1.提供給開發人員自測需要的環境

比如我們是 Windows 客戶端的軟件，經常需要覆蓋不同的 Windows 系統版本，很多開發都沒有很全的系統版本的環境，所以提測的時候只會在一個他自己常用的環境進行自測。

有時候出現問題，他們的借口也可以是自己沒有現成的環境，搭建環境需要時間太多等等，那好吧，我們給提供需要的各種拿來即用的環境就好了，反正我們測試也是要準備各種各樣的環境的。

其實和幾個開發的溝通發現，他們還是挺高興有這些環境的，所以可能真不是人家不想自測。

那既然可以兩全其美，何樂而不為呢。

2.提供開發人員自測的測試用例

我們在收到開發的提測通知後，經常的對話就是「自測沒？」，「這次真的自測了。」，結果一冒煙，依然有問題，開發帶著震驚的表情過來一看，不好意思，這個場景我們考慮到，但是我確實自測了呀，你看測試數據換成這樣肯定沒問題。

是滴，不是沒有自測的錯，只是測試的內容和我們預期的不一樣，也就是每個人對「自測」的理解不一樣，那我們明確下自測的詳細要求就好了唄。

目前我們組幾個同學的方法就是直接丟給開發冒煙測試的用例，必須把這些用例跑通過了才能提測。

開發其實也挺樂意這樣做的，畢竟目標明確，還能避免反復低質量提測，何樂而不為呢。

3.提供提測時的前置自動化校驗

上面說的兩種方法都是人工幹預，既然是人工幹預，就會涉及到人的不可控性，為了避免人的因素造成的問題，我們又在提測系統中增加了一些必要檢查點的自動化檢測邏輯。

比如文件簽名屬性的檢查，一方面這是對所有文件的通用檢查要求，另一方面檢查的規範要求的十分明確，那麽這種就特別適合做成自動化實現，如果檢查有問題，直接阻止提測，減少交互造成的時間浪費。

這地方提醒下，所有的阻止項一定要給明確的說明，避免開發不知道什麽原因被阻止，也不知道怎麽修改，那就尷尬了。

4.提供冒煙測試的自動化用例

在一些自動化落實程度比較高的項目中，如果已經有主要用例完成了自動化用例覆蓋，完全可以把自動化執行接入到提測流程中，提測前必須過自動化用例檢查。

這樣一方面可以節省開發準備環境的時間，另一方面開發對用例的關註程度也可以減弱了，所有的結果和問題都可以在自動化用例實現上進行完善。

三

其實對於一些要求開發進行充分單元測試的項目，上面這些擔心都不是必要的，因為我們提供的解決方法都包含到單元測試的要求裏面了。

但是基於國內的現狀，能完整開展單元測試的項目並不多，那麽質量保證的任務就全部落到測試人員的身上了。

有同學可能對上面的方式有一些疑問，比如測試是不是做的太多了，提測質量的要求本來就是需要開發做到的，現在他們做不到，卻還讓測試幫忙額外做這麽多事情，太沒有道理了。

其實之前我也是這麽想的，後來發現測試工程師的主要工作職責其實就是質量保證，那麽所有和質量保證相關的事情，測試都可以去推進，這也是很多公司衍生出 SQA 的原因。

那如果從質量保證的角度想想，是不是上面做的這些事情就很有必要了，只是把一些測試人員需要做的事情前置了，但是帶來的好處卻是比投入要大的多，畢竟誰都知道早期發現問題的修改成本要比後期發現再修改的成本低的多。

以上，關於冒煙測試你有什麽看法和想法，歡迎給我留言討論。

本文首發於公眾號「sylan215」，十年測試老司機的原創幹貨，關註我，一起漲姿勢！

如何通過冒煙測試前置來把控提測質量？