結合敏捷專案管理,測試驅動模式,讓測試跑起來...
我給這套體系的定義就是 「保障質量的同時保證專案進度」 ,四個節點及時反饋及時溝通,有效的讓產品、研發和測試都動起來,避免任意一方的停滯。
質量的四層把控:
1、測試人員更早的介入需求
2、需求用例+
功能用例
3、每天乙個功能秀
4、嚴控用例執行規範
指標維度
核心指標
測試週期
要求指標
衡量標準
測試用例執行規範
測試用例執行率
第一版本
優先順序1
100%
(差):≤85%,沒有根據測試用例執行管理目錄進行管理,不能根據測試用例執行,導致測試不全面;缺少執行記錄。
第二版本
優先順序2
100%
(基本合格):85%《測試用例執行率<95%
第三版本/第四版本/第五版本
優先順序3/優先順序4/優先順序5
100%
(合格):≥95%,根據測試用例執行管理目錄進行管理。能夠根據測試用例執行測試,並及時記錄執行狀態。
測試用例覆蓋率
第一版本
用例覆蓋率50%
100%
(差):≤85%,沒有根據測試用例執行管理目錄進行管理。不能根據測試用例執行測試,缺少執行測試用例條數的執行記錄
第二版本
用例覆蓋率30%
100%
(基本合格):85%《測試用例覆蓋率<95%
第三版本,第四版本,第五版本
用例覆蓋率20%
100%
(合格):≥95%,根據測試用例執行管理目錄進行管理。能夠根據測試用例執行測試,並及時記錄執行測試用例條數
測試缺陷發現率(嚴重級別)
第一版本
嚴重級別缺陷率80%
100%
(差):≤85%,沒有根據測試用例執行管理目錄進行管理。不能根據測試用例執行測試,並及時記錄發現的缺陷
第二版本
100%
(基本合格):85%《測試缺陷發現率<95%
第三版本,第四版本,第五版本
嚴重級別缺陷率20%
100%
(合格):≥95%根據測試用例執行管理目錄進行管理。能夠根據測試用例執行測試,並及時記錄發現的缺陷
規範要求
測試負責人或指定人員需要進行每日測試情況發布
測試負責人需要每週進行周計畫跟蹤和調整
每個版本需要確認開發執行bat才能接受測試
非發布版本需要對fixed和reject問題進行確認,不允許此兩個狀態的缺陷遺留到下乙個版本。
發布版本不允許存在非close、delay、nobug缺陷存在
其他,需要根據測試管理過程、缺陷管理子過程、測試標準執行。
敏捷測試驅動模式 專案質量保障體系
結合敏捷專案管理,測試驅動模式,讓測試跑起來.我給這套體系的定義就是 保障質量的同時保證專案進度 四個節點及時反饋及時溝通,有效的讓產品 研發和測試都動起來,避免任意一方的停滯。質量的四層把控 1 測試人員更早的介入需求 2 需求用例 功能用例 3 每天乙個功能秀 4 嚴控用例執行規範 指標維度 核...
敏捷專案如何保證測試質量
關於敏捷專案,是迭代更新快,每個迭代都會有新的內容,或是業務需求,或是 優化,我們身為測試,要在每個迭代的測試中,保證每個迭代的測試質量。測試質量,包括這次迭代的改動不影響已有的功能,以及增加的功能,實現的效果符合預期。那麼,問題來了,測試如何保證測試質量?因為敏捷時間緊張,我們可以採用兩個方式混合...
從瀑布到敏捷(六)逐步完善專案級的質量保障體系
前面談到了專案級質量保障體系的基本架構建設情況,這裡再深入的說說專案級質量保障體系的測試用例體系建設過程。我們開發的是大型嵌入式軟體,從軟體測試角度來說,在專案級一般應該包含單元測試 整合測試和系統測試三部分。但是實際上根據各個軟體專案組的不同情況,各個專案組的專案級質量保障體系在實際建設過程中不完...