這篇文章我主要想記錄學習一下在軟體測試行業中的一些常見理論效應以做基本瞭解。

一、殺蟲劑效應

1、殺蟲劑效應介紹

　　殺蟲劑效應原本指農業中隨著農藥的普及使用，害蟲對農藥的抗藥性就越來越強，農藥就越來越難殺死害蟲。在農場裡為了對付破壞農作物的害蟲，農業專家開發出了對應的殺蟲劑，剛開始效果很好，但是隨著時間的流逝，害蟲適應了殺蟲劑，產生了抗藥性，這些原有的農藥就越來越難殺死害蟲，必須設計新型的殺蟲劑來對付害蟲。

　　在軟體測試中這個理論是由《軟體測試技術》一書的作者Boris Beizer在30年前提出的。在軟體測試中殺蟲劑效應指的是：如果你不斷重複相同的測試，那麼軟體會對你的測試產生免疫，多個版本迭代下來，最終這些相同的測試用例將不再能發現新的bug。

　　這是因為幾輪下來，在這些用例覆蓋的領域，bug已經被修復的差不多了，而且在測試人員發現bug的地方，開發人員也會格外關注和小心，這樣最終軟體對這些測試產生了免疫，就很難再發現新的bug了。

　　我們把軟體測試的殺蟲劑效應放到農業中解釋下：農藥：軟體測試員 —— 害蟲：bug —— 農作物：被測軟體

　　現狀：隨著被測軟體的規模越來越大，功能越來越複雜，越來越多的缺陷開始出現，我們的測試工程師對其進行不斷的進行測試、不斷的迴歸，但仍然發現每次測試仍然會發現很多的缺陷（測試無窮盡）。

　　原因：（1）被測軟體越來越大，功能越來越複雜（害蟲抵抗力越來越強）；（2）測試人員思維定勢，使用測試技術和方法單一（長期使用同一款農藥）。

2、從農業迴歸到IT測試行業：

　　只要做過軟體測試的測試人員都會發現一個有趣的現象：開發剛轉測當天，測試人員是一個bug接一個bug的提，但隨著測試進度的推進，每天發現在的缺陷會越來越少，到最後簡直就是不能夠發現缺陷了。

　　但是能說這個軟體中不存在缺陷麼?我相信哪個測試人員都沒有這樣的自信保證自己測試的軟體中沒有bug了，那為什麼存在中明明不存在缺陷，而測試人員就是發現不了呢?

　　這是因為測試人員對缺陷產生了免疫能力，就算是一個bug放在測試人員面前，測試人員也不一定能發現。這就像害蟲對殺蟲劑產生了免疫，殺不死一樣的。那應該怎麼解決這個問題呢，我相信這是所有測試人員都關注的一個問題。

3、解決方法：

（1）內部測試人員交叉測試，測試團隊成員對被測系統交叉模組測試。（使用不同品牌的農藥）

（2）測試用例常用常更新，在測試過程中根據軟體的特性修改測試用例。

（3）不斷地變化測試方法，不要使用單一的測試方法去測試軟體，根據軟體內容使用不同的測試手段、測試方法。

　　測試人員提升自己能力，掌握新技能，新思想，新方案，用更多測試技術提高測試覆蓋率。（修改農藥配方，提升配方質量）

（4）引入更高階測試人員，同時對現有技術人員進行技能培訓。（提高使用農藥濃度）

　　根據上面四種方法交叉執行，從而發現更多的缺陷，保證軟體質量，降低風險。

　　所以永遠不要停止測試，永遠不要停止思考，永遠不要相信某一種方法或者工具可以幫助你解決所有問題！在這崗位上就不要停止學習新的技術和方法！

4、那如何防止殺蟲劑效應呢？

（1）根據產品變更，持續維護和更新你的測試用例

　　不管是大的變更還是瑣碎的變更，都要及時增加相應的新用例；並分析對已有功能的影響，修改受影響的現有用例。

（2）改變原有測試資料

　　在實際工作中，我們會發現，有很多生產環境的bug都是和具體資料相關的缺陷，所以在原有測試資料發現缺陷越來越少甚至發現不了缺陷的情況下，應該嘗試去增加或者更新一下舊的測試資料。

（3）同行測試

　　讓同行，可以是測試同行、也可以是產品經理、運維人員、甚至是新人等，參與進來進行測試，他們會從一些新的視角，嘗試一些新測試場景，發現一些新的bug。

（4）減少已經有殺蟲劑效應的測試用例或者降低它們的優先順序

　　比如對於一些用例來說，他們在10次迴歸測試中都沒有發現bug，這個時候就要review評審一下這些用例，說明系統已經對它們產生了殺蟲劑效應，除了冒煙測試級別的用例外，就要適當減少這些用例的數量，或者降低這些用例的執行優先順序。

　　因為隨著時間推移，系統逐漸變的龐大，這些用例的數量也將越積累越多，他們在每次迴歸中可能都會佔用很大比例的執行時間，一般來說如果這些用例在5次迴歸執行中都沒有發現缺陷，就要考慮減少他們的數量或者降低它們的執行優先順序，以提升測試執行的效率，同時保證測試質量。

二、金字塔模型：

1、金字塔模型介紹

　　在敏捷方法中，持續整合是其基石，持續整合的核心是自動化測試。關於測試金字塔，來自Martin Fowler。在他的書《Succeeding With Agile》中詳細描述著：“測試金字塔最底層是單元測試，然後是業務邏輯測試，最後是端到端的測試（GUI或CLI）。”模型如下圖：

　　金字塔模型大約是在10年前，隨著敏捷流程的出現，由敏捷專家Mike Cohn提出的。金字塔模型是對整個軟體開發過程中所有測試工作的一個理想指導模型，不僅涉及測試工程師的測試工作，同樣涉及開發人員的測試相關工作，尤其適用於當前敏捷模式中的自動化測試。

　　金字塔模型把整個開發流程中的所有測試由底到上分成了三大型別：

（1）最底層的單元測試（unit testing）：單元測試是基於程式碼層面的測試，重點在於驗證某個程式碼單元的功能是否正確，屬於白盒測試範疇，一般由開發人員自己進行。

（2）中間層的整合測試（integration testing）：整合測試的重點是測試元件與元件之間，模組與模組之間，或者更大的系統與系統之間的整合情況，屬於灰盒測試的範疇，根據情況一部分可以由開發人員進行，一部分可以由測試人員進行。

（3）最上層的UI層測試（User interface testing）：UI測試的重點在於在UI層模仿使用者使用系統，驗證系統是否符合使用者需求，屬於黑盒測試的範疇，一般由測試人員進行。

2、金字塔模型原則

　　金字塔模型給出了在整個專案開發中，這三大測試型別的理想佔比：單元測試的比重應該佔70%以上，整合測試的比重佔20%左右，UI層測試的比重小於10%。

　　這種佔比的金字塔模型體現了兩個原則：

（1）缺陷越早被發現，解決的成本越低

　　有一個不同階段發現缺陷解決成本的統計：如果單元測試階段發現缺陷解決成本為1的話，那麼整合測試階段發現缺陷的解決成本就是10，到了UI層解決成本就是100。所以從成本考慮，應該更多的進行單元測試和整合測試。

（2）越底層的測試執行效率越高

　　執行一個單元測試，需要的時間可能是毫秒級別，而執行一個UI層的測試，連最簡單的登入驗證都需要幾秒鐘的時間，一個下單流程需要幾分鐘的時間，而一個複雜的End 2 End的流程可能需要幾個小時的時間。

　　而在當前的敏捷模式下，頻繁的版本釋出需要配合頻繁的測試驗證工作，如果UI層測試的佔比很大，每次驗證就會花很多的時間，勢必影響測試執行和專案釋出的效率。所以從這個層面考慮，也應該更多的進行單元測試和整合測試。

3、理解總結

　　我的理解是自動化測試金字塔模型中最底層是單元測試，中間層是整合/介面測試，最頂端是端到端的GUI測試。其實自動化測試金字塔模型並不是什麼新鮮內容，比較類似我們大家瞭解的MVC模型，有異曲同工之處。

　　自動化測試金字塔模型給我們帶來的啟示如下：

1、unit單元測試，速度快，且成本低（當然這裡的成本低，是指可以前移測試早發現問題，缺陷修復代價來講，但從目前如果開發要強制單元測試，成本其實並不低，影響因素也眾多）

2、ui端到端測試，速度慢，且成本高（與上面解釋類似）

3、Service整合和介面測試，處於二者中間，其實這塊我認為是測試收益最大，且最容易有成果和成效的部分；

4、自動化測試金字塔模型還給我們的啟示是，如果在進行ui測試時，發現缺陷，有可能是你的中間service層或是unit層有缺陷，我們應追朔本源，解決問題根據原因所在。

三、缺陷叢集性 (2/8原則)

　　世界上萬事萬物都符合二八原則，比如著名的財富理論：世界20%的人掌握了世界上80%的財富。還有成長理論：判斷一個人是否成功，主要看他20%的業餘時間做什麼事情。

　　軟體測試也符合二八原則:

1、功能：一個軟體20%為主要功能，會花費軟體測試人員80%的時間。

2、缺陷：一個功能模組發現的缺陷越高，那存在的未被發現的缺陷也越高，故：發現的缺陷與未發現的缺陷成正比。

　　軟體測試工作的分配比例應該與預期的和後期觀察到的缺陷分佈模組相適應。少數模組通常包含大部分在軟體測試版本中發現的缺陷或失效。這個符合80-20原則，即80%的缺陷發生在20%的模組中。

　　造成這種現象的可能性如下：（1）該模組功能比較複雜；（2）實現該功能模組的開發工程師水平比較低；

　　James Whittaker等著的《探索式軟體測試》書中提到對軟體災難區進行重點測試也是基於這點考慮的。

四、軟體測試活動依賴於軟體測試背景

　　在面試過程中有時總會遇到面試官問“做軟體測試什麼最重要”，想來做過測試的都知道“需求”最重要，對測試人員來說是需求，對公司來說就是業務。

　　根據業務的不同，軟體測試內部也分不同的行業，比如遊戲行業，金融行業，電商行業等等。不同的行業，測試活動的開展都有所有不同，比如工具的選擇，測試流程都不盡相同，所以軟體測試活動的開展依賴於所測試的內容。

五、軟體測試的7大基本原則

1、測試儘早介入

　　從分析不同的測試模型來看，測試介入的越早越好。為什麼測試要儘早介入呢？這要先弄清楚軟體測試的目的是什麼？簡單的來說就是保證軟體質量，降低成本。

　　測試人員一般都在需求階段就開始介入，這時測試的物件就是需求。

　　軟體測試的目的是保證質量，預防風險，降低成本，其中成本包括缺陷的修復成本，缺陷有一個特點就是越早發現的缺陷，修復成本越低，這也是為什麼測試要儘早介入，就是為了能夠在需求階段就能找出需求與設計方面的缺陷，降低後期的修復成本。

2、窮盡軟體測試是不可行的

　　理論上我們希望在軟體投入使用之前能夠通過軟體測試，把各種輸入和前提條件的組合都測試一遍。但在實際上這種窮盡的軟體測試是不可能實現的。一方面這種窮盡的軟體測試所消耗的工作量巨大，軟體的收益和成本不成比例；另一方面軟體中存在。一些無關緊要的缺陷，並不會影響軟體的使用。所以軟體通常會遵循一個 good enough原則——通過衡量測試的投入產出比，測試既不能太少，也不能太過。

3、軟體測試能夠發現軟體存在缺陷，但不能證明軟體沒有缺陷

4、缺陷叢集性（2/8原則)

5、殺蟲劑悖論

6、測試活動依賴於測試內容

　　不同領域的軟體測試都有它自己的特殊的測試策略。比如，軍用軟體會重視可靠性和安全性的測試，資訊化系統軟體則會強調壓力測試等效能的測試。

7、無法使用的軟體不需要測試

　　如果一個軟體根本無法正常使用，或者他最主要的軟體功能都不能正常使用這樣的軟體是完全沒有必要進行測試的。