定義、分級和管理 bugDefine, triage, and manage bugs

Azure Boards |Azure DevOps Server 2020 |Azure DevOps Server 2019 |TFS 2018-TFS 2013Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

您要如何追蹤和管理程式碼中的瑕疵?How do you track and manage defects in your code? 您要如何確保軟體問題和客戶意見反應及時解決,以支援高品質的軟體部署?How do you make sure software problems and customer feedback get addressed in a timely manner to support high-quality software deployments? 而且,您要如何在新功能上做出良好的進展?And, how do you do this while making good progress on new features?

您至少需要一種方法來捕捉您的軟體問題、設定其優先順序、指派這些問題,以及追蹤進度。At a minimum, you need a way to capture your software issues, prioritize them, assign them, and track progress. 此外,您也會想要以與敏捷式實務一致的方式來管理您的 bug。Moreover, you'll want to manage your bugs in ways that align with your Agile practices.

簡言之,您可以透過下列工作來管理 bug:In a nutshell, you manage bugs through the following tasks:

  • 使用 bug 工作專案類型來捕捉資訊Capture information using the bug work item type
  • 指派優先順序來將 bug 分類Triage bugs by assigning a priority
  • 更新整個 bug 生命週期的 bug 狀態Update bug status throughout the bug lifecycle
  • 監視 bug 指派和趨勢Monitor bug assignments and trends

每個小組都可以選擇如何在其待處理專案 和麵板上顯示 bugEach team can choose how bugs show up on their backlogs and boards.

注意

基本進程無法使用 Bug 工作專案類型。Bug work item types aren't available with the Basic process. 當您從 Azure DevOps Services 或 Azure DevOps Server 2019.1 或更新版本建立新的專案時,基本程式會將 bug 追蹤為問題,並可供使用。The Basic process tracks bugs as Issues and is available when you create a new project from Azure DevOps Services or Azure DevOps Server 2019.1 or later versions.

必要條件Prerequisites

  • 您必須連接到專案。You must connect to a project. 如果您還沒有專案,請 建立一個專案。If you don't have a project yet, create one.
  • 您必須將專案加入至專案,做為 參與者project Administrators 安全性群組的成員。You must be added to a project as a member of the Contributors or Project Administrators security group. 若要加入,請 將使用者加入至專案或小組To get added, Add users to a project or team.
  • 若要查看或修改工作專案,您必須 在此節點中使用 view 工作專案 ,並將 此節點許可權中的 [工作專案 ] 設定為 [ 允許]。To view or modify work items, you must have your View work items in this node and Edit work items in this node permissions set to Allow. 依預設, Contributors 群組具有此許可權集合。By default, the Contributors group has this permission set. 若要深入瞭解,請參閱 設定工作追蹤的許可權和存取權To learn more, see Set permissions and access for work tracking.
  • 若要加入新的標記以加入至工作專案,您必須具有 基本 存取權或更高版本,並將專案層級的 [ 建立新的標記定義 ] 許可權設定為 [ 允許]。To add new tags to add to work items, you must have Basic access or higher and have the project-level Create new tag definition permissions set to Allow. 依預設, Contributors 群組具有此許可權集合。By default, the Contributors group has this permission set. 即使已為專案關係 明確設定許可權,他們也不會有新增標記的許可權,因為它們是透過其存取層級禁止的。Even if the permission is explicitly set for a Stakeholder, they won't have permission to add new tags, as they are prohibited through their access level.
  • 您必須連接到專案。You must connect to a project. 如果您還沒有專案,請 建立一個專案。If you don't have a project yet, create one.
  • 您必須將專案加入至專案,做為 參與者project Administrators 安全性群組的成員。You must be added to a project as a member of the Contributors or Project Administrators security group. 若要加入,請 將使用者加入至專案或小組To get added, Add users to a project or team.
  • 若要查看或修改工作專案,您必須 在此節點中使用 view 工作專案 ,並將 此節點許可權中的 [工作專案 ] 設定為 [ 允許]。To view or modify work items, you must have your View work items in this node and Edit work items in this node permissions set to Allow. 依預設, Contributors 群組具有此許可權集合。By default, the Contributors group has this permission set. 若要深入瞭解,請參閱 設定工作追蹤的許可權和存取權To learn more, see Set permissions and access for work tracking.
  • 若要加入新的標記以加入至工作專案,您必須具有 基本 存取權或更高版本,並將專案層級的 [ 建立新的標記定義 ] 許可權設定為 [ 允許]。To add new tags to add to work items, you must have Basic access or higher and have the project-level Create new tag definition permissions set to Allow. 依預設, Contributors 群組具有此許可權集合。By default, the Contributors group has this permission set. 即使已為專案關係 明確設定許可權,他們也不會有新增標記的許可權,因為它們是透過其存取層級禁止的。Even if the permission is explicitly set for a Stakeholder, they won't have permission to add new tags, as they are prohibited through their access level.

定義和列出 bugDefine and list bugs

當 bug 和需求一起管理時,您可以透過產品待處理專案( backlog)看板面板來加入 bug。When bugs are managed along with requirements, you can add them through the product backlog or Kanban board. 當 bug 與工作一起管理時,您可以將它們加入至短期衝刺待處理專案( backlog)或工作面板When bugs are managed along with tasks, you can add them to a sprint backlog or taskboard.

或者,您可以從 web 入口網站、Visual Studio/Team Explorer、 工作專案範本或使用 測試控管來定義 bug。Or, you can define a bug from the web portal, Visual Studio/Team Explorer, a work item template, or using test tools. 您可以使用 bug 工作專案表單來捕捉標題中的程式碼缺失、重現的步驟,以及其他欄位。Using the bug work item form, you capture the code defect in the Title, Steps to Reproduce, and other fields.

您可以藉由建立查詢並指定 工作專案類型 = bug,來查看為專案定義的 bug。You can review bugs defined for your project by creating a query and specifying the Work Item Type=Bug. 或者,您也可以開啟預先定義的查詢、 有效的 bug (AGILE 和 CMMI) 或 進行中 (Scrum) 。Or, open a predefined query, Active Bugs (Agile and CMMI) or Work in Progress (Scrum). 如需其他 bug 相關工作,請參閱下列文章:For other bug related tasks, see the following articles:

Bug 工作專案表單Bug work item form

Bug 工作專案表單會追蹤類似 Scrum 流程所顯示的資訊。The bug work item form tracks similar information to the one shown for the Scrum process.

注意

您在入口網站中看到的影像可能會與您在本文中看到的映射不同。The images you see from your web portal may differ from the images you see in this article. 這些差異是因為對您的 web 應用程式所做的更新、您或您的系統管理員已啟用的選項,以及建立您的 project — AgileBasicScrumCMMI時所選擇的流程。These differences result from updates made to your web app, options that you or your admin have enabled, and which process was chosen when creating your project—Agile, Basic, Scrum, or CMMI. Azure DevOps Server 2019 Update 1和更新版本有提供基本的流程。The Basic process is available with Azure DevOps Server 2019 Update 1 and later versions.

新的 web form 提供了舊版 web 表單未提供的許多體驗。The new web form provides a number of experiences not provided with the old web form. 若要深入瞭解,請參閱 新的工作專案體驗To learn more, see New work item experience.

Scrum bug 工作專案表單

提示

您可以使用 [討論] 區段 來新增和審核所執行之工作的相關批註,以解決 bug。Use the Discussion section to add and review comments made about the work being performed to resolve the bug.

新的 web 表單僅可從 TFS 2017 和更新版本使用。The new web form is only available from TFS 2017 and later versions.

Bug 特有的欄位Fields specific to bugs

定義 bug 時,請使用這些欄位來捕捉在分級、調查、修正和關閉 bug 時,所做的初始問題和進行中的探索。When defining a bug, use these fields to capture both the initial issue and ongoing discoveries made when triaging, investigating, fixing, and closing the bug.

欄位/索引標籤Field/tab

使用方式Usage

重現 (易記名稱 = 重現步驟 的步驟) Steps to Reproduce (friendly name=Repro Steps)

擷取足夠的資訊,讓其他小組成員了解問題的完整影響以及他們是否已修正 Bug。Capture enough information so that other team members can understand the full impact of the problem as well as whether they have fixed the bug. 這包括尋找或重現 Bug 和預期行為所採取的動作。This includes actions taken to find or reproduce the bug and expected behavior.

描述小組必須用來驗證程式碼缺失是否已修正的準則。Describe the criteria that the team should use to verify whether the code defect is fixed.

系統資訊System Info

與測試相關之軟體和系統組態的相關資訊。Information about the software and system configuration that is relevant to the test.

驗收準則 Acceptance Criteria

提供可在 bug 或使用者案例關閉之前符合的準則。Provide the criteria to be met before the bug or user story can be closed. 開始工作之前,請盡可能清楚地描述客戶驗收準則。Before work begins, describe the customer acceptance criteria as clearly as possible. 驗收準則可以用來做為接受度測試的基準,讓您能夠更有效地評估項目是否圓滿完成。The acceptance criteria can be used as the basis for acceptance tests so that you can more effectively evaluate whether an item has been satisfactorily completed.

發現的組建Found In Build

整合于組建中Integrated in Build

當 Test Manager 建立 bug 時,會自動填入 [ 系統資訊 ],並 在 [組建] 中找到 發生錯誤之軟體環境和組建的相關資訊。When Test Manager creates bugs, it automatically populates System Info and Found in Build with information about the software environment and build where the bug occurred. 若要深入瞭解如何定義軟體環境,請參閱 測試不同的設定。To learn more about defining the software environments, see Test different configurations.

當您解決 bug 時,請使用 [ 整合于組建 ] 來指出組建的名稱,該組建會併入修正 bug 的程式碼。When you resolve the bug, use Integrated in Build to indicate the name of the build that incorporates the code that fixes the bug.

若為內部部署 Azure DevOps,若要存取所有已執行組建的下拉式功能表,您可以更新 [ FIELD 組建] 和 [整合于組建] 中所找到的定義,以參考全域清單。For on-premises Azure DevOps, to access a drop-down menu of all builds that have been run, you can update the FIELD definitions for Found in Build and Integrated in Build to reference a global list. 全域清單會藉由每個已執行的組建自動進行更新。The global list is automatically updated with each build that is run. 若要深入瞭解,請參閱以 組建和測試整合欄位為基礎的查詢To learn more, see Query based on build and test integration fields.

如需如何定義組建名稱的詳細資訊,請參閱 組建編號格式選項For information about how to define build names, see build number format options.

優先順序 1 Priority 1

與商務或客戶需求相關的錯誤主觀評等。A subjective rating of the bug as it relates to the business or customer requirements. Priority 表示應修正程式碼瑕疵的順序。Priority indicates the order in which code defects should be fixed. 您可以指定下列值:You can specify the following values:

  • 1:若未成功解決工作專案,產品就無法出貨,而且應該儘快解決。 1: Product cannot ship without the successful resolution of the work item, and it should be addressed as soon as possible.
  • 2:產品無法在不成功解決工作專案的情況下送出,但不需要立即解決。 2: Product cannot ship without the successful resolution of the work item, but it does not need to be addressed immediately.
  • 3:根據資源、時間和風險,工作專案的解決方式是選擇性的。 3: Resolution of the work item is optional based on resources, time, and risk.
嚴重性 1 Severity 1 專案或軟體系統上 bug 影響的主觀評等。A subjective rating of the impact of a bug on the project or software system. 例如:如果按一下遠端連結 (罕見的事件) 會導致應用程式或網頁損毀 (嚴重的客戶體驗) ,您可能會指定嚴重性 = 2-高和優先順序 = 3。For example: If clicking a remote link (a rare event) causes an application or web page to crash (a severe customer experience), you might specify Severity = 2 - High and Priority = 3. 允許的值和建議的指導方針如下:Allowed values and suggested guidelines are:
  • 1-重大:必須修正。 1 - Critical: Must fix. 造成一或多個系統元件或整個系統終止,或造成大量資料損毀的瑕疵。A defect that causes termination of one or more system components or the complete system, or causes extensive data corruption. 而且沒有可接受的替代方法來達成所需的結果。And, there are no acceptable alternative methods to achieve required results.
  • 2-高:考慮修正。 2 - High: Consider fix. 造成一或多個系統元件或整個系統終止,或造成大量資料損毀的瑕疵。A defect that causes termination of one or more system components or the complete system, or causes extensive data corruption. 不過,有一個可接受的替代方法可達成所需的結果。However, an acceptable alternative method exists to achieve required results.
  • 3-中型: (預設) 造成系統產生不正確、不完整或不一致結果的瑕疵。 3 - Medium: (Default) A defect that causes the system to produce incorrect, incomplete or inconsistent results.
  • 4-低:具有可接受之因應措施的次要或表面瑕疵,以達成所需的結果。 4 - Low: A minor or cosmetic defect that has acceptable workarounds to achieve required results.

注意:Notes:

1 若要變更功能表選取專案或挑選清單,請參閱 自訂工作追蹤體驗1 To change the menu selection or picklist, see Customize the work tracking experience. 自訂方法取決於您的專案所使用的進程模型。The customization method depends on the process model used by your project.

如需 CMMI 流程特定欄位的詳細資訊,請參閱 bug、問題和風險欄位參考For information about fields specific to the CMMI process, see Bugs, issues, and risks field reference. 如需所有其他欄位的詳細資訊,請參閱 工作專案欄位索引For information about all other fields, see Work item field index.

在討論區段中捕捉批註Capture comments in the Discussion section

使用 [ 討論 ] 區段來新增和審核所執行之工作的相關批註。Use the Discussion section to add and review comments made about the work being performed.

工作專案表單中的討論區段Discussion section within a work item form

當您在每個可格式化的文字方塊內按一下游標時,rich text 編輯器工具列會顯示在文字輸入區域下方。The rich text editor tool bar displays below the text entry area when you click your cursor within each text box that can be formatted.

新的 Rich Text 編輯器工具列、討論區Discussion section, New Rich Text Editor toolbar

注意

沒有討論工作專案欄位。There is no Discussion work item field. 若要使用在討論區中輸入的批註來查詢工作專案,您可以篩選 歷程 [記錄 ] 欄位To query work items with comments entered in the Discussion area, you filter on the History field. 在 [討論] 文字方塊中輸入之文字的完整內容會加入至 [歷程記錄] 欄位。The full content of the text entered into the Discussion text box is added to the History field.

提及某人、群組、工作專案或提取要求 ( 提取要求識別碼圖示 )

選擇下列其中一個圖示 —  提取要求識別碼圖示, — 以開啟您所提出之最近專案的功能表、連結至工作專案,或連結至提取要求。 或者,您可以直接輸入 @#Or, you can simply type @, #, or ! 開啟相同的功能表。to open the same menu.

討論區、 @mention 下拉式功能表Discussion section, @mention drop-down menu

注意

此最新版本的 rich text 編輯器需要 Azure DevOps Server 2019 Update 1 或更新版本。This latest version of the rich text editor requires Azure DevOps Server 2019 Update 1 or later version.

輸入名稱,或輸入數位,功能表清單將會篩選以符合您的專案。Type a name, or enter a number and the menu list will filter to match your entry. 選擇您要新增的專案。Choose the entry you want to add. 您可以輸入 @ 和組名(例如小組或安全性群組),將群組帶入討論中。You can bring a group into the discussion by typing @ and the group name, such as a team or security group.

編輯或刪除批註Edit or delete a comment

如果您需要編輯或刪除任何討論批註,請選擇 [ 編輯 ] 或選擇 [ 動作] 圖示,然後選擇 [ 刪除]。

討論區段、編輯、刪除動作Discussion section, Edit, Delete actions

注意

編輯/刪除功能需要 Azure DevOps Server 2019 Update 1 或更新版本。The edit/delete feature requires Azure DevOps Server 2019 Update 1 or later version.

更新批註之後,請選擇 [ 更新]。After updating the comment, choose Update. 若要刪除批註,您必須確認是否要將它刪除。To delete the comment, you'll need to confirm that you want to delete it.

在工作專案表單的 [歷程 記錄 ] 索引標籤中,會保留所有已編輯和已刪除之批註的完整審核記錄。A full audit trail of all edited and deleted comments is maintained in the History tab on the work item form.

使用 @mention 控制項來通知另一個小組成員有關討論的內容。Use the @mention control to notify another team member about the discussion. 只要輸入 @ 和其名稱即可。Simply type @ and their name. 若要參考工作專案,請使用 #ID 控制項To reference a work item, use the #ID control. [類型] # 和您最近參考的工作專案清單隨即出現,您可以從中選取。Type # and a list of work items that you've recently referenced will appear from which you can select.

若要參考工作專案,請使用 #ID 控制項。To reference a work item, use the #ID control. [類型] # 和您最近參考的工作專案清單隨即出現,您可以從中選取。Type # and a list of work items that you've recently referenced will appear from which you can select.

請注意,一旦輸入批註後即無法編輯或刪除。Note that you can't edit or delete comments once they've been entered.

重要

若為內部部署 Azure DevOps Server, 您必須設定 SMTP 伺服器 ,小組成員才能接收通知。For on-premises Azure DevOps Server, you must configure an SMTP server in order for team members to receive notifications.

將回應新增至批註Add a reaction to a comment

您可以將一或多個反應新增至任何批註。You can add one or more reactions to any comment. 選擇任何批註右上角的笑臉圖示,或從任何現有反應旁的批註底部的圖示中選擇。Choose a smiley icon at the upper-right corner of any comment or choose from the icons at the bottom of a comment next to any existing reactions. 若要移除您的反應,請按一下批註底部的 [回應]。To remove your reaction, click the reaction on the bottom of your comment. 以下顯示加入回應的體驗範例,以及批註上的反應顯示。The following shows an example of the experience of adding a reaction, as well as the display of reactions on a comment.

將反應新增至批註Add reactions to a comment

使用測試控管來捕捉 bugCapture bugs using test tools

您可以使用下列其中一項工具,在測試會話期間建立 bug:You can create bugs during test sessions using one of the following tools:

將 Bug 分級Triage bugs

當您開始撰寫程式碼和測試之後,您會想要保留週期性分級會議,以檢查並排定 bug 的優先順序。Once you've started coding and testing, you'll want to hold periodic triage meetings to review and prioritize your bugs. 符合您的情況的頻率和時間長短。How frequently you meet and for how long depends on your situation. 一般情況下,專案擁有者會執行 bug 分級會議,而小組負責人、商務分析師和其他可以說出特定專案風險的專案關係人都可以參與。Typically, the project owner runs the bug triage meetings, and team leads, business analysts and other stakeholders who can speak about specific project risks attend them.

專案擁有者可以針對新的和重新開啟的 bug 建立或開啟共用查詢,以產生要分級的 bug 清單。The project owner can create or open a shared query for new and reopened bugs to generate a list of bugs to be triaged.

Bug 查詢Bug queries

開啟共用查詢,或 使用查詢編輯器 來建立有用的 bug 查詢,如下所示:Open a shared query or use the query editor to create useful bug queries, such as the following:

  • 依優先順序 (State <> Done 或) 的有效 bug State <> ClosedActive bugs by priority (State <> Done or State <> Closed)
  • 正在進行錯誤 (State = CommittedState = Active) In Progress bugs (State = Committed or State = Active)
  • 要針對目標版本修正的錯誤 (Tags Contains RTM) Bugs to fix for a target release (Tags Contains RTM)
  • 最近的 bug-過去3周內開啟的錯誤 (Created Date > @Today-21) Recent bugs - bugs opened within the last 3 weeks (Created Date > @Today-21)

當您對小組感興趣的查詢之後,就可以 建立狀態或趨勢圖 ,也可以將圖表新增至 儀表板Once you have the queries of interest to your team, you can create status or trend charts that you can also add the chart to a dashboard.

查詢結果中的分級模式Triage mode in query results

在 [查詢結果] 頁面上,您可以使用向上和向下箭號,在 bug 工作專案清單中快速向上和向下移動。From the query results page, you can quickly move up and down within the list of bug work items using the up and down arrows. 當您查看每個 bug 時,可以指派它、新增詳細資料或設定優先順序。As you review each bug, you can assign it, add details, or set priority.

若要深入瞭解,請參閱將 工作專案分類。To learn more, see Triage work items.

將 bug 指派給短期衝刺Assign bugs to a sprint

一旦將 bug 分類之後,就可以將它們指派給短期衝刺以進行修正。Once bugs have been triaged, it's time to assign them to a sprint to get fixed. 藉由解決一組 bug 以修正每個短期衝刺的問題,您的小組可以將 bug 總數維持合理的大小。By addressing a set of bugs to get fixed every sprint, your team can keep the total number of bugs to a reasonable size.

當產品待處理專案上出現 bug 時,您可以將 bug 指派給衝刺(sprint),方法與在短期衝刺計畫會話期間 (PBI) 和使用者案例相同When bugs appear on the product backlog, you can assign bugs to sprints in the same way you do a Product Backlog Item (PBI) and user story during your sprint planning sessions.

當 bug 被視為工作時,通常會自動連結到 PBI 或使用者案例。When bugs are treated as tasks, they're often automatically linked to a PBI or user story. 因此,將其父 PBI 或使用者案例指派給短期衝刺,會將連結的 bug 指派給短期衝刺計畫會話期間與 父 PBI 或使用者案例相同 的短期衝刺。So, assigning their parent PBI or user story to a sprint will assign the linked bugs to the same sprint as the parent PBI or user story during your sprint planning sessions.

您的小組應該考慮在測試開發中的功能時,修正在短期衝刺期間發現的所有錯誤。Your team should consider fixing all bugs found during a sprint when testing a feature in development.

修正、解決和關閉 bug (更新狀態) Fix, resolve and close bugs (update status)

牽涉到多個程式碼區段的 Bug 修正可能需要進行大量的迴歸測試,而且可能牽涉到其他小組成員。Bug fixes that involve more than a single section of code may require significant regression testing and may involve other team members. 記錄與評估 bug 工作專案歷程記錄中錯誤修正的風險相關的任何交談。Record any conversations that relate to assessing the risk of bug fixes in the bug work item history.

Bug 工作流程生命週期Bug workflow lifecycle

修正 bug 之後,您應該更新其工作流程狀態。Once you fix a bug, you should update its workflow State. 狀態選項會根據您使用 — ScrumAgileCMMI的程式而有所不同。State choices vary depending on the process you use—Scrum, Agile, or CMMI. 下列影像說明針對 Agile、Scrum 和 CMMI 流程的預設 bug 工作流程定義的工作流程生命週期。The following images illustrate the workflow lifecycle defined for the default bug workflow for the Agile, Scrum, and CMMI processes.

敏捷Agile ScrumScrum CMMICMMI
Bug 工作流程狀態,Agile 流程範本 Bug 工作流程狀態,Scrum 流程範本 Bug 工作流程狀態,CMMI 流程範本

注意

Agile 程式 bug 工作專案類型先前有一項規則,可將 bug 重新指派給建立它的人員。The Agile process bug work item type previously had a rule which reassigned the bug to the person who created it. 此規則已 從預設系統進程中移除This rule has been removed from the default system process. 您可以藉由新增規則來恢復這項自動化。You can reinstate this automation by adding a rule. 如需繼承程式,請參閱 將規則套用至工作流程狀態、根據狀態變更自動重新指派For an Inheritance process, see Apply rules to workflow states, Automate reassignment based on state change.

針對 Scrum bug,您只要將狀態從 [已認可] (變更為 [作用中) ] 即可完成。For Scrum bugs, you simply change the State from Committed (similar to Active) to Done. 若是 Agile 和 CMMI,您必須先解決錯誤,指出已修正 bug。For Agile and CMMI, you first resolve the bug, indicating that the bug has been fixed. 一般來說,建立 bug 的人員會確認修正,並將狀態從 [已解決] 更新為 [已關閉]。Typically, the person who created the bug then verifies the fix and updates the State from Resolved to Closed. 如果在 bug 解決或關閉之後找到更多的工作,可以將狀態設定為 [已認可] 或 [作用中] 來重新啟用。If more work has been found after a bug has been resolved or closed, it can be reactivated by setting the State to Committed or Active.

確認修正Verify a fix

若要驗證修正程式,開發人員或測試人員應該嘗試重現 bug,並尋找其他未預期的行為。To verify a fix, a developer or tester should attempt to reproduce the bug and look for additional unexpected behavior. 如有必要,他們應該重新開機 bug。If necessary, they should reactivate the bug.

確認 bug 解析時,您可能會發現 bug 未完全修正,或您可能不同意解決方法。When verifying a bug resolution, you may find that the bug was not completely fixed or you may disagree with the resolution. 在此情況下,請與解決問題的人員討論 bug,並進入合約,且可能會重新啟用 bug。In this case, discuss the bug with the person who resolved it, come to an agreement, and possibly reactivate the bug. 如果您重新開機 bug,請在 bug 描述中包含重新開機 bug 的原因。If you reactivate a bug, include the reasons for reactivating the bug in the bug description.

確認 bug,重新執行針對 web apps 定義的測試Verify a bug, re-run tests defined for web apps

選擇 [ 驗證 ] 選項來重新執行識別 bug 的測試。Choose the Verify option to re-run tests which identified the bug. 您可以從 Bug 工作項目表單操作功能表叫用 [驗證] 選項,以啟動 Web 執行器中的相關測試案例。You can invoke the Verify option from the bug work item form context menu to launch the relevant test case in the web runner. 請使用 Web 執行器執行驗證,並在 Web 執行器內直接更新 Bug 工作項目。Perform your validation using the web runner and update the bug work item directly within the web runner.

選擇 [ 驗證 ] 選項來重新執行識別 bug 的測試。Choose the Verify option to re-run tests which identified the bug. (需要 TFS 2017.1 或更新版本。 ) 您可以從 bug 工作專案表單操作功能表叫用 [ 驗證 ] 選項,以啟動 web 執行器中的相關測試案例。(Requires TFS 2017.1 or later version.) You can invoke the Verify option from the bug work item form context menu to launch the relevant test case in the web runner. 請使用 Web 執行器執行驗證,並在 Web 執行器內直接更新 Bug 工作項目。Perform your validation using the web runner and update the bug work item directly within the web runner.

Bug 工作專案表單、動作功能表、驗證選項

若要深入瞭解如何從入口網站執行測試,請參閱 針對 web 應用程式執行測試。To learn more about running test from the web portal, see Run tests for web apps.

關閉 bugClose a bug

當 bug 經過驗證為固定之後,您就會將其關閉。You close a bug once it's verified as fixed. 不過,您也可能會因為下列其中一個原因而關閉 bug:However, you may also close a bug for one of these reasons:

  • 延後延遲延遲至下一個產品版本Deferred - deferring a fix until the next product release
  • 已回報重複的 bug,您可以將每個 bug 與連結類型的重複/重複連結,然後關閉其中一個錯誤Duplicate - bug has already been reported, you can link each bug with the Duplicate/Duplicate of link type and close one of the bugs
  • 依設計-功能依設計運作As Designed - feature works as designed
  • 無法重現-測試證明無法重現 bugCannot Reproduce - tests prove that the bug can't be reproduced
  • 已淘汰-bug 的功能已不再存在於產品中Obsolete - the bug's feature is no longer in the product
  • 已複製到待處理專案-已開啟 PBI 或使用者案例來追蹤 bugCopied to Backlog - a PBI or user story has been opened to track the bug

提示

一旦 bug 已經關閉,而且在部署中主動發行修正程式,建議的作法是永遠不要因為回歸而重新開啟。Once a bug has been closed and the fix is actively released in deployments, recommended practice is to never reopen it due to regression. 相反地,您應該考慮開啟新的 bug,並連結至舊版、已關閉的 bug。Instead, you should consider opening a new bug and link to the older, closed bug.

在討論欄位中關閉 bug 的任何其他詳細資料,都是很好的想法 (新的 web 表單) 或 (舊的 web 表單) 的歷程記錄欄位,以避免未來 bug 關閉的混淆。It's always a good idea to describe any additional details for closing a bug in the Discussion field (new web form) or the History field (old web form) to avoid future confusion as to why the bug was closed.

您可以使用查詢來追蹤 bug 狀態、指派和趨勢,然後將其繪製至儀表板並將其加入至儀表板。You can track the bug status, assignments, and trends using queries which you can then chart and add to a dashboard.

例如,以下兩個範例會依優先順序趨勢來顯示作用中 bug,並依優先權排列 bug 的快照。For example, here are two examples showing active bugs by priority trend and a snapshot of bugs by priority.

來自查詢的 Bug 趨勢圖表 Bug 快照(依優先順序)

若要深入瞭解查詢、圖表和儀表板,請參閱 關於 managed 查詢圖表以及 儀表板To learn more about queries, charts, and dashboards; see About managed queries and Charts, and Dashboards.

自訂 bug 表單Customize the bug form

您可以加入欄位、變更工作流程、加入自訂規則,以及將自訂頁面加入至大部分工作專案類型的工作專案表單中。You can add fields, change the workflow, add custom rules, and add custom pages to the work item form of most work item types. 您也可以加入自訂工作專案類型。You can also add custom work item types. 如需詳細資訊,請參閱 自訂繼承流程For details, see Customize an inheritance process.

您可以加入欄位、變更工作流程、加入自訂規則,以及將自訂頁面加入至大部分工作專案類型的工作專案表單中。You can add fields, change the workflow, add custom rules, and add custom pages to the work item form of most work item types. 您也可以加入自訂工作專案類型。You can also add custom work item types. 如需詳細資訊,請參閱 自訂繼承程式 ,或根據您的專案所使用的進程模型 自訂內部部署 XML 進程模型For details, see Customize an inheritance process or Customize the On-premises XML process model depending on the process model used by your project.

您可以加入欄位、變更工作流程、加入自訂規則,以及將自訂頁面加入至大部分工作專案類型的工作專案表單中。You can add fields, change the workflow, add custom rules, and add custom pages to the work item form of most work item types. 您也可以加入自訂工作專案類型。You can also add custom work item types. 如需詳細資訊,請參閱 自訂內部部署 XML 進程模型For details, see Customize the On-premises XML process model.

接下來嘗試這個Try this next

若要追蹤您的錯誤並與其他可用的資源整合,請參閱下列主題:To track your bugs and integrate with other resources available to you, see these topics:

Marketplace 延伸模組Marketplace extensions

整合 & 測試資源Integrate & Test resources

流量分析服務來建立 bug 報告Use the Analytics service to create bug reports

您可以使用 Power BI 來建立比查詢所能取得更複雜的報表。You can use Power BI to create more complex reports than what you can get from a query. 若要深入瞭解,請參閱 使用 Power BI 資料連線器連接To learn more, see Connect with Power BI Data Connector.

預先定義的 SQL Server 錯誤報表Pre-defined SQL Server bug reports

如果您從內部部署 Azure DevOps Server 工作,且已針對您的專案設定 SQL Server Analysis Services 和 SQL Server Reporting Services,則可以存取下列報表 (僅) Agile 和 CMMI 流程。If you work from an on-premises Azure DevOps Server and you have SQL Server Analysis Services and SQL Server Reporting Services configured for your project, you have access to the following reports (Agile and CMMI processes only).

若要瞭解如何加入專案 SQL Server 報表,請參閱 將報表加入至專案To learn how to add SQL Server reports for a project, see Add reports to a project.

使用 SonarQube 協助管理技術債務Use SonarQube to help manage technical debt

SonarQube 可讓您自動測量一些技術債務。SonarQube provides a way of automatically measuring some technical debt. SonarQube 發現最佳編碼作法的重大違規。SonarQube finds important violations of best coding practices. 您可以執行聲納,以確保開發人員遵循重要的程式碼計量,例如適當的類別和方法大小或低圈複雜度, (透過程式的原始程式碼) 的線性獨立路徑數目量值。You implement Sonar to ensure that developers follow important code metrics like appropriate class and method size or low cyclomatic complexity (a quantitative measure of the number of linearly independent paths through a program's source code).

藉由整合您的內部部署 Azure DevOps 與 SonarQube 伺服器,您可以取得下列資料:By integrating your on-premises Azure DevOps with a SonarQube server, you can get the following data:

  • .NET 和 JavaScript 程式碼分析的結果Results of .NET and JavaScript code analysis
  • 程式碼複製分析Code clone analysis
  • 測試中的程式碼涵蓋範圍資料Code coverage data from tests
  • .NET 和 JavaScript 的計量Metrics for .NET and JavaScript

請參閱 技術債務管理:宣佈 SonarQube 與 MSBuild 和 Team Build 的整合 ,以取得詳細資料。See Technical Debt Management: Announcing SonarQube integration with MSBuild and Team Build for details.