作者簡介

　　朱姍

　　英國理學碩士，從事測試開發行業多年。

　　2012年開始獨立和美國方面合作負責E2E財務系統，工業監控系統、生物醫療工具系統等多個項目的測試，貫徹執行敏捷研發測試流程,經歷過大型軟件的研發工作，對軟件研發有豐富的經驗，同時具備互聯網軟件測試框架研發和方案整合能力，對軟件質量保障全局有體系化的思考和經驗。能夠面對復雜情形構建體系化的質量控制策略，並具備良好的落地實踐。測試心得經驗受到國內多家銀行，證券，互聯網公司的喜愛和推崇。

　　序言

　　互聯網時代，企業越來越註重產品的快速叠代與交付，當然產品質量也是舉足輕重。企業在有限的資源情況下，快速的步調意味著更多的挑戰，本次演講重點在於測試人員如何無縫連接客訴，運營，產品，研發，運維以及高效快速搭建DevOps測試體系從而保證產品快速交付的質量。

　　本文的六個部分：

　　什麽是 DevOps 測試?

　　如何適應 DevOps 的組織和文化;

　　一個關於測試的故事;

　　測試金字塔;

　　建設可靠可重復的交付流水線;

　　數字驅動改進。

　　1、什麽是DevOps測試?

　　什麽是 DevOps 測試呢?和傳統測試相比，DevOps測試對測試人員可能會有更高的要求，對業務的掌握和研發技術的深入了解，以及如何快速融入到業務的的可持續發展，整個業務的價值生態和發展趨勢也要有全局的理解。

　　1.1.聚焦DevOps測試

　　第一，聚焦業務的價值。這個聽上去有一點學院派。一般人理解軟件測試是一種實際輸出與預期輸出之間的審核或者比較過程,測試人員主要目的就是找bug,如果有bug就是測試者的工作業績。

　　自從接觸DevOps測試以來，我們發現測試不僅僅是研發代碼寫完了提交給測試進行驗證，以及回歸bug就終止了。

　　Devops測試推崇的是讓測試者可以站在更高的角度，即：業務的價值去審視和優化自己的工作。談到業務的價值，耳熟能詳的就是體現在投資回報率。

　　有人說測試是非增值的部分(屬於成本部分)，其實測試其實完全可以是一個增值的部分。因為，作為測試人員肯定希望工資待遇不斷提高，職業發展更加良好。

　　但是，得到這一切的前提是我們最終輸出的產品得到用戶認可和推薦，打造最佳的用戶體驗，讓每一個功能都順著用戶的場景走順;

　　我們的產品提供用戶需要的服務;為客戶帶來了價值;然後我們自然會得到更多的收益。

　　每個細小的功能都是一個小分子，只有每個小分子都是良好的細胞組成，而沒有惡性腫瘤細胞，我們的大分子產品才會健康的發展起來。

　　第二，DevOps測試是在流水線的任何階段。這個任何階段是指什麽呢?所謂流水線大家都知道;

　　舉個例子：我們平時在餐廳裏面吃飯，一道菜要經過很多的工序才能呈現到我們的桌面上，可能先從原材料的采購，到廚師切菜、做菜烹飪、傳菜，最後到服務員將菜端到我們面前，這其實就屬於一個流水線。並且，這條流水線是可重復執行的。

　　在日常工作時，產品負責人會維護一個按優先級排序的“產品待開發項”(Product Backlog)，即從客戶價值理解和描述的產品功能條目，在每次叠代的第一天，召開Sprint Planning Meeting，產品負責人會逐一挑選最高優先級的部分進行講解。

　　團隊可就需求細節、完成標準等進行詢問，並逐條估算，放入本次叠代的開發任務中，直至 任務量飽和。

　　對於優秀的測試人員來說從Product Backlog就可以參與其中;也就是從最開始產品的需求產生，然後到每個叠代需求評審、分析、研發、設計、代碼實現，再到測試的集成環境，我們的灰度環境、UAT環境，到最後的生產環境。

　　整個所有的鏈路環節我們都應該會參與，這也是測試人員主人翁意識和責任心的體現。

　　自動化測試其實不是一個新的詞匯，也並非是一鐘高大上的技術。只是相對於目前大部分測試人員由於受限於代碼技術水平，所以自動化測試的推動較弱。

　　聞道有先後，術業有專攻，我們做手工測試的人員一定要滲透我們的功能業務，舉例子：在需求評審期，可以挖掘需求文檔的bug提醒產品經理進行優化 。

　　假設測試人員執行測試過程中發現，當想要配置一個活動露出的時間為明天上午11點，由於系統設計存在缺陷，配置活動的動作必須要提前1個小時以上完成系統才能在11點整正常露出，如果測試人員能及時提醒運營人員的工作，那麽一定會在降低客訴率上起到一定作用為客戶提供更好的客戶體驗。

　　對於自動化測試工程師，可以挖掘那一部分在某一段較長周期內，可預見的能明確輸出預期值的功能進行分層提取自動化起來，從而達到提高測試效率的目的。

　　最後，一個是快速的反饋。因為在傳統的項目中，測試會有一個集中的時間和測試點;就是等研發代碼碼完之後，再給測試提測。

　　這個時候需要準備測試的環境，準備測試的數據，還有測試的案例。在整個軟件開發周期中，有一個固定的時間是專署我們測試的環節，只有等完全確認好每一個流程之後才會生成測試報告。

　　其實，DevOps測試更多提倡的是一種快速的反饋。就好比現在很多創業公司，第一步就是要抓住市場，搶占市場先機。

　　快速反饋也代表著快速告知團隊我們的質量，大家最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。

　　1.2.DevOps中沈默的脊柱

　　對於DevOps測試，我個人認為是沈默的脊柱。

　　因為，很多的講座和視頻以及跟IT行業很多專家請教交流，大家提到DevOps是Development+Operations，從字面意義上來說是開發和運維。

　　但是，測試在這中間也是必不可少的一環。並非我們用代碼進行測試自動化之後測試人員就會被消滅掉，Devops價值文化中更多體現的是測試人員融入這個生態，使用自動化輔助提高我們的測試效率，同時對測試人員的技術和業務大局觀有了更高的要求。

　　從圖中，我們可以看到產品是從需求到研發的分析協作編碼，到持續集成的測試，然後到持續的部署，接下來進行持續的監控，最後到持續的反饋和優化。這是一個閉環，而且是一個完整的生態，其中持續測試就是重要的脊柱。

　　1.3.DevOps給測試帶來的好處

　　DevOps給測試帶來的好處有：

　　第一，測試環境虛擬化自動化部署。

　　第二，自動化構建變得簡單。

　　第三，配置管理數據更新維護更便捷。

　　第四，提高測試效率。

　　這幾個點會在之後進行詳細敘述。

　　2、如何適應DevOps的組織和文化

　　我們如何適應DevOps的組織和文化?大家在了解DevOps的時候，焦點都在研發和運維互相協作，以及打破壁壘和創造價值上。

　　其實，我們的測試也是要打破部門壁壘，早參與、多參與，而且多分享、信任，並且有主人翁的精神。測試人員要清楚自身的價值地位，我們是研發和業務之間最重要的橋梁!

　　我們怎麽樣去適應devops組織和文化呢?首先，我們需要運用創新工具來改變做事的思維和協作的方式。

　　對於冗余的、笨重的、低效率的溝通或者協作都要消除。同時，我們要擁抱變化，積極響應團隊的目標;不要覺得測試工具的改變會給自己帶來很多的挑戰從而感到害怕和沒有信心。而是，應該有一顆擁抱變化的心態，積極的參與，並且持續的改進。

　　3、一個關於測試的故事

　　3.1.測試的故事以及剖析

　　首先，分享是一個關於測試的故事。我跟很多做測試的同行有交流，所以這個故事並不是發生在某一個特定的人身上;而是我們大部分測試人員都會有這樣的困惑。

　　最近我朋友圈裏最流行一個圖，就是我是誰的小程序截圖。我們是測試或者開發怎麽樣，有一些調侃和吐槽。看到很多測試從業者吐出了很多苦水和不易。

　　現在是互聯網時代。很多的系統不是純粹的單體式架構(創建一個完美的產品去附和整個市場)，而是多方協調;即:這個系統只是公司內部一些API之間的調動不夠，還要去調第三方的API接口。

　　比如:有一個網站是賣食品，全中國有那麽多種類的食品，我們不可能創建一個工廠去生產所有種類的食品;而是，通過和不同的大型現貨供應商合作進行快速的批量對接。

　　我們在測試的過程中，很多時候都停留在一種等待的狀態。比如：測試賣食品的網站需要等待商戶提供可用可測的接口，然後才開始跑測試。這個時候測試處於一種被動等待的尷尬處境。

　　另外，測試人員的流動。因為無論什麽原因，比如：有更高的薪水、有更廣闊的平臺、學到更多的技術，或者搬到另外一個城市去生活都會影響人員的流動。

　　還有就是進來測試新人，有流動必然有新人進來，這些都會給我們測試流程帶來整體效率產出的降低。因為，新人進來需要熟悉業務和工具。

　　同時，測試工程師的配比也不是測試團隊可控的。現在，很多公司會考慮成本問題。所以，測試工程師的配比並不是按照國外所說的1：1、1：2的比例。我們可能達不到，因為需要降低成本，即：人員上投入的成本。

　　其次，很多公司在招聘的時會寫上要求，比如：會哪些技術，要求有豐富的工作經驗。

　　但是，在招進來之後，會發現對於做手工測試的人員學習自動化的成本非常高。同時，新進測試人員在團隊裏面的存在感較弱。

　　那麽以上問題產生的原因是什麽?因為，目前中國大部分企業都開始采用敏捷研發流程。

　　就是小步快跑，每一個叠代可能兩到三周。而每個叠代發版為了不影響線上用戶的使用都會選擇在半夜進行。

　　高頻率的半夜發版會增大團隊的內耗，大家容易產生疲倦的心態，這樣其實對產品的質量埋下了地雷。

　　再則，就是測試環境資源特別緊張，我相信這也是大多數公司都會存在的問題。當系統比較復雜的時候，我們需要不同的機器類型，比如：做兼容性的測試時，把測試的系統部署在多臺服務器上。

　　如果有集群涉及的機器更多，那麽這個時候測試的環境，比如：UAT和預發布測試環境，我們都按照生產上的配比去配置，準備許多不同的測試機器。從公司的角度來說，這個投入有點偏大。

　　接下來，是產品在上線前會經過一些測試。比如：我們是三周的測試和研發，前兩周是研發，第三周是測試。

　　有時候我們發現第三周可能在周一的時候還是不能測。為什麽?

　　因為，我們一直在等，等測試環境，等運維部署好測試環境，等開發說代碼全部碼好(這個時候提測可能延期)。這種被動的等待使得測試團隊的效率和士氣受損。

　　還有，準備測試其耗時很長，尤其當我們進行一些跑批的測試。比如：同步大量的第三方貨品信息到數據庫裏面，這時候會有大量的數據過來;如果進行測試準備，那麽耗時會非常的長。

　　無論是傳統的瀑布，還是現在流行的敏捷，都會有工作進度排期。我們可以把最開始的計劃(就是給測試排任務的時間表)和在執行測試整個過程中的時間表進行對比。

　　從而分析初期人力估算、時間估算和實際情況有哪些差異，差異的點在哪些模塊哪個環節。這個時候發現測試的困境是等待，阻塞、浪費和瓶頸以及消極情緒。

　　3.2.方案

　　通過實踐，我們總結出來一個可行方案：

　　第一，管理層積極的支持，跨部門的協作。

　　第二，我們建設測試服務平臺，搭建鏡像管理平臺。

　　第三，標準化分層測試，數字驅動改進，並且建設穩定可重復的流水線。

　　3.3.以微見著 Start Small

　　Start small，這個詞從字面意義上來說就是從小做起。什麽是從小做起?比說：我喜歡喝咖啡，可以直接去星巴克買一杯咖啡，也可以自己動手做一杯咖啡;

　　如果我想花費更少的成本去獲得一杯我想要喝的咖啡，那肯定是自己動手豐衣足食，這樣的成本會最低。

　　那麽，星巴克和這杯咖啡有什麽聯系?因為，我們自己沖泡一杯好的咖啡會從自己買豆子，再到研磨、萃取和沖泡。

　　這個流程每一個小環節其實都是一小步，我們不可能一下子把豆子做成咖啡，而是每一個環節都要一步一步來完成。

　　有朋友和我說DevOps其實大部分在忽悠洗腦，還有朋友跟我說，DevOps測試要那麽人一起協同工作，然而我們團隊裏的人並不喜歡改變已有的的一些習慣;

　　而且假設我們是乙方，我們的甲方也不願意配合我們做一些相應的協調。這樣導致推動積極性大大降低。

　　其實我想說不要太焦慮，就是不要擔心我們無法控制的事情，我們為什麽管一些不可控制的事情呢?我們不要害怕改變，因為想看到成果肯定需要改變的。

　　但是也不要一下子將所有的東西都進行改變，我們可以慢慢的來，水滴石穿，用可量化的指標去呈現給你的老板看。

　　同時在這裏還要提到使用精益的方法。關於精益的方法，大家或許有一定的了解了;它是豐田推崇的理念：杜絕浪費，提高效率。還有就是找到一個願意合作的夥伴，互相督促，互相鼓勵和互相進步。

　　另外一個值得關註的點是我們要梳理好基線，方便我們後期做出變革後進行前後對比，這樣才好度量進步了多少。最後是改進一個測試的流程，並且分享和影響他人。

　　使用現在擁有的手段，換句話說：自動化測試不是一個新的技術，而且我們也不要急於自動化，錯誤的自動化將造成技術債。

　　就像買車買房一樣，你背了債，你要償還利息就會越來越多。我們應該是梳理自己公司目前團隊所擁有的，並且已經熟悉的工具。

　　3.5.單元和接口測試以及UI自動化測試框架

　　接下來，分享下測試體系的知識。一個是單元測試，需要關註幾個點：檢測函數返回值，檢測函數拋出的異常。檢測端口被調用的次數。

　　然後，是接口測試：檢測數據類型、數據格式、業務邏輯。

　　最後是UI的測試框架。這裏只是簡單提供給大家參考，分為用例層、提取層和工具層。為什麽會有這麽一個框架的存在?

　　如果簡單的用目前市面上開源的selenium直接使用，團隊協作實現維護成本較高。

　　所以我們要花更多的時間去看自己的程序和框架，建立一個可靠的穩定的測試框架是很有必要的。

　　4、測試金字塔

　　上圖是我們的分層測試。Google測試之道裏面有提到：有一個比例是單元測試、接口測試，還有UI的測試是7：2：1。

　　但是，真正的執行測試過程中我們應該因地制宜。因為這個比例並不是固定的，而是要根據自己項目的特點來找到最合適的比例配置。

　　如果就你一個人在做測試，你會要求自己把所有的單元測試都做到70%嗎?那其實是不現實的，我們應該要考慮當前實際的情況。

　　對於分層測試，這裏列了為什麽執行測試?由誰執行，以及測試的工具有哪些，還有頻率，投資回報率等。

　　5、建設可靠可重復的交付流水線

　　上述所說的可靠可重復的交付流水線，其實就是如上圖所示。研發在編碼完成之後，要進行一個自測。在代碼投入之後，我們要觸發編譯、掃描和測試。然後，單元測試會執行鏡像。接著就是模塊的測試和系統測試。

　　那麽，下一步就是日常的測試。這裏提到一個人工決策，為什麽會有人工決策?因為，並非所有的測試都可以自動化完成的。

　　舉個例子，比如探索性測試，如果連人類自己都不知道預期的結果是什麽樣的，難道人工智能就會知道嗎?目前來看人工智能的博弈還在持續發展中。

　　在做完日常測試後，我們會做集成測試、拉出分支和準入測試。準入測試是什麽呢?

　　就是在做大規模測試的時候並不是說開發、運維準備了一個環境就會測試了，而是有一系列的腳本來判斷是不是可以進行大規模的深入測試。

　　接著上灰度測試，也就是部分生產流量流入。

　　最後上生產：生產有一個監控和報警。為什麽要有監控和報警呢?不是說我們測完了就上線了，並在線上走一輪冒煙就完事了。

　　因為有一些BUG隱藏得很深，並非上了線點一輪就OK了，沒有BUG了。在達到某些特殊的情況才爆發出來，這個時候對用戶會產生一些負面的影響，所以我們就需要有監控，如果有異常的行為都要快速的響應。

　　搭建測試服務平臺從三個方面來做：

　　測試數據服務;

　　一個是Mock;

　　一個是日誌搜索引擎。

　　測試數據服務是可以寫代碼、調用一些結果或者從線上引流過來。Mock就相當於打樁，演電影有一些替身，這個就是替身。

　　Mock Server，我們可以進行第二次的開發，效果是降低耦合。日誌搜索引擎，我們在發現BUG的時候，要先自己過一遍這個到底是不是一個BUG(有可能它是個偽BUG)，所以我們要借助強大的日誌。

　　這裏提到的是ELK，這個也是開源的，我們測試人員自己可以搭建一套，或者和運維研發人員協商一起搭建。

　　6、數字驅動改進

　　最後，我提到的是數字驅動改進。有些領導說你什麽時候能給我答案，你的測試結果是怎麽樣的?你的狀態是怎麽樣的?如果你回答是一天，有可能領導會問為什麽還要一天?我晚上就要上線了，或者我要很快的知道目前這個產品質量的狀態。

　　那麽，這個時候如果你采用自動化測試，並且快速的量化測試結果，其實可以達到秒級響應。這裏的例子是把測試結果推送給微信。上面顯示的是淩晨兩三點執行的測試結果。

　　當測試環境在雲上或者假設部署在雲上，以及當雲平臺做一些遷移的時候，也許不需要讓整個測試團隊在深更半夜都留下來值班。

　　而是可以通過自動化的測試流程來快速的得到響應，知道測試的狀態和進度，然後反饋給研發團隊和領導。

　　最後一句話：優秀的測試人員其實是擁有CEO的思維，去推動研發流程標準化建立的重要角色，因為測試是研發和產品的橋梁，做測試的你更了解一線研發和產品的情況，需要內心篤定去推動流程落地和優化，哪怕過程中會遇到困難，但是堅持做為客戶為團隊帶來更大價值的事情是意義深遠的。

　　大連男科醫院哪家好 http://wapjbk.39.net/yiyuanzaixian/dlbhyy/

　　大連渤海醫院電話 http://wapjbk.39.net/yiyuanfengcai/lx_dlbhyy/

DevOps 測試在企業中如何落地？