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(Dev With Confidence), 有興趣的同事能夠諮詢咱們組的Andy Ma和Vicky Chen 同窗。

那麼在這樣的開發模式下，咱們要怎樣進行質量保證工做呢？如下是我我的的粗淺看法：

第一，團隊的目標是交付。

隨時隨地，各類形式，各類方式，無所不用其極地強調咱們的目標是交付。 當咱們說某一個功能是否是完成，那必定是指這個功能是否是良好運行在產品環境（而不是本地或測試環境），並知足定義好的質量要求（功能，性能，安全性等等）。

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

當產品只有長週期，大版本的交付時，在平常工做中咱們容易會把某些任務，特別是質量保證任務放到後期進行，質量債務趁虛而入。而若是實現的增量要快速交付，咱們就不得不把質量保證任務融入到平常開發活動中。開發人員, QE, 產品經理以及團隊的全部人都要進行相應的質量保證活動，讓缺陷無處遁形。

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

而Quality Strategy 絕對不是一成不變的，需求在變化，產品在變化，團隊在變化，質量保證活動也應該隨之變化。每運行一段時間，咱們要收集反饋，不管是外部質量的反饋（好比來自產品團隊的反饋，客戶報告的缺陷或需求），仍是內部質量的反饋，好比需求是否清晰，測試案例是否valuable, 代碼質量是否足夠好，自動化ROI(Return on Investment)是否可接受，等等。根據這些反饋，咱們再來改進質量策略。

第三，預防缺陷

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

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的原創技術文章，請關注公衆號"汪子熙"或者掃描下面二維碼: