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)是否可接受,等等。根據這些反饋,我們再來改進質量策略。
第三,預防缺陷
測試是一種基于后驗的質量保證方法。另一個更為重要的先驗方法,就是缺陷預防。也就是說在開發人員提交測試前預防缺陷的產生,包括:
第四,實施策略性的自動化測試
當我們的發布周期很長時,可能覺得自動化測試可有可無,作用也不是那么明顯,但隨著發布周期越來越短,自動化測試的重要性越來越明顯。在Revenue Cloud ,我們除了季度的大版本發布,還有更短周期的feature發布,以及每天的patch發布。可以說,自動化測試是不可動搖的根本。然而實現自動化測試,必然有很多因素要考慮。誰來做?選什么工具?哪些測試被自動化?各個層面的自動化怎么組合?這個策略需要團隊自己決定,嘗試和改進,畢竟適合的才是最好的。但我認為有幾點原則是共性的:
我們既要避免某個層面測試薄弱,也要避免在多個層面進行重復的自動化測試。以成都團隊為例,在開始的一兩個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成都研究院姚瑶:软件质量保证工作的变迁的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 移动端HTML5 文件下载
- 下一篇: 记录我开发工作中遇到HTTP跨域和OPT