測試無定法,測試必有法:軟體測試策略運用之道
軟體測試實施中,綜合運用測試策略,就是根據專案的實際情況協調好手上有限的測試資源和要素,從專案整體上分析測試難點、破解測試痛點、控制測試風險,在恰當的測試階段運用恰當的測試方法和技術,面向目標,提綱挈領,讓測試任務相關的人、事、物等要素髮揮協同效應,力爭在有效時間內產生最佳的測試效率和測試交付。
1. 測試策略的重要性
任何一個測試專案都會受到範圍、時間、質量、成本等因素的制約,這裡的測試資源和要素簡言之就是人、事、物:
人不僅有測試人員,還有開發人員、專案管理人員、以及外包供應商、領導層等;
事就是可能的風險事項、需求變化、人員變更、各利益方角力以及突發事件等;
物最好理解,就是測試時間、測試進度、測試範圍、測試環境等實際資源。
測試策略就在不同的階段把人、事、物等要素綜合考慮和運用,使各方資源發揮合力,讓有限的資源產生最好的組合效能。在軟體測試時選擇合適的測試策略和方法組合,才能有效地提升測試效率和質量。尤其是在當今網際網路軟體時代,軟體更新迭代週期短,對軟體測試的質量需求和效率要求提出了新挑戰,就更需要有合理的測試策略的綜合應用。
測試策略的綜合運用,概括起來就是先找專案的測試難點、痛點、風險點,然後 更精準地確定範圍,更細緻地準備業務知識,更合理地安排測試資源和進度,更有效地調動測試人員的積極性,最後 集中優勢兵力攻難點、破痛點、控風險,更早更及時地找出系統問題。同時持續開展業務學習和技術交流,提升團體戰鬥力,動態跟進專案風險點,並針對性地動態調整測試策略,最終高效地保證測試交付質量。下面以筆者所經歷過的兩個金融測試專案例項來探討測試策略的綜合應用,希望能夠管中窺豹,投石探路,引發讀者的討論和思考。
2.1 某大型商業銀行核心系統UAT測試 專案背景 : 為適應網際網路化的發展,強呼叫戶體驗,強化全行業務統一管理、資料統一管理、全行一本賬, 某銀行對使用了十多年的大集中系統進行全新的設計和替換, 某銀行總行IT中心特地成立測試中心,用以保障新核心系統的交付質量。 專案開發規模 : 開發人員600+ 專案測試規模 : 六家外包測試供應商+甲方自己的團隊,測試人員初期有150多人,高峰時有500多人。 專案實施難度 :
總行領導直接關注,每月要定期彙報,甲方測試中心領導高度重視,測試交付人員壓力空前巨大。
專案加班嚴重,測試人員非常疲憊。前期是996模式(早上9點上班,晚上9點下班,一週工作6天),後面測試人員增加後改成每週5個工作日中三天固定加班到晚上9點,週末週六固定一天加班。
專案組的管理人員都是從各省分行支行抽調的業務骨幹,他們在業務上沒問題的,但管理水平的確有限,對測試更是沒什麼積累,有點外行領導內行的感覺。
測試人員眾多,來自多個測試服務供應商,人員管理複雜,且測試人員能力參差不齊。
測試策略運用:面對這樣的大型專案,測試組織和執行猶如大兵團作戰,如果沒有合適的系列化的測試策略組合,很難有效發揮測試團隊的協同作戰能力,打贏測試的運動戰和殲滅戰,下面是我們當時所在管理團隊針對團隊現狀並結合測試策略的基本理論方法, 從業務維度、技術維度和管理維度去綜合制定測試策略組合:1) 群組內的配對測試策略。針對基於測試人員業務不熟練而調撥的業務人員測試技術不熟練的問題,測試分組上讓測試人員與業務人員搭配,讓業務與技術互補,配備業務正組長和技術副組長,讓他們各施所長,又相互影響,最終每個UAT測試都能變成技術和業務雙能測試人員。 策略分析:有效地規避業務人員測試技術不足,而測試人員業務儲備不夠的風險。
2) 基於人員能力層級的測試分工策略。針對測試人員業務能力參差不齊的問題, 專門設立需求分析組,承接所有的上游測試需求分析、案例框架和場景設計,集體評審後,發給中初級人員做案例補全、測試資料準備和測試執行。每一個測試周期對分析組人員與優秀的測試執行人員都業務考核,進行適當崗位輪動和優勝劣汰,持續最佳化業務分析組的能力。 策略分析:讓合適的人做合適的事,讓測試考核驅動人員層級流動。
3) 基於業務場景的測試策略。測試用例的設計全部源於真實的業務場景,全覆蓋對應業務曾經的生產事故,業務場景的下一層設計中對所有頁面功能點和頁面控制元件做檢驗, 功能點檢驗按照一正三反的比例設計。 策略分析:強調負面用例、異常用例的作用,關注程式對錯誤的處理覆蓋。
4) 基於高頻業務的快速回歸測試。每個版本上線前,除了對應維護的業務部分做全面的迴歸外,其他業務則選擇Top100的高頻業務做必要的快速回歸。 策略分析:讓測試緊貼生產實際,客戶生產關心的業務是測試最應該重點保護的。
5) 基於不同環境的三輪交叉驗證。由於是銀行業務,使用者廣,每個功能點的上線都是經過三輪交叉驗證測試,第一輪甲測試員在A環境做初測,透過後則第二輪乙測試員在B環境做複測,複測透過後丙測試員在C環境做迴歸測試。並且鼓勵不同的測試員不要侷限評審過的用例,要基於需求多做發散性的隨機測試。 策略分析:有效規避基於測試人員個人的思維定式而引發測試盲點和測試不充分的風險。
6) 基於自動化的冒煙測試。每個開發版本提交後,首先會透過自動化測試來驗證版本的配置及程式碼的可測性。如果冒煙透過率小於90%則直接打回,大於90%小於100%的根據缺陷情況來決定是否退回。持續更新冒煙測試的用例集(動態的)。 策略分析:有效利用自動化工具,用制度把關測試准入關,避免無效測試執行。
7) 基於測試結果的考核驅動策略。針對測試人員眾多、態度及能力良莠不齊的現象,每兩個月的上線週期結束後,對所有測試執行人員進行主客觀共十個維度的量化評分考核,獎勵前三分,通報後六名,清退後三名,也清退連續兩次在後六名的人員。這一策略有效發揮了鯰魚效應,提升了測試人員的積極性和交付能力。 策略分析:利用鯰魚效應,讓測試人員學會居安思危,壓力直接轉換為動力,有效調動測試人員的自驅力!
8) 基於測試需求工單的責任人策略。一個測試需求從測試到上線,測試透過的最後報告中有ABC三輪測試人員簽字、測試組長簽字、測試經理簽字,層層責任落實。 策略分析: 問責驅動,讓需求工單的測試質量關聯多級責任人。從人員業務管理出發,中間整合業務特點設計用例、選擇用例、選擇環境,融合測試考核和激勵策略, 測試策略始終圍繞人、業務兩個核心,促進人和業務的有機融合,最終提升測試效率和交付質量。
2.2 某大型證券公司PB系統專案測試 專案背景 : 為搶佔核心使用者,擴大營業規模,某券商根據重點客戶的需求,同時上線了幾套PB業務系統。 專案開發規模 : 開發人員50+ 專案測試規模 : 專職測試3人 專案實施難度 :
PB業務系統直接對接股票、期權、基金、債券、新三板等全市場全品種的核心業務,對測試人員的業務能力的廣度和嘗試都有非常高的要求。尤其是對風控這一塊需要測試人員有較高的業務理解度。
專案上線測試有顯著的測試交付高峰,公司配置的測試只有一個測試管理和兩個外包測試執行人員,人手非常緊張。
開發商也是面對多家券商,開發內部也有任務排期,也有許多分支版本。三個相關係統在三個月內將依次上線,版本控制、測試計劃安排都有較大挑戰。
開發人員多數是外包供應商,且是離岸開發,測試溝通角色多且難以實時討論。
業務部門基於客戶需求,對系統上線期望非常高。上線質量保障壓力巨大。
測試策略運用:
1) 基於穩定版本測試,節約每一粒糧食,嚴守測試准入關口。嚴格控制釋出的版本頻率和質量,累計三次冒煙測試不透過,約談開發供應商負責人。 策略分析:把關與問責,雙管齊下,有效規避開發版本質量太差或缺少內部測試的風險。
2) 基於業務場景的測試。由於測試人員緊張,且任務相對集中,專案組專門請相關業務模組的老師給測試人員做指導,理清業務流程、列舉業務場景,測試人員基於業務場景整理好測試用例,讓業務老師幫忙稽核把關,確保業務覆蓋率。 策略分析:讓測試人的技術和業務人的業務有機結合,形成1+1>2的測試合力。
3) 基於完整業務能力提升的測試執行。俗話說磨刀不誤砍柴功,測試經理並未因為人少任務多而盲目地投入測試執行。專案組針對測試人員業務積累有限的現狀,組織了9 次系列化的業務培訓和技術培訓,並調動同一測試供應商的其他另外三名測試人員加入培訓,作為測試預備隊。 策略分析:曾國藩當年的湘勇未訓練成軍時都敢違抗聖旨不發兵,也是這個道理,只有測試人員的業務積累到一定程度時,再做去做測試執行才有效果。沒有戰鬥力的拼殺只會徒耗資源、抹殺士氣。
4) 基於業務劃分的分批測試。基於業務系統中公共模組之外的業務模板的相對獨立性,測試組與開發組約定好相關交付計劃,按公共模組到高頻業務模組再到低頻業務模組。測試組分割包圍,逐步測試,最後做一輪整合測試和上線版本測試。 策略分析:合理切割,集中兵力應對重點業務,分批有序執行,這是兵力不足時的必選策略。
5) 基於業務波及分析的迴歸測試。由於測試人員較少,有限的資源和時間無法全量回歸,測試經理非常珍惜每一份測試人力的合理高效使用。對於迴歸測試,測試經理會先對每一個版本的程式碼做兩個層次的分析,一是黑盒分析,針對變動的功能點,找出與之相關的業務場景用例和功能點用例,無則立即補充。二是白盒分析,請開發人員協助,整理出程式碼變化後,相關有調動關係的函式、類或程式包,理清這些函式涉及的功能點和業務路徑,最後根據這兩層波及分析,精準確定需要回歸的用例範圍。 策略分析:調動周邊開發資源,定向波及分析,有效定位迴歸範圍。最大限度降低迴歸測試可能不充分的風險。
6) 基於交叉測試的快速執 行,強調執行效率和可見成果。測試溝通上每日站立晨會同步進度和問題,測試用例重點強調業務場景分析和團隊評審,測試缺陷跟蹤強調解決問題,開發交付版本進入執行週期時強調普通模組快速測試與重點模組交叉測試相結合,有問題的模組則集中轟炸。 策略分析:抓測試重點,緊跟重點模組和缺陷模組,狠搗缺陷窩,是每個測試人必學的策略。
7) 按必要場景有序測試和隨機發散性測試相結合,既要保證正常需求覆蓋率,也要保證異常處理的探索性測試。 策略分析:有序測試是保證覆蓋,隨機發散探索更依賴測試經驗積累,不僅能有效降低漏測風險,更有助於培養測試人員跳出限定邊界的測試思維習慣。
2.3 測試策略運用的經驗與教訓
我們在長期的測試管理實踐中,總結了一些測試策略運用的經驗和教訓,主要有以下幾點。
重視自動化測試但不依賴自動化測試,同時考慮自動化測試的投入產出比。
資源緊張時,更能凸顯業務積累的重要性、單兵能力提高的必要性,因此,業務培訓需要常抓不懈。能有效提升測試團隊的整體素質。
測試策略的最重要控制就是對測試資源的高效整合和最最佳化利用。整合和利用的資源中,人是決定性因素,如何調動(或拆借)測試資源,讓測試工程師樂意測,測到實處,測有所得,關鍵一點是要和組員平等相處,為組員的成長著想,從而進行有效的激勵。
凡事預則立,不預則廢。在測試策略的制定上需要有預見性的計劃,整盤考慮資源、範圍、時間、成本、相關干係人訴求等情況,預判困難預判風險。
工作氛圍的營造與控制是測試策略推進和有效執行的保證。首先,負面情緒傳導,止於測試經理。其次,戰略上要相信一定有解決辦法,策略上重視專案中時刻發生的風險問題,調動專案團隊的集體力量,並及時尋求公司幫助。
階段性測試執行後的溝通總結非常重要,測試反饋推動測試策略最佳化和微調。
3. 總結
本文介紹了測試策略的重要性,重點闡述了測試策略綜合運用的兩個金融專案實踐,最後總結了測試策略綜合運用的經驗與教訓。測試策略實施是測試管理實施的重要組成部分,測試策略管理也是 技術和藝術的綜合運用。 測試策略是測試實施的“綱”和“領”,測試策略綜合應用沒有定法,依專案而定,比較靈活。針對不同的團隊,同一專案階段也可能需要採取不同的測試策略。同樣,測試策略的運用不僅是技術的發揮,也是藝術的展現。 “測”無定法,“測”必有法,作為測試工程師和測試管理者,最佳化測試實踐、精進測試管理,任重道遠,我們需要不斷探索測試策略的新模式新方法,為專案保駕護航。
文章來源:軟體質量報導
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69940641/viewspace-2656483/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【軟體測試】(三)黑盒測試綜合策略概述
- 影子測試:軟體測試的創新策略
- 軟體測試的策略
- 【軟體測試】質量保證與測試策略
- 【軟體測試】——介面測試
- 認識軟體測試步測試測試 (轉)
- 軟體測試-測試計劃
- 軟體驗收測試 第三方軟體測試 軟體功能測試 軟體資訊保安測試
- 《Google軟體測試之道》 第一章google軟體測試介紹Go
- 4大軟體測試策略的特點和區別(單元測試、整合測試、確認測試和系統測試)
- PR效能測試軟體適用於哪些測試
- 軟體測試:自動化測試
- 軟體測試技術-黑盒測試
- Web測試入門——軟體測試員必知的50個常見測試點Web
- 測試測試測試測試測試測試
- 軟體測試中的功能測試和非功能測試
- 軟體測試中功能測試的測試工作流程
- 軟體測試之功能測試、效能測試經驗談
- 軟體漸進性測試策略
- 軟體測試的策略和方法
- 軟體測試——三、軟體測試的分類
- 軟體相容性測試有什麼作用?相容性測試必備測試工具
- 軟體測試
- 軟體效能測試常見指標。在哪裡測試測試?指標
- 軟體測試員如何提取測試需求?
- 軟體測試經典測試題(4)
- 軟體穩定性測試的測試點
- 軟體測試計劃與測試方案
- 軟體測試之易用性測試
- 軟體測試文件寫作——測試方案
- 軟體測試戰略_測試那些事
- 軟體測試之測試分類_1.4
- 軟體測試培訓教程:軟體測試面試之怎麼測試刷抖音?面試
- 軟體測試中的測試計劃和測試用例起到什麼作用?
- 軟體測試教程之手機軟體測試方法
- 軟體測試學習教程—軟體測試質量
- 軟體測試學習 ——五種軟體測試模型模型
- 軟體測試筆試題筆試