Keywords: 提高準入標準、增加冒煙測試、增加各節點質量效率(進度)評估

BUG質量

規范BUG錄入標準

BUG 優質級別從測試評估維度出發

BUG 嚴重程度從開發評估維度出發

1.統一BUG標題格式：(為BUG分析做準備)

新需求BUG：【需求名(版本號)】(【性能/兼容/安全】)模塊-BUG詳情；

非新需求BUG：【系統測試】(【優化】)-BUG詳情。

備注：非新需求BUG為與當前版本無關的BUG，( )中的內容為選填。

標準BUG樣例：

內部圖，略

2.嚴重級別(H，M，L)(必填)

H：影響測試流程，0級用例的BUG；

M：一般功能性BUG；

L：不重要功能性BUG。

3.BUG是否優質級別(A，B，C)

A：級別高，能夠復述詳細步驟，寫出分析過程，并找到BUG產生原因；

B：一般的BUG，好的建議性BUG；

C：非測試人員也可發現的BUG和一般性建議的BUG。

4.優先級P(此項暫不在考核中)

P2：緊急；

P4：不緊急。

增加BUG分析

1.每個測試人員對 預發布/線上 的BUG分析原因，并打上【預發布】、【生產環境】的標簽。禁止出現的懸空BUG，如：

BUG標題中無【需求名】，無【系統測試】；

Label中無【預發布】，無【生產環境】。

2.每個測試人員提報 改了3次及以上的BUG，超過3天未改的BUG。需測試人員在功能上線后給出。

3.初步計劃1個月出一次BUG分析報告(報告格式后期給出)

Keywords

總BUG數，新功能BUG率，預發布BUG率，上線BUG率；

同比上月的增長率；

每周跟進進度，每天跟進重要的時間節點。

提測節點

按照開發周報的任務進度：標記提測

提測issues標準

1.需求背景或背景需求鏈接；

2.需求內容(文字描述或給出接口文檔)(必填)；

3.改動點(選填)；

4.測試點(必填)(同一個需求同一個人建議不要分步提測)。

提測issues打回標準

每個節點共5個，需記錄打回原因，作為提測質量的依據

1.單元測試階段

構建 ——節點1

單元測試 ——節點2

靜態代碼分析 ——節點3

2.API層冒煙測試 ——節點4

第一階段：功能點測試，開發自測0級測試不通過聯調未通過或測試環境問題導致整個需求無法測試；

第二階段：API 功能自助測試。

3.提測issues： ——節點5

測試內容未填寫或只有1句話；

接口提測issues，無接口文檔；

無測試點。

測試準備

1.功能性issues

用例分類等級

0級：阻塞測試流程的主要功能點；

1級：重要功能點；

2級：非重要功能點及常用異常點；

3級：非常用異常點。

產品提需求前或開發做需求前將需求文檔和技術方案同步給測試； 測試在提測前給出測試用例-0級用例必寫，1級2級3級可提測后測試前給出或給出需要開發自測的xmind測試點。

2.開發驅動的需求

開發給出內容及測試點；

測試在提測后給出xmind或測試用例。

測試排期

根據需求的優先級和提測時間，測試進行工期評估，并排期。

測試工期評估依據及優化(后期)

上線節點

給出測試報告(原來)

測試用例(原來)

BUG鏈接(測試環境)

關于每周周報BUG分類

BUG按緊急程度分為高、中、低，按BUG發現的等級分為了A、B、C

H：嚴重，必須立即修改| 后期需要更改

M：一般，本次版本需要解決

L：微小，可不在本次版本解決

A: 能明確給開發說明，指出修改意見的BUG

B: BUG產生原因清晰，能重現定位

C: 不能重現，描述不清晰，無法定位 和 頁面展示級別的BUG。

總結

以上是生活随笔為你收集整理的软件测试qa等级考核制度,QA质量规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。