持续交付会如何影响测试
如果要做持續(xù)交付,那我們必須關(guān)注我們寫的代碼的質(zhì)量。不是所有團(tuán)隊(duì)都配備專門的測試人員,但如果有測試人員的話,他們會(huì)和開發(fā)人員緊密合作,編寫在單元測試中無法覆蓋的少數(shù)測試的自動(dòng)化代碼,并幫助開發(fā)人員搭建單元測試。
\\Industrial Logic Canada公司的首席執(zhí)行官Jeff Morgan在2018年eXperience Agile大會(huì)上介紹了持續(xù)交付會(huì)如何影響測試人員的工作。InfoQ會(huì)以問答、總結(jié)和文章的形式報(bào)道eXperience Agile大會(huì)。
\\Morgan說,持續(xù)交付的優(yōu)勢在于可以迅速在生產(chǎn)環(huán)境下進(jìn)行實(shí)驗(yàn)。它可以幫助我們盡快測試用戶對(duì)產(chǎn)品的想法,并收集數(shù)據(jù)結(jié)果。
\\我們大多數(shù)的應(yīng)用程序都會(huì)進(jìn)行單元測試。Morgan表示他們沒有人工測試,一切測試都是自動(dòng)化進(jìn)行的。并不存在強(qiáng)化階段,我們必須從一開始就保證產(chǎn)品的質(zhì)量。
\\Morgan建議如果你需要專門的測試知識(shí),那讓測試方面的專家和團(tuán)隊(duì)一起工作,不要讓專家悶頭寫測試。是整個(gè)團(tuán)隊(duì)需要測試,不僅僅是這個(gè)專家需要測試。
\\Morgan說,由于測試人員越來越技術(shù)化,開發(fā)人員也越來越注重測試的重要性,隨著時(shí)間的推移,開發(fā)人員也會(huì)承擔(dān)測試的工作,測試人員也會(huì)做一些開發(fā)的工作。
\\InfoQ采訪了Morgan,咨詢了他持續(xù)交付會(huì)如何影響測試工作。
\\InfoQ:當(dāng)組織采用持續(xù)交付的方法時(shí),軟件搭建和交付的方式會(huì)有什么重大改變?
\\\Jeff Morgan:最主要的變化是我們不會(huì)再用傳統(tǒng)的軟件開發(fā)方式了,構(gòu)建完軟件之后就直接進(jìn)入測試階段。選擇進(jìn)行持續(xù)交付,一旦代碼進(jìn)行了源代碼管理并遍歷了部署管道,代碼就部署到了生產(chǎn)環(huán)境下。
\\這個(gè)重大的變更也表明,測試需要在開發(fā)的同時(shí)進(jìn)行。實(shí)際上,我們通常不會(huì)把開發(fā)和測試認(rèn)為是兩個(gè)分開的工作。相反,測試是整個(gè)開發(fā)流程的一部分。這個(gè)變更還表明,我們會(huì)更多地依賴自動(dòng)化:自動(dòng)化測試、自動(dòng)化部署和環(huán)境自動(dòng)化。
\\\InfoQ:持續(xù)交付會(huì)如何影響我們對(duì)于質(zhì)量的看法?
\\\Morgan:通常,我們會(huì)在軟件開發(fā)周期的最后,在發(fā)布前才驗(yàn)證并完善軟件的質(zhì)量。這通常被稱為強(qiáng)化階段。但是我們?nèi)绻捎贸掷m(xù)交付,就沒有必要設(shè)立專門的強(qiáng)化階段,因?yàn)橹灰獧z查了代碼就會(huì)立刻進(jìn)入生產(chǎn)環(huán)境。 相反,在我們寫代碼的時(shí)候,我們要全程關(guān)注軟件的質(zhì)量。對(duì)于我工作的團(tuán)隊(duì)來說,這代表著我們寫代碼的方式發(fā)生了徹底的改變。我們會(huì)采用結(jié)對(duì)編程、測試驅(qū)動(dòng)開發(fā)、減少分支、以及功能開關(guān)等實(shí)踐。開發(fā)人員會(huì)更加注意測試和質(zhì)量問題。如果團(tuán)隊(duì)中有開發(fā)人員,他們會(huì)主要關(guān)注少量端到端的自動(dòng)化,并和開發(fā)人員結(jié)對(duì)進(jìn)行探索性測試。與傳統(tǒng)的僅由測試人員來測試不同,團(tuán)隊(duì)中的“每個(gè)人”都會(huì)進(jìn)行非功能性需求的測試。很優(yōu)秀的團(tuán)隊(duì)中,開發(fā)人員和測試人員之間并沒有很多區(qū)別。
\\我們也會(huì)使用大家所說的DevOps來幫助我們完善系統(tǒng)。通過搭建管道,用不同的方法運(yùn)行我們所有的測試來降低風(fēng)險(xiǎn),并通過測試來消除安全性、能力以及合規(guī)性的問題。通過容器和基礎(chǔ)設(shè)施來避免環(huán)境方面的風(fēng)險(xiǎn)。通過對(duì)于小的變更的發(fā)布控制來避免對(duì)于用戶和產(chǎn)品產(chǎn)生的風(fēng)險(xiǎn)。
\\\InfoQ:這會(huì)如何影響測試人員的工作?
\\\Morgan:首先我要指出在現(xiàn)代社會(huì),不是所有團(tuán)隊(duì)都會(huì)配備專門的測試人員的。如果有測試人員的話,他們不會(huì)手動(dòng)執(zhí)行測試腳本。相反,他們要編寫少量單元測試無法覆蓋的自動(dòng)化代碼,幫助開發(fā)人員從金字塔最上面轉(zhuǎn)移到最底端的單元測試。他們和開發(fā)人員合作非常緊密,并幫助搭建管道。他們會(huì)在整個(gè)開發(fā)過程中和開發(fā)人員結(jié)對(duì),來進(jìn)行探索性測試。一旦發(fā)現(xiàn)了缺陷,他們會(huì)和開發(fā)人員結(jié)對(duì),立刻修復(fù)并部署修訂后的版本。所有的工作都是和開發(fā)人員合作完成的。
\\\\\InfoQ:如果沒有“測試階段”的時(shí)間的話,開發(fā)人員應(yīng)該做什么?
\\\Morgan:根據(jù)我的經(jīng)驗(yàn),和傳統(tǒng)的“敏捷”相比,持續(xù)交付中會(huì)進(jìn)行更多的測試。同時(shí),在開發(fā)周期的不同時(shí)間都會(huì)進(jìn)行測試,而不僅僅在最后才進(jìn)行測試。我們非常依賴于自動(dòng)化(主要是單元測試)和管道,來保證系統(tǒng)的質(zhì)量。
\\開發(fā)人員應(yīng)該和開發(fā)人員緊密合作,保證軟件的質(zhì)量,保證缺陷幾乎不會(huì)發(fā)生。開發(fā)人員通常要關(guān)注金字塔最上面的“用戶測試”。他們還可以和開發(fā)人員結(jié)對(duì),幫助他們獲得并提升自己的測試能力。測試人員還需要幫助定義構(gòu)建管道。
\\有時(shí)候會(huì)需要專門的測試專家,比如安全或負(fù)載/性能測試專家。這種情況下,他們需要和團(tuán)隊(duì)討論、創(chuàng)建并維護(hù)測試腳本在管道階段的運(yùn)作。
\\在很多方面,管道是最接近“測試階段”的存在。每次檢入代碼時(shí),我們?cè)谶@里運(yùn)行所有測試,并最終將我們的代碼部署到生產(chǎn)環(huán)境。盡管所有的管道都是不同的,但我發(fā)現(xiàn)各個(gè)團(tuán)隊(duì)之間總有些核心的通用模式。這里舉例說明了團(tuán)隊(duì)可能會(huì)有的管道階段:
\\搭建并運(yùn)行單元測試
\\運(yùn)行動(dòng)態(tài)代碼分析,如果質(zhì)量沒有達(dá)到的話就會(huì)失敗
\\在功能開關(guān)開啟的時(shí)候進(jìn)行部署,只運(yùn)行關(guān)注于未發(fā)布功能的測試。任何不在控制之內(nèi)的后端系統(tǒng)都應(yīng)該模擬。
\\在功能開關(guān)關(guān)閉的時(shí)候進(jìn)行部署,運(yùn)行其他的測試,實(shí)現(xiàn)回歸。這個(gè)測試要很快運(yùn)行,因此它們可以并行運(yùn)作。同時(shí),任何控制之外的后端系統(tǒng)都應(yīng)該模擬。
\\在功能開關(guān)關(guān)閉的時(shí)候進(jìn)行部署,在不同的瀏覽器和設(shè)備上進(jìn)行小部分測試。后端需要模擬。
\\在功能開關(guān)關(guān)閉的情況下部署,運(yùn)行一小部分測試,不需要模擬。這能保證完整集成工作的正常運(yùn)作。
\\運(yùn)行靜態(tài)和動(dòng)態(tài)安全測試。
\\運(yùn)行負(fù)載和性能測試。
\\運(yùn)行合規(guī)性測試,解決任何生產(chǎn)前的合規(guī)性工作。
\\部署到生產(chǎn)環(huán)境。
\\如果任何階段失敗了,管道都需要停止。
\\\InfoQ:你對(duì)于想要采用持續(xù)交付的組織有什么建議?
\\\Morgan:有很多公司跟我說正在接受持續(xù)交付。當(dāng)我問他們?yōu)槭裁吹臅r(shí)候,他們大多數(shù)會(huì)聊到更快的交付或是質(zhì)量提升。雖然這都是很好的目標(biāo),但我認(rèn)為持續(xù)交付有更重要的優(yōu)勢。在我認(rèn)為,采用持續(xù)交付的最重要原因是改變我們計(jì)劃和交付產(chǎn)品的方式。持續(xù)交付可以幫助我們拋棄辛苦的、推測性的長期產(chǎn)品路線圖,而改為采用“精益創(chuàng)新”方式來進(jìn)行產(chǎn)品設(shè)計(jì)。它可以幫助我們根據(jù)真實(shí)用戶的體驗(yàn)來修改代碼,以交付完善的產(chǎn)品。這是我認(rèn)為使用持續(xù)交付的關(guān)注點(diǎn)。
\\對(duì)于正在使用持續(xù)交付的公司,他們需要了解DevOps并不是解決所有問題的方法。它當(dāng)然是個(gè)重要的組成部分,但必須要和高質(zhì)量的開發(fā)相結(jié)合。實(shí)際上,我建議首先提高質(zhì)量,這需要一些時(shí)間。一旦實(shí)現(xiàn)之后,你可以考慮添加持續(xù)集成,這樣開發(fā)人員可以盡快在搭建過程中獲得反饋。隨著時(shí)間的推移,你可以把它擴(kuò)展為成熟的部署管道。
\\一旦你的組織中有了質(zhì)量保證的文化之后,你就可以為每天交付多次添加DevOps自動(dòng)化了。
\\\查看英文原文:How Continuous Delivery Impacts Testing
《新程序員》:云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作,文字、視頻、音頻交互閱讀總結(jié)
以上是生活随笔為你收集整理的持续交付会如何影响测试的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Linux之父为过去的言行道歉,宣布离开
- 下一篇: 权限判断-位运算