2019年10月26日，由Testin主辦的第二屆NCTS中國云測試行業(yè)峰會在京召開，此次峰會以“AI+未來”為主題，匯聚來自國內(nèi)外測試領(lǐng)域的知名專家學(xué)者、領(lǐng)先企業(yè)決策者、高層技術(shù)管理者、媒體從業(yè)者等，共同探討高端云測試技術(shù)，幫助測試從業(yè)者了解最前沿行業(yè)趨勢，及最新的行業(yè)實踐。

會上，中國卓越測試中心負(fù)責(zé)人陳曉鵬做《基于BDD的敏捷測試案例分享》主題演講，陳曉鵬指出，“做自動化測試，一定要跟CICD和DevOps做集成，把從Idea到實施上線到最終交付市場的整條鏈條打通，只有實現(xiàn)業(yè)務(wù)端的敏捷，自動化測試才能發(fā)揮最大的價值。”

以下為陳曉鵬演講實錄：

大家下午好，非常高興能夠參加Testin舉辦的NCTS中國云測試行業(yè)峰會，我在北京參加活動比較少，所以先自我介紹，我叫陳曉鵬，目前在某國際TOP3的IT咨詢公司負(fù)責(zé)中國區(qū)測試業(yè)務(wù)，也就是中國卓越測試中心負(fù)責(zé)人，現(xiàn)在整個測試團隊規(guī)模大概200人服務(wù)30-40個國內(nèi)外項目。我個人的背景很簡單，在測試領(lǐng)域工作18年多，相對來講比較專一，期間沒有換過其它領(lǐng)域。但是從服務(wù)的公司性質(zhì)來講，前6年是在民營企業(yè)，后12年是在外企。外企經(jīng)歷也非常集中，主要在埃森哲、IBM、德勤這三家全球最領(lǐng)先的 IT咨詢公司工作。

我是2008年開始和敏捷結(jié)緣。不過在21世紀(jì)的前10年CMMI在中國非?；穑援?dāng)時雖然接受過敏捷的相關(guān)培訓(xùn)，但總覺得敏捷在中國落地有點難，畢竟當(dāng)時是CMMI的天下。不過2010年之后敏捷在中國卻發(fā)展得紅紅火火。2013年的時候，我在IBM開始接觸 DevOps，然后一直在中國推廣DevOps。我記得第一次做DevOps的講座應(yīng)該是2013年在深圳科技園，當(dāng)時很多人連DevOps如何發(fā)音、是什么都不知道。不過后來DevOps也發(fā)展很快。到如今敏捷也好、DevOps也好，已經(jīng)在中國如火如荼的發(fā)展，每個人都耳熟能詳。

現(xiàn)在如果談敏捷、談DevOps，大家可以在網(wǎng)上搜索到很多很多介紹它們的書籍和資料，但是大家有沒有在網(wǎng)上搜索過關(guān)于敏捷測試的書呢？據(jù)我所知，現(xiàn)在市面只有兩本比較出名的專門談敏捷測試的書，它們出自同一個美國女性敏捷專家Lisa Crispin。她這兩本書是姐妹篇，已經(jīng)被中國的譯者翻譯成中文出版。除此之外沒有太多其它敏捷測試相關(guān)的書籍了，所以我在2015年開始專門研究敏捷測試這樣一個話題。本來我想在今天下午去分享敏捷測試方法論體系的，但是我看大會上都想聽落地的東西，所以今天下午我給大家?guī)砹艘粋€實實在在的敏捷測試相關(guān)的落地案例分享。

這個項目的客戶是一家娛樂公司，我們在2017年和他們做接觸，客戶已經(jīng)有了一套會員管理系統(tǒng)，但是該系統(tǒng)比較舊，技術(shù)比較落后，但客戶非常有想法也非常激進(jìn)，他對我們說需要用業(yè)界最新的技術(shù)、最好的方法、最先進(jìn)的理念來開發(fā)一套新的會員管理系統(tǒng)，這是當(dāng)時客戶的目標(biāo)。另外一個客戶的目標(biāo)是希望在半年內(nèi)把項目上線，所以這是當(dāng)時客戶給我們的任務(wù)。

我們?nèi)绾螒?yīng)對呢？通過對項目的風(fēng)險分析后，我們發(fā)現(xiàn)挑戰(zhàn)在于三方面內(nèi)容，第一是技術(shù)方面，客戶說要采用新的IT技術(shù)，那么新的IT技術(shù)勢必會帶來很大的技術(shù)風(fēng)險。新的技術(shù)到底成熟不成熟，有沒有相應(yīng)的資源懂這些技術(shù)，這是一個很大的風(fēng)險；第二是進(jìn)度非常緊而質(zhì)量要求很高，需要在半年內(nèi)上線所有的功能，把老系統(tǒng)替換掉，用新系統(tǒng)做承接。同時，因為會員管理系統(tǒng)涉及到會員資金管理，大家知道如果系統(tǒng)一旦涉及到金額算錯或者有問題，那勢必帶來非常大的負(fù)面影響；第三是采用敏捷測試Scrum加BDD開發(fā)模式來開發(fā)，在2016年這樣的開發(fā)模式還處于很多人在嘗試但還不是很成熟的狀態(tài)。

所以，我們當(dāng)時組成了項目組，大概規(guī)模是50人左右，分成5個Scrum Team，每個Team大概8-9人的規(guī)模。其中每個Team包含兩個BA，這兩個BA在客戶的香港辦公室駐場，和客戶近距離溝通，獲取客戶需求。剩下6個人都在廣州遠(yuǎn)程，有5個人是開發(fā)，1個人負(fù)責(zé)功能測試。除此之外還有兩個Share的測試開發(fā)工程師是在不同Scurm Team之間共享的，所以整個項目是40-50人的規(guī)模。這個敏捷團隊其實屬于分布式的，因為有香港團隊還有大陸團隊，而且也包含多個Scrum Team。

這個項目的技術(shù)架構(gòu)底層采用了亞馬遜AWS云，上面是mongoDB數(shù)據(jù)庫，再往上采用容器技術(shù)和微服務(wù)架構(gòu)，然后通過暴露的RestfulAPI給到前端，前端用Angular JS來實現(xiàn)，這是技術(shù)層的介紹。同時在開發(fā)模式上引用了兩個敏捷實踐：一個是Scrum，Scrum大家聽了很多，很多人也都在用Scrum；另外一個是BDD行為驅(qū)動開發(fā)。這是另一種敏捷實踐，它和Scrum不沖突，而且還可以融合在一起，這就是當(dāng)時的情況。

從整個項目的技術(shù)特點和開發(fā)特點，它們會對測試會帶來四個風(fēng)險：第一個風(fēng)險是技術(shù)風(fēng)險。在2017年初，很多測試人員都不具備云計算和微服務(wù)的知識，在這樣一個技術(shù)平臺下要做測試的話，如何保證在新技術(shù)下能夠確保質(zhì)量是第一個挑戰(zhàn)；第二個挑戰(zhàn)是進(jìn)度風(fēng)險，計劃整個項目在半年完成上線，同時兩周一次的迭代節(jié)奏是非?？斓?，大家想想兩周時間要有開發(fā)還要有測試，節(jié)奏怎樣配合確實是非常大的挑戰(zhàn)；第三是質(zhì)量風(fēng)險，剛才提到因為系統(tǒng)當(dāng)中涉及到金額信息，如果計算錯誤會帶來很大的負(fù)面影響，所以在質(zhì)量上也有很大的壓力；第四點是管理風(fēng)險，在2017年Scrum大家可能比較熟悉了，但是BDD到底怎么玩其實項目也沒有太多的經(jīng)驗，特別是對測試人員。測試人員怎么融合在整個敏捷的流程里面其實是很大的挑戰(zhàn)。

那么，如何面對這四大挑戰(zhàn)呢？我們當(dāng)時總結(jié)了測試難點后經(jīng)過分析和尋找對策，最后把它歸納成兩個策略：一個是自動化測試，我稱之為倚天劍；另一個是持續(xù)集成，我稱之為屠龍刀。這兩招在現(xiàn)在看來可能不算太新的亮點，但在3年前還算蠻新的一次嘗試了。

關(guān)于自動化測試，很多人會講這沒有什么特別的，因為我在項目也在用自動化測試啊。那到底有什么區(qū)別呢？我這里講的自動化測試是分層自動化測試的概念，分層自動化是最近這幾年測試的一個流行趨勢。何謂分層自動化？就是指我們做自動化測試不能一直只是往UI層的自動化測試方向發(fā)力，為什么不能這樣發(fā)力呢？因為UI層的自動化比較脆弱、不穩(wěn)定，開發(fā)和維護(hù)成本比較高。前幾年起，包括騰訊等很多大廠都漸漸的不再往UI自動化做投入，而是把測試精力下沉到下一個級別，比如API測試，甚至單元測試。今年上半年我和騰訊手機管家的測試負(fù)責(zé)人一起聊天，手機管家自動化測試的UI測試只占不到20%，大部分是通過API測試來保證的?？梢钥吹?，分層自動化已經(jīng)是一個趨勢了。無論從風(fēng)險降低程度，從成本節(jié)省程度來講，都應(yīng)該這么做。所以，在分層自動化這部分，我們當(dāng)時想的是如何把UI層，API層和單元測試層都覆蓋來減少風(fēng)險。

關(guān)于持續(xù)集成，這里我為什么沒有強調(diào)DevOps？因為當(dāng)時在這個項目里Ops運維側(cè)不由我們這邊控制，是客戶管控的，所以我們沒有辦法做到端到端閉環(huán)的環(huán)境。當(dāng)時我們只是覆蓋到UAT，沒有到運維，所以我們叫做持續(xù)集成。

我一直認(rèn)為，所謂的自動化測試如果拋開CI/CD、拋開DevOps去談，從整個項目來講自動化測試的價值只局限于非常小的部分；做自動化測試，一定要跟CI/CD或DevOps做集成，把從Idea到實施上線到最終交付市場的整條鏈條打通，只有實現(xiàn)業(yè)務(wù)端的敏捷，自動化測試才能發(fā)揮最大的價值。

那么策略是有了但是怎么落地才是最重要的。我們的第一個方式是自動化測試，由于項目開發(fā)采用BDD方式，所以自動化框架選擇上我們當(dāng)然毫無疑問選擇了支持BDD的框架Cucumber。其實Cucumber從我的理解上來講并不能稱之為自動化測試框架，我覺得更多的作用是能夠一個所謂用自然語言編寫的需求能自動翻譯成自動化測試的代碼框架，這是一個非常非常大的好處。如果在座各位年紀(jì)和我差不多的話，你一定會聽說過有一個工具ROSE。如果開發(fā)出身的話，一定會知道做UML統(tǒng)一建模語言設(shè)計，那么統(tǒng)一建模語言設(shè)計工具ROSE在2000年左右是所有開發(fā)人員必須得學(xué)的一個工具。那個工具有一個非常大的好處，就是通過畫UML圖可以自動轉(zhuǎn)化成代碼框架。其實Cucumber就是和ROSE有異曲同工之妙，可以把自然語言的需求直接翻譯成自動化測試代碼框架。在這種情況下，自動化測試工程師所要做的，就是在代碼框架里填寫業(yè)務(wù)邏輯和驗證規(guī)則就OK了。在某種意義上來講，這能夠提高我們自動化腳本的編寫速度，這就是我們當(dāng)時采用Cucumber框架的原因。

大家知道在用BDD開發(fā)模式時，在需求端要用一個標(biāo)準(zhǔn)化的或者說規(guī)定好的語法下來編寫，這個語法我們叫做Gherkin語言，這要求所有需求都要采用一種叫GWT的方式，也就是給我什么樣的場景，什么樣條件下會發(fā)生什么樣的一個結(jié)果。那么用GWT方式有什么好處呢？如果說我們在需求階段如果用傳統(tǒng)方式去做需求分析的話，一定會涉及到首先需要從業(yè)務(wù)需求轉(zhuǎn)變成為系統(tǒng)需求，再從系統(tǒng)需求轉(zhuǎn)變成開發(fā)需求，需求的轉(zhuǎn)換過程會存在有信息傳遞的損失還有翻譯錯誤的風(fēng)險。我曾經(jīng)做過一個項目的咨詢，為某移動公司系統(tǒng)做缺陷分析，一年有400多個上線后缺陷，我當(dāng)時是一個一個分析后去歸類，發(fā)現(xiàn)大概有15%的缺陷是因為需求不明確導(dǎo)致開發(fā)理解和需求不一致。通過BDD方式是能夠解決這個問題，因為通過BDD方式在整個項目里只有唯一的需求描述，你看不到還有什么所謂的業(yè)務(wù)需求、開發(fā)需求、系統(tǒng)需求，沒有那么多需求版本了，你只有一份，無論是需求人員，開發(fā)人員，測試人員拿到的都是同一份的需求。我覺得BDD最大的好處，就是減少了項目成員對需求理解層面的差異和不一致，完美解決傳統(tǒng)項目里所帶來的需求問題。所以采用了BDD的這個Gherkin語法去描述需求，需求通過Cucumber框架翻譯成自動化測試代碼框架，翻譯完自動化測試工程師只需要寫一些業(yè)務(wù)代碼邏輯就可以了。

我們當(dāng)時除了集成UI自動化測試工具之外，還把API接口測試的工具集成進(jìn)去了，為什么要這么做呢？其實我們想實現(xiàn)所謂分層自動化的能力，也就是說讓框架既能支持UI層自動化，也能支持API自動化，那很多人會問UT單元測試呢？單元測試由開發(fā)人員通過Junit去實現(xiàn)。

總而言之，測試金字塔由三個測試層級去做覆蓋。我們基于Cucumber做了大量二次開發(fā)的工作，大家會看到原始的Cucumber框架就在這里，就是這么一點的東西，我們在原始Cucumber框架上做了很多二次開發(fā)的工作，包括驅(qū)動層支持Selenium，HttpClient和Appium等，通過插件方式使得這樣一個自動化平臺不僅僅支持Web、API，還可以支持Mobile。

另外，在上層做封裝。比如我們對元素管理，大家知道做UI的自動化最頭疼的就是對象的改變，對象改變后很多時候必須要調(diào)腳本，這使我們做UI自動化的時候，腳本維護(hù)上工作量很大，因此，我們也在做很多這方面的改進(jìn)。這里包括控件優(yōu)化，還有封裝，配置管理，數(shù)據(jù)管理等。比如，測試數(shù)據(jù)可以從數(shù)據(jù)庫、表格導(dǎo)入；包括異常管理，出現(xiàn)問題以后有自動截屏，自動獲取日志，將信息自動提供給開發(fā)人員。再上層集成了Jenkins和email，Jenkins可以做交付流水線編排和管理，能夠使它達(dá)到每日構(gòu)建能力，通過每日構(gòu)建相當(dāng)于不光只做UI測試的任務(wù)，可以做單元測試、API測試和UI測試三個層級。當(dāng)然和郵件集成現(xiàn)在很多人說郵件很慢的，所以我們除了郵件還可以做更實時的短信通知，方便出問題以后馬上有人做跟進(jìn)。

這個框架特點有五個，第一是確保腳本穩(wěn)定性大大增強，同時使用Cucumber加快自動化測試腳本的開發(fā)，縮減了開發(fā)時間，提升了效率；第二是通過封裝手段，使得在寫腳本的時候，不用再用Xpath方式去定位對象，這樣操作很慢，我們會用更簡便的識別方式去實現(xiàn)，使得我寫腳本時候可以大大提速；第三是易讀性，Cucumber大家知道用GWT語法寫需求，這個無論開發(fā)人員也好，測試人員也好，甚至業(yè)務(wù)人員都能很容易讀懂你的腳本；第四是易擴展，可以支持APP，WEB；第五是易維護(hù)，它有截屏截圖、日志log等來幫助開發(fā)定位。這是我們當(dāng)時在自動化測試方面做的一些工作。

剛才講到的是自動化實踐，但是自動化測試或者說測試如何融入在一個Scrum流程里，我估計在座很多同學(xué)可能都有同樣的問題，測試在敏捷環(huán)境中到底怎么做？和傳統(tǒng)測試是不是有很大變化？這里我給一個圖，這個圖相對來講比較簡單，但我們?yōu)榱诉@個流程圖足足花了兩個月的時間才摸索出來，是實實在在通過項目實踐摸索出來的。

如果大家了解Scrum，我們在每一個Sprint開始時，肯定會有迭代計劃會，在計劃會的時候，所有的相關(guān)人員都需要參加，無論是BA，行業(yè)SME，開發(fā)測試人員都要參加。參加完這個計劃會后，會確認(rèn)本次計劃會做哪些用戶故事。確認(rèn)用戶故事后，開發(fā)人員會進(jìn)行開發(fā)構(gòu)建和單元測試。測試人員做什么呢？測試人員會做ET，探索式測試。測試開發(fā)工程師做什么呢？首先會看本次用戶故事是否能夠做自動化測試，如果不行的話就停止，如果可以的話就需要做自動化測試準(zhǔn)備。

其中大家看到自動化測試任務(wù)進(jìn)度條被迭代結(jié)束時間線分成兩邊，也就是自動化測試任務(wù)跨了兩個迭代。自動化測試任務(wù)和其它任務(wù)比起來偏后了。為什么會偏后？因為我們當(dāng)時摸索出來一個經(jīng)驗，就是自動化測試會在第二周星期三開始才真正做自動化腳本開發(fā)。為什么會這樣呢？因為我們當(dāng)時發(fā)現(xiàn)，在最開始做自動化腳本開發(fā)的時候，因為那時開發(fā)人員還沒有想好想法，在開發(fā)過程中會看到界面變來變?nèi)?，前端非常不穩(wěn)定，那么這個時候你做腳本開發(fā)的時候，你會發(fā)現(xiàn)需要跟著經(jīng)常調(diào)整，這種情況下會浪費自動化工程師的很大精力。所以我們當(dāng)時是等到相對穩(wěn)定的時候再去做自動化腳本的開發(fā)，這就是為什么會在第二周的周二或者周三開始做腳本的開發(fā)。而自動化測試任務(wù)的完成就要到下一個迭代的第一周周三左右的時間了，這就是為什么自動化測試任務(wù)跨了兩個迭代。

在座可能有些人會問本次迭代自動化測試沒有完成那怎么保證質(zhì)量？因為本次Sprint的質(zhì)量會有這個功能測試人員通過做探索式測試來保證，而本次之前的Sprint質(zhì)量是通過執(zhí)行自動化回歸測試的時候去覆蓋，也就是N-1的迭代質(zhì)量是自動化回歸搞定，第N迭代質(zhì)量由探索式測試搞定，所以沒有什么問題。等到N+1迭代時，會把N迭代開發(fā)好的自動化腳本加到下一次回歸用例庫里，又變成下一個輪回了。這是我們摸索幾個Sprint以后總結(jié)出來的，是一個關(guān)鍵點。

剛剛講到的是自動化測試解決方法，我們實現(xiàn)了分層次自動化，實現(xiàn)API和UI自動化。接下來我們把它融合在集成的CI/CD場景里面，這是我們CI/CD的集成場景，可以看到開發(fā)人員寫完代碼以后不會直接提交到代碼配置庫里，會在本地先做代碼掃描，然后做開發(fā)的JUnit單元測試，沒有問題了才把代碼提交到GIT里。提交到GIT后由CI/CD流程做保障。Jenkins開始構(gòu)建，Jenkins先做服務(wù)端的代碼掃描，因為剛才做的是本地端的。做完服務(wù)端代碼掃描，然后做Docker部署，做完部署后首先先觸發(fā)Cucumber做API測試，然后再觸發(fā)Cucumber做UI測試。大家想為什么有先后順序？因為API執(zhí)行效率最高，執(zhí)行一個API接口的測試一兩秒就已經(jīng)能夠得到結(jié)果了，然后跑一個UI腳本可能需要幾分鐘。所以一般來說我們通過先做API，API沒有問題了才往UI層做自動化，如果API有問題就停止，然后去解決，跑完UI后沒有問題了，再通過人工做探索式手工測試。手工測試如果發(fā)現(xiàn)問題，那么就提交Bug，然后回到前面開發(fā)人員去修改代碼和單元測試，所以這是一個持續(xù)集成的工具鏈，通過這樣一個場景能夠使得整個效率在兩周之內(nèi)把它測試完，而且兩周之內(nèi)確實能夠測試完，這就是整體的集成測試場景。

另外我想補充一點，有些人以為只要把工具鏈搭建好了就實現(xiàn)了DevOps，這是理解有誤。我們所說的DevOps不僅僅只是一條工具鏈，DevOps除了工具上的實施之外還有很多方面，包括人、組織、流程，這些方面都需要做改變才能夠真正實現(xiàn)。

下面這個是一個持續(xù)集成的截圖過程，會看到我們在Jenkins里做配置，每日自動觸發(fā)，然后下面是自動化測試報告，會有不同的執(zhí)行結(jié)果狀態(tài)，還有運行日志和記錄截圖，每天把信息通過郵件或者溝通，短信當(dāng)然沒有那么詳細(xì)，只是有問題的時候通過短信通知，比如說半夜會通知。但是郵件就比較詳細(xì)，每一個開發(fā)人員早上來了以后發(fā)現(xiàn)有郵件點擊開就可以看到問題，馬上就可以進(jìn)行修復(fù)。

綜上所述，整個項目我總結(jié)有三個收獲：第一是實現(xiàn)全棧式自動化測試，從單元測試、到API測試，再到UI測試，測試金字塔都覆蓋到了。單元測試是開發(fā)人員做，但是通過Jenkins集成。我們當(dāng)時做的API自動化測試覆蓋率達(dá)到80% ，UI覆蓋率達(dá)到65%；第二個是我們當(dāng)時在這樣一個所謂比較新的技術(shù)環(huán)境下，整個項目的質(zhì)量得到保證，我剛才也介紹了我們怎么通過自動化一步步保證質(zhì)量，減了上線后的缺陷，我們這個項目上線以后缺陷很少。所以節(jié)省很多返工工作量；第三是遵循了BDD和Scrum開發(fā)模式，開發(fā)人員測試人員緊密合作互相配合，使整個速度加快。所以整個案例是是結(jié)合了敏捷Scrum和真正使用BDD方式再結(jié)合自動化、結(jié)合CIC/D的整個過程，這就是我今天想給大家分享的實戰(zhàn)案例。