大家好，我是來自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

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

總結

以上是生活随笔為你收集整理的SAP成都研究院姚瑶：软件质量保证工作的变迁的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。