1. 你所在公司，是否有研發自測環節 ？
2. 這個自測範圍和內容誰提供 ？每個提測版本，研發都自測哪些內容 ？
3. 測試准入標準是什麼 ？自測未通過的，如何處理 ？
4. 測試通過標準（上線標準）
**001 研發自測 **
一般來說，都是需要「研發自測」的，甚至有些專案，研發自測完，就可以直接上線，不需要測試同學的參與 。
那麼自測內容，誰提供呢？提供哪些內容 ？測試會根據自己的任務將對應的需求拆解功能點，然後輸出冒煙測試的測試點，放在confluence平台（此處平台，很多，比如 tapd / xmind檔案也行 / excel放在svn也行，方式不重要，團隊內部協商即可），這個文件作為研發自測範圍和自測內容（至於這個文件是否需要經過評審？最好評審一下，跟開發、產品碰一碰），測試的功能點可以寫粒度也是比較大的點。每乙個提測版本，研發人員負責自測自己開發的功能點即可，保證主流程沒有問題（基礎的業務聯調，那是必須的，否則，冒煙都通過不了） 。
補充，實際跟n多測試同學溝通後，很多公司，是沒有研發自測的，導致的結果就是，乙個版本，提交了上百個bug，非常恐怖 。
對於，乙個版本，總共就幾個bug的同學，是無法理解的 。
提測版本質量爛、bug多，效率低，且累，而且經常加班 。
寫bug要時間、錄bug要時間、改bug要時間、驗bug要時間、重複寫bug要時間 ...
002 測試准入標準
1. 手動執行冒煙測試用例，且都測試通過（打包時，自動執行新業務的介面自動化測試，以及已有業務的自動化介面測試，通過後，准入 。）
2. 轉測資料齊全
3. 部署資料正確
4. svn和git的**提交記錄正常有效
5. 上次的問題修復率達到要求
自測沒通過的咋辦 ？版本打回，郵件通知全團隊，待提交新版本再測試，上線時間，順延 。實際情況是，提測延期，上線時間，定死，咋辦 ？
1. 加班，趕工 。
2. 實在搞不定的，參考下面的「通過標準」，最後的做法 。
003 測試通過標準
注：如下這段，來自妹紙「紫芸」，在「軟體測試圈」的主題 。近期上線的某個專案並未達到測試組管理規範設定的通過標準，但因市場等各種原因，算妥協發布了正式版。對於這類專案的報告出具等很費心，因為遺留問題實在太多，不出具報告對自己不利，出具報告有違背起初設定的通過標準。 什麼才是測試通過標準？以往常有聽過領導問：「這個專案怎麼就是測試通過了？」也常有開發問：「專案怎麼才算通過測試？」 一系列的疑問，最好的解決方式是什麼？重新審視了測試通過標準，感覺本身有缺陷：太過完美，看似可量化，站在不同角色看，實則無法很好量化，如何優化測試通過標準？當前功能測試方面使用的部分通過標準：
1、測試方案/用例覆蓋程度：95%以上；
2、測試輸出結果與預期輸出之間的符合率：95%以上；
3、測試方案/用例的執行程度：100%；
4、缺陷處理情況：缺陷等級非常重要、重要（p0、p1）需全部關閉，一般、建議性缺陷<10%。開發和測試有爭議的缺陷需要經專案小組討論後決定是否需要修改（拉上產品經理、專案經理、業務方），若經討論後確認可以忽略不改或因其他原因要在以後的版本中實現，則本次測試可以認為通過（這裡非常重要：遺留的問題，一定要跟團隊討論，確定可遺留到下個版本，而且要在測試報告中，註明已知問題 & 風險）。
end 。
最近，很多同學，諮詢此類疑惑，希望此文的內容梳理，對你有參考作用 。
注：此文內容，摘自「軟體測試圈」
效能測試通過標準
對於效能測試，在測試過程中需要通過觀察一些目標，根據這些目標的結果來判斷是否滿足要求，主要包含如下 業內對於效能測試有一些通用的通過標準，這裡給出乙個web專案效能測試通過標準，作為樣板 基本都遵循2 5 10，2s以內最佳 說明 另外需要強調的是，每個專案對於是否通過的標準不盡相同，實際執行中，優...
測試通過與失敗的標準
一般公司不同，標準也不同，以下僅為參考 測試通過與失敗的標準 系統測試執行對需求達到覆蓋100 系統功能測試，高階別和中級別測試用例100 執行，低級別用例執行率達到60 缺陷修復率達到80 及以上，且無致命及嚴重級別的缺陷未修復 測試掛起的標準及恢復的必要條件 如果測試過程中發生致命問題，導致50...
效能准入標準與建議
1.web互動型 通過瀏覽器與後台互動並實現各項功能 2.後台介面型 通過介面方式提供服務並實現各項功能 3.離線計算型 通過指令碼定時 儲存過程的方式實現後台離線計算 針對這幾類應用我們給出一些效能准入測試的建議，見下表 模組型別 指標閾值 備註web互動型 瀏覽器端操作響應時間 90 小於3秒 ...