一、測試架構(gòu)的演進(jìn)
- 從有測試開始之初，是比較偏純手工測試的方式，那就是大家說的“測試就是點(diǎn)點(diǎn)嘛”，這時候的測試“龜縮在測試階段”，還經(jīng)常被產(chǎn)品、研發(fā)壓縮時間，可謂慘不忍睹。此時的測試階段，效率低下，覆蓋度不高，重復(fù)工作高，以黑盒測試為主，整體測試效率不高。
- 然后測試團(tuán)隊(duì)意識到，不能一直這樣的，麻木的重復(fù)性點(diǎn)點(diǎn)，沒有技術(shù)含量，自身成長也不高。此時，測試團(tuán)隊(duì)里有想法的小伙伴，開始把部分重復(fù)性工作，寫成一些腳本工具，測試團(tuán)隊(duì)開始有部分工具支持，提升了部分測試效率。但從測試的深度和廣度，并沒有得到提升。還是停留在功能、UI層面測試。
- 接著為了提升深度和廣度，開始有白盒測試，重新定義測試方法，深入代碼級別的測試，此時從功能的黑盒測試，流轉(zhuǎn)到了對代碼的測試，然后測試和研發(fā)不在功能的bug上去溝通，而是測試指著代碼給研發(fā)說，看這里有bug，應(yīng)該怎么怎么改
- 這時候，測試發(fā)現(xiàn)我怎么比以前還累了，以前只要測試功能，不需要review代碼。隨著白盒測試的深入，codereview的時間占據(jù)了大部分時間，研發(fā)和產(chǎn)品說，你們能提升效率嗎？然后測試開始思考，如何提升效率和質(zhì)量，然后開始搭建自動化測試，持續(xù)集成，持續(xù)部署。部署流pipeline 隨時檢測業(yè)務(wù)代碼。如此，降低了功能測試的覆蓋，這時候測試同學(xué)，大部分時間在完善pipeline 和codereview。
-
此時團(tuán)隊(duì)來了一位架構(gòu)師，開始思考，團(tuán)隊(duì)的質(zhì)量體系如何建設(shè)，難道一直是流水線完善，怎么做到研發(fā)自測，測試不參與到具體的項(xiàng)目，提測研發(fā)測試比，從1:3 => 1:5 => 1:10 ,甚至部分業(yè)務(wù)無測試。這就需要研發(fā)在不斷ci代碼的同時，項(xiàng)目不斷推進(jìn)時，質(zhì)量體系是一直默默的在“保護(hù)”項(xiàng)目的質(zhì)量，要求對線下和線上，都能快速無感知的，發(fā)現(xiàn)問題，也就是devops開始了。
質(zhì)量模型演化進(jìn)程
二、devops是什么
devOps（Development和Operations的組合）是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開發(fā)（RD）、產(chǎn)品運(yùn)營（PM）和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。
簡單來說，其核心理念是提倡開發(fā)、測試、運(yùn)維人員之間的高度協(xié)同，在高頻率部署的同時，保證生產(chǎn)環(huán)境的可靠性、穩(wěn)定性和安全性。
三、devops解決了什么問題
“升級”到devops后，有幾個特點(diǎn)，線下有完整的質(zhì)量流水線在檢測項(xiàng)目和代碼，從多維度去檢測質(zhì)量，同時不需要測試人員干預(yù)，可以說devops將會干掉測試，干掉那些純手工測試的測試，因?yàn)閐evops的高度自動化，解決了很多功能測試所能覆蓋的問題，而且在功能、性能、安全、兼容性等層面測試保障。具體幾個特點(diǎn)，
1. 標(biāo)準(zhǔn)化的流程
如果需要做到devops，重要的前提是把項(xiàng)目和代碼的流程標(biāo)準(zhǔn)化，各角色如何配合，各項(xiàng)目階段如何做到準(zhǔn)入。同時需要把人為的執(zhí)行流程，使用工具管理起來。既保證了流程標(biāo)準(zhǔn)化，也同時對于項(xiàng)目的數(shù)據(jù)做到集中共享。推薦使用jira。
2. 增加測試廣度寬度
devops是一種框架，類似于一艘航母，需要裝備“電磁炮”，“戰(zhàn)斗機(jī)”，“核潛艇”等等，才能發(fā)揮最大作用。從項(xiàng)目開始，devops這艘航母就開始保障項(xiàng)目質(zhì)量。從深度上講，單測、模塊自動化、集成自動化、系統(tǒng)自動化，多層覆蓋；從廣度上講，功能測試、性能測試、兼容性測試、靜（動）態(tài)代碼掃描，多維度覆蓋。這些測試組件，有的叫測試服務(wù)化，是devops最尖端的武器。在配合項(xiàng)目流程場景下，分別從代碼開發(fā)、提測準(zhǔn)入、功能回歸、全鏈路壓測、線上回歸等等，對項(xiàng)目提供質(zhì)量保障
3. 提升整體質(zhì)量
沒有devops時，測試服務(wù)（工具/平臺）是游離在項(xiàng)目之外的，即使有工具平臺，但缺少完善的使用場景，對于不同的業(yè)務(wù)，不同的端，不同的測試同學(xué)，所使用的工具平臺是不一樣的，同時對測試場景的制定，也需要線下制定，然后手動，非常費(fèi)時成本較高。而devops是無需人力干預(yù)，從項(xiàng)目開始就在保障了，整個流程中，都是自動的，且在每個環(huán)節(jié)都有標(biāo)準(zhǔn)，保證質(zhì)量的持續(xù)提升。此外，在不停地持續(xù)構(gòu)建部署中，做到測試前置，在交付給QA的代碼，是保證高質(zhì)量的。
4. 質(zhì)量可度量
一般評估項(xiàng)目的質(zhì)量，是從項(xiàng)目效率、代碼質(zhì)量、服務(wù)穩(wěn)定性、線上事故、用戶反饋等幾個維度來評估的。在devops中的各個武器，都需要對質(zhì)量檢測做數(shù)據(jù)輸出，比如說自動化測試的代碼覆蓋度率、接口覆蓋率、bug率等等；而項(xiàng)目管理工具，可以對項(xiàng)目的各階段效率數(shù)據(jù)化；從線上監(jiān)控，可以拿到事故的數(shù)據(jù)指標(biāo)，什么級別，什么原因，影響面等等；用戶反饋接口，獲取用戶的數(shù)據(jù)，并通過一定算法（后續(xù)文章可以解答），抽取有效信息并聚合。如此，線上、線下、用戶側(cè)多個場景拿到數(shù)據(jù)，評估整體項(xiàng)目的質(zhì)量。
5. 提高研發(fā)測試比
基于高效，高質(zhì)的持續(xù)部署方式，測試同學(xué)不用在執(zhí)行重復(fù)低效的點(diǎn)點(diǎn)工作，而更多關(guān)注在如何提高devops的測試賦能（后續(xù)也會提到），這樣devops第一批干掉了純測試的同學(xué)（說真的，這些同學(xué)前景堪憂），這時候從常規(guī)的比例提高（1:3 => 1:5），而測試賦能，把測試技能輸出給研發(fā)，這時候研發(fā)自測的效率和質(zhì)量更高了，新功能測試的工作量降低了，測試的排期進(jìn)一步壓縮（1:5 => 1:7），而devops的武器庫使得更多的項(xiàng)目，無需測試參與，極限情況下可以把比例壓縮到1:10.這就是阿里之前提過的，干掉QA。正式通過devops方式，干掉了QA
四、總結(jié)
現(xiàn)在大廠都在實(shí)施devops，bat依托于各自的云計(jì)算，優(yōu)秀的團(tuán)隊(duì)，快速地搭建地devops。這方面，阿里做的最好（個人感覺）。而小廠比大廠缺少搭建devops條件，devops實(shí)施的成本非常高。后續(xù)會講到如何devops更多內(nèi)容。
參考資料：
