論測試用例的有效更新及殺蟲劑悖論
在2014年，我們團隊試圖推動一件事情——把產品後端（客戶、客服、生產製造等等）出現的問題，反向增補爲測試用例，擴充到測試用例庫中，避免後續重複的出現問題——早些年柳傳志在創業類的節目問一個選手，作爲老闆，你每天第一件要處理什麼事情。選手按照自己的優先級和重要性說了一堆。柳傳志說：你應該優先處理反覆出現的問題。
覆盤論是聯想的看家本領，這也僅借用一下這個意思。
嘗試這麼做了一段時間，把已經形成的反向增補測試用例，推廣到相關測試用例庫，然後在實際中執行和檢查，一段時間大致有如下幾種現象：
一、絕大部分，根本不執行。
二、小部分，有選擇的執行。
三、小部分，重新編寫，納入到原有的測試用例中執行。
第一種現象的原因有很多種，光明正大的以及不那麼光明正大的——我更願意認爲是下文會提到的原因。
對於第二、三種現象，我被反問的問題是：如果沒有按照我們寫好的格式，單獨的拉取出來並有執行結果，那麼就無法通過人工或者工具來統計這些新增的用例是否被執行過？數據拿不到，由此就不能判斷大家在測試方面是否有優化和進步。
先暫時放下複雜的執行和檢查的針對性問題，僅僅從測試本身——一個問題出現，是否要把這個問題出現的步驟、缺陷的場景，類似可能出現的邏輯，都寫在測試用例中，在後續的項目中，反覆的執行？
答案是不一定——測試設計是一個領域的高手才做的事情，而不是單純的有一說一的死板描述。或者換個說法，測試用例是測試工作的核心，是充滿創造力的事情，而不是可以有一個什麼絕對正確的方法論，就可以一勞永逸搞定的。
列舉一些不同的例子，來展示表象和本質之間的複雜關係：
一、問題產生的原因，它的頻率是什麼？
EX1——如果問題是因爲開發人員錯手把一段代碼註釋，或者因爲各種筆誤產生的缺陷，發現之後修改代碼重新編譯，問題解決。
那麼這種問題的概率就是一次性的。這個缺陷修復後，再次出現的概率就非常小——除非這代碼是別人留下來的，然後換個開發，又膽大的修改了一些老代碼。然後自己的組長還沒有代碼審覈，直接提交了。那麼這問題纔有可能重見天日。正常針對這種情況，是沒有必要寫上幾條case，後續的項目每次都執行的。
EX2——有一個資源，多個模塊都會調用，而且這幾個模塊業務邏輯耦合的較爲緊密，而且聯調一直做的不好，甚至因爲解決缺陷還發生過多次扯皮到底是你的我的他的等破事兒。
那麼這種問題應該是有概率出現的。這個缺陷修復後，不僅僅這條缺陷產生的操作後續要增補，甚至這幾個模塊調用資源的一些方法，之前沒有太過注意，後續也要適當的加強測試設計。
二、問題涉及的組件、分支流、版本多少情況？
EX3——在嵌入式設備中，“兗”字無法顯示，顯示爲“口”。問題的原因是在嵌入式設備內存較小時，可能字庫採用的是一級字庫，那麼可能所有的二級字庫的文字都會顯示異常。
2.1、具有唯一性：
如果全公司使用的都是統一的font字庫。那麼只更新這個font，所有嵌入式設備的二級字庫問題都會得到解決，這個缺陷一次性修復後，就不需要納入到測試用例。
2.2、存在多分支：
有好多的外包項目，要顯示不同字體、不同國家的語言，簡而言之就是有好多的分支font存在。
2.A、如果有好的全面的缺陷分析和波及通知方式，大家各自修復，也不需要寫到測試用例中，因爲是一次性的行爲。
2.B、如果有一定的缺陷知會方式，不同的分支流可以感知，但是時效性較差，那麼這事兒就要固化在測試用例中，執行上一段時間。
2.C、如果沒有一定高度的缺陷知會方式，大家基於一個流，後續各自開發維護，那麼肯定要寫在測試用例中，甚至要組織小的專項測試，來集中暴露不同版本的問題。
三、是否有強順序依賴關係？
EX4——如果一個問題，和業務邏輯順序強相關，需要經過必須的1、2、3、4、5等步驟，纔會導致一個必然的bug。從測試人員的本職工作來說，能發現這樣的bug（俗稱神級bug），簡直是自己對業務知識瞭如指掌的最好表現，甚至可以作爲自己的江湖軼事不斷的吹噓下去。
但是，這種bug，迴歸測試之後，真心不用把它形成測試用例，讓後面每一個項目，都去反覆的執行——強業務順序關係修復了，後續自然不會出現。至於是否有其他隱含的邏輯，是否需要進行其他的分支狀態測試，那是另外一回事兒。
四、驗證條件具不具備？
EX5——各種複雜的外廠商對通問題。
此類的bug，多是在現場，通過抓包分析、碼流分析，然後不停的替換臨時版本才能修復。如果是協議標準化方面，可以在測試環節加強，如果是各廠家飛速發展中產生的非標協議，誰也沒辦法，只能現場解決。
所以，你可以寫一條，A設備，需要接入甲廠家的XXX產品/乙廠家的YYY產品，進行ZZZ功能測試。但是，這些測試用例，不具備可執行性。
對於此類的互聯互通問題，最好的解決方案是，找到一個設備型號很多的客戶，維繫好客戶關係，發佈新產品的時候，自己帶臺設備過去，聯調就搞定了。
這個例子需要的是此類問題的測試策略和方案，而不是生硬的補充無法執行的測試用例。
EX6——長時間運行後導致的問題，比如XX設備運行三年後，器件老化，或者版本、文件無故丟失。
這就分別涉及了可靠性和flash反覆讀取，碎片和黑天鵝事件等。
測試這類的問題，要在短時間內模擬三年的效果，只能是通過上測試設備量，以及通過公式推導大概的穩定性。寫在測試用例裏面，在日常的工作中，顯然是無法實現的，還不如老老實實的做專項測試，集中人力、設備等等。把此類問題一次性搞定。
以上是由缺陷反向提煉測試用例的第一個概念——從問題中汲取經驗，避免以後再犯同樣的問題，思路和邏輯都是對的。但是絕對不意味着比着葫蘆畫瓢，有的問題可能就是一次性的，有的問題背後可能有更大的問題，有的問題你知道但是還只能看概率和投入產出比，或者嘗試通過其他方法來解決。
第二個概念和團隊和人有關係，一個團隊真實的運作，往往只有內部人知道。同理，問題產生的真實原因，往往是一個團隊內部被隱藏的，所以是否能寫出精準的測試用例，也只有團隊內部自己人才能搞的定。這就意味着如果測試用例更新不是自己部門內部主動觸發，而是第三方部門（質量部門、流程部門）驅動的，那麼就註定只會拿到一些樣子貨。
五、問題產生的真實原因，會讓你寫的case完全不一樣。
舉個例子：軟件客戶端解碼無聲音。
但是如果你增加一條測試用例：“軟件安裝/更新成功後，查看編解碼狀態是否正常，預期結果：圖像、聲音正常。”拿到這條用例的人會認爲編寫人秀逗了，這麼基本的東西早就測爛了，還正兒八經的新增，最後的結果要麼是不執行，要麼就是無腦打鉤通過。
但這個最基本的問題，會一次次的出現，背後自然有深層次的東西存在。
EX7：兼容性問題，某音頻格式經過翻轉，未考慮兼容性。
早期版本的音頻碼流發過來，解碼失敗，這種無聲音就是標準的兼容性問題——所以增補測試用例，就要寫成，和各產品各版本進行兼容性測試，看視音頻是否正常。
看起來是不是抓到實際問題了？但是這種用例也是理論上的全面用例，實際也不可能會被執行（參考六、測試用例的可執行性）——歷史產品可能有二十幾個，歷史版本可能也有二十幾個。你動動嘴皮子互聯互通，且不說是不是測試環境有這麼多設備，就是在一切順利的情況下，版本更換並測試一輪，也要個幾個工作日。在測試資源、時間一貫緊張項目背景的下，這條case會被執行纔怪。
結合上面的觀點，看編解碼組件的版本是否有變更，然後再決定是否執行編解碼不同版本之間的兼容性測試，然後通過等價類，選取產品和版本，讓測試執行在半個小時到一個小時可以被執行，纔是正解。
EX8：DLL被覆蓋的問題。系統先裝了產品的的編解碼插件，然後又裝了其他的播放器（暴風影音、千千靜聽都出現過此問題），同名編解碼插件被覆蓋，解碼失敗。
此類的問題，排查過程可能比較糾結，但是排查清楚後，是否要寫條測試用例，以後每次都納入執行呢：“首先安裝我司產品，然後安裝暴風影音，進行編解碼，看是否正常。預期結果：視音頻正常。”這種用例是否可執行？
看解決問題的方案是什麼：
8.1、如果解決方案是銷售規避——服務器是獨立安裝的，所裝軟件都是有標準版本，不允許安裝其他軟件，那麼這個問題根本就不需要解決。只需要卸載非允許軟件，重新安裝一次即可。
8.2如果解決方案是統一把dll的路徑由system目錄，修改到指定的目錄，規避dll被覆蓋的問題。那麼這條case就需要執行一段時間，並且要明確檢查，setup之後，查看XX路徑下的XX文件，是否更新成功這條檢查項。
8.3如果解決方案沒有統一指定，每個軟件團隊都是自己指定目錄，且dll的特性不一樣，有多個版本在同時使用，那麼必然會存在自己公司多款軟件調用dll衝突的現象，或者毫不客氣的說，部分人員連dll搜索路徑“當前目錄->system目錄->windows目錄->環境變量Path指定的目錄”都沒有考慮。那麼這事兒如果要暴露，就要找幾個人成立專項測試，甚至要週期性進行檢查了——但是一旦惡劣到這種情況，就是各軟件產品沒有統一的規則，大家關起門來自己按照自己的想法設定，並單純的認爲客戶只會安裝一款 產品。如果是我，肯定罷工——系統部門坐下來定個規則，大家一起修改一下，就可以一勞永逸，分分鐘的事兒。結果把問題甩給後端團隊，找幾個人費工費時，長期的去折騰。這是不拿別人當人看，也沒有考慮項目整體成本，或者乾脆就是沒有盡到責任，憑什麼讓測試人員來背鍋？
一個看起來相同的現象，因爲產生原因的不同，可能採用的行動是截然不同的。如果你不在項目組裏面，不對裏面的原因瞭如指掌。只是單純的督促某一個人員，這事兒是不是你的問題？這反而容易激發逆反情緒，對整體推進產品，會產生非常大的負能量。
六、測試用例的可執行性。
上文已經舉了一個例子。凡是隨意的寫出窮率測試的測試用例，都是不負責任的。
A：我寫了遍歷所有的接口，所有的格式，清清楚楚，你怎麼沒有測到？
B：你算過你這一行實際要測試多少時間麼？你寫一句話，我要折騰一個禮拜。
出了問題，你說你想到了，是執行人員偷懶，但是這麼緊張的測試時間，不可能給一個禮拜的時間去測試這麼一個基本功能。測試優先級、測試等價類劃分，甚至根據客戶使用概率做帶風險的暫不測試決定，不是測試設計該做的事兒麼？
形成一張圖表來闡述觀點。
這張表的目的並不是死記硬背，而是當你思考“這個問題的產生，我們要不要寫條case，然後一直去執行它？”的時候，能夠根據自己產品的實際特點，做出正確的分析判斷就可以。
所以迴歸一開始的問題，如果是按照冷冰冰的規範約定，所有的問題都必須納入到缺陷進行管理。在面對複雜多變的種種現實情況時，落地的樣式可能會多種多樣（不需要、選擇執行、長期例行覆蓋、短期覆蓋、專項重點解決）。
第三方部門的種種檢查方法，可能並不能套用到一條條的用現有用例中，而趨利避害的本能，向不瞭解業務的人，講解清楚的緣由和解決方案是非常麻煩的事情。所以往往實際的產品驗證方，與其試圖無謂的解釋清楚一二三四，還不如干脆做表面文章，寫幾條看上去通俗易懂的測試用例，大家反而會過的舒服一些。
按照驅動力3.0的概念，胡蘿蔔大棒會扼殺別人的積極性和創造力，所以通過智力定位並且寫出足夠牛B的測試用例這種高大上的行爲，通過標準化、檢查化的方式，往往會被變成寫水文的應付行爲——這不是本文的重點，就稍微點到爲止。
迴歸測試用例更新、優化本身。
除了由缺陷提煉出測試用例進行反向增補外，測試用例的基準庫，也要定時評審修改更新的。
這就是測試用例中的殺蟲劑悖論（pesticide paradox）——對軟件進行越多的測試，那麼該軟件對軟件測試人員的測試就越具有免疫力。或者字面理解，如果地裏長期只打一種農藥，那麼蟲子（bug）就會產生抗藥性，導致效果越來越差，最後殺不死蟲子。或者換個維度來描述：測試用例就是一種數據量化指標，你想考覈什麼，長此以往就必然會得到這種量化結果，但是對事情實際的提升，可能幫助不大。
可能一些測試用例在設計時是針對當時產品的一些薄弱環節。但是幾個項目測試完成，甚至幾年之後，這些測試用例的有效性就趨於爲0。
1、可能是代碼邏輯修復，此類問題再也不會出現；
2、可能是軟硬件變更，原來的測試方案需要調整；
3、可能是功能點優先級變化導致的測試用例優先級調整等等。
舉個例子，曾經在測試用例中，要求把版本放在發佈服務器之後，需要重新下載後，進行一次安裝測試，確認各模塊的版本號信息。這在當時的條件下，是必然的一個測試步驟。原因一、曾經出現過用不同的解壓軟件和斷點續傳下載工具，導致文件字節數大小不一致的問題；二、原來版本是一個文件夾，其中有各種ini、exe、bin、setup文件，很容易出現測試版本和發佈版本不一致的現象；所以重新進行安裝後檢查版本，是非常必要的行爲。
但是過了幾年之後，解壓縮軟件越來越多，兼容性越來越好。覆蓋解壓軟件越來越不可能，還不如指定解壓軟件及版本號更現實；發佈文件本身也不是一個文件夾，而是一個或幾個Zip包，也避免了人工複製粘貼多個文件，人爲混亂的風險；三、數據校驗也做的比之前好多了，沒必要採用土鱉的方法手動覈實。
所以，這條用例，毫無疑問可以刪除掉，畢竟下載、替換、看版本號，怎麼說也要兩、三個小時才能搞的定。
經年不變的測試用例，從工作性價比的角度來說，這就是無效的工作內容。就好像站在樓梯口的服務員，僅僅是因爲傳統而站在那裏，而不知道一開始僅僅是爲了提醒大家樓梯的油漆未乾。
從測試職責和風險來講，這就是推卸管理者的職責。無論怎麼說，常年不變的測試用例，就意味着多年沒有進步的測試團隊，這是毋庸置疑的。