2015年11月ThoughtWorks發(fā)布的技術(shù)雷達提到一個新的主題——產(chǎn)品環(huán)境下的QA（QA in Production）味抖，2016年4月再次提到旁壮。這個主題第一次出現(xiàn)在技術(shù)雷達童漩，就深深的吸引了我啊胶，當(dāng)時我就給測試團隊成員轉(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)境有運維支持團隊（Ops）超陆，產(chǎn)品環(huán)境下的QA跟Ops所做的事情又有什么區(qū)別與聯(lián)系？
帶著這些疑問浦马，結(jié)合項目上的一系列實踐时呀，于是有了本文。
一個產(chǎn)品環(huán)境Bug的解決辦法
先來跟大家分享一個產(chǎn)品環(huán)境下的Bug：
一個在線訂購葡萄酒的系統(tǒng)晶默，訂購流程相對復(fù)雜谨娜，下單過程中后臺會有隨機的失敗，系統(tǒng)采取的措施是重試磺陡，就是說顧客下單后趴梢，后臺如果有錯誤就會不停的重試，直到成功币他，這個過程對顧客是不可見的坞靶。這聽起來沒什么問題，用戶體驗似乎也不錯蝴悉。
后來有個新版本上線了彰阴，顧客下單后還是會有隨機失敗也糊，系統(tǒng)依然不停的重試肄满，但這次不一樣的是有的隨機失敗，下單卻能夠成功缠黍，這樣就導(dǎo)致用戶雖然只訂購一箱葡萄酒倦微，由于后臺的多次重試都成功了妻味，用戶最終拿到的可能是好幾百箱葡萄酒。
這是一個非常嚴重且昂貴的Bug欣福！對于這樣的問題责球，作為QA，你能想到的解決辦法有哪些？
瀑布式QA流程
瀑布式軟件開發(fā)模式下雏逾，測試是計劃驅(qū)動的嘉裤，基本是根據(jù)需求文檔進行驗證，測試的目的就是找到盡可能多的bug栖博，而且測試階段處于開發(fā)階段結(jié)束之后的一個相對獨立的階段屑宠，測試結(jié)束之后發(fā)布產(chǎn)品到產(chǎn)品環(huán)境〕鹑茫基本流程如下：
對于上述葡萄酒訂購系統(tǒng)的Bug典奉，通常的辦法就是加強在測試階段的測試保證，除了驗證系統(tǒng)功能跟需求文檔的一致性以外丧叽，還可以增加一些ad hoc測試卫玖，確保發(fā)布到產(chǎn)品環(huán)境的系統(tǒng)盡量的穩(wěn)定。
敏捷QA流程
敏捷測試則提倡盡早測試踊淳、頻繁測試假瞬，QA要從需求分析階段就開始介入，QA參與從需求到發(fā)布的整個生命周期中各個階段迂尝。在整個QA的過程中脱茉，會依據(jù)敏捷測試象限，在不同階段采取不同的測試垄开；還會根據(jù)測試金字塔的分層指導(dǎo)琴许，加強自動化測試，制定有利于項目質(zhì)量保證的測試策略说榆，同時也會做探索性測試虚吟，盡量去發(fā)現(xiàn)更多不易發(fā)現(xiàn)的缺陷。敏捷QA的流程如下：
對于葡萄酒訂購系統(tǒng)的bug签财，處理方式也無非就是加強上線前各個階段的測試串慰，提高發(fā)布到產(chǎn)品環(huán)境的產(chǎn)品質(zhì)量。
除此之外唱蒸，我們還有什么處理辦法呢邦鲫？
上面兩種開發(fā)模式下，QA的重點都是放在發(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ù)量異常的情況進行監(jiān)控抵碟，將能及時發(fā)現(xiàn)bug，并且比較容易在損失發(fā)生之前及時阻止產(chǎn)生更嚴重的后果坏匪。這就是產(chǎn)品環(huán)境下的QA內(nèi)容之一拟逮！
產(chǎn)品環(huán)境的特點
為了更好的實踐產(chǎn)品環(huán)境下的QA，先來分析下產(chǎn)品環(huán)境有哪些特點：
1. 真實适滓、不可破壞
產(chǎn)品環(huán)境都是真實用戶在使用敦迄，是真正的支持企業(yè)業(yè)務(wù)運轉(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)境由于是真實業(yè)務(wù)線上的系統(tǒng)哥蔚，對安全性和穩(wěn)定性要求更高，服務(wù)器的通常不是所有QA可以隨便訪問的蛛蒙，這種訪問受限的情況對于產(chǎn)品環(huán)境的一些缺陷的排查帶來了很大的不便糙箍。
7. 真實的用戶反饋
真實用戶在產(chǎn)品環(huán)境使用，能夠提出一些真實而重要的反饋牵祟，但是開發(fā)團隊往往不能直接接觸終端用戶深夯，QA也就沒有辦法獲得第一手的用戶反饋，這些反饋常常需要通過支持團隊的轉(zhuǎn)述诺苹。
產(chǎn)品環(huán)境的這些特點決定了QA在產(chǎn)品環(huán)境不是想做什么就能做什么的咕晋，原來類產(chǎn)品環(huán)境那套質(zhì)量保證理論和方法都行不通了。
產(chǎn)品環(huán)境下的QA有這么多挑戰(zhàn)收奔，聽起來是不是很沮喪掌呜？不要著急，針對產(chǎn)品環(huán)境獨有的特點坪哄，一定能找到相應(yīng)的解決方案质蕉。接下來呢撞，咱們一起來看看產(chǎn)品環(huán)境下（不僅是QA）可以做什么。
產(chǎn)品環(huán)境下可以做什么
一饰剥、監(jiān)控預(yù)警
前面講到不能隨便去操作產(chǎn)品環(huán)境下的系統(tǒng)對其進行測試殊霞，但是可以通過監(jiān)控的方式去獲得我們需要的信息，對異常情況進行預(yù)警汰蓉。提到監(jiān)控預(yù)警绷蹲，不得不提大家都了解或者至少聽說過的日志和網(wǎng)站分析工具，這兩者都是做好產(chǎn)品環(huán)境下的QA非常有幫助的工具顾孽。
日志
日志就像是飛機上的黑匣子祝钢，可以記錄系統(tǒng)運行的各種信息，包括錯誤若厚、異常和失敗等拦英。一旦程序出現(xiàn)問題，記錄的這些信息就可以用來分析問題的原因测秸；同時可以利用記錄的日志設(shè)置好預(yù)警疤估，提前預(yù)測系統(tǒng)可能出現(xiàn)的問題。產(chǎn)品環(huán)境下日志所提供的監(jiān)控和預(yù)警信息霎冯，將有利于：
- 阻止不良后果铃拇，避免大的損失：前面提到的葡萄酒訂購系統(tǒng)就是一個很好的例子；
- 發(fā)現(xiàn)潛在的性能問題：通過對日志進行分析沈撞，可能發(fā)現(xiàn)還沒暴露出來的性能問題慷荔，提前修復(fù)；
- 指導(dǎo)類產(chǎn)品環(huán)境的測試：通過產(chǎn)品環(huán)境下日志的分析缠俺，可以看出哪些功能易出什么樣的錯誤显晶，從而相應(yīng)調(diào)整測試策略，加強類產(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è)重點，指導(dǎo)類產(chǎn)品環(huán)境的測試凡泣；根據(jù)用戶行為習(xí)慣等信息枉疼，還可以幫助優(yōu)化產(chǎn)品業(yè)務(wù)價值皮假。
二、用戶反饋
介紹產(chǎn)品環(huán)境特點的時候提到一點就是產(chǎn)品環(huán)境能夠收到真實的用戶反饋骂维，這是非常有價值的惹资，要做好產(chǎn)品環(huán)境下的QA一定要利用這些反饋。由于用戶行為和習(xí)慣的千奇百怪航闺，用戶提供的反饋也可能是各種各樣的褪测，為了更好的利用它們，需要一個嚴格的Triage的過程潦刃，對所有反饋進行分類并相應(yīng)處理侮措。用戶反饋，可以總結(jié)為下面幾類：
缺陷
用戶在使用過程中乖杠，系統(tǒng)所出現(xiàn)的問題分扎，并且能夠穩(wěn)定重現(xiàn)的，我們定義為缺陷胧洒，缺陷通常會影響到功能的使用畏吓，是需要修復(fù)的，根據(jù)優(yōu)先級和嚴重程度略荡，安排相應(yīng)的修復(fù)計劃并對其進行修復(fù)庵佣，同時還需要對修復(fù)的缺陷增加（自動化）測試，以防被再次破壞汛兜。
除了能夠穩(wěn)定重現(xiàn)的缺陷，有時候還會有一些隨機的失斖ń瘛（比如前面提到的葡萄酒訂購系統(tǒng)的bug）或者難以重現(xiàn)的問題粥谬，這類問題很難找到原因，但是又給用戶帶來很大的不爽辫塌。其實漏策，它們通常也是一些缺陷引起的，只是根源可能隱藏的比較深臼氨，對于這種問題的處理辦法就是前面部分提到的可以添加日志對相關(guān)功能進行監(jiān)控和預(yù)警掺喻，利用日志協(xié)助找到問題根源并進行修復(fù)。
抱怨
用戶在使用系統(tǒng)過程中由于行為習(xí)慣储矩、網(wǎng)絡(luò)環(huán)境等差異感耙，總會有各種抱怨，一般以非功能性的問題居多持隧，比如易用性即硼、性能、可維護性屡拨、可擴展性等只酥，當(dāng)然也有可能是某個功能設(shè)計的不能滿足真實的用戶需求褥实。需要對所有抱怨進行分類嫂便，確定是非功能的缺陷伪煤，還是新的需求。用戶的抱怨有可能千奇百怪禁谦，不是所有的都能滿足绝编，需要根據(jù)分類定義優(yōu)先級草冈，確定哪些是需要改進和修復(fù)，從而采取相應(yīng)的措施瓮增。
建議
除了反饋問題和提出抱怨怎棱，用戶也會對系統(tǒng)使用方面提一些建議。但一般用戶很難提出好的建議绷跑，要想收集到有價值的信息拳恋，需要提前設(shè)計好問卷進行問卷調(diào)查，有針對性的去收集砸捏；或者對一些重要用戶進行訪談谬运，或者發(fā)布一個簡單的新功能收集用戶的使用建議等。然后對收集到的建議進行分析垦藏，確定可行性梆暖，并將可行的建議應(yīng)用到后續(xù)的系統(tǒng)和業(yè)務(wù)流程的改進中。
利用用戶反饋掂骏，改進系統(tǒng)功能轰驳，可以優(yōu)化業(yè)務(wù)價值，擴大產(chǎn)品的市場影響力弟灼，提高企業(yè)的競爭力级解。常被用來收集用戶反饋的實踐有：
- Beta測試：很多有前瞻性的網(wǎng)站或應(yīng)用會發(fā)布新功能給特定用戶組（Beta用戶），收集用戶使用新功能的統(tǒng)計數(shù)據(jù)田绑；
- AB測試：同時發(fā)布兩個不同版本的系統(tǒng)到產(chǎn)品環(huán)境勤哗，并將用戶引導(dǎo)到兩個版本，統(tǒng)計使用每個版本的用戶數(shù)據(jù)掩驱；
- Observed Requirement：發(fā)布一個簡單的功能芒划，或者發(fā)布一個MVP版本，觀察用戶使用情況欧穴，從而引出并收集到用戶的真實需求民逼。
監(jiān)控預(yù)警、收集和分析用戶反饋并不是QA能獨立完成的苔可，需要與不同角色協(xié)作缴挖，QA在整個過程中主要充當(dāng)分析者和協(xié)調(diào)者的角色，對產(chǎn)品環(huán)境下的質(zhì)量保證工作起到至關(guān)重要的作用：
- 跟DEV一起討論監(jiān)控標準焚辅，把日志標準化的要求融入到軟件開發(fā)流程中映屋，確保日志能夠記錄到真正需要記錄的信息苟鸯。
- 跟運維團隊一起分析收集到的統(tǒng)計數(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在項目上的實踐
我所在的項目是一個離岸交付項目，采用的是敏捷開發(fā)模式贬循，四周一次發(fā)布到產(chǎn)品環(huán)境咸包，開發(fā)的系統(tǒng)包括一個內(nèi)部員工使用系統(tǒng)和一個外部用戶使用的網(wǎng)站，用戶遍及全球杖虾，項目整個已經(jīng)持續(xù)了七年有余烂瘫，產(chǎn)品環(huán)境具備前面所描述的所有特點，并且產(chǎn)品環(huán)境每日的錯誤日志達到幾千條奇适。正是由于錯誤日志的數(shù)量到了一個不能忍的程度坟比，產(chǎn)品環(huán)境引起了各方的關(guān)注，也使得產(chǎn)品環(huán)境下的QA迎來了試點的最佳時機嚷往。產(chǎn)品環(huán)境下的QA在我們項目上的實踐主要是三部分內(nèi)容：日志分析和優(yōu)化葛账、Google Analytics數(shù)據(jù)分析、用戶反饋的收集和分析皮仁，下面逐個介紹籍琳。
日志分析和優(yōu)化
既然錯誤日志那么多，首當(dāng)其沖就是從這些錯誤日志下手魂贬。項目使用的日志分析工具是Splunk巩割，這個工具功能強大、使用方便付燥，關(guān)于工具的詳細信息可以參考官網(wǎng)。下圖所示為使用Splunk通過指定條件搜索日志文件得到的結(jié)果頁面愈犹，結(jié)果集里四條類似亂碼的東西就是代表有四種類型的錯誤日志键科，每種錯誤出現(xiàn)的數(shù)量和百分比都有統(tǒng)計，點擊每條結(jié)果可以查看詳細的錯誤日志信息漩怎。
關(guān)于日志的分析和優(yōu)化勋颖，我們在項目上做了如下工作：
1. 分析產(chǎn)品環(huán)境的錯誤日志
每天會有專人負責(zé)錯誤日志的分析，找出其中的優(yōu)先級高的問題給團隊修復(fù)勋锤。QA會協(xié)助重現(xiàn)饭玲、跟蹤并負責(zé)測試這些重要的需要修復(fù)的問題，通過對錯誤日志的分析叁执，QA可以大概的統(tǒng)計出哪些功能特性比較容易產(chǎn)生錯誤茄厘，在接下來的類產(chǎn)品環(huán)境的測試中要重點關(guān)注矮冬。
另外，對于某些功能由于測試環(huán)境的數(shù)據(jù)等局限性次哈，擔(dān)心部署到產(chǎn)品環(huán)境會產(chǎn)生錯誤或者有性能問題胎署，一般上線后會著重關(guān)注這樣的功能，除了日常的監(jiān)控分析之外窑滞，還要單獨對該功能的日志進行檢查琼牧，以防產(chǎn)生嚴重問題。
2. 監(jiān)控測試環(huán)境的錯誤日志
把產(chǎn)品環(huán)境錯誤日志的分析方法應(yīng)用于測試環(huán)境哀卫，對測試環(huán)境的錯誤日志進行監(jiān)控巨坊，盡量把環(huán)境無關(guān)由功能引起的錯誤找出來，盡早修復(fù)此改，不讓其流落到產(chǎn)品環(huán)境趾撵。據(jù)不完全統(tǒng)計，最近兩三個月通過這種方式發(fā)現(xiàn)并修復(fù)了好幾個潛在的Bug带斑。
3. 利用日志監(jiān)控不同功能的性能
Ops在Splunk里設(shè)置有專門的統(tǒng)計和監(jiān)控系統(tǒng)性能的Dashboard鼓寺，QA會定期從里邊拿出潛在的存在性能問題的功能模塊，創(chuàng)建對應(yīng)的任務(wù)卡由開發(fā)團隊來做性能調(diào)優(yōu)勋磕。
4. 日志記錄標準化
通過對產(chǎn)品環(huán)境錯誤日志的分析妈候，發(fā)現(xiàn)現(xiàn)有日志記錄存在如下問題：
- 存儲位置不統(tǒng)一，有些日志沒有辦法通過Splunk統(tǒng)計分析挂滓，造成分析成本的增加苦银；
- 記錄格式不一致，有些日志雖然可以通過Splunk看到赶站，但是沒有記錄很有用的信息幔虏，比如沒有記錄錯誤發(fā)生時候的一些有意義的message，或者是Post請求沒有記錄輸入?yún)?shù)贝椿，導(dǎo)致排查錯誤日志的工作增加了難度想括；
- 日志級別定義混亂，有些沒有到達錯誤級別（error）的日志也記成了錯誤（error）日志烙博，這也是錯誤日志數(shù)量大的原因之一瑟蜈。
為了讓日志分析更輕松、讓日志更全面的記錄系統(tǒng)的各種情況渣窜，針對上面的問題铺根，團隊討論并達成共識：
- 將日志輸出到各個服務(wù)器的同一個路徑；
- 統(tǒng)一日志記錄格式乔宿，并且盡量記錄更全面的信息幫助后期的日志分析位迂；
- 清晰定義各個日志級別（Debug，Info，Warning掂林，Error臣缀，Critical，F(xiàn)atal）党饮，將已有的誤記成錯誤的日志降低到正確的級別肝陪，對于新功能則嚴格按照所定義級別記錄日志；
- QA在用戶故事（Story）的開發(fā)機驗收（Dev-box Testing or Desk Check）階段負責(zé)跟開發(fā)人員確認相關(guān)日志記錄是否符合標準刑顺，并且通過測試環(huán)境的日志監(jiān)控可以及時驗證新功能的日志記錄情況氯窍。
Google Analytics數(shù)據(jù)分析
Google Analytics（以下簡稱GA）是項目用來統(tǒng)計網(wǎng)站使用情況的工具，從GA上可以獲取很多有價值的信息蹲堂，對這些信息的分析是我們實踐的產(chǎn)品環(huán)境下QA的另一塊內(nèi)容狼讨，具體做了下面幾項工作：
1. 操作系統(tǒng)和瀏覽器使用情況分析
根據(jù)GA數(shù)據(jù)統(tǒng)計分析出用戶使用的操作系統(tǒng)和瀏覽器分布情況，從而相應(yīng)的調(diào)整QA用來測試的操作系統(tǒng)和瀏覽器柒竞，盡量讓測試環(huán)境跟真實用戶更接近政供。比如，前兩年客戶內(nèi)部員工使用的瀏覽器最多的是IE9朽基，那么我們QA的測試也是主要關(guān)注IE9布隔，而今年變成了IE11，我們重點關(guān)注的瀏覽器也相應(yīng)調(diào)整為IE11（當(dāng)然稼虎，鑒于IE9的特殊性——容易出問題衅檀，只要還有用戶使用，我們還是需要關(guān)注）霎俩，而對于沒有用戶使用的Firefox哀军，我們則不用來測試。
2. 分析QA測試跟用戶真實行為的差異打却，及時調(diào)整測試根據(jù)
GA上用戶訪問的路徑可以發(fā)現(xiàn)我們QA的測試跟一些真實用戶使用習(xí)慣的差異杉适，這樣如果按照我們通常的路徑去測試，可能有些問題難以在測試階段發(fā)現(xiàn)柳击。比如猿推，QA在測試環(huán)境通常打開“工作記錄”的方式是這樣的：
而我們從GA上發(fā)現(xiàn)真實用戶使用過程中，打開“工作記錄”最多的路徑是這樣的：
發(fā)現(xiàn)了這種差異捌肴，QA就要在測試時候做相應(yīng)的調(diào)整彤守，讓測試更接近用戶的行為習(xí)慣。
3. 提煉關(guān)鍵業(yè)務(wù)場景哭靖，增加測試覆蓋
一個開發(fā)好幾年的系統(tǒng)，其功能必然是比較復(fù)雜的侈离，由于自動化測試覆蓋率不是很理想试幽，過去回歸測試需要的投入比較大，而且由于功能相對復(fù)雜，又不是很清楚哪些功能對用戶來說最為重要铺坞，測試很難做到有效覆蓋起宽。這種情況對于人員比例低下的敏捷團隊QA來說，是一件非常有挑戰(zhàn)的事情济榨，通常QA們在發(fā)布前忙得不行坯沪。利用GA的數(shù)據(jù)結(jié)合客戶業(yè)務(wù)人員對系統(tǒng)各功能使用情況的介紹，我們提煉出來系統(tǒng)最為關(guān)鍵的一些業(yè)務(wù)場景擒滑，并且盡量分層（參考測試金字塔）實現(xiàn)自動化測試覆蓋腐晾，從而不需要花費太多的人力去做回歸測試，同樣可以保證主要的業(yè)務(wù)流程不至于被破壞丐一，而QA則可以有更多的時間和精力去做探索性測試等更有價值的事情藻糖。
4. 發(fā)現(xiàn)用戶較少使用的功能，優(yōu)化業(yè)務(wù)流程
關(guān)鍵場景就是用戶使用頻率較高的功能库车，類似的巨柒，我們還可以通過GA發(fā)現(xiàn)一些用戶較少使用的功能，這可能的原因是不符合用戶真實行為習(xí)慣柠衍，喜歡用其他路徑去完成同樣的事情洋满，或者不符合真實業(yè)務(wù)需求，也就是說真實的業(yè)務(wù)環(huán)境下根本沒有要用到這個功能的地方珍坊。對于這種功能牺勾，首先從QA角度來講，我們的測試基本不需要太多去關(guān)注垫蛆，如果有相關(guān)功能的缺陷禽最，它的優(yōu)先級也很低很低；另外，可以跟業(yè)務(wù)分析人員一起分析下原因，在后續(xù)的功能開發(fā)過程中可以作為借鑒侠姑，從而優(yōu)化業(yè)務(wù)流程唉窃。
5. 分析用戶地區(qū)分布和使用時間段分布，合理安排定時任務(wù)運行時間
系統(tǒng)用戶遍及全球击你，使用時間段分布也就變得復(fù)雜，為了不影響正常使用，有些事情是需要盡量在系統(tǒng)沒人使用的時候去做的仅叫，比如統(tǒng)計某類數(shù)據(jù)需要定時執(zhí)行SQL腳本等定時任務(wù)。通過GA上的數(shù)據(jù)糙捺，統(tǒng)計出哪個時間段是相對空閑的诫咱，在不影響真實業(yè)務(wù)的前提下，把一些資源消耗較大的任務(wù)安排在那個時候執(zhí)行洪灯，合理分配資源以減輕服務(wù)器的負擔(dān)坎缭。
6. 監(jiān)控系統(tǒng)性能變化趨勢，規(guī)避性能風(fēng)險
QA定期查看網(wǎng)站平均訪問時間，監(jiān)控性能趨勢掏呼，同時要重點關(guān)注那些訪問非常慢的頁面或功能坏快，必要的時候創(chuàng)建性能缺陷卡，由開發(fā)人員來調(diào)查分析并修復(fù)或優(yōu)化憎夷。
7. 確保GA能夠統(tǒng)計到所有需要統(tǒng)計的功能
GA數(shù)據(jù)雖然很有用莽鸿，但前提是正確記錄了所需要統(tǒng)計的數(shù)據(jù)，所以在開發(fā)過程中要確保GA嵌入到了各個需要統(tǒng)計的功能或頁面拾给，QA在類產(chǎn)品環(huán)境測試的時候需要驗證這一點祥得。
下圖為從GA拿到的瀏覽器分布情況和頁面平均加載時間的一些數(shù)據(jù)：
用戶反饋的收集和分析
作為開發(fā)團隊的我們基本是不能直接接觸到系統(tǒng)終端用戶的，直接接受反饋的是我們客戶的Ops團隊鸣戴，QA主要通過下面幾個途徑去協(xié)助分析和梳理用戶反饋：
1. 跟Ops和業(yè)務(wù)的定期溝通會議
QA會定期跟客戶的Ops和業(yè)務(wù)人員溝通啃沪，了解用戶對于現(xiàn)有系統(tǒng)的反饋，找出在測試中需要重視的功能特性窄锅，將類產(chǎn)品環(huán)境的測試關(guān)注點做出相應(yīng)的調(diào)整创千。
2. 培訓(xùn)Ops人員
指導(dǎo)和協(xié)助客戶Ops人員利用魚骨圖（Fishbone Diagram）的方法對收集到的用戶反饋進行分析和分類，將分析結(jié)果跟現(xiàn)有的測試覆蓋情況進行對比入偷，找出測試過程的薄弱環(huán)節(jié)追驴，并做出改進。比如疏之，如果某個瀏覽器出現(xiàn)的bug比較多殿雪，而我們的測試則要加強該瀏覽器的關(guān)注；或者是因為不同用戶權(quán)限導(dǎo)致的問題出現(xiàn)頻率高锋爪，那就得在測試中注意覆蓋不同用戶角色的測試丙曙，反之則減弱不同用戶的覆蓋，主要測最常用的那類角色即可其骄。
3. 調(diào)查和跟蹤產(chǎn)品環(huán)境Bug
幫助重現(xiàn)和調(diào)查用戶反饋過來的產(chǎn)品環(huán)境Bug亏镰，并負責(zé)跟蹤修復(fù)和驗證；對于難以重現(xiàn)的問題拯爽，則添加日志監(jiā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有什么特點
1. 不同于類產(chǎn)品環(huán)境的QA
產(chǎn)品環(huán)境的特點決定了產(chǎn)品環(huán)境下的QA是跟類產(chǎn)品環(huán)境的QA不同的另患，不是主動的去測試產(chǎn)品環(huán)境的系統(tǒng)纽乱，而是通過設(shè)置監(jiān)控條件，收集用戶使用系統(tǒng)的反饋昆箕，對反饋進行分析并改進鸦列，從而讓產(chǎn)品質(zhì)量獲得提高。因此鹏倘，產(chǎn)品環(huán)境下的QA并不是類產(chǎn)品環(huán)境QA活動的簡單后延薯嗤，它有著自己獨特的特點。
2. 不能獨立存在
產(chǎn)品環(huán)境下的QA所設(shè)置的監(jiān)控標準是根據(jù)系統(tǒng)的行為特點和在類產(chǎn)品環(huán)境下的表現(xiàn)來定義的纤泵，產(chǎn)品環(huán)境下各項反饋的分析結(jié)果反過來又影響著類產(chǎn)品環(huán)境的QA過程骆姐，而且這兩者是相輔相成的，只有形成了良性環(huán)路捏题，才能把產(chǎn)品環(huán)境下的QA做好玻褪。
3. 有別于Ops
產(chǎn)品環(huán)境設(shè)置監(jiān)控預(yù)警和收集用戶反饋不都是Ops團隊可以做的事情嗎？還要QA參與干什么公荧？那是因為QA有著獨特的思維模式和視角带射，QA的參與能夠幫助更好的分析產(chǎn)品環(huán)境下收集到的各種反饋，并且結(jié)合對于系統(tǒng)的了解循狰，能夠?qū)⑦@些反饋更好的應(yīng)用到日常的開發(fā)工作中窟社。
這時候的QA帶著QA和Ops的帽子，兼具QA和Ops的部分職責(zé)绪钥，類似于QAOps灿里，不過現(xiàn)在都提倡不要有獨立的DevOps，我們也不要獨立的QAOps角色昧识，只是讓QA這個角色可做的事情得到了延伸和擴展而已钠四，本質(zhì)上還是QA。
4. 跟APM的側(cè)重點不同
可能有人會覺得產(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)境進行一系列的監(jiān)控和數(shù)據(jù)收集咏雌，從系統(tǒng)功能凡怎、性能、易用性等多個方面進行優(yōu)化赊抖，從而最終優(yōu)化業(yè)務(wù)價值统倒。因此，兩者是不同的氛雪。
總結(jié)
- 產(chǎn)品環(huán)境下的QA將QA的工作范圍擴大到從需求到產(chǎn)品環(huán)境房匆，增加了更多的反饋來源，跟持續(xù)交付結(jié)合报亩，可以幫助持續(xù)提高產(chǎn)品質(zhì)量浴鸿、持續(xù)優(yōu)化業(yè)務(wù)價值。
- 產(chǎn)品環(huán)境下的QA給QA的工具箱添加了更多的工具弦追，提供了更多評估和提高系統(tǒng)質(zhì)量的選項岳链，是QA們值得深入研究的話題。
- 產(chǎn)品環(huán)境下的QA不能走的太遠劲件，必須先做好類產(chǎn)品環(huán)境的質(zhì)量保證掸哑，并且僅適用于持續(xù)交付實踐的比較好的組織，如果連類產(chǎn)品環(huán)境的質(zhì)量保證都做不好寇仓，而就想著去做產(chǎn)品環(huán)境下的QA举户，那只能是舍本逐末、事倍功半遍烦。
