本節書摘來自華章出版社《軟體測試價值提升之路》一書中的第3章，第3.1節，作者：楊曉慧編著，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
掃 門 前 雪
作為一個測試團隊，基本的職責是：測試産品，發現缺陷，報告結果，使每個版本的測試水準穩步提升。這些價值是作為一個測試所必須具備的，發揮這些價值能夠讓測試獲得研發團隊的基本信任。
這類價值分為3部分：
1）攔截缺陷，即對産品進行測試，盡可能把産品的缺陷攔截在研發階段。
2）提供資料，即提供産品的品質結論，并且給出支撐這些結論的資料。
3）測試過程可控，提升測試團隊和測試工程師的能力，使得産品測試的效率、品質、成本都處于可控狀态。
“掃門前雪”說明這些價值基本上是測試的本職工作，價值的發揮是依靠測試自身或者以測試為主進行能力建設。當然，這并不是說測試必須将這些價值發揮到極緻，測試工程師們還需要權衡成本和收益，找到合适的“度”。
攔截缺陷是測試最基本的價值，盡可能多地發現缺陷，盡可能在版本釋出前發現并解決影響使用者使用的缺陷，這是測試這個職業存在的基礎。
一個測試團隊或者測試工程師，如果經常将基本功能缺陷漏出去，那是無論如何也得不到信任的。這也不是說隻要産品到客戶那裡有遺留缺陷，測試活動就一定有問題，攔截缺陷的能力就一定需要改進。通常還是會視缺陷的影響程度而定。
為了友善說明問題的解決辦法，這裡按照缺陷的激活條件（産品中的錯誤在特定條件下被激活，導緻産品出現故障，這個“特定條件”就是激活條件），把缺陷分為4類：
基本功能缺陷。使用者進行正常業務的基本操作時，由于缺陷導緻業務操作無法完成。這類缺陷對使用者的影響最大，是研發需要最優先解決的問題。
正常使用缺陷。使用者大部分情況下能完成正常的業務操作，但在特定的條件下進行業務操作時，缺陷被激活導緻操作無法完成，産品絕大部分的缺陷都屬于這一類。想要減少這類缺陷，需要進一步按故障的影響範圍和嚴重程度找到優先解決的重點。
受攻擊暴露的缺陷。産品出現故障并非由于使用者的業務操作，而是由于軟硬體或網絡環境發生異常、業務請求量超出預期而造成過載、受到黑客攻擊等。這類缺陷對使用者的影響很大，但使用者會基于成本來考慮解決的方式，不一定全部是通過增強軟體能力來解決。
随機出現的缺陷。産品出現故障的條件不明确，如果故障的影響範圍大、嚴重程度高、出現頻次高，也會對缺陷進行專項分析。
本章将分别介紹攔截各類缺陷的一般原則、常用方法，以及具體可參考的方法和工具。
3.1.1 問題案例
我遇到最狼狽的問題是有一次切換資料庫，切換的過程是先導出資料，更新程式，然後導入資料恢複系統。在實驗室經過詳細驗證的切換腳本，在客戶那裡始終卡在第三步，導入資料失敗。從淩晨兩點一直折騰到淩晨五點，也沒能讓資料成功導入，最後不得已回退到更新前系統。把資料拿回研發分析，發現是由于2個資料庫支援的字庫略有差别，有一個使用者的名字使用了生僻字，原來的資料庫支援這個字，新資料庫的預設字庫中不支援這個字。
在日常生活中，軟體無法正常使用的例子也很常見，比如，下載下傳的手機app一打開就閃退，遊戲更新後原來的過關記錄都丢了。曾經有一段時間，我每次更新完某度用戶端，追的書就停止更新，直到兩三天後才恢複。
這類缺陷典型的有：安裝或更新過程中出錯，新研發特性的基本功能有錯，更新後原本正常使用的功能出錯，産品在正常使用中數次崩潰，正常使用中有導緻使用者直接經濟損失或資訊洩露的錯誤。
3.1.2 解決問題的思路
【一般處理原則】
産品安裝或更新後，基本的功能出錯或者完全不能使用，這對于測試的信譽是極大的傷害，如果這類錯誤經常反複發生，測試需要把攔截缺陷作為最優先的任務。
【解決方法】
這類缺陷的發現條件是：隻要測試時覆寫到了這個功能或特性，就能夠發現缺陷。是以，在遇到這類問題的時候，推薦的解決思路是：
1）建立基本測試用例基線（測試用例基線類似代碼基線，是産品截止到某個版本時，産品全部測試用例及其測試結果的集合，這是産品下一個版本測試的基礎，故稱基線。基本測試用例基線是測試用例基線的一個子集），基本測試用例集包含産品最常見的業務場景，覆寫絕大部分功能特性。
2）盡可能實作100%自動化測試，在每次啟動測試、産品釋出之前都将基本測試用例全部測試一遍。
3）有時候出現問題還與客戶資料、環境、使用方法有關，那麼基本用例基線的測試用例就需要包含客戶的資料、環境、應用場景等資訊，并按版本、客戶進行管理。
無論是否有專業的測試團隊，産品在釋出之前一定是驗證過基本功能的。安裝或更新後仍出現無法啟動、異常退出、原有基本功能不能用、新增特性基本功能錯誤等這些缺陷，雖然看上去像是根本沒有測試過，但事實卻并非如此。缺陷沒有被攔截，實際上大部分原因是：
新增的功能測試了，原有的老功能沒有全部測試。
原有老功能測試了，但是結果檢查不完整，例如隻檢查特性相關的特殊結果資料，正常的結果資料沒有檢查。
新、老功能都測試了，但是測試用例和使用者的常用使用場景有出入；測試環境的基礎資料、開關設定、終端類型、作業系統版本等和使用者常用的使用資料有出入。
針對以上原因，基本用例相當于确定了：在這樣的條件下，可以通過這樣的操作過程，正常地實作這個業務場景。建立測試用例基線是确定了産品的常見使用場景；而自動化是固化成果，確定每次釋出正常場景都能正常使用。
3.1.3 建立測試用例基線
我們的主要産品都要求建立測試用例基線，用例基線包含基本用例、正常用例、生僻用例。基本用例就是上一小節提到的基本用例集。正常用例包含絕大部分正常和異常用例，一般在老特性修改或者新特性對老特性影響較大時，會測試老特性的正常用例。生僻用例是一些使用非正常手段才能實施的測試，比如暴力攻擊、斷電、代碼注入等，這些用例很少會重複測試，隻有在可靠性、安全機制做架構更新時才會考慮重新測試。
測試用例基線的建設标準包含基本要求和附加要求2部分，基本要求主要關注測試用例基線的完整性；附加要求主要關注測試用例基線是否易于使用。
【基本要求】
1）建立産品級測試用例基線，基線覆寫産品的全部特性功能和所有品質屬性（功能、性能、可靠性、安全性、可服務性、資料）。産品級的含義是，一個産品一個用例集基線，而不是一個版本一個用例基線，這是為了随時都能根據用例的測試結果得到産品品質的整體視圖。
2）測試用例基線中的用例集或用例，包含與産品特性、産品需求的對應關系。這是為了在測試結束時，按特性或需求進行測試結果分析。
3）測試用例基線包含基本用例集，基本用例100%覆寫産品特性。這要求每個産品特性都至少有一個用例在基本用例集中。
4）測試用例基線的用例不存在空用例、拷貝用例、自動化腳本和文本不一緻等情況。這是用例品質最基本的要求。
【附加要求】
1）測試用例基線覆寫産品的全部需求。
2）有針對測試用例基線的更新、稽核機制。測試用例基線要做到和産品同步更新，每個版本根據特性變更情況重新整理基線，保證基線不腐化。
3）有管理用例基線的工具，工具管理了用例及其執行過程和結果的全部的資訊，并可以根據版本、客戶、業務等條件友善地查詢，并進行測試結果演變過程分析。
在基本要求中，要求測試用例基線覆寫産品特性；在附加要求中，要求測試用例基線覆寫産品需求。特性的粒度比功能需求大，比如支援語音通話計費是一個特性，而本地、漫遊、長途有不同費率，欠費、低餘額做不同處理，不同品牌不同套餐的不同優惠等這些都是功能需求。
測試用例對應到需求更容易進行準确的挑選，也更便于在需求變更時，同步更新測試用例。但是從測試用例的管理難度上看，對應到到需求比對應到特性難度要大。對應到需求的主要難度是，通常開發團隊對産品隻管理到特性，每個特性有特定的代碼；但需求通常沒有有效的管理，因為需求經常變化并不像特性那樣穩定。
在附加要求中，要求測試用例基線和産品同步更新。有些團隊的做法是，老用例從不更新，特性有變更時，寫一批新用例加入基線。後一種做法實施起來更簡單一些，但是這樣一來，測試用例基線中就遺留了無效的用例，長期積累下來，就很難從測試用例基線中找到特性的有效用例全集了。
建立測試用例基線的目的是為了複用，如果老特性永遠也不會需要重新驗證，比如某些遊戲，那麼可以選擇不建測試用例基線，千萬不要為了讓測試工作看起來有一些積累的，而去做這個事情。
這個标準隻包括對大部分産品都适用的做法，前面提到的，用例應該包含客戶資料、環境、應用場景，并具備版本和客戶辨別，這是産品根據自身的情況再增加的内容。有些産品還會建立起用例和缺陷（尤其是客戶報告的缺陷）的對應關系，這樣做的好處是，對重要的客戶，至少可以通過用例的覆寫保證出過的缺陷不再重複出現。
對于測試用例基線的管理，我們的測試團隊用的是自行研發的一個工具，工具中用例集的結構如圖3-1所示，按特性和測試項分層管理。管理的最小顆粒是單個測試用例，用例的内容結構如圖3-2所示，包含用例的描述、自動化腳本、每次執行的結果、所有的分類标簽和辨別。在工具上能完成用例所有資訊的編輯、存儲，按各種條件挑選用例，也能和自動化工具、研發管理的電子流同步資料。
說明：測試項和測試子項通常對應一個測試目的，例如“××接口測試”“××參數測試”。
要做一個這樣的用例管理工具成本還是很高的，用正常的配置管理工具配合用例文檔的一些規範也可以實作基本的用例管理。
3.1.4 測試用例基線要同步優化管理和品質
在常用的、久經考驗的軟體中，也不乏“使用者無法正常使用”的例子。
某天，我需要把信用卡提前還款，恢複信用額度，以應付接下來的支付需要。通過網銀查詢賬單如圖3-3所示。
點選連結進入快速還款，發現應還款金額為零，與賬單查詢到的不一緻，如圖3-4所示。
查詢未出賬單，發現此筆已經自動還款，是以上述應還金額為零可能是對的。但是還款之後的消費，無論是否入賬，都無法選擇提前還款，如圖3-5所示。這樣，還是無法恢複信用額度（以前曾經這樣操作成功過）。
查詢賬單、快速還款，這些功能單獨看起來都是對的，但是組合起來，卻無法實作我所希望的應用場景。打電話到客服，對這個問題也沒有解釋，最後就是臨時調高信用額度了事。
想要在測試的時候發現這個缺陷，必然需要有業務場景用例基線，覆寫已出賬單、未出賬單的快速還款。這樣在新版本驗證的時候，才能夠發現出現了特性丢失、有的業務場景已經不能實作的缺陷。
有些時候，“使用者無法正常使用”的缺陷顯得匪夷所思，無法接受。我在某購書網站上找一套《給孩子的哲學》，得到的查詢結果如圖3-6所示。
在這個例子中，搜尋結果的書名資訊和搜尋關鍵字“給孩子的哲學”毫無關系，但是除了書名以外，其他的内容都是正确的，書籍的整個購買流程也可以正确地實作。也就是說，即使有“搜尋并購書”這一基本業務流程的自動化用例，并且在版本上線之前進行了自動化驗證，也不一定能夠發現如此“明顯的”缺陷，除非在基本業務流程的每個操作環節，都在驗證操作前後資料的一緻性。
業務場景：完成一次業務處理的一組操作，例如使用者開戶、一次網購下訂單、一個客戶投訴的處理等。以“搜尋并購書”為例，業務場景的基本流程是：用關鍵字搜尋圖書→點開其中一個圖書連結→浏覽圖書資訊→加入購物車。
通常，一個業務場景就是一組有明确目标的操作序列。
從這兩個例子可以知道，建立測試用例基線絕非簡單地把現有的用例實作自動化并管理起來，很可能需要改善用例的品質，一方面需要根據業務場景設計用例，另一方面在預置條件、操作步驟、中間和最終結果檢查方面需要更嚴謹。
在我們的産品中，最開始部分産品出于自己的業務需要，建立基本測試用例集并實作自動化、形成基線，在每個版本中作為冒煙測試的基礎用例使用，并随着産品版本的演進，同步進行維護和更新。由于這種做法很好地控制了基本功能的品質，後來逐漸在産品間推廣，把建立基本測試用例基線作為對全部産品的基本能力要求。
在各個産品進行這項能力建設的過程中，有些産品直接把特性測試時的基本功能驗證用例拿來構造基本測試用例基線，使用後發現并不能攔截“使用者無法正常使用”的缺陷，于是覺得基本測試用例基線“沒有用”。但事實上并不是基本測試用例基線這種方法沒有用，而是基線中的用例并沒有覆寫使用者的正常使用場景，或者覆寫了場景但是結果檢查的内容不完整。
3.1.5 找對症結建立測試用例基線
新團隊或新産品經常會遇到這類問題，由于這類問題直接影響産品的銷售，是以研發通常急于解決這類問題，但是從無到有建立自動化的基本用例集絕非一日之功。是以，在建立測試用例基線工作的前期，我建議和服務代表、市場代表、研發經理做充分的溝通，切忌盲目鋪開或者孤立的看待每個問題。
溝通前，首先進行缺陷分析，明确基本用例集需要包含哪些方面的測試用例，導緻缺陷遺漏是因為缺少用例？還是操作方法不對或結果檢查不完整？是否需要和具體的環境、客戶資料、應用場景建立關聯？根據這些資訊估計用例數量、手工測試工作量和自動化工作量。
然後和市場代表或者研發經理讨論政策，一種是先把用例集整理出來手工測試，再逐漸實作自動化；一種是按缺陷出現的頻率和業務影響排優先級，先把風險最大的部分整理用例集并實作自動化。後一種政策有更明顯的商業成功導向。
發生這類問題的另一個原因是測試工程師對客戶的業務流程、使用習慣、網絡環境、産品部署不了解。是以，基本用例集中功能測試的環境、操作步驟、測試資料、結果檢查項，都最好能夠和客戶或者市場代表進行确認。這樣做的好處不僅是讓用例更貼近使用者的真實情況，還有利于測試工程師掌握客戶的業務和要求的第一手資訊。
總之，解決這一類問題，最好進行思路上的轉變：測試的角度由設計驗證轉變為需求驗證、應用場景驗證；首先考慮的是業務問題的解決而不是自動化的方法。