摘自http://www.51testing.com/html/23/n-3720823.html

質(zhì)量綜述

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

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

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

軟件質(zhì)量綜述圖

質(zhì)量驗證

軟件質(zhì)量驗證，具體的說就是軟件測試绑洛，它分為黑盒測試救斑，灰盒測試，白盒測試真屯，灰度測試脸候。

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

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

隨著計算機科學專業(yè)在大學完善凉馆，越來越多的科班生都參與到測試行業(yè)，在互聯(lián)網(wǎng)公司隨著開發(fā)人員慢慢滲透到測試亡资，自動化測試澜共、白盒測試和灰度測試越來越盛行。流行上面主要原因是分層自動化锥腻，測試需求減少嗦董，測試人力資源減少越來越專業(yè)化，測試瘦黑、開發(fā)比例越來越低京革，讓機器干活，逐漸釋放人力幸斥，節(jié)約成本匹摇。下面逐漸開始介紹質(zhì)量驗證，質(zhì)量驗證包括黑盒測試甲葬、白盒測試廊勃、灰盒測試、灰度測試经窖。

黑盒測試

黑盒測試分功能測試和非功能測試坡垫。

常用的功能測試有單元測試、接口/組件測試画侣、冒煙測試冰悠、集成測試、系統(tǒng)測試棉钧、回歸測試屿脐、UI測試涕蚤、α測試、β測試的诵，非功能測試有性能測試万栅、穩(wěn)定性測試、安全測試西疤、恢復(fù)測試這些測試都是一個項目必須要有的方式烦粒，但是在時間和人力允許的情況下可以有交叉測試、兼容性測試代赁、可用性測試扰她、比較性測試、探索性測試芭碍。然后使用分層自動化測試來提高上面各種測試效率徒役。

黑盒分層自動化可以分為單元測試自動化、集成接口自動化窖壕、UI層自動化忧勿，單元測試采用框架如java的Junit、testNG瞻讽，C#的NUnit鸳吸，python的unittest、pytest等速勇，集成接口自動化框架如SoapUI（改名叫Ready!API）晌砾、Postman等,UI層自動化如QTP，Robot Framework烦磁、watir养匈、selenium等，具體怎么做分層自動化个初，具體需求根據(jù)具體項目去做乖寒。

開發(fā)人員自測標準：完成需求文檔、設(shè)計文檔院溺、完成代碼開發(fā)

提交測試人員標準：開發(fā)人員輸出單元測試楣嘁，接口/組件測試報告、測試人員通過冒煙測試

單元測試珍逸、接口/組件測試

輸入：完成需求文檔逐虚、設(shè)計文檔、完成代碼開發(fā)

輸出：單元測試用例谆膳、單元測試報告

人員：開發(fā)人員

環(huán)境：開發(fā)環(huán)境

冒煙測試

輸入：完成單元測試報告叭爱、冒煙測試用例

輸出：冒煙測試報告

人員：測試人員

環(huán)境：測試環(huán)境

集成測試

輸入：完成冒煙測試報告、集成測試用例

輸出：集成測試報

人員：測試人員

環(huán)境：測試環(huán)境

系統(tǒng)測試

輸入：集成測試報告漱病、系統(tǒng)測試用例

輸出：系統(tǒng)測試報告

人員：測試人員

環(huán)境：測試環(huán)境

回歸測試

輸入：功能測試報告买雾、回歸測試用例

輸出：回歸測試報告

人員：測試人員

環(huán)境：測試環(huán)境\

安全測試

輸入：功能測試報告把曼、安全測試用例

輸出：安全測試報告

人員：測試人員

環(huán)境：測試環(huán)境

性能測試

輸入：功能測試報告、性能測試用例

輸出：性能測試報告

人員：測試人員

環(huán)境：測試環(huán)境

穩(wěn)定性測試

輸入：功能測試報告漓穿、性能測試用例

輸出：穩(wěn)定性測試報告（它往往和性能測試報告一起出）

人員：測試人員

環(huán)境：測試環(huán)境

UI測試

輸入：回歸測試報告嗤军、UI測試用例

輸出：UI測試報告

人員：測試人員

環(huán)境：測試環(huán)境

α測試

輸入：功能測試報告、α測試用例

輸出：α測試報告

人員：公司內(nèi)部人員

環(huán)境：測試環(huán)境

β測試

輸入：功能測試報告晃危、性能測試報告

輸出：β測試報告

人員：客戶

環(huán)境：生產(chǎn)環(huán)境

白盒測試

白盒測試常用的測試方式有單元測試叙赚、組件測試、系統(tǒng)測試僚饭、性能測試震叮、靜態(tài)代碼測試。這里說性能測試和黑盒測試里面性能方式有點不同這里強調(diào)的是一個大方法鳍鸵、大函數(shù)調(diào)用執(zhí)行1萬次所消耗響應(yīng)時間苇瓣。

在互聯(lián)網(wǎng)時代的白盒測試測試人員主要負責代碼質(zhì)量，代碼質(zhì)量包括白盒測試和黑盒測試里面的非功能測試（上面已經(jīng)介紹了黑盒測試里面的非功能測試這里就不在介紹了）如：靜態(tài)代碼測試（程序風格权纤、程序邏輯钓简、代碼安全、程序建狀性）及開發(fā)人員單元測試汹想、組件測試代碼覆蓋率，配合開發(fā)人員一起完成業(yè)務(wù)邏輯代碼自動化撤蚊，不能自動化代碼分層自動化古掏。完善自動化測試體系。

白盒分層自動化可以分為靜態(tài)代碼掃描（PMD侦啸、JOCOCO槽唾、Profile）、單元測試(TestNG光涂、junit)庞萍、集成測試、安全測試(Fortify+findbugs)忘闻、自動化性能測試(jmeter)

開發(fā)人員自測標準：完成需求文檔钝计、設(shè)計文檔、完成代碼開發(fā)

開發(fā)齐佳、測試人員標準：完成靜態(tài)代碼測試規(guī)則編寫私恬、完成白盒測試、自動化測試框架選型

單元測試炼吴、接口/組件測試

輸入：完成需求文檔本鸣、設(shè)計文檔、完成代碼開發(fā)

輸出：單元測試用例硅蹦、單元測試報告

人員：開發(fā)人員

環(huán)境：開發(fā)環(huán)境

系統(tǒng)測試

輸入：單元測試報告抓艳、系統(tǒng)測試用例

輸出：系統(tǒng)測試報告

人員：開發(fā)人員、測試人員

環(huán)境：集成環(huán)境

靜態(tài)代碼測試

輸入：完成代碼調(diào)試

輸出：靜態(tài)代碼測試報告

人員：開發(fā)人員岖免、測試人員

環(huán)境：集成環(huán)境

灰盒測試

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

灰度測試

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

測試、開發(fā)青伤、運維人員測試標準：程序代碼編寫完成督怜，環(huán)境搭建完成。

輸入：完成功能測試狠角，線下性能測試

輸出：灰度測試報告

人員：開發(fā)人員号杠、測試人員、運維人員

環(huán)境：另一套生產(chǎn)環(huán)境或者測試環(huán)境

質(zhì)量交互

質(zhì)量交互它指的是軟件開發(fā)丰歌、配置管理姨蟋、構(gòu)建管理、持續(xù)集成立帖、測試管理眼溶、環(huán)境管理、部署管理晓勇、數(shù)據(jù)度量和分析層層交互堂飞，它從以前的CI、CD宵蕉、已經(jīng)逐步演變成DEVOPS如下圖：

質(zhì)量交互

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

DevOps

配置管理

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

全面的配置管理坑雅，它包括項目代碼、配置文件衬横、構(gòu)建腳本裹粤、數(shù)據(jù)庫腳本、部署腳本蜂林、基礎(chǔ)設(shè)施信息等遥诉，可以選擇SVN或者分布式管理系統(tǒng)Git。

有效的代碼提交注釋噪叙。清晰的提交功能說明矮锈，提交者信息。

頻繁的提交代碼到主干构眯，按照一定的規(guī)則頻繁提交變更愕难，讓參與者及時獲知到項目的變更信息；提交的變更是原子性的惫霸，并且有信心不能影響到原有業(yè)務(wù)。

配置的分類葱弟，何時將配置信息注入到應(yīng)用內(nèi)壹店，構(gòu)建時，打包時芝加，運行時硅卢，推薦在運行時加載配置信息。

依賴的管理藏杖，應(yīng)用的外部依賴文件的版本管理将塑，例如jar文件，可以使用Maven蝌麸、Ivy進行管理点寥。

構(gòu)建管理

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

構(gòu)建戚长、部署流程腳本化盗冷，讓構(gòu)建、部署過程成為一個可重復(fù)性并且可靠的行為同廉。

使用相同的部署腳本向所有環(huán)境進行部署仪糖，避免產(chǎn)生在開發(fā)環(huán)境能運行，測試環(huán)境無法運行的情況迫肖。

部署過程是冪等的锅劝，無論目標環(huán)境處于何種狀態(tài)，部署流程應(yīng)該總是令目標環(huán)境達到正確的狀態(tài)咒程。

部署系統(tǒng)的增量式演進鸠天，以迭代的方式不斷完善部署過程。

任何時候可以重新構(gòu)建二進制文件,容器部署到各各平臺帐姻，并且部署平臺的依賴都是一致的稠集，使部署的應(yīng)用做到標準化

持續(xù)集成

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

構(gòu)建失敗后不要提交代碼新代碼，讓開發(fā)人員能夠快速的找到失敗的原因呢铆。

提交前在本地運行所有的測試用例晦鞋，或者讓持續(xù)集成服務(wù)器（Jenkins）完成此事。本地測試通過后棺克，可以增加提交的信心悠垛。

等到提交測試通過后再繼續(xù)工作，直接把問題扼殺在持續(xù)集成中娜谊，而不是流露到外面人工檢查确买，10分鐘的等待測試通過時間是值得的。

時刻準備著回滾到前一個版本纱皆，世界上沒有完美的事情湾趾，誰也無法保證每次提交都是正確的，時刻保持警惕派草。

在回滾到上一個版本之前規(guī)定一個修復(fù)時間搀缠，約定一個修復(fù)問題的時間，比如10分鐘近迁，如果實在找不到原因艺普，在回退到上一版。

不要注釋掉失敗的測試，保持一定量的測試覆蓋率衷敌，一般來說50%勿侯。同時，可以允許有2%左右被注釋掉的測試用例（出于某種情況）缴罗。但每次構(gòu)建時助琐，都需要掃描測試用例的覆蓋率。TestNG面氓、junit兵钮、Sonar、Selenium工具是不錯的選擇舌界。

特別是測試驅(qū)動開發(fā)掘譬，任何東西都是可測試的，要是不能測試直接重構(gòu)呻拌，直接導(dǎo)致自動化構(gòu)建和測試葱轩，降低了人力成本。

測試管理

建立分級測試體系藐握，從多個層次和多個驗證角度實現(xiàn)質(zhì)量防護網(wǎng)如下圖：

分級測試模型

從上面圖分級測試模型根據(jù)測試運行時間靴拱，不包括寫測試用例時間它劃分為白盒分層自動化、功能分層自動化猾普、非功能分層自動化袜炕、線上仿真測試。

白盒分層自動化主要以靜態(tài)代碼檢查為主初家，系統(tǒng)設(shè)計架構(gòu)度量可以用RFC偎窘，系統(tǒng)設(shè)計架構(gòu)度量達到類高內(nèi)聚、低耦合LCOM4指標衡量溜在，代碼風格可以用sonar加插件（PMD陌知、JOCOCO、Profile）的方式檢查掖肋，死鎖和一致性檢查Lint4j插件纵诞，安全測試可以用Fortify+findbugs，單元測試可以用TESTNG或者是junit ,Smoke Test可以用從功能自動化程序中抽取一些用例采用junittask去執(zhí)行培遵。

功能分層自動化主要完成功能自動化涉及到功能自動化工具如Testng、Selenium登刺、Junit籽腕、Suite、Qunit

非功能分層自動化主要是那些不能自動化測試的用例纸俭，已經(jīng)需要長時間運行的性能測試及性能測試異常測試

線上仿真測試主要采用是灰度測試常用工具Tcpcopy皇耗、Gor

環(huán)境管理

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

所有環(huán)境標準化，測試環(huán)境要和生產(chǎn)環(huán)境保持一致呜袁，開發(fā)環(huán)境由于變更頻繁敌买，可以有一定的差異，但是差異也是在可控范圍內(nèi)阶界。

基礎(chǔ)設(shè)施的信息也要納入到版本控制虹钮，對待環(huán)境信息也要向?qū)Υa一樣，記錄變更信息膘融，回溯歷史版本芙粱。

使用自動化手段對所有環(huán)境進行變更，避免手工操作帶來的未知環(huán)境差異氧映。Puppet春畔，Ansible配置管理工具能夠有效的解決此類問題。

虛擬化岛都、容器化方式構(gòu)建應(yīng)用運行環(huán)境律姨，快速搭建環(huán)境，標準化環(huán)境疗绣。利用現(xiàn)在流行的Docker容器技術(shù)线召，將應(yīng)用所需所有內(nèi)容封裝起來，交付給下游多矮，是一種非常高效缓淹，避免差異化的方式。

部署管理

部署對運維來說是一個體力活塔逃，怎么樣才能把一個體力活變成一個讓機器干的活讯壶，這樣才能釋放運維人員。它的最佳實踐：

采用統(tǒng)一部署管理平臺

快速部署湾盗、回滾

灰度發(fā)布

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

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

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

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

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

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

質(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)來實現(xiàn)進程調(diào)度的問題)

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

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

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

Pv/uv/transaction/

例如：下面是一個TPS統(tǒng)計結(jié)果如下圖

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

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

1悔醋、建立線上撥測功能

2摩窃、統(tǒng)計線上用戶失敗率進行分析優(yōu)化如：請求超時，是業(yè)務(wù)超時篙顺，還是系統(tǒng)超時如下圖：

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

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

線上安全質(zhì)量監(jiān)控可以采用WAF防火墻偶芍。例如NGINX中的ngx_lua_waf支持 WAF 防護功能。

對上面三大部分只是說的簡單的監(jiān)控德玫，并沒有深化匪蟀，對上面三大監(jiān)控可以進行持續(xù)優(yōu)化，關(guān)于質(zhì)量運維提到的部分還可以跟蹤完善宰僧、優(yōu)化材彪，線上質(zhì)量運維空間還很大。

附錄

名詞說明

黑盒測試：已知產(chǎn)品的功能設(shè)計規(guī)格琴儿，可以進行測試證明每個實現(xiàn)了的功能是否符合要求段化。

白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格要求造成，所有內(nèi)部成分是否以經(jīng)過檢查

灰盒測試：是介于白盒測試與黑盒測試之間的显熏，可以這樣理解，灰盒測試關(guān)注輸出對于輸入的正確性晒屎，同時也關(guān)注內(nèi)部表現(xiàn)喘蟆，但這種關(guān)注不象白盒那樣詳細、完整鼓鲁，只是通過一些表征性的現(xiàn)象蕴轨、事件、標志來判斷內(nèi)部的運行狀態(tài)骇吭，有時候輸出是正確的橙弱，但內(nèi)部其實已經(jīng)錯誤了，這種情況非常多燥狰，如果每次都通過白盒測試來操作棘脐，效率會很低，因此需要采取這樣的一種灰盒的方法龙致。

恢復(fù)測試：主要檢查系統(tǒng)的容錯能力荆残。當系統(tǒng)出錯時，能否在指定時間間隔內(nèi)修正錯誤并重新啟動系統(tǒng)净当。恢復(fù)測試首先要采用各種辦法強迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快恢復(fù)像啼。對于自動恢復(fù)需驗證重新初始化（reinitialization）俘闯、檢查點(checkpointingmechanisms)、數(shù)據(jù)恢復(fù)(datarecovery)和重新啟動(restart)等機制的正確性忽冻；對于人工干預(yù)的恢復(fù)系統(tǒng)真朗，還需估測平均修復(fù)時間，確定其是否在可接受的范圍內(nèi)

互聯(lián)網(wǎng)的特性：我們可以總結(jié)為四個字多僧诚、快遮婶、好、省湖笨，1旗扑、多就是指用戶多，信息量多和服務(wù)器也多慈省，在這個龐大的消費群體作用下臀防，有著巨大的利潤市場。2边败、快是指獲取信息和傳遞信息的速度快袱衷，這無疑給信息交流和商貿(mào)活動提供了快速的通道。3笑窜、好是指在互聯(lián)網(wǎng)上我們可以根據(jù)我們的需要致燥，選擇我們個性的東西，不需要因為別的因素而耽擱排截。4嫌蚤、省是指省時、省力匾寝、省財搬葬、省物、省心艳悔、省神急凰，還可以節(jié)省很多很多的費用