一：自測背景
開發人員做好自測，非常必要，也是大趨勢。前期都是開發自測（包含必要的測試），後期才是使用者體驗方面的測試；從成本上分析，BUG越晚發現修複成本越高；從修改的效率來講，越早處理會越快。另外，寫出高品質的代碼，是能力的展現，專業的展現，自身價值的展現。一個優秀的開發者，自測的bug一定會多于測試發現的bug，也就是輪到測試的時候bug數量相當少。
二：疑難問題
- 時間和進度太緊張
- 對自己代碼過于自信，自認為很健壯，不忍心去修改
- 認為這是測試的責任，多度依賴測試
- 不知如何有效的做好自測，覆寫全面
三：思維轉變
- 代碼品質、項目品質均是我們的責任。
- 測試和開發人員思考問題不同，開發是在制造軟體，測試是在破壞軟體，想辦法去找出問題。
- 任何功能都有正常場景和異常場景，多數使用等價類和邊界值去選擇資料，覆寫全面。
- 不要相信任何開發的代碼是無bug
- 走出具體實作時用的開發思維，站在需求和使用者的角度去自測是否通過，假如自己是使用者去測試你的功能
四：不好好自測帶來的痛處
- 需求遺漏：一旦被使用者發現此問題，使用者印象會大打折扣，可能直接從開始使用即放棄使用，将帶來非常大的客戶流失
- 功能事故：主流程功能沒有測試到位，或者異常場景沒有測試到位，導緻線上頻繁報錯，體驗極度不好，直接認為就是事故
- 需求延期上線：如果自測不充分，測試花大量的時間去溝通低等級bug，甚至主流程走不下去，這樣無疑會給開發帶來返工、重複測試、耗時、需求延期、項目延期等一系列問題。
五：自測報告規範
功能子產品介紹及背景介紹
- 功能、背景介紹
- 使用使用者群體介紹
環境資訊
- 版本号
- Hosts
- 預發or正式
- 賬密資訊
- 功能設計文檔以及UI設計圖等
評估時間
梳理好的自測點
- 編寫代碼時候記錄的業務點
- 需求變更的自測點
- 正反向場景測試點
- 易用性測試點
- 相容性
- 開發此功能是否會對其他功能造成影響（需要leader評估）
自測實際結果：
- 高等級bug數量
- 中等級bug數量
- 低等級bug數量
- 單元測試覆寫率
- 單元測試通過率
期望結果：
- 高等級bug數量為0
- 中等級bug數量為0
- 低等級bug數量不超過5
- 單元測試覆寫率90%
- 單元測試通過率100%
是否具備提測标準
- 實際結果在期望結果之内則表示通過，否則不通過。
六：測試案例--新增安全組規則
1.先找出我們要測試的測試點
1.1、規則方向
建立入口決定了規則方向，是以隻需要關注從哪個建立入口進入，觀察二者是否一緻
1.2、授權政策
1.3、協定類型
1.4、端口範圍
1.5、授權對象
1.6、優先級
1.7、描述
1.8、界面展示
2.像這種多種因子的測試，我們盡量交叉測試，這樣大大減少工作量.
2.1、正常場景和異常場景建立
2.1.1、我們輸入正常場景的資料，建立看能否成功
2.1.2、輸入上述資料異常的場景去建立，檢視确定按鈕，或者是否能建立成功。
比如這種情況就不能出現：
3.1、結合業務
3.1.1、企業安全組建立規則
因為涉及到業務的問題，暫時先舉例這麼多
七：祝福
最後祝願每一個developer都成為一名優秀的開發者，在代碼的世界裡，越走越遠。
備注：編寫代碼的時候記錄自測點，可以用xmind或者excel或者筆記本都可以，隻要最後羅列出來的都通過測試即可，要有記錄。