2015年11月ThoughtWorks發布的技術雷達提到一個新的主題——產品環境下的QA（QA in Production），2016年4月再次提到。這個主題第一次出現在技術雷達，就深深的吸引了我，當時我就給測試團隊成員轉發了這個內容，但同時腦子里也產生了這樣一系列的疑問：
- 產品環境下的QA可以做什么呢？有什么挑戰，又有哪些好處？
- 它跟類產品環境的QA有何區別，是否就是類產品環境QA方法的延伸？
- 產品環境有運維支持團隊（Ops），產品環境下的QA跟Ops所做的事情又有什么區別與聯系？
帶著這些疑問，結合項目上的一系列實踐，于是有了本文。
產品環境的特點
為了盡量避免產品環境出現Bug，通常采取的措施是從“類產品環境”考慮，一步步做好質量控制。其實，如果能從產品環境做些QA工作，對于產品質量的提高也是有很大幫助的。想要做產品環境下的QA，首先得了解產品環境有哪些特點：
1. 真實、不可破壞
產品環境都是真實用戶在使用，是真正支持企業業務運轉的系統，不可以隨意在這個環境中做測試，尤其是破壞性的測試。
2. 基礎設施差異
產品環境往往有著比類產品環境更復雜和健全的基礎設施，可能會出現類產品環境不能預測到的缺陷和異常。
3. 系統復雜度
產品環境需要與多個不同的系統集成，系統復雜度會比類產品環境高很多，這種復雜的系統集成很有可能導致一些意外的情況出現。
4. 數據復雜度
產品環境的數據量和數據復雜度也是類產品環境無法比擬的，通常都不是一個數量級的數據，容易引發性能問題、或者一些復雜的數據組合導致的問題。
5. 用戶行為千奇百怪
產品環境中用戶分布廣泛，使用習慣各種各樣，導致用戶行為千奇百怪，某些使用行為可能就會產生意想不到的問題。
6. 訪問受限
產品環境由于是真實業務線上的系統，對安全性和穩定性要求更高，服務器通常不是所有QA可以隨便訪問的，這種訪問受限的情況對于產品環境的一些缺陷排查帶來了很大的不便。
7. 真實的用戶反饋
用戶在產品環境中使用，能夠提出一些真實而重要的反饋，但是開發團隊往往不能直接接觸終端用戶，QA也就沒有辦法獲得第一手的用戶反饋，這些反饋常常需要通過支持團隊來轉述。
產品環境的這些特點決定了QA在產品環境不是想做什么就能做什么的。原來類產品環境那套質量保證理論和方法都行不通了。那么，產品環境下的QA又有哪些特點呢？
產品環境下的QA的特點
一、不同于類產品環境的QA
產品環境的特點決定了產品環境下的QA是跟類產品環境的QA不同的，前者不能主動的去測試產品環境的系統，但是可以做到下面這些：
產品環境下的QA
- 引入產品系統的監控，制定監控預警標準，找出產品環境下使用的質量度量。比如，分析產品環境日志，收集系統運行的錯誤、異常和失敗等信息；或者利用網站分析工具收集用戶使用應用程序的數據，分析數據量需求、產品的性能趨勢、用戶的地域特征、用戶的行為習慣和產品在同類型產品市場的占有率等。
- 收集產品環境下最終用戶的反饋，對反饋進行分類分析。用戶反饋通常有缺陷、抱怨和建議，針對不同類型需要采取不同的處理方式，利用用戶反饋，改進系統功能，提高產品質量，同時優化業務價值，擴大產品的市場影響力，提高企業競爭力。
因此，產品環境下的QA并不是類產品環境QA活動的簡單后延，它有著自己獨特的特點。
二、不能獨立存在
產品環境下的QA所設置的監控標準是根據系統的行為特點和在類產品環境下的表現來定義的，產品環境下各項反饋的分析結果反過來又影響著類產品環境的QA過程，而且這兩者是相輔相成的，只有形成了良性環路，才能把產品環境下的QA做好。
三、有別于Ops
產品環境設置監控預警和收集用戶反饋不都是Ops團隊可以做的事情嗎？還要QA參與干什么？是因為QA有著獨特的思維模式和視角，QA的參與能夠幫助更好的分析產品環境下收集到的各種反饋，并且基于對于系統的了解，將這些反饋更好的應用到日常的開發工作中。QA在整個監控預警、收集和分析用戶反饋的過程中主要充當分析者和協調者的角色，對產品環境下的質量保證工作起到至關重要的作用。
產品環境下的QA與Ops
這時候的QA帶著QA和Ops的帽子，兼具QA和Ops的部分職責，類似于QAOps，不過現在都提倡不要有獨立的DevOps，我們也不要獨立的QAOps角色，只是讓QA這個角色可做的事情得到了延伸和擴展而已，本質上還是QA。
四、跟APM的側重點不同
可能有人會覺得產品環境下的QA跟APM有相似之處，那么這兩者是不是一回事呢？
維基百科這樣解釋APM：
“In the fields of information technology and systems management, application performance management (APM) is the monitoring and management of performance and availability of software applications. （在信息科技和系統管理領域，APM對軟件應用程序的性能和可用性的監控和管理。）”
APM更多的是從性能角度出發去管理和優化應用，可以發生在各個階段，不一定是產品環境。產品環境下的QA是指在產品環境進行一系列的監控和數據收集，從系統功能、性能、易用性等多個方面進行優化，從而最終優化業務價值。因此，兩者是不同的。
產品環境下的QA在項目上的實踐
我所在的項目是一個離岸交付項目，采用敏捷開發模式，四周一次發布到產品環境，開發的系統包括一個內部員工使用系統和一個外部用戶使用的網站，用戶遍及全球，整個項目已經持續了七年有余。產品環境具備前面所描述的所有特點，并且產品環境每日的錯誤日志達到幾千條。正是由于錯誤日志的數量到了一個不能忍的程度，產品環境才引起了各方的關注，也使得產品環境下的QA迎來了試點的最佳時機。產品環境下的QA在我們項目上的實踐主要是三部分內容：日志分析和優化、Google Analytics數據分析、用戶反饋的收集和分析。下面逐個介紹。
一、日志分析和優化
既然錯誤日志那么多，首先就是從這些錯誤日志下手。項目使用的日志分析工具是Splunk，這個工具功能強大、使用方便，關于工具的詳細信息可以參考官網。下圖所示為使用Splunk通過指定條件搜索日志文件得到的結果頁面，結果集里四條類似亂碼的東西就是代表有四種類型的錯誤日志，每種錯誤出現的數量和百分比都有統計，點擊每條結果可以查看詳細的錯誤日志信息。
Splunk日志分析
關于日志的分析和優化，我們在項目上做了如下工作：
1. 分析產品環境的錯誤日志
專人負責產品環境錯誤日志的分析，挑出優先級高的進行修復處理；對新功能進行日志監控，確保上線后能夠運行正常。
2. 監控測試環境的錯誤日志
把產品環境錯誤日志的分析方法應用于測試環境，讓bug發現提前到測試階段。據不完全統計，最近兩三個月通過這種方式發現并修復了好幾個潛在的Bug。
3. 利用日志監控不同功能的性能
Splunk里設有專門的統計和監控系統性能的Dashboard，QA會定期從里邊拿出高優先級的給開發人員進行性能調優。
4. 日志記錄標準化
現有的產品環境日志記錄中存在一些問題，給分析工作帶來不便。團隊為此進行討論并達成共識：
- 將日志輸出到各個服務器的同一個路徑；
- 統一日志記錄格式，并且盡量記錄更全面的信息以便進行后期的日志分析；
- 清晰定義各個日志級別（Debug，Info，Warning，Error，Critical，Fatal），將已有的誤記成錯誤的日志降低到正確的級別，對于新功能則嚴格按照所定義級別記錄日志；
- QA在用戶故事（Story）的開發機驗收（Dev-box Testing or Desk Check）階段負責跟開發人員確認相關日志記錄是否符合標準，并且通過測試環境的日志監控可以及時驗證新功能的日志記錄情況。
二、Google Analytics數據分析
Google Analytics（以下簡稱GA）是項目用來統計網站使用情況的工具，從GA上可以獲取很多有價值的信息，對這些信息進行分析是我們實踐的產品環境下QA的另一塊內容，具體做了下面幾項工作：
1. 操作系統和瀏覽器使用情況分析
根據產品環境操作系統和瀏覽器使用比例去調整測試環境所使用的系統，比如從重點關注IE9調整到IE11。
2. 分析QA測試跟用戶真實行為的差異，及時調整測試
根據GA上用戶訪問的路徑可以發現我們QA的測試跟一些真實用戶使用習慣的差異，這樣如果按照我們通常的路徑去測試，可能有些問題難以在測試階段被發現。比如，QA在測試環境通常打開“工作記錄”的方式是這樣的：
QA測試路徑
而我們從GA上發現真實用戶使用過程中，打開“工作記錄”最多的路徑是這樣的：
用戶使用路徑
發現了這種差異，QA就要在測試時候做相應的調整，讓測試更接近用戶的行為習慣。
3. 提煉關鍵業務場景，增加測試覆蓋
利用GA的數據結合客戶業務人員對系統各功能使用情況的介紹，我們提煉出系統最為關鍵的業務場景，并且盡量分層（參考測試金字塔）實現自動化測試覆蓋，以減輕QA回歸測試的壓力。
4. 發現用戶較少使用的功能，優化業務流程
類似的，我們還可以通過GA發現一些用戶較少使用的功能，QA的測試基本不需要太多去關注這些功能，同時可以跟業務分析人員一起分析功能不被使用的原因，在后續的功能開發過程中可以作為借鑒，從而優化業務流程。
5. 分析用戶地區分布和使用時間段分布，合理安排定時任務運行時間
通過GA上的數據，統計出哪個時間段是相對空閑的，在不影響真實業務的前提下，把一些資源消耗較大的任務安排在那個時候執行，合理分配資源以減輕服務器的負擔，盡量減少對用戶的影響。
6. 監控系統性能變化趨勢，規避性能風險
QA定期查看網站平均訪問時間，監控性能趨勢，同時要重點關注那些訪問非常慢的頁面或功能，必要的時候創建性能缺陷卡，由開發人員來調查分析并修復或優化。
7. 確保GA能夠統計到所有需要統計的功能
GA數據雖然很有用，但前提是正確記錄了所需要統計的數據，所以在開發過程中要確保GA嵌入到了各個需要統計的功能或頁面，QA在類產品環境測試的時候需要驗證這一點。
下圖為從GA拿到的瀏覽器分布情況和頁面平均加載時間的一些數據：
GA數據分析
三、用戶反饋的收集和分析
作為開發團隊的我們基本是不能直接接觸到系統終端用戶的，直接接受反饋的是客戶的Ops團隊，QA主要通過下面幾個途徑去協助分析和梳理用戶反饋：
1. 跟Ops和業務的定期溝通會議
QA會定期跟客戶的Ops和業務人員溝通，了解用戶對于現有系統的反饋，找出在測試中需要重視的功能特性，對類產品環境的測試關注點做出相應的調整。
2. 培訓Ops人員
指導和協助客戶Ops人員利用魚骨圖（Fishbone Diagram）的方法對收集到的用戶反饋進行分析和分類，將分析結果跟現有的測試覆蓋情況進行對比，找出測試過程的薄弱環節，并做出改進。比如，如果某個瀏覽器出現的bug比較多，我們的測試就要加強該瀏覽器的關注；或者在發現不同用戶權限導致的問題出現頻率高，那就得在測試中注意覆蓋不同用戶角色的測試，反之則減弱不同用戶的覆蓋，主要測最常用的那類角色即可。
3. 調查和跟蹤產品環境Bug
幫助重現和調查用戶反饋過來的產品環境Bug，并負責跟蹤修復和驗證；對于難以重現的問題，則添加日志監控，通過分析收集到的日志信息找出問題根源，從而進行修復。
4. 協助梳理業務需求
系統要增加某個新功能的時候，客戶Product Owner（以下簡稱PO）或其他業務人員跟用戶會一起溝通該功能相關業務現有的使用習慣、使用場景，QA也會盡量參與這種會議，收集用戶第一手需求信息，這些信息對于后期該業務功能開發時候的QA過程將非常有幫助。而還有些功能，PO可能一時也拿不定主意要做成什么樣子，我們會發布MVP的版本給用戶使用，QA協助業務人員分析用戶使用后的反饋，梳理更具體的用戶需求。
總結
- 產品環境下的QA將工作范圍從需求擴大到了產品環境，增加了更多的反饋來源，跟持續交付結合，可以幫助持續提高產品質量、優化業務價值。
- 產品環境下的QA給的工具箱添加了更多的工具，提供了更多評估和提高系統質量的選項，是QA們值得深入研究的話題。
- 產品環境下的QA不能走的太遠，必須先做好類產品環境的質量保證，并且僅適用于持續交付實踐的比較好的組織。如果連類產品環境的質量保證都做不好，就想著去做產品環境下的QA，那只能是舍本逐末、事倍功半。
