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

當(dāng)我們談?wù)撥浖a(chǎn)品的質(zhì)量保證工作時，必然是基于某種軟件開發(fā)模式上的。皮之不存，毛將焉附？脫離了軟件開發(fā)模式，質(zhì)量保證工作就是空中樓閣。相信大家都感受到，近十幾年，軟件開發(fā)模式不斷涌現(xiàn)新的概念和詞匯，Agile, Continuous Integration , Continuous Delivery, DevOps ，令人應(yīng)接不暇。我們首先要理解軟件開發(fā)模式的變遷，然后才能進行與開發(fā)模式匹配的質(zhì)量保證活動。

1. 瀑布開發(fā)

傳統(tǒng)的瀑布模式如下圖：

在這種模式下，測試活動僅僅是線性開發(fā)活動的后期活動。質(zhì)量保證嚴(yán)格依賴于各個文檔（需求文檔，設(shè)計文檔，測試計劃和測試報告）以及評審會議，自動化測試可有可無。

2.增量開發(fā)

團隊把產(chǎn)品的需求，設(shè)計，實現(xiàn)以及測試放在若干迭代周期里完成，每個迭代結(jié)束的交付物視為產(chǎn)品的增量，不要求增量達到能交付的要求，但需要能夠基本可以工作。產(chǎn)品的交付仍然發(fā)生在最后，如下圖所示：

增量開發(fā)的核心就是持續(xù)測試和持續(xù)集成。對質(zhì)量保證工作來說，分為了兩類活動。 一是迭代中對增量的質(zhì)量保證，二是發(fā)布前對整個產(chǎn)品的質(zhì)量保證。由于增量和產(chǎn)品最終交付的要求是不一樣的，所以通常在軟件發(fā)布前團隊要停止功能開發(fā)，進行全方位的回歸測試和缺陷修復(fù)，從而保證產(chǎn)品質(zhì)量達到交付要求。增量開發(fā)的優(yōu)點很明顯：

• 測試的計劃，執(zhí)行，評估不僅僅是基于每一個發(fā)布版本，而是細化到每一個迭代中。產(chǎn)品的質(zhì)量在開發(fā)過程中進行了頻繁的校驗，質(zhì)量的可見性更高，反饋更及時。
• 過程的質(zhì)量更多的被考慮在了質(zhì)量管理范疇中。質(zhì)量管理人員深入到項目過程中，能觀察到團隊的整體運行情況，從一些實際質(zhì)量現(xiàn)象和數(shù)據(jù)上反饋團隊存在的問題，從而幫助團隊識別風(fēng)險，并相應(yīng)調(diào)整開發(fā)和測試策略。

3.敏捷開發(fā)

實際上，運行的很好的增量開發(fā)已經(jīng)具備了敏捷開發(fā)的雛形，它們都具有以下特點：

• 強調(diào)短時間的迭代
• 必須實現(xiàn)持續(xù)測試和持續(xù)集成
• 能響應(yīng)頻繁的需求變化。

那什么是敏捷開發(fā)?它的核心又是什么呢? 如下圖所示，相對于“非敏捷”，敏捷開發(fā)在Continues Integration(CI)的基礎(chǔ)上強調(diào)Continuous Delivery(CD),每個迭代的產(chǎn)出物要達到可交付質(zhì)量要求，它的核心就是把發(fā)布（到客戶的生產(chǎn)環(huán)境）也納入到短時間的迭代中。

成都Revenue Cloud團隊從2016年項目一開始就明確定義了這個方向，我們要一步步地實現(xiàn)真正的Continuous Delivery。負責(zé)Infrastructure 的德國同事們做了很多工作，搭建了支持持續(xù)交付的完整框架，包括持續(xù)集成，構(gòu)建管理，配置管理，發(fā)布管理，我們稱之為DWC(**D**ev?**W**ith?**C**onfidence), 有興趣的同事可以咨詢我們組的Andy Ma和Vicky Chen 同學(xué)。

那么在這樣的開發(fā)模式下，我們要怎樣進行質(zhì)量保證工作呢？以下是我個人的粗淺見解：

第一，團隊的目標(biāo)是交付。

隨時隨地，各種形式，各種方式，無所不用其極地強調(diào)我們的目標(biāo)是交付。 當(dāng)我們說某一個功能是不是完成，那一定是指這個功能是不是良好運行在產(chǎn)品環(huán)境（而不是本地或測試環(huán)境），并滿足定義好的質(zhì)量要求（功能，性能，安全性等等）。

第二，全員對質(zhì)量負責(zé)，質(zhì)量保證活動是日常開發(fā)活動的一部分。

當(dāng)產(chǎn)品只有長周期，大版本的交付時，在日常工作中我們?nèi)菀讜涯承┤蝿?wù)，特別是質(zhì)量保證任務(wù)放到后期進行，質(zhì)量債務(wù)趁虛而入。而如果實現(xiàn)的增量要快速交付，我們就不得不把質(zhì)量保證任務(wù)融入到日常開發(fā)活動中。開發(fā)人員, QE, 產(chǎn)品經(jīng)理以及團隊的所有人都要進行相應(yīng)的質(zhì)量保證活動，讓缺陷無處遁形。

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

而Quality Strategy 絕對不是一成不變的，需求在變化，產(chǎn)品在變化，團隊在變化，質(zhì)量保證活動也應(yīng)該隨之變化。每運行一段時間，我們要收集反饋，無論是外部質(zhì)量的反饋（比如來自產(chǎn)品團隊的反饋，客戶報告的缺陷或需求），還是內(nèi)部質(zhì)量的反饋，比如需求是否清晰，測試案例是否valuable, 代碼質(zhì)量是否足夠好，自動化ROI(**R**eturn?**o**n?**I**nvestment)是否可接受，等等。根據(jù)這些反饋，我們再來改進質(zhì)量策略。

第三，預(yù)防缺陷

測試是一種基于后驗的質(zhì)量保證方法。另一個更為重要的先驗方法，就是缺陷預(yù)防。也就是說在開發(fā)人員提交測試前預(yù)防缺陷的產(chǎn)生，包括:

在開發(fā)人員實現(xiàn)代碼前，盡量確保需求清晰，Accept Criteria 和自測點清晰。

在產(chǎn)品功能實現(xiàn)過程中，開發(fā)人員, 產(chǎn)品經(jīng)理, QE,UX ,UA密切溝通，確保需求，實現(xiàn)和測試點的正確性和全面性。大家都坐在一個辦公室里面，不管是Daily Meeting還是直接面對面, 溝通是很容易的，關(guān)鍵在于大家有沒這個意識和習(xí)慣。

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

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

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

自動化測試絕不是QE 一個人的事情。自動化測試和功能實現(xiàn)一樣，應(yīng)該是整個團隊的任務(wù)，和功能backlog一樣，包括QE和開發(fā)人員在內(nèi)的所有團隊人員都可以領(lǐng)取自動化測試的任務(wù) 。測試代碼也應(yīng)和功能代碼一樣對待，要進行代碼審查,以及代碼維護。不要舍不得讓資深的人員參與自動化測試，良好可靠的自動化測試終會讓團隊受益。

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

我們團隊在剛開始做E2E(End-to-End)自動化測試時，測試總是不夠穩(wěn)定，但經(jīng)過一段時間的結(jié)果監(jiān)控，我們逐步總結(jié)并優(yōu)化了遇到的一些常見問題 ：比如測試數(shù)據(jù)之間有依賴或沖突，identify UI 元素的ID不唯一，斷言不準(zhǔn)確，測試前置條件被其他自動或手動測試破壞，UI新的調(diào)整或?qū)崿F(xiàn)導(dǎo)致測試失效等等。經(jīng)過團隊一段時間的努力，現(xiàn)在E2E測試的有效性大大提高了，團隊所有成員都認(rèn)可自動化測試的反饋。分析和優(yōu)化的過程可能是痛苦的，甚至讓你懷疑投入是否值得。但堅持下來，當(dāng)自動化測試有效性得到保證時候，你會感受到它帶給你的安全感。

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

我們既要避免某個層面測試薄弱，也要避免在多個層面進行重復(fù)的自動化測試。以成都團隊為例，在開始的一兩個release， 我們對Service Unit Test 的要求是覆蓋率>80%, Service Integration Test 大致是覆蓋60%的API測試用例, 然后E2E GUI Test覆蓋核心業(yè)務(wù)場景, UI 的Integration Test并沒有引入。后來隨著項目的進行，我們發(fā)現(xiàn)API Integration Test 投入產(chǎn)出比最高。它比Unit Test 更接近service 真實行為，它比E2E GUI Test反饋更早更快，也更易實現(xiàn)。我們逐漸調(diào)整了策略，減少了Unit Test 的比重, 加大了Integration Test 的覆蓋，目前我們API 的Integration Test 覆蓋了>80%的測試用例。

再后來，隨著產(chǎn)品功能的增加，我們發(fā)現(xiàn)E2E GUI 測試運行越來越慢，于是我們又再次調(diào)整了策略，一是引入是OPA5的UI Integration Test，把原來E2E GUI測試中純UI 的邏輯完全挪到OPA5測試中,大大縮短了自動化測試的運行時間。二是減少了部分和Service Integration Test 的重復(fù)測試,使E2E GUI 測試更多的側(cè)重于端到端完整的業(yè)務(wù)場景，而不僅僅是某個具體功能。 通過這兩次調(diào)整，多層面的自動化測試能更高效的分工合作，為產(chǎn)品質(zhì)量保駕護航。

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

SauceLabs 是一個云測試服務(wù)平臺，在云上提供VMs運行多個測試，并提供了視頻錄制，截圖和日志記錄功能，很好地解決了多個自動化測試并行運行的設(shè)備問題。并且它支持不同瀏覽器，不同屏幕分辨率，可以應(yīng)用到瀏覽器兼容性測試中。當(dāng)然，這個是商業(yè)服務(wù)，申請的VM 越多，價格越貴。

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

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

因此，我最后特別想和大家分享的一點是QE 的角色定位。QE 不是充當(dāng)警察的角色，站在大家對立面挑刺。QE也不是最后的質(zhì)量安全防線，站在大家身后填坑救火。QE是和大家一起并肩戰(zhàn)斗的戰(zhàn)友。一方面，QE充當(dāng)著質(zhì)量教練，引導(dǎo)和幫助團隊提升質(zhì)量，建立成熟的質(zhì)量文化。另一方面，和Agile團隊的每一位成員一樣，QE也需要在團隊中不斷學(xué)習(xí)和成長，不僅僅是加強QE技能，還要加強對業(yè)務(wù)的理解，對用戶行為的認(rèn)知， 甚至對具體實現(xiàn)技術(shù)的認(rèn)識。

最后感謝大家閱讀。關(guān)于SAP Revenue Cloud產(chǎn)品本身的更多介紹，請參考SAP官網(wǎng)：https://cx.sap.com/en/products/billing/revenue-cloud

更多閱讀

• SAP成都研究院DevOps那些事
• 金庸和古龍，Netweaver和微服務(wù)，以及SAP Hybris Revenue Cloud

要獲取更多Jerry的原創(chuàng)技術(shù)文章，請關(guān)注公眾號”汪子熙”或者掃描下面二維碼:

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。