怎么樣把產品后端（客戶、客服、生產制造等等）出現的問題，反向增補為測試用例，擴充到測試用例庫中，避免后續重復的出現問題——早些年柳傳志在創業類的節目問一個選手，作為老板，你每天第一件要處理什么事情。選手按照自己的優先級和重要性說了一堆。柳傳志說：你應該優先處理反復出現的問題。

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

嘗試這么做一段時間，把已經形成的反向增補測試用例，推廣到相關測試用例庫，然后在實際中執行和檢查，一段時間大致有如下幾種現象：

• 絕大部分，根本不執行。
• 小部分，有選擇的執行。
• 小部分，重新編寫，納入到原有的測試用例中執行。

第一種現象的原因有很多種，光明正大的以及不那么光明正大的——我更愿意認為是下文會提到的原因。

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

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

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

問題產生的原因，它的頻率是什么？

EX1

如果問題是因為開發人員錯手把一段代碼注釋，或者因為各種筆誤產生的缺陷，發現之后修改代碼重新編譯，問題解決。

那么這種問題的概率就是一次性的。這個缺陷修復后，再次出現的概率就非常小——除非這代碼是別人留下來的，然后換個開發，又膽大的修改了一些老代碼。然后自己的組長還沒有代碼審核，直接提交了。那么這問題才有可能重見天日。正常針對這種情況，是沒有必要寫上幾條case，后續的項目每次都執行的。

EX2

有一個資源，多個模塊都會調用，而且這幾個模塊業務邏輯耦合的較為緊密，而且聯調一直做的不好，甚至因為解決缺陷還發生過多次扯皮到底是你的我的他的等破事兒。

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

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

EX3

在嵌入式設備中，“兗”字無法顯示，顯示為“口”。問題的原因是在嵌入式設備內存較小時，可能字庫采用的是一級字庫，那么可能所有的二級字庫的文字都會顯示異常。

1.具有唯一性：

如果全公司使用的都是統一的font字庫。那么只更新這個font，所有嵌入式設備的二級字庫問題都會得到解決，這個缺陷一次性修復后，就不需要納入到測試用例。

2.存在多分支：

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

A、如果有好的全面的缺陷分析和波及通知方式，大家各自修復，也不需要寫到測試用例中，因為是一次性的行為。

B、如果有一定的缺陷知會方式，不同的分支流可以感知，但是時效性較差，那么這事兒就要固化在測試用例中，執行上一段時間。

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被覆蓋的問題。系統先裝了產品的的編解碼插件，然后又裝了其他的播放器（暴風影音、千千靜聽都出現過此問題），同名編解碼插件被覆蓋，解碼失敗。

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

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

1、如果解決方案是銷售規避——服務器是獨立安裝的，所裝軟件都是有標準版本，不允許安裝其他軟件，那么這個問題根本就不需要解決。只需要卸載非允許軟件，重新安裝一次即可。

2、如果解決方案是統一把dll的路徑由system目錄，修改到指定的目錄，規避dll被覆蓋的問題。那么這條case就需要執行一段時間，并且要明確檢查，setup之后，查看XX路徑下的XX文件，是否更新成功這條檢查項。

3、如果解決方案沒有統一指定，每個軟件團隊都是自己指定目錄，且dll的特性不一樣，有多個版本在同時使用，那么必然會存在自己公司多款軟件調用dll沖突的現象，或者毫不客氣的說，部分人員連dll搜索路徑“當前目錄->system目錄->windows目錄->環境變量Path指定的目錄”都沒有考慮。那么這事兒如果要暴露，就要找幾個人成立專項測試，甚至要周期性進行檢查了——但是一旦惡劣到這種情況，就是各軟件產品沒有統一的規則，大家關起門來自己按照自己的想法設定，并單純的認為客戶只會安裝一款 產品。如果是我，肯定罷工——系統部門坐下來定個規則，大家一起修改一下，就可以一勞永逸，分分鐘的事兒。結果把問題甩給后端團隊，找幾個人費工費時，長期的去折騰。這是不拿別人當人看，也沒有考慮項目整體成本，或者干脆就是沒有盡到責任，憑什么讓測試人員來背鍋？

一個看起來相同的現象，因為產生原因的不同，可能采用的行動是截然不同的。如果你不在項目組里面，不對里面的原因了如指掌。只是單純的督促某一個人員，這事兒是不是你的問題？這反而容易激發逆反情緒，對整體推進產品，會產生非常大的負能量。

測試用例的可執行性

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

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

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

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

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

這張表的目的并不是死記硬背，而是當你思考“這個問題的產生，我們要不要寫條case，然后一直去執行它？”的時候，能夠根據自己產品的實際特點，做出正確的分析判斷就可以。

所以回歸一開始的問題，如果是按照冷冰冰的規范約定，所有的問題都必須納入到缺陷進行管理。在面對復雜多變的種種現實情況時，落地的樣式可能會多種多樣（不需要、選擇執行、長期例行覆蓋、短期覆蓋、專項重點解決）。  

第三方部門的種種檢查方法，可能并不能套用到一條條的用現有用例中，而趨利避害的本能，向不了解業務的人，講解清楚的緣由和解決方案是非常麻煩的事情。所以往往實際的產品驗證方，與其試圖無謂的解釋清楚一二三四，還不如干脆做表面文章，寫幾條看上去通俗易懂的測試用例，大家反而會過的舒服一些。

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

回歸測試用例更新、優化本身

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

這就是測試用例中的殺蟲劑悖論（pesticide paradox）——對軟件進行越多的測試，那么該軟件對軟件測試人員的測試就越具有免疫力?；蛘咦置胬斫?，如果地里長期只打一種農藥，那么蟲子（bug）就會產生抗藥性，導致效果越來越差，最后殺不死蟲子。或者換個維度來描述：測試用例就是一種數據量化指標，你想考核什么，長此以往就必然會得到這種量化結果，但是對事情實際的提升，可能幫助不大。

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

• 可能是代碼邏輯修復，此類問題再也不會出現；
• 可能是軟硬件變更，原來的測試方案需要調整；
• 可能是功能點優先級變化導致的測試用例優先級調整等等。

舉個例子，曾經在測試用例中，要求把版本放在發布服務器之后，需要重新下載后，進行一次安裝測試，確認各模塊的版本號信息。這在當時的條件下，是必然的一個測試步驟。原因一、曾經出現過用不同的解壓軟件和斷點續傳下載工具，導致文件字節數大小不一致的問題；二、原來版本是一個文件夾，其中有各種ini、exe、bin、setup文件，很容易出現測試版本和發布版本不一致的現象；所以重新進行安裝后檢查版本，是非常必要的行為。

但是過了幾年之后，解壓縮軟件越來越多，兼容性越來越好。覆蓋解壓軟件越來越不可能，還不如指定解壓軟件及版本號更現實；發布文件本身也不是一個文件夾，而是一個或幾個Zip包，也避免了人工復制粘貼多個文件，人為混亂的風險；三、數據校驗也做的比之前好多了，沒必要采用土鱉的方法手動核實。

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

原文轉載自：軟件測試的自我修養