用測試覆蓋率度量代碼質量真的靠譜?

發表于:2020-4-23 09:45  作者:陳曉鵬   來源:晨小菜

字體: | 上一篇 | 下一篇 |我要投稿 | 推薦標簽: 測試覆蓋率

  測試覆蓋率和代碼質量是少數兩個用于分析、跟蹤和度量IT項目有效性的度量標準。
  測試覆蓋率和代碼質量在某種程度上是相互關聯的,很少有其他指標是這樣的。例如,我們度量代碼質量的方法之一是通過查看相應的測試覆蓋率。然而問題隱藏在使用測試覆蓋率指標來度量代碼質量的有效性上。
  所以在這篇文章中,我們將帶著批判的眼光來看待這個實踐。我們將通過回顧關于使用測試覆蓋率度量代碼質量的普遍接受的觀點,以及您如何應用一個適合您的情況的解決方案來做到這一點。
  1.房間里的大象——測試覆蓋率
  讓我們首先解決這個問題——即測試覆蓋率。
  “多少測試覆蓋率是足夠的?”
  足夠的測試覆蓋率有助于提高您捕獲所有關鍵/高優先級bug的機會。這不僅僅是一個您祖母講的故事,實際上是一個非常可靠的標準來建立對您的IT系統的代碼質量的信心。
  然而,業內關于測試覆蓋率的主要分歧似乎集中在“多少是足夠的?”
  理論各不相同——從60%到80%甚至100%。每個支持者都有一個合理的理由來解釋為什么他們認為一定的測試覆蓋率是足夠的還是不夠的。
  似乎沒有人討論的一件事是:您根據什么來度量測試覆蓋率?
  不要誤解我——每個人都有一個傳統上被接受的度量測試覆蓋率的基礎——被測試軟件中的代碼行數。
  這是正確的方法嗎?這正是我們今天要回答的問題。
  2.根據代碼行度量測試覆蓋率
  這是怎么做到的呢?你只需要:
  (A)你正在測試的軟件的總代碼行數,以及
  (B)所有測試用例當前執行的代碼行數
  找到(B除以A)乘以100——這將是您的測試覆蓋率%。
  例如,
  如果系統組件中的代碼行總數為1000,并且所有現有測試用例中實際執行的行數為650,那么您的測試覆蓋率為:
  (650 / 1000) * 100 = 65%
  當以執行的代碼行數來度量時,通常被接受的“足夠的”測試覆蓋率是什么?對于關鍵系統,共識徘徊在80%或者更高(關鍵系統的定義可能因行業、地理位置、用戶基礎等而異)。
  重要的問題是:這個度量標準是否有效?
  嗯,這是一個難題。我搜索了互聯網論壇尋找答案,發現一般來說,人們認為80%就足夠了。然后,還有一個問題是,您是否使用了好的測試,而不是那些對覆蓋率沒有真正用處的測試。
  好的測試是什么樣的?
  這并不難回答。一個好的測試應該跟蹤需求的實現。正常路徑和異常路徑的用例都是很好的測試。
  那么,您如何確保您是用好的測試來提高測試覆蓋率呢?
  在回答這個問題之前,讓我們先看一個更重要的問題。
  3.您真正應該根據什么來衡量代碼質量呢?
  測試覆蓋率-當然。但是您如何真正度量測試覆蓋率呢?
  流行的答案:由測試用例執行的代碼行數。
  正確答案:嗯,這就是有趣的地方。
  通過執行的代碼行數來度量測試覆蓋率
  雖然傳統上開發人員、測試人員和項目經理都傾向于使用這種方法,但是我一直在質疑使用這種方法來度量覆蓋率的有效性。
  為什么?正如這個論壇帖子告訴你的,確保100%的代碼行覆蓋率并不能真正得到高質量的產品。
  那么是什么呢?
  我之前說過,
  良好的測試用例和
  足夠的測試覆蓋率
  為了實現這兩個目標,您需要以批判的眼光看待您的參考點。
  4.提高測試庫中良好測試用例的比例
  一個好的測試用例跟蹤一個需求(包括正常和異常路徑)到實現。為了確保您主要擁有良好的測試用例,您所要做的就是建立需求的可跟蹤性。
  我的團隊通過清晰地規劃測試場景來覆蓋發布、項目、迭代、sprint范圍內的所有需求,從而實現項目中的可跟蹤性。通過建立需求的可追溯性,我知道——在任何給定的時間點——需求的測試覆蓋率。
  在敏捷項目中,假定您只關注下一個即時版本的需求,如果您使用基本的跟蹤矩陣,那么通過需求實現100%的測試覆蓋率應該是相當簡單的。
  如果您只測試需求,那么您的測試庫中應該只有良好的測試用例。
  現在進入下一個挑戰——足夠的測試覆蓋率。
  好吧,我開始這一部分的時候并沒有告訴你正確的答案是由測試用例執行的代碼行數。
  “如果你確保測試用例100%覆蓋了你的需求,那么你就擁有了所有你需要的測試用例。”
  我為什么要那么做?
  因為我不相信這是衡量代碼質量的正確方法。如果你還在想“為什么?”在你的嘴唇上,所以我要試著回答這個問題。
  5.如何用測試覆蓋率來度量代碼質量?
  需求可跟蹤性為您提供了一種可靠的方法來構建良好的測試用例。讓我們擴展一下,思考一下為什么會這樣。
  如果您只編寫可以追溯到需求的測試用例,那么您就有效地消除了任何冗余的、不必要的測試用例。這樣可以提高團隊休息的效率。
  現在,如果你把它轉過來,你會得到這樣的結果:如果你確保100%的需求被測試用例覆蓋,那么你就有了所有你需要的測試用例。
  很有趣,對吧?
  那么,您如何確保您有100%準確的需求呢?如果一些需求是不正確的,或者遺漏了呢?
  就像他們說的,“一個建立在糟糕需求上的高質量產品,是一個低質量的產品。”
  然后重點轉移到確保您擁有高質量的用戶描述,這些描述涵蓋了所有功能性和非功能性需求。在internet上進行粗略的搜索將告訴您需要什么來確保充分有效地捕獲所有需求。
  6.測試覆蓋在測試驅動開發TDD的世界中
  讓我們考慮一下我是如何運行我的敏捷項目的(例如一周的sprint)。
  沖刺-第一天
  我的scrum團隊利用規劃會議來篩選待辦事項列表中最重要的x個故事。每一個故事都已經被詳細闡述,并為規劃會議(通過正在進行的backlog梳理會議)做好了準備。Scrum測試人員拿起新創建的sprint backlog,規劃出他們希望用測試用例覆蓋的所有測試場景。然后,這些場景被移交給已經在努力編寫代碼的開發人員。
  沖刺-第2天
  到目前為止,scrum開發人員已經在開發計劃和啟動方面取得了一些初步進展,并且有機會與BA和測試人員一起了解sprint的需求和測試場景。測試人員已經完成了對新的測試用例的腳本編寫,或者從一個用例存儲庫中復制現有的測試用例,以覆蓋所有的測試場景。他們還確定了正常和異常場景,并優先考慮這些場景。最后,他們將測試用例映射回源需求,建立可跟蹤性。至此,測試人員知道當前sprint的所有需求是否已經被測試用例覆蓋了。
  沖刺——最后一天
  Scrum開發人員使用了測試場景和詳細的測試用例來指導他們的編碼工作,并使用這些測試用例對代碼進行了單元測試。當他們部署到一個集成的測試環境進行端到端功能測試時,大多數容易發現的錯誤已經被發現了。Scrum測試人員也開始使用這些測試用例來執行端到端的測試,并幫助識別那些阻止故事在sprint中交付的高/關鍵bug。當我們進行演示和回顧時,通常所有重要的bug都會被修復,其他未解決的bug會被優先考慮,以便在必要時進行后續的解決(我們總是在發行版的最后用一個峰值清除大多數這些“其他”bug)。
  如您所見,當我們到達Sprint結束時,我的團隊有一個能保證充分覆蓋所有需求的測試,而且我們的測試符合標準發布(如:沒有嚴重缺陷,100%執行測試用例,測試通過了95%)。
  通過測試驅動的開發,這是可以實現的。如果你能夠在每個Sprint中演示一個有效的、幾乎沒有bug的產品,并在此基礎上清除這些bug,以修復剩下的不太合適的bug,那么我的經驗告訴我,現在是發布產品的好時機。
  7.那么,應該根據什么來衡量代碼質量呢?
  我的回答是:需求覆蓋率和執行的代碼行數。
  為什么?坦白地說,我相信確保100%的需求覆蓋率是足夠的。畢竟,有了敏捷,你應該一直只處理發布的高優先級需求,從而減少浪費——精力、時間和金錢。
  然而,人類并不是完美的。糟糕的需求可能會潛入您的范圍。好的需求可能會被遺漏。您可能直到項目后期才會發現這一點。我們不能保證100%的準確性。
  另一方面,我發現通過執行的代碼行來檢查測試覆蓋率有助于在表面上判斷代碼質量。例如,如果您的測試達到了100%的需求覆蓋率,并且通過了發布的所有退出標準,但是卻發現您的測試只覆蓋了65%的代碼,這是為什么呢?
  極端的例子——我同意。但這是可能的。它可能是低質量的需求和浪費的編碼工作的組合。
  遇到開發人員編寫了太多不必要的代碼行數的項目是很常見的。原因可能有很多,而且有些是合理的,但是我經常發現“過多的代碼”對于我的客戶的許多項目來說是一個問題。
  編碼工作偏離了需求,開發人員花費寶貴的資源編寫不必要的代碼行。
  那么,如果一個開發人員嚴格遵循約定的范圍,那么100%的代碼都將被測試覆蓋,這是真的嗎?不一定。這又一次歸結于對開發人員編寫有效代碼的指導不足。只編寫交付需求所需的代碼。即使這樣,也有可能出現100%覆蓋率無法實現或沒有必要的情況。
  因此,我們的目標不應該是實現100%的代碼覆蓋率——或者任何類似的具體數字。盡管當與100%的需求覆蓋率相結合時,您應該能夠發現代碼覆蓋率在缺省情況下徘徊在80-90之間。
  8.我們學到了什么?
  代碼質量是每個人的首要任務。在一個資源成本增加和交付預算緊縮的時代,度量和跟蹤代碼質量以更好地了解您的團隊的效率以及他們可以在哪里改進是很有必要的。
  您應該使用您所掌握的每一種工具來實現您的目標代碼質量指標。根據代碼的總行數跟蹤執行的代碼行數是一種選擇。但是這并不能幫助您確定足夠的測試覆蓋率,或者實際的代碼質量。
  您應該依靠互補的、有時更強大的方法來度量代碼質量和測試覆蓋率。您可以通過在您的測試中考慮需求覆蓋率來輕松地實現這一點,這可以直接導致更好的代碼質量——立即!

      本文內容不用于商業目的,如涉及知識產權問題,請權利人聯系博為峰小編(021-64471599-8017),我們將立即處理

【福利】填問卷送精選測試禮包+接口測試課程!為測試行業做點事!

評 論

論壇新帖

頂部 底部


建議使用IE 6.0以上瀏覽器,800×600以上分辨率,法律顧問:上海瀛東律師事務所 張楠律師
版權所有 上海博為峰軟件技術股份有限公司 Copyright©51testing.com 2003-2020, 滬ICP備05003035號
投訴及意見反饋:webmaster@51testing.com; 業務聯系:service@51testing.com 021-64471599-8017

滬公網安備 31010102002173號

51Testing官方微信

51Testing官方微博

掃一掃 測試知識全知道

日本av