質(zhì)量綜述

隨著互聯(lián)網(wǎng)快速發(fā)展，早期的傳統(tǒng)軟件公司強(qiáng)調(diào)工程的嚴(yán)謹(jǐn)性，CMMI，ISO9000格局已經(jīng)發(fā)生變化，逐漸退出歷史舞臺(tái)。前期敏捷理念被迅速的普及。Scrum迎合了產(chǎn)品管理的需求, XP迎合了工程化發(fā)展的需求。各自發(fā)展都很迅猛，然后逐漸衍生了更深入的CI、CD和DEVOPS等模式。

企業(yè)扁平化管理，大質(zhì)量部模式被打散，為了提高運(yùn)作效率， QA或者測(cè)試工程師團(tuán)隊(duì)被逐漸分拆到各個(gè)具體業(yè)務(wù)部門(mén)，技術(shù)性測(cè)試工程師開(kāi)始逐漸發(fā)揮價(jià)值。未來(lái)隨著DEVOPS完善，質(zhì)量問(wèn)題將會(huì)越來(lái)越突出不久的將來(lái)可能會(huì)出現(xiàn)DEVQA。

根據(jù)目前軟件發(fā)展趨勢(shì)，軟件質(zhì)量可以分為發(fā)布前軟件質(zhì)量和發(fā)布后軟件質(zhì)量，發(fā)布前軟件質(zhì)量分為軟件質(zhì)量驗(yàn)證和軟件質(zhì)量交互，發(fā)布后軟件質(zhì)量可以分為軟件質(zhì)量監(jiān)控和軟件質(zhì)量運(yùn)維如下圖：

軟件質(zhì)量綜述圖

質(zhì)量驗(yàn)證

軟件質(zhì)量驗(yàn)證，具體的說(shuō)就是軟件測(cè)試，它分為黑盒測(cè)試，灰盒測(cè)試，白盒測(cè)試，灰度測(cè)試。

質(zhì)量驗(yàn)證及相關(guān)內(nèi)容

在傳統(tǒng)軟件公司強(qiáng)調(diào)工程的嚴(yán)謹(jǐn)性黑盒測(cè)試發(fā)展很成熟，方式方法也很全面，測(cè)試資源投入比較多。這樣開(kāi)發(fā)人員可以專心寫(xiě)著優(yōu)雅的代碼，只做單元測(cè)試和接口、組件測(cè)試就可以了，其他的事情都讓測(cè)試人員去干。

隨著計(jì)算機(jī)科學(xué)專業(yè)在大學(xué)完善，越來(lái)越多的科班生都參與到測(cè)試行業(yè)，在互聯(lián)網(wǎng)公司隨著開(kāi)發(fā)人員慢慢滲透到測(cè)試，自動(dòng)化測(cè)試、白盒測(cè)試和灰度測(cè)試越來(lái)越盛行。流行上面主要原因是分層自動(dòng)化，測(cè)試需求減少，測(cè)試人力資源減少越來(lái)越專業(yè)化，測(cè)試、開(kāi)發(fā)比例越來(lái)越低，讓機(jī)器干活，逐漸釋放人力，節(jié)約成本。下面逐漸開(kāi)始介紹質(zhì)量驗(yàn)證，質(zhì)量驗(yàn)證包括黑盒測(cè)試、白盒測(cè)試、灰盒測(cè)試、灰度測(cè)試。

黑盒測(cè)試

黑盒測(cè)試分功能測(cè)試和非功能測(cè)試。

常用的功能測(cè)試有單元測(cè)試、接口/組件測(cè)試、冒煙測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、回歸測(cè)試、UI測(cè)試、α測(cè)試、β測(cè)試，非功能測(cè)試有性能測(cè)試、穩(wěn)定性測(cè)試、安全測(cè)試、恢復(fù)測(cè)試這些測(cè)試都是一個(gè)項(xiàng)目必須要有的方式，但是在時(shí)間和人力允許的情況下可以有交叉測(cè)試、兼容性測(cè)試、可用性測(cè)試、比較性測(cè)試、探索性測(cè)試。然后使用分層自動(dòng)化測(cè)試來(lái)提高上面各種測(cè)試效率。

黑盒分層自動(dòng)化可以分為單元測(cè)試自動(dòng)化、集成接口自動(dòng)化、UI層自動(dòng)化，單元測(cè)試采用框架如java的Junit、testNG，C#的NUnit，python的unittest、pytest等，集成接口自動(dòng)化框架如SoapUI（改名叫Ready!API）、Postman等,UI層自動(dòng)化如QTP，Robot Framework、watir、selenium等，具體怎么做分層自動(dòng)化，具體需求根據(jù)具體項(xiàng)目去做。

• 開(kāi)發(fā)人員自測(cè)標(biāo)準(zhǔn)：完成需求文檔、設(shè)計(jì)文檔、完成代碼開(kāi)發(fā)
• 提交測(cè)試人員標(biāo)準(zhǔn)：開(kāi)發(fā)人員輸出單元測(cè)試，接口/組件測(cè)試報(bào)告、測(cè)試人員通過(guò)冒煙測(cè)試

單元測(cè)試、接口/組件測(cè)試

• 輸入：完成需求文檔、設(shè)計(jì)文檔、完成代碼開(kāi)發(fā)
• 輸出：?jiǎn)卧獪y(cè)試用例、單元測(cè)試報(bào)告
• 人員：開(kāi)發(fā)人員
• 環(huán)境：開(kāi)發(fā)環(huán)境

冒煙測(cè)試

• 輸入：完成單元測(cè)試報(bào)告、冒煙測(cè)試用例
• 輸出：冒煙測(cè)試報(bào)告
• 人員：測(cè)試人員
• 環(huán)境：測(cè)試環(huán)境

集成測(cè)試

• 輸入：完成冒煙測(cè)試報(bào)告、集成測(cè)試用例
• 輸出：集成測(cè)試報(bào)
• 人員：測(cè)試人員
• 環(huán)境：測(cè)試環(huán)境

系統(tǒng)測(cè)試

• 輸入：集成測(cè)試報(bào)告、系統(tǒng)測(cè)試用例
• 輸出：系統(tǒng)測(cè)試報(bào)告
• 人員：測(cè)試人員
• 環(huán)境：測(cè)試環(huán)境

回歸測(cè)試

• 輸入：功能測(cè)試報(bào)告、回歸測(cè)試用例
• 輸出：回歸測(cè)試報(bào)告
• 人員：測(cè)試人員
• 環(huán)境：測(cè)試環(huán)境\

安全測(cè)試

• 輸入：功能測(cè)試報(bào)告、安全測(cè)試用例
• 輸出：安全測(cè)試報(bào)告
• 人員：測(cè)試人員
• 環(huán)境：測(cè)試環(huán)境

性能測(cè)試

• 輸入：功能測(cè)試報(bào)告、性能測(cè)試用例
• 輸出：性能測(cè)試報(bào)告
• 人員：測(cè)試人員
• 環(huán)境：測(cè)試環(huán)境

穩(wěn)定性測(cè)試

• 輸入：功能測(cè)試報(bào)告、性能測(cè)試用例
• 輸出：穩(wěn)定性測(cè)試報(bào)告（它往往和性能測(cè)試報(bào)告一起出）
• 人員：測(cè)試人員
• 環(huán)境：測(cè)試環(huán)境

UI測(cè)試

• 輸入：回歸測(cè)試報(bào)告、UI測(cè)試用例
• 輸出：UI測(cè)試報(bào)告
• 人員：測(cè)試人員
• 環(huán)境：測(cè)試環(huán)境

α測(cè)試

• 輸入：功能測(cè)試報(bào)告、α測(cè)試用例
• 輸出：α測(cè)試報(bào)告
• 人員：公司內(nèi)部人員
• 環(huán)境：測(cè)試環(huán)境

β測(cè)試

• 輸入：功能測(cè)試報(bào)告、性能測(cè)試報(bào)告
• 輸出：β測(cè)試報(bào)告
• 人員：客戶
• 環(huán)境：生產(chǎn)環(huán)境

白盒測(cè)試

白盒測(cè)試常用的測(cè)試方式有單元測(cè)試、組件測(cè)試、系統(tǒng)測(cè)試、性能測(cè)試、靜態(tài)代碼測(cè)試。這里說(shuō)性能測(cè)試和黑盒測(cè)試?yán)锩嫘阅芊绞接悬c(diǎn)不同這里強(qiáng)調(diào)的是一個(gè)大方法、大函數(shù)調(diào)用執(zhí)行1萬(wàn)次所消耗響應(yīng)時(shí)間。

在互聯(lián)網(wǎng)時(shí)代的白盒測(cè)試測(cè)試人員主要負(fù)責(zé)代碼質(zhì)量，代碼質(zhì)量包括白盒測(cè)試和黑盒測(cè)試?yán)锩娴姆枪δ軠y(cè)試（上面已經(jīng)介紹了黑盒測(cè)試?yán)锩娴姆枪δ軠y(cè)試這里就不在介紹了）如：靜態(tài)代碼測(cè)試（程序風(fēng)格、程序邏輯、代碼安全、程序建狀性）及開(kāi)發(fā)人員單元測(cè)試、組件測(cè)試代碼覆蓋率，配合開(kāi)發(fā)人員一起完成業(yè)務(wù)邏輯代碼自動(dòng)化，不能自動(dòng)化代碼分層自動(dòng)化。完善自動(dòng)化測(cè)試體系。
白盒分層自動(dòng)化可以分為靜態(tài)代碼掃描（PMD、JOCOCO、Profile）、單元測(cè)試(TestNG、junit)、集成測(cè)試、安全測(cè)試(Fortify+findbugs)、自動(dòng)化性能測(cè)試(jmeter)

• 開(kāi)發(fā)人員自測(cè)標(biāo)準(zhǔn)：完成需求文檔、設(shè)計(jì)文檔、完成代碼開(kāi)發(fā)
• 開(kāi)發(fā)、測(cè)試人員標(biāo)準(zhǔn)：完成靜態(tài)代碼測(cè)試規(guī)則編寫(xiě)、完成白盒測(cè)試、自動(dòng)化測(cè)試框架選型

單元測(cè)試、接口/組件測(cè)試

• 輸入：完成需求文檔、設(shè)計(jì)文檔、完成代碼開(kāi)發(fā)
• 輸出：?jiǎn)卧獪y(cè)試用例、單元測(cè)試報(bào)告
• 人員：開(kāi)發(fā)人員
• 環(huán)境：開(kāi)發(fā)環(huán)境

系統(tǒng)測(cè)試

• 輸入：?jiǎn)卧獪y(cè)試報(bào)告、系統(tǒng)測(cè)試用例
• 輸出：系統(tǒng)測(cè)試報(bào)告
• 人員：開(kāi)發(fā)人員、測(cè)試人員
• 環(huán)境：集成環(huán)境

靜態(tài)代碼測(cè)試

• 輸入：完成代碼調(diào)試
• 輸出：靜態(tài)代碼測(cè)試報(bào)告
• 人員：開(kāi)發(fā)人員、測(cè)試人員
• 環(huán)境：集成環(huán)境

灰盒測(cè)試

灰盒測(cè)試介于黑盒和白盒之間，它包括恢復(fù)測(cè)試、安全測(cè)試、性能測(cè)試，但是目前有很多持續(xù)集成中的自動(dòng)化都是采用灰盒測(cè)試用例

灰度測(cè)試

灰度測(cè)試：把生產(chǎn)環(huán)境用戶流量引到另外一個(gè)互不相干的環(huán)境驗(yàn)證系統(tǒng)功能，由A/B測(cè)試演變而成，此項(xiàng)測(cè)試常用于仿真測(cè)試、全鏈路壓力測(cè)試，現(xiàn)在好多互聯(lián)網(wǎng)公司架構(gòu)，業(yè)務(wù)改進(jìn)都向這方面設(shè)計(jì)，用來(lái)保證回歸上線用戶不丟失。在生產(chǎn)進(jìn)行灰度測(cè)試往往要網(wǎng)絡(luò)部門(mén)進(jìn)行網(wǎng)絡(luò)配合，特別適合業(yè)務(wù)重構(gòu)，或者業(yè)務(wù)遷移。常用測(cè)試工具如：TCPCOPY、Gor

• 測(cè)試、開(kāi)發(fā)、運(yùn)維人員測(cè)試標(biāo)準(zhǔn)：程序代碼編寫(xiě)完成，環(huán)境搭建完成。
• 輸入：完成功能測(cè)試，線下性能測(cè)試
• 輸出：灰度測(cè)試報(bào)告
• 人員：開(kāi)發(fā)人員、測(cè)試人員、運(yùn)維人員
• 環(huán)境：另一套生產(chǎn)環(huán)境或者測(cè)試環(huán)境

質(zhì)量交互

質(zhì)量交互它指的是軟件開(kāi)發(fā)、配置管理、構(gòu)建管理、持續(xù)集成、測(cè)試管理、環(huán)境管理、部署管理、數(shù)據(jù)度量和分析層層交互，它從以前的CI、CD、已經(jīng)逐步演變成DEVOPS如下圖：

質(zhì)量交互

DevOps是企業(yè)內(nèi)開(kāi)發(fā)、技術(shù)運(yùn)營(yíng)和質(zhì)量保障這三方面工作的融合，用于促進(jìn)開(kāi)發(fā)、技術(shù)運(yùn)營(yíng)和質(zhì)保部門(mén)之間的溝通、協(xié)作與整合。有研究顯示，在那些引入了DevOps概念的企業(yè)中，開(kāi)發(fā)與運(yùn)營(yíng)人員在設(shè)計(jì)、構(gòu)建、測(cè)試工作中共同在內(nèi)部應(yīng)用上進(jìn)行協(xié)作之后，可以將產(chǎn)品開(kāi)發(fā)的效率提升20%,強(qiáng)IT服務(wù)績(jī)效的團(tuán)隊(duì)比較差I(lǐng)T服務(wù)績(jī)效團(tuán)隊(duì)的部署頻率要快30倍，變更失敗率要低50%。如下圖

DevOps

配置管理

開(kāi)發(fā)人員從穩(wěn)定的最新版本中Checkout代碼在本地開(kāi)發(fā)新功能，在本地構(gòu)建（測(cè)試、代碼檢查）Check in在主干上編譯、等待持續(xù)集成結(jié)果。它可以帶來(lái)以下最佳實(shí)踐：

• 全面的配置管理，它包括項(xiàng)目代碼、配置文件、構(gòu)建腳本、數(shù)據(jù)庫(kù)腳本、部署腳本、基礎(chǔ)設(shè)施信息等，可以選擇SVN或者分布式管理系統(tǒng)Git。
• 有效的代碼提交注釋。清晰的提交功能說(shuō)明，提交者信息。
• 頻繁的提交代碼到主干，按照一定的規(guī)則頻繁提交變更，讓參與者及時(shí)獲知到項(xiàng)目的變更信息；提交的變更是原子性的，并且有信心不能影響到原有業(yè)務(wù)。
• 配置的分類(lèi)，何時(shí)將配置信息注入到應(yīng)用內(nèi)，構(gòu)建時(shí)，打包時(shí)，運(yùn)行時(shí)，推薦在運(yùn)行時(shí)加載配置信息。
• 依賴的管理，應(yīng)用的外部依賴文件的版本管理，例如jar文件，可以使用Maven、Ivy進(jìn)行管理。

構(gòu)建管理

構(gòu)建模塊間依賴采用二進(jìn)制構(gòu)建產(chǎn)物，并按照1-5-10（構(gòu)建運(yùn)行的時(shí)間，最多容忍10分鐘，一般是5分鐘，最快是1分鐘）法則構(gòu)建任務(wù)重Push改成Pull編譯結(jié)果推送到產(chǎn)品倉(cāng)庫(kù)管理。它的最佳實(shí)踐：

• 構(gòu)建、部署流程腳本化，讓構(gòu)建、部署過(guò)程成為一個(gè)可重復(fù)性并且可靠的行為。
• 使用相同的部署腳本向所有環(huán)境進(jìn)行部署，避免產(chǎn)生在開(kāi)發(fā)環(huán)境能運(yùn)行，測(cè)試環(huán)境無(wú)法運(yùn)行的情況。
• 部署過(guò)程是冪等的，無(wú)論目標(biāo)環(huán)境處于何種狀態(tài)，部署流程應(yīng)該總是令目標(biāo)環(huán)境達(dá)到正確的狀態(tài)。
• 部署系統(tǒng)的增量式演進(jìn)，以迭代的方式不斷完善部署過(guò)程。
• 任何時(shí)候可以重新構(gòu)建二進(jìn)制文件,容器部署到各各平臺(tái)，并且部署平臺(tái)的依賴都是一致的，使部署的應(yīng)用做到標(biāo)準(zhǔn)化

持續(xù)集成

開(kāi)發(fā)人員頻繁提交代碼到主干持續(xù)集成，并執(zhí)行自動(dòng)化構(gòu)建和測(cè)試并分級(jí)測(cè)試快速反饋，如果構(gòu)建失敗立即修復(fù)。它的最佳實(shí)踐：

• 構(gòu)建失敗后不要提交代碼新代碼，讓開(kāi)發(fā)人員能夠快速的找到失敗的原因。
• 提交前在本地運(yùn)行所有的測(cè)試用例，或者讓持續(xù)集成服務(wù)器（Jenkins）完成此事。本地測(cè)試通過(guò)后，可以增加提交的信心。
• 等到提交測(cè)試通過(guò)后再繼續(xù)工作，直接把問(wèn)題扼殺在持續(xù)集成中，而不是流露到外面人工檢查，10分鐘的等待測(cè)試通過(guò)時(shí)間是值得的。
• 時(shí)刻準(zhǔn)備著回滾到前一個(gè)版本，世界上沒(méi)有完美的事情，誰(shuí)也無(wú)法保證每次提交都是正確的，時(shí)刻保持警惕。
• 在回滾到上一個(gè)版本之前規(guī)定一個(gè)修復(fù)時(shí)間，約定一個(gè)修復(fù)問(wèn)題的時(shí)間，比如10分鐘，如果實(shí)在找不到原因，在回退到上一版。
• 不要注釋掉失敗的測(cè)試，保持一定量的測(cè)試覆蓋率，一般來(lái)說(shuō)50%。同時(shí)，可以允許有2%左右被注釋掉的測(cè)試用例（出于某種情況）。但每次構(gòu)建時(shí)，都需要掃描測(cè)試用例的覆蓋率。TestNG、junit、Sonar、Selenium工具是不錯(cuò)的選擇。
• 特別是測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，任何東西都是可測(cè)試的，要是不能測(cè)試直接重構(gòu)，直接導(dǎo)致自動(dòng)化構(gòu)建和測(cè)試，降低了人力成本。

測(cè)試管理

建立分級(jí)測(cè)試體系，從多個(gè)層次和多個(gè)驗(yàn)證角度實(shí)現(xiàn)質(zhì)量防護(hù)網(wǎng)如下圖：

分級(jí)測(cè)試模型

從上面圖分級(jí)測(cè)試模型根據(jù)測(cè)試運(yùn)行時(shí)間，不包括寫(xiě)測(cè)試用例時(shí)間它劃分為白盒分層自動(dòng)化、功能分層自動(dòng)化、非功能分層自動(dòng)化、線上仿真測(cè)試。

• 白盒分層自動(dòng)化主要以靜態(tài)代碼檢查為主，系統(tǒng)設(shè)計(jì)架構(gòu)度量可以用RFC，系統(tǒng)設(shè)計(jì)架構(gòu)度量達(dá)到類(lèi)高內(nèi)聚、低耦合LCOM4指標(biāo)衡量，代碼風(fēng)格可以用sonar加插件（PMD、JOCOCO、Profile）的方式檢查，死鎖和一致性檢查L(zhǎng)int4j插件，安全測(cè)試可以用Fortify+findbugs，單元測(cè)試可以用TESTNG或者是junit ,Smoke Test可以用從功能自動(dòng)化程序中抽取一些用例采用junittask去執(zhí)行。
• 功能分層自動(dòng)化主要完成功能自動(dòng)化涉及到功能自動(dòng)化工具如Testng、Selenium、Junit、Suite、Qunit
• 非功能分層自動(dòng)化主要是那些不能自動(dòng)化測(cè)試的用例，已經(jīng)需要長(zhǎng)時(shí)間運(yùn)行的性能測(cè)試及性能測(cè)試異常測(cè)試
• 線上仿真測(cè)試主要采用是灰度測(cè)試常用工具Tcpcopy、Gor

環(huán)境管理

基礎(chǔ)設(shè)施的信息管理是容易被忽視的地方。但是環(huán)境的不穩(wěn)定，造成部署，排錯(cuò)的成本成指數(shù)倍增長(zhǎng)。它的最佳實(shí)踐：

• 所有環(huán)境標(biāo)準(zhǔn)化，測(cè)試環(huán)境要和生產(chǎn)環(huán)境保持一致，開(kāi)發(fā)環(huán)境由于變更頻繁，可以有一定的差異，但是差異也是在可控范圍內(nèi)。
• 基礎(chǔ)設(shè)施的信息也要納入到版本控制，對(duì)待環(huán)境信息也要向?qū)Υa一樣，記錄變更信息，回溯歷史版本。
• 使用自動(dòng)化手段對(duì)所有環(huán)境進(jìn)行變更，避免手工操作帶來(lái)的未知環(huán)境差異。Puppet，Ansible配置管理工具能夠有效的解決此類(lèi)問(wèn)題。
• 虛擬化、容器化方式構(gòu)建應(yīng)用運(yùn)行環(huán)境，快速搭建環(huán)境，標(biāo)準(zhǔn)化環(huán)境。利用現(xiàn)在流行的Docker容器技術(shù)，將應(yīng)用所需所有內(nèi)容封裝起來(lái)，交付給下游，是一種非常高效，避免差異化的方式。

部署管理

部署對(duì)運(yùn)維來(lái)說(shuō)是一個(gè)體力活，怎么樣才能把一個(gè)體力活變成一個(gè)讓機(jī)器干的活，這樣才能釋放運(yùn)維人員。它的最佳實(shí)踐：

• 采用統(tǒng)一部署管理平臺(tái)
• 快速部署、回滾
• 灰度發(fā)布
• 運(yùn)維監(jiān)控和業(yè)務(wù)監(jiān)控

數(shù)據(jù)度量和分析

在DEVOPS里面數(shù)據(jù)度量和分析是重要的部分，要是沒(méi)有這些數(shù)據(jù)不能體現(xiàn)效率、質(zhì)量是否提高。這些數(shù)據(jù)通常包括構(gòu)建數(shù)據(jù)、線下質(zhì)量驗(yàn)證數(shù)據(jù)、及線上質(zhì)量數(shù)據(jù)。

質(zhì)量監(jiān)控和質(zhì)量運(yùn)維

隨著業(yè)務(wù)發(fā)展，互聯(lián)網(wǎng)公司更應(yīng)該重視線上質(zhì)量，對(duì)比傳統(tǒng)的軟件開(kāi)發(fā)，互聯(lián)網(wǎng)公司更加沒(méi)有辦法確定需求價(jià)值，可以說(shuō)是在不斷的嘗試過(guò)程，線上質(zhì)量監(jiān)控分析和線上質(zhì)量分析運(yùn)維越來(lái)越被各大互聯(lián)網(wǎng)公司重視。線上質(zhì)量可分為線上質(zhì)量監(jiān)控和線上質(zhì)量運(yùn)維，如下圖：

質(zhì)量監(jiān)控和質(zhì)量運(yùn)維圖

質(zhì)量監(jiān)控分為性能質(zhì)量監(jiān)控、功能質(zhì)量監(jiān)控、安全質(zhì)量監(jiān)控

性能質(zhì)量監(jiān)控

基礎(chǔ)監(jiān)控

cpu/cpuload/mem/jvm mem/iowait/diskbusy/net/spinlock/fullgc/ spinlock(使用自旋鎖(spinlock)來(lái)實(shí)現(xiàn)進(jìn)程調(diào)度的問(wèn)題)

應(yīng)用監(jiān)控

Latency/hit ratio/recursive call/queuesize/thread status/stack/Latency(它表示完全執(zhí)行一個(gè)指令所需的時(shí)鐘周期)

業(yè)務(wù)監(jiān)控

Pv/uv/transaction/
例如：下面是一個(gè)TPS統(tǒng)計(jì)結(jié)果如下圖

TPS統(tǒng)計(jì)結(jié)果圖

功能質(zhì)量監(jiān)控

1、建立線上撥測(cè)功能
2、統(tǒng)計(jì)線上用戶失敗率進(jìn)行分析優(yōu)化如：請(qǐng)求超時(shí)，是業(yè)務(wù)超時(shí)，還是系統(tǒng)超時(shí)如下圖：

線上用戶失敗監(jiān)控

安全質(zhì)量監(jiān)控

線上安全質(zhì)量監(jiān)控可以采用WAF防火墻。例如NGINX中的ngx_lua_waf支持 WAF 防護(hù)功能。
對(duì)上面三大部分只是說(shuō)的簡(jiǎn)單的監(jiān)控，并沒(méi)有深化，對(duì)上面三大監(jiān)控可以進(jìn)行持續(xù)優(yōu)化，關(guān)于質(zhì)量運(yùn)維提到的部分還可以跟蹤完善、優(yōu)化，線上質(zhì)量運(yùn)維空間還很大。

附錄

名詞說(shuō)明
黑盒測(cè)試：已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測(cè)試證明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。
白盒測(cè)試：已知產(chǎn)品的內(nèi)部工作過(guò)程，可以通過(guò)測(cè)試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過(guò)檢查
灰盒測(cè)試：是介于白盒測(cè)試與黑盒測(cè)試之間的，可以這樣理解，灰盒測(cè)試關(guān)注輸出對(duì)于輸入的正確性，同時(shí)也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細(xì)、完整，只是通過(guò)一些表征性的現(xiàn)象、事件、標(biāo)志來(lái)判斷內(nèi)部的運(yùn)行狀態(tài)，有時(shí)候輸出是正確的，但內(nèi)部其實(shí)已經(jīng)錯(cuò)誤了，這種情況非常多，如果每次都通過(guò)白盒測(cè)試來(lái)操作，效率會(huì)很低，因此需要采取這樣的一種灰盒的方法。
恢復(fù)測(cè)試：主要檢查系統(tǒng)的容錯(cuò)能力。當(dāng)系統(tǒng)出錯(cuò)時(shí)，能否在指定時(shí)間間隔內(nèi)修正錯(cuò)誤并重新啟動(dòng)系統(tǒng)。恢復(fù)測(cè)試首先要采用各種辦法強(qiáng)迫系統(tǒng)失敗，然后驗(yàn)證系統(tǒng)是否能盡快恢復(fù)。對(duì)于自動(dòng)恢復(fù)需驗(yàn)證重新初始化（reinitialization）、檢查點(diǎn)(checkpointingmechanisms)、數(shù)據(jù)恢復(fù)(datarecovery)和重新啟動(dòng)(restart)等機(jī)制的正確性；對(duì)于人工干預(yù)的恢復(fù)系統(tǒng)，還需估測(cè)平均修復(fù)時(shí)間，確定其是否在可接受的范圍內(nèi)
互聯(lián)網(wǎng)的特性：我們可以總結(jié)為四個(gè)字多、快、好、省，1、多就是指用戶多，信息量多和服務(wù)器也多，在這個(gè)龐大的消費(fèi)群體作用下，有著巨大的利潤(rùn)市場(chǎng)。2、快是指獲取信息和傳遞信息的速度快，這無(wú)疑給信息交流和商貿(mào)活動(dòng)提供了快速的通道。3、好是指在互聯(lián)網(wǎng)上我們可以根據(jù)我們的需要，選擇我們個(gè)性的東西，不需要因?yàn)閯e的因素而耽擱。4、省是指省時(shí)、省力、省財(cái)、省物、省心、省神，還可以節(jié)省很多很多的費(fèi)用
DevOps****的技術(shù)棧與工具鏈

Everything is Code，DevOps也同樣要通過(guò)技術(shù)工具鏈完成持續(xù)集成、持續(xù)交付、用戶反饋和系統(tǒng)優(yōu)化的整合。Elasticbox整理了60+開(kāi)源工具與分類(lèi)，其中包括版本控制&協(xié)作開(kāi)發(fā)工具、自動(dòng)化構(gòu)建和測(cè)試工具、持續(xù)集成&交付工具、部署工具、維護(hù)工具、監(jiān)控，警告&分析工具等等，
補(bǔ)充了一些國(guó)內(nèi)的服務(wù)，可以讓你更好的執(zhí)行實(shí)施DevOps工作流。

• 版本控制&協(xié)作開(kāi)發(fā)：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar
• 自動(dòng)化構(gòu)建和測(cè)試:Apache Ant、Maven、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit、Pipeline
• 持續(xù)集成&交付:Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go
• 容器平臺(tái): Docker、Rocket、Ubuntu（LXC）、第三方廠商如（AWS/阿里云）
• 配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible
• 微服務(wù)平臺(tái)：OpenShift、Cloud Foundry、Kubernetes、Mesosphere
  ·服務(wù)開(kāi)通：Puppet、Docker Swarm、Vagrant、Powershell、OpenStack Heat
• 日志管理：Logstash、CollectD、StatsD
• 監(jiān)控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana
  https://zhuanlan.zhihu.com/p/22638204?refer=ciweekly 工具部分內(nèi)容摘自這個(gè)鏈接
  DEVOPS參考《黎嘉豪：持續(xù)交付：新產(chǎn)品的成長(zhǎng)思維.pdf》
  參考url：http://www.d1net.com/cloud/news/381046.html http://www.searchsoa.com.cn/showcontent_83139.html
  https://testerhome.com/topics/6911