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

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

以下為陳曉鵬演講實(shí)錄：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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