企業(yè)在敏捷和DevOps的逐步轉(zhuǎn)型過(guò)程中，測(cè)試如何應(yīng)對(duì)挑戰(zhàn)，如何有的放矢進(jìn)行測(cè)試，建立適合產(chǎn)品自身發(fā)展階段、產(chǎn)品特點(diǎn)的敏捷測(cè)試能力。

敏捷和DevOps

敏捷和DevOps轉(zhuǎn)型始終是被業(yè)務(wù)目標(biāo)和客戶需求驅(qū)動(dòng)的。市場(chǎng)競(jìng)爭(zhēng)環(huán)境越來(lái)越激烈，新商業(yè)模式的創(chuàng)新和變現(xiàn)時(shí)間窗口越來(lái)越短，催生更多的企業(yè)采取精益創(chuàng)業(yè)的方式，捕捉市場(chǎng)需求后，盡量縮短TTM產(chǎn)品面世時(shí)間，快速推出MVP產(chǎn)品并快速響應(yīng)客戶需求迭代產(chǎn)品。

以華為為例，在2008年左右的時(shí)候，華為的項(xiàng)目還是采用傳統(tǒng)的交付方式。例如，在年初開(kāi)始一個(gè)項(xiàng)目，在項(xiàng)目立項(xiàng)之初就會(huì)把客戶的需求全部收集好，包括一些用戶的反饋，并把需求做了全年的排序。年中的時(shí)候發(fā)布產(chǎn)品給用戶，兩個(gè)月之后再出一個(gè)補(bǔ)丁，最終年底出一個(gè)正式的版本。當(dāng)時(shí)版本交付的節(jié)奏還是比較慢的，但是對(duì)質(zhì)量要求比較強(qiáng)。因?yàn)楫a(chǎn)品發(fā)布給客戶以后，下一個(gè)補(bǔ)丁需要兩個(gè)月，如果用戶在這個(gè)期間發(fā)現(xiàn)產(chǎn)品問(wèn)題，他們只能再等兩個(gè)月，而在這期間如果用戶不接受我們的產(chǎn)品，會(huì)導(dǎo)致項(xiàng)目前功盡棄，所以對(duì)產(chǎn)品的質(zhì)量有嚴(yán)格的要求。

產(chǎn)品逐漸向敏捷方向發(fā)展，這時(shí)有一部分研發(fā)工具平臺(tái)已經(jīng)陸續(xù)轉(zhuǎn)到上云，一些測(cè)試類的工具也需要轉(zhuǎn)型。之前產(chǎn)品的交付是半年、兩個(gè)月發(fā)一次，轉(zhuǎn)型之后變成一個(gè)月，甚至兩周發(fā)一次，但這時(shí)的轉(zhuǎn)變并不徹底，與客戶的交付過(guò)程仍然存在一些問(wèn)題。后來(lái)越來(lái)越多的工具向平臺(tái)化、服務(wù)化方向轉(zhuǎn)型，這個(gè)時(shí)候一些商業(yè)模式發(fā)生了根本性的變化，也就是說(shuō)當(dāng)需求上云了以后，用戶更加快速的介入進(jìn)來(lái)?；谠破脚_(tái)，把一些功能快速的開(kāi)發(fā)出來(lái)，然后頻繁的和用戶去商量，聽(tīng)取客戶意見(jiàn)，牽引產(chǎn)品做快速迭代，這種交付方法使得交付周期一下變快了，之前是半年交付一次，現(xiàn)在是一周、兩周，更有甚者，可能一兩天就把功能發(fā)布出去了。從需求的角度來(lái)說(shuō)發(fā)生了巨大變化，基本做到了小步快跑，快速試錯(cuò)。

測(cè)試債務(wù)

從瀑布到敏捷再到DevOps，在開(kāi)發(fā)和測(cè)試生產(chǎn)率和需求交付效率提升的過(guò)程中，不同的組織或多或少面臨一些積壓?jiǎn)栴}沒(méi)有解決，影響測(cè)試能力和測(cè)試價(jià)值的持續(xù)提升。

從對(duì)測(cè)試的重視程度上看，有的公司存在重開(kāi)發(fā)、輕測(cè)試的情況，測(cè)試人員職業(yè)發(fā)展受限；手工測(cè)試人員不熟悉編程，開(kāi)發(fā)人員對(duì)測(cè)試重視不足；測(cè)試工作量高，但人員配比低。

從部門組織和流程和文化上看，測(cè)試人員對(duì)需求理解不足，測(cè)試和開(kāi)發(fā)之間的部門墻導(dǎo)致信息不透明、溝通協(xié)作滯后和不足，質(zhì)量向速度過(guò)分妥協(xié)，以及忽視敏捷文化和價(jià)值觀的培養(yǎng)塑造。

從測(cè)試和產(chǎn)品技術(shù)和方法上看，產(chǎn)品耦合度高、可測(cè)試性差，測(cè)試過(guò)于依賴黑盒功能測(cè)試，測(cè)試策略、方法不恰當(dāng)，測(cè)試環(huán)境部署時(shí)間長(zhǎng)，頻繁升級(jí)等。

測(cè)試的焦點(diǎn)：業(yè)務(wù)價(jià)值的質(zhì)量

測(cè)試首先是一個(gè)質(zhì)量活動(dòng)，做測(cè)試就是要保證質(zhì)量；其次是一個(gè)工程性的活動(dòng)，即在有限的時(shí)間、人力、資源投入內(nèi)獲得盡可能大的產(chǎn)出價(jià)值。質(zhì)量有多個(gè)維度，需要有一個(gè)焦點(diǎn)：業(yè)務(wù)價(jià)值的質(zhì)量，也就是產(chǎn)品“對(duì)客戶呈現(xiàn)的價(jià)值”的質(zhì)量。測(cè)試圍繞業(yè)務(wù)價(jià)值去做，確定質(zhì)量在功能、安全性、性能、易用性、兼容性等多個(gè)維度上的權(quán)重和優(yōu)先級(jí)，而不是說(shuō)一個(gè)測(cè)試上來(lái)之后，就把測(cè)試相關(guān)的關(guān)系點(diǎn)、關(guān)聯(lián)點(diǎn)全部做測(cè)試。

讓我們來(lái)看幾個(gè)例子：例如現(xiàn)在正在做一個(gè)線上支付的功能，對(duì)這個(gè)功能最關(guān)心的方面肯定是安全，所以相關(guān)的測(cè)試用例關(guān)鍵點(diǎn)就應(yīng)該圍繞安全大做文章，一定把安全保證好；再比如，現(xiàn)在要做一個(gè)線上商城，面向用戶是老百姓，不僅要讓年輕人會(huì)用，也要讓老人都會(huì)用，那么就要關(guān)注易用性；除此之外，電商舉辦大規(guī)模搶購(gòu)促銷活動(dòng)，那就還需要關(guān)注性能。因此，測(cè)試要求瞄準(zhǔn)產(chǎn)品本身的業(yè)務(wù)價(jià)值，確定產(chǎn)品的目標(biāo)，相應(yīng)的制定質(zhì)量關(guān)鍵點(diǎn)，制訂相關(guān)的測(cè)試策略，然后實(shí)踐落地。落地之后還要基于一些不良的效果不斷的進(jìn)行反饋、循環(huán)，校驗(yàn)整體的測(cè)試過(guò)程是否達(dá)到預(yù)期結(jié)果，這就是我們的測(cè)試焦點(diǎn)。

常規(guī)安全與彈性安全

在我們常規(guī)的設(shè)想中，通常是哪個(gè)地方不安全，就一定要把所有不安全的因素找出來(lái)、清除掉。這是常規(guī)的做法，但卻偏向于理想，在實(shí)際工作中是不可能把整個(gè)系統(tǒng)中不安全的因子全部識(shí)別到的，這其中涉及能力、架構(gòu)等各方面的原因。

因此，在此基礎(chǔ)上演變出了彈性安全，即通過(guò)場(chǎng)景模擬的方式將不安全因素盡量展現(xiàn)出來(lái)，從而基于這種不安全場(chǎng)景，給出快速的修復(fù)方案彌補(bǔ)這個(gè)不安全因素，從用戶角度來(lái)講是感知不到的。從產(chǎn)品來(lái)講，它的商業(yè)目的和質(zhì)量目的都可以達(dá)到，這就是所謂的彈性安全，即便發(fā)生了錯(cuò)誤，能夠及時(shí)快速的修復(fù)漏洞或者自我修復(fù)，達(dá)到正常工作的目的。

測(cè)試左移和測(cè)試右移

左移就是前移，盡量把活動(dòng)向前移。例如BDD（Behavior Driven Development，行為驅(qū)動(dòng)開(kāi)發(fā)），基于場(chǎng)景直接設(shè)計(jì)出符合這個(gè)場(chǎng)景的用例，來(lái)匹配這個(gè)設(shè)計(jì)；契約測(cè)試，服務(wù)和服務(wù)本身之間有耦合，我們可以通過(guò)契約測(cè)試解耦，以防導(dǎo)致問(wèn)題。

測(cè)試右移是指要把測(cè)試活動(dòng)的覆蓋范圍盡量向后蔓延。通常的測(cè)試只進(jìn)行到了版本發(fā)布之前，測(cè)好之后發(fā)布一個(gè)軟件包，而測(cè)試右移要把軟件包發(fā)布到生產(chǎn)環(huán)境，以及到線上運(yùn)營(yíng)環(huán)節(jié)，都要去做測(cè)試。

在這兩個(gè)方面也有一些相應(yīng)的實(shí)踐，例如線上撥測(cè)，主動(dòng)線上監(jiān)控用戶的一些行為，并從行為軌跡里面快速捕捉相應(yīng)的問(wèn)題，主動(dòng)推送給相關(guān)的責(zé)任人，讓他去關(guān)注并且解決。線上的過(guò)程可以通過(guò)一些測(cè)試手段，不斷的反饋給真正的開(kāi)發(fā)人員，讓他知道當(dāng)前產(chǎn)品的整體表現(xiàn)，開(kāi)發(fā)人員就會(huì)快速的針對(duì)產(chǎn)品作出應(yīng)對(duì)方案。

產(chǎn)品發(fā)展不同時(shí)期的測(cè)試策略

是否在團(tuán)隊(duì)組建之初，就要把整個(gè)自動(dòng)化測(cè)試的能力構(gòu)建起來(lái)呢？其實(shí)這有一個(gè)過(guò)程，下面從軟件的成熟周期的角度，看一下如何構(gòu)建測(cè)試自動(dòng)化的能力。

在軟件初期探索階段，產(chǎn)品是一個(gè)不確定的狀態(tài)，從前端的風(fēng)格和整體的布局到后端的API都時(shí)刻在變化當(dāng)中，而且變化比較頻繁，由于自動(dòng)化用例的生命周期比較短，所以在這個(gè)時(shí)候創(chuàng)建一些自動(dòng)化測(cè)試用例是不太劃算的。而這個(gè)時(shí)間段的產(chǎn)品，往往特性是可控制的，只有幾個(gè)測(cè)試，因此可以以手動(dòng)為主，不考慮自動(dòng)化，讓產(chǎn)品能夠快速識(shí)別錯(cuò)誤點(diǎn)，讓用戶能用起來(lái)。

到了產(chǎn)品擴(kuò)張階段，用戶認(rèn)可產(chǎn)品，這時(shí)候會(huì)出現(xiàn)兩個(gè)現(xiàn)象：第一是用戶量增長(zhǎng)，第二是需求數(shù)量增長(zhǎng)。這時(shí)候必須要考慮自動(dòng)化，因?yàn)樵谶@個(gè)階段每一次迭代的全量驗(yàn)證成本會(huì)越來(lái)越大，而交付的速度也會(huì)越來(lái)越快。我們不可能每一輪上線的時(shí)候都全部用手工做測(cè)試，這時(shí)候舊的模塊就需要自動(dòng)化用例去保證。

到產(chǎn)品提取階段，產(chǎn)品已經(jīng)到了需求的飽和期，產(chǎn)品的利益增長(zhǎng)也到了飽和期，這時(shí)候要嚴(yán)格控制產(chǎn)品需求，自動(dòng)化用例的職責(zé)變成守護(hù)，不允許變動(dòng)引入額外的風(fēng)險(xiǎn)點(diǎn)、大的特性變動(dòng)，導(dǎo)致對(duì)成熟的用戶造成攻擊。

團(tuán)隊(duì)規(guī)模對(duì)測(cè)試建設(shè)的影響

當(dāng)團(tuán)隊(duì)規(guī)模在5個(gè)人以下，團(tuán)隊(duì)處于探索階段，這時(shí)質(zhì)量活動(dòng)可以僅僅局限于測(cè)試的自組織階段，只是做一些基礎(chǔ)類測(cè)試管理活動(dòng)，把缺陷管理起來(lái)，做一些回歸測(cè)試。在這個(gè)階段主要是建立一個(gè)測(cè)試管理的流程和機(jī)制，并沒(méi)有接觸到自動(dòng)化測(cè)試。

隨著項(xiàng)目的進(jìn)一步擴(kuò)大，逐漸增長(zhǎng)到5-10人的團(tuán)隊(duì)規(guī)模，這時(shí)測(cè)試工作量突然增加，可能會(huì)有專門的測(cè)試人員進(jìn)來(lái)，這個(gè)測(cè)試人員會(huì)去和開(kāi)發(fā)人員進(jìn)行串聯(lián)，把需求轉(zhuǎn)化成自動(dòng)化測(cè)試的用例，搭建持續(xù)集成，逐步演進(jìn)一些測(cè)試手段。——這個(gè)階段已經(jīng)開(kāi)始做一些自動(dòng)化的嘗試。

團(tuán)隊(duì)進(jìn)一步增大，一個(gè)人可能搞不定工作量的時(shí)候，會(huì)招聘更多的測(cè)試人員，成立專門的測(cè)試團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)就從自動(dòng)化測(cè)試轉(zhuǎn)向測(cè)試自動(dòng)化，把更多的管理工作做進(jìn)來(lái)。在這個(gè)管理過(guò)程中，我們會(huì)做一些產(chǎn)品的對(duì)接，包括開(kāi)發(fā)專門的工具，實(shí)現(xiàn)自動(dòng)化的整體能力，不僅僅是自動(dòng)化執(zhí)行了。

經(jīng)過(guò)上面幾個(gè)演進(jìn)周期之后，測(cè)試團(tuán)隊(duì)具備了很多的測(cè)試自動(dòng)化經(jīng)驗(yàn)，這個(gè)時(shí)候可以進(jìn)行面向云化的轉(zhuǎn)型，現(xiàn)在很多團(tuán)隊(duì)都在進(jìn)行DevOps轉(zhuǎn)型，最關(guān)心的方面就是組建DevOps的全功能團(tuán)隊(duì)。那么之前轉(zhuǎn)型的這些人在做什么？原有10-15人的測(cè)試專項(xiàng)團(tuán)隊(duì)做什么？在這個(gè)階段團(tuán)隊(duì)要把測(cè)試專項(xiàng)能力向服務(wù)化能力轉(zhuǎn)型：測(cè)試專員會(huì)在團(tuán)隊(duì)創(chuàng)建初期進(jìn)行賦能，包括測(cè)試工程搭建、早期的測(cè)試用例怎么寫、標(biāo)準(zhǔn)化模板的編制、針對(duì)非功能性測(cè)試的專項(xiàng)能力的賦能；所有團(tuán)隊(duì)進(jìn)行測(cè)試流程的評(píng)審，包括測(cè)試策略、測(cè)試計(jì)劃、測(cè)試用例的評(píng)審，再看一下整個(gè)團(tuán)隊(duì)里面流程上還有哪些改進(jìn)的；從各個(gè)方面整個(gè)專項(xiàng)測(cè)試團(tuán)隊(duì)向服務(wù)化進(jìn)行轉(zhuǎn)型，幫助所有團(tuán)隊(duì)完成自動(dòng)化轉(zhuǎn)型。

自動(dòng)化測(cè)試和測(cè)試自動(dòng)化

這里要澄清一個(gè)概念，就是測(cè)試自動(dòng)化（Test Automation）。

測(cè)試自動(dòng)化的目的是減少手工測(cè)試和手工操作。測(cè)試自動(dòng)化不僅僅包括自動(dòng)化測(cè)試執(zhí)行（Automated Testing），還包括其它所有可以減人力投入的活動(dòng)，例如自動(dòng)化創(chuàng)建測(cè)試環(huán)境、自動(dòng)化部署被測(cè)系統(tǒng)、自動(dòng)化監(jiān)控、自動(dòng)化數(shù)據(jù)分析等。很多自動(dòng)化測(cè)試只是測(cè)試的執(zhí)行部分，例如把一些測(cè)試執(zhí)行的人工測(cè)試手段做成自動(dòng)化測(cè)試。但是測(cè)試自動(dòng)化不僅僅是只是執(zhí)行，還包括了從環(huán)境的獲取到生成測(cè)試數(shù)據(jù)、執(zhí)行自動(dòng)化測(cè)試，最終生成結(jié)果。如果有問(wèn)題，會(huì)自動(dòng)推送給相關(guān)的人，對(duì)應(yīng)的組織解決。自動(dòng)生成測(cè)試報(bào)告，測(cè)試人員直接拿到測(cè)試結(jié)果。