以下內容均個人總結，請尊重原創，轉載請注明出處，謝謝

?一、概述

對測試期間的測試工作和測試數據做簡單復盤，目的在于從數據中找到項目管理過程中存在的問題，并對問題進行解決或對項目過程做優化。

先簡單介紹下站在測試角度的復盤過程。

1、復盤數據說明

As we knows,?測試應該盡早參與到項目中，應該從需求接收階段就開始介入，然后經過需求分析?→?測試分析?→?測試設計（用例）→?測試執行?→?項目上線?→?測試總結?這些階段后，測試可以積累到【 需求、用例、缺陷 】這3大塊數據，這3類數據就是測試用于復盤的重要數據。一般來說，我會對這3類數據做以下維度的復盤（需要注意的是，復盤并不是在最后一個階段“測試總結”才做的事情，在項目進程中，就應該階段性的使用這些數據進行小范圍復盤；其次，復盤也不是一定要做的，當你覺得缺少數據幫你發現問題、說明問題嚴重性、做決策的時候，就可以用下面的數據做分析、復盤）：

（1）【需求】

首先，從【需求】這類數據，我們可以知曉，項目整體共劃分了幾個迭代？每個迭代有多少需求？

我會有意識的統計和收集，每個迭代計劃要實現的需求是哪些？計劃要提測的需求是哪些（因為有些需求可能不需要提測）？達到提測時間后實際提測的需求是哪些？未提測的需求后續計劃是怎么樣的？以及該迭代測試完成后，實際測試通過的需求是哪些？沒有測試通過的需求后續計劃是怎么樣的？

	需求總數	計劃提測需求數	實際提測需求數	需求測試通過數	需求提測率	需求測試通過率
迭代1
迭代2
總計

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 表A

當一個迭代即將結束或項目要上線的時候，通過這個表格，我們可以了解項目任務的完成情況，這些具體的數據可以幫助我們清晰的梳理出每一項任務的測試情況，如果有需求未提測或測試不通過，需要進而進一步分析風險是什么，按目前提測的、測試通過的需求是否可以上線.....

（2）【用例】

這類數據，我更多的應用在測試過程把控，同時可以作為衡量研發提測質量和項目質量的指標之一

在測試執行過程中，每天測試結束后，我需要知道總體的測試進度是多少？是否有阻塞？如果沒有用例執行數據衡量的話，我們一般通過“感覺”去判斷，然后給出一個進度，但如果測試的體量比較大的話，精確的執行數據會幫助我們的更好把控測試進度和風險。

在每一輪的測試執行過程中，我會用以下表格（表B）管理我本輪的測試數據：

模塊	用例總數	有效用例總數	已執行	通過數	通過率	失敗數	阻塞數	進度（已執行/有效用例總數）	取消數	未執行數
模塊A
模塊B
總計

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 表B

每一輪測試結束后，我會用以下表格（表C）管理我每輪測試的數據，除此之外，最好保存每輪測試的測試用例源文件（下一輪測試不要直接在上一輪的測試文件里修改），因為每輪“取消”、“阻塞”備注的原因可能不一樣，最好保持源文件，以便我們在做最后的全局復盤的時候，可以根據需要找出當時的原因。

在這份表格里，我首要關注的是，每個迭代首輪的測試通過率，這個指標可以幫助我們衡量研發的開發質量，我覺得將研發開發質量劃分為以下4個等級，還是很合理的：

• ?A?優秀:??通過率?>=90 %? ??

• B?良好：?90% >?通過率?>=80%

• C?合格:???80% >?通過率?>=70%??

• D?差:??通過率?< 70%

研發的開發質量說明了項目質量，項目質量當然是越高越好啦

其次，公司一般會要求研發自測，并在提測的時候提供自測用例執行情況（自測用例可以由研發自己寫，也可以由測試提供）。
假設某功能，測試共設計了100條用例，其中20條標記為研發自測用例，研發承諾這20條用例都通過，才提測。則提測后，測試執行完這100條用例，統計下研發提測時承諾通過的20條用例，實際通過情況是怎么樣的，比如20條用例中，經過測試后發現實際通過的只有10條，則10除以20這個指標則可以幫助我們衡量研發的自測質量。

這個指標，可以叫做，研發自測用例實際通過率。一般而言研發自測用例實際通過率要≥95%，才算自測良好。

輪次/迭代	提測時間	有效執行用例總數	用例通過數	測試通過率	用例阻塞數	異常取消數
第X輪/XX迭代						本列指因需求變更等原因導致的取消

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?表C

表格B、C字段說明：

• “用例總數”是指測試人員設計的全部用例數，“有效用例總數”是指最終執行的用例數。在測試執行過程中，可能有些測試設計與需求不符，或者需求變更和刪除不需要測試了，或者需求在本輪未提測等原因，則把這類已經被設計好的用例標記為“cancel”（需要在備注中說明cancel原因），歸到“取消數”中。因需求不符、需求刪除、需求變更而被取消的需求數不應太多，太多則需要引起注意：是否測試、研發、產品之間的協作有問題？是否因溝通不及時導致在測試執行過程中過多用例被取消？

• 阻塞數是指在本輪測試時間內因其他缺陷阻塞無法測試的用例，需要備注說明阻塞原因

（3）【缺陷】

最后是關于【缺陷】，這個階段的數據最重要，不僅可以用于衡量研發提測質量，跟重要的是可以幫助我們發現流程、協作上的問題。項目前期埋的坑，在這個階段基本都會暴露出來。但這個數據需要研發、測試共同按規范去維護，不然可能會不準確。

基本的缺陷分析維度：缺陷總數、缺陷修復率、缺陷等級分布、缺陷重新打開的個數和次數、缺陷類型

分析維度	說明
缺陷總數和缺陷修復率	迭代/項目的缺陷總數是多少？已關閉多少？未關閉多少？缺陷修復率=已關閉/缺陷總數 嚴格的項目管理，需要規定要迭代或上線的準出條件，其中之一就是缺陷修復率要≥95%，如果有遺留問題需要評估遺留問題的風險，總之就是評估是否能帶著這些遺留問題進入下一個迭代或者上線，并且需要明確遺留缺陷的修復時間
缺陷等級分布和嚴重缺陷占比	統計致命、嚴重、中等、輕微、建議（一般都是這個5個等級）的缺陷數量，其中嚴重缺陷占比不能超過8%（超過則表示研發質量一般，且需要做進一步原因分析），同時也需要關注其他等級的缺陷修復，如果某一等級缺陷分布過多，需要具體進一步分析原因，比如輕微+建議的缺陷特別多，可能是研發沒有對這塊進行自測或產品提供的交互不合理等，那測試就要給相關角色提問題、提需求
缺陷重新打開的個數和次數	返工是一種浪費，倡導一次性將事情做正確。通過這一指標來度量開發人員一次性正確修復缺陷的能力（研發的缺陷修復效率）。 同時這個指標可以幫助衡量研發和測試的協作是否順暢、測試人員提的缺陷是否準確等問題 統計迭代內缺陷被重新打開的個數和次數，將每個迭代的數據做一個趨勢圖，通過看趨勢，幫助我們看團隊問題是否得到改善。
缺陷類型?	測試過程中發現的缺陷一般分為如下幾類： 功能問題：不滿足需求、功能實現錯誤；對產品或項目質量有影響的bug可統一劃入； 設計缺陷：頁面美觀性、交互友好性、錯別字等 用戶體驗：對產品、項目的建議性意見，不強制要求修改 性能問題：進行性能測試時使用，如：網絡延時、內存問題、CPU占用、硬盤問題 安全問題：業務功能存在的安全問題 接口問題:? 涉及有模塊間數據傳遞時使用 配置問題:? 由于提供的配置不當或者配置不能夠滿足實際要求而出現的問題 假設從缺陷等級分布統計中，發現“輕微+建議”的缺陷比較多，我們可以通過缺陷類型進一步分析，這兩個級別的缺陷類型是什么 如果大部分缺陷類型集中為功能性，可能揭示了團隊在其余質量指標的關注不足
缺陷解決方案分布	解決方案一般分為以下幾種： 已解決：研發按缺陷描述修復了缺陷 延期解決：延后處理 設計如此：無需改動 重復bug：已有記錄同樣的bug 外部原因：非本系統原因 無法重現：按復現步驟復現不了的bug 不予解決：因其他原因不予解決的bug 特別說明：其中“已解決”和“延期處理”的bug視為有效bug。如果無效bug數量過多，需要引起注意，具體進一步分析原因，是否測試對需求理解存在較多偏差？是否測試人員對缺陷的描述不夠準確？ 無效缺陷分析：軟件測試中的無效缺陷率分析 - 51Testing軟件測試網
缺陷模塊分布	這個模塊幫助我們看到每個模塊的缺陷情況，從模塊缺陷分布可以看出，哪個模塊的代碼質量最好
缺陷生命周期	缺陷從創建到關閉的時間統計，反映缺陷修復效率問題，特別是級別高的缺陷，是否被及時得到解決？
缺陷趨勢分析	缺陷趨勢可以是每日新增(new)、每日關閉(closed)、累計活躍的(all-active)，累計關閉(all-closed)、bug總數的，通過分析缺陷增長和減少的趨勢，分析來了解測試的效率和開發修復bug的效率、測試瓶頸、測試延期原因、測試生命周期等。 （1）其中每日新增(new)趨勢分析來了解測試的效率，正常看，提測準入通過的1-2天后每日新增應該在一個高峰值，總體呈下降趨勢，最后趨向于0。整個測試周期，80%＋的bug發現在測試周期中前期，測試后期甚至回歸測試的bug新增數趨于平穩到0，可以說明測試效率是比較高的，測試質量較高，且開發修復bug新引入bug的概率是比較小的 （2）每日關閉(closed)趨勢反映了開發對bug處理響應快，修復bug效率高，累計活躍的(all-active)bug得到收斂 （3）如果新建的bug越來越少，但關閉的bug曲線一直在打開bug下面，說明，瓶頸在研發那邊，他修改bug的效率過低 （4）bug總數曲線和累計關閉(all-closed)應該呈對數曲線，坡度應當逐漸變緩，最后無限接近并且重合 （5）如果累計活躍的(all-active)bug上升的坡度一直很陡，說明整個團隊中，bug的平均生命周期長，越平滑越好。 本指標分析摘抄自：淺談通過缺陷分析進行項目質量分析 - 簡書

??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?表D

總結

以上是生活随笔為你收集整理的软件测试复盘思路个人总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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