曾經瓮床，在星球「軟件測試圈」，問了4個問題：

1. 你所在公司产镐，是否有研發(fā)自測環(huán)節(jié) 隘庄？

2. 這個自測范圍和內容誰提供 ？每個提測版本癣亚，研發(fā)都自測哪些內容 丑掺？

3. 測試準入標準是什么 ？自測未通過的逃糟，如何處理 吼鱼？

4. 測試通過標準（上線標準）

此文闡述，一些參考做法：

**001 研發(fā)自測 **

一般來說绰咽，都是需要「研發(fā)自測」的菇肃，甚至有些項目，研發(fā)自測完取募，就可以直接上線琐谤，不需要測試同學的參與 。
那么自測內容玩敏，誰提供呢斗忌？提供哪些內容 ？測試會根據自己的任務將對應的需求拆解功能點旺聚，然后輸出冒煙測試的測試點织阳，放在confluence平臺（此處平臺，很多砰粹，比如 TAPD / xmind文件也行 / Excel放在svn也行唧躲，方式不重要，團隊內部協商即可），這個文檔作為研發(fā)自測范圍和自測內容（至于這個文檔是否需要經過評審弄痹？最好評審一下饭入，跟開發(fā)、產品碰一碰）肛真，測試的功能點可以寫粒度也是比較大的點谐丢。每一個提測版本，研發(fā)人員負責自測自己開發(fā)的功能點即可蚓让，保證主流程沒有問題（基礎的業(yè)務聯調乾忱，那是必須的，否則凭疮，冒煙都通過不了） 饭耳。

補充串述，
實際跟N多測試同學溝通后执解，很多公司，是沒有研發(fā)自測的纲酗，導致的結果就是衰腌，一個版本，提交了上百個Bug觅赊，非秤胰铮恐怖 。
對于吮螺，一個版本饶囚，總共就幾個Bug的同學，是無法理解的 鸠补。

提測版本質量爛萝风、Bug多，效率低紫岩，且累规惰，而且經常加班 。
寫B(tài)ug要時間泉蝌、錄Bug要時間歇万、改Bug要時間、驗Bug要時間勋陪、重復寫B(tài)ug要時間 ...

002 測試準入標準

1. 手動執(zhí)行冒煙測試用例贪磺，且都測試通過（打包時，自動執(zhí)行新業(yè)務的接口自動化測試诅愚，以及已有業(yè)務的自動化接口測試寒锚，通過后，準入 。）

2. 轉測資料齊全

3. 部署資料正確

4. SVN和Git的代碼提交記錄正常有效

5. 上次的問題修復率達到要求

自測沒通過的咋辦 壕曼？版本打回苏研，郵件通知全團隊，待提交新版本再測試腮郊，上線時間摹蘑，順延 。實際情況是轧飞，提測延期衅鹿，上線時間，定死过咬，咋辦 大渤？

1. 加班，趕工 掸绞。

2. 實在搞不定的泵三，參考下面的“通過標準”，最后的做法 衔掸。

003 測試通過標準

注：如下這段烫幕，來自妹紙“紫蕓”，在「軟件測試圈」的主題 敞映。近期上線的某個項目并未達到測試組管理規(guī)范設定的通過標準较曼，但因市場等各種原因，算妥協發(fā)布了正式版振愿。對于這類項目的報告出具等很費心捷犹，因為遺留問題實在太多，不出具報告對自己不利冕末，出具報告有違背起初設定的通過標準萍歉。 什么才是測試通過標準？以往常有聽過領導問：“這個項目怎么就是測試通過了栓霜？”也常有開發(fā)問：“項目怎么才算通過測試翠桦？” 一系列的疑問，最好的解決方式是什么胳蛮？重新審視了測試通過標準销凑，感覺本身有缺陷：太過完美，看似可量化仅炊，站在不同角色看斗幼，實則無法很好量化，如何優(yōu)化測試通過標準抚垄？當前功能測試方面使用的部分通過標準：

1蜕窿、測試方案/用例覆蓋程度：95%以上谋逻；

2、測試輸出結果與預期輸出之間的符合率：95%以上桐经；

3毁兆、測試方案/用例的執(zhí)行程度：100%；

4阴挣、缺陷處理情況：缺陷等級非常重要气堕、重要（P0、P1）需全部關閉畔咧，一般茎芭、建議性缺陷<10%。開發(fā)和測試有爭議的缺陷需要經項目小組討論后決定是否需要修改（拉上產品經理誓沸、項目經理梅桩、業(yè)務方），若經討論后確認可以忽略不改或因其他原因要在以后的版本中實現拜隧，則本次測試可以認為通過（這里非常重要：遺留的問題宿百，一定要跟團隊討論，確定可遺留到下個版本虹蓄，而且要在測試報告中犀呼，注明已知問題 & 風險）。

End 薇组。

最近，很多同學坐儿，咨詢此類疑惑律胀，希望此文的內容梳理，對你有參考作用 貌矿。

注：此文內容炭菌，摘自「軟件測試圈」

原文鏈接 http://istester.com/tester/298.html
作者：IDO老徐
原創(chuàng)文章，禁止轉載