一、單元測試

單元測試引入

      軟件的問題，90% 都是編碼的問題。在編碼階段發現問題，不會對任何人有影響，并且可以隨手改掉，這也是成本最低，效率最高的。

      那么單元測試如何執行呢？一句話，就是一行一行執行代碼。只有讓代碼跑起來，才能發現代碼的問題。單元測試帶來的收益還有很多，例如：更好的模塊設計，更放心的代碼重構等等。

      當然，任何事情都有兩面性，單元測試也不例外，這需要持續編寫測試代碼。這也就是出現了兩極分化的情況：

      一般的大廠，都會做單元測試，因為這是減少缺陷，提高效率的方式；
      而一些小廠，可能就不會考慮這么多，畢竟人員、資源都有限…

投入產出比

      測試投入：🌟🌟🌟
      測試產出：🌟🌟🌟🌟🌟
      測試指數：🌟🌟🌟🌟🌟

冒煙測試引入

      每個測開的大佬，都會有過修復了1個缺陷，引入10個缺陷的經歷。開發大佬提供的版本，不是閃退就是無法運行，計劃中的特性測試根本沒辦法開展。每次出現這種情況，都需要PM出面，否則可能會休長假…..

      而解決這些問題，最好的方法就是給開發提交測試版本設置的一道防線，即冒煙測試。如果說回歸測試是追求大而全，那么冒煙測試追求的就是小而精。

      冒煙用例/測試環境/執行入口 由測開人員提供，覆蓋本次提交版本的核心功能，涉及主流程，冒煙測試通過，可以說明開發的代碼改動沒有很大問題，軟件也有了基本的質量保證，后續的測試階段也可以陸續展開。

      冒煙測試作為開發提測的一道防線，可以減少浪費，提高效率，冒煙測試用例比較少，因為開發和維護成本就低很多，主要的成本是冒煙用例失敗的定位分析成本，這是一件持續的事情。

投入產出比

      測試投入：🌟🌟

      測試產出：🌟🌟🌟🌟🌟

三、灰度測試

軟件的依賴

      軟件測試中，有一個根深蒂固，也是很普遍存在的問題：預發環境都OK的功能，上線后，就出現各種問題，在大廠的人，應該是很有感觸的。

      我們都知道，軟件是運行在特定環境中的，軟件的的實際行為與其所處的環境具有高度依賴性。

      軟件運行的終極環境是生產環境，只有在生產環境測試通過，我們才能說軟件有風險的幾率非常低。但是在生產環境做測試，風險是很大的，對用戶的影響也很大，這個時候，就需要引入灰度測試。

引入灰度環境

      在灰度測試中，通常將待發版的軟件部署到部分生產環境(即灰度環境)上，然后將測試流量或者部分用戶流量引入到灰度環境。

      如果你是某軟件非常活躍的用戶，你會收到某新功能的體驗邀請。例如：支某寶邀請你參加體驗xx新功能、某信邀請你體驗xx新功能......

      灰度測試實現了在生產環境對軟件的終極驗證，是軟件發布前的最后一道防線。它的投入(環境配置/引流/自動化用例)等是一次性的，但是其產出是顯著的(提前于用戶發現問題)，并且可以持續產出(每一次軟件升級都受益)。

投入產出比

      測試投入：🌟
      測試產出：🌟🌟🌟🌟🌟
      測試指數：🌟🌟🌟🌟🌟

      注：尊重原創文章,轉載請注明出處和鏈接 http://m.hebeijilong.cn/news-id-19342.html 違者必究！部分文章來源于網絡由培訓無憂網編輯部人員整理發布,內容真實性請自行核實或聯系我們，了解更多相關資訊請關注軟件測試頻道查看更多，了解相關專業課程信息您可在線咨詢也可免費申請試課。關注官方微信了解更多：150 3333 6050