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

復盤論是聯(lián)想的看家本領(lǐng)，這也僅借用一下這個意思。

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

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

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

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

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

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

問題產(chǎn)生的原因，它的頻率是什么？

EX1

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

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

EX2

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

那么這種問題應(yīng)該是有概率出現(xiàn)的。這個缺陷修復后，不僅僅這條缺陷產(chǎn)生的操作后續(xù)要增補，甚至這幾個模塊調(diào)用資源的一些方法，之前沒有太過注意，后續(xù)也要適當?shù)募訌姕y試設(shè)計。

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

EX3

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

1.具有唯一性：

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

2.存在多分支：

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

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

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

C、如果沒有一定高度的缺陷知會方式，大家基于一個流，后續(xù)各自開發(fā)維護，那么肯定要寫在測試用例中，甚至要組織小的專項測試，來集中暴露不同版本的問題。

是否有強順序依賴關(guān)系？

EX4

如果一個問題，和業(yè)務(wù)邏輯順序強相關(guān)，需要經(jīng)過必須的1、2、3、4、5等步驟，才會導致一個必然的bug。從測試人員的本職工作來說，能發(fā)現(xiàn)這樣的bug（俗稱神級bug），簡直是自己對業(yè)務(wù)知識了如指掌的最好表現(xiàn)，甚至可以作為自己的江湖軼事不斷的吹噓下去。

但是，這種bug，回歸測試之后，真心不用把它形成測試用例，讓后面每一個項目，都去反復的執(zhí)行——強業(yè)務(wù)順序關(guān)系修復了，后續(xù)自然不會出現(xiàn)。至于是否有其他隱含的邏輯，是否需要進行其他的分支狀態(tài)測試，那是另外一回事兒。

驗證條件具不具備？

EX5

各種復雜的外廠商對通問題。

此類的bug，多是在現(xiàn)場，通過抓包分析、碼流分析，然后不停的替換臨時版本才能修復。如果是協(xié)議標準化方面，可以在測試環(huán)節(jié)加強，如果是各廠家飛速發(fā)展中產(chǎn)生的非標協(xié)議，誰也沒辦法，只能現(xiàn)場解決。

所以，你可以寫一條，A設(shè)備，需要接入甲廠家的XXX產(chǎn)品/乙廠家的YYY產(chǎn)品，進行ZZZ功能測試。但是，這些測試用例，不具備可執(zhí)行性。

對于此類的互聯(lián)互通問題，最好的解決方案是，找到一個設(shè)備型號很多的客戶，維系好客戶關(guān)系，發(fā)布新產(chǎn)品的時候，自己帶臺設(shè)備過去，聯(lián)調(diào)就搞定了。

這個例子需要的是此類問題的測試策略和方案，而不是生硬的補充無法執(zhí)行的測試用例。

EX6

長時間運行后導致的問題，比如XX設(shè)備運行三年后，器件老化，或者版本、文件無故丟失。

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

測試這類的問題，要在短時間內(nèi)模擬三年的效果，只能是通過上測試設(shè)備量，以及通過公式推導大概的穩(wěn)定性。寫在測試用例里面，在日常的工作中，顯然是無法實現(xiàn)的，還不如老老實實的做專項測試，集中人力、設(shè)備等等。把此類問題一次性搞定。

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

第二個概念和團隊和人有關(guān)系，一個團隊真實的運作，往往只有內(nèi)部人知道。同理，問題產(chǎn)生的真實原因，往往是一個團隊內(nèi)部被隱藏的，所以是否能寫出精準的測試用例，也只有團隊內(nèi)部自己人才能搞的定。這就意味著如果測試用例更新不是自己部門內(nèi)部主動觸發(fā)，而是第三方部門（質(zhì)量部門、流程部門）驅(qū)動的，那么就注定只會拿到一些樣子貨。

問題產(chǎn)生的真實原因，會讓你寫的case完全不一樣。

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

但是如果你增加一條測試用例：“軟件安裝/更新成功后，查看編解碼狀態(tài)是否正常，預期結(jié)果：圖像、聲音正常。”拿到這條用例的人會認為編寫人秀逗了，這么基本的東西早就測爛了，還正兒八經(jīng)的新增，最后的結(jié)果要么是不執(zhí)行，要么就是無腦打鉤通過。

但這個最基本的問題，會一次次的出現(xiàn)，背后自然有深層次的東西存在。

EX7

兼容性問題，某音頻格式經(jīng)過翻轉(zhuǎn)，未考慮兼容性。

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

看起來是不是抓到實際問題了？但是這種用例也是理論上的全面用例，實際也不可能會被執(zhí)行（參考六、測試用例的可執(zhí)行性）——歷史產(chǎn)品可能有二十幾個，歷史版本可能也有二十幾個。你動動嘴皮子互聯(lián)互通，且不說是不是測試環(huán)境有這么多設(shè)備，就是在一切順利的情況下，版本更換并測試一輪，也要個幾個工作日。在測試資源、時間一貫緊張項目背景的下，這條case會被執(zhí)行才怪。

結(jié)合上面的觀點，看編解碼組件的版本是否有變更，然后再決定是否執(zhí)行編解碼不同版本之間的兼容性測試，然后通過等價類，選取產(chǎn)品和版本，讓測試執(zhí)行在半個小時到一個小時可以被執(zhí)行，才是正解。

EX8

DLL被覆蓋的問題。系統(tǒng)先裝了產(chǎn)品的的編解碼插件，然后又裝了其他的播放器（暴風影音、千千靜聽都出現(xiàn)過此問題），同名編解碼插件被覆蓋，解碼失敗。

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

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

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

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

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

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

測試用例的可執(zhí)行性

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

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

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

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

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

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

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

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

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

回歸測試用例更新、優(yōu)化本身

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

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

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

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

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

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

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

原文轉(zhuǎn)載自：軟件測試的自我修養(yǎng)