靈活開發中常見的幾種軟體測試方法

參考文章：http://www.51testing.net/study/basis/69945.html

回歸測試

回歸測試，是軟體維護階段對軟體修改後進行的測試，指修改了舊代碼後，重新進行測試以确認修改沒有引入新的錯誤或導緻其他代碼産生錯誤。

回歸測試主要應用在代碼變更的場景，我們需要測試修改後的代碼是否影響軟體應用程式的其他功能。 此外，當将新功能添加到軟體應用程式中并用于缺陷修複和性能問題修複時，同樣需要進行回歸測試。 為了執行回歸測試過程，我們需要首先調試代碼以識别錯誤。一旦發現錯誤，就進行必要的更改以修複它，然後通過從涵蓋代碼的修改部分和受影響部分的測試套件中選擇相關的測試用例來完成回歸測試。

自動回歸測試将大幅降低系統測試、維護更新等階段的成本。回歸測試作為軟體生命周期的一個組成部分，在整個軟體測試過程中占有很大的工作量比重，軟體開發的各個階段都會進行多次回歸測試。

冒煙測試

每個測開的大佬，都會經曆過：

• 修複了1個缺陷，引入10個缺陷；
• 開發大佬提供的版本，不是閃退，就是無法運作，計劃中的特性測試根本沒辦法開展。

每次出現這種情況，都需要PM出面，否則…（可能會休長假…）

而解決這些問題，最好的方法就是，給開發送出測試版本設定的一道防線，即冒煙測試。

如果說回歸測試是追求大而全，那麼冒煙測試追求的就是小而精。

冒煙用例/測試環境/執行入口 由測開人員提供，覆寫本次送出版本的核心功能，涉及主流程。

冒煙測試通過，可以說明開發的代碼改動沒有很大問題，軟體也有了基本的品質保證，後續的測試階段也可以陸續展開。

冒煙測試作為開發提測的一道防線，可以減少浪費，送出效率。

冒煙[測試用例](javascript:;)比較少，因為開發和維護成本就低很多。

主要的成本是冒煙用例失敗的定位分析成本，這是一件持續的事情

冒煙測試就是完成一個新版本的開發後，對該版本最基本的功能進行測試，保證基本的功能和流程能走通。

如果不通過，則打回開發那邊重新開發；

如果通過測試，才會進行下一步的測試(功能測試，內建測試，系統測試等等)。

簡化：門檻測試，一個開關而不是一個階段。

**目的：**版本驗證測試BVT（Build Verification Testing）。

**時間：**開發轉測試，曆時半至一個小時，很短。

**對象：**需求覆寫，主功能路徑。

**優點：**節省測試時間，防止build失敗。

**缺點：**覆寫率還是比較低。

**操作：**對着需求文檔把新功能過一遍；把所有流程功能走一遍；用monkey跑個一兩個小時；如果有曆史用例的話，可以把用例分級，冒煙級、詳細級、回歸級等等

**用例：**冒煙測試基本上不需要什麼用例，如果有的話，就用詳細用例裡，覆寫需求文檔級别的用例就可以了

冒煙測試，是版本驗證測試，主要确認新的版本是否存在緻命性bug，冒煙測試最大的優點在于節約測試的時間成本，減少測試輪數。

灰階測試

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

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

軟體運作的終極環境是生産環境，隻有在生産環境測試通過，我們才能說軟體有風險的幾率非常低。但是在生産環境做測試，風險是很大的，對使用者的影響也很大，這個時候，就需要引入灰階測試。

引入灰階環境

在灰階測試中，通常将待發版的軟體部署到部分生産環境(即灰階環境)上，然後将測試流量或者部分使用者流量引入到灰階環境。

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

灰階測試實作了在生産環境對軟體的終極驗證，是軟體釋出前的最後一道防線。它的投入(環境配置/引流/自動化用例)等是一次性的，但是其産出是顯著的(提前于使用者發現問題)，并且可以持續産出(每一次軟體更新都受益)。

單元測試

軟體的問題，90% 都是編碼的問題

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

那麼，單元測試，如何執行呢？

一句話，就是 一行一行執行代碼。

隻要讓代碼跑起來，才能發現代碼的問題。

單元測試帶來的收益，還有很多，例如：更好的子產品設計，更放心的代碼重構等等。

當然，任何事情都有兩面性，單元測試也不例外，這需要持續的編寫測試代碼。

這也就是出現了兩極分化的情況，支援派與反對派。

一般的大廠，都會做單元測試，因為這是減少缺陷，提高效率的方式；

而一些小廠，可能就不會考了這麼多，畢竟人員，資源都有限…

一些追蹤問題平台

Jira、禅道等