本篇內(nèi)容主要講解“SAP軟件質(zhì)量怎么保證工作的變遷”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“SAP軟件質(zhì)量怎么保證工作的變遷”吧!
當(dāng)我們談?wù)撥浖a(chǎn)品的質(zhì)量保證工作時(shí)，必然是基于某種軟件開發(fā)模式上的。皮之不存，毛將焉附？脫離了軟件開發(fā)模式，質(zhì)量保證工作就是空中樓閣。相信大家都感受到，近十幾年，軟件開發(fā)模式不斷涌現(xiàn)新的概念和詞匯，Agile, Continuous Integration , Continuous Delivery, DevOps ，令人應(yīng)接不暇。我們首先要理解軟件開發(fā)模式的變遷，然后才能進(jìn)行與開發(fā)模式匹配的質(zhì)量保證活動(dòng)。
1. 瀑布開發(fā)
傳統(tǒng)的瀑布模式如下圖：
在這種模式下，測(cè)試活動(dòng)僅僅是線性開發(fā)活動(dòng)的后期活動(dòng)。質(zhì)量保證嚴(yán)格依賴于各個(gè)文檔（需求文檔，設(shè)計(jì)文檔，測(cè)試計(jì)劃和測(cè)試報(bào)告）以及評(píng)審會(huì)議，自動(dòng)化測(cè)試可有可無。
2.增量開發(fā)
團(tuán)隊(duì)把產(chǎn)品的需求，設(shè)計(jì)，實(shí)現(xiàn)以及測(cè)試放在若干迭代周期里完成，每個(gè)迭代結(jié)束的交付物視為產(chǎn)品的增量，不要求增量達(dá)到能交付的要求，但需要能夠基本可以工作。產(chǎn)品的交付仍然發(fā)生在最后，如下圖所示：
增量開發(fā)的核心就是持續(xù)測(cè)試和持續(xù)集成。對(duì)質(zhì)量保證工作來說，分為了兩類活動(dòng)。 一是迭代中對(duì)增量的質(zhì)量保證，二是發(fā)布前對(duì)整個(gè)產(chǎn)品的質(zhì)量保證。由于增量和產(chǎn)品最終交付的要求是不一樣的，所以通常在軟件發(fā)布前團(tuán)隊(duì)要停止功能開發(fā)，進(jìn)行全方位的回歸測(cè)試和缺陷修復(fù)，從而保證產(chǎn)品質(zhì)量達(dá)到交付要求。增量開發(fā)的優(yōu)點(diǎn)很明顯：
測(cè)試的計(jì)劃，執(zhí)行，評(píng)估不僅僅是基于每一個(gè)發(fā)布版本，而是細(xì)化到每一個(gè)迭代中。產(chǎn)品的質(zhì)量在開發(fā)過程中進(jìn)行了頻繁的校驗(yàn)，質(zhì)量的可見性更高，反饋更及時(shí)。
過程的質(zhì)量更多的被考慮在了質(zhì)量管理范疇中。質(zhì)量管理人員深入到項(xiàng)目過程中，能觀察到團(tuán)隊(duì)的整體運(yùn)行情況，從一些實(shí)際質(zhì)量現(xiàn)象和數(shù)據(jù)上反饋團(tuán)隊(duì)存在的問題，從而幫助團(tuán)隊(duì)識(shí)別風(fēng)險(xiǎn)，并相應(yīng)調(diào)整開發(fā)和測(cè)試策略。
3.敏捷開發(fā)
實(shí)際上，運(yùn)行的很好的增量開發(fā)已經(jīng)具備了敏捷開發(fā)的雛形，它們都具有以下特點(diǎn)：
強(qiáng)調(diào)短時(shí)間的迭代
必須實(shí)現(xiàn)持續(xù)測(cè)試和持續(xù)集成
能響應(yīng)頻繁的需求變化。
那什么是敏捷開發(fā)?它的核心又是什么呢? 如下圖所示，相對(duì)于“非敏捷”，敏捷開發(fā)在Continues Integration(CI)的基礎(chǔ)上強(qiáng)調(diào)Continuous Delivery(CD),每個(gè)迭代的產(chǎn)出物要達(dá)到可交付質(zhì)量要求，它的核心就是把發(fā)布（到客戶的生產(chǎn)環(huán)境）也納入到短時(shí)間的迭代中。
成都Revenue Cloud團(tuán)隊(duì)從2016年項(xiàng)目一開始就明確定義了這個(gè)方向，我們要一步步地實(shí)現(xiàn)真正的Continuous Delivery。負(fù)責(zé)Infrastructure 的德國(guó)同事們做了很多工作，搭建了支持持續(xù)交付的完整框架，包括持續(xù)集成，構(gòu)建管理，配置管理，發(fā)布管理，我們稱之為DWC(Dev With Confidence), 有興趣的同事可以咨詢我們組的Andy Ma和Vicky Chen 同學(xué)。
那么在這樣的開發(fā)模式下，我們要怎樣進(jìn)行質(zhì)量保證工作呢？以下是我個(gè)人的粗淺見解：
第一，團(tuán)隊(duì)的目標(biāo)是交付。
隨時(shí)隨地，各種形式，各種方式，無所不用其極地強(qiáng)調(diào)我們的目標(biāo)是交付。 當(dāng)我們說某一個(gè)功能是不是完成，那一定是指這個(gè)功能是不是良好運(yùn)行在產(chǎn)品環(huán)境（而不是本地或測(cè)試環(huán)境），并滿足定義好的質(zhì)量要求（功能，性能，安全性等等）。
第二，全員對(duì)質(zhì)量負(fù)責(zé)，質(zhì)量保證活動(dòng)是日常開發(fā)活動(dòng)的一部分。
當(dāng)產(chǎn)品只有長(zhǎng)周期，大版本的交付時(shí)，在日常工作中我們?nèi)菀讜?huì)把某些任務(wù)，特別是質(zhì)量保證任務(wù)放到后期進(jìn)行，質(zhì)量債務(wù)趁虛而入。而如果實(shí)現(xiàn)的增量要快速交付，我們就不得不把質(zhì)量保證任務(wù)融入到日常開發(fā)活動(dòng)中。開發(fā)人員, QE, 產(chǎn)品經(jīng)理以及團(tuán)隊(duì)的所有人都要進(jìn)行相應(yīng)的質(zhì)量保證活動(dòng)，讓缺陷無處遁形。
怎樣落實(shí)呢? 那就是定義我們的Quality Strategy 了， 保障每個(gè)角色(who)都清楚知道自己應(yīng)該在什么時(shí)候(when)，什么環(huán)境(where)下如何進(jìn)行(how)什么樣(what)的質(zhì)量保證活動(dòng)。建議團(tuán)隊(duì)可以有一張圖來指導(dǎo)大家。 這是Revenue Cloud 成都團(tuán)隊(duì)的質(zhì)量保證活動(dòng)的Overview Picture(出于安全考慮，landscape 被我打上馬賽克啦)。
而Quality Strategy 絕對(duì)不是一成不變的，需求在變化，產(chǎn)品在變化，團(tuán)隊(duì)在變化，質(zhì)量保證活動(dòng)也應(yīng)該隨之變化。每運(yùn)行一段時(shí)間，我們要收集反饋，無論是外部質(zhì)量的反饋（比如來自產(chǎn)品團(tuán)隊(duì)的反饋，客戶報(bào)告的缺陷或需求），還是內(nèi)部質(zhì)量的反饋，比如需求是否清晰，測(cè)試案例是否valuable, 代碼質(zhì)量是否足夠好，自動(dòng)化ROI(Return on Investment)是否可接受，等等。根據(jù)這些反饋，我們?cè)賮砀倪M(jìn)質(zhì)量策略。
第三，預(yù)防缺陷
測(cè)試是一種基于后驗(yàn)的質(zhì)量保證方法。另一個(gè)更為重要的先驗(yàn)方法，就是缺陷預(yù)防。也就是說在開發(fā)人員提交測(cè)試前預(yù)防缺陷的產(chǎn)生，包括:
在開發(fā)人員實(shí)現(xiàn)代碼前，盡量確保需求清晰，Accept Criteria 和自測(cè)點(diǎn)清晰。
在產(chǎn)品功能實(shí)現(xiàn)過程中，開發(fā)人員, 產(chǎn)品經(jīng)理, QE,UX ,UA密切溝通，確保需求，實(shí)現(xiàn)和測(cè)試點(diǎn)的正確性和全面性。大家都坐在一個(gè)辦公室里面，不管是Daily Meeting還是直接面對(duì)面, 溝通是很容易的，關(guān)鍵在于大家有沒這個(gè)意識(shí)和習(xí)慣。
在開發(fā)人員代碼提交（從自己的分支提交代碼到主線）前，除了通過所有的自動(dòng)化回歸測(cè)試，還需要按自測(cè)點(diǎn)來驗(yàn)證實(shí)現(xiàn)的新功能。在這點(diǎn)上，我們需要思考怎樣幫助里開發(fā)人員更好更有效的做自測(cè)。比如，自測(cè)點(diǎn)Scope是否合適？是不是有些重要場(chǎng)景沒覆蓋或者場(chǎng)景定義太多？開發(fā)人員是否需要培養(yǎng)測(cè)試思維或方法？Planning時(shí)候是否沒有預(yù)估自測(cè)時(shí)間？開發(fā)人員自測(cè)是否得到了產(chǎn)品經(jīng)理/QE及時(shí)和正確的反饋？
第四，實(shí)施策略性的自動(dòng)化測(cè)試
當(dāng)我們的發(fā)布周期很長(zhǎng)時(shí)，可能覺得自動(dòng)化測(cè)試可有可無，作用也不是那么明顯，但隨著發(fā)布周期越來越短，自動(dòng)化測(cè)試的重要性越來越明顯。在Revenue Cloud ,我們除了季度的大版本發(fā)布，還有更短周期的feature發(fā)布，以及每天的patch發(fā)布。可以說，自動(dòng)化測(cè)試是不可動(dòng)搖的根本。然而實(shí)現(xiàn)自動(dòng)化測(cè)試，必然有很多因素要考慮。誰來做？選什么工具？哪些測(cè)試被自動(dòng)化？各個(gè)層面的自動(dòng)化怎么組合？這個(gè)策略需要團(tuán)隊(duì)自己決定，嘗試和改進(jìn)，畢竟適合的才是最好的。但我認(rèn)為有幾點(diǎn)原則是共性的：
自動(dòng)化測(cè)試絕不是QE 一個(gè)人的事情。自動(dòng)化測(cè)試和功能實(shí)現(xiàn)一樣，應(yīng)該是整個(gè)團(tuán)隊(duì)的任務(wù)，和功能backlog一樣，包括QE和開發(fā)人員在內(nèi)的所有團(tuán)隊(duì)人員都可以領(lǐng)取自動(dòng)化測(cè)試的任務(wù) 。測(cè)試代碼也應(yīng)和功能代碼一樣對(duì)待，要進(jìn)行代碼審查,以及代碼維護(hù)。不要舍不得讓資深的人員參與自動(dòng)化測(cè)試，良好可靠的自動(dòng)化測(cè)試終會(huì)讓團(tuán)隊(duì)受益。
自動(dòng)化測(cè)試的有效性比完備性更重要。如果自動(dòng)化測(cè)試的“假失效”和“假通過”太高，對(duì)團(tuán)隊(duì)來說不僅沒有幫助，反而是一種干擾。要保證測(cè)試的有效性，除了保障測(cè)試腳本實(shí)現(xiàn)的質(zhì)量外，還有很重要的一點(diǎn)，不要放過自動(dòng)化測(cè)試的每一個(gè)fail， 要分析清楚fail的原因，是產(chǎn)品實(shí)現(xiàn)層面的缺陷就改實(shí)現(xiàn)，是測(cè)試腳本的問題就改腳本，是環(huán)境問題就優(yōu)化環(huán)境。如果以自動(dòng)化測(cè)試不穩(wěn)定為理由，不去深入分析，那它永遠(yuǎn)都不穩(wěn)定，自動(dòng)化測(cè)試結(jié)果也永遠(yuǎn)得不到信賴。
我們團(tuán)隊(duì)在剛開始做E2E(End-to-End)自動(dòng)化測(cè)試時(shí)，測(cè)試總是不夠穩(wěn)定，但經(jīng)過一段時(shí)間的結(jié)果監(jiān)控，我們逐步總結(jié)并優(yōu)化了遇到的一些常見問題 ：比如測(cè)試數(shù)據(jù)之間有依賴或沖突，identify UI 元素的ID不唯一，斷言不準(zhǔn)確，測(cè)試前置條件被其他自動(dòng)或手動(dòng)測(cè)試破壞，UI新的調(diào)整或?qū)崿F(xiàn)導(dǎo)致測(cè)試失效等等。經(jīng)過團(tuán)隊(duì)一段時(shí)間的努力，現(xiàn)在E2E測(cè)試的有效性大大提高了，團(tuán)隊(duì)所有成員都認(rèn)可自動(dòng)化測(cè)試的反饋。分析和優(yōu)化的過程可能是痛苦的，甚至讓你懷疑投入是否值得。但堅(jiān)持下來，當(dāng)自動(dòng)化測(cè)試有效性得到保證時(shí)候，你會(huì)感受到它帶給你的安全感。
多層面的自動(dòng)化測(cè)試要綜合考慮。自動(dòng)化測(cè)試是多個(gè)層面的，在Revenue Cloud ,以功能測(cè)試為例，測(cè)試可以分為Unit Test, Integration Test, Contract Test, E2E Test。如下圖所示：
我們既要避免某個(gè)層面測(cè)試薄弱，也要避免在多個(gè)層面進(jìn)行重復(fù)的自動(dòng)化測(cè)試。以成都團(tuán)隊(duì)為例，在開始的一兩個(gè)release， 我們對(duì)Service Unit Test 的要求是覆蓋率>80%, Service Integration Test 大致是覆蓋60%的API測(cè)試用例, 然后E2E GUI Test覆蓋核心業(yè)務(wù)場(chǎng)景, UI 的Integration Test并沒有引入。后來隨著項(xiàng)目的進(jìn)行，我們發(fā)現(xiàn)API Integration Test 投入產(chǎn)出比最高。它比Unit Test 更接近service 真實(shí)行為，它比E2E GUI Test反饋更早更快，也更易實(shí)現(xiàn)。我們逐漸調(diào)整了策略，減少了Unit Test 的比重, 加大了Integration Test 的覆蓋，目前我們API 的Integration Test 覆蓋了>80%的測(cè)試用例。
再后來，隨著產(chǎn)品功能的增加，我們發(fā)現(xiàn)E2E GUI 測(cè)試運(yùn)行越來越慢，于是我們又再次調(diào)整了策略，一是引入是OPA5的UI Integration Test，把原來E2E GUI測(cè)試中純UI 的邏輯完全挪到OPA5測(cè)試中,大大縮短了自動(dòng)化測(cè)試的運(yùn)行時(shí)間。二是減少了部分和Service Integration Test 的重復(fù)測(cè)試,使E2E GUI 測(cè)試更多的側(cè)重于端到端完整的業(yè)務(wù)場(chǎng)景，而不僅僅是某個(gè)具體功能。 通過這兩次調(diào)整，多層面的自動(dòng)化測(cè)試能更高效的分工合作，為產(chǎn)品質(zhì)量保駕護(hù)航。
以上三點(diǎn)是我認(rèn)為定義自動(dòng)化測(cè)試策略的重要原則。另外，我經(jīng)常被問到一個(gè)問題： 你們項(xiàng)目采用什么自動(dòng)化測(cè)試框架/工具呢? 在談到多層面自動(dòng)化測(cè)試的時(shí)候，我列出了Revenue Cloud 采用的自動(dòng)化測(cè)試工具。對(duì)于Unit Test, Contract Test, Integration test 這些和技術(shù)平臺(tái)/語言相關(guān)的測(cè)試，我們采用的測(cè)試工具并沒有什么” 驚喜” 。Junit，Spring Contract Cloud, OPA5, Rest-Assured 都是大家耳熟能詳?shù)臏y(cè)試框架，在SAP 類似技術(shù)背景的項(xiàng)目中廣泛應(yīng)用著。我重點(diǎn)介紹下可能大家比較陌生的Nightwatch + SauceLabs 的E2E 測(cè)試方案吧。
SauceLabs 是一個(gè)云測(cè)試服務(wù)平臺(tái)，在云上提供VMs運(yùn)行多個(gè)測(cè)試，并提供了視頻錄制，截圖和日志記錄功能，很好地解決了多個(gè)自動(dòng)化測(cè)試并行運(yùn)行的設(shè)備問題。并且它支持不同瀏覽器，不同屏幕分辨率，可以應(yīng)用到瀏覽器兼容性測(cè)試中。當(dāng)然，這個(gè)是商業(yè)服務(wù)，申請(qǐng)的VM 越多，價(jià)格越貴。
Nightwatch(守夜人)，這是一個(gè)使用Selenium 2 (webdriver)實(shí)現(xiàn)的開源E2E 測(cè)試框架，對(duì)Selenium API 做了些封裝，能更容易和簡(jiǎn)潔的實(shí)現(xiàn)測(cè)試腳本，但它不支持UI 操作錄制。其實(shí)本質(zhì)上，它和Selenium, Ranorex, Start 等工具沒什么實(shí)質(zhì)不同。就像江湖高手會(huì)根據(jù)自己的喜好、功夫的特點(diǎn)選擇武器，我們也可以根據(jù)團(tuán)隊(duì)的技術(shù)特點(diǎn)和偏好，當(dāng)然還有預(yù)算來選擇工具。然而工具只是工具，就像決定比武結(jié)果的決定因素并不是武器一樣，決定自動(dòng)化實(shí)施成功的關(guān)鍵因素，從來不是工具，而在于我們自己的功夫修為本身。
第五, QE的角色定位。Revenue Cloud 成都團(tuán)隊(duì)從2016年建立，也曾經(jīng)回歸缺陷 比比皆是，也曾經(jīng)有提交測(cè)試的功能連Smoke Test（冒煙測(cè)試）都跑不過。那段時(shí)間，QE其實(shí)很忙碌的，有各種測(cè)試要做，各種缺陷要回歸測(cè)試，而且產(chǎn)品發(fā)版前還緊張的不行。但到現(xiàn)在，團(tuán)隊(duì)越來越成熟，質(zhì)量意識(shí)越來越好，開發(fā)人員提交測(cè)試的backlog 一次通過率基本維持在80%左右。在整個(gè)項(xiàng)目交叉測(cè)試時(shí)候，其他組給我們提的缺陷越來越稀少，團(tuán)隊(duì)的交付越來越順暢，而我作為QE， 不再淹沒在基礎(chǔ)測(cè)試中，可以有更多的時(shí)間做更有價(jià)值的事情。我也在團(tuán)隊(duì)的需求和幫助下，學(xué)習(xí)了自動(dòng)化測(cè)試框架， 研究了SAP產(chǎn)品標(biāo)準(zhǔn)的Performance, Accessibility, GDPR 以及Fiori Guideline 等等，拓展了自身的技術(shù)領(lǐng)域。
因此，我最后特別想和大家分享的一點(diǎn)是QE 的角色定位。QE 不是充當(dāng)警察的角色，站在大家對(duì)立面挑刺。QE也不是最后的質(zhì)量安全防線，站在大家身后填坑救火。QE是和大家一起并肩戰(zhàn)斗的戰(zhàn)友。一方面，QE充當(dāng)著質(zhì)量教練，引導(dǎo)和幫助團(tuán)隊(duì)提升質(zhì)量，建立成熟的質(zhì)量文化。另一方面，和Agile團(tuán)隊(duì)的每一位成員一樣，QE也需要在團(tuán)隊(duì)中不斷學(xué)習(xí)和成長(zhǎng)，不僅僅是加強(qiáng)QE技能，還要加強(qiáng)對(duì)業(yè)務(wù)的理解，對(duì)用戶行為的認(rèn)知， 甚至對(duì)具體實(shí)現(xiàn)技術(shù)的認(rèn)識(shí)。
到此，相信大家對(duì)“SAP軟件質(zhì)量怎么保證工作的變遷”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
重慶分公司
重慶分公司
