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)是否可接受，等等。根據這些反饋，我們再來改進質量策略。

第三，預防缺陷

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

1. 在開發人員實現程式碼前，儘量確保需求清晰，Accept Criteria 和自測點清晰。

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

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

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

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

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

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

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

4. 多層面的自動化測試要綜合考慮。 自動化測試是多個層面的，在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

要獲取更多Jerry的原創技術文章，請關注公眾號"汪子熙"或者掃描下面二維碼:

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/24475491/viewspace-2213833/，如需轉載，請註明出處，否則將追究法律責任。