論測試用例的有效更新及殺蟲劑悖論

論測試用例的有效更新及殺蟲劑悖論

        在2014年，咱們團隊試圖推進一件事情——把產品後端（客戶、客服、生產製造等等）出現的問題，反向增補爲測試用例，擴充到測試用例庫中，避免後續重複的出現問題——早些年柳傳志在創業類的節目問一個選手，做爲老闆，你天天第一件要處理什麼事情。選手按照本身的優先級和重要性說了一堆。柳傳志說：你應該優先處理反覆出現的問題。

        覆盤論是聯想的看家本領，這也僅借用一下這個意思。

        嘗試這麼作了一段時間，把已經造成的反向增補測試用例，推廣到相關測試用例庫，而後在實際中執行和檢查，一段時間大體有以下幾種現象：

        1、絕大部分，根本不執行。

        2、小部分，有選擇的執行。

        3、小部分，從新編寫，歸入到原有的測試用例中執行。

        第一種現象的緣由有不少種，光明正大的以及不那麼光明正大的——我更願意認爲是下文會提到的緣由。

        對於第2、三種現象，我被反問的問題是：若是沒有按照咱們寫好的格式，單獨的拉取出來並有執行結果，那麼就沒法經過人工或者工具來統計這些新增的用例是否被執行過？數據拿不到，由此就不能判斷你們在測試方面是否有優化和進步。

        先暫時放下複雜的執行和檢查的針對性問題，僅僅從測試自己——一個問題出現，是否要把這個問題出現的步驟、缺陷的場景，相似可能出現的邏輯，都寫在測試用例中，在後續的項目中，反覆的執行？

        答案是不必定——測試設計是一個領域的高手才作的事情，而不是單純的有一說一的死板描述。或者換個說法，測試用例是測試工做的核心，是充滿創造力的事情，而不是能夠有一個什麼絕對正確的方法論，就能夠一勞永逸搞定的。

        列舉一些不一樣的例子，來展現表象和本質之間的複雜關係：

        1、問題產生的緣由，它的頻率是什麼？

        EX1——若是問題是由於開發人員錯手把一段代碼註釋，或者由於各類筆誤產生的缺陷，發現以後修改代碼從新編譯，問題解決。

        那麼這種問題的機率就是一次性的。這個缺陷修復後，再次出現的機率就很是小——除非這代碼是別人留下來的，而後換個開發，又膽大的修改了一些老代碼。而後本身的組長尚未代碼審覈，直接提交了。那麼這問題纔有可能重見天日。正常針對這種狀況，是沒有必要寫上幾條case，後續的項目每次都執行的。

        EX2——有一個資源，多個模塊都會調用，並且這幾個模塊業務邏輯耦合的較爲緊密，並且聯調一直作的很差，甚至由於解決缺陷還發生過屢次扯皮究竟是你的個人他的等破事兒。

        那麼這種問題應該是有機率出現的。這個缺陷修復後，不只僅這條缺陷產生的操做後續要增補，甚至這幾個模塊調用資源的一些方法，以前沒有太過注意，後續也要適當的增強測試設計。

        2、問題涉及的組件、分支流、版本多少狀況？

        EX3——在嵌入式設備中，「兗」字沒法顯示，顯示爲「口」。問題的緣由是在嵌入式設備內存較小時，可能字庫採用的是一級字庫，那麼可能全部的二級字庫的文字都會顯示異常。

        2.一、具備惟一性：

        若是全公司使用的都是統一的font字庫。那麼只更新這個font，全部嵌入式設備的二級字庫問題都會獲得解決，這個缺陷一次性修復後，就不須要歸入到測試用例。

        2.二、存在多分支：

        有好多的外包項目，要顯示不一樣字體、不一樣國家的語言，簡而言之就是有好多的分支font存在。

        2.A、若是有好的全面的缺陷分析和波及通知方式，你們各自修復，也不須要寫到測試用例中，由於是一次性的行爲。

        2.B、若是有必定的缺陷知會方式，不一樣的分支流能夠感知，可是時效性較差，那麼這事兒就要固化在測試用例中，執行上一段時間。

        2.C、若是沒有必定高度的缺陷知會方式，你們基於一個流，後續各自開發維護，那麼確定要寫在測試用例中，甚至要組織小的專項測試，來集中暴露不一樣版本的問題。

        3、是否有強順序依賴關係？

        EX4——若是一個問題，和業務邏輯順序強相關，須要通過必須的一、二、三、四、5等步驟，纔會致使一個必然的bug。從測試人員的本職工做來講，能發現這樣的bug（俗稱神級bug），簡直是本身對業務知識瞭如指掌的最好表現，甚至能夠做爲本身的江湖軼事不斷的吹噓下去。

        可是，這種bug，迴歸測試以後，真心不用把它造成測試用例，讓後面每個項目，都去反覆的執行——強業務順序關係修復了，後續天然不會出現。至因而否有其餘隱含的邏輯，是否須要進行其餘的分支狀態測試，那是另一回事兒。

        4、驗證條件具不具有？

        EX5——各類複雜的外廠商對通問題。

        此類的bug，可能是在現場，經過抓包分析、碼流分析，而後不停的替換臨時版本才能修復。若是是協議標準化方面，能夠在測試環節增強，若是是各廠家飛速發展中產生的非標協議，誰也沒辦法，只能現場解決。

        因此，你能夠寫一條，A設備，須要接入甲廠家的XXX產品/乙廠家的YYY產品，進行ZZZ功能測試。可是，這些測試用例，不具有可執行性。

        對於此類的互聯互通問題，最好的解決方案是，找到一個設備型號不少的客戶，維繫好客戶關係，發佈新產品的時候，本身帶臺設備過去，聯調就搞定了。

        這個例子須要的是此類問題的測試策略和方案，而不是生硬的補充沒法執行的測試用例。

        EX6——長時間運行後致使的問題，好比XX設備運行三年後，器件老化，或者版本、文件無端丟失。    

        這就分別涉及了可靠性和flash反覆讀取，碎片和黑天鵝事件等。

        測試這類的問題，要在短期內模擬三年的效果，只能是經過上測試設備量，以及經過公式推導大概的穩定性。寫在測試用例裏面，在平常的工做中，顯然是沒法實現的，還不如老老實實的作專項測試，集中人力、設備等等。把此類問題一次性搞定。

        以上是由缺陷反向提煉測試用例的第一個概念——從問題中汲取經驗，避免之後再犯一樣的問題，思路和邏輯都是對的。可是絕對不意味着比着葫蘆畫瓢，有的問題可能就是一次性的，有的問題背後可能有更大的問題，有的問題你知道可是還只能看機率和投入產出比，或者嘗試經過其餘方法來解決。

        第二個概念和團隊和人有關係，一個團隊真實的運做，每每只有內部人知道。同理，問題產生的真實緣由，每每是一個團隊內部被隱藏的，因此是否能寫出精準的測試用例，也只有團隊內部本身人才能搞的定。這就意味着若是測試用例更新不是本身部門內部主動觸發，而是第三方部門（質量部門、流程部門）驅動的，那麼就註定只會拿到一些樣子貨。

        5、問題產生的真實緣由，會讓你寫的case徹底不同。

        舉個例子：軟件客戶端解碼無聲音。

        可是若是你增長一條測試用例：「軟件安裝/更新成功後，查看編解碼狀態是否正常，預期結果：圖像、聲音正常。」拿到這條用例的人會認爲編寫人秀逗了，這麼基本的東西早就測爛了，還正兒八經的新增，最後的結果要麼是不執行，要麼就是無腦打鉤經過。

        但這個最基本的問題，會一次次的出現，背後天然有深層次的東西存在。

        EX7：兼容性問題，某音頻格式通過翻轉，未考慮兼容性。

        早期版本的音頻碼流發過來，解碼失敗，這種無聲音就是標準的兼容性問題——因此增補測試用例，就要寫成，和各產品各版本進行兼容性測試，看視音頻是否正常。

        看起來是否是抓到實際問題了？可是這種用例也是理論上的全面用例，實際也不可能會被執行（參考6、測試用例的可執行性）——歷史產品可能有二十幾個，歷史版本可能也有二十幾個。你動動嘴皮子互聯互通，且不說是否是測試環境有這麼多設備，就是在一切順利的狀況下，版本更換並測試一輪，也要個幾個工做日。在測試資源、時間一向緊張項目背景的下，這條case會被執行纔怪。

        結合上面的觀點，看編解碼組件的版本是否有變動，而後再決定是否執行編解碼不一樣版本之間的兼容性測試，而後經過等價類，選取產品和版本，讓測試執行在半個小時到一個小時能夠被執行，纔是正解。

        EX8：DLL被覆蓋的問題。系統先裝了產品的的編解碼插件，而後又裝了其餘的播放器（暴風影音、千千靜聽都出現過此問題），同名編解碼插件被覆蓋，解碼失敗。

        此類的問題，排查過程可能比較糾結，可是排查清楚後，是否要寫條測試用例，之後每次都歸入執行呢：「首先安裝我司產品，而後安裝暴風影音，進行編解碼，看是否正常。預期結果：視音頻正常。」這種用例是否可執行？

        看解決問題的方案是什麼：

        8.一、若是解決方案是銷售規避——服務器是獨立安裝的，所裝軟件都是有標準版本，不容許安裝其餘軟件，那麼這個問題根本就不須要解決。只須要卸載非容許軟件，從新安裝一次便可。

        8.2若是解決方案是統一把dll的路徑由system目錄，修改到指定的目錄，規避dll被覆蓋的問題。那麼這條case就須要執行一段時間，而且要明確檢查，setup以後，查看XX路徑下的XX文件，是否更新成功這條檢查項。

        8.3若是解決方案沒有統一指定，每一個軟件團隊都是本身指定目錄，且dll的特性不同，有多個版本在同時使用，那麼必然會存在本身公司多款軟件調用dll衝突的現象，或者絕不客氣的說，部分人員連dll搜索路徑「當前目錄->system目錄->windows目錄->環境變量Path指定的目錄」都沒有考慮。那麼這事兒若是要暴露，就要找幾我的成立專項測試，甚至要週期性進行檢查了——可是一旦惡劣到這種狀況，就是各軟件產品沒有統一的規則，你們關起門來本身按照本身的想法設定，並單純的認爲客戶只會安裝一款 產品。若是是我，確定罷工——系統部門坐下來定個規則，你們一塊兒修改一下，就能夠一勞永逸，分分鐘的事兒。結果把問題甩給後端團隊，找幾我的費工費時，長期的去折騰。這是不拿別人當人看，也沒有考慮項目總體成本，或者乾脆就是沒有盡到責任，憑什麼讓測試人員來背鍋？

        一個看起來相同的現象，由於產生緣由的不一樣，可能採用的行動是大相徑庭的。若是你不在項目組裏面，不對裏面的緣由瞭如指掌。只是單純的督促某一我的員，這事兒是否是你的問題？這反而容易激發逆反情緒，對總體推動產品，會產生很是大的負能量。

        6、測試用例的可執行性。

        上文已經舉了一個例子。凡是隨意的寫出窮率測試的測試用例，都是不負責任的。            

        A：我寫了遍歷全部的接口，全部的格式，清清楚楚，你怎麼沒有測到？

        B：你算過你這一行實際要測試多少時間麼？你寫一句話，我要折騰一個禮拜。

        出了問題，你說你想到了，是執行人員偷懶，可是這麼緊張的測試時間，不可能給一個禮拜的時間去測試這麼一個基本功能。測試優先級、測試等價類劃分，甚至根據客戶使用機率作帶風險的暫不測試決定，不是測試設計該作的事兒麼？

        造成一張圖表來闡述觀點。

        這張表的目的並非死記硬背，而是當你思考「這個問題的產生，咱們要不要寫條case，而後一直去執行它？」的時候，可以根據本身產品的實際特色，作出正確的分析判斷就能夠。

        因此迴歸一開始的問題，若是是按照冷冰冰的規範約定，全部的問題都必須歸入到缺陷進行管理。在面對複雜多變的種種現實狀況時，落地的樣式可能會多種多樣（不須要、選擇執行、長期例行覆蓋、短時間覆蓋、專項重點解決）。    

        

        第三方部門的種種檢查方法，可能並不能套用到一條條的用現有用例中，而趨利避害的本能，向不瞭解業務的人，講解清楚的原因和解決方案是很是麻煩的事情。因此每每實際的產品驗證方，與其試圖無謂的解釋清楚一二三四，還不如干脆作表面文章，寫幾條看上去通俗易懂的測試用例，你們反而會過的舒服一些。

        按照驅動力3.0的概念，胡蘿蔔大棒會扼殺別人的積極性和創造力，因此經過智力定位而且寫出足夠牛B的測試用例這種高大上的行爲，經過標準化、檢查化的方式，每每會被變成寫水文的應付行爲——這不是本文的重點，就稍微點到爲止。

        迴歸測試用例更新、優化自己。    

        除了由缺陷提煉出測試用例進行反向增補外，測試用例的基準庫，也要定時評審修改更新的。

        這就是測試用例中的殺蟲劑悖論（pesticide paradox）——對軟件進行越多的測試，那麼該軟件對軟件測試人員的測試就越具備免疫力。或者字面理解，若是地裏長期只打一種農藥，那麼蟲子（bug）就會產生抗藥性，致使效果愈來愈差，最後殺不死蟲子。或者換個維度來描述：測試用例就是一種數據量化指標，你想考覈什麼，久而久之就必然會獲得這種量化結果，可是對事情實際的提高，可能幫助不大。

        可能一些測試用例在設計時是針對當時產品的一些薄弱環節。可是幾個項目測試完成，甚至幾年以後，這些測試用例的有效性就趨於爲0。

        一、多是代碼邏輯修復，此類問題不再會出現；

        二、多是軟硬件變動，原來的測試方案須要調整；     

        三、多是功能點優先級變化致使的測試用例優先級調整等等。

        舉個例子，曾經在測試用例中，要求把版本放在發佈服務器以後，須要從新下載後，進行一次安裝測試，確認各模塊的版本號信息。這在當時的條件下，是必然的一個測試步驟。緣由1、曾經出現過用不一樣的解壓軟件和斷點續傳下載工具，致使文件字節數大小不一致的問題；2、原來版本是一個文件夾，其中有各類ini、exe、bin、setup文件，很容易出現測試版本和發佈版本不一致的現象；因此從新進行安裝後檢查版本，是很是必要的行爲。

        可是過了幾年以後，解壓縮軟件愈來愈多，兼容性愈來愈好。覆蓋解壓軟件愈來愈不可能，還不如指定解壓軟件及版本號更現實；發佈文件自己也不是一個文件夾，而是一個或幾個Zip包，也避免了人工複製粘貼多個文件，人爲混亂的風險；3、數據校驗也作的比以前好多了，不必採用土鱉的方法手動覈實。

        因此，這條用例，毫無疑問能夠刪除掉，畢竟下載、替換、看版本號，怎麼說也要兩、三個小時才能搞的定。

        經年不變的測試用例，從工做性價比的角度來講，這就是無效的工做內容。就好像站在樓梯口的服務員，僅僅是由於傳統而站在那裏，而不知道一開始僅僅是爲了提醒你們樓梯的油漆未乾。

        

        從測試職責和風險來說，這就是推卸管理者的職責。不管怎麼說，常年不變的測試用例，就意味着多年沒有進步的測試團隊，這是毋庸置疑的。