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

[[283755]]

會(huì)上，DevOps專家顧宇做《DevOps的交付質(zhì)量從需求質(zhì)量開(kāi)始》主題演講。顧宇介紹了企業(yè)DevOps轉(zhuǎn)型的經(jīng)驗(yàn)，并說(shuō)道，“我不推薦企業(yè)在 DevOps 能力不足的情況下做微服務(wù)改造。微服務(wù)應(yīng)當(dāng)是 DevOps 成熟度高之后的必然結(jié)果。否則很多質(zhì)量問(wèn)題會(huì)大幅增加人力成本和時(shí)間成本。在質(zhì)量標(biāo)準(zhǔn)較低的情況下，縮短發(fā)布周期，提升部署頻率是沒(méi)有意義的。”

以下為顧宇演講實(shí)錄：

大家下午好！做開(kāi)發(fā)工程師的同學(xué)請(qǐng)舉手，做測(cè)試的同學(xué)，有沒(méi)有做運(yùn)維的？在之前的大會(huì)上，我都發(fā)現(xiàn)沒(méi)有運(yùn)維的同學(xué)，DevOps有開(kāi)發(fā)，有測(cè)試，有運(yùn)維，但是運(yùn)維的同學(xué)一般不會(huì)來(lái)。我今天做DevOps的交付質(zhì)量從需求質(zhì)量開(kāi)始的主題演講，我來(lái)自某咨詢公司，我們面向高科技、互聯(lián)網(wǎng)和傳統(tǒng)的電信企業(yè)做DevOps方面的咨詢。

我做DevOps的轉(zhuǎn)型和咨詢已經(jīng)有五年的時(shí)間了，也參與制訂過(guò)一些DevOps的標(biāo)準(zhǔn)并為企業(yè)做輔導(dǎo)。我曾經(jīng)做過(guò)測(cè)試，做過(guò)開(kāi)發(fā)，也做過(guò)運(yùn)維，我在這講DevOps，上一個(gè)講師講OverMind，我四年前也開(kāi)發(fā)了一個(gè)開(kāi)源工具，OverMind這個(gè)單詞的意思是《星際爭(zhēng)霸》的蟲族的首腦——主宰。

我今天講的內(nèi)容有三點(diǎn)，先講一下案例，在咨詢公司的好處就是可以碰到不同的企業(yè)，不同的人，在案例中，我給不同企業(yè)做DevOps轉(zhuǎn)型的時(shí)候，發(fā)現(xiàn)測(cè)試的同學(xué)對(duì)測(cè)試的很多概念的理解都是不一樣的。然后再講一下經(jīng)常碰到的技術(shù)性問(wèn)題，最后講一下DevOps的質(zhì)量觀，最重要的是提升需求質(zhì)量的實(shí)踐。

先說(shuō)案例，客戶的領(lǐng)導(dǎo)對(duì)我說(shuō)，產(chǎn)品剛剛完成微服務(wù)改造，需要做DevOps。其實(shí)DevOps是什么一點(diǎn)不重要，關(guān)鍵是DevOps能幫你解決什么問(wèn)題。他們想解決的問(wèn)題是發(fā)布，兩個(gè)月發(fā)布一次版本，產(chǎn)品節(jié)奏是這樣的：用兩周時(shí)間做分析，兩周時(shí)間做開(kāi)發(fā)，兩周時(shí)間做SIT，兩周時(shí)間做UAT。一般來(lái)說(shuō)都不會(huì)達(dá)到這樣的情況。他們的需求分析到5周，開(kāi)發(fā)到4周，給SIT留出充足的時(shí)間進(jìn)行測(cè)試，最后UAT，用戶驗(yàn)收的部門。這導(dǎo)致測(cè)試時(shí)Bug越來(lái)越多，因?yàn)閁AT的時(shí)間不夠，增加了4倍的人集中在一周里做UAT，天天要去解決一堆Bug，每次版本都是這樣發(fā)布的。

我們發(fā)現(xiàn)，很多企業(yè)完成微服務(wù)改造之后，其測(cè)試成本都增加了。因?yàn)?，從前是單體應(yīng)用，后面改成分布式應(yīng)用，需要測(cè)試的點(diǎn)多了，服務(wù)和服務(wù)之間各種功能測(cè)試和非功能性測(cè)試都要測(cè)試，特別是在SIT這部分，這部分增加成本會(huì)帶來(lái)延緩交付周期的結(jié)果。我做微服務(wù)架構(gòu)，也做DevOps架構(gòu)轉(zhuǎn)型，我不推薦企業(yè)在 DevOps 能力不足的情況下做微服務(wù)改造。微服務(wù)應(yīng)當(dāng)是 DevOps 成熟度高之后的必然結(jié)果。否則很多質(zhì)量問(wèn)題會(huì)大幅增加人力成本和時(shí)間成本。在質(zhì)量標(biāo)準(zhǔn)較低的情況下，縮短發(fā)布周期，提升部署頻率是沒(méi)有意義的。

DevOps解決兩個(gè)問(wèn)題，第一是軟件交付效率，另外是提升軟件交付質(zhì)量。質(zhì)量和效率兩個(gè)都想要，兩個(gè)都重要。如何提升軟件質(zhì)量呢？是不是要增加測(cè)試人員和測(cè)試時(shí)間？增加質(zhì)量就會(huì)增加測(cè)試的時(shí)間，導(dǎo)致更多頻次的測(cè)試。那么在我們剛才的例子里，用了交付周期的70%來(lái)做測(cè)試，也增加人了，為什么Bug還是那么多？這是他們當(dāng)時(shí)拋給我的問(wèn)題。

Bug少就是質(zhì)量高嗎？首先第一個(gè)問(wèn)題，Bug是什么？第一個(gè)Bug是來(lái)自于愛(ài)迪生的信，最早的計(jì)算機(jī)Bug是一個(gè)日志，那時(shí)的計(jì)算機(jī)是電子管的，大概有會(huì)場(chǎng)這么大，通過(guò)燈泡電子管來(lái)進(jìn)行計(jì)算。很多燈泡在一個(gè)房間里面發(fā)光發(fā)熱，飛蛾飛上去被高壓擊穿了，就形成了短路，運(yùn)算結(jié)果就出錯(cuò)了，這是機(jī)房管理的失誤，不是軟件開(kāi)發(fā)人員造成的問(wèn)題。當(dāng)談到Bug的時(shí)候，我們會(huì)用不同的詞，Bug在國(guó)際標(biāo)準(zhǔn)里是沒(méi)有定義的。我們現(xiàn)在能找到的定義來(lái)自維基百科，就是軟件Bug。那么，當(dāng)我和客戶談到什么是Bug的時(shí)候，他就愣了一下，他說(shuō)我們的Bug就是指問(wèn)題單，我們就區(qū)分一下這三個(gè)詞。當(dāng)談到問(wèn)題的時(shí)候，你的反應(yīng)是哪個(gè)詞？谷歌在中國(guó)唯一能用的就是翻譯，這里有這么多問(wèn)題，用戶一般都是遇到了問(wèn)題，一個(gè)問(wèn)題在不同人中，因?yàn)閱卧~內(nèi)容是不一樣的，早上我們做自動(dòng)化測(cè)試的時(shí)候，中文這個(gè)東西沒(méi)有辦法表達(dá)詞性。用戶使用中出現(xiàn)的障礙叫做問(wèn)題。另外，什么是缺陷？是與生俱來(lái)的不符合常理的東西，這取決于怎么定義正常。缺陷是在開(kāi)發(fā)過(guò)程中，邏輯不完備產(chǎn)生的意外結(jié)果。什么是故障？這是《黑客帝國(guó)》里面的截圖，就是系統(tǒng)失敗，故障是應(yīng)用程序在運(yùn)行時(shí)出現(xiàn)的不符合期望的結(jié)果。出現(xiàn)的原因很復(fù)雜，有可能是開(kāi)發(fā)引入的，有可能是設(shè)備引入的，有可能是網(wǎng)絡(luò)引入的，也有可能是用戶自己引入的。維基百科是這樣定義Bug的，Bug是計(jì)算機(jī)或者系統(tǒng)中的一個(gè)錯(cuò)誤、瑕疵、失敗或者故障，導(dǎo)致了非預(yù)期的結(jié)果和行為。我們明確Bug定義是為了找到形成的原因，我們這樣定義Bug的原因，是為了找到質(zhì)量低下的問(wèn)題，然后去解決。

準(zhǔn)確定義Bug，就是質(zhì)量改進(jìn)的開(kāi)始，當(dāng)然用戶不關(guān)心是哪一種原因。軟件開(kāi)發(fā)是對(duì)用戶預(yù)期的一種承諾，不符合這種預(yù)期就是質(zhì)量差。我們之前做過(guò)一個(gè)改進(jìn)項(xiàng)目，改進(jìn)質(zhì)量的原因不是增加測(cè)試，是改變這個(gè)程序在交互界面上的用詞，用戶對(duì)行為預(yù)期就是一致的，否則大家對(duì)這個(gè)詞的理解是不一樣的，質(zhì)量就會(huì)下降，這是沒(méi)有增加測(cè)試而提升質(zhì)量的例子。

什么是軟件質(zhì)量？這是ISO在1999年對(duì)軟件質(zhì)量的定義，翻譯過(guò)來(lái)就是軟件產(chǎn)品符合需求的能力。一般的需求，那邊可能是客戶，發(fā)現(xiàn)質(zhì)量問(wèn)題出現(xiàn)在每個(gè)環(huán)節(jié)過(guò)程中，因?yàn)槲覀冊(cè)谧鰷贤ǖ臅r(shí)候會(huì)出現(xiàn)一個(gè)問(wèn)題，那就是真正對(duì)方表達(dá)出來(lái)的想要的內(nèi)容有多少，不想要的內(nèi)容有沒(méi)有表達(dá)出來(lái)，有沒(méi)有記錄下來(lái)，他沒(méi)有表達(dá)出來(lái)的東西你是不是想到了？還有非功能性的部分，有沒(méi)有表達(dá)出來(lái)，要求不能慢，怎么定義這個(gè)慢？一秒鐘之內(nèi)還是三秒鐘之內(nèi)？還有安全性、穩(wěn)定性都沒(méi)有表達(dá)出來(lái)。遺失的需求到哪里去了？語(yǔ)言文字的表達(dá)能力是有限的，包括我們之前說(shuō)的文字，不同的人理解有不同的意思，我們?cè)谶@個(gè)過(guò)程中一定會(huì)忘記一些問(wèn)題，我們?cè)趺窗褯](méi)有想到的問(wèn)題，在需求階段提出來(lái)。

通常的辦法是增加需求文檔。發(fā)現(xiàn)質(zhì)量問(wèn)題是需求原因?qū)е碌?，原?lái)只寫三句話，現(xiàn)在要交另外PPT，Word文章，還有Excel表格，業(yè)務(wù)部門，包括提需求的部門是非常強(qiáng)勢(shì)的，他們經(jīng)常說(shuō)的是給我一套模板，這些人就變成了模板僵尸。我們?cè)谶@個(gè)時(shí)候只關(guān)注做需求結(jié)果的質(zhì)量，并沒(méi)有分析需求活動(dòng)的質(zhì)量。DevOps不僅關(guān)注結(jié)構(gòu)的質(zhì)量，更關(guān)注的每個(gè)活動(dòng)的質(zhì)量。需求文檔是不是能解決質(zhì)量問(wèn)題？在我們的例子里是這樣的，第一個(gè)對(duì)接客戶和用戶是業(yè)務(wù)設(shè)計(jì)環(huán)節(jié)，業(yè)務(wù)BA，中間是產(chǎn)品BA，負(fù)責(zé)產(chǎn)品的研發(fā)，架構(gòu)概要的設(shè)計(jì)，然后是開(kāi)發(fā)進(jìn)行詳細(xì)設(shè)計(jì)，再給產(chǎn)品做評(píng)審，評(píng)審?fù)ㄟ^(guò)之后，這個(gè)方案沒(méi)有問(wèn)題了，把測(cè)試?yán)祥_(kāi)發(fā)，開(kāi)發(fā)講一遍，測(cè)試講一遍，相互確認(rèn)一下。這個(gè)過(guò)程就是需求的過(guò)程，這個(gè)過(guò)程就是我們前面說(shuō)的花費(fèi)五周時(shí)間在做的事情。每個(gè)環(huán)節(jié)會(huì)有四種不同的文檔，到了開(kāi)發(fā)的手上，包括后面用戶測(cè)試的手上，又拿不到這些文檔。

DevOps要打破組織墻，在這個(gè)過(guò)程中，軟件質(zhì)量有兩種，一種叫客觀質(zhì)量，符合質(zhì)量度量標(biāo)準(zhǔn)，比如接口覆蓋率，各種指標(biāo)，比如之前做的項(xiàng)目，單元測(cè)試?yán)锶际前俜种?，用戶就一定?huì)覺(jué)得質(zhì)量好嗎？不一定，產(chǎn)品一定沒(méi)問(wèn)題嗎？也不一定。另外是主觀質(zhì)量，每個(gè)人對(duì)軟件的結(jié)果和過(guò)程的體驗(yàn)，不光包含最終使用這個(gè)軟件的用戶，也包含參與所有環(huán)節(jié)的人，他們體驗(yàn)也算作質(zhì)量，分為內(nèi)部質(zhì)量和外部質(zhì)量。如果團(tuán)隊(duì)之間，開(kāi)發(fā)覺(jué)得需求不夠詳細(xì)，測(cè)試覺(jué)得代碼不夠好，沒(méi)有人改進(jìn)，內(nèi)部質(zhì)量就已經(jīng)先垮了，就不說(shuō)外部質(zhì)量了。

來(lái)講講DevOps測(cè)試觀。每次測(cè)試聽(tīng)到DevOps的時(shí)候，內(nèi)心都是崩潰的。這里講的不是測(cè)試人員和開(kāi)發(fā)人員，而是包括運(yùn)維人員的開(kāi)發(fā)團(tuán)隊(duì)。因?yàn)樵趪?guó)外的很多組織里，測(cè)試人員已經(jīng)被整合到開(kāi)發(fā)團(tuán)隊(duì)里了，所以講的是開(kāi)發(fā)團(tuán)隊(duì)，或者產(chǎn)品團(tuán)隊(duì)，以及運(yùn)維團(tuán)隊(duì)。這會(huì)導(dǎo)致一個(gè)問(wèn)題，DevOps引入中國(guó)的時(shí)候，大家的理解不統(tǒng)一，大家不知道該怎么辦。

回顧一下DevOps的發(fā)展，比利時(shí)人Patrick是DevOps的創(chuàng)始人，他是一個(gè)獨(dú)立的質(zhì)量顧問(wèn)，通俗的講，他就是一個(gè)外包測(cè)試，在比利時(shí)做數(shù)據(jù)遷移的時(shí)候，他白天和開(kāi)發(fā)人員用敏捷的開(kāi)發(fā)方式去開(kāi)發(fā)，得到一個(gè)軟件，下午去機(jī)房和運(yùn)維工程師去上線進(jìn)行測(cè)試，這是他的工作。他發(fā)現(xiàn)這兩個(gè)團(tuán)隊(duì)，白天和下午工作的方式有些問(wèn)題，因?yàn)樯衔鐪y(cè)得好好的，下午就完全不一樣了，為什么不把兩個(gè)團(tuán)隊(duì)拉到一起？后面就有了DevOps這個(gè)運(yùn)動(dòng)。從一開(kāi)始，DevOps本質(zhì)上就是一個(gè)端到端的質(zhì)量改進(jìn)運(yùn)動(dòng)，關(guān)注的是質(zhì)量，把質(zhì)量提升之后再去提升速度。DevOps的質(zhì)量觀是每個(gè)人都對(duì)質(zhì)量負(fù)責(zé)，測(cè)試是驗(yàn)證需求的手段，當(dāng)你的需求沒(méi)有提出來(lái)的時(shí)候，質(zhì)量是沒(méi)有辦法保證的。測(cè)試在整個(gè)團(tuán)隊(duì)里面是一項(xiàng)任務(wù)，不是一個(gè)角色，每個(gè)人都可以做測(cè)試這件事，有測(cè)試前、測(cè)試中、測(cè)試后，每個(gè)人都可以做不同的事情，非功能測(cè)試和功能測(cè)試同等重要，還有很多生產(chǎn)環(huán)境的問(wèn)題，特別是微服務(wù)架構(gòu)，除了功能性都正常了，每個(gè)服務(wù)都拼起來(lái)之后仍然正常嗎？做測(cè)試這件事情越早越好，越頻繁越好，于是有了自動(dòng)測(cè)試開(kāi)發(fā)。事事可測(cè)，時(shí)時(shí)可測(cè)。從需求的開(kāi)始，我之前在敏捷團(tuán)隊(duì)，每天討論一件事情，我們問(wèn)兩個(gè)問(wèn)題，第一，這個(gè)東西怎么測(cè)？第二，這個(gè)東西怎么自動(dòng)化的測(cè)？這已經(jīng)形成了我們團(tuán)隊(duì)的文化，這就是測(cè)試的文化。所以，在一個(gè)研發(fā)團(tuán)隊(duì)里面，要問(wèn)的問(wèn)題是怎么測(cè)，怎么自動(dòng)化的測(cè)試，要想辦法提升自動(dòng)化的效率和自動(dòng)化的覆蓋度。在設(shè)計(jì)時(shí)就偏向測(cè)試，我們?cè)谧鲎詣?dòng)化測(cè)試的時(shí)候，前端都不好測(cè)試，那是因?yàn)榍岸藳](méi)有按照測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的方式去設(shè)計(jì)，在設(shè)計(jì)時(shí)沒(méi)有把自動(dòng)化測(cè)試的應(yīng)用性放到前端的工程和項(xiàng)目里考慮，所以就變得很難測(cè)。我們選了一個(gè)折中的方法，用MVVM模型把中間的ViewModel層簡(jiǎn)單的測(cè)一下，把發(fā)布的內(nèi)容拆分到幾乎沒(méi)有發(fā)布風(fēng)險(xiǎn)的程度，就隨時(shí)可以上線了。

發(fā)布風(fēng)險(xiǎn)的技術(shù)有幾點(diǎn)，第一是減少代碼提交內(nèi)容，每次發(fā)布的內(nèi)容很少，要快速的知道是哪行代碼出現(xiàn)了問(wèn)題。然后是TDD，持續(xù)集成和部署，還有是金絲雀發(fā)布，灰度發(fā)布，藍(lán)綠部署。微服務(wù)就是在測(cè)試周期長(zhǎng)的情況下，把應(yīng)用拆小來(lái)進(jìn)行測(cè)試。自動(dòng)化測(cè)試能夠紋理運(yùn)行，就一定能獨(dú)立部署，通過(guò)拆分自動(dòng)化測(cè)試對(duì)應(yīng)的代碼來(lái)進(jìn)行服務(wù)的拆分，拆分出來(lái)的服務(wù)一般都沒(méi)有問(wèn)題，因?yàn)橛袦y(cè)試做一層保護(hù)。

提升需求質(zhì)量的實(shí)踐，第一是用戶故事地圖，用好的方式記錄需求，我們把用戶的一句話，比如“我想要定外賣的軟件”拆分，直到每個(gè)測(cè)試的代碼，把所有用戶故事全部講完，用戶故事的概念，給別人介紹特別好軟件的時(shí)候，會(huì)用講故事的方法，這種方法能描述我們的軟件，讓我們知道軟件是做什么的。推薦一本書，《用戶故事地圖》，里面有很多關(guān)于需求和質(zhì)量的金句。我們不僅關(guān)注寫需求的結(jié)果，也關(guān)注如何實(shí)現(xiàn)需求的過(guò)程，以及參與人的體驗(yàn)。如果你的團(tuán)隊(duì)沒(méi)有在一起對(duì)用戶故事進(jìn)行充分的討論，就說(shuō)明方式不對(duì)。我們用了比較小但是比較有效的，用“需要”替代“需求”，用戶提需求的時(shí)候是求著你，而需要的時(shí)候，態(tài)度和想法，包括問(wèn)的問(wèn)題都是不一樣的，產(chǎn)生的結(jié)果也是不一樣的，大家可以試一試，我們不再問(wèn)用戶的需求是什么，我們問(wèn)的是他們的需要是什么。

好的用戶故事有3C原則和INVEST原則，3C原則，Card、Conversation、Confirmation，一定是很少的記錄，很多的討論，要把你的解決方案跟用戶達(dá)成一致，始終由你來(lái)引導(dǎo)整個(gè)軟件的開(kāi)發(fā)。INVEST原則，首先是可獨(dú)立的，我們希望故事之間的開(kāi)發(fā)順序不影響最終結(jié)果，是在一個(gè)迭代周期內(nèi)，不影響最終結(jié)果，這是故事的力度?？蓞f(xié)商的，如果用戶直接告訴你怎么做，就是不可協(xié)商的，所以要反客為主，來(lái)引導(dǎo)這個(gè)需求的方向。有價(jià)值的，設(shè)兩到三個(gè)高優(yōu)先的，越迫切的就表示價(jià)值是越高的。小的，可估計(jì)的，可測(cè)試的，這是可相關(guān)的，如果過(guò)大就沒(méi)有辦法估計(jì)，沒(méi)有辦法給出準(zhǔn)確的時(shí)間，所以要做得小。我們對(duì)需求的可測(cè)試是這個(gè)要求，如果不能自動(dòng)化測(cè)試，就不是可測(cè)試的。因?yàn)橹挥锌梢宰詣?dòng)化測(cè)試的那些規(guī)格，才是清晰的，不能自動(dòng)化測(cè)試的規(guī)格都是模糊的。

如何產(chǎn)生用戶故事？通過(guò)用戶故事工作坊，在一個(gè)工作坊里大家一起討論。這個(gè)人是下議院的院長(zhǎng)，他經(jīng)常說(shuō)的一個(gè)詞就是“保持秩序”，在這個(gè)工作坊里，一定要先讓用戶說(shuō)，不要打斷，否則很快會(huì)導(dǎo)致?tīng)?zhēng)論。先讓用戶充分的表達(dá)，因?yàn)樗琴|(zhì)量最后的決策者。用戶故事，要做到“5W1H”，確認(rèn)用戶（Who），確認(rèn)功能（What），確認(rèn)價(jià)值（Why），確認(rèn)場(chǎng)景（When & Where），確認(rèn)規(guī)格（How），我們勾畫的時(shí)候都會(huì)產(chǎn)生新的問(wèn)題，產(chǎn)生新的Bug，在原因回溯的時(shí)候，找到這些原因，放到需求階段，去提出這些問(wèn)題，在這個(gè)階段去解答。當(dāng)把沒(méi)有問(wèn)到的問(wèn)題積累到列表的時(shí)候，軟件交付的質(zhì)量會(huì)越來(lái)越高。還有，一定不要讓用戶告訴你怎么做，如果導(dǎo)航員亂指揮，開(kāi)車的人就要走錯(cuò)方向，還是應(yīng)該讓專業(yè)的司機(jī)去開(kāi)車。

還有實(shí)例化需求，要讓客戶舉例子，有清晰的規(guī)格。先確認(rèn)規(guī)格和結(jié)果，不要先確認(rèn)形式，從輸入到輸出，中間有很多種形式，先確認(rèn)結(jié)果是什么，輸入是什么，后面再進(jìn)行設(shè)計(jì)。語(yǔ)言的表達(dá)一般來(lái)說(shuō)是很有限的，我們構(gòu)建紙片小人，去討論，去設(shè)計(jì)，把故事講給用戶聽(tīng)，講清楚，大家確認(rèn)之后再做開(kāi)發(fā)。還有一點(diǎn)，用戶故事一定要講出來(lái)，和所有人都確認(rèn)一遍，自己講完再讓用戶講一遍，作確認(rèn)。

用一句話描述原則，如果一句話表達(dá)不完，這個(gè)內(nèi)容就很大，需求就很大。我們使用需求規(guī)格成熟度，好的需求規(guī)格有用戶故事，有驗(yàn)收條件，有測(cè)試場(chǎng)景分析，按格式寫作用戶故事，每個(gè)故事都有驗(yàn)收條件，有BDD風(fēng)格的驗(yàn)收條件，有基于驗(yàn)收條件的測(cè)試場(chǎng)景和測(cè)試用例分析，能夠自動(dòng)化驗(yàn)收用戶故事。我們要求所有團(tuán)隊(duì)要達(dá)到第三級(jí)和第四級(jí)之間。我們不用文檔，用思維導(dǎo)圖，我們的需求到測(cè)試，到結(jié)果之間都是一一對(duì)應(yīng)的，當(dāng)思維導(dǎo)圖再大的時(shí)候就知道怎么去拆。

介紹TDD的時(shí)候，發(fā)現(xiàn)大家的了解不一樣。TDD有三種，第一種是測(cè)試用例驅(qū)動(dòng)開(kāi)發(fā)，測(cè)試人員驅(qū)動(dòng)開(kāi)發(fā)人員，最后是測(cè)試計(jì)劃驅(qū)動(dòng)開(kāi)發(fā)計(jì)劃。測(cè)試人員在需求階段要分析明確測(cè)試用例，一開(kāi)始大家對(duì)TDD都是抗拒的，因?yàn)樵黾恿斯ぷ鲿r(shí)間，后續(xù)用了一段時(shí)間TDD，所有開(kāi)發(fā)人員都說(shuō)不要停。而且，當(dāng)自動(dòng)化測(cè)試的覆蓋率不到76%以上的時(shí)候，不會(huì)減少測(cè)試人員的工作量。還有要盡量采用自動(dòng)化的方式實(shí)現(xiàn)測(cè)試用例，如果不好實(shí)現(xiàn)，需要進(jìn)行評(píng)估和評(píng)審。開(kāi)發(fā)人員以完成測(cè)試用例為驗(yàn)收條件，自己沒(méi)有測(cè)過(guò)是不能交給測(cè)試的，這是一個(gè)起碼的要求。

測(cè)試人員驅(qū)動(dòng)開(kāi)發(fā)人員，就是測(cè)試人員不再做重復(fù)的測(cè)試工作，而是作為一個(gè)用戶來(lái)驗(yàn)收交付的軟件，測(cè)試的工作是一個(gè)任務(wù)，讓開(kāi)發(fā)人員去完成。測(cè)試人員有兩種轉(zhuǎn)型，一種是向后做DevOps，一種是向QA，向業(yè)務(wù)的方向去做前項(xiàng)，在這個(gè)過(guò)程中QA和BA是可以輪換的。我做一段時(shí)間需求分析，再做一段質(zhì)量驗(yàn)收，都是作為用戶的角度，要求開(kāi)發(fā)人員去開(kāi)發(fā)出符合測(cè)試質(zhì)量要求的產(chǎn)品。大部分的QA或者測(cè)試人員最后都在團(tuán)隊(duì)里面晉升了，變成一個(gè)團(tuán)隊(duì)的leader。測(cè)試計(jì)劃驅(qū)動(dòng)開(kāi)發(fā)計(jì)劃，第一點(diǎn)好處是能夠分?jǐn)倻y(cè)試壓力，最后一周的UAT測(cè)試分散到每一天，每天的測(cè)試量都比較平均，根據(jù)測(cè)試計(jì)劃倒排開(kāi)發(fā)計(jì)劃，采用拉動(dòng)的方式，而非推動(dòng)。

落地DevOps的關(guān)鍵是讓用戶的發(fā)布和測(cè)試拆分到每次發(fā)布風(fēng)險(xiǎn)可以高度可控的程度，如果能拆到兩周，兩周就能開(kāi)發(fā)，如果能拆到一天，每天都能發(fā)布，我們最快的是15分鐘發(fā)布一次，力度就是一行代碼。當(dāng)把要求做得很高的時(shí)候，我們發(fā)現(xiàn)一個(gè)問(wèn)題，我們兩個(gè)人討論了一天，寫了很多測(cè)試代碼，測(cè)試用例，結(jié)束的時(shí)候只寫了一行代碼，就是高度討論，經(jīng)過(guò)了充分測(cè)試的結(jié)果，這個(gè)結(jié)果是我們場(chǎng)景中最優(yōu)化的，讓每個(gè)提交變得更小，風(fēng)險(xiǎn)更可控。

我的演講到這里就結(jié)束了，謝謝大家！