2015年11月ThoughtWorks發(fā)布的技術(shù)雷達(dá)提到一個新的主題——產(chǎn)品環(huán)境下的QA（QA in Production），2016年4月再次提到。這個主題第一次出現(xiàn)在技術(shù)雷達(dá)，就深深的吸引了我，當(dāng)時我就給測試團(tuán)隊(duì)成員轉(zhuǎn)發(fā)了這個內(nèi)容，但同時腦子里卻產(chǎn)生這樣一系列的疑問：
- 產(chǎn)品環(huán)境下的QA可以做什么呢？有什么挑戰(zhàn)，又有哪些好處？
- 它跟類產(chǎn)品環(huán)境的QA有何區(qū)別，是否就是類產(chǎn)品環(huán)境QA方法的延伸？
- 產(chǎn)品環(huán)境有運(yùn)維支持團(tuán)隊(duì)（Ops），產(chǎn)品環(huán)境下的QA跟Ops所做的事情又有什么區(qū)別與聯(lián)系？
帶著這些疑問，結(jié)合項(xiàng)目上的一系列實(shí)踐，于是有了本文。
一個產(chǎn)品環(huán)境Bug的解決辦法
先來跟大家分享一個產(chǎn)品環(huán)境下的Bug：
一個在線訂購葡萄酒的系統(tǒng)，訂購流程相對復(fù)雜，下單過程中后臺會有隨機(jī)的失敗，系統(tǒng)采取的措施是重試，就是說顧客下單后，后臺如果有錯誤就會不停的重試，直到成功，這個過程對顧客是不可見的。這聽起來沒什么問題，用戶體驗(yàn)似乎也不錯。
后來有個新版本上線了，顧客下單后還是會有隨機(jī)失敗，系統(tǒng)依然不停的重試，但這次不一樣的是有的隨機(jī)失敗，下單卻能夠成功，這樣就導(dǎo)致用戶雖然只訂購一箱葡萄酒，由于后臺的多次重試都成功了，用戶最終拿到的可能是好幾百箱葡萄酒。
這是一個非常嚴(yán)重且昂貴的Bug！對于這樣的問題，作為QA，你能想到的解決辦法有哪些？
瀑布式QA流程
瀑布式軟件開發(fā)模式下，測試是計(jì)劃驅(qū)動的，基本是根據(jù)需求文檔進(jìn)行驗(yàn)證，測試的目的就是找到盡可能多的bug，而且測試階段處于開發(fā)階段結(jié)束之后的一個相對獨(dú)立的階段，測試結(jié)束之后發(fā)布產(chǎn)品到產(chǎn)品環(huán)境?；玖鞒倘缦拢?/p>
對于上述葡萄酒訂購系統(tǒng)的Bug，通常的辦法就是加強(qiáng)在測試階段的測試保證，除了驗(yàn)證系統(tǒng)功能跟需求文檔的一致性以外，還可以增加一些ad hoc測試，確保發(fā)布到產(chǎn)品環(huán)境的系統(tǒng)盡量的穩(wěn)定。
敏捷QA流程
敏捷測試則提倡盡早測試、頻繁測試，QA要從需求分析階段就開始介入，QA參與從需求到發(fā)布的整個生命周期中各個階段。在整個QA的過程中，會依據(jù)敏捷測試象限，在不同階段采取不同的測試；還會根據(jù)測試金字塔的分層指導(dǎo)，加強(qiáng)自動化測試，制定有利于項(xiàng)目質(zhì)量保證的測試策略，同時也會做探索性測試，盡量去發(fā)現(xiàn)更多不易發(fā)現(xiàn)的缺陷。敏捷QA的流程如下：
對于葡萄酒訂購系統(tǒng)的bug，處理方式也無非就是加強(qiáng)上線前各個階段的測試，提高發(fā)布到產(chǎn)品環(huán)境的產(chǎn)品質(zhì)量。
除此之外，我們還有什么處理辦法呢？
上面兩種開發(fā)模式下，QA的重點(diǎn)都是放在發(fā)布前的類產(chǎn)品環(huán)境的質(zhì)量保證上，而較少考慮產(chǎn)品環(huán)境的系統(tǒng)質(zhì)量。隨著敏捷開發(fā)和持續(xù)交付的出現(xiàn)，QA角色逐漸轉(zhuǎn)變到需要分析軟件產(chǎn)品在產(chǎn)品環(huán)境下的質(zhì)量。這需要引入產(chǎn)品系統(tǒng)的監(jiān)控, 制定檢測緊急錯誤的警報條件，持續(xù)質(zhì)量問題的確定以及找出在產(chǎn)品環(huán)境下使用的度量以保證這種方式可行。
回到前面葡萄酒訂購系統(tǒng)的那個Bug，如果在產(chǎn)品環(huán)境下設(shè)置監(jiān)控預(yù)警，對于一個訂單購買葡萄酒數(shù)量異常的情況進(jìn)行監(jiān)控，將能及時發(fā)現(xiàn)bug，并且比較容易在損失發(fā)生之前及時阻止產(chǎn)生更嚴(yán)重的后果。這就是產(chǎn)品環(huán)境下的QA內(nèi)容之一！
產(chǎn)品環(huán)境的特點(diǎn)
為了更好的實(shí)踐產(chǎn)品環(huán)境下的QA，先來分析下產(chǎn)品環(huán)境有哪些特點(diǎn)：
1. 真實(shí)、不可破壞
產(chǎn)品環(huán)境都是真實(shí)用戶在使用，是真正的支持企業(yè)業(yè)務(wù)運(yùn)轉(zhuǎn)的系統(tǒng)，不可以隨意在產(chǎn)品環(huán)境去做測試，尤其是破壞性的測試。
2. 基礎(chǔ)設(shè)施差異
產(chǎn)品環(huán)境往往有著比類產(chǎn)品環(huán)境要復(fù)雜和健全的基礎(chǔ)設(shè)施，可能會出現(xiàn)類產(chǎn)品環(huán)境不能預(yù)測到的缺陷和異常。
3. 系統(tǒng)復(fù)雜度
產(chǎn)品環(huán)境需要與多個不同的系統(tǒng)集成，系統(tǒng)復(fù)雜度會比類產(chǎn)品環(huán)境高很多，這種復(fù)雜的系統(tǒng)集成很有可能導(dǎo)致一些意外的情況出現(xiàn)。
4. 數(shù)據(jù)復(fù)雜度
產(chǎn)品環(huán)境的數(shù)據(jù)量和數(shù)據(jù)復(fù)雜度也是類產(chǎn)品環(huán)境無法比擬的，通常都不是一個數(shù)量級的數(shù)據(jù)，容易引發(fā)性能問題、或者一些復(fù)雜的數(shù)據(jù)組合導(dǎo)致的問題。
5. 用戶行為千奇百怪
產(chǎn)品環(huán)境的用戶分布廣泛，使用習(xí)慣各種各樣，導(dǎo)致用戶行為千奇百怪，某些使用行為可能就會產(chǎn)生意想不到的問題。
6. 訪問受限
產(chǎn)品環(huán)境由于是真實(shí)業(yè)務(wù)線上的系統(tǒng)，對安全性和穩(wěn)定性要求更高，服務(wù)器的通常不是所有QA可以隨便訪問的，這種訪問受限的情況對于產(chǎn)品環(huán)境的一些缺陷的排查帶來了很大的不便。
7. 真實(shí)的用戶反饋
真實(shí)用戶在產(chǎn)品環(huán)境使用，能夠提出一些真實(shí)而重要的反饋，但是開發(fā)團(tuán)隊(duì)往往不能直接接觸終端用戶，QA也就沒有辦法獲得第一手的用戶反饋，這些反饋常常需要通過支持團(tuán)隊(duì)的轉(zhuǎn)述。
產(chǎn)品環(huán)境的這些特點(diǎn)決定了QA在產(chǎn)品環(huán)境不是想做什么就能做什么的，原來類產(chǎn)品環(huán)境那套質(zhì)量保證理論和方法都行不通了。
產(chǎn)品環(huán)境下的QA有這么多挑戰(zhàn)，聽起來是不是很沮喪？不要著急，針對產(chǎn)品環(huán)境獨(dú)有的特點(diǎn)，一定能找到相應(yīng)的解決方案。接下來，咱們一起來看看產(chǎn)品環(huán)境下（不僅是QA）可以做什么。
產(chǎn)品環(huán)境下可以做什么
一、監(jiān)控預(yù)警
前面講到不能隨便去操作產(chǎn)品環(huán)境下的系統(tǒng)對其進(jìn)行測試，但是可以通過監(jiān)控的方式去獲得我們需要的信息，對異常情況進(jìn)行預(yù)警。提到監(jiān)控預(yù)警，不得不提大家都了解或者至少聽說過的日志和網(wǎng)站分析工具，這兩者都是做好產(chǎn)品環(huán)境下的QA非常有幫助的工具。
日志
日志就像是飛機(jī)上的黑匣子，可以記錄系統(tǒng)運(yùn)行的各種信息，包括錯誤、異常和失敗等。一旦程序出現(xiàn)問題，記錄的這些信息就可以用來分析問題的原因；同時可以利用記錄的日志設(shè)置好預(yù)警，提前預(yù)測系統(tǒng)可能出現(xiàn)的問題。產(chǎn)品環(huán)境下日志所提供的監(jiān)控和預(yù)警信息，將有利于：
- 阻止不良后果，避免大的損失：前面提到的葡萄酒訂購系統(tǒng)就是一個很好的例子；
- 發(fā)現(xiàn)潛在的性能問題：通過對日志進(jìn)行分析，可能發(fā)現(xiàn)還沒暴露出來的性能問題，提前修復(fù)；
- 指導(dǎo)類產(chǎn)品環(huán)境的測試：通過產(chǎn)品環(huán)境下日志的分析，可以看出哪些功能易出什么樣的錯誤，從而相應(yīng)調(diào)整測試策略，加強(qiáng)類產(chǎn)品環(huán)境的相關(guān)功能的測試。
網(wǎng)站分析工具
網(wǎng)站分析工具根據(jù)具體工具不同，所能記錄信息也有差異，但基本都可以記錄如下信息：
- 用戶使用的操作系統(tǒng)、瀏覽器等信息
- 用戶行為習(xí)慣，包括使用的時間、關(guān)鍵路徑、關(guān)鍵業(yè)務(wù)流程等
- 用戶所在地區(qū)、語言等區(qū)域信息
- 用戶訪問量，請求的響應(yīng)時間，網(wǎng)站性能等
利用網(wǎng)站分析工具收集到的以上數(shù)據(jù)，可以幫助我們調(diào)整類產(chǎn)品環(huán)境的測試側(cè)重點(diǎn)，指導(dǎo)類產(chǎn)品環(huán)境的測試；根據(jù)用戶行為習(xí)慣等信息，還可以幫助優(yōu)化產(chǎn)品業(yè)務(wù)價值。
二、用戶反饋
介紹產(chǎn)品環(huán)境特點(diǎn)的時候提到一點(diǎn)就是產(chǎn)品環(huán)境能夠收到真實(shí)的用戶反饋，這是非常有價值的，要做好產(chǎn)品環(huán)境下的QA一定要利用這些反饋。由于用戶行為和習(xí)慣的千奇百怪，用戶提供的反饋也可能是各種各樣的，為了更好的利用它們，需要一個嚴(yán)格的Triage的過程，對所有反饋進(jìn)行分類并相應(yīng)處理。用戶反饋，可以總結(jié)為下面幾類：
缺陷
用戶在使用過程中，系統(tǒng)所出現(xiàn)的問題，并且能夠穩(wěn)定重現(xiàn)的，我們定義為缺陷，缺陷通常會影響到功能的使用，是需要修復(fù)的，根據(jù)優(yōu)先級和嚴(yán)重程度，安排相應(yīng)的修復(fù)計(jì)劃并對其進(jìn)行修復(fù)，同時還需要對修復(fù)的缺陷增加（自動化）測試，以防被再次破壞。
除了能夠穩(wěn)定重現(xiàn)的缺陷，有時候還會有一些隨機(jī)的失敗（比如前面提到的葡萄酒訂購系統(tǒng)的bug）或者難以重現(xiàn)的問題，這類問題很難找到原因，但是又給用戶帶來很大的不爽。其實(shí)，它們通常也是一些缺陷引起的，只是根源可能隱藏的比較深，對于這種問題的處理辦法就是前面部分提到的可以添加日志對相關(guān)功能進(jìn)行監(jiān)控和預(yù)警，利用日志協(xié)助找到問題根源并進(jìn)行修復(fù)。
抱怨
用戶在使用系統(tǒng)過程中由于行為習(xí)慣、網(wǎng)絡(luò)環(huán)境等差異，總會有各種抱怨，一般以非功能性的問題居多，比如易用性、性能、可維護(hù)性、可擴(kuò)展性等，當(dāng)然也有可能是某個功能設(shè)計(jì)的不能滿足真實(shí)的用戶需求。需要對所有抱怨進(jìn)行分類，確定是非功能的缺陷，還是新的需求。用戶的抱怨有可能千奇百怪，不是所有的都能滿足，需要根據(jù)分類定義優(yōu)先級，確定哪些是需要改進(jìn)和修復(fù)，從而采取相應(yīng)的措施。
建議
除了反饋問題和提出抱怨，用戶也會對系統(tǒng)使用方面提一些建議。但一般用戶很難提出好的建議，要想收集到有價值的信息，需要提前設(shè)計(jì)好問卷進(jìn)行問卷調(diào)查，有針對性的去收集；或者對一些重要用戶進(jìn)行訪談，或者發(fā)布一個簡單的新功能收集用戶的使用建議等。然后對收集到的建議進(jìn)行分析，確定可行性，并將可行的建議應(yīng)用到后續(xù)的系統(tǒng)和業(yè)務(wù)流程的改進(jìn)中。
利用用戶反饋，改進(jìn)系統(tǒng)功能，可以優(yōu)化業(yè)務(wù)價值，擴(kuò)大產(chǎn)品的市場影響力，提高企業(yè)的競爭力。常被用來收集用戶反饋的實(shí)踐有：
- Beta測試：很多有前瞻性的網(wǎng)站或應(yīng)用會發(fā)布新功能給特定用戶組（Beta用戶），收集用戶使用新功能的統(tǒng)計(jì)數(shù)據(jù)；
- AB測試：同時發(fā)布兩個不同版本的系統(tǒng)到產(chǎn)品環(huán)境，并將用戶引導(dǎo)到兩個版本，統(tǒng)計(jì)使用每個版本的用戶數(shù)據(jù)；
- Observed Requirement：發(fā)布一個簡單的功能，或者發(fā)布一個MVP版本，觀察用戶使用情況，從而引出并收集到用戶的真實(shí)需求。
監(jiān)控預(yù)警、收集和分析用戶反饋并不是QA能獨(dú)立完成的，需要與不同角色協(xié)作，QA在整個過程中主要充當(dāng)分析者和協(xié)調(diào)者的角色，對產(chǎn)品環(huán)境下的質(zhì)量保證工作起到至關(guān)重要的作用：
- 跟DEV一起討論監(jiān)控標(biāo)準(zhǔn)，把日志標(biāo)準(zhǔn)化的要求融入到軟件開發(fā)流程中，確保日志能夠記錄到真正需要記錄的信息。
- 跟運(yùn)維團(tuán)隊(duì)一起分析收集到的統(tǒng)計(jì)數(shù)據(jù)，指導(dǎo)和優(yōu)化各個階段的測試，以預(yù)防和減少系統(tǒng)在產(chǎn)品環(huán)境下的缺陷。
- 跟業(yè)務(wù)分析人員一起分析和梳理從產(chǎn)品環(huán)境收集到的需求相關(guān)的反饋，提煉出合理的需求，優(yōu)化業(yè)務(wù)價值。
產(chǎn)品環(huán)境下的QA在項(xiàng)目上的實(shí)踐
我所在的項(xiàng)目是一個離岸交付項(xiàng)目，采用的是敏捷開發(fā)模式，四周一次發(fā)布到產(chǎn)品環(huán)境，開發(fā)的系統(tǒng)包括一個內(nèi)部員工使用系統(tǒng)和一個外部用戶使用的網(wǎng)站，用戶遍及全球，項(xiàng)目整個已經(jīng)持續(xù)了七年有余，產(chǎn)品環(huán)境具備前面所描述的所有特點(diǎn)，并且產(chǎn)品環(huán)境每日的錯誤日志達(dá)到幾千條。正是由于錯誤日志的數(shù)量到了一個不能忍的程度，產(chǎn)品環(huán)境引起了各方的關(guān)注，也使得產(chǎn)品環(huán)境下的QA迎來了試點(diǎn)的最佳時機(jī)。產(chǎn)品環(huán)境下的QA在我們項(xiàng)目上的實(shí)踐主要是三部分內(nèi)容：日志分析和優(yōu)化、Google Analytics數(shù)據(jù)分析、用戶反饋的收集和分析，下面逐個介紹。
日志分析和優(yōu)化
既然錯誤日志那么多，首當(dāng)其沖就是從這些錯誤日志下手。項(xiàng)目使用的日志分析工具是Splunk，這個工具功能強(qiáng)大、使用方便，關(guān)于工具的詳細(xì)信息可以參考官網(wǎng)。下圖所示為使用Splunk通過指定條件搜索日志文件得到的結(jié)果頁面，結(jié)果集里四條類似亂碼的東西就是代表有四種類型的錯誤日志，每種錯誤出現(xiàn)的數(shù)量和百分比都有統(tǒng)計(jì)，點(diǎn)擊每條結(jié)果可以查看詳細(xì)的錯誤日志信息。
關(guān)于日志的分析和優(yōu)化，我們在項(xiàng)目上做了如下工作：
1. 分析產(chǎn)品環(huán)境的錯誤日志
每天會有專人負(fù)責(zé)錯誤日志的分析，找出其中的優(yōu)先級高的問題給團(tuán)隊(duì)修復(fù)。QA會協(xié)助重現(xiàn)、跟蹤并負(fù)責(zé)測試這些重要的需要修復(fù)的問題，通過對錯誤日志的分析，QA可以大概的統(tǒng)計(jì)出哪些功能特性比較容易產(chǎn)生錯誤，在接下來的類產(chǎn)品環(huán)境的測試中要重點(diǎn)關(guān)注。
另外，對于某些功能由于測試環(huán)境的數(shù)據(jù)等局限性，擔(dān)心部署到產(chǎn)品環(huán)境會產(chǎn)生錯誤或者有性能問題，一般上線后會著重關(guān)注這樣的功能，除了日常的監(jiān)控分析之外，還要單獨(dú)對該功能的日志進(jìn)行檢查，以防產(chǎn)生嚴(yán)重問題。
2. 監(jiān)控測試環(huán)境的錯誤日志
把產(chǎn)品環(huán)境錯誤日志的分析方法應(yīng)用于測試環(huán)境，對測試環(huán)境的錯誤日志進(jìn)行監(jiān)控，盡量把環(huán)境無關(guān)由功能引起的錯誤找出來，盡早修復(fù)，不讓其流落到產(chǎn)品環(huán)境。據(jù)不完全統(tǒng)計(jì)，最近兩三個月通過這種方式發(fā)現(xiàn)并修復(fù)了好幾個潛在的Bug。
3. 利用日志監(jiān)控不同功能的性能
Ops在Splunk里設(shè)置有專門的統(tǒng)計(jì)和監(jiān)控系統(tǒng)性能的Dashboard，QA會定期從里邊拿出潛在的存在性能問題的功能模塊，創(chuàng)建對應(yīng)的任務(wù)卡由開發(fā)團(tuán)隊(duì)來做性能調(diào)優(yōu)。
4. 日志記錄標(biāo)準(zhǔn)化
通過對產(chǎn)品環(huán)境錯誤日志的分析，發(fā)現(xiàn)現(xiàn)有日志記錄存在如下問題：
- 存儲位置不統(tǒng)一，有些日志沒有辦法通過Splunk統(tǒng)計(jì)分析，造成分析成本的增加；
- 記錄格式不一致，有些日志雖然可以通過Splunk看到，但是沒有記錄很有用的信息，比如沒有記錄錯誤發(fā)生時候的一些有意義的message，或者是Post請求沒有記錄輸入?yún)?shù)，導(dǎo)致排查錯誤日志的工作增加了難度；
- 日志級別定義混亂，有些沒有到達(dá)錯誤級別（error）的日志也記成了錯誤（error）日志，這也是錯誤日志數(shù)量大的原因之一。
為了讓日志分析更輕松、讓日志更全面的記錄系統(tǒng)的各種情況，針對上面的問題，團(tuán)隊(duì)討論并達(dá)成共識：
- 將日志輸出到各個服務(wù)器的同一個路徑；
- 統(tǒng)一日志記錄格式，并且盡量記錄更全面的信息幫助后期的日志分析；
- 清晰定義各個日志級別（Debug，Info，Warning，Error，Critical，F(xiàn)atal），將已有的誤記成錯誤的日志降低到正確的級別，對于新功能則嚴(yán)格按照所定義級別記錄日志；
- QA在用戶故事（Story）的開發(fā)機(jī)驗(yàn)收（Dev-box Testing or Desk Check）階段負(fù)責(zé)跟開發(fā)人員確認(rèn)相關(guān)日志記錄是否符合標(biāo)準(zhǔn)，并且通過測試環(huán)境的日志監(jiān)控可以及時驗(yàn)證新功能的日志記錄情況。
Google Analytics數(shù)據(jù)分析
Google Analytics（以下簡稱GA）是項(xiàng)目用來統(tǒng)計(jì)網(wǎng)站使用情況的工具，從GA上可以獲取很多有價值的信息，對這些信息的分析是我們實(shí)踐的產(chǎn)品環(huán)境下QA的另一塊內(nèi)容，具體做了下面幾項(xiàng)工作：
1. 操作系統(tǒng)和瀏覽器使用情況分析
根據(jù)GA數(shù)據(jù)統(tǒng)計(jì)分析出用戶使用的操作系統(tǒng)和瀏覽器分布情況，從而相應(yīng)的調(diào)整QA用來測試的操作系統(tǒng)和瀏覽器，盡量讓測試環(huán)境跟真實(shí)用戶更接近。比如，前兩年客戶內(nèi)部員工使用的瀏覽器最多的是IE9，那么我們QA的測試也是主要關(guān)注IE9，而今年變成了IE11，我們重點(diǎn)關(guān)注的瀏覽器也相應(yīng)調(diào)整為IE11（當(dāng)然，鑒于IE9的特殊性——容易出問題，只要還有用戶使用，我們還是需要關(guān)注），而對于沒有用戶使用的Firefox，我們則不用來測試。
2. 分析QA測試跟用戶真實(shí)行為的差異，及時調(diào)整測試根據(jù)
GA上用戶訪問的路徑可以發(fā)現(xiàn)我們QA的測試跟一些真實(shí)用戶使用習(xí)慣的差異，這樣如果按照我們通常的路徑去測試，可能有些問題難以在測試階段發(fā)現(xiàn)。比如，QA在測試環(huán)境通常打開“工作記錄”的方式是這樣的：
而我們從GA上發(fā)現(xiàn)真實(shí)用戶使用過程中，打開“工作記錄”最多的路徑是這樣的：
發(fā)現(xiàn)了這種差異，QA就要在測試時候做相應(yīng)的調(diào)整，讓測試更接近用戶的行為習(xí)慣。
3. 提煉關(guān)鍵業(yè)務(wù)場景，增加測試覆蓋
一個開發(fā)好幾年的系統(tǒng)，其功能必然是比較復(fù)雜的，由于自動化測試覆蓋率不是很理想，過去回歸測試需要的投入比較大，而且由于功能相對復(fù)雜，又不是很清楚哪些功能對用戶來說最為重要，測試很難做到有效覆蓋。這種情況對于人員比例低下的敏捷團(tuán)隊(duì)QA來說，是一件非常有挑戰(zhàn)的事情，通常QA們在發(fā)布前忙得不行。利用GA的數(shù)據(jù)結(jié)合客戶業(yè)務(wù)人員對系統(tǒng)各功能使用情況的介紹，我們提煉出來系統(tǒng)最為關(guān)鍵的一些業(yè)務(wù)場景，并且盡量分層（參考測試金字塔）實(shí)現(xiàn)自動化測試覆蓋，從而不需要花費(fèi)太多的人力去做回歸測試，同樣可以保證主要的業(yè)務(wù)流程不至于被破壞，而QA則可以有更多的時間和精力去做探索性測試等更有價值的事情。
4. 發(fā)現(xiàn)用戶較少使用的功能，優(yōu)化業(yè)務(wù)流程
關(guān)鍵場景就是用戶使用頻率較高的功能，類似的，我們還可以通過GA發(fā)現(xiàn)一些用戶較少使用的功能，這可能的原因是不符合用戶真實(shí)行為習(xí)慣，喜歡用其他路徑去完成同樣的事情，或者不符合真實(shí)業(yè)務(wù)需求，也就是說真實(shí)的業(yè)務(wù)環(huán)境下根本沒有要用到這個功能的地方。對于這種功能，首先從QA角度來講，我們的測試基本不需要太多去關(guān)注，如果有相關(guān)功能的缺陷，它的優(yōu)先級也很低很低；另外，可以跟業(yè)務(wù)分析人員一起分析下原因，在后續(xù)的功能開發(fā)過程中可以作為借鑒，從而優(yōu)化業(yè)務(wù)流程。
5. 分析用戶地區(qū)分布和使用時間段分布，合理安排定時任務(wù)運(yùn)行時間
系統(tǒng)用戶遍及全球，使用時間段分布也就變得復(fù)雜，為了不影響正常使用，有些事情是需要盡量在系統(tǒng)沒人使用的時候去做的，比如統(tǒng)計(jì)某類數(shù)據(jù)需要定時執(zhí)行SQL腳本等定時任務(wù)。通過GA上的數(shù)據(jù)，統(tǒng)計(jì)出哪個時間段是相對空閑的，在不影響真實(shí)業(yè)務(wù)的前提下，把一些資源消耗較大的任務(wù)安排在那個時候執(zhí)行，合理分配資源以減輕服務(wù)器的負(fù)擔(dān)。
6. 監(jiān)控系統(tǒng)性能變化趨勢，規(guī)避性能風(fēng)險
QA定期查看網(wǎng)站平均訪問時間，監(jiān)控性能趨勢，同時要重點(diǎn)關(guān)注那些訪問非常慢的頁面或功能，必要的時候創(chuàng)建性能缺陷卡，由開發(fā)人員來調(diào)查分析并修復(fù)或優(yōu)化。
7. 確保GA能夠統(tǒng)計(jì)到所有需要統(tǒng)計(jì)的功能
GA數(shù)據(jù)雖然很有用，但前提是正確記錄了所需要統(tǒng)計(jì)的數(shù)據(jù)，所以在開發(fā)過程中要確保GA嵌入到了各個需要統(tǒng)計(jì)的功能或頁面，QA在類產(chǎn)品環(huán)境測試的時候需要驗(yàn)證這一點(diǎn)。
下圖為從GA拿到的瀏覽器分布情況和頁面平均加載時間的一些數(shù)據(jù)：
用戶反饋的收集和分析
作為開發(fā)團(tuán)隊(duì)的我們基本是不能直接接觸到系統(tǒng)終端用戶的，直接接受反饋的是我們客戶的Ops團(tuán)隊(duì)，QA主要通過下面幾個途徑去協(xié)助分析和梳理用戶反饋：
1. 跟Ops和業(yè)務(wù)的定期溝通會議
QA會定期跟客戶的Ops和業(yè)務(wù)人員溝通，了解用戶對于現(xiàn)有系統(tǒng)的反饋，找出在測試中需要重視的功能特性，將類產(chǎn)品環(huán)境的測試關(guān)注點(diǎn)做出相應(yīng)的調(diào)整。
2. 培訓(xùn)Ops人員
指導(dǎo)和協(xié)助客戶Ops人員利用魚骨圖（Fishbone Diagram）的方法對收集到的用戶反饋進(jìn)行分析和分類，將分析結(jié)果跟現(xiàn)有的測試覆蓋情況進(jìn)行對比，找出測試過程的薄弱環(huán)節(jié)，并做出改進(jìn)。比如，如果某個瀏覽器出現(xiàn)的bug比較多，而我們的測試則要加強(qiáng)該瀏覽器的關(guān)注；或者是因?yàn)椴煌脩魴?quán)限導(dǎo)致的問題出現(xiàn)頻率高，那就得在測試中注意覆蓋不同用戶角色的測試，反之則減弱不同用戶的覆蓋，主要測最常用的那類角色即可。
3. 調(diào)查和跟蹤產(chǎn)品環(huán)境Bug
幫助重現(xiàn)和調(diào)查用戶反饋過來的產(chǎn)品環(huán)境Bug，并負(fù)責(zé)跟蹤修復(fù)和驗(yàn)證；對于難以重現(xiàn)的問題，則添加日志監(jiān)控，通過分析收集到的日志信息找出問題根源，從而進(jìn)行修復(fù)。
4. 協(xié)助梳理業(yè)務(wù)需求
系統(tǒng)要增加某個新功能的時候，客戶Product Owner（以下簡稱PO）或其他業(yè)務(wù)人員跟用戶會一起溝通該功能相關(guān)業(yè)務(wù)現(xiàn)有的使用習(xí)慣、使用場景，QA也會盡力參與這種會議，收集用戶第一手需求信息，這些信息對于后期該業(yè)務(wù)功能開發(fā)時候的QA過程將非常有幫助。而還有些功能，PO可能一時也拿不定主意要做成什么樣子，我們會發(fā)布MVP的版本給用戶使用，QA協(xié)助業(yè)務(wù)人員分析用戶使用后的反饋，梳理更具體的用戶需求。
產(chǎn)品環(huán)境下的QA有什么特點(diǎn)
1. 不同于類產(chǎn)品環(huán)境的QA
產(chǎn)品環(huán)境的特點(diǎn)決定了產(chǎn)品環(huán)境下的QA是跟類產(chǎn)品環(huán)境的QA不同的，不是主動的去測試產(chǎn)品環(huán)境的系統(tǒng)，而是通過設(shè)置監(jiān)控條件，收集用戶使用系統(tǒng)的反饋，對反饋進(jìn)行分析并改進(jìn)，從而讓產(chǎn)品質(zhì)量獲得提高。因此，產(chǎn)品環(huán)境下的QA并不是類產(chǎn)品環(huán)境QA活動的簡單后延，它有著自己獨(dú)特的特點(diǎn)。
2. 不能獨(dú)立存在
產(chǎn)品環(huán)境下的QA所設(shè)置的監(jiān)控標(biāo)準(zhǔn)是根據(jù)系統(tǒng)的行為特點(diǎn)和在類產(chǎn)品環(huán)境下的表現(xiàn)來定義的，產(chǎn)品環(huán)境下各項(xiàng)反饋的分析結(jié)果反過來又影響著類產(chǎn)品環(huán)境的QA過程，而且這兩者是相輔相成的，只有形成了良性環(huán)路，才能把產(chǎn)品環(huán)境下的QA做好。
3. 有別于Ops
產(chǎn)品環(huán)境設(shè)置監(jiān)控預(yù)警和收集用戶反饋不都是Ops團(tuán)隊(duì)可以做的事情嗎？還要QA參與干什么？那是因?yàn)镼A有著獨(dú)特的思維模式和視角，QA的參與能夠幫助更好的分析產(chǎn)品環(huán)境下收集到的各種反饋，并且結(jié)合對于系統(tǒng)的了解，能夠?qū)⑦@些反饋更好的應(yīng)用到日常的開發(fā)工作中。
這時候的QA帶著QA和Ops的帽子，兼具QA和Ops的部分職責(zé)，類似于QAOps，不過現(xiàn)在都提倡不要有獨(dú)立的DevOps，我們也不要獨(dú)立的QAOps角色，只是讓QA這個角色可做的事情得到了延伸和擴(kuò)展而已，本質(zhì)上還是QA。
4. 跟APM的側(cè)重點(diǎn)不同
可能有人會覺得產(chǎn)品環(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)管理領(lǐng)域，APM是對軟件應(yīng)用程序的性能和可用性的監(jiān)控和管理。）”
APM更多的是從性能角度出發(fā)去管理和優(yōu)化應(yīng)用的可用性，可以發(fā)生在各個階段，不一定是產(chǎn)品環(huán)境。產(chǎn)品環(huán)境下的QA是指在產(chǎn)品環(huán)境進(jìn)行一系列的監(jiān)控和數(shù)據(jù)收集，從系統(tǒng)功能、性能、易用性等多個方面進(jìn)行優(yōu)化，從而最終優(yōu)化業(yè)務(wù)價值。因此，兩者是不同的。
總結(jié)
- 產(chǎn)品環(huán)境下的QA將QA的工作范圍擴(kuò)大到從需求到產(chǎn)品環(huán)境，增加了更多的反饋來源，跟持續(xù)交付結(jié)合，可以幫助持續(xù)提高產(chǎn)品質(zhì)量、持續(xù)優(yōu)化業(yè)務(wù)價值。
- 產(chǎn)品環(huán)境下的QA給QA的工具箱添加了更多的工具，提供了更多評估和提高系統(tǒng)質(zhì)量的選項(xiàng)，是QA們值得深入研究的話題。
- 產(chǎn)品環(huán)境下的QA不能走的太遠(yuǎn)，必須先做好類產(chǎn)品環(huán)境的質(zhì)量保證，并且僅適用于持續(xù)交付實(shí)踐的比較好的組織，如果連類產(chǎn)品環(huán)境的質(zhì)量保證都做不好，而就想著去做產(chǎn)品環(huán)境下的QA，那只能是舍本逐末、事倍功半。
