前沿拓展：

tapd登錄

菀的地枋，
鏈接；r-pw.COm?gyre（**粘貼即可打開）
，
，
第一只叫做Dasher，猛沖者的意思
第二只叫做Comet，彗星的意思
第三只叫做Cupid，丘比特
第四只叫做Dancer，跳舞家
第六只叫做Prancer，跳躍
第七只叫做Vixen，雌狐
第八只叫做Donner，是荷蘭語中的雷
第九只叫做Blitzen，也是荷蘭語，閃電
第十只叫做Fireball，火球
第十一只叫做Olive，橄欖
第十二只叫做Rudolph，魯道夫
圣誕老人原本馴鹿的組合只有九只，到了后代才多出了三只，變成了整整十二只。也就是現今我們所知道的圣誕老人馴鹿。
不需要清除刷機恢復的。當在連續輸入鎖屏密碼錯誤5次的時候會提示等待60秒
連續輸入13次錯誤的密碼后出現提示僅有兩次輸入密碼的機會解鎖。
連續錯誤密碼15次后，提示必須輸入魅族Flyme帳號密碼才能進行解鎖。
手機會自動打開手機移動網絡進行在線解鎖。這時只要輸入登錄的flyme賬號的密碼即可。
溫馨提示：輸入正確的魅族Flyme帳號密碼解鎖

導語：傳統行業轉型的過程中，騰訊向來扮演的是數字化助手的角色，騰訊云作為幫助企業數字化轉型的入口，也已經成為騰訊的“獨角獸”業務。

然而伴隨著云業務的增長，騰訊內部業務如何上云，對于外界來說一直是個秘密。近日，騰訊自研上云項目負責人周小軍首次披露，騰訊如何把內部海量的自研業務搬上云端的故事。以下是他的分享內容。

大家好，我今天分享的核心內容有三個：

騰訊自研業務如何從私有云的模式搬遷到公有云；如何把這些大體量的業務搬到云端；如何擁抱云原生。

騰訊的業務量非常龐大，社交業務包括QQ和空間的體量有近二十萬臺服務器，分布在全國三地。要把如此龐大體積的業務搬到云上，可以稱之為“把大象搬到云端”。

今天我就分四個方面向大家介紹騰訊自研業務上云的故事。第一是騰訊業務為什么要上公有云，第二個是業務上云的價值，第三個是如何上云，第四個是以QQ上云的案例分享業務上云的過程。

為什么要上云？

1. 騰訊業務的煙囪模式

2018年以前，騰訊的業務線是類似煙囪一樣的模式，每個業務事業群從邏輯層、數據層到后端的容器或虛機層，都是**一套技術框架和技術體系。每個事業群之間的框架多數是不通用的，一個騰訊的員工從IEG轉崗到微信事業群，發現他的開發框架可能都要重新熟悉。一個新人來到騰訊之后，面臨那么多的服務框架，也不知道如何選擇合適的框架著手。

甚至在騰訊的內部論壇上，經常有很多新人發帖問，我該選什么樣的工具，我該選什么樣的框架，這種情況就導致三種困惑：

第一個是很多工程師不斷抱怨為什么騰訊內部有這么多名詞，不同的工具、不同的框架、不同的平臺、不同的數據庫和不同的存儲等等。第二個是很多部門都開發和使用自己的一套東西，跟其他部門缺乏分享和協作。第三個是開源文化氛圍不強。很多部門的代碼不開放，或者缺乏文檔。我們知道成為一個優秀的組件，組件的文檔、支持、社區都是非常重要的，沒有這些支持的話，你很難把一個組件做到最優，但是在騰訊內部很多組件是缺少文檔，支持力度不足，甚至出現很多無人維護的孤兒組件。

2. 兩大開放戰略并行

基于以上問題，為了技術體系革新，930調整后，騰訊內部做了大變革，包括成立新的云事業群，公司內部成立“技術委員會”，啟動“開源協同”和“自研業務上云”的兩大戰略方向。

首先，開源協同就是在騰訊內部，所有的開發團隊代碼都是開放的，騰訊內部有統一代碼庫，所有的團隊及個人的代碼都要在上面公開提交、公開發布。團隊與團隊協作更好，隨時可以去創建個分支，或者提交更豐富的特性功能，形成公司內的開源代碼文化，創建更好的工程師氛圍。

其次是“自研業務上云”。基于公有云的研發模式，使用云上豐富的組件、豐富的服務，把內部的一些優秀的工具和組件上云，對外開放，在云上做服務。在客戶的激勵驅動下，不斷迭代成為行業內的領先水平。

這是騰訊技術領域一個很大的變革。

上云的價值是什么？

第一是業務價值，業務的研發效率更高，從0到1開發一個新產品短短一周就能完成，微服務框架、數據庫、容器資源、持續集成、持續交付、統一配置中心等等，云上都有現成的服務，研發團隊不需要到處拼裝各種組件和工具，可以更專注業務研發。

第二是工程師價值，工程師可以使用到整個業界最標準化的服務，基于公有云的研發模式，能夠離開封閉的開發環境和組件，同時工程師還可以輸出非常優秀的組件到云上成為服務，這也是大多數工程師的夢想。

第三是客戶價值，可以給行業輸出非常多的公有云的經驗。截至2019年初，騰訊正式發布的對外開源項目將近70個，諸如騰訊云T stack、藍鯨智云BlueKing CMDB、微信開源系列和TARS等，都是騰訊開源的典型案例。

如何上云？

1. 業務上云的三個階段

騰訊自研業務上云也并不是一蹴而就的，而是有三個階段：

第一階段是從2017年開始直播類業務的上云。直播業務上云模式是一整套直播業務從自研機房搬遷到公有云機房，在騰訊云上提供服務，完成國內和海外幾十個節點的建設，服務于自研的直播業務和外部客戶。上云時打通了內部的運營管理系統和**系統，同時支持跨云的管理。第二個階段是沙箱云，這個階段是在騰訊云上建立一個邏輯隔離的私有網絡空間，利用騰訊云的IaaS服務，使用云的虛擬機、云的網絡、云的機房來支撐自研業務的服務。不過這類模式只屬于基礎平臺上云，并不是整體業務體系完整上云。第三階段，是在騰訊“930”變革之前， 2018年6月我們就已經開始擁抱公有云，啟動自研的整個業務從私有云遷到公有云，這是把整個業務連根拔起搬遷到云上。

上云之前，2017年，我們所有QQ用戶還在私有云上，到了2018年年底，就已經把一成半的QQ用戶從華南區遷到廣州云。到了2019年的6月，已經有三成的QQ用戶在云上，每6個QQ用戶就有2個是在云上。我們計劃到2019年年底，QQ實現華南、華東和華北三大區域的所有用戶全部都遷到云上，實現完整的QQ公有云上服務。

2. 上云有哪些流程？

在上云的過程中，我們可以直觀的感知到，跟之前煙囪式的架構不同，上云后像IEG、PCG、WXG等事業群等，都將在公有云上運行各自的業務。業務會使用公有云的CLB、接入服務、服務框架，云PaaS服務，包括Redis、MySQL、Kafka、ES、CBS、COS等等，還有像K8S這些公有云上的原生服務。

為了實現這一點，我們做了一些改造，在每個區域的公有云和私有云機房之間拉了專線，實現了公有云私有網絡到私有云機房的互通，保證業務能夠來回遷移及訪問內部服務能力。

根據業務體量不同，業務采用三種方式上云，有改造后上云，有邊改造邊上云，有先上云再改造。業務可以根據自己的人力資源和上云計劃，選擇對應的上云方式。

下圖是整個業務團隊在上云的過程中所做的幾個流程：

第一是測試，包括公有云上的網絡、存儲、虛擬機、核心服務，以及單機性能、服務吞吐性能、存儲讀寫性能、業務模塊性能等等都經過測試。通過測試之后，我們和云團隊一起優化了服務性能，對業務也相應做了改造適配。第二是業務上云方案，包括安全方案、容量評估、服務遷移方案和數據遷移方案等。第三是業務遷移，遷移包括接入層、邏輯層、數據層及文件存儲等的遷移。第四是混合云共存，業務會逐漸灰度遷移到云上，比如在線用戶從5%、10%、20%、30%到100%等，是一個灰度遷移過程。在灰度過程中可以及早發現各種問題，逐一解決，避免大規模上量時出現災難性后果。這個過程中就存在公有云和私有云的混合部署模式，就要重點關注專線使用容量，做好專線在業務高峰期的預案，以及業務跨混合云訪問的服務延遲，及時做好用戶在不同云之間調度的策略和方法。最后是業務**。上了云之后使用立體化的**體系，度量服務調用質量、用戶訪問質量和服務可用率等，譬如跟蹤用戶在私有云和公有云的訪問延遲有沒有變差，不能變壞，運營質量有沒有跟原來保持一致，甚至變得更好。

從測試、方案、遷移、混合到**，這是我們上云團隊所實施的上云遷移整體流程。

3. 企業上云方案

根據騰訊自研業務上云，團隊所積累的經驗之上，我們抽象出完整的上云方案，也十分符合很多企業上云的實際情況，方案分五個階段：

第一階段：規劃。規劃中要對業務系統化的梳理，包括業務評估、容量評估、業務架構、組織體系。組織體系是指上云后組織架構和職能的變化，包括運維職責的變化：例如不再有中間件的運維人員，研發流程的變化；研發、測試和生產環境如何在混合云甚至多云**存；資源預核算的變化；以前是購買機架和服務器，現在是先充值再按量計費；故障處理流程的變化等。技術體系的組織都要準備跟著公有云轉變。第二階段是方案規劃和設計。要做好詳細的遷移方案，風險預案，回滾預案，混合云預案，多云預案等，譬如上云過程中數據遷移有問題，出現丟數據，我該如何解決等等。第三階段是驗證。這個是非常核心的階段，上云前，要有預測試、預驗證的過程?？梢园岩恍┖诵哪K，譬如高并發，或延遲非常敏感的模塊，在云上做好充分的壓測，并跟云服務團隊一起優化解決各種問題。第四階段是業務遷移。遷移就更復雜了，包括服務和數據怎么遷、怎么做好備份，遷移過程中對業務有沒有影響，我們用云的通用遷移工具，還是我們自己開發的遷移工具。上云過程中，做好對灰度模塊的觀察，通過客戶端服務質量，服務間調用延遲，全網撥測等**指標觀察業務有沒有問題。第五階段是持續運營。整個服務運營體系都變了，基礎運維和公共運維團隊變成由公有云的運維團隊來支持。內部使用的開源**工具，或者改造成支持公有云的資源**，或者使用云上成熟的**SaaS服務。CMDB要支持多云管理。運營流程也發生很大的變化，服務SLA要跟公有云服務商一起制定。

4. 上云過程中的安全

當然，上云的過程中，安全是不可或缺且關鍵的一環，騰訊是一個非常注重安全的公司，特別是用戶數據安全。我們在上云安全這塊做了很多安全方案。自研內部、企業內部我們有一整套自研的安全體系。上云后，我們結合云上的一些安全產品，以及原來自研的安全服務和安全策略，制定混合云的安全通用體系。

首先在公有云的大網里，我們會劃出一個**的私有網絡VPC，業務分別去部署。之上有網絡防護以及網絡安全的產品服務。主機上有主機防護，漏洞掃描等。業務層有應用防護，運維有運維安全，云上有豐富的產品可以去使用。然后我們也打造了一些內部積累的安全方案，并回饋到云上。形成了公有云安全產品和自研安全產品兩者相互匹配融合的上云案例解決方案。

事實上，整個公有云的安全策略和私有云是一樣的，沒有什么根本性的差別。

5. 數據庫的遷移模式

在上云過程中，也必然會遭遇到一些比較大的挑戰，比如數據的遷移。在私有云到公有云的數據搬遷模式中，我們有四種模式給業務選擇。

首先是私有組件數據遷移到公有云的模式。騰訊內部有很多自研的數據庫，像QQ的Grocery KV存儲使用的是內部私有協議，云上沒有對應服務。業務需要將數據從私有組件遷移到Redis。

我們采取冷遷移的方式，先將數據全備，然后把數據導到云上Redis集群，導完后開始做新增數據追加。怎么追加呢？我們用數據同步中心來實現。后面會有同步中心實現的架構。數據同步完之后，我們通知業務可以切割，留一個業務低峰期時間，比如晚上凌晨2點，花1分鐘把數據路由服務從自研IDC切到公有云Redis集群上。

第二、三種模式可以統稱為開源組件到公有云。我們內部有一些業務，在開源組件之上做二次開發，譬如基于單機Redis實現自研分布式Redis集群。這些基于自研或開源組件的數據遷移到公有云上對應的數據服務，可通過DTS遷移工具來實現。

這個非常簡單，也是業界非常通用的做法，我們直接用云上的DTS來做自助遷移。這個工具甚至不需要運維**作，開發團隊自己在DTS窗口上輸入幾個參數，點個搬遷按紐后就可以自助搬遷。搬遷完成后自助切換或自動切換。

第四種模式是私有組件直接上云。因為有一些組件云上沒有，業務也沒有資源將私有組件改造成云的標準服務，這個時候業務就將組件集群直接在云上部署一套，數據通過同步中心或主備備等方式搬遷到公有云上。

比如說我在深圳的自研有一臺主兩臺備，那么我再把備3、備4放到廣州云，數據同時同步到私有云的兩個備和公有云的兩個備機模式。所有的主備數據完全同步完成之后，我們再把公有云的備變成主，自研云的主變成備，就相當于是做了切換。

6. 云管平臺

還有一點非常核心的就是云管平臺。之前內部的配置系統、**系統、CMDB等等，都是基于私有云的管理模式。業務上云之后，我們很多運營系統要改造成支持混合云，支持多云的管理模式。譬如業務模塊會有50個實例在騰訊云上，30個實例在海外亞馬遜云上，30個實例在內部私有云里，那么我們的CMDB必須要支持多云的資源管理。從圖中可以看到，底下是我們的整個業務線，下面這些帳號體系、預核算、企業安全、**等等其他的應用工具或平臺，都要改造以適應混合云模式。就拿帳號體系來說，內部員工以公有云的帳號登錄云官網來購買、使用和運營公有云上的資源。但內部如何把帳號所使用的資源成本核算到對應的業務，員工離職或轉崗后資源怎么回收或轉移，如何把帳號綁定給企業組織架構，云官網帳號登陸如何與內部OA鑒權等，都是必須要考慮和解決的問題。

如何把QQ的所有用戶搬上云？

前面講了業務上云的思路和方法，QQ上云是走了這樣一個經歷。下圖就是一張全國地圖， QQ業務有三大區域的數據中心，有華北自研，2015年這里曾發生了一個很大的爆炸事件，當時我們還把天津的用戶調回了華南和華東區域。上海有華東自研機房，深圳有華南自研機房，在**還有一些海外的出口。三大區域各有三成多的QQ在線用戶。

根據用戶分布情況，QQ上云時，在華東、華南、華北三地，在騰訊云建設的云機房上，我們創建了業務的公有云網絡，然后把QQ業務從各地的自研機房往云上遷移。

QQ上云中業務架構圖分成了三大區域，分別是華北、華東、華南，而華南分成了廣州云和深圳自研機房兩大機房。目前是“三云一地”。每個區域都是完全**的存儲和業務邏輯服務。可以把華南的整個用戶全部都調度到華北和華東區。業務隨時將用戶從不同的云區域和自研區域來回調度。

1. MySQL數據搬遷

我們接著看下業務的MySQL數據搬遷案例，詳細見下圖，它有主—從的模式。我們沒有通過IP和PORT來尋址，而是通過內部的DNS類名字服務來尋址。先分配業務一個實例的名稱，然后通過DNS拿到這個實例的IP端口，再去訪問具體的實例。從自研的IDC使用騰訊云DTS遷移工具，把數據導到云的MySQL。數據自動導入完成后，開發團隊只需要在云上切換服務就可以完成數據實例的遷移。這種適合一些數據體量不大的業務數據遷移。

還有一種是主—備的模式，即在深圳自研有數據庫服務器的主和備，在云機房新部署幾臺備機。通過主備同步的方式，把所有數據都同步到云機房。然后將云機房的某臺備機切換成主機，將自研的主機降級為備機。這樣就切換為云機房主備，自研機房備的模式。

2. 數據同步中心

還有更復雜的是數據同步中心。這種是適合業務量非常大，有全國多地分布的業務。服務模塊寫數據的時候，統一寫到各地的接入**，**統一寫一地，譬如深圳自研的寫服務。

寫服務的轉發存儲會將新增記錄同時寫到各地自研、各地的云機房，實現最終數據一致性。

用戶就近讀，比如華北的用戶，就讀華北云的這個數據存儲集群，華南就讀華南的數據存儲存儲。

通過同步中心的方式完成大規模數據的混合云同步。當要增加一個成都云區域，我們只需在當地部署好一套同步服務，增加路由服務規則，同步服務就會自動把數據同步到成都的云機房。

這種方式適合對延遲不敏感的業務，譬如社交業務的點贊、發表說說等。一般從深圳自研同步到上海和天津的時候延遲達到幾十毫秒，延遲非常高，不適合金融行業等延時高敏感業務模式。

3. 混合云紅包的架構

從2014年開始，每年春節騰訊都有春節紅包活動，今年春節我們首次在公有云和私有云之間做了紅包的兩地混合。我們在廣州云部署了與自研相同規模的紅包服務模塊，包括數據集群，在春節前演練及預熱階段，充分對廣州云服務做了各種測試和驗證，包括跨城專線延遲對業務的影響程度。

紅包活動期間，用戶在接入的時候根據用戶的ID分片或用戶來源，通過路由策略分流到廣州云機房和深圳自研機房。春節期間，混合云扛住了整個紅包活動的用戶流量。驗證了跨地域的混合云完全能支持億級的業務大并發流量。當然我們也做了很多方案，比如萬一公有云的紅包模塊沒有扛住，我們怎么辦？如果我們發現用戶在云上有大量失敗，我們就把用戶在幾分鐘以內切回到深圳云，甚至把整個業務從云上切回本地，我們有信心去扛云機房的壓力。

在上云過程中，QQ研發自身也對業務進行了優化，積極擁抱變化，做了很多處服務的改造，以能夠適應新一代的基礎設施。

服務邏輯上，很多個業務直接使用云PaaS服務，如長消息、加群邏輯等用了云Redis存儲服務。更多的服務遷移到TKE之上，一些內存存儲服務，譬如資料、關系鏈等數據存儲層做了鏈接數、數據副本擴展、混合云單元分布等架構層級的優化改造。

上云前后，上云團隊對業務質量非常關注，不斷對比二個云之間的可用率、客戶訪問質量、服務間調用延遲等質量數據。上云前后， 經過各個架構層的優化，業務質量數據最終保持私有云和公有云一致，保證了用戶訪問體驗。

4. 云原生

上云不僅是為了上云，我們更多要擁抱業界開源生態。要用云上優秀成熟的產品和服務。在開發方法、業務交付、云原生服務等方面，業務上云前后已經是部分甚至全部擁抱云原生的體系。我們已經把TAPD研發管理工具、工蜂代碼倉庫，還有藍盾、橘子CI、QCI、coding等集成為工具鏈，在云上打造了一個持續集成、持續部署的DevOps流水線閉環。

目前在云上的交付，業務每周都有幾百次的交付是通過容器來完成的，從以前的包交付變成容器交付。

在微服務這塊，像SF2、SPP、TAF等，我們內部不同業務已經使用了很多微服務框架，并計劃在公司內迭代升級更優秀的微服務框架。

5. TKE引擎

K8S平臺上，我們用了騰訊的TKE引擎，這是一個跟K8S完全兼容的引擎。我幾天前跟一個業界公司聊，他們在騰訊云、阿里云上買了K8S服務，自己內部也部署了K8S集群。他們的容器可以隨時、同時交付到騰訊云、阿里云和他們本身的K8S集群，而不用做任何改動。通過容器交付，業務可以不用考慮環境依賴等問題，交付變得更敏捷和輕松。

我們基于TKE之上做了功能定制和優化。TKE有基于CPU負載等基礎容量的彈性伸縮能力。在TKE優秀的伸縮能力之上，我們還做了功能疊加，包括業務畫像，就是根據業務長期的趨勢和業務突發活動，去做趨勢預測和活動預測，通過算法來預估容量在什么時間窗會達到多少水位，以準備相應的容器資源來提前幾小時擴容，應對突發流量。

上云團隊、業務研發跟云的TKE團隊合作，我們把業務特性跟TKE相融合，來做出一個特性更加豐富、滿足業務場景的K8S應用功能。譬如QQ是三地分布，特別是上云后又增加了自研和云的機房屬性。原生K8S不支持跨地域的，因此我們做了跨地域的特性。

除此之外還有權限限制，業務對權限要求非常嚴格，是基于IP鑒權的。比如內部的業務模塊訪問MySQL時，要授權MySQL要給這些IP放行。容器是很難去做這種基于IP的權限管理，我們的容器都是用了固定IP，每個容器都有自己的IP，交付時注冊到CMDB上，并完成鑒權等自動化交付流程。

內部的CI/CD，我們有很多的優秀工具，讓業務自行去選擇使用，開發團隊喜歡什么樣的工具，從鏡像倉庫、到CI、CD、CO都能保持業務自己的習慣。還有包括管理體系、安全、審計、服務**、日志、告警等功能特性，我們增加和優化了近百個特性，滿足TKE與海量業務結合。

于是，我們總結了八類的TKE業務應用適配，從業務管理、網絡、路由與服務發現、分批發布、權限控制、鏡像倉庫、網絡存儲到遠程日志。

6. 藍盾支持云上DevOps的范例

這是藍盾支持云上DevOps的范例，能夠實現計劃、需求管理、設計、研發、構建、測試、部署、搭建、**到運營等一整套工具閉環。

所以，從騰訊自研業務上云，再到一些合作伙伴的案例，對于上云的的趨勢，我們總結了五點經驗：

第一，徹底擁抱云原生，用云來滿足業務快速迭代，資源彈性伸縮的需求。第二，全面擁抱DevOps，研發效率更高效。第三，內部的優秀工具上云，給云提供更好的服務。第四，整個開發團隊心態更加開放、更加開源，主動與開源社區協同，貢獻更多的功能特性。第五，公有云經受了QQ海量流量的錘煉，我們在上云過程中，經歷很多的經驗教訓，邊上云邊解決問題，邊上云邊優化，將整個公有云的基礎設施和服務錘煉成更加成熟。

作者簡介：

周小軍，騰訊云資深運維專家。加入騰訊以來先后負責騰訊社交事業群數據存儲運維、接入架構運維、社交業務運維等運營工作。擁有十幾年互聯網IT運維經驗，精通互聯網海量業務規模技術架構、云計算基礎架構、自動化運營系統、**系統等領域。帶領團隊維護亞洲最大的數據庫集群，以及春節QQ紅包、天津大調度等海量規模業務的運營保障項目。所負責社交業務在線用戶3億 ，月活8億，20多萬臺服務器集群，全國三地三活數據中心。

拓展知識：

tapd登錄

前面幾期我們談及了如何將測試的介入時間提前， 從而提早發現問題， 提早解決， 并介紹了兩個實踐：持續集成和測試先行。這個兩個一個是從業務上面預防問題， 一個是從技術方面提早發現問題。是質量內建中用于提早發現問題的常用實踐。

但貌似這些實踐都著力于測試之外的范圍， 是否有著力于測試本身的招式去將軟件測試做的更加完善， 有效。這期， 我們就來感受一下軟件測試本領域的內卷 — 測試用例版本管理

通常我們的測試用例， 本質上是對軟件需求的各個功能點展開與組合。開始， 在需求逐步增加的情況下，這是很容易的。一般的實踐中測試用例分兩種：

測試需求類型的測試用例

測試動作類型的測試用例

測試需求類型的測試用例描述的是需要測試什么， 例如：測試登錄頁面-進入登錄頁面-進行登錄-查看結果 這是很不專業但是很常見的測試用例書寫方法， 寫這種用例的好處就是可以快速的生成成噸的用例的測試不同的功能點。

測試動作類型的測試用例則描述的是怎么測試， 例如：瀏覽器中輸入 www.xxxx.com/Login

用戶名輸入框輸入xxx, 密碼輸入框輸入yyyy,點擊登錄；期望：頁面會跳轉至 www.xxxx.com/Dashboard

這顯然就描述了測試中需要執行的步驟，無任何歧義，任何人都可以拿來執行；這樣的好處明顯就是可以消除功能測試中用例執行的不確定性， 使測試時執行的用例即是測試設計時所想

然而隨著功能點的增加，測試用例根據功能點變化是指數級的，一個功能點下會根據不同的測試精度設計N條用例， 測試精度越高， 那單個功能點產生的測試用例就越多。

如果這個功能點發生正刪改的話， 那么就會產生對測試用例維護維護工作。依照不同的測試用例精細度產生的工作量也不一樣。如果多個功能發生修改的話會讓維護測試用例這個工作變得更加困難。所以讓測試用例保持新鮮度（實時吻合當前的功能）是非常大的挑戰。

在實際的修改過程中， 我們通常會遇到兩個困難點：1.用例多 2.**難

在指數型的用例爆炸時，即使識別出了需要修改的用例，因為種種原因， 可能是設計過為精細或者功能點組合過于復雜， 導致有很多條需要修改。

因為要修改的用例太多，這個時候的反應要么就是花時間去重新寫用例，要么就是迫于壓力，采用能測則測，能舍則舍的方法去測試， 這時的測試用例聊勝于無， 如果錯將已經失效的用例當成正確的執行要么就是誤報，要么就是漏報。

最好的解決方法是按照模塊去規劃，不斷的將測試用例進行原子化處理，使用業務逐級下分的方式，這里有個坑，就是往往一個測試的**是多個人編輯的， 有可能存在放錯地方問題，這個問題也很好解決： 套用開發的實踐-code review，來個testcase review ， 一天一個高產的測試工程師也就是60個用例，假設一組有5個測試， 300條用例，灑灑水啦

有了原子化的測試用例， 當一個功能點發生變更的時候， 只需要根據變更的功能點廢棄或者重構某個節點即可， 由于用例是原子性的， 重構的成本為所有情況中最小

所以針對 用例多 這個業務痛點場景， 原子分類法的效果如下：

此外，也可是使用模糊用例的方法， 很多小微的項目為了響應這已知的變化通常會將用例寫的比較粗糙， 或者僅僅是記錄測試的思路， 有的是畫一個腦圖，梳理用戶故事， AC等等， 然后介于AC之后的方向繼續發散，得到一些沒有步驟但是明確要測試什么的一個文檔。這個文檔的形式有很多， 總體的特點就是可以一目了然的看到所有功能。

對于實際測試時， 需要根據當前的思路繼續即興發散， 得到一個相對比較準確的結果。

這種方法也無疑會減少因功能變更導致的用例失效， 畢竟“你變任你變， 意識在中線”

對于由于用例的分配和知識散點的出現， 會導致在功能點發生變化的第一時間， 無法精確**到對應的測試用例，這個時候就會有第一時間找不到，測的時候碎一地的結果。

這時除了上面提到的原子分類法可以解決歸類找到對應的測試用例以外，可以使用測試用例管理工具來快速的查到你需要修改的用例， 例如，zephyr, testhub, Ones testcase， 禪道，云效， tapd等等， 通過搜索對應的關鍵字可以非常快速的找到你想要修改的問題，甚至有些功能可以直接將用例關聯到需求上， 需求變更后直接通過需求下鉆的方式就可以順路去修改即可

好了， 到了這里也列舉出了幾個常用的基礎方法，用來解決用例多， 改用例困難的問題， 每種方法都能解決一個或者多個問題， 不過要解決**難和用例多的問題， 貌似必須要采取多種方法混合的策略， 是否有一個通過的方法，或者是否有更高效的方式去管理測試用例呢， 有的， 這就是今天的主角–測試用例的版本管理

是想有這樣的一個用例發展圖：

看起來與開發中的版本管理如出一轍：

使用軟件開發的版本管理策略管理測試用例， 本質上是使測試用例有了版本的概念：

這樣可以：

雖然對于版本管理這個技能很多測試都還不具備，但有很多工具可以幫助測試完成對應的設計， 且版本管理目前的學習成本很小。

值得一提的是， 測試用例管理的方法可以是一個方**， 并結合上面提到的工作進行混合模式， 這樣就有了測試用例管理的proplu**axultra的版本了（笑）

下期預告 :

版本管理固然重要， 目前所有的實踐都是散兵游勇， 下期， 我會介紹測試流程的編排，從整體上和大家一起討論如何優化測試流程和測試流程的本質。