軟件測試教程 第五節(jié) 敏捷篇

我們在之前介紹了測試用例的各種設(shè)計(jì)方法抓于。但是存在的一個(gè)問題是：越來越多的公司開始使用敏捷的開發(fā)模式，輕文檔甚至無文檔，需求不明確创南，測試時(shí)間越來越短涩嚣。這對我們的測試設(shè)計(jì)帶來了很大的挑戰(zhàn)崇众。

在這時(shí)我們需要更多的測試手段來進(jìn)行測試掂僵。

在這里我們將回答以下問題

• 探索性測試

• code review

• 代碼靜態(tài)分析

• CI/CD

探索性測試

留給測試的時(shí)間越來越短，我們沒有大量的專屬時(shí)間來設(shè)計(jì)用例顷歌，然后再去執(zhí)行了锰蓬。這時(shí)候我們需要邊設(shè)計(jì)邊測試，這就是探索性測試眯漩。

在日常生活中芹扭，我們其實(shí)經(jīng)常會(huì)進(jìn)行探索性測試：例如我們買了一部新手機(jī)，試試拍照怎么樣

什么是探索性測試（ET）

? 在概念上說赦抖，探索性測試是一種測試風(fēng)格舱卡，而不是某一種具體的測試方法（等價(jià)類測試/邊界測試等），它強(qiáng)調(diào)系統(tǒng)軟件學(xué)習(xí)队萤，設(shè)計(jì)測試用例以及測試執(zhí)行同時(shí)進(jìn)行,他適用于要求在短時(shí)間內(nèi)以及測試需求頻繁變更下尋找出重大缺陷的情況轮锥。

1、探索性測試是手工測試
2要尔、探索性測試仍然需要寫文檔舍杜，但是在測試執(zhí)行中寫
3、探索性測試的缺點(diǎn)是可能沒有重點(diǎn)赵辕，無法保證測試覆蓋率蝴簇，無法度量質(zhì)量
4、探索性測試是有指導(dǎo)方法的自由測試
5匆帚、在項(xiàng)目中推薦用例測試和探索性測試同時(shí)進(jìn)行熬词。
6、測試的五個(gè)問題：漫無目的吸重、重復(fù)互拾、暫時(shí)性、單調(diào)性嚎幸、健忘

探索性測試的來源

? 探索性測試是由測試專家Cem Kaner博士在1983年的時(shí)候提出颜矿。測試專家James A. Whittaker曾經(jīng)是Cem Kaner佛羅里達(dá)工學(xué)院的同事，后來擔(dān)任微軟測試架構(gòu)師以及Google總監(jiān)嫉晶，基于在這些公司的工作經(jīng)驗(yàn)骑疆，他撰寫了《Exploratory Software Testing》一書，進(jìn)一步拓展了探索性測試的概念和方法替废。

探索性測試的指導(dǎo)思想

探索性測試跟傳統(tǒng)的測試方法有很大的不同箍铭，在過去一般都是按照先編寫完整的測試用例以及計(jì)劃，然后再進(jìn)行測試執(zhí)行椎镣，最后再進(jìn)行測試結(jié)果分析诈火。與這種“先設(shè)計(jì)后測試”的思路有巨大的不同，在探索性測試中状答，軟件學(xué)習(xí)冷守，軟件用例設(shè)計(jì)以及軟件測試執(zhí)行同時(shí)進(jìn)行刀崖，這個(gè)適用于要求在短時(shí)間內(nèi)或者在測試需要頻繁變更下快速發(fā)現(xiàn)重大缺陷的情況。

探索性軟件測試的三個(gè)目標(biāo)：

1拍摇、理解應(yīng)用程序的工作邏輯和原理亮钦，接口，以及實(shí)現(xiàn)了哪些功能

2充活、盡量了解熟悉軟件的所有功能

3蜂莉、尋找缺陷

這三個(gè)目標(biāo)說明了我們的測試不是漫無目的的。所有的測試都應(yīng)該圍繞著軟件功能來進(jìn)行堪唐，而優(yōu)先保證的是要實(shí)現(xiàn)的業(yè)務(wù)是正確的巡语。

探索性測試方法

旅行者的漫游探索性測試方法

我們可以將軟件的測試比做是去一個(gè)城市的旅游。那么我們?nèi)绾慰焖俚娜サ轿覀兿肴サ牡胤侥鼗床ぃ恳粋€(gè)辦法就是我們對這個(gè)城市很熟悉男公。另外一個(gè)辦法就是找一個(gè)導(dǎo)游或者一份地圖，用來指導(dǎo)我們?nèi)ピ谶@個(gè)城市旅游合陵。

對于軟件測試來說枢赔，我們同樣需要對被測軟件很熟悉，同時(shí)也需要一份測試地圖或者測試指南拥知，來幫助我們更好的探索性測試踏拜。

拿到地圖后，我們可以根據(jù)地圖將城市按照功能分為各種區(qū)域低剔，比如：商業(yè)區(qū)速梗，歷史區(qū)，娛樂區(qū)襟齿，旅游區(qū)姻锁，旅館區(qū)，破舊區(qū)等猜欺。而每個(gè)區(qū)域?qū)?yīng)軟件相應(yīng)的功能位隶。比如：

商業(yè)區(qū)：是工作得以完成的地方，對于旅游者來說沒什么意思开皿。對應(yīng)軟件包裝上面的對應(yīng)特性涧黄，類似我們的需求。

歷史區(qū)：上一個(gè)版本遺留下來的代碼赋荆、問題或則曾經(jīng)出現(xiàn)多次bug的功能或者特性笋妥。

娛樂區(qū)：對應(yīng)軟件的輔助特性和功能，可以做完補(bǔ)充測試糠睡。

旅游區(qū)：旅游者聚集的地方挽鞠，目的是為了到此一游。對應(yīng)產(chǎn)品的某些特性和功能可以吸引新的用戶狈孔，然而老用戶不在使用它們信认。

旅館區(qū)：旅游者的休息之處，所以旅館區(qū)測試時(shí)指軟件測試人員放過那些主要和最受歡迎的功能均抽，而去測試在測試計(jì)劃中較少描述的次要及輔助功能嫁赏。

破舊區(qū)：對應(yīng)軟件的歷史穩(wěn)定的代碼，一般很少人去接觸

一油挥、商業(yè)區(qū)測試方法：

指南測試法：城市的旅游手冊通常都?xì)w納出一些實(shí)現(xiàn)選好的景點(diǎn)潦蝇，測試這些區(qū)域是非常重要的。要求測試人員通過閱讀用戶手冊并驗(yàn)證遵守手冊的建議執(zhí)行操作深寥。如果是幫助手冊攘乒，請以完全不了解系統(tǒng)視角嚴(yán)格按照其使用進(jìn)行操作。

案例：
1惋鹅、手機(jī)的用戶操作手冊測試
2则酝、用戶注冊時(shí)的完整流程

賣點(diǎn)測試法：發(fā)現(xiàn)軟件最吸引人的這些特性功能，鎖定測試范圍闰集。此方法是鼓勵(lì)測試人員觀看銷售給客戶演示的Demo沽讹，理解銷售的角度哪些功能對客戶來說是最大的賣點(diǎn)，他們未必就是核心功能武鲁，但值得測試人員把它們當(dāng)核心功能來對待爽雄。同時(shí)，也許刁鉆的客戶會(huì)提出各種質(zhì)疑沐鼠，這些質(zhì)疑和稀奇古怪的問題也可以納入測試人員的設(shè)計(jì)中挚瘟。

案例：
1、nubia手機(jī)的賣點(diǎn)是拍星星饲梭，怎么拍乘盖？怎么測試？

地標(biāo)測試法： 在旅游的時(shí)候排拷，如果我們設(shè)計(jì)了要到訪的地方侧漓，通常會(huì)在地圖上插上旗子，這就是地標(biāo)监氢。但是沒有人規(guī)定我們應(yīng)該按照何種順序去到訪這些地標(biāo)布蔗。不同的測試人員可能會(huì)選擇不同的順序，有經(jīng)驗(yàn)的測試人員會(huì)基于對軟件產(chǎn)品架構(gòu)和技術(shù)層面的理解浪腐，采取一些古怪的路徑但更可能發(fā)現(xiàn)缺陷纵揍。

案例：
1、用戶注冊時(shí)有注冊信息议街、激活泽谨、完善信息、登錄等，我們可以在注冊后就直接去登錄

極限測試法：一個(gè)學(xué)者不斷的質(zhì)疑導(dǎo)游的各種說法吧雹。向軟件提出難以回答的問題骨杂，比如最大可以發(fā)揮到什么程度，承受多少用戶雄卷，承載多少數(shù)據(jù)搓蚪。那個(gè)特性或功能會(huì)把軟件逼到極限運(yùn)作，哪些輸入和數(shù)據(jù)會(huì)消耗軟件最多的計(jì)算能力丁鹉？哪些輸入可能繞過它的錯(cuò)誤檢測妒潭？

案例：
1、用戶注冊時(shí)將所有的注冊信息都輸入到最大值揣钦，然后注冊雳灾，最大值的email地址能否成功注冊并登錄？
2冯凹、手機(jī)空間滿進(jìn)行拍照

快遞測試法：快遞運(yùn)送的貨物谎亩，就好比軟件里的數(shù)據(jù)，結(jié)果不同的地點(diǎn)轉(zhuǎn)接谈竿，拆包裝包最終到底目的地团驱。主要關(guān)注關(guān)鍵數(shù)據(jù)流的走向，比如：輸入一個(gè)數(shù)據(jù)后空凸，最后該數(shù)據(jù)會(huì)去哪里

案例：
1嚎花、用戶注冊時(shí)填寫的姓名、email等最后在哪里可以看到呀洲？個(gè)人信息紊选？兩者是否一致？
2道逗、用戶注冊完善的信息在哪里可以看到兵罢？

深夜測試法：城市燈火闌珊會(huì)在午夜過后逐漸安靜下來，商場店鋪紛紛打烊滓窍。但是軟件不應(yīng)該停止工作卖词，軟件測試人員有時(shí)應(yīng)該刻意的關(guān)注在冷門時(shí)間段軟件所做的附屬工作，比如數(shù)據(jù)備份歸檔吏夯、維護(hù)監(jiān)控任務(wù)的運(yùn)行等等此蜈。

遍歷測試法：選定一個(gè)目標(biāo)（比如：所有菜單項(xiàng)、所有錯(cuò)誤框）噪生，然后用最短路徑來訪問這些目標(biāo)對象裆赵，從而遍歷完所有的路徑點(diǎn)；

案例：
1跺嗽、檢查用戶填寫注冊信息時(shí)战授，檢查所有的輸入錯(cuò)誤提示页藻，包括輸入不符合要求，兩個(gè)密碼不一致植兰，驗(yàn)證碼不正確份帐、沒有輸入等各種提示語

二、歷史區(qū)類型：
惡鄰測試法：在測試的過程中钉跷，當(dāng)發(fā)現(xiàn)某一段代碼的bug很多的時(shí)候弥鹦，我們可以專門針對這段代碼進(jìn)行遍歷測試肚逸，通過這樣的方法很容易發(fā)現(xiàn)改動(dòng)引發(fā)的bug爷辙。

類似于錯(cuò)誤猜測法

博物館測試法：找到那些遺留和很長時(shí)間沒有被翻動(dòng)的老代碼，看看在新的環(huán)境是否可以運(yùn)行朦促，比如：某一個(gè)腳本可能就直接失效了膝晾。

回歸測試的重要性

上一版本測試法：對先前版本的更新，運(yùn)行上一個(gè)版本所有的分支和測試用例务冕。確保老的功能還能正常使用血当。如果新版本更新或者刪除了功能，應(yīng)該仔細(xì)檢查新版本無法運(yùn)行的用例禀忆，保證沒有遺漏必須的功能臊旭。

測試之前進(jìn)行代碼比較，確認(rèn)差異項(xiàng)箩退，然后進(jìn)行測試

三离熏、娛樂區(qū)類型：
配角測試法：鼓勵(lì)測試人員關(guān)注某些特定的特性，并將這些特性與主流業(yè)務(wù)特性放在一個(gè)視角來測試戴涝；比如：一個(gè)菜單有多個(gè)選項(xiàng)滋戳，我們通常選擇第2個(gè)選項(xiàng)，那么我們可以去測試第3個(gè)選項(xiàng)啥刻。

案例：
1奸鸯、注冊時(shí)選擇不同意用戶協(xié)議

深巷測試法：最不可能被用到的用戶特性以及沒有被覆蓋過的代碼；以及將不常用的特性和最常用的特性進(jìn)行結(jié)合起來使用可帽。

案例：
1娄涩、手機(jī)輸入法中的幫助菜單

2、不常用的子功能映跟，例如手機(jī)百度輸入法中-設(shè)置-調(diào)整高度的功能

通宵測試法：盡可能不關(guān)閉程序蓄拣，讓程序一直去運(yùn)行。比如：移動(dòng)設(shè)備的某一個(gè)后臺程序可能就是一直運(yùn)行的申窘。

案例：
1弯蚜、手機(jī)不關(guān)機(jī)，一直運(yùn)行剃法，看新通知提示是否正確

四碎捺、旅游區(qū)類型：

收藏家法：建議我們收集軟件的輸出，收集的越多越好。然后可以將這些搜集進(jìn)行梳理收厨，可能會(huì)收到一些意想不到的驚喜晋柱。

案例：

測試中我們經(jīng)常做的容錯(cuò)測試可以理解為是收藏家測試法的一種，通過輸入不同的內(nèi)容诵叁，看是否能輸出合理的信息

1雁竞、注冊時(shí)各種輸入各種正確、不正確的信息拧额，看能夠注冊

2碑诉、輸入各種異常姓名，例如：英文侥锦、繁體进栽、簡體、阿拉伯語恭垦、特殊字符快毛、數(shù)字等等，查看校驗(yàn)情況

長路徑法：那些需要被點(diǎn)擊N次才能激活的特性點(diǎn)番挺，把那個(gè)埋在應(yīng)用程序最深處的界面作為測試目標(biāo)唠帝；

案例：
1、注冊-激活-完善信息-登錄-個(gè)人信息-修改頭像

超模測試法：是一種純界面測試方法玄柏，它的原理是不關(guān)注特性襟衰，而只關(guān)注界面的設(shè)計(jì)是否給我們帶來愉悅感。針對UI的表面測試禁荸，衡量軟件的展現(xiàn)能力右蒲。

功能測試中的界面測試

測一送一法：它只測試同時(shí)運(yùn)行同一應(yīng)用程序多個(gè)拷貝的情況。比如：運(yùn)行一個(gè)應(yīng)用程序赶熟，然后再去運(yùn)行該應(yīng)用程序的一個(gè)拷貝瑰妄。

案例：
email注冊一個(gè)email只能注冊一個(gè)用戶
1、兩個(gè)用戶同時(shí)用一個(gè)email進(jìn)行注冊映砖，再先后進(jìn)行激活间坐，后激活者能成功么？能同時(shí)注冊么?

蘇格蘭酒吧測試法：適用于大規(guī)模軟件邑退，測試角落中不易找到的功能竹宋。

五、旅館區(qū)類型：

取消測試法：此方法的思想是啟動(dòng)了立即停止地技，特別是一些運(yùn)行流程比較耗時(shí)的功能如備份還原或者搜索蜈七，在啟動(dòng)之后，立即取消莫矗。發(fā)散一點(diǎn)還可以變成飒硅，啟動(dòng)一個(gè)耗時(shí)操作砂缩，不停止立即啟動(dòng)另外一個(gè)耗時(shí)操作，以此來檢測應(yīng)用程序的自我清除能力三娩。

案例：
1庵芭、手機(jī)開機(jī)過程中關(guān)機(jī)
2、用戶注冊時(shí)雀监，激活后在完善信息時(shí)取消

懶漢測試法：軟件必須處理默認(rèn)值双吆，它必須運(yùn)行處理空白輸入的代碼，很多輸入不填寫就直接進(jìn)入下一步等等会前；選擇盡可能少的輸入好乐，能不輸入盡量不輸入，能不修改盡量不修改回官，觀察應(yīng)用程序是否能響應(yīng)得出正確結(jié)果

案例：
1曹宴、注冊時(shí)，不輸入任何值
2歉提、檢查默認(rèn)值，比如用戶注冊協(xié)議默認(rèn)是否勾選

六区转、破舊區(qū)測試類型
破壞測試法：強(qiáng)迫軟件做一些操作苔巨；掌握軟件成功完成操作必須使用的資源；在不同程度上移除那些資源或限制使用那些資源废离；

案例：
1侄泽、注冊時(shí)，斷掉網(wǎng)絡(luò)
2蜻韭、發(fā)送激活郵件時(shí)悼尾，關(guān)閉郵件發(fā)送服務(wù)器

反叛測試法：故意輸入一些最不可能的數(shù)據(jù)或者已知的惡意輸入，然后判斷程序如何去處理肖方；

案例：
注冊時(shí)闺魏，輸入空格作為姓名

強(qiáng)迫癥測試：一遍又一遍的輸入同樣的數(shù)據(jù)，反復(fù)的做一些同樣的操作俯画；

案例：
1析桥、注冊用戶再次注冊
2、已激活用戶再次激活

code review

在敏捷中艰垂，質(zhì)量提升是需要全員參與的

為什么執(zhí)行review

1泡仗、代碼評審可以及時(shí)發(fā)現(xiàn)一些容易發(fā)現(xiàn)的BUG，而不必將發(fā)現(xiàn)BUG的時(shí)間點(diǎn)推遲到測試階段猜憎。

2娩怎、碼評審可以保證至少有兩個(gè)人都理解任何一份代碼。當(dāng)出現(xiàn)員工休假胰柑，離職等情況的時(shí)候截亦，至少保證團(tuán)隊(duì)的代碼不會(huì)陷入無人理解或者無人處理的狀況辣辫。

3、代碼評審的最大好處是純社會(huì)性的魁巩，當(dāng)你知道你的每一行代碼都有另外一個(gè)人看急灭，自然而然會(huì)更加賣力的表現(xiàn)，拿出最好的狀態(tài)編碼谷遂，因?yàn)槊總€(gè)人都有虛榮心嘛葬馋。

代碼評審的流程有以下兩種：

1、提交前評審(pre-pushcode review)

• 程序員在試圖提交代碼變更到代碼庫之前肾扰，先提交變更申請畴嘶，變更申請包含了這次變更的內(nèi)容，評審人集晚；
• 評審人查看變更內(nèi)容窗悯，評估變更，與變更申請人溝通偷拔，評估是否通過變更蒋院；
• 如果評審人通過變更，則變更申請人才可以提交代碼到代碼庫莲绰；
• 如果評審人不通過變更欺旧，則變更申請人需要根據(jù)討論結(jié)果或評審建議做出修改，直到與評審人達(dá)成一致蛤签，通過評審辞友，才可以提交代碼到代碼庫；

2震肮、提交后評審(post-pushcode review)

• 程序員提交變更代碼到代碼庫称龙；

• 評審人審查這次變更的內(nèi)容，如果評審?fù)ㄟ^戳晌，則標(biāo)記此次的變更已審查鲫尊；

• 如果評審人有疑義，則與變更人溝通躬厌，變更人根據(jù)討論結(jié)果或評審意見做出修改马昨，知道與評審人達(dá)成一致，通過評審扛施。

提交前評審對比提交后評審有諸多好處

1鸿捧、程序員會(huì)更積極的將變更的代碼組織的更好，更模塊化疙渣，更容易閱讀匙奴；

2、評審人有機(jī)會(huì)在代碼提交之前發(fā)現(xiàn)問題妄荔，或給出更好的建議泼菌，對應(yīng)的程序員對這樣的反饋更容易接受谍肤；

3、評審人給出建議或意見之后哗伯，相比提交后評審荒揣，程序員會(huì)更加積極的最反饋?zhàn)龀鲰憫?yīng)；

4焊刹、評審人會(huì)更加認(rèn)真的對變更進(jìn)行評審系任，并且發(fā)現(xiàn)問題后會(huì)更加積極的參與討論，對發(fā)起變更的程序員提供支持虐块；

5俩滥、在真正提交變更前發(fā)現(xiàn)問題并予以解決顯然比提交后再進(jìn)行評審尖昏，然后提交修改補(bǔ)丁更好山害；

**提交后評審對比提交前評審有諸多好處 **

1厚满、post-push code review 更加容易實(shí)施懦趋，過程對現(xiàn)有的組織架構(gòu)和流程沒有完全的顛覆，對團(tuán)隊(duì)成員的要求沒有那么高毫别；

2组贺、 相比pre-push code review泡躯，post-push code review不需要對修改代碼&提交變更這個(gè)過程中斷喉悴，不需要等待評審的時(shí)間棱貌；

3、可以作為組織向pre-push code review過程實(shí)施的過渡訓(xùn)練箕肃；

常用工具：

Phabricator、 Review Board今魔、gitlab等

4-15.png

代碼靜態(tài)分析

代碼靜態(tài)分析（Program Static Analysis）是指在不運(yùn)行代碼的方式下勺像，通過詞法分析、語法分析错森、控制流吟宦、數(shù)據(jù)流分析等技術(shù)對程序代碼進(jìn)行掃描，驗(yàn)證代碼是否滿足規(guī)范性涩维、安全性殃姓、可靠性、可維護(hù)性等指標(biāo)的一種代碼分析技術(shù)瓦阐。

代碼靜態(tài)分析可以在開發(fā)階段就找到一些bug蜗侈，尤其是黑盒測試難易發(fā)現(xiàn)的bug，如資源未釋放等睡蟋。

代碼靜態(tài)分析的特點(diǎn)

代碼靜態(tài)分析是與程序動(dòng)態(tài)分析相對應(yīng)的代碼分析技術(shù)踏幻，它通過對代碼的自動(dòng)掃描發(fā)現(xiàn)隱含的程序問題，主要具有以下特點(diǎn)：

（1）不實(shí)際執(zhí)行程序戳杀。動(dòng)態(tài)分析是通過在真實(shí)或模擬環(huán)境中執(zhí)行程序進(jìn)行分析的方法该面，多用于性能測試夭苗、功能測試、內(nèi)存泄漏測試等方面隔缀。與之相反题造，靜態(tài)分析不運(yùn)行代碼只是通過對代碼的靜態(tài)掃描對程序進(jìn)行分析。

（2）執(zhí)行速度快猾瘸、效率高界赔。目前成熟的代碼靜態(tài)分析工具每秒可掃描上萬行代碼，相對于動(dòng)態(tài)分析须妻，具有檢測速度快仔蝌、效率高的特點(diǎn)。

（3）誤報(bào)率較高荒吏。代碼靜態(tài)分析是通過對程序掃描找到匹配某種規(guī)則模式的代碼從而發(fā)現(xiàn)代碼中存在的問題敛惊，這樣有時(shí)會(huì)造成將一些正確代碼定位為缺陷的問題，因此靜態(tài)分析有時(shí)存在誤報(bào)率較高的缺陷绰更，可結(jié)合動(dòng)態(tài)分析方法進(jìn)行修正瞧挤。

代碼靜態(tài)分析的工作內(nèi)容

類型檢查

風(fēng)格檢查

bug查找

安全漏洞

代碼靜態(tài)分析的時(shí)機(jī)

1、在編碼時(shí)檢查儡湾，在IDE中集成對應(yīng)的插件

2特恬、編碼完成后統(tǒng)一檢查

建議采用第一種方式

常用工具：

Pclint，checkstyle徐钠，pmd癌刽，findbugs，hp fortify尝丐，sonarqube

4-16.png

CI/CD显拜、devops

持續(xù)集成是什么（CI）

持續(xù)集成（ContinousIntergration，CI）是一種軟件開發(fā)實(shí)踐爹袁，即團(tuán)隊(duì)開發(fā)成員經(jīng)常集成它們的工作远荠，通常每個(gè)成員每天至少集成一次，也就意味著每天可能會(huì)發(fā)生多次集成失息。每次集成都通過自動(dòng)化的編譯譬淳、發(fā)布、自動(dòng)化回歸測試來驗(yàn)證盹兢，從而盡快地發(fā)現(xiàn)集成錯(cuò)誤邻梆。許多團(tuán)隊(duì)發(fā)現(xiàn)這個(gè)過程可以大大減少集成的問題，讓團(tuán)隊(duì)能夠更快的開發(fā)內(nèi)聚的軟件蛤迎。

持續(xù)集成是為了持續(xù)交付确虱。

沒有單元測試的持續(xù)集成基本無意義。

4-17.PNG

持續(xù)部署是什么（CD）

持續(xù)部署（ContinousDelivery替裆，CD）在持續(xù)集成的基礎(chǔ)上校辩，將集成后的代碼部署到更貼近真實(shí)運(yùn)行環(huán)境中窘问。比如，我們完成單元測試后宜咒，可以把代碼部署到測試環(huán)境中惠赫，交付給質(zhì)量團(tuán)隊(duì)或者用戶，以供評審故黑。如果評審?fù)ㄟ^儿咱，代碼就進(jìn)入生產(chǎn)階段。

4-18.PNG

對于測試最大的好處是節(jié)約時(shí)間场晶！

設(shè)想一下混埠，一個(gè)常規(guī)的測試過程：開發(fā)送測一個(gè)版本---測試人員從配置庫下載版本---編譯版本---部署到測試環(huán)境---進(jìn)行冒煙測試---進(jìn)行功能測試。

而這些過程完全可以由CI/CD來替代诗轻。

DevOps：

DevOps 是一個(gè)完整的面向IT運(yùn)維的工作流钳宪，以 IT 自動(dòng)化以及持續(xù)集成（CI）、持續(xù)部署（CD）為基礎(chǔ)扳炬，來優(yōu)化程式開發(fā)吏颖、測試、系統(tǒng)運(yùn)維等所有環(huán)節(jié)恨樟。

目標(biāo)：

讓生產(chǎn)端變得敏捷起來半醉！

DevOps實(shí)際是一種文化上的變遷，代表了開發(fā)劝术、運(yùn)維缩多、測試等環(huán)節(jié)之間的協(xié)作，因此DevOps工具是非常多種多樣的养晋，甚至可以由多種工具組成一個(gè)完整的DevOps工具鏈瞧壮。此類工具可以應(yīng)用于一種或多種類別，并可體現(xiàn)出軟件開發(fā)和交付過程的不同階段：

• 編碼：代碼開發(fā)和審閱匙握，版本控制工具、代碼合并工具

• 構(gòu)建：持續(xù)集成工具陈轿、構(gòu)建狀態(tài)統(tǒng)計(jì)工具

• 測試：通過測試和結(jié)果確定績效的工具

• 打包：成品倉庫圈纺、應(yīng)用程序部署前暫存

• 發(fā)布：變更管理、發(fā)布審批麦射、發(fā)布自動(dòng)化

• 配置：基礎(chǔ)架構(gòu)配置和部署蛾娶，基礎(chǔ)架構(gòu)即代碼工具

• 監(jiān)視：應(yīng)用程序性能監(jiān)視、最終用戶體驗(yàn)

工具：

• 版本控制&協(xié)作開發(fā)：GitHub潜秋、GitLab蛔琅、BitBucket、SubVersion峻呛、Coding罗售、Bazaar
• 自動(dòng)化構(gòu)建和測試:Apache Ant辜窑、Maven 、Selenium寨躁、PyUnit穆碎、QUnit、JMeter职恳、Gradle所禀、PHPUnit
• 持續(xù)集成&交付:Jenkins、Capistrano放钦、BuildBot色徘、Fabric、Tinderbox操禀、Travis CI褂策、flow.ci Continuum、LuntBuild床蜘、CruiseControl辙培、Integrity、Gump邢锯、Go
• 容器平臺: Docker扬蕊、Rocket、Ubuntu（LXC）丹擎、第三方廠商如（AWS/阿里云）
• 配置管理：Chef尾抑、Puppet、CFengine蒂培、Bash再愈、Rudder、Powershell护戳、RunDeck翎冲、Saltstack、Ansible
• 微服務(wù)平臺：OpenShift媳荒、Cloud Foundry抗悍、Kubernetes、Mesosphere
• 服務(wù)開通：Puppet钳枕、Docker Swarm缴渊、Vagrant、Powershell鱼炒、OpenStack Heat
• 日志管理：Logstash衔沼、CollectD、StatsD
• 監(jiān)控，警告&分析：Nagios指蚁、Ganglia菩佑、Sensu、zabbix欣舵、ICINGA擎鸠、Graphite、Kibana