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

敏捷和DevOps

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

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

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

測試債務(wù)

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

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

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

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

測試的焦點：業(yè)務(wù)價值的質(zhì)量

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

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

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

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

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

測試左移和測試右移

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

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

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

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

是否在團隊組建之初，就要把整個自動化測試的能力構(gòu)建起來呢？其實這有一個過程，下面從軟件的成熟周期的角度，看一下如何構(gòu)建測試自動化的能力。

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

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

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

團隊規(guī)模對測試建設(shè)的影響

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

隨著項目的進一步擴大，逐漸增長到5-10人的團隊規(guī)模，這時測試工作量突然增加，可能會有專門的測試人員進來，這個測試人員會去和開發(fā)人員進行串聯(lián)，把需求轉(zhuǎn)化成自動化測試的用例，搭建持續(xù)集成，逐步演進一些測試手段?！@個階段已經(jīng)開始做一些自動化的嘗試。

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

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

自動化測試和測試自動化

這里要澄清一個概念，就是測試自動化（Test Automation）。

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