SAP成都研究院姚瑤：軟體品質保證工作的變遷

大家好，我是來自SAP成都研究院Revenue Cloud 團隊的品質工程師 , yoyo。很高興可以和大家分享我個人的工作體會。每個團隊都有QE（Quality Engineer）, 相信大家對QE 的工作并不陌生，我也就不唠叨QE 的具體工作啦。作為從事軟體品質保證工作十年的“老人”，我想就我個人的工作經曆和大家探讨下軟體品質保證工作的變遷。

當我們談論軟體産品的品質保證工作時，必然是基于某種軟體開發模式上的。皮之不存，毛将焉附？脫離了軟體開發模式，品質保證工作就是空中樓閣。相信大家都感受到，近十幾年，軟體開發模式不斷湧現新的概念和詞彙，Agile, Continuous Integration , Continuous Delivery, DevOps ，令人應接不暇。我們首先要了解軟體開發模式的變遷，然後才能進行與開發模式比對的品質保證活動。

1. 瀑布開發

傳統的瀑布模式如下圖：

在這種模式下，測試活動僅僅是線性開發活動的後期活動。品質保證嚴格依賴于各個文檔（需求文檔，設計文檔，測試計劃和測試報告）以及評審會議，自動化測試可有可無。

2.增量開發

團隊把産品的需求，設計，實作以及測試放在若幹疊代周期裡完成，每個疊代結束的傳遞物視為産品的增量，不要求增量達到能傳遞的要求，但需要能夠基本可以工作。産品的傳遞仍然發生在最後，如下圖所示：

增量開發的核心就是持續測試和持續內建。對品質保證工作來說，分為了兩類活動。 一是疊代中對增量的品質保證，二是釋出前對整個産品的品質保證。由于增量和産品最終傳遞的要求是不一樣的，是以通常在軟體釋出前團隊要停止功能開發，進行全方位的回歸測試和缺陷修複，進而保證産品品質達到傳遞要求。增量開發的優點很明顯：

測試的計劃，執行，評估不僅僅是基于每一個釋出版本，而是細化到每一個疊代中。産品的品質在開發過程中進行了頻繁的校驗，品質的可見性更高，回報更及時。

過程的品質更多的被考慮在了品質管理範疇中。品質管理人員深入到項目過程中，能觀察到團隊的整體運作情況，從一些實際品質現象和資料上回報團隊存在的問題，進而幫助團隊識别風險，并相應調整開發和測試政策。

3.靈活開發

實際上，運作的很好的增量開發已經具備了靈活開發的雛形，它們都具有以下特點：

強調短時間的疊代

必須實作持續測試和持續內建

能響應頻繁的需求變化。

那什麼是靈活開發?它的核心又是什麼呢? 如下圖所示，相對于“非靈活”，靈活開發在Continues Integration(CI)的基礎上強調Continuous Delivery(CD),每個疊代的産出物要達到可傳遞品質要求，它的核心就是把釋出（到客戶的生産環境）也納入到短時間的疊代中。

成都Revenue Cloud團隊從2016年項目一開始就明确定義了這個方向，我們要一步步地實作真正的Continuous Delivery。負責Infrastructure 的德國同僚們做了很多工作，搭建了支援持續傳遞的完整架構，包括持續內建，建構管理，配置管理，釋出管理，我們稱之為DWC(**D**ev **W**ith **C**onfidence), 有興趣的同僚可以咨詢我們組的Andy Ma和Vicky Chen 同學。

那麼在這樣的開發模式下，我們要怎樣進行品質保證工作呢？以下是我個人的粗淺見解：

第一，團隊的目标是傳遞。

随時随地，各種形式，各種方式，無所不用其極地強調我們的目标是傳遞。 當我們說某一個功能是不是完成，那一定是指這個功能是不是良好運作在産品環境（而不是本地或測試環境），并滿足定義好的品質要求（功能，性能，安全性等等）。

第二，全員對品質負責，品質保證活動是日常開發活動的一部分。

當産品隻有長周期，大版本的傳遞時，在日常工作中我們容易會把某些任務，特别是品質保證任務放到後期進行，品質債務趁虛而入。而如果實作的增量要快速傳遞，我們就不得不把品質保證任務融入到日常開發活動中。開發人員, QE, 産品經理以及團隊的所有人都要進行相應的品質保證活動，讓缺陷無處遁形。

怎樣落實呢? 那就是定義我們的Quality Strategy 了， 保障每個角色(who)都清楚知道自己應該在什麼時候(when)，什麼環境(where)下如何進行(how)什麼樣(what)的品質保證活動。建議團隊可以有一張圖來指導大家。 這是Revenue Cloud 成都團隊的品質保證活動的Overview Picture(出于安全考慮，landscape 被我打上馬賽克啦)。

而Quality Strategy 絕對不是一成不變的，需求在變化，産品在變化，團隊在變化，品質保證活動也應該随之變化。每運作一段時間，我們要收集回報，無論是外部品質的回報（比如來自産品團隊的回報，客戶報告的缺陷或需求），還是内部品質的回報，比如需求是否清晰，測試案例是否valuable, 代碼品質是否足夠好，自動化ROI(**R**eturn **o**n **I**nvestment)是否可接受，等等。根據這些回報，我們再來改進品質政策。

第三，預防缺陷

測試是一種基于後驗的品質保證方法。另一個更為重要的先驗方法，就是缺陷預防。也就是說在開發人員送出測試前預防缺陷的産生，包括:

在開發人員實作代碼前，盡量確定需求清晰，Accept Criteria 和自測點清晰。

在産品功能實作過程中，開發人員, 産品經理, QE,UX ,UA密切溝通，確定需求，實作和測試點的正确性和全面性。大家都坐在一個辦公室裡面，不管是Daily Meeting還是直接面對面, 溝通是很容易的，關鍵在于大家有沒這個意識和習慣。

在開發人員代碼送出（從自己的分支送出代碼到主線）前，除了通過所有的自動化回歸測試，還需要按自測點來驗證實作的新功能。在這點上，我們需要思考怎樣幫助裡開發人員更好更有效的做自測。比如，自測點Scope是否合适？是不是有些重要場景沒覆寫或者場景定義太多？開發人員是否需要培養測試思維或方法？Planning時候是否沒有預估自測時間？開發人員自測是否得到了産品經理/QE及時和正确的回報？

第四，實施政策性的自動化測試

當我們的釋出周期很長時，可能覺得自動化測試可有可無，作用也不是那麼明顯，但随着釋出周期越來越短，自動化測試的重要性越來越明顯。在Revenue Cloud ,我們除了季度的大版本釋出，還有更短周期的feature釋出，以及每天的patch釋出。可以說，自動化測試是不可動搖的根本。然而實作自動化測試，必然有很多因素要考慮。誰來做？選什麼工具？哪些測試被自動化？各個層面的自動化怎麼組合？這個政策需要團隊自己決定，嘗試和改進，畢竟适合的才是最好的。但我認為有幾點原則是共性的：

自動化測試絕不是QE 一個人的事情。自動化測試和功能實作一樣，應該是整個團隊的任務，和功能backlog一樣，包括QE和開發人員在内的所有團隊人員都可以領取自動化測試的任務 。測試代碼也應和功能代碼一樣對待，要進行代碼審查,以及代碼維護。不要舍不得讓資深的人員參與自動化測試，良好可靠的自動化測試終會讓團隊受益。

自動化測試的有效性比完備性更重要。如果自動化測試的“假失效”和“假通過”太高，對團隊來說不僅沒有幫助，反而是一種幹擾。要保證測試的有效性，除了保障測試腳本實作的品質外，還有很重要的一點，不要放過自動化測試的每一個fail， 要分析清楚fail的原因，是産品實作層面的缺陷就改實作，是測試腳本的問題就改腳本，是環境問題就優化環境。如果以自動化測試不穩定為理由，不去深入分析，那它永遠都不穩定，自動化測試結果也永遠得不到信賴。

我們團隊在剛開始做E2E(End-to-End)自動化測試時，測試總是不夠穩定，但經過一段時間的結果監控，我們逐漸總結并優化了遇到的一些常見問題 ：比如測試資料之間有依賴或沖突，identify UI 元素的ID不唯一，斷言不準确，測試前置條件被其他自動或手動測試破壞，UI新的調整或實作導緻測試失效等等。經過團隊一段時間的努力，現在E2E測試的有效性大大提高了，團隊所有成員都認可自動化測試的回報。分析和優化的過程可能是痛苦的，甚至讓你懷疑投入是否值得。但堅持下來，當自動化測試有效性得到保證時候，你會感受到它帶給你的安全感。

多層面的自動化測試要綜合考慮。自動化測試是多個層面的，在Revenue Cloud ,以功能測試為例，測試可以分為Unit Test, Integration Test, Contract Test, E2E Test。如下圖所示：

我們既要避免某個層面測試薄弱，也要避免在多個層面進行重複的自動化測試。以成都團隊為例，在開始的一兩個release， 我們對Service Unit Test 的要求是覆寫率>80%, Service Integration Test 大緻是覆寫60%的API測試用例, 然後E2E GUI Test覆寫核心業務場景, UI 的Integration Test并沒有引入。後來随着項目的進行，我們發現API Integration Test 投入産出比最高。它比Unit Test 更接近service 真實行為，它比E2E GUI Test回報更早更快，也更易實作。我們逐漸調整了政策，減少了Unit Test 的比重, 加大了Integration Test 的覆寫，目前我們API 的Integration Test 覆寫了>80%的測試用例。

再後來，随着産品功能的增加，我們發現E2E GUI 測試運作越來越慢，于是我們又再次調整了政策，一是引入是OPA5的UI Integration Test，把原來E2E GUI測試中純UI 的邏輯完全挪到OPA5測試中,大大縮短了自動化測試的運作時間。二是減少了部分和Service Integration Test 的重複測試,使E2E GUI 測試更多的側重于端到端完整的業務場景，而不僅僅是某個具體功能。 通過這兩次調整，多層面的自動化測試能更高效的分工合作，為産品品質保駕護航。

以上三點是我認為定義自動化測試政策的重要原則。另外，我經常被問到一個問題： 你們項目采用什麼自動化測試架構/工具呢? 在談到多層面自動化測試的時候，我列出了Revenue Cloud 采用的自動化測試工具。對于Unit Test, Contract Test, Integration test 這些和技術平台/語言相關的測試，我們采用的測試工具并沒有什麼” 驚喜” 。Junit，Spring Contract Cloud, OPA5, Rest-Assured 都是大家耳熟能詳的測試架構，在SAP 類似技術背景的項目中廣泛應用着。我重點介紹下可能大家比較陌生的Nightwatch + SauceLabs 的E2E 測試方案吧。

SauceLabs 是一個雲測試服務平台，在雲上提供VMs運作多個測試，并提供了視訊錄制，截圖和日志記錄功能，很好地解決了多個自動化測試并行運作的裝置問題。并且它支援不同浏覽器，不同螢幕分辨率，可以應用到浏覽器相容性測試中。當然，這個是商業服務，申請的VM 越多，價格越貴。

Nightwatch(守夜人)，這是一個使用Selenium 2 (webdriver)實作的開源E2E 測試架構，對Selenium API 做了些封裝，能更容易和簡潔的實作測試腳本，但它不支援UI 操作錄制。其實本質上，它和Selenium, Ranorex, Start 等工具沒什麼實質不同。就像江湖高手會根據自己的喜好、功夫的特點選擇武器，我們也可以根據團隊的技術特點和偏好，當然還有預算來選擇工具。然而工具隻是工具，就像決定比武結果的決定因素并不是武器一樣，決定自動化實施成功的關鍵因素，從來不是工具，而在于我們自己的功夫修為本身。

**第五, QE的角色定位。**Revenue Cloud 成都團隊從2016年建立，也曾經回歸缺陷 比比皆是，也曾經有送出測試的功能連Smoke Test（冒煙測試）都跑不過。那段時間，QE其實很忙碌的，有各種測試要做，各種缺陷要回歸測試，而且産品發版前還緊張的不行。但到現在，團隊越來越成熟，品質意識越來越好，開發人員送出測試的backlog 一次通過率基本維持在80%左右。在整個項目交叉測試時候，其他組給我們提的缺陷越來越稀少，團隊的傳遞越來越順暢，而我作為QE， 不再淹沒在基礎測試中，可以有更多的時間做更有價值的事情。我也在團隊的需求和幫助下，學習了自動化測試架構， 研究了SAP産品标準的Performance, Accessibility, GDPR 以及Fiori Guideline 等等，拓展了自身的技術領域。

是以，我最後特别想和大家分享的一點是QE 的角色定位。QE 不是充當警察的角色，站在大家對立面挑刺。QE也不是最後的品質安全防線，站在大家身後填坑救火。QE是和大家一起并肩戰鬥的戰友。一方面，QE充當着品質教練，引導和幫助團隊提升品質，建立成熟的品質文化。另一方面，和Agile團隊的每一位成員一樣，QE也需要在團隊中不斷學習和成長，不僅僅是加強QE技能，還要加強對業務的了解，對使用者行為的認知， 甚至對具體實作技術的認識。

最後感謝大家閱讀。關于SAP Revenue Cloud産品本身的更多介紹，請參考SAP官網：

https://cx.sap.com/en/products/billing/revenue-cloud

更多閱讀

SAP成都研究院DevOps那些事

金庸和古龍，Netweaver和微服務，以及SAP Hybris Revenue Cloud