資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝學
法學軟體測試中的測試覆蓋率
什麼是測試覆蓋率？
在軟體測試中，測試覆蓋率是指一個統計資料，它指示一組測試完成的測試量。它將包含獲取有關在執行測試套件時執行程式的哪些部分的資訊，以確定是否已採用條件語句分支。
這是一種確保測試正在測試程式碼或執行測試時使用了多少程式碼的方法。
程式碼覆蓋率和測試覆蓋率
程式碼覆蓋率和測試覆蓋率經常被混淆。即使基本概念相同，它們也不是一回事。
程式碼覆蓋率是指必須至少一次針對程式碼所有部分的單元測試過程，由開發人員執行。
另一方面，測試覆蓋率意味著至少測試每個需求一次，顯然是 QA 團隊的責任。
真正算作已覆蓋的需求由每個團隊的視角決定。
例如，有些團隊認為，如果某個需求至少有一個針對它的測試用例，則該需求已覆蓋。如果至少有一名團隊成員負責它，有時它也被認為是已覆蓋的。或者，如果與之相關的全部測試用例都已執行。
如果有 10 個需求和 100 個測試用例，如果這 100 個測試用例都針對這 10 個標準並且沒有遺漏任何一個，那麼在設計層面我們稱之為適當的測試覆蓋率。
當僅執行了 80 個準備好的測試用例，並且僅針對 6 個需求時。儘管已完成 80% 的測試，但我們聲稱有四個標準未滿足。這是執行級別的覆蓋率資料。
當只有 90 個與 8 個需求相關的測試用例有測試人員分配給它們，而其餘的沒有時，我們說測試分配覆蓋率為 80%。（10 個需求中的 8 個）。
瞭解何時計算覆蓋率也很重要。
如果你在流程的早期就這樣做，你會看到很多差距，因為專案仍然缺失。因此，通常建議等到最後構建，通常稱為最終迴歸構建。這確保了為給定需求執行的測試得到正確覆蓋。
測試覆蓋率的目的是什麼？
識別一組測試用例未覆蓋的需求區域
它有助於建立新的測試用例以提高覆蓋率。
開發測試覆蓋率的可量化指標作為質量控制的間接方法
識別無用的測試場景，這些場景不會提高覆蓋率
如何實現測試覆蓋率？
可以透過使用靜態審查技術（例如同行評審、檢查和演練）來實現測試覆蓋率。
透過將臨時缺陷轉換為可執行測試用例
可以透過使用自動程式碼覆蓋率或單元測試覆蓋率技術，在程式碼或單元測試級別完成測試覆蓋率。
藉助適當的測試管理技術，可以實現功能測試覆蓋率。
測試覆蓋率的優點
它可以確保測試的質量。
它可以幫助確定程式碼的哪些部分實際上是為釋出或修復而修改的。
它可以幫助識別應用程式中未經測試的路徑。
防止缺陷蔓延。
時間、範圍和成本都可以得到管理。
在專案生命週期的早期預防缺陷
它可以確定應用程式的所有決策點和路徑，從而可以提高測試覆蓋率。
可以輕鬆識別單元和程式碼級別需求、測試用例和問題中的差距。
應該如何實施良好的測試覆蓋率方法？
一切圍繞意識展開：
首先，QA 團隊必須瞭解專案的範圍和設計活動的現狀。如果以這種方式引入更多測試，他們將收到通知。您可以使用 RTM 來執行此操作，這是一種常見的做法。
其次，調查資源分配和測試執行過程，以確保一切儘快得到測試。
如何確保一切都被測試過？
每個測試人員都應該瞭解需求以及測試過程。
優先考慮您的需求，並將您的精力集中在最需要的地方。
瞭解特定版本與以前版本的不同之處，以便更精確地識別重要需求，並專注於最大程度的積極覆蓋率
修改測試自動化
使用測試管理工具確保您始終保持最新狀態。
分配智慧工作——將您最優秀的人員集中在重要任務上，並允許新的測試人員從不同的角度探索更多內容。
為所有任務和其他活動保留清單
與您的開發/Scrum/BA 團隊進行更多互動，以便更好地瞭解應用程式的行為。
維護所有構建週期和修復的記錄。
瞭解特定版本與以前版本的不同之處，以便更精確地識別重要需求，並專注於最大程度的積極覆蓋率。
使用測試管理工具確保您始終保持最新狀態。
分配智慧工作——將您最優秀的人員集中在重要任務上，並允許新的測試人員從不同的角度探索更多內容。
為所有任務和其他活動保留清單
與您的開發/Scrum/BA 團隊進行更多互動，以便更好地瞭解應用程式的行為。
維護所有構建週期和修復的記錄。
高效測試的關鍵領域和技術
**資源混雜——**在團隊成員之間分配任務。這提高了參與度，同時防止資訊集中。
**相容性覆蓋率——**確保您在測試應用程式時瞭解幷包含各種瀏覽器和系統。
**所有權——**讓測試人員承擔責任，並賦予他們對正在處理的模組/任務的完全自主權（當然，要進行監控和協助）。這促進了責任感，並允許他們嘗試新的方法，而不是墨守成規。
**截止日期——**在測試過程開始之前瞭解釋出截止日期有助於高效規劃。
**溝通——**在釋出週期之間與開發和其他團隊保持聯絡，瞭解正在發生的事情。
**維護 RTM——**作為利益相關者或客戶的良好派生，允許確認釋出計劃。
測試覆蓋率計算公式
要確定測試覆蓋率，請按照以下方法：
**步驟 1——**您正在評估的程式質量中的總程式碼行數。
**步驟 2——**所有測試用例目前正在執行的總程式碼行數。
您現在必須將（X 除以 Y）乘以 100。此計算得出您的測試覆蓋率百分比。
例如：
如果系統元件中有 500 行程式碼，並且所有當前測試用例中運行了 50 行程式碼，則您的測試覆蓋率為：
10% = (50 / 500) * 100
產品覆蓋率 – 您檢查了產品的哪些部分？
是的，在根據產品衡量測試覆蓋率時，主要關注的主題是 - 您測試了產品的哪些部分，哪些部分尚未測試？
**示例 #1——**如果您正在測試“刀”，則無需擔心它是否能正確切碎蔬菜/水果。其他需要考慮的因素包括使用者舒適地使用它的能力。
**示例 #2——**如果您正在評估名為“記事本”的應用程式，則檢查相關功能是一個要求。其他注意事項包括：應用程式在同時使用其他應用程式時能夠正確響應，使用者嘗試執行異常操作時應用程式不會崩潰，使用者收到正確的警告/錯誤訊息，使用者能夠輕鬆理解和使用應用程式，以及在需要時提供幫助內容。除非您調查上述場景，否則您不能說應用程式的測試覆蓋率是全面的。
風險覆蓋率 – 您檢查了哪些風險？
全面測試覆蓋率的另一個組成部分是風險覆蓋率。除非您還測試了相關的風險，否則您不能將產品或應用程式標記為“已測試”。相關風險的覆蓋率是全面測試覆蓋率的關鍵組成部分。
**示例 #1——**如果在測試飛機時，測試人員告訴您他/她已經完全檢查了飛機的內部系統並且它執行正常，但是隻有飛機的飛行能力在測試期間未被覆蓋，您的反應會是什麼？畢竟，這就是風險覆蓋率的含義。識別特定於應用程式/產品的風險並對其進行正確的測試始終是一種明智的方法。
**示例 #2——**在測試電子商務網站時，測試人員評估了每個有效功能，但沒有考慮大量消費者同時訪問網站的可能性，這在超級優惠日被證明是一個重大錯誤。
需求覆蓋率 – 您測試了哪些需求？
如果產品或應用程式開發良好，但不能滿足客戶的需求，那麼它就毫無用處。在測試過程中，產品覆蓋率與需求覆蓋率同樣重要。
示例 #1 − 你因為家庭聚會而興奮，所以你要求裁縫縫製你的衣服，並在領口處加上那些孔雀藍的裝飾紐扣。在縫製衣服的過程中，裁縫認為在領口處加上那些紐扣會不好看，所以他繡上了金色的邊。當然，在試穿那天，不滿意的顧客因為裁縫沒有按照規格要求而對他大喊大叫。
示例 #2 − 在測試一個聊天應用程式時，測試人員處理了所有重要的點，例如多使用者群聊、兩個使用者獨立聊天、所有型別的表情符號可用、立即向用戶傳送更新等等，但是忘記檢視需求文件，文件中明確指出，當兩個使用者獨立聊天時，應該啟用視訊通話選項。客戶宣傳該聊天程式允許兩人獨立通話時進行呼叫。你可以想象一下，如果發生這種情況，這個聊天應用程式會發生什麼。
缺點
因為沒有工具可以自動化測試覆蓋率手冊中的大部分活動。因此，評估需求和開發測試用例需要大量時間。
測試覆蓋率允許你統計功能，然後將它們與許多測試進行比較。但是，判斷中總是有出錯的可能。
8K+ 閱讀量
