<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          敏捷項目中該如何度量測試績效?丨IDCF

          共 1743字,需瀏覽 4分鐘

           ·

          2022-06-24 14:02

          來源:晨小菜
          作者:陳曉鵬



          度量是將一個數(shù)字賦給一個對象或事件的特征,可以與其他對象或事件進行比較。度量是一種很好的手段來檢驗我們離目標到底有多遠。

          如果項目不進行度量,我們則不知道當時的狀態(tài)和目標相比到底是落后了還是超前了,是偏差了還是符合目標要求。

          因此我們常常把度量當作一種路標,來衡量團隊是否在偏離軌道還是朝著正確的軌道在前進。但是,在使用度量的時候,我們應該警惕以下兩點誤區(qū):

          度量個人績效而不是度量團隊目標

          如果把度量用在對個人的績效評價上面,將會是一件非常危險的事情。因為個人為了達到績效指標的要求,勢必會想方設法來滿足指標考核要求。

          比如如果我們對開發(fā)人員每天開發(fā)的代碼量(行數(shù))做考核的話,就很有可能使得開發(fā)人員為了達到指標要求而開發(fā)出大量的冗余代碼或者使得代碼邏輯不夠簡潔清晰,久而久之代碼的可維護性將會變得很差。

          這種沒有正確使用度量造成的后果不是我們希望看到的。一旦把度量應用在個人考核方面,則很有可能會出現(xiàn)各種各樣的副作用。

          因此我們應當把度量放在關注團隊的目標上面,比如我們關注自動化測試的通過率,是為了檢驗到底我們當前版本離我們希望達到的質(zhì)量目標有多遠,而不是為了證明開發(fā)人員寫的代碼有多差。

          另外需要記住的是,我們應當把度量當作一種正向的激勵手段而不是負面的懲罰別人的證據(jù),否則我們一定不會得到客觀的結(jié)果。

          只看單獨的指標而不是全局性的指標組合

          我們?nèi)绻粚蝹€指標進行割裂的分析是沒有任何意義的。比如說測試人員在測試過程中發(fā)現(xiàn)了很多缺陷,這說明什么?

          有可能說明測試人員的能力強;也可能說明不是測試人員厲害而是開發(fā)人員太差,寫的代碼出現(xiàn)很多問題;還有可能不是因為開發(fā)人員差而是因為此模塊本身就很復雜難度高,所以出現(xiàn)的缺陷當然比開發(fā)一個簡單功能的模塊多。

          因此如果你不是全局性對多個指標進行綜合性分析而只是看單獨的指標是很難知道真正的根源是什么。我們只有結(jié)合其他指標一起,通過全局性思維去分析,才能透過這些指標發(fā)現(xiàn)項目的真實情況,才有助于我們接下來采取正確的行動。

          那么與敏捷測試相關的度量指標有哪些呢?下面是部分參考的指標:

          • 代碼覆蓋率

          指由開發(fā)人員在單元測試過程中運行單元測試用例時所執(zhí)行的代碼量占該模塊總代碼量的百分比。目前有很多工具可以幫助自動化的統(tǒng)計這個度量值,比如Jacoco就是一個用于Java語言的代碼覆蓋率統(tǒng)計工具。

          另外需要注意一點的是,代碼覆蓋率指標并不要一味追求100%。包括Martin Fowler在內(nèi)的眾多專家都認為追求100%代碼覆蓋率是沒有意義的,因為它并不代表代碼質(zhì)量就真的那么高。

          代碼覆蓋率真正的意義是幫助發(fā)現(xiàn)你的代碼還有哪些部分沒有被測試,因此一般代碼覆蓋率達到80%以上就已經(jīng)很好了。

          • 驗收測試通過率

          指某版本(一個Sprint或Release)中通過驗收測試的用戶故事數(shù)占總用戶故事數(shù)的百分比。該指標主要是用來衡量當前版本的需求總體完成情況以及是否達到發(fā)布的條件。因為只有通過驗收測試的用戶故事才可以算“完成”,所以我們可以很容易統(tǒng)計出本次版本的需求完成情況、

          另外對于是否可發(fā)布,除了驗收測試通過率外我們還需要關注最小可發(fā)布特性集MRF(指在一個版本內(nèi)最少必須要實現(xiàn)的需求集,否則無法滿足本次版本目標)里的需求必須全部完成,并且這是必要條件而不是充分條件。

          • 每用戶故事點數(shù)缺陷率

          指某版本(一個Sprint或Release)中發(fā)布后發(fā)現(xiàn)的缺陷數(shù)(可以定義發(fā)布后一段時間內(nèi)發(fā)現(xiàn)的缺陷,比如兩周內(nèi))除以本次版本用戶故事點數(shù)的總數(shù)。

          這個指標主要是用來度量版本的總體質(zhì)量,以幫助我們進行分析版本質(zhì)量是否隨著迭代的增加而逐漸提升的趨勢。

          • 驗收自動化率

          指能夠通過自動化測試來驗收的用戶故事數(shù)占總用戶故事數(shù)的百分比。該指標主要是考核自動化實施的情況。

          我們應該鼓勵盡量把能進行自動化的驗收測試都要自動化,只有自動化的程度越高,我們進行回歸測試的效率也會越高。




          超級工程師實戰(zhàn)第六模塊【測試模塊】邀請到測試、敏捷及DevOps專家 陳曉鵬老師帶來3小時大時段課程分享,主題是《敏捷環(huán)境下的測試自動化實踐指南


          6月28日(周二)和6月29日(周三)晚上19:30-21:00,線上直播,掃碼立即報名,精彩內(nèi)容,不容錯過


          瀏覽 67
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  玖玖视屏| 久久夜色精品国产欧美乱极品 | 美女一级毛片 | 丁香五月天网站 | 成人在线免费观看黄片 |