“精準測試”在商家地址專項的探索
在商家地址專項測試中結合現有精準測試平臺,以STAR模式介紹精準測試探索與實踐。
1、背景
隨著公司業務的不斷迭代發展,業務架構越來越復雜,測試亟需優化以下幾個方面:
(1)應用隨業務發展在不斷擴展,各個應用代碼復雜度會不斷增加,如何準確、全面判定代碼修改影響范圍會越來越重要;
(2)測試過程中會發現只是自身應用代碼一個修改,會導致對外暴露的接口邏輯發生很大變動,此時測試人員需要判定出這個對外暴露的接口對上層應用到底有多大影響;
(3)業務快速迭代導致測試時間不斷壓縮,全量回歸是一個很困難的事情,那么測試范圍需要開發測試人員根據代碼和業務熟悉程度精確把控,風險不可控。
基于上述背景,QA可以將精準測試作為應用上線質量的參考維度之一,有效輔助日常迭代測試工作,提高測試效率。?
2、任務
2.1 認清精準測試
精準測試是基于源代碼變更分析,結合一些分析算法,從而確定改動代碼影響的范圍,設計測試用例進行針對性測試,一方面可以提升測試效率,另一方面精準測試還可以將測試用例與程序代碼之間的邏輯映射關系建立起來, 而這個過程則是通過工具去采集測試過程執行的代碼邏輯及測試數據。這兩個點也正是精準測試的核心:正向追溯和逆向追溯。
所以,要想做好精準測試,核心目標可以總結為以下兩點:
(1)質量的評估不再完全靠個人經驗和業務熟悉度,而是通過精準的數據。在測試資源有限的前提下,將用例精簡到更加有針對性,提高測試效率,有效的減少漏測風險。
(2)代碼覆蓋率的可衡量性,提升測試質量,同時幫助開發定位缺陷對應的代碼執行邏輯,提升缺陷修復效率。
2.2 了解正向追溯
所謂正向溯源,就是解決開發處理bug的盲目性、QA測試覆蓋率的可衡量性。通過精準測試可以分析出哪些代碼被覆蓋到,哪些代碼沒有被覆蓋,從而統計測試覆蓋率,通過代碼覆蓋率,找出漏測的地方,可以更精準的進行驗證,減少重復工作。精準測試的運用是從經驗型的主觀判斷向精準的數據可視化轉變,讓質量的把控減少了一些不確定性、不可控性。
在用例執行過程中,開發也可以看到QA執行用例的代碼細節。從而追溯到調用具體方法與實現類,可直接在代碼級定位測試執行的代碼缺陷邏輯,并提供最后運行的時序數據。也可以更快地定位缺陷對應的代碼執行邏輯,幫助開發人員快速修復缺陷,可追蹤難復現缺陷。
2.3 了解逆向追溯
所謂逆向追溯,就是解決QA要測什么的問題,實現了代碼變更的影響面評估,分析識別增量與變更代碼。QA通過精準測試對影響的代碼做準確的針對性測試,回歸的范圍更準確,避免了全量回歸造成測試資源的浪費,既保證了質量又縮短了版本的迭代周期。
在日常的迭代回歸測試中極大減少回歸測試的盲目性和工作量,釋放人力成本,將更多的時間和成本投入到更深更復雜的測試工作中,減少資源浪費。
3、行動
基于精準測試的兩大核心目標,QA可以通過正向溯源和逆向追溯進行精準測試探索。下面就借助精準測試平臺以商家地址專項這個項目進行精準測試實踐。
3.1 了解精準平臺架構
3.2 精準平臺接入計劃
迭代 | 需求 | 涉及服務 | 接口數量 |
512-513迭代 | 商家地址專項-地址監控 | 商家核心服務、商家下單鏈路服務、商家拆分服務 | 22 |
514迭代 | 商家地址專項-接口新增 | 商家拆分服務 | 2 |
3.3 開發梳理改動接口清單
從開發梳理的改動清單中,可以看到,本次商家地址涉及的改動的接口包含三個服務:商家下單鏈路服務(4個)、商家核心服務(8個)、商家拆分服務(10),總的接口數量為22個。
單從開發的技術方案上梳理的涉及接口清單上看,QA無法判斷是否有接口遺漏或者錯誤,按照以往的測試策略,QA只能針對這22個接口進行相應的測試。
但是有了精準測試平臺之后,QA可以先針對這三個服務在提測分支和線上master進行對比,識別出有變動的接口數量,可以初步確認測試范圍。
3.4 精準平臺拉取接口清單
精準平臺地址:??https://ep.shizhuang-inc.com/precision/center/recommend??
(1)商家下單鏈路服務
從平臺拉取的結果來看,當前提測分支feature-address-513_monitor分支跟master分支對比,涉及到4個接口的改動,其中2個接口完成自動化,2個接口沒有相關自動化。
對比開發梳理的商家下單鏈路服務改動接口清單和平臺拉取的接口清單,可以看出商家下單鏈路服務改動接口以及數量是完全吻合的,這無疑給了QA莫大的信心。
(2)商家拆分服務
從平臺拉取的結果來看,當前提測分支feature-address-513_monitor分支跟master分支對比,涉及到8個接口,4個接口完成自動化,4個接口沒有相關自動化。
對比開發梳理的商家拆分服務改動接口清單和平臺拉取的接口清單,可以看出商家拆分服務改動接口以及數量也是完全吻合的,只是存在部分接口沒有自動化覆蓋,需要后期補充對應的接口自動化進行覆蓋。
(3)商家核心服務
從平臺拉取的結果來看,當前提測分支feature-address-513_monitor分支跟master分支對比,涉及到11個接口,且均沒有相關自動化。
對比開發梳理的商家核心服務改動接口清單和平臺拉取的接口清單,可以看出商家核心服務改動接口數量比開發梳理的接口多一個,并且有一個接口沒在開發的方案當中,說明該服務需要進行具體分析。
3.5 具體分析發現問題
(1)接口遺漏
通過精準平臺確認通過商家用戶id查詢退貨地址接口也存在對應的改動,開發少梳理了一個,并同步開發在清單中進行補充。
(2)代碼分支合并
商家核心服務識別出了一個非地址相關的改動,跟開發確認之后發現是因為當前提測分支沒有合并當前線上最新的master分支,導致跑出了非地址相關的功能數據。告知開發進行對應代碼合并之后,QA需要重新部署重新拉取接口再次確認。
(3)接口重載
商家核心服務有一個重載方法精準平臺沒有識別出這個根據商家id查詢商家地址的接口,跟開發進行確認,最終結論是根據商家id查詢商家地址的V2接口是重載了以下接口:平臺沒有看到重載的方法名,最終確認重載方法還是原來的方法名,只是在入參上作區分,一個只有商家ID,一個需要傳商家ID、訂單類型、商品ID。最終在精準平臺確認了對應的入參區別,平臺沒有作為兩個接口進行識別。
(4)內部調用方法也被識別
在使用精準平臺進行新增接口拉取的時候,發現平臺會將一些私有方法識別出來,這些方法是內部調用,沒有注冊,接口測試平臺也看不到對應的接口信息,無法覆蓋。
3.6 最終接口確認
(1)商家拆分服務
本次涉及8個改動接口,并補充缺少的4個接口的自動化之后,正常識別且狀態正常,說明此服務接口都正常覆蓋。
(2)商家核心服務
本次涉及10個接口改動,并補充缺少的接口自動化之后,對應接口都能正常識別且狀態正常,說明此服務接口都正常覆蓋。
(3)商家下單鏈路服務
本次涉及4個接口改動,并補充缺少的2個接口自動化之后,對應接口都能正常識別且狀態正常,說明此服務接口都正常覆蓋。
4、結果
4.1 各個服務觸發自動化結果
(1)商家拆分服務
(2)商家核心服務
(3)商家下單鏈路服務
5、探索心得
5.1 總結
(1)借助于精準測試平臺,發現一個開發梳理遺漏的接口,有效避免了梳理遺漏導致的測試遺漏,一定程度上規避了風險,是QA從經驗型的主觀判斷向精準的數據可視化轉變。
(2)借助精準平臺識別出一些沒有進行自動化覆蓋的接口,讓QA能針對這些清單進行接口自動化的查缺補漏,從另一層面提升了自動化用例集的完整性。
(3)精準平臺與自動化平臺、測試用例平臺、覆蓋率平臺打通,從正向追溯和逆向追溯兩個核心進行測試,確保數據的準確性、完整性,方便QA持續跟蹤,提高測試效率。
5.2 優化
在接入精準測試平臺的過程中,對平臺有了進一步的了解,當然在使用的過程中也發現一些問題,并給開發提了相關建議,從而不斷完善精準測試平臺開發,也幫助QA更好更高效得完成質量保障工作。