一、一個(gè)生產(chǎn)環(huán)境 Bug 的解決辦法

先來跟大家分享一個(gè)生產(chǎn)環(huán)境下的 Bug：

一個(gè)在線訂購葡萄酒的系統(tǒng)，訂購流程相對(duì)復(fù)雜，下單過程中后臺(tái)會(huì)有隨機(jī)的失敗，系統(tǒng)采取的措施是重試，就是說顧客下單后，后臺(tái)如果有錯(cuò)誤就會(huì)不停的重試，直到成功，這個(gè)過程對(duì)顧客是不可見的。這聽起來沒什么問題，用戶體驗(yàn)似乎也不錯(cuò)。

后來有個(gè)新版本上線了，顧客下單后還是會(huì)有隨機(jī)失敗，系統(tǒng)依然不停的重試，但這次不一樣的是有的隨機(jī)失敗，下單卻能夠成功，這樣就導(dǎo)致用戶雖然只訂購一箱葡萄酒，由于后臺(tái)的多次重試都成功了，用戶最終拿到的可能是好幾百箱葡萄酒。

這是一個(gè)非常嚴(yán)重且昂貴的 Bug！對(duì)于這樣的問題，作為 QA，你能想到的解決辦法有哪些？

1. 瀑布式 QA 流程

瀑布式軟件開發(fā)模式下，測(cè)試是計(jì)劃驅(qū)動(dòng)的，基本是根據(jù)需求文檔進(jìn)行驗(yàn)證，測(cè)試的目的就是找到盡可能多的 bug，而且測(cè)試階段處于開發(fā)階段結(jié)束之后的一個(gè)相對(duì)獨(dú)立的階段，測(cè)試結(jié)束之后發(fā)布產(chǎn)品到生產(chǎn)環(huán)境?；玖鞒倘缦拢?img src="https://imgs.yssmx.com/Uploads/2023/08/653705-1.png" alt="測(cè)試右移，也就是生產(chǎn)環(huán)境下的QA,數(shù)據(jù)庫,sql,python,jmeter,程序人生,軟件測(cè)試" referrerpolicy="no-referrer" />

如果你想學(xué)習(xí)自動(dòng)化測(cè)試，我這邊給你推薦一套視頻，這個(gè)視頻可以說是B站播放全網(wǎng)第一的接口自動(dòng)化測(cè)試教程，同時(shí)在線人數(shù)到達(dá)1000人，并且還有筆記可以領(lǐng)取及各路大神技術(shù)交流：798478386???

【已更新】B站講的最詳細(xì)的Python接口自動(dòng)化測(cè)試實(shí)戰(zhàn)教程全集（實(shí)戰(zhàn)最新版）_嗶哩嗶哩_bilibili【已更新】B站講的最詳細(xì)的Python接口自動(dòng)化測(cè)試實(shí)戰(zhàn)教程全集（實(shí)戰(zhàn)最新版）共計(jì)200條視頻，包括：1、接口自動(dòng)化之為什么要做接口自動(dòng)化、2、接口自動(dòng)化之request全局觀、3、接口自動(dòng)化之接口實(shí)戰(zhàn)等，UP主更多精彩視頻，請(qǐng)關(guān)注UP賬號(hào)。https://www.bilibili.com/video/BV17p4y1B77x/?spm_id_from=333.337&vd_source=488d25e59e6c5b111f7a1a1a16ecbe9a對(duì)于上述葡萄酒訂購系統(tǒng)的 Bug，通常的辦法就是加強(qiáng)在測(cè)試階段的測(cè)試保證，除了驗(yàn)證系統(tǒng)功能跟需求文檔的一致性以外，還可以增加一些 ad hoc 測(cè)試 ( https://en.wikipedia.org/wiki/Ad_hoc_testing )，確保發(fā)布到生產(chǎn)環(huán)境的系統(tǒng)盡量的穩(wěn)定。

2. 敏捷 QA 流程

敏捷測(cè)試則提倡盡早測(cè)試、頻繁測(cè)試，QA 要從需求分析階段就開始介入，QA 參與從需求到發(fā)布的整個(gè)生命周期中各個(gè)階段。在整個(gè) QA 的過程中，會(huì)依據(jù)敏捷測(cè)試象限 ( http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/ )，在不同階段采取不同的測(cè)試；還會(huì)根據(jù)測(cè)試金字塔 ( http://martinfowler.com/bliki/TestPyramid.html )的分層指導(dǎo)，加強(qiáng)自動(dòng)化測(cè)試，制定有利于項(xiàng)目質(zhì)量保證的測(cè)試策略，同時(shí)也會(huì)做探索式測(cè)試 ( http://www.satisfice.com/articles/what_is_et.shtml )，盡量去發(fā)現(xiàn)更多不易發(fā)現(xiàn)的缺陷。敏捷 QA 的流程如下：

?文章來源地址http://www.zghlxwxcb.cn/news/detail-653705.html

對(duì)于葡萄酒訂購系統(tǒng)的 bug，處理方式也無非就是加強(qiáng)上線前各個(gè)階段的測(cè)試，提高發(fā)布到生產(chǎn)環(huán)境的產(chǎn)品質(zhì)量。

除此之外，我們還有什么處理辦法呢？

上面兩種開發(fā)模式下，QA 的重點(diǎn)都是放在發(fā)布前的測(cè)試和預(yù)生產(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)控, 制定檢測(cè)緊急錯(cuò)誤的警報(bào)條件，持續(xù)質(zhì)量問題的確定以及找出在生產(chǎn)環(huán)境下使用的度量以保證這種方式可行。

回到前面葡萄酒訂購系統(tǒng)的那個(gè) Bug，如果在生產(chǎn)環(huán)境下設(shè)置監(jiān)控預(yù)警，對(duì)于一個(gè)訂單購買葡萄酒數(shù)量異常的情況進(jìn)行監(jiān)控，將能及時(shí)發(fā)現(xiàn) bug，并且比較容易在損失發(fā)生之前及時(shí)阻止產(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)境去做測(cè)試，尤其是破壞性的測(cè)試。

2. 基礎(chǔ)設(shè)施差異

生產(chǎn)環(huán)境往往有著比測(cè)試和預(yù)生產(chǎn)環(huán)境要復(fù)雜和健全的基礎(chǔ)設(shè)施，可能會(huì)出現(xiàn)測(cè)試和預(yù)生產(chǎn)環(huán)境不能預(yù)測(cè)到的缺陷和異常。

3. 系統(tǒng)復(fù)雜度

生產(chǎn)環(huán)境需要與多個(gè)不同的系統(tǒng)集成，系統(tǒng)復(fù)雜度會(huì)比測(cè)試環(huán)境和預(yù)生產(chǎn)環(huán)境高很多，這種復(fù)雜的系統(tǒng)集成很有可能導(dǎo)致一些意外的情況出現(xiàn)。

4. 數(shù)據(jù)復(fù)雜度

生產(chǎn)環(huán)境的數(shù)據(jù)量和數(shù)據(jù)復(fù)雜度也是測(cè)試環(huán)境和預(yù)生產(chǎn)環(huán)境無法比擬的，通常都不是一個(gè)數(shù)量級(jí)的數(shù)據(jù)，容易引發(fā)性能問題、或者一些復(fù)雜的數(shù)據(jù)組合導(dǎo)致的問題。

5. 用戶行為千奇百怪

生產(chǎn)環(huán)境的用戶分布廣泛，使用習(xí)慣各種各樣，導(dǎo)致用戶行為千奇百怪，某些使用行為可能就會(huì)產(chǎn)生意想不到的問題。

6. 訪問受限

生產(chǎn)環(huán)境由于是真實(shí)業(yè)務(wù)線上的系統(tǒng)，對(duì)安全性和穩(wěn)定性要求更高，服務(wù)器的通常不是所有 QA 可以隨便訪問的，這種訪問受限的情況對(duì)于生產(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)境不是想做什么就能做什么的，原來測(cè)試環(huán)境和預(yù)生產(chǎn)環(huán)境那套質(zhì)量保證理論和方法都行不通了。

生產(chǎn)環(huán)境下的 QA 有這么多挑戰(zhàn)，聽起來是不是很沮喪？不要著急，針對(duì)生產(chǎn)環(huán)境獨(dú)有的特點(diǎn)，一定能找到相應(yīng)的解決方案。接下來，咱們一起來看看生產(chǎn)環(huán)境下（不僅是 QA）可以做什么。

三、生產(chǎn)環(huán)境下可以做什么

?

生產(chǎn)環(huán)境的這些特點(diǎn)決定了 QA 在生產(chǎn)環(huán)境不是想做什么就能做什么的，原來測(cè)試環(huán)境那套質(zhì)量保證理論和方法都行不通了。要實(shí)現(xiàn)生產(chǎn)環(huán)境下的 QA，有以下三個(gè)方向：

• 直接在生產(chǎn)環(huán)境測(cè)試

• 監(jiān)控預(yù)警

• 用戶反饋收集

1. 直接在生產(chǎn)環(huán)境測(cè)試

前面講到不能隨便去操作生產(chǎn)環(huán)境下的系統(tǒng)對(duì)其進(jìn)行測(cè)試，怎么還能直接在生產(chǎn)環(huán)境測(cè)試呢？的確不是像在測(cè)試環(huán)境那樣測(cè)試，有一些限制和特定技術(shù)的采用。

對(duì)于只讀操作和可隔離特性的測(cè)試

在不影響真實(shí)用戶體驗(yàn)的情況下，可以對(duì)某些功能進(jìn)行只讀操作，需要選擇用戶使用頻率較低的時(shí)段進(jìn)行，不能進(jìn)行大數(shù)據(jù)量的只讀操作，以免影響系統(tǒng)性能。對(duì)于某些特定的特性，如果比較方便隔離的話，可以在生產(chǎn)環(huán)境利用獨(dú)立的測(cè)試數(shù)據(jù)對(duì)其進(jìn)行測(cè)試。

藍(lán)綠部署（Blue Green Deployment）

藍(lán)綠部署是一種通過運(yùn)行兩個(gè)相同的生產(chǎn)環(huán)境“藍(lán)環(huán)境”和“綠環(huán)境”來減少停機(jī)時(shí)間和風(fēng)險(xiǎn)的技術(shù)，雖然不能算是真正意義的直接在生產(chǎn)環(huán)境測(cè)試，也是非常典型的實(shí)踐之一。

在任何時(shí)候，只有一個(gè)環(huán)境是活的，活的環(huán)境為所有生產(chǎn)流量提供服務(wù)。通常綠環(huán)境是閑置的，藍(lán)環(huán)境是活的。部署新的版本到綠環(huán)境，可以先進(jìn)行測(cè)試，而不會(huì)給真正在使用的藍(lán)環(huán)境帶來影響。完成部署和測(cè)試以后，再進(jìn)行藍(lán)綠環(huán)境的切換。

此技術(shù)可以消除由于應(yīng)用程序部署導(dǎo)致的停機(jī)時(shí)間。此外，藍(lán)綠部署可降低風(fēng)險(xiǎn)：如果新版本在綠環(huán)境上發(fā)生意外情況，可以通過切換回藍(lán)環(huán)境立即回滾到上一版本。這樣就有機(jī)會(huì)提前發(fā)現(xiàn)新版本部署生產(chǎn)環(huán)境可能引起的問題。

金絲雀發(fā)布（Canary release）

不同于藍(lán)綠部署有兩套服務(wù)器，金絲雀發(fā)布，也就是我們常說的灰度發(fā)布，只有一套服務(wù)器，是通過先部署新版本到其中部分服務(wù)器，并測(cè)試驗(yàn)證，沒問題再推廣部署到更多服務(wù)器的發(fā)布流程。

2. 監(jiān)控預(yù)警

前面講到不能隨便去操作生產(chǎn)環(huán)境下的系統(tǒng)對(duì)其進(jìn)行測(cè)試，但是可以通過監(jiān)控的方式去獲得我們需要的信息，對(duì)異常情況進(jìn)行預(yù)警。提到監(jiān)控預(yù)警，不得不提大家都了解或者至少聽說過的日志和網(wǎng)站分析工具，這兩者都是做好生產(chǎn)環(huán)境下的 QA 非常有幫助的工具。

日志

日志就像是飛機(jī)上的黑匣子，可以記錄系統(tǒng)運(yùn)行的各種信息，包括錯(cuò)誤、異常和失敗等。一旦程序出現(xiàn)問題，記錄的這些信息就可以用來分析問題的原因；同時(shí)可以利用記錄的日志設(shè)置好預(yù)警，提前預(yù)測(cè)系統(tǒng)可能出現(xiàn)的問題。生產(chǎn)環(huán)境下日志所提供的監(jiān)控和預(yù)警信息，將有利于：

• 阻止不良后果，避免大的損失：前面提到的葡萄酒訂購系統(tǒng)就是一個(gè)很好的例子；

• 發(fā)現(xiàn)潛在的性能問題：通過對(duì)日志進(jìn)行分析，可能發(fā)現(xiàn)還沒暴露出來的性能問題，提前修復(fù)；

• 指導(dǎo)測(cè)試和預(yù)生產(chǎn)環(huán)境的測(cè)試：通過生產(chǎn)環(huán)境下日志的分析，可以看出哪些功能易出什么樣的錯(cuò)誤，從而相應(yīng)調(diào)整測(cè)試策略，加強(qiáng)預(yù)生產(chǎn)環(huán)境的相關(guān)功能的測(cè)試。

網(wǎng)站分析工具

網(wǎng)站分析工具根據(jù)具體工具不同，所能記錄信息也有差異，但基本都可以記錄如下信息：

• 用戶使用的操作系統(tǒng)、瀏覽器等信息

• 用戶行為習(xí)慣，包括使用的時(shí)間、關(guān)鍵路徑、關(guān)鍵業(yè)務(wù)流程等

• 用戶所在地區(qū)、語言等區(qū)域信息

• 用戶訪問量，請(qǐng)求的響應(yīng)時(shí)間，網(wǎng)站性能等

利用網(wǎng)站分析工具收集到的以上數(shù)據(jù)，可以幫助我們調(diào)整預(yù)生產(chǎn)環(huán)境的測(cè)試側(cè)重點(diǎn)，指導(dǎo)預(yù)生產(chǎn)環(huán)境的測(cè)試；根據(jù)用戶行為習(xí)慣等信息，還可以幫助優(yōu)化產(chǎn)品業(yè)務(wù)價(jià)值。

3. 用戶反饋

介紹生產(chǎn)環(huán)境特點(diǎn)的時(shí)候提到一點(diǎn)就是生產(chǎn)環(huán)境能夠收到真實(shí)的用戶反饋，這是非常有價(jià)值的，要做好生產(chǎn)環(huán)境下的 QA 一定要利用這些反饋。由于用戶行為和習(xí)慣的千奇百怪，用戶提供的反饋也可能是各種各樣的，為了更好的利用它們，需要一個(gè)嚴(yán)格的 Triage 的過程，對(duì)所有反饋進(jìn)行分類并相應(yīng)處理。用戶反饋，可以總結(jié)為下面幾類：

缺陷

用戶在使用過程中，系統(tǒng)所出現(xiàn)的問題，并且能夠穩(wěn)定重現(xiàn)的，我們定義為缺陷，缺陷通常會(huì)影響到功能的使用，是需要修復(fù)的，根據(jù)優(yōu)先級(jí)和嚴(yán)重程度，安排相應(yīng)的修復(fù)計(jì)劃并對(duì)其進(jìn)行修復(fù)，同時(shí)還需要對(duì)修復(fù)的缺陷增加（自動(dòng)化）測(cè)試，以防被再次破壞。

除了能夠穩(wěn)定重現(xiàn)的缺陷，有時(shí)候還會(huì)有一些隨機(jī)的失敗（比如前面提到的葡萄酒訂購系統(tǒng)的 bug）或者難以重現(xiàn)的問題，這類問題很難找到原因，但是又給用戶帶來很大的不爽。其實(shí)，它們通常也是一些缺陷引起的，只是根源可能隱藏得比較深，對(duì)于這種問題的處理辦法就是前面部分提到的可以添加日志對(duì)相關(guān)功能進(jìn)行監(jiān)控和預(yù)警，利用日志協(xié)助找到問題根源并進(jìn)行修復(fù)。

抱怨

用戶在使用系統(tǒng)過程中由于行為習(xí)慣、網(wǎng)絡(luò)環(huán)境等差異，總會(huì)有各種抱怨，一般以非功能性的問題居多，比如易用性、性能、可維護(hù)性、可擴(kuò)展性等，當(dāng)然也有可能是某個(gè)功能設(shè)計(jì)的不能滿足真實(shí)的用戶需求。需要對(duì)所有抱怨進(jìn)行分類，確定是非功能的缺陷，還是新的需求。用戶的抱怨有可能千奇百怪，不是所有的都能滿足，需要根據(jù)分類定義優(yōu)先級(jí)，確定哪些是需要改進(jìn)和修復(fù)，從而采取相應(yīng)的措施。

建議

除了反饋問題和提出抱怨，用戶也會(huì)對(duì)系統(tǒng)使用方面提一些建議。但一般用戶很難提出好的建議，要想收集到有價(jià)值的信息，需要提前設(shè)計(jì)好問卷進(jìn)行問卷調(diào)查，有針對(duì)性的去收集；或者對(duì)一些重要用戶進(jìn)行訪談，或者發(fā)布一個(gè)簡單的新功能收集用戶的使用建議等。然后對(duì)收集到的建議進(jìn)行分析，確定可行性，并將可行的建議應(yīng)用到后續(xù)的系統(tǒng)和業(yè)務(wù)流程的改進(jìn)中。

利用用戶反饋，改進(jìn)系統(tǒng)功能，可以優(yōu)化業(yè)務(wù)價(jià)值，擴(kuò)大產(chǎn)品的市場(chǎng)影響力，提高企業(yè)的競(jìng)爭(zhēng)力。常被用來收集用戶反饋的實(shí)踐有：

• Beta 測(cè)試 (?https://en.wikipedia.org/wiki/Software_testing#Beta_testing?)：很多有前瞻性的網(wǎng)站或應(yīng)用會(huì)發(fā)布新功能給特定用戶組（Beta 用戶），收集用戶使用新功能的統(tǒng)計(jì)數(shù)據(jù)；

• AB 測(cè)試 (?https://en.wikipedia.org/wiki/A/B_testing?)：同時(shí)發(fā)布兩個(gè)不同版本的系統(tǒng)到生產(chǎn)環(huán)境，并將用戶引導(dǎo)到兩個(gè)版本，統(tǒng)計(jì)使用每個(gè)版本的用戶數(shù)據(jù)；

• Observed Requirement (?http://martinfowler.com/bliki/ObservedRequirement.html?)：發(fā)布一個(gè)簡單的功能，或者發(fā)布一個(gè) MVP (?https://en.wikipedia.org/wiki/Minimum_viable_product?)版本，觀察用戶使用情況，從而引出并收集到用戶的真實(shí)需求。

監(jiān)控預(yù)警、收集和分析用戶反饋并不是 QA 能獨(dú)立完成的，需要與不同角色協(xié)作，QA 在整個(gè)過程中主要充當(dāng)分析者和協(xié)調(diào)者的角色，對(duì)生產(chǎn)環(huán)境下的質(zhì)量保證工作起到至關(guān)重要的作用：

1. 跟 DEV 一起討論監(jiān)控標(biāo)準(zhǔn)，把日志標(biāo)準(zhǔn)化的要求融入到軟件開發(fā)流程中，確保日志能夠記錄到真正需要記錄的信息。

2. 跟運(yùn)維團(tuán)隊(duì)一起分析收集到的統(tǒng)計(jì)數(shù)據(jù)，指導(dǎo)和優(yōu)化各個(gè)階段的測(cè)試，以預(yù)防和減少系統(tǒng)在生產(chǎn)環(huán)境下的缺陷。

3. 跟業(yè)務(wù)分析人員一起分析和梳理從生產(chǎn)環(huán)境收集到的需求相關(guān)的反饋，提煉出合理的需求，優(yōu)化業(yè)務(wù)價(jià)值。

四、生產(chǎn)環(huán)境下的 QA 在項(xiàng)目上的實(shí)踐

我所在的項(xiàng)目是一個(gè)離岸交付項(xiàng)目，采用的是敏捷開發(fā)模式，四周一次發(fā)布到生產(chǎn)環(huán)境，開發(fā)的系統(tǒng)包括一個(gè)內(nèi)部員工使用系統(tǒng)和一個(gè)外部用戶使用的網(wǎng)站，用戶遍及全球，項(xiàng)目整個(gè)已經(jīng)持續(xù)了七年有余，生產(chǎn)環(huán)境具備前面所描述的所有特點(diǎn)，并且生產(chǎn)環(huán)境每日的錯(cuò)誤日志達(dá)到幾千條。正是由于錯(cuò)誤日志的數(shù)量到了一個(gè)不能忍的程度，生產(chǎn)環(huán)境引起了各方的關(guān)注，也使得生產(chǎn)環(huán)境下的 QA 迎來了試點(diǎn)的最佳時(shí)機(jī)。生產(chǎn)環(huán)境下的 QA 在我們項(xiàng)目上的實(shí)踐主要是三部分內(nèi)容：日志分析和優(yōu)化、Google Analytics 數(shù)據(jù)分析、用戶反饋的收集和分析，下面逐個(gè)介紹。

1. 日志分析和優(yōu)化

既然錯(cuò)誤日志那么多，首當(dāng)其沖就是從這些錯(cuò)誤日志下手。項(xiàng)目使用的日志分析工具是 Splunk ( http://www.splunk.com/ )，這個(gè)工具功能強(qiáng)大、使用方便，關(guān)于工具的詳細(xì)信息可以參考官網(wǎng)。下圖所示為使用 Splunk 通過指定條件搜索日志文件得到的結(jié)果頁面，結(jié)果集里四條類似亂碼的東西就是代表有四種類型的錯(cuò)誤日志，每種錯(cuò)誤出現(xiàn)的數(shù)量和百分比都有統(tǒng)計(jì)，點(diǎn)擊每條結(jié)果可以查看詳細(xì)的錯(cuò)誤日志信息。

關(guān)于日志的分析和優(yōu)化，我們?cè)陧?xiàng)目上做了如下工作：

1) 分析生產(chǎn)環(huán)境的錯(cuò)誤日志

每天會(huì)有專人負(fù)責(zé)錯(cuò)誤日志的分析，找出其中的優(yōu)先級(jí)高的問題給團(tuán)隊(duì)修復(fù)。QA 會(huì)協(xié)助重現(xiàn)、跟蹤并負(fù)責(zé)測(cè)試這些重要的需要修復(fù)的問題，通過對(duì)錯(cuò)誤日志的分析，QA 可以大概的統(tǒng)計(jì)出哪些功能特性比較容易產(chǎn)生錯(cuò)誤，在接下來的預(yù)生產(chǎn)環(huán)境的測(cè)試中要重點(diǎn)關(guān)注。另外，對(duì)于某些功能由于測(cè)試環(huán)境的數(shù)據(jù)等局限性，擔(dān)心部署到生產(chǎn)環(huán)境會(huì)產(chǎn)生錯(cuò)誤或者有性能問題，一般上線后會(huì)著重關(guān)注這樣的功能，除了日常的監(jiān)控分析之外，還要單獨(dú)對(duì)該功能的日志進(jìn)行檢查，以防產(chǎn)生嚴(yán)重問題。

2) 監(jiān)控測(cè)試環(huán)境的錯(cuò)誤日志

把生產(chǎn)環(huán)境錯(cuò)誤日志的分析方法應(yīng)用于測(cè)試環(huán)境，對(duì)測(cè)試環(huán)境的錯(cuò)誤日志進(jìn)行監(jiān)控，盡量把環(huán)境無關(guān)由功能引起的錯(cuò)誤找出來，盡早修復(fù)，不讓其流落到生產(chǎn)環(huán)境。據(jù)不完全統(tǒng)計(jì)，最近兩三個(gè)月通過這種方式發(fā)現(xiàn)并修復(fù)了好幾個(gè)潛在的 Bug。

3) 利用日志監(jiān)控不同功能的性能

Ops 在 Splunk 里設(shè)置有專門的統(tǒng)計(jì)和監(jiān)控系統(tǒng)性能的 Dashboard，QA 會(huì)定期從里邊拿出潛在的存在性能問題的功能模塊，創(chuàng)建對(duì)應(yīng)的任務(wù)卡由開發(fā)團(tuán)隊(duì)來做性能調(diào)優(yōu)。

4) 日志記錄標(biāo)準(zhǔn)化

通過對(duì)生產(chǎn)環(huán)境錯(cuò)誤日志的分析，發(fā)現(xiàn)現(xiàn)有日志記錄存在如下問題：

• 存儲(chǔ)位置不統(tǒng)一，有些日志沒有辦法通過 Splunk 統(tǒng)計(jì)分析，造成分析成本的增加；

• 記錄格式不一致，有些日志雖然可以通過 Splunk 看到，但是沒有記錄很有用的信息，比如沒有記錄錯(cuò)誤發(fā)生時(shí)候的一些有意義的 message，或者是 Post 請(qǐng)求沒有記錄輸入?yún)?shù)，導(dǎo)致排查錯(cuò)誤日志的工作增加了難度；

• 日志級(jí)別定義混亂，有些沒有到達(dá)錯(cuò)誤級(jí)別（error）的日志也記成了錯(cuò)誤（error）日志，這也是錯(cuò)誤日志數(shù)量大的原因之一。

為了讓日志分析更輕松、讓日志更全面地記錄系統(tǒng)的各種情況，針對(duì)上面的問題，團(tuán)隊(duì)討論并達(dá)成共識(shí)：

• 將日志輸出到各個(gè)服務(wù)器的同一個(gè)路徑；

• 統(tǒng)一日志記錄格式，并且盡量記錄更全面的信息幫助后期的日志分析；

• 清晰定義各個(gè)日志級(jí)別（Debug，Info，Warning，Error，Critical，F(xiàn)atal），將已有的誤記成錯(cuò)誤的日志降低到正確的級(jí)別，對(duì)于新功能則嚴(yán)格按照所定義級(jí)別記錄日志；

• QA 在用戶故事（Story）的開發(fā)機(jī)驗(yàn)收（Dev-box Testing or Desk Check）階段負(fù)責(zé)跟開發(fā)人員確認(rèn)相關(guān)日志記錄是否符合標(biāo)準(zhǔn)，并且通過測(cè)試環(huán)境的日志監(jiān)控可以及時(shí)驗(yàn)證新功能的日志記錄情況。? ?

2. Google Analytics 數(shù)據(jù)分析

Google Analytics ( https://analytics.google.com/ )（以下簡稱 GA）是項(xiàng)目用來統(tǒng)計(jì)網(wǎng)站使用情況的工具，從 GA 上可以獲取很多有價(jià)值的信息，對(duì)這些信息的分析是我們實(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 用來測(cè)試的操作系統(tǒng)和瀏覽器，盡量讓測(cè)試環(huán)境跟真實(shí)用戶更接近。比如，前兩年客戶內(nèi)部員工使用的瀏覽器最多的是 IE9，那么我們 QA 的測(cè)試也是主要關(guān)注 IE9，而今年變成了 IE11，我們重點(diǎn)關(guān)注的瀏覽器也相應(yīng)調(diào)整為 IE11（當(dāng)然，鑒于 IE9 的特殊性——容易出問題，只要還有用戶使用，我們還是需要關(guān)注），而對(duì)于沒有用戶使用的 Firefox，我們則不用來測(cè)試。

2) 分析 QA 測(cè)試跟用戶真實(shí)行為的差異，及時(shí)調(diào)整測(cè)試根據(jù)

GA 上用戶訪問的路徑可以發(fā)現(xiàn)我們 QA 的測(cè)試跟一些真實(shí)用戶使用習(xí)慣的差異，這樣如果按照我們通常的路徑去測(cè)試，可能有些問題難以在測(cè)試階段發(fā)現(xiàn)。比如，QA 在測(cè)試環(huán)境通常打開“工作記錄”的方式是這樣的：

?而我們從 GA 上發(fā)現(xiàn)真實(shí)用戶使用過程中，打開“工作記錄”最多的路徑是這樣的：

發(fā)現(xiàn)了這種差異，QA 就要在測(cè)試時(shí)候做相應(yīng)的調(diào)整，讓測(cè)試更接近用戶的行為習(xí)慣。

3) 提煉關(guān)鍵業(yè)務(wù)場(chǎng)景，增加測(cè)試覆蓋

一個(gè)開發(fā)好幾年的系統(tǒng)，其功能必然是比較復(fù)雜的，由于自動(dòng)化測(cè)試覆蓋率不是很理想，過去回歸測(cè)試需要的投入比較大，而且由于功能相對(duì)復(fù)雜，又不是很清楚哪些功能對(duì)用戶來說最為重要，測(cè)試很難做到有效覆蓋。這種情況對(duì)于人員比例低下的敏捷團(tuán)隊(duì) QA 來說，是一件非常有挑戰(zhàn)的事情，通常 QA 們?cè)诎l(fā)布前忙得不行。利用 GA 的數(shù)據(jù)結(jié)合客戶業(yè)務(wù)人員對(duì)系統(tǒng)各功能使用情況的介紹，我們提煉出來系統(tǒng)最為關(guān)鍵的一些業(yè)務(wù)場(chǎng)景，并且盡量分層（參考測(cè)試金字塔）實(shí)現(xiàn)自動(dòng)化測(cè)試覆蓋，從而不需要花費(fèi)太多的人力去做回歸測(cè)試，同樣可以保證主要的業(yè)務(wù)流程不至于被破壞，而 QA 則可以有更多的時(shí)間和精力去做探索性測(cè)試等更有價(jià)值的事情。

4) 發(fā)現(xiàn)用戶較少使用的功能，優(yōu)化業(yè)務(wù)流程

關(guān)鍵場(chǎng)景就是用戶使用頻率較高的功能，類似的，我們還可以通過 GA 發(fā)現(xiàn)一些用戶較少使用的功能，這可能的原因是不符合用戶真實(shí)行為習(xí)慣，喜歡用其他路徑去完成同樣的事情，或者不符合真實(shí)業(yè)務(wù)需求，也就是說真實(shí)的業(yè)務(wù)環(huán)境下根本沒有要用到這個(gè)功能的地方。對(duì)于這種功能，首先從 QA 角度來講，我們的測(cè)試基本不需要太多去關(guān)注，如果有相關(guān)功能的缺陷，它的優(yōu)先級(jí)也很低很低；另外，可以跟業(yè)務(wù)分析人員一起分析下原因，在后續(xù)的功能開發(fā)過程中可以作為借鑒，從而優(yōu)化業(yè)務(wù)流程。

5) 分析用戶地區(qū)分布和使用時(shí)間段分布，合理安排定時(shí)任務(wù)運(yùn)行時(shí)間

系統(tǒng)用戶遍及全球，使用時(shí)間段分布也就變得復(fù)雜，為了不影響正常使用，有些事情是需要盡量在系統(tǒng)沒人使用的時(shí)候去做的，比如統(tǒng)計(jì)某類數(shù)據(jù)需要定時(shí)執(zhí)行 SQL 腳本等定時(shí)任務(wù)。通過 GA 上的數(shù)據(jù)，統(tǒng)計(jì)出哪個(gè)時(shí)間段是相對(duì)空閑的，在不影響真實(shí)業(yè)務(wù)的前提下，把一些資源消耗較大的任務(wù)安排在那個(gè)時(shí)候執(zhí)行，合理分配資源以減輕服務(wù)器的負(fù)擔(dān)。

6) 監(jiān)控系統(tǒng)性能變化趨勢(shì)，規(guī)避性能風(fēng)險(xiǎn)

QA 定期查看網(wǎng)站平均訪問時(shí)間，監(jiān)控性能趨勢(shì)，同時(shí)要重點(diǎn)關(guān)注那些訪問非常慢的頁面或功能，必要的時(shí)候創(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 嵌入到了各個(gè)需要統(tǒng)計(jì)的功能或頁面，QA 在預(yù)生產(chǎn)環(huán)境測(cè)試的時(shí)候需要驗(yàn)證這一點(diǎn)。

下圖為從 GA 拿到的瀏覽器分布情況和頁面平均加載時(shí)間的一些數(shù)據(jù)：

3. 用戶反饋的收集和分析

作為開發(fā)團(tuán)隊(duì)的我們基本是不能直接接觸到系統(tǒng)終端用戶的，直接接受反饋的是我們客戶的 Ops 團(tuán)隊(duì)，QA 主要通過下面幾個(gè)途徑去協(xié)助分析和梳理用戶反饋：

1) 跟 Ops 和業(yè)務(wù)的定期溝通會(huì)議

QA 會(huì)定期跟客戶的 Ops 和業(yè)務(wù)人員溝通，了解用戶對(duì)于現(xiàn)有系統(tǒng)的反饋，找出在測(cè)試中需要重視的功能特性，將測(cè)試環(huán)境和預(yù)生產(chǎn)環(huán)境的測(cè)試關(guān)注點(diǎn)做出相應(yīng)的調(diào)整。

2) 培訓(xùn) Ops 人員

指導(dǎo)和協(xié)助客戶 Ops 人員利用魚骨圖（Fishbone Diagram） ( https://en.wikipedia.org/wiki/Ishikawa_diagram )的方法對(duì)收集到的用戶反饋進(jìn)行分析和分類，將分析結(jié)果跟現(xiàn)有的測(cè)試覆蓋情況進(jìn)行對(duì)比，找出測(cè)試過程的薄弱環(huán)節(jié)，并做出改進(jìn)。比如，如果某個(gè)瀏覽器出現(xiàn)的 bug 比較多，而我們的測(cè)試則要加強(qiáng)該瀏覽器的關(guān)注；或者是因?yàn)椴煌脩魴?quán)限導(dǎo)致的問題出現(xiàn)頻率高，那就得在測(cè)試中注意覆蓋不同用戶角色的測(cè)試，反之則減弱不同用戶的覆蓋，主要測(cè)最常用的那類角色即可。

3) 調(diào)查和跟蹤生產(chǎn)環(huán)境 Bug

幫助重現(xiàn)和調(diào)查用戶反饋過來的生產(chǎn)環(huán)境 Bug，并負(fù)責(zé)跟蹤修復(fù)和驗(yàn)證；對(duì)于難以重現(xiàn)的問題，則添加日志監(jiān)控，通過分析收集到的日志信息找出問題根源，從而進(jìn)行修復(fù)。

4) 協(xié)助梳理業(yè)務(wù)需求

系統(tǒng)要增加某個(gè)新功能的時(shí)候，客戶 Product Owner（以下簡稱 PO）或其他業(yè)務(wù)人員跟用戶會(huì)一起溝通該功能相關(guān)業(yè)務(wù)現(xiàn)有的使用習(xí)慣、使用場(chǎng)景，QA 也會(huì)盡力參與這種會(huì)議，收集用戶第一手需求信息，這些信息對(duì)于后期該業(yè)務(wù)功能開發(fā)時(shí)候的 QA 過程將非常有幫助。而還有些功能，PO 可能一時(shí)也拿不定主意要做成什么樣子，我們會(huì)發(fā)布 MVP 的版本給用戶使用，QA 協(xié)助業(yè)務(wù)人員分析用戶使用后的反饋，梳理更具體的用戶需求。

五、生產(chǎn)環(huán)境下的 QA 有什么特點(diǎn)

1. 不同于測(cè)試環(huán)境和預(yù)生產(chǎn)環(huán)境的 QA

生產(chǎn)環(huán)境的特點(diǎn)決定了生產(chǎn)環(huán)境下的 QA 是跟預(yù)生產(chǎn)環(huán)境的 QA 不同的，不是主動(dòng)的去測(cè)試生產(chǎn)環(huán)境的系統(tǒng)，而是通過設(shè)置監(jiān)控條件，收集用戶使用系統(tǒng)的反饋，對(duì)反饋進(jìn)行分析并改進(jìn)，從而讓產(chǎn)品質(zhì)量獲得提高。因此，生產(chǎn)環(huán)境下的 QA 并不是測(cè)試環(huán)境和預(yù)生產(chǎn)環(huán)境 QA 活動(dòng)的簡單后延，它有著自己獨(dú)特的特點(diǎn)。

2. 不能獨(dú)立存在

生產(chǎn)環(huán)境下的 QA 所設(shè)置的監(jiān)控標(biāo)準(zhǔn)是根據(jù)系統(tǒng)的行為特點(diǎn)和在預(yù)生產(chǎn)環(huán)境下的表現(xiàn)來定義的，生產(chǎn)環(huán)境下各項(xiàng)反饋的分析結(jié)果反過來又影響著預(yù)生產(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)?QA 有著獨(dú)特的思維模式和視角，QA 的參與能夠幫助更好的分析生產(chǎn)環(huán)境下收集到的各種反饋，并且結(jié)合對(duì)于系統(tǒng)的了解，能夠?qū)⑦@些反饋更好的應(yīng)用到日常的開發(fā)工作中。

這時(shí)候的 QA 帶著 QA 和 Ops 的帽子，兼具 QA 和 Ops 的部分職責(zé)，類似于 QAOps，不過現(xiàn)在都提倡不要有獨(dú)立的 DevOps，我們也不要獨(dú)立的 QAOps 角色，只是讓 QA 這個(gè)角色可做的事情得到了延伸和擴(kuò)展而已，本質(zhì)上還是 QA。

4. 跟 APM 的側(cè)重點(diǎn)不同

可能有人會(huì)覺得生產(chǎn)環(huán)境下的 QA 跟 APM 有相似之處，那么這兩者是不是一回事呢？

維基百科這樣解釋 APM ( https://en.m.wikipedia.org/wiki/Application_performance_management )：

“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 是對(duì)軟件應(yīng)用程序的性能和可用性的監(jiān)控和管理。）”

APM 更多的是從性能角度出發(fā)去管理和優(yōu)化應(yīng)用的可用性，可以發(fā)生在各個(gè)階段，不一定是生產(chǎn)環(huán)境。生產(chǎn)環(huán)境下的 QA 是指在生產(chǎn)環(huán)境進(jìn)行一系列的監(jiān)控和數(shù)據(jù)收集，從系統(tǒng)功能、性能、易用性等多個(gè)方面進(jìn)行優(yōu)化，從而最終優(yōu)化業(yè)務(wù)價(jià)值。因此，兩者是不同的。

六、總結(jié)

• 生產(chǎn)環(huán)境下的 QA 將 QA 的工作范圍擴(kuò)大到從需求到生產(chǎn)環(huán)境，增加了更多的反饋來源，跟持續(xù)交付結(jié)合，可以幫助持續(xù)提高產(chǎn)品質(zhì)量、持續(xù)優(yōu)化業(yè)務(wù)價(jià)值。

• 生產(chǎn)環(huán)境下的 QA 給 QA 的工具箱添加了更多的工具，提供了更多評(píng)估和提高系統(tǒng)質(zhì)量的選項(xiàng)，是 QA 們值得深入研究的話題。

• 生產(chǎn)環(huán)境下的 QA 不能走的太遠(yuǎn)，必須先做好測(cè)試環(huán)境和預(yù)生產(chǎn)環(huán)境的質(zhì)量保證，并且僅適用于持續(xù)交付實(shí)踐的比較好的組織，如果連測(cè)試環(huán)境和預(yù)生產(chǎn)環(huán)境的質(zhì)量保證都做不好，而就想著去做生產(chǎn)環(huán)境下的 QA，那只能是舍本逐末、事倍功半。

?

?

到了這里，關(guān)于測(cè)試右移，也就是生產(chǎn)環(huán)境下的QA的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！