本節書摘來自華章出版社《軟體測試價值提升之路》一書中的第3章，第3.2節，作者：楊曉慧編著，更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。
3.2.1 問題案例
我們的産品中遇到的大部分客戶問題都屬于此類。例如：
某産品的用戶端是運作在浏覽器上的，支援ie8、ie9、firefox，但是經常出現某些頁面在其中一款浏覽器上顯示不全或者錯位等問題，有個産品由于問題太多，以至于不再支援firefox。對于移動應用，最常見的是app在某個終端品牌或作業系統版本上不能正常使用。
某産品新版本逐漸替換老版本的過程中，客戶開始使用時都沒有發現問題，到某個客戶那裡突然和原有的功能不相容。分析發現某個接口字段的合法取值是0～10，産品上一個版本暫時隻用了0～5，其他的預留。在新上線的版本中啟用了6，觸發一個新的功能分支。但是，這個産品是支援客戶定制的，客戶之前就用了6這個值來觸發他們自行定制的一個功能分支。這樣，不相容就産生了。
在日常生活中，我也遇到過某信支付時，付款人已經收到銀行扣款的短信，但是在app上沒有交易的資訊，收款方也看不到收款提醒。打電話到客服，隻告知是系統故障，背景手工處理過一段時間以後，交易資料才恢複。
這類缺陷典型的有：新版本在部分使用者那裡無法正确更新或使用，新特性在使用者進行特别的操作或使用特定的資料時保護不足、出錯或造成損失，系統在忙時處理能力不足或出錯率高等。
3.2.2 解決問題的思路
【一般處理原則】
産品在使用過程中小毛病不斷，一方面會降低使用者的滿意度；另一方面也會讓産品研發不得不投入大量的精力去處理缺陷。如果這類問題經常發生，測試需要把攔截缺陷作為比較優先的任務。
由于解決這類問題需要一個經驗和成果積累的過程，是以周期比較長。
【解決方法】
這類缺陷的發現條件是：必須在特定場景下測試，或者使用了特定的資料，或者進行了特定的操作，或者走了特定的路徑，總之，測試設計必須考慮到了這些情況。在遇到這類問題的時候，推薦的方法是：1）擴充基本用例集，使之包含安裝、更新、應用場景、性能的部分用例；2）形成測試設計要素集，完善測試設計方法。
如果錯誤經常出現在特定場景，比如安裝或忙時，那麼需要考慮對測試範圍做完善。一般的軟體産品，測試中需要考慮功能、性能、安全性、可靠性、易用性等的覆寫。移動網際網路應用的測試類型中還有包含安裝在内的整個使用過程，以及能耗、組網等方面。
如果錯誤經常是由于特性的某些影響因素沒有考慮到，比如vip使用者、欠費狀态使用者需要特殊處理等，那麼需要考慮改進測試設計，把容易遺漏的測試設計要素（例如上面例子中的使用者類型、使用者狀态）進行歸類整理。
判斷采取什麼手段進行改進，需要依據對客戶問題的分析，常用的分析方法是根因分析法（root cause analysis，rca），通過對缺陷根本原因的分析，找到需要解決的問題，進而确定合适的解決問題的突破點。
為什麼沒有強調 “使用經典的測試設計方法”
産品在使用過程中有缺陷，肯定會想到改善測試設計，而改善測試設計首先又會想到使用經典的測試設計方法，如因果圖、邊界值、等價類等。我們的測試團隊曾經做過統計，嚴格要求測試工程師使用這些測試設計方法進行用例的設計，用例倒是增加了不少，但對增加缺陷的發現作用甚微。
進行原因分析後發現，測試沒有成功地攔截缺陷，問題并不是出在“測試設計”上，而是出在“測試分析”上。以一個業務流程為例，“測試分析”是畫出業務流程，以及各種分支、異常處理過程；“測試設計”是使用深度優先或廣度優先政策，實作對圖的邊、語句、邏輯或路徑等的覆寫。大部分情況下，測試沒有發現産品的缺陷，并不是“覆寫”的方法不全面，而是在圖上根本就沒有畫出這部分内容。
是以，在測試設計中需要重視“被測試對象分析”：針對需要測試的特性、業務流程、功能（即被測試對象），選擇合适的模型表達處理過程、狀态跳轉、異常處理、邏輯限制、資料結構等，以這些模型為基礎進行測試設計，才真正能更有效地攔截缺陷。而在解決方法中提到的兩點正是幫助完善“被測試對象分析”的方法。
總之，測試設計方法很重要，但是測試工程師更容易忽略被測試對象分析。
此外，沒有正規測試設計過程的探索式測試似乎能夠更快地發現缺陷，如果仔細了解常用的探索方法，可以看出這種測試很重視“被測試對象分析”和“攻擊”，即通過各種探索方法找到軟體各種可能的用法（被測試對象分析），以及通過各種探索方法試探如何讓軟體出錯（可靠性和安全性攻擊）。
3.2.3 擴充測試類型
定義測試類型的目的是幫助測試工程師從多個角度對特性或産品的測試範圍進行分析。我們的産品中，常見的測試類型包含功能、性能、可靠性、安全性、可服務性、資料；其他測試類型則由産品根據自己的情況選擇或者定義。
測試類型一般認為是和iso 9126軟體品質模型一緻，但是在實際工作中，測試類型和品質模型并不完全一緻，我們産品常用的測試類型有：
功能測試。産品的新、老功能與需求是否一緻，各種分支處理是否正确。
性能測試。系統的性能名額，超負載處理能力，長時間穩定性。
一緻性測試。産品是否滿足相關的标準、規範和法規的要求。
相容性測試。産品對不同的作業系統、資料庫、第三方插件、外部接口、組網環境、硬體平台的相容性。
可靠性測試。系統從各種已知故障中恢複的過程、影響和難易程度。備援備份、過載控制等可靠性機制在各種已知場景下是否可靠。
安全性測試。組網設計、通路控制、權限管理、資料保護等安全機制是否能夠有效防止安全攻擊，并能維持正常運作和保護敏感資料。
可服務性測試。安裝更新的過程、影響和難易程度。配置、維護、故障處理等能力是否滿足日常維護需要。
資料測試。産品的配套資料能否正确指導安裝、更新、配置、維護、故障處理等操作。
體驗測試。在仿真、鏡像或客戶環境中，模拟客戶的真實業務場景，對學習成本、操作路徑、操作時間、資訊呈現方式、界面布局等進行的體驗。
互操作測試（iot）。與不同的第三方裝置、不同主流終端裝置能否正确地互操作。
實驗局測試。新産品或新版本在正式大範圍商用前，先在個别客戶的真實業務環境下使用一段時間，使缺陷可以更充分暴露，降低大範圍應用後的品質風險。
鏡像測試。在鏡像環境上進行的測試，産品在特定環境下使用，使其所存在的問題能夠提前暴露。鏡像測試主要強調測試環境的鏡像，測試内容可以是功能、體驗、可靠性、可服務性等測試類型。這裡的鏡像是将産品的真實應用環境複制到實驗室，環境的複制包含裝置、網絡、資料、業務、第三方系統等全部環境要素。嚴格意義上說，是将客戶的環境按1∶1的比例在實驗室複制，但這樣做成本太高，是以更常見的是縮小比例複制，采用與客戶環境同系列、但配置較低的裝置搭建測試環境。
每個測試類型所測試的大緻内容，參見5.2.1節“測試方法和工具方面的能力”。
這些雖然是正常測試内容，但幾乎所有産品都測試的隻有功能和性能，其他類型測試都會根據産品的特點選擇，例如：
平台類的産品。這類産品指公司内部使用的二次開發平台、公共元件等，主要是供公司内部其他産品使用，有時候也可能對外銷售。由于不同的産品會将這些平台用于不同的環境和場景，是以這些平台産品需要進行相容性、可靠性測試。此外，其他産品還需要通過體驗測試結果，評估這些平台的學習成本、二次開發和內建的難易程度。
需要遵循标準、規範的産品。在電信領域，針對主要的網絡裝置都有标準、規範來限制功能、接口、可靠性、安全性等方面。依靠這些标準、規範，客戶就可以使用不同供應商的裝置，在實作業務的提供、營運、維護的同時，降低采購成本。對于這些産品，必須進行的是一緻性測試和iot。
有較多web前端或移動app前端界面的産品。這些産品的使用者從web前端界面或者移動app進行操作，實作與背景程式的互動。對于這些産品，安全性測試比較重要，此外在前端設計有大的調整時，還需要進行體驗測試。
路标版本。指架構層面進行重構或更新的版本，我們的産品一般2年左右會有一個路标版本，這個版本相對前一個路标在dfx多個次元上都有很大的變化，是以，對于這種版本，除了性能，還會對可靠性、安全性、可服務性和資料、一緻性、相容性等進行比較全面的測試。
總的說來，功能、性能、一緻性、可靠性、安全性測試在我們的産品中比較受重視。而客戶化測試（主要指體驗測試、鏡像測試、驗收測試、beta測試等有客戶參與或者由客戶主導的測試）是近年來逐漸被看重的測試内容。
我們的産品中，功能、性能、一緻性、可靠性的測試手段和工具比較完整。尤其是功能、性能、一緻性測試，自動化程度比較高。這些工具絕大部分也是自行研發的。安全性、可靠性測試的商用工具可選範圍比較大，也有免費工具可用，但是不一定真正适合自己的産品；一緻性的工具有但是普遍比較貴；功能、性能測試的工具選擇比較多，尤其是界面自動化的工具發展得比較成熟。
3.2.4 測試設計要素清單
測試設計要素清單是影響特性表現的各種正常因素。這是根據特性測試的經驗總結出來的測試設計輔助工具，這個清單和測試設計方法一起，幫助測試工程師更全面地分析被測試對象。
測試設計要素清單完全是由每個産品經理自行建設，一般測試設計要考慮的要素和産品的資料模型密切相關，是以通常建議産品測試和設計團隊共同參與。
【案例】為簡易的電商内控系統設計測試要素清單。
這個系統的主要特性和主要設計要素的關聯關系如表3-1所示。
此例子是電商的内控系統，該電商在不同電商平台都有網店，每個電商平台都支援pc和移動用戶端接入。此系統功能如下：
商品管理。實作商品上架、調價、折扣等操作。
商品訂購。實作商品查詢、對比、下訂單、付款等操作。
商品訂單處理。處理客戶送出的訂單，付款以後啟動，至收到貨款結束。
商品采購。處理采購單，采購下單以後啟動，到貨驗收，入庫後結束。
測試的主要設計要素如下：
使用者級别。新客戶、常客戶、vip等。
庫存狀态。充足、緊張、售罄、預售等。
平台訂單。電商平台的訂單資訊。
接入管道。哪個電商平台，pc還是移動用戶端接入。
平台狀态。忙、閑等。
其中，商品訂單處理之是以與這些要素有關，其原因如下：
vip客戶可以有額外的折扣或贈品，是以在備貨的時候會用到使用者級别的資料。
商品訂單是否能夠開始處理決定于庫存狀态，是以特性與庫存有關。
備貨、發貨時都需要更新平台訂單狀态，發貨以後需要定時掃描平台訂單，檢查确認情況，商品訂單和平台訂單狀态變化時，可以發短信通知客戶。
電商平台處于浪湧沖擊（促銷）時，不允許查詢平台訂單狀态等操作。
測試設計要素清單并非一個新的測試設計方法，而是作為測試設計的參考資訊之一，與測試設計常用的流程圖、狀态圖、邏輯、資料結構分析等方法結合，目的是使測試設計的時候不容易遺漏對輸入參數、處理分支的覆寫。以電商内控系統的“商品訂單處理”為例，設計的處理流程如圖3-7所示。
結合測試設計要素的逐一審查，可以發現“平台狀态”處于過載時，可能會導緻“同步平台訂單資訊”操作失敗，可能是傳回操作失敗，也可能沒有任何傳回消息。無論哪種情況，系統都需要正常處理。于是需對測試設計進行補充，如圖3-8所示。
在我們的産品中，測試設計要素清單在新特性的測試設計時完成初稿，在産品上線後通過對客戶問題的分析進行補充。
以上介紹的隻是解決問題的一種思路。我們的産品中，有一些資料模型超級複雜，不僅測試設計要素多，而且要素之間還要考慮組合，采用上面的思路改善測試設計始終是杯水車薪，無法達到理想的覆寫範圍。産品測試團隊探索了一個行之有效的做法：随機抽取一段時間的使用者操作及其對應的資料，在版本釋出之前在實驗環境上進行回放，這樣一來，現實存在的絕大部分資料組合和業務場景就被覆寫了。對大部分網際網路公司而言，這個思路都是一個不錯的選擇。實施這個思路需要産品做一些工作：系統在處理完任何一個事務後，都需要留下足夠詳細的記錄，測試用這個記錄可以還原使用者業務場景，形成一個包含預置條件、操作步驟、預期結果在内的完整用例。
3.2.5 客戶問題rca分析
擴充測試類型和優化測試分析，目的都是使以前遺漏到客戶的那些類型的缺陷，在以後的測試中能攔截下來。是以，在确定方法之前，需要分析那些遺漏到客戶使用時才發現的缺陷，以找到測試過程或方法中存在的薄弱點。
客戶問題分析比較推薦的方法是根本原因分析（rca），這是一種回溯性失誤分析方法，包括确定和分析問題原因，找出問題解決辦法，并制訂問題攔截和預防措施。rca的一般分析過程如圖3-9所示。
在問題發生後，首先通過訪談和資料分析收集盡可能完整的問題資訊和資料。然後通過頭腦風暴、魚骨圖、因果圖、5why等分析方法确定直接原因（問題發生時事物的狀态、進行的操作，比如服務工程師誤操作）、根本原因（導緻問題必然發生的最本質原因，比如操作沒有分級權限控制）、間接原因（導緻問題發生的其他影響原因，比如操作員是新手）。最後針對分析出來的各個原因制訂對應的改進措施，并在措施實施後進行結果的核實和成果的推廣。
根本原因分析是一個通用的方法，在不同領域應用時，需要結構化的具體方法，用于解決不同領域的具體問題。
測試進行客戶問題的根本原因分析，主要是進行如下調查和追溯：
1）缺陷在項目的哪個階段被發現，缺陷的觸發條件、外在表現和業務影響有哪些。這些是缺陷的背景資訊，用于今後确定改進的優先級和設計用例。通常觸發條件不明的缺陷，不會進行根本原因分析。
2）缺陷的引入階段和引入的直接原因、間接原因、根本原因，如何避免引入這個缺陷？缺陷引入的原因可能是需求中缺乏相關資訊、代碼實作的疏忽、人員交接的遺漏等。通常缺陷都不是測試引入的，追問引入的原因，主要是為了找到問題改進的合夥人。
3）缺陷應該在哪個階段發現，測試遺漏的直接原因、間接原因、根本原因，如何才能發現？這是測試進行rca分析的核心，原因可能是需求分析錯誤、測試設計遺漏、缺少觀察點等。測試就是根據這些資訊最終歸整出改進方法。
4）在分析原因、制訂解決措施的時候，盡可能追問到根因，并且針對各層原因确定相應的解決措施。在啟動專項改進工作後，還需要根據技術難度、實施成本以及目标達成，确定究竟采取哪些措施、從那一層着手攔截缺陷。
rca分析中，測試遺漏的根因分析是最關鍵的環節。在我的經驗中，rca分析首先要注意：追問到技術原因，避免把責任心之類的人為原因作為根因。很多時候需要追問3～5次才能找到真正的根因。
下面以缺少觀察點導緻了資料不一緻缺陷的遺漏為例，說明rca問題分析和改進措施制訂過程。問題原因和措施如表3-2所示。
第一次追問why，得到直接原因，措施可以攔截這個缺陷，但同類缺陷無法攔截，治标不治本。
第二次追問why，得到間接原因，措施可以攔截這個缺陷，也可以攔截同類缺陷，但缺乏可實施性，隔靴搔癢。
第三次追問why，找到根本原因，措施可以攔截這類缺陷，改進徹底且可持續。
進行rca分析的工作量比較大，是以不可能對全部客戶問題進行分析，可以先進行一遍粗略的篩選，選出價值大或者典型的問題進行分析。
3.2.6 提升能力的目的是解決問題
我們的很多産品，都是以這類缺陷的爆發作為測試團隊、測試技術建設的契機，因為這時測試工作會比較容易擷取所需的人力和裝置資源。但是也有不少人在有這個機會時，卻把事情做砸了，究其原因，不外乎：
産品對測試的投入長期不足使得測試技術欠賬太多，終于品質問題開始失控，讓研發團隊痛下決心，加大對測試的人力投入。測試經理終于有了喘息之機，把很久就想做的測試設計方法應用、自動化、測試方案模闆規範化、dfx測試……一一落實。
那麼，問題來了：千頭萬緒，從哪裡開始？要不就是基于最近出現的、客戶反應激烈的幾個問題；要不就是測試經理有印象的一些問題；要不就幹脆不是基于問題，而是測試經理或幾個專家個人的技術偏好。具體實施某一項工作，比如測試設計，開展的工作就是組織團隊學習測試類型、測試設計方法，制訂測試的各種模闆，把寫的好的測試方案和用例做成樣闆或案例……，測試團隊緻力于學會使用标準的方法和模闆，使測試終于像一個有技術含量的工作，但是卻完全忘了當初為什麼要做這些。
最後，在局外人來看，測試團隊就是利用這些人，做了最基礎的、本來早就該做好的事情，真正的業務問題，并沒有思路和行動去解決。
這并不是說不能在這個時間進行基礎能力建設，而是說不能止步于此，需要着眼于問題，從問題分析得到解決方案，有能力則補齊短闆，最後以新具備的能力為基礎，結合其他輔助手段完成解決方案的實施，最終解決問題。這樣才算完成了一個問題閉合的循環，如圖3-10所示。
3.2.7 預則立不預則廢—重視網上問題分析
即使是成熟的測試團隊也可能會遇到這類問題。産品被用于新的客戶時，由于客戶内部組織、業務營運、發展曆史、文化等環境不同，産品上線初期幾乎都會出現這類問題。如果産品是一個統一版本用于多個客戶，遇到這類問題的機會就更大了。
可能研發團隊的所有成員，包括測試自己，在遇到這類問題時，都會覺得測試應該可以獨自解決這個問題，提升測試設計能力就可以了，因為很多時候，隻要測試執行時那樣操作了，缺陷是顯而易見的。但是真正分析這些問題，會發現當初在測試設計的時候，測試工程師根本沒有相應的資訊：不知道客戶還在用這個型号的機器、不知道客戶會這麼用、不知道有這種類别的使用者等。是以這個問題要改進，很多時候是需要市場代表、系統工程師、測試工程師合作的。
推薦的做法是：持續搜集和分析在客戶驗收、應用中發現的問題，對問題至少分析到軟體設計和測試設計的改進方法，周期性地進行統計。這樣，當某類問題比較突出的時候，可以把包括問題、解決方法、需要的協助（這個很重要）、改進後的效果等資訊完整、及時地拿出來。
一般開始統計之前确定的分類次元是特性、缺陷嚴重級别等，這樣分類并不利于問題的聚焦和解決措施的制訂，建議早期分析積累一定的資訊後，采用親和圖法（一種品質分析的方法）逐漸形成具有産品特點的分類統計的次元。
通常，在客戶沒有激烈的反應的時候，研發團隊也不會太在意這些問題，但是一旦客戶開始投訴，留給改進的時間窗就非常短。是以，建議在産品開始應用之初，就開始搜集、分析客戶發現的所有問題，當研發團隊沒有将問題改進提到議事日程的時候，測試先有資訊和方法、工具方面的準備，一旦問題爆發，就能夠給出多角色合作解決問題的可行方案。
測試團隊既要重視測試設計，也要重視客戶問題的分析，這是測試最重要的兩個手段，無論是個人能力提升，還是團隊技術積累都要用到。