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

[[283755]]

會上，DevOps專家顧宇做《DevOps的交付質量從需求質量開始》主題演講。顧宇介紹了企業DevOps轉型的經驗，并說道，“我不推薦企業在 DevOps 能力不足的情況下做微服務改造。微服務應當是 DevOps 成熟度高之后的必然結果。否則很多質量問題會大幅增加人力成本和時間成本。在質量標準較低的情況下，縮短發布周期，提升部署頻率是沒有意義的。”

以下為顧宇演講實錄：

大家下午好！做開發工程師的同學請舉手，做測試的同學，有沒有做運維的？在之前的大會上，我都發現沒有運維的同學，DevOps有開發，有測試，有運維，但是運維的同學一般不會來。我今天做DevOps的交付質量從需求質量開始的主題演講，我來自某咨詢公司，我們面向高科技、互聯網和傳統的電信企業做DevOps方面的咨詢。

我做DevOps的轉型和咨詢已經有五年的時間了，也參與制訂過一些DevOps的標準并為企業做輔導。我曾經做過測試，做過開發，也做過運維，我在這講DevOps，上一個講師講OverMind，我四年前也開發了一個開源工具，OverMind這個單詞的意思是《星際爭霸》的蟲族的首腦——主宰。

我今天講的內容有三點，先講一下案例，在咨詢公司的好處就是可以碰到不同的企業，不同的人，在案例中，我給不同企業做DevOps轉型的時候，發現測試的同學對測試的很多概念的理解都是不一樣的。然后再講一下經常碰到的技術性問題，最后講一下DevOps的質量觀，最重要的是提升需求質量的實踐。

先說案例，客戶的領導對我說，產品剛剛完成微服務改造，需要做DevOps。其實DevOps是什么一點不重要，關鍵是DevOps能幫你解決什么問題。他們想解決的問題是發布，兩個月發布一次版本，產品節奏是這樣的：用兩周時間做分析，兩周時間做開發，兩周時間做SIT，兩周時間做UAT。一般來說都不會達到這樣的情況。他們的需求分析到5周，開發到4周，給SIT留出充足的時間進行測試，最后UAT，用戶驗收的部門。這導致測試時Bug越來越多，因為UAT的時間不夠，增加了4倍的人集中在一周里做UAT，天天要去解決一堆Bug，每次版本都是這樣發布的。

我們發現，很多企業完成微服務改造之后，其測試成本都增加了。因為，從前是單體應用，后面改成分布式應用，需要測試的點多了，服務和服務之間各種功能測試和非功能性測試都要測試，特別是在SIT這部分，這部分增加成本會帶來延緩交付周期的結果。我做微服務架構，也做DevOps架構轉型，我不推薦企業在 DevOps 能力不足的情況下做微服務改造。微服務應當是 DevOps 成熟度高之后的必然結果。否則很多質量問題會大幅增加人力成本和時間成本。在質量標準較低的情況下，縮短發布周期，提升部署頻率是沒有意義的。

DevOps解決兩個問題，第一是軟件交付效率，另外是提升軟件交付質量。質量和效率兩個都想要，兩個都重要。如何提升軟件質量呢？是不是要增加測試人員和測試時間？增加質量就會增加測試的時間，導致更多頻次的測試。那么在我們剛才的例子里，用了交付周期的70%來做測試，也增加人了，為什么Bug還是那么多？這是他們當時拋給我的問題。

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

準確定義Bug，就是質量改進的開始，當然用戶不關心是哪一種原因。軟件開發是對用戶預期的一種承諾，不符合這種預期就是質量差。我們之前做過一個改進項目，改進質量的原因不是增加測試，是改變這個程序在交互界面上的用詞，用戶對行為預期就是一致的，否則大家對這個詞的理解是不一樣的，質量就會下降，這是沒有增加測試而提升質量的例子。

什么是軟件質量？這是ISO在1999年對軟件質量的定義，翻譯過來就是軟件產品符合需求的能力。一般的需求，那邊可能是客戶，發現質量問題出現在每個環節過程中，因為我們在做溝通的時候會出現一個問題，那就是真正對方表達出來的想要的內容有多少，不想要的內容有沒有表達出來，有沒有記錄下來，他沒有表達出來的東西你是不是想到了？還有非功能性的部分，有沒有表達出來，要求不能慢，怎么定義這個慢？一秒鐘之內還是三秒鐘之內？還有安全性、穩定性都沒有表達出來。遺失的需求到哪里去了？語言文字的表達能力是有限的，包括我們之前說的文字，不同的人理解有不同的意思，我們在這個過程中一定會忘記一些問題，我們怎么把沒有想到的問題，在需求階段提出來。

通常的辦法是增加需求文檔。發現質量問題是需求原因導致的，原來只寫三句話，現在要交另外PPT，Word文章，還有Excel表格，業務部門，包括提需求的部門是非常強勢的，他們經常說的是給我一套模板，這些人就變成了模板僵尸。我們在這個時候只關注做需求結果的質量，并沒有分析需求活動的質量。DevOps不僅關注結構的質量，更關注的每個活動的質量。需求文檔是不是能解決質量問題？在我們的例子里是這樣的，第一個對接客戶和用戶是業務設計環節，業務BA，中間是產品BA，負責產品的研發，架構概要的設計，然后是開發進行詳細設計，再給產品做評審，評審通過之后，這個方案沒有問題了，把測試拉上開發，開發講一遍，測試講一遍，相互確認一下。這個過程就是需求的過程，這個過程就是我們前面說的花費五周時間在做的事情。每個環節會有四種不同的文檔，到了開發的手上，包括后面用戶測試的手上，又拿不到這些文檔。

DevOps要打破組織墻，在這個過程中，軟件質量有兩種，一種叫客觀質量，符合質量度量標準，比如接口覆蓋率，各種指標，比如之前做的項目，單元測試里全都是百分之百，用戶就一定會覺得質量好嗎？不一定，產品一定沒問題嗎？也不一定。另外是主觀質量，每個人對軟件的結果和過程的體驗，不光包含最終使用這個軟件的用戶，也包含參與所有環節的人，他們體驗也算作質量，分為內部質量和外部質量。如果團隊之間，開發覺得需求不夠詳細，測試覺得代碼不夠好，沒有人改進，內部質量就已經先垮了，就不說外部質量了。

來講講DevOps測試觀。每次測試聽到DevOps的時候，內心都是崩潰的。這里講的不是測試人員和開發人員，而是包括運維人員的開發團隊。因為在國外的很多組織里，測試人員已經被整合到開發團隊里了，所以講的是開發團隊，或者產品團隊，以及運維團隊。這會導致一個問題，DevOps引入中國的時候，大家的理解不統一，大家不知道該怎么辦。

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

發布風險的技術有幾點，第一是減少代碼提交內容，每次發布的內容很少，要快速的知道是哪行代碼出現了問題。然后是TDD，持續集成和部署，還有是金絲雀發布，灰度發布，藍綠部署。微服務就是在測試周期長的情況下，把應用拆小來進行測試。自動化測試能夠紋理運行，就一定能獨立部署，通過拆分自動化測試對應的代碼來進行服務的拆分，拆分出來的服務一般都沒有問題，因為有測試做一層保護。

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

好的用戶故事有3C原則和INVEST原則，3C原則，Card、Conversation、Confirmation，一定是很少的記錄，很多的討論，要把你的解決方案跟用戶達成一致，始終由你來引導整個軟件的開發。INVEST原則，首先是可獨立的，我們希望故事之間的開發順序不影響最終結果，是在一個迭代周期內，不影響最終結果，這是故事的力度。可協商的，如果用戶直接告訴你怎么做，就是不可協商的，所以要反客為主，來引導這個需求的方向。有價值的，設兩到三個高優先的，越迫切的就表示價值是越高的。小的，可估計的，可測試的，這是可相關的，如果過大就沒有辦法估計，沒有辦法給出準確的時間，所以要做得小。我們對需求的可測試是這個要求，如果不能自動化測試，就不是可測試的。因為只有可以自動化測試的那些規格，才是清晰的，不能自動化測試的規格都是模糊的。

如何產生用戶故事？通過用戶故事工作坊，在一個工作坊里大家一起討論。這個人是下議院的院長，他經常說的一個詞就是“保持秩序”，在這個工作坊里，一定要先讓用戶說，不要打斷，否則很快會導致爭論。先讓用戶充分的表達，因為他是質量最后的決策者。用戶故事，要做到“5W1H”，確認用戶（Who），確認功能（What），確認價值（Why），確認場景（When & Where），確認規格（How），我們勾畫的時候都會產生新的問題，產生新的Bug，在原因回溯的時候，找到這些原因，放到需求階段，去提出這些問題，在這個階段去解答。當把沒有問到的問題積累到列表的時候，軟件交付的質量會越來越高。還有，一定不要讓用戶告訴你怎么做，如果導航員亂指揮，開車的人就要走錯方向，還是應該讓專業的司機去開車。

還有實例化需求，要讓客戶舉例子，有清晰的規格。先確認規格和結果，不要先確認形式，從輸入到輸出，中間有很多種形式，先確認結果是什么，輸入是什么，后面再進行設計。語言的表達一般來說是很有限的，我們構建紙片小人，去討論，去設計，把故事講給用戶聽，講清楚，大家確認之后再做開發。還有一點，用戶故事一定要講出來，和所有人都確認一遍，自己講完再讓用戶講一遍，作確認。

用一句話描述原則，如果一句話表達不完，這個內容就很大，需求就很大。我們使用需求規格成熟度，好的需求規格有用戶故事，有驗收條件，有測試場景分析，按格式寫作用戶故事，每個故事都有驗收條件，有BDD風格的驗收條件，有基于驗收條件的測試場景和測試用例分析，能夠自動化驗收用戶故事。我們要求所有團隊要達到第三級和第四級之間。我們不用文檔，用思維導圖，我們的需求到測試，到結果之間都是一一對應的，當思維導圖再大的時候就知道怎么去拆。

介紹TDD的時候，發現大家的了解不一樣。TDD有三種，第一種是測試用例驅動開發，測試人員驅動開發人員，最后是測試計劃驅動開發計劃。測試人員在需求階段要分析明確測試用例，一開始大家對TDD都是抗拒的，因為增加了工作時間，后續用了一段時間TDD，所有開發人員都說不要停。而且，當自動化測試的覆蓋率不到76%以上的時候，不會減少測試人員的工作量。還有要盡量采用自動化的方式實現測試用例，如果不好實現，需要進行評估和評審。開發人員以完成測試用例為驗收條件，自己沒有測過是不能交給測試的，這是一個起碼的要求。

測試人員驅動開發人員，就是測試人員不再做重復的測試工作，而是作為一個用戶來驗收交付的軟件，測試的工作是一個任務，讓開發人員去完成。測試人員有兩種轉型，一種是向后做DevOps，一種是向QA，向業務的方向去做前項，在這個過程中QA和BA是可以輪換的。我做一段時間需求分析，再做一段質量驗收，都是作為用戶的角度，要求開發人員去開發出符合測試質量要求的產品。大部分的QA或者測試人員最后都在團隊里面晉升了，變成一個團隊的leader。測試計劃驅動開發計劃，第一點好處是能夠分攤測試壓力，最后一周的UAT測試分散到每一天，每天的測試量都比較平均，根據測試計劃倒排開發計劃，采用拉動的方式，而非推動。

落地DevOps的關鍵是讓用戶的發布和測試拆分到每次發布風險可以高度可控的程度，如果能拆到兩周，兩周就能開發，如果能拆到一天，每天都能發布，我們最快的是15分鐘發布一次，力度就是一行代碼。當把要求做得很高的時候，我們發現一個問題，我們兩個人討論了一天，寫了很多測試代碼，測試用例，結束的時候只寫了一行代碼，就是高度討論，經過了充分測試的結果，這個結果是我們場景中最優化的，讓每個提交變得更小，風險更可控。

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