這篇文章我主要想記錄學習一下在軟件測試行業中的一些常見理論效應以做基本了解。
一、殺蟲劑效應
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、無法使用的軟件不需要測試
如果一個軟件根本無法正常使用，或者他最主要的軟件功能都不能正常使用這樣的軟件是完全沒有必要進行測試的。