2015年11月ThoughtWorks發(fā)布的技術雷達提到一個新的主題——產品環(huán)境下的QA（QA in Production）陨晶，2016年4月再次提到。這個主題第一次出現在技術雷達帝璧，就深深的吸引了我先誉，當時我就給測試團隊成員轉發(fā)了這個內容，但同時腦子里也產生了這樣一系列的疑問：
- 產品環(huán)境下的QA可以做什么呢的烁？有什么挑戰(zhàn)褐耳，又有哪些好處？
- 它跟類產品環(huán)境的QA有何區(qū)別渴庆，是否就是類產品環(huán)境QA方法的延伸铃芦？
- 產品環(huán)境有運維支持團隊（Ops）雅镊，產品環(huán)境下的QA跟Ops所做的事情又有什么區(qū)別與聯(lián)系？
帶著這些疑問刃滓，結合項目上的一系列實踐仁烹，于是有了本文。
產品環(huán)境的特點
為了盡量避免產品環(huán)境出現Bug咧虎，通常采取的措施是從“類產品環(huán)境”考慮卓缰，一步步做好質量控制。其實砰诵，如果能從產品環(huán)境做些QA工作征唬，對于產品質量的提高也是有很大幫助的。想要做產品環(huán)境下的QA茁彭，首先得了解產品環(huán)境有哪些特點：
1. 真實总寒、不可破壞
產品環(huán)境都是真實用戶在使用，是真正支持企業(yè)業(yè)務運轉的系統(tǒng)尉间，不可以隨意在這個環(huán)境中做測試偿乖，尤其是破壞性的測試。
2. 基礎設施差異
產品環(huán)境往往有著比類產品環(huán)境更復雜和健全的基礎設施哲嘲，可能會出現類產品環(huán)境不能預測到的缺陷和異常。
3. 系統(tǒng)復雜度
產品環(huán)境需要與多個不同的系統(tǒng)集成媳禁，系統(tǒng)復雜度會比類產品環(huán)境高很多眠副，這種復雜的系統(tǒng)集成很有可能導致一些意外的情況出現。
4. 數據復雜度
產品環(huán)境的數據量和數據復雜度也是類產品環(huán)境無法比擬的竣稽，通常都不是一個數量級的數據囱怕，容易引發(fā)性能問題、或者一些復雜的數據組合導致的問題毫别。
5. 用戶行為千奇百怪
產品環(huán)境中用戶分布廣泛娃弓，使用習慣各種各樣，導致用戶行為千奇百怪岛宦，某些使用行為可能就會產生意想不到的問題台丛。
6. 訪問受限
產品環(huán)境由于是真實業(yè)務線上的系統(tǒng)，對安全性和穩(wěn)定性要求更高砾肺，服務器通常不是所有QA可以隨便訪問的挽霉，這種訪問受限的情況對于產品環(huán)境的一些缺陷排查帶來了很大的不便。
7. 真實的用戶反饋
用戶在產品環(huán)境中使用变汪，能夠提出一些真實而重要的反饋侠坎，但是開發(fā)團隊往往不能直接接觸終端用戶，QA也就沒有辦法獲得第一手的用戶反饋裙盾，這些反饋常常需要通過支持團隊來轉述实胸。
產品環(huán)境的這些特點決定了QA在產品環(huán)境不是想做什么就能做什么的他嫡。原來類產品環(huán)境那套質量保證理論和方法都行不通了。那么庐完，產品環(huán)境下的QA又有哪些特點呢钢属？
產品環(huán)境下的QA的特點
一、不同于類產品環(huán)境的QA
產品環(huán)境的特點決定了產品環(huán)境下的QA是跟類產品環(huán)境的QA不同的假褪，前者不能主動的去測試產品環(huán)境的系統(tǒng)署咽，但是可以做到下面這些：
產品環(huán)境下的QA
- 引入產品系統(tǒng)的監(jiān)控，制定監(jiān)控預警標準生音，找出產品環(huán)境下使用的質量度量宁否。比如，分析產品環(huán)境日志缀遍，收集系統(tǒng)運行的錯誤慕匠、異常和失敗等信息；或者利用網站分析工具收集用戶使用應用程序的數據域醇，分析數據量需求台谊、產品的性能趨勢、用戶的地域特征譬挚、用戶的行為習慣和產品在同類型產品市場的占有率等锅铅。
- 收集產品環(huán)境下最終用戶的反饋，對反饋進行分類分析减宣。用戶反饋通常有缺陷盐须、抱怨和建議，針對不同類型需要采取不同的處理方式漆腌，利用用戶反饋贼邓，改進系統(tǒng)功能，提高產品質量闷尿，同時優(yōu)化業(yè)務價值塑径，擴大產品的市場影響力，提高企業(yè)競爭力填具。
因此统舀，產品環(huán)境下的QA并不是類產品環(huán)境QA活動的簡單后延，它有著自己獨特的特點灌旧。
二绑咱、不能獨立存在
產品環(huán)境下的QA所設置的監(jiān)控標準是根據系統(tǒng)的行為特點和在類產品環(huán)境下的表現來定義的，產品環(huán)境下各項反饋的分析結果反過來又影響著類產品環(huán)境的QA過程枢泰，而且這兩者是相輔相成的描融，只有形成了良性環(huán)路惊豺，才能把產品環(huán)境下的QA做好矮固。
三棚愤、有別于Ops
產品環(huán)境設置監(jiān)控預警和收集用戶反饋不都是Ops團隊可以做的事情嗎髓涯？還要QA參與干什么？是因為QA有著獨特的思維模式和視角年叮，QA的參與能夠幫助更好的分析產品環(huán)境下收集到的各種反饋具被，并且基于對于系統(tǒng)的了解，將這些反饋更好的應用到日常的開發(fā)工作中只损。QA在整個監(jiān)控預警一姿、收集和分析用戶反饋的過程中主要充當分析者和協(xié)調者的角色，對產品環(huán)境下的質量保證工作起到至關重要的作用跃惫。
產品環(huán)境下的QA與Ops
這時候的QA帶著QA和Ops的帽子叮叹，兼具QA和Ops的部分職責，類似于QAOps爆存，不過現在都提倡不要有獨立的DevOps蛉顽，我們也不要獨立的QAOps角色，只是讓QA這個角色可做的事情得到了延伸和擴展而已先较，本質上還是QA携冤。
四、跟APM的側重點不同
可能有人會覺得產品環(huán)境下的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. （在信息科技和系統(tǒng)管理領域，APM對軟件應用程序的性能和可用性的監(jiān)控和管理菜循。）”
APM更多的是從性能角度出發(fā)去管理和優(yōu)化應用睁蕾，可以發(fā)生在各個階段，不一定是產品環(huán)境债朵。產品環(huán)境下的QA是指在產品環(huán)境進行一系列的監(jiān)控和數據收集，從系統(tǒng)功能瀑凝、性能序芦、易用性等多個方面進行優(yōu)化，從而最終優(yōu)化業(yè)務價值粤咪。因此谚中，兩者是不同的。
產品環(huán)境下的QA在項目上的實踐
我所在的項目是一個離岸交付項目寥枝，采用敏捷開發(fā)模式宪塔，四周一次發(fā)布到產品環(huán)境，開發(fā)的系統(tǒng)包括一個內部員工使用系統(tǒng)和一個外部用戶使用的網站囊拜，用戶遍及全球某筐，整個項目已經持續(xù)了七年有余。產品環(huán)境具備前面所描述的所有特點冠跷，并且產品環(huán)境每日的錯誤日志達到幾千條南誊。正是由于錯誤日志的數量到了一個不能忍的程度身诺，產品環(huán)境才引起了各方的關注，也使得產品環(huán)境下的QA迎來了試點的最佳時機抄囚。產品環(huán)境下的QA在我們項目上的實踐主要是三部分內容：日志分析和優(yōu)化霉赡、Google Analytics數據分析、用戶反饋的收集和分析幔托。下面逐個介紹穴亏。
一、日志分析和優(yōu)化
既然錯誤日志那么多重挑，首先就是從這些錯誤日志下手嗓化。項目使用的日志分析工具是Splunk，這個工具功能強大攒驰、使用方便蟆湖，關于工具的詳細信息可以參考官網。下圖所示為使用Splunk通過指定條件搜索日志文件得到的結果頁面玻粪，結果集里四條類似亂碼的東西就是代表有四種類型的錯誤日志隅津，每種錯誤出現的數量和百分比都有統(tǒng)計，點擊每條結果可以查看詳細的錯誤日志信息劲室。
Splunk日志分析
關于日志的分析和優(yōu)化伦仍，我們在項目上做了如下工作：
1. 分析產品環(huán)境的錯誤日志
專人負責產品環(huán)境錯誤日志的分析，挑出優(yōu)先級高的進行修復處理很洋；對新功能進行日志監(jiān)控充蓝，確保上線后能夠運行正常。
2. 監(jiān)控測試環(huán)境的錯誤日志
把產品環(huán)境錯誤日志的分析方法應用于測試環(huán)境喉磁，讓bug發(fā)現提前到測試階段谓苟。據不完全統(tǒng)計，最近兩三個月通過這種方式發(fā)現并修復了好幾個潛在的Bug协怒。
3. 利用日志監(jiān)控不同功能的性能
Splunk里設有專門的統(tǒng)計和監(jiān)控系統(tǒng)性能的Dashboard涝焙，QA會定期從里邊拿出高優(yōu)先級的給開發(fā)人員進行性能調優(yōu)。
4. 日志記錄標準化
現有的產品環(huán)境日志記錄中存在一些問題孕暇，給分析工作帶來不便仑撞。團隊為此進行討論并達成共識：
- 將日志輸出到各個服務器的同一個路徑；
- 統(tǒng)一日志記錄格式妖滔，并且盡量記錄更全面的信息以便進行后期的日志分析隧哮；
- 清晰定義各個日志級別（Debug，Info座舍，Warning沮翔，Error，Critical簸州，Fatal）鉴竭，將已有的誤記成錯誤的日志降低到正確的級別歧譬，對于新功能則嚴格按照所定義級別記錄日志；
- QA在用戶故事（Story）的開發(fā)機驗收（Dev-box Testing or Desk Check）階段負責跟開發(fā)人員確認相關日志記錄是否符合標準搏存，并且通過測試環(huán)境的日志監(jiān)控可以及時驗證新功能的日志記錄情況瑰步。
二、Google Analytics數據分析
Google Analytics（以下簡稱GA）是項目用來統(tǒng)計網站使用情況的工具璧眠，從GA上可以獲取很多有價值的信息缩焦，對這些信息進行分析是我們實踐的產品環(huán)境下QA的另一塊內容，具體做了下面幾項工作：
1. 操作系統(tǒng)和瀏覽器使用情況分析
根據產品環(huán)境操作系統(tǒng)和瀏覽器使用比例去調整測試環(huán)境所使用的系統(tǒng)责静，比如從重點關注IE9調整到IE11袁滥。
2. 分析QA測試跟用戶真實行為的差異，及時調整測試
根據GA上用戶訪問的路徑可以發(fā)現我們QA的測試跟一些真實用戶使用習慣的差異灾螃，這樣如果按照我們通常的路徑去測試题翻，可能有些問題難以在測試階段被發(fā)現。比如腰鬼，QA在測試環(huán)境通常打開“工作記錄”的方式是這樣的：
QA測試路徑
而我們從GA上發(fā)現真實用戶使用過程中嵌赠，打開“工作記錄”最多的路徑是這樣的：
用戶使用路徑
發(fā)現了這種差異，QA就要在測試時候做相應的調整熄赡，讓測試更接近用戶的行為習慣姜挺。
3. 提煉關鍵業(yè)務場景，增加測試覆蓋
利用GA的數據結合客戶業(yè)務人員對系統(tǒng)各功能使用情況的介紹彼硫，我們提煉出系統(tǒng)最為關鍵的業(yè)務場景炊豪，并且盡量分層（參考測試金字塔）實現自動化測試覆蓋，以減輕QA回歸測試的壓力拧篮。
4. 發(fā)現用戶較少使用的功能词渤，優(yōu)化業(yè)務流程
類似的，我們還可以通過GA發(fā)現一些用戶較少使用的功能串绩，QA的測試基本不需要太多去關注這些功能掖肋，同時可以跟業(yè)務分析人員一起分析功能不被使用的原因，在后續(xù)的功能開發(fā)過程中可以作為借鑒赏参，從而優(yōu)化業(yè)務流程。
5. 分析用戶地區(qū)分布和使用時間段分布沿盅，合理安排定時任務運行時間
通過GA上的數據把篓，統(tǒng)計出哪個時間段是相對空閑的，在不影響真實業(yè)務的前提下腰涧，把一些資源消耗較大的任務安排在那個時候執(zhí)行韧掩，合理分配資源以減輕服務器的負擔，盡量減少對用戶的影響窖铡。
6. 監(jiān)控系統(tǒng)性能變化趨勢疗锐，規(guī)避性能風險
QA定期查看網站平均訪問時間坊谁，監(jiān)控性能趨勢，同時要重點關注那些訪問非常慢的頁面或功能滑臊，必要的時候創(chuàng)建性能缺陷卡口芍，由開發(fā)人員來調查分析并修復或優(yōu)化。
7. 確保GA能夠統(tǒng)計到所有需要統(tǒng)計的功能
GA數據雖然很有用雇卷，但前提是正確記錄了所需要統(tǒng)計的數據鬓椭，所以在開發(fā)過程中要確保GA嵌入到了各個需要統(tǒng)計的功能或頁面，QA在類產品環(huán)境測試的時候需要驗證這一點关划。
下圖為從GA拿到的瀏覽器分布情況和頁面平均加載時間的一些數據：
GA數據分析
三小染、用戶反饋的收集和分析
作為開發(fā)團隊的我們基本是不能直接接觸到系統(tǒng)終端用戶的，直接接受反饋的是客戶的Ops團隊贮折，QA主要通過下面幾個途徑去協(xié)助分析和梳理用戶反饋：
1. 跟Ops和業(yè)務的定期溝通會議
QA會定期跟客戶的Ops和業(yè)務人員溝通裤翩，了解用戶對于現有系統(tǒng)的反饋，找出在測試中需要重視的功能特性调榄，對類產品環(huán)境的測試關注點做出相應的調整踊赠。
2. 培訓Ops人員
指導和協(xié)助客戶Ops人員利用魚骨圖（Fishbone Diagram）的方法對收集到的用戶反饋進行分析和分類，將分析結果跟現有的測試覆蓋情況進行對比振峻，找出測試過程的薄弱環(huán)節(jié)臼疫，并做出改進。比如扣孟，如果某個瀏覽器出現的bug比較多烫堤，我們的測試就要加強該瀏覽器的關注；或者在發(fā)現不同用戶權限導致的問題出現頻率高凤价，那就得在測試中注意覆蓋不同用戶角色的測試鸽斟，反之則減弱不同用戶的覆蓋，主要測最常用的那類角色即可利诺。
3. 調查和跟蹤產品環(huán)境Bug
幫助重現和調查用戶反饋過來的產品環(huán)境Bug富蓄，并負責跟蹤修復和驗證；對于難以重現的問題慢逾，則添加日志監(jiān)控立倍，通過分析收集到的日志信息找出問題根源，從而進行修復侣滩。
4. 協(xié)助梳理業(yè)務需求
系統(tǒng)要增加某個新功能的時候口注，客戶Product Owner（以下簡稱PO）或其他業(yè)務人員跟用戶會一起溝通該功能相關業(yè)務現有的使用習慣、使用場景君珠，QA也會盡量參與這種會議寝志，收集用戶第一手需求信息，這些信息對于后期該業(yè)務功能開發(fā)時候的QA過程將非常有幫助。而還有些功能材部，PO可能一時也拿不定主意要做成什么樣子毫缆，我們會發(fā)布MVP的版本給用戶使用，QA協(xié)助業(yè)務人員分析用戶使用后的反饋乐导，梳理更具體的用戶需求苦丁。
總結
- 產品環(huán)境下的QA將工作范圍從需求擴大到了產品環(huán)境，增加了更多的反饋來源兽叮，跟持續(xù)交付結合芬骄，可以幫助持續(xù)提高產品質量、優(yōu)化業(yè)務價值鹦聪。
- 產品環(huán)境下的QA給的工具箱添加了更多的工具账阻，提供了更多評估和提高系統(tǒng)質量的選項，是QA們值得深入研究的話題泽本。
- 產品環(huán)境下的QA不能走的太遠淘太，必須先做好類產品環(huán)境的質量保證，并且僅適用于持續(xù)交付實踐的比較好的組織规丽。如果連類產品環(huán)境的質量保證都做不好蒲牧，就想著去做產品環(huán)境下的QA，那只能是舍本逐末赌莺、事倍功半冰抢。
