測試 - 禪道篇
before
回到頂部
一般的，產品的從需求開始到上線，要經歷很多個步驟：
在產品的整個開發測試周期內，都需要進行相應的開發流程、測試流程、缺陷管理、配置管理等等。
那最開始，我們使用word文檔來管理缺陷，后來慢慢的發展到管理整個項目，這個時候，用word就不方便了，所以，人們開發出了項目管理工具：
-
Quality Control（QC）：是Mercury Interactive 公司（軟件版權屬於惠普公司）推出的一個基於 Web（偽） 且支持測試管理的所有必要方面的應用程序。該軟件提供統一、可重復的流程，用於收集需求、計划和安排測試、分析結果並管理缺陷和問題。組織可使用該軟件在較大的應用程序生命周期中實現特定質量流程和過程的數字化。該軟件還支持在 IT 團隊間進行高水平溝通和協調。功能真的很強大（收費版），但是要花錢........
-
Bugzilla：Bugzilla 是一個開源的缺陷跟蹤系統（Bug-Tracking System），它可以管理軟件開發中缺陷的提交（new），修復（resolve），關閉（close）等整個生命周期，功能較少，專門用來管理缺陷。
-
Bugfree：除了管理缺陷，也可以管理用例，但不能管理需求.......
-
Mantis：缺陷管理平台Mantis，也做MantisBT，全稱Mantis Bug Tracker。Mantis是一個基於PHP技術的輕量級的開源缺陷跟蹤系統，以Web操作的形式提供項目管理及缺陷跟蹤服務。在功能上、實用性上足以滿足中小型項目的管理及跟蹤。更重要的是其開源，不需要負擔任何費用。
-
JIRA：JIRA是集項目計划、任務分配、需求管理、缺陷跟蹤於一體的軟件。它基於Java架構的管理系統，被廣泛應用於缺陷跟蹤、客戶服務、需求收集、流程審批、任務跟蹤、項目跟蹤和敏捷管理等工作領域。
JIRA創建的問題類型包括New Feature（新功能）、Bug（缺陷）、Task（任務）和Improvement（改進）四種，還可以自定義，所以它也是一個過程管理系統。同時融合了項目管理、任務管理和缺陷管理。JIRA功能強大，可配合着一些組件及工具一起使用，如： Confluence 用於 wiki 管理需求，JIRA管理任務、進度和 Bug 。
JIRA設計以項目為主線，產品、測試結合管理，通過issues控制管理。因此它的核心訴求還是圍繞issue展開的，以issue驅動管理、分工、以及團隊協作，進而實現項目的規划、建設，終完成產品開發。
-
禪道：禪道項目管理軟件（簡稱：禪道）集產品管理、項目管理、質量管理、文檔管理、組織管理和事務管理於一體，是一款功能完備的項目管理軟件，完美地覆蓋了項目管理的核心流程。
禪道的主要管理思想基於國際流行的敏捷項目管理方式—Scrum。Scrum是一種注重實效的敏捷項目管理方式，它規定了核心的管理框架 ，但具體的細節還需要團隊自行擴充。禪道在遵循其管理方式基礎上，又融入了國內研發現狀的很多需求，比如bug管理，測試用例管理，發布管理，文檔管理等。因此禪道不僅僅是一款scrum敏捷項目管理工具，更是一款完備的項目管理軟件。基於scrum，又不局限於scrum。
禪道最大的特色是創造性的將產品、項目、測試這三者的概念明確分開，互相配合，又互相制約。通過需求、任務、bug來進行交相互動，最終通過項目拿到合格的產品。
目前，禪道和JIRA用的人較多。我們這里以禪道為例。
禪道項目管理軟件是做什么的？
禪道由青島易軟天創網絡科技有限公司開發，國產開源項目管理軟件。它集產品管理、項目管理、質量管理、文檔管理、組織管理和事務管理於一體，是一款專業的研發項目管理軟件，完整覆蓋了研發項目管理的核心流程。禪道管理思想注重實效，功能完備豐富，操作簡潔高效，界面美觀大方，搜索功能強大，統計報表豐富多樣，軟件架構合理，擴展靈活，有完善的API可以調用。禪道，專注研發項目管理！
為什么用禪道這個名字？
禪和道這兩個字含義極其豐富，有宗教方面的含義，也有文化層面的含義。禪道項目管理軟件取其文化含義，期望通過這兩個字來傳達我們對管理的理解和思考。這個名字是受《編程之道》和《編程之禪》這兩本書的啟發。英文里面的禪為Zen，道為Tao，所以我們軟件的英文名字為zentao。
禪道的安裝
回到頂部
docker部署禪道
回到頂部
- 新建一個容器卷掛載目錄
[root@C /]# mkdir -p /docker_data/zento_data
- 拉取鏡像
[root@C ~]# docker pull idoop/zentao:12.0.1
- 啟動禪道
docker run -d -p 6003:80 -p 3308:3306 --restart=always -e ADMINER_USER="root" -e ADMINER_PASSWD="password" -e BIND_ADDRESS="false" -v /docker_data/zentao_data:/opt/zbox/ --add-host smtp.exmail.qq.com:163.177.90.125 --name zentao-server idoop/zentao:latest
- 現在就瀏覽器訪問
ip:6003端口即可，然后會讓你修改密碼，默認賬號和密碼：
賬號：admin
密碼：123456
for Windows
回到頂部
- 執行安裝，注意，無論哪個盤，都要安裝在根目錄下。
- 安裝完事了。在
C:\xampp目錄中雙擊start啟動它。
- (可能的提示)安裝
VC++運行環境。
如果VC++安裝失敗，參考：https://answers.microsoft.com/zh-hans/windows/forum/all/microsoft-visual-c-2015/0b2acae1-63fa-4e0b-b482-c9f8e138100e
- 啟動后，是這個頁面，點擊啟動按鈕即可。
- 提示修改密碼，你修改成較為簡單的即可。
- 按照提示瀏覽器訪問給出連接，提示讓你登錄，這是因為在啟動時沒有取消勾選
啟用Apache用戶訪問驗證選項，你可以取消勾選。
- 當你取消勾選
啟用Apache用戶訪問驗證選項后，瀏覽器訪問就可以了，這里你可以選擇開源版即可。
- 選擇開源版，用戶名默認是
admin，密碼默認是123456。
- 進入修改密碼界面。
- 問你是否進入新手教程，這里選擇取消。
- 完事就進入到了這樣的一個頁面。
- 禪道的項目流程介紹。
我們通過這個流程圖，使用禪道走一遍流程。
創建角色
回到頂部
我們知道當一個項目開始的時候，需要由產品經理創建產品和收集需求等操作，還需要其他的角色來完成不同的任務，所以，我們先來把各個角色創建完成。
為了不忘記密碼，下面列出相關角色和密碼，便於參考：
| 角色 | 密碼 | 備注 |
|---|---|---|
| admin | root!1234 | 管理員 |
| chanpinjingli1 | root!1234 | 產品經理1 |
| xiangmujingli1 | root!1234 | 項目經理1 |
| yanfazhuguan1 | root!1234 | 研發主管1 |
| chanpinzhuguan1 | root!1234 | 產品主管1 |
| ceshizhuguan1 | root!1234 | 測試主管1 |
| gaocengguanli1 | root!1234 | 高層管理1 |
| kaifa1 | root!1234 | 開發人員1 |
| kaifa2 | root!1234 | 開發人員2 |
| ceshi1 | root!1234 | 測試人員1 |
| ceshi2 | root!1234 | 測試人員2 |
為了方便，角色密碼以都為root!1234。
現在，使用admin賬號登錄系統。
添加角色
選擇組織下面的添加用戶，參照下圖設置個人信息。
然后按照這個套路你可以使用批量添加將其他的角色建立起來，錯了也可以修改。
完事，大概角色就這些，后續用到再添加即可。
產品管理
回到頂部
創建產品
回到頂部
現在使用產品經理登錄，並略過新手教程：
賬號:chanpinjingli1
密碼：root!1234
開始吧！
選擇產品視圖，選擇添加產品按鈕，填寫相應信息即可。
完事了。
這里需要注意的是：
- 產品負責人，可以選擇當前的產品人員，產品經理。
- 測試負責人，測試主管或者測試經理。
- 產品代號，內部的對於該產品的名稱。
- 訪問控制選項，有三種選擇：
- 默認選項，只有能看到
產品視圖的人，可以訪問。 - 私有的， 該產品項目下的人員才能看到。
- 設置白名單，白名單中組中的用戶可以訪問。
- 默認選項，只有能看到
此時，產品創建完畢，接下來應該干嘛？應該創建該產品的計划了。
創建產品計划
回到頂部
還是使用產品經理登錄，並略過新手教程：
賬號:chanpinjingli1
密碼：root!1234
開始吧！
產品下面的計划選擇創建計划。
填寫相應的信息即可。
創建計划的好處有：
- 可以幫助產品人員控制產品的研發過程。
- 幫助相關人員了解產品進度，便於后續的工作安排。
有了相應的計划了，接下來就可以建立相應的需求，並且可以將需求分解為多個模塊。
添加模塊和創建需求
回到頂部
還是使用產品經理登錄，並略過新手教程：
賬號:chanpinjingli1
密碼：root!1234
開始吧！
產品選項點擊代碼統計產品，然后點擊模塊按鈕，就可以填寫相應的模塊信息。
當你點擊保存后，會在左側菜單欄顯式剛剛創建的模塊。
將產品需求分為各個模塊，方便我們對產品有個宏觀認識，掌握產品的構成，任務細化后也便於跟進進度和隨時調整。
有了模塊，就可以在該模塊下提需求，然后對提的需求進行評審后，就可以進入實現開發階段了。
來，創建需求吧！
選擇產品,然后在產品列表中選擇相應的產品(我們這里就一個)，完事點擊需求，再點擊提需求。
編輯各個選項即可，這里需要注意的是，提的需求是需要評審的，所以需求評審選項你應該取消勾選，然后你要指定有誰評審，也就是這個需求保存后，需要你指定的人去評審這個需求；抄送選項則是說提的需求應該被誰看到，或者"告訴"誰，可以多選；至於優先級選項則是數字越小優先級越高；關鍵字,后續搜索用；你也可以為這個需求上傳附件和附件的標題信息。
當你點擊保存后，就會看到，該需求如下圖所示的樣子，這是因為該需求剛剛提出，但還沒經過評審，所以是草稿狀態，此時該需求還不能進入到研發階段；當然，需求的評審應該是一個線下的過程，禪道這里只是記錄一下評審過程。
那接下，就是需要對需求進行評審了吧！
需求評審
回到頂部
先來看需求的評審流程，如下圖。
知道了需求評審的流程，並且當時這個需求指派給產品主管去評審，所以我們現在以產品主管的身份登錄：
賬號:chanpinzhuguan1
密碼：root!1234
PS：由於需求的評審相關是多人參加，你應該注意每個截圖中的登錄者的身份。
在產品的需求選項，選擇指派給我選項，會發現有一條來自產品經理創建的需求，需要評審，點擊操作列的眼睛也就是評審按鈕。
新的評審頁面如下：
在這個頁面中，需要注意的有個評審結果選項，有三個：
- 確認通過，需求沒有問題，通過。
- 有待明確，這個需求有些問題，你可以在備注欄中填寫需求的問題。
- 拒絕，這個需求有大問題，或者這需求不對，這個需求不用實現，所以該需求被拒絕。
我們這里選擇有待明確，打回去這個需求。
可以看到歷史記錄中，發現產品主管已經評審完畢，並且把評審結果展示了，這個時候，應該由產品經理(提需求的人)去完善該需求：
此時產品經理登錄禪道后，會發現自己提交的需求被打回來了，那么點擊需求描述也能發現產品主管的評審結果，所以，此時，產品經理需要再次編輯完善該需求。
產品經理已經完善了該需求，並且重新保存，那么該需求將重新提交給產品主管，此時產品主管登錄，就可以發現完善的內容。
那么，此時點擊評審按鈕再次評審，這里我們選擇拒絕選項看看發生什么情況？新增了一個下拉框，讓你選擇拒絕原因。
我們隨便選擇一項，如涉及如此，此時無論是產品經理還是產品主管登錄，都會發現此時該需求處於已關閉狀態。
那么，如果產品主管在評審時，選擇了確認通過，那么此時的需求狀態就是激活的，如下圖，一個新的需求的評審結果。
注意，只有進入到激活狀態的需求才能進行后續的開發。
需求評審是一個線下過程，有多人決定，評審完畢在禪道中記錄即可。
需求變更
回到頂部
一般的，項目中的需求變更流程如下圖所示：
除了需求的評審，還會經常遇到需求的變更，來看看禪道中的需求變更流程。
# 產品經理
賬號:chanpinjingli1
密碼:root!1234
# 產品主管
賬號:chanpinzhuguan1
密碼:root!1234
現在，讓我們以以產品經理的身份登錄，修改其中一個激活狀態的需求，進行變更操作。
然后進行內容的變更。
變更完畢后，此時該需求的狀態是已變更狀態。
現在，以產品主管的身份對上述變更做變更評審。
需要我們重點關注的是評審結果：
- 確認通過：選擇該項后， 該需求的變更完成，新的需求狀態為
激活狀態。后續的開發任務按照該需求來。 - 撤銷變更，選擇該項后，該需求撤回到上一次的激活狀態，並且記錄一個變更的版本信息，后續開發任務按照原需求進行，相當於拍了個快照，恢復到之前的狀態。
- 有待明確，選擇該項后，可以將評審結果重新指派給產品經理，然后產品經理再次修改變更記錄，再交給產品主管進行評審的這樣一個流程。
上面三種狀態都是基於產品經理在提需求變更時，選擇需求評審的結果。如果選擇不需要評審，那需求就直接變更完畢，狀態也是激活狀態。
再次強調，當需求內容(標題/描述/附件信息等)發生改變時，都要走變更流程。
項目管理
回到頂部
項目立項
回到頂部
現在，關於產品相關的需求已經評審結束，就可以進入到項目立項階段，也就是即將進入到實際的編碼階段了。
項目立項一般都是開個立項會：
- 由產品人員把產品的需求與項目組成員溝通，必要時調整需求；
- 項目組成員估算完成需求的工作量；
- 對需求進行分解，任務分配；
完事之后，一般由項目經理在禪道中建立項目。
PS:項目組成員在線下已經分配好了，但還需要在項目創建后，手動的關聯，所以，稱這個過程為創建項目和創建團隊。
那現在我們來看項目經理如何建立項目和需求分配，這里先看怎么建項目，由項目經理登錄禪道：
賬號: xiangmujingli1
密碼: root!1234
選擇項目下的添加項目,編輯相關選項。
當你點擊保存后，會提示：
選擇設置團隊，進入如下界面：
當然， 你后續也可以手動的設置項目團隊
選擇團隊管理，關聯項目組成員，並未每個成員設置開發/測試時間。
完事之后，長這樣：
以上就是創建項目和關聯團隊的操作。
注意，訪問控制這里跟之前產品的訪問控制一樣：
- 默認的，只要有項目視圖的就可以看到
- 私有的，項目團隊成員可以看到
- 白名單，白名單中的成員可以看到
關聯/分配需求
回到頂部
當項目創建后，也有了項目團隊，接下來該做什么？是關聯需求，只有關聯了產品人員提出的需求，就可以繼續后續的開發/測試工作了。
那如何關聯需求呢？以及需求如何分配呢？用項目經理登錄：
賬號: xiangmujingli1
密碼: root!1234
關聯需求
項目視圖下的需求選項，該選項展示已經關聯的需求列表，我們暫時還沒有關聯需求，所以列表為空；這里點擊關聯需求。
勾選需要關聯的需求，完事點擊保存，注意，這里只能關聯激活狀態的需求，並且，由於在創建項目的時候，該項目關聯的是代碼統計產品，所以，此時關聯的需求也是該產品下的激活狀態的需求。
關聯完畢后，是這樣的：
那接下來，要干嘛？毫無疑問，關聯完了需求后，那肯定是要找人擼袖子干了啊，所以，接下來要開始需求分配了。
分配需求
此時就到了具體讓誰干的階段了，比如讓開發去碼后台代碼代碼；讓UI去切圖；讓測試去設計測試用例等等。
此時，還是項目經理登錄狀態。
在項目下的需求列表中，點擊加好開始分配需求。
舉一個為開發分配需求的例子，參照下圖進行相關選項的編寫。
在來為測試分配需求：
分配需求就是這么簡單！但是有個問題，在上述操作過程中，都是將任務指派給一個角色，那如果遇到需要將需求分配個多個角色怎么辦，比如各個角色在完成任務后需要編寫總結和報告該怎么分配這個需求，來看看怎么搞。
這就用到了你可能沒有注意到的任務類型選項中的事物選項，該選項就是干這個事兒的。
當選擇事物后，我們就可以將該任務分配多個角色了，相關選項如下圖所示。
現在，任務分配大致就這樣做，我們可以在項目視圖中的任務列表查看這些任務。
另外，在項目視圖下的需求列表中，也能看到各需求的任務數。
當然，在實際的個工作中， 需求分配這些操作都是項目團隊商量着來的，而禪道上只是一種表現形式。
那么，接下來，該干嘛了？開發人員領取任務，並且統計每天的工作量。
項目開發階段
回到頂部
現在，到了開發領取任務，創建項目版本的階段了。
由開發人員登錄：
賬號: kaifa1
密碼: root!1234
需求開發
回到頂部
項目視圖下的任務欄，選擇指派給我的，然后在每一個任務的操作中，點擊開始按鈕，就可以了。
由於，在之前分配任務的時候，項目經理給開發人員就10個工時，此時，第一天干了8個小時，還剩下兩個小時。
當你點擊開始后，在任務列表中也能體現，如下圖，該任務已經開始了，並且任務進度和耗時都有相應的變動。
此時你也可以點擊工時按鈕，進行后續工時的編寫：
如上圖，我們在剩下的的兩個工時中，改了代碼的bug，預計這需求完成了，工時剩余未0，當你點擊保存時，會提示你，是否標記任務完成，此時根據當前的完成情況，這里點擊確定；在所有的任務列表中，發現該需求的狀態是以完成的。
現在，當開發人員完成需求后，就要把項目構建版本、打包傳合並到主分支這些操作了。
構建版本
回到頂部
來看禪道中如何構建版本，此時，還是開發人員登錄狀態。
PS：在工作中，產品最起碼有測試版本(beta)和生穩定(生產)版本(stable)兩個版本甚至有更多的版本。
項目視圖中的版本列表欄，選擇創建版本。
如下圖的選項中：
- 產品的名稱編號一般都是
產品名稱_版本號_teta/stable_日期。 - 描述選項，一遍填寫該版本有哪些功能，解決哪些問題，測試中的注意事項等等。
版本構建完成后，是這樣的：
此時的版本是一個空的版本，因為各項數據都是初始狀態。
版本關聯需求
回到頂部
上一步驟中，構建了版本，那該版本都完成了哪些需求呢？我們來為這個版本關聯上需求。
用到的相關角色賬號：
# admin
賬號: admin
密碼: root!1234
# 開發人員
賬號: kaifa1
密碼: root!1234
賦予(開發)角色自定義權限
默認的，開發人員在構建版本完畢后，並沒有關聯版本的操作按鈕或者鏈接，因為默認沒有該權限。所以，需要使用admin用戶為開發人員賦予該權限。
使用admin賬號登錄。
組織視圖下的版本選項，在研發列，點擊權限維護按鈕。
下拉選擇版本選項，勾選關聯需求選項，再下拉點擊保存即可。 當然，你也可以勾選其他的功能。
此時，在以開發人員人員的角色登錄禪道，在項目視圖下的版本選項，就可以看到了關聯需求的按鈕了，點擊它。
在需求列表中，勾選上相應的需求，就可以關聯了。
完事之后，該版本的完成的需求列表也能查看到該需求了。
OK了。
現在，開發階段算是完事了，該測試人員上場了！
測試階段
回到頂部
開發完成了需求，就該進入提測階段，然后測試就開始進行具體的測試環節了。
那么開發提測的過程在禪道上是如何操作的呢？一起來看看！
用到的相關角色賬號：
# 測試人員
賬號: ceshi1
密碼: root!1234
# 開發人員
賬號: kaifa1
密碼: root!1234
# admin
賬號: admin
密碼: root!1234
# 測試主管
賬號: ceshizhuguan1
密碼: root!1234
開發提測
回到頂部
開發人員登錄。
測試視圖下的版本列表中，下圖是提交測試后的樣子。
點擊提交測試，編寫提測的相關說明。
需要注意的：
- 負責人，指的測試的負責人。
- 優先級，根據功能來選擇。
- 描述，告訴測試需要注意的事項等其他事項。
接下來該干嘛了？測試？測試用例都沒有！來寫測試用例吧！
創建用例
回到頂部
測試人員登錄。
測試視圖下用例列表，點擊＋建用例。
填寫相關選項。
保存后，用例列表就有了這個用例。
版本關聯用例
回到頂部
接下來，還需要將該用例關聯到當前的版本中。
還是測試人員登錄。
測試視圖下的版本列表，點擊關聯用例按鈕。
勾選用例后點擊保存即可。
OK了。
此時，雖然用例寫完了，但是嚴格意義上來說還需要對該用例進行評審。
當然， 默認的，禪道中，用例評審默認是關閉的，我們需要先打開該功能。
后台開啟用例評審功能
回到頂部
admin賬號登錄，后台視圖，自定義菜單欄選擇用例中的評審流程，勾選開啟即可，如下圖所示。
用例評審
回到頂部
當管理員開啟用例評審功能后，在創建用例時，就會發現，有了用例評審選項單選框。
如上圖，該用例需要評審，那在用例列表中，就會發現該用例就是出於待評審階段。
點進該用例的詳情頁，你會發現，你自己其實也可以評審，這塊禪道對於權限的限制沒有那么嚴格，但是一般的由測試主管等領導來評審你的用例。
下圖的截圖是以測試主管的身份登錄，進行該用例的評審。
測試視圖中的用例列表，可以看到待評審的那個用例。
點進詳情頁后，可以進行評審操作。
評審結果這里就兩個選項：
- 確認通過，選擇該項后，該用例處於
正常狀態，就是可以進行實際的測試操作了。 - 和繼續完善，很明顯打回去從新完善唄，流程參考需求評審的流程。
PS：你也可以為剛剛這個用例關聯版本。
用例執行及提交bug
回到頂部
當用例評審過了之后，就可以執行了，執行用例會有兩種結果，通過和失敗，而對於通過和失敗的處理方式，一般可以參考下圖來處理：
我這里以測試主管的身份登錄的， 你可以以測試人員登錄的身份登錄，相關流程都一樣，無所謂的。
測試視圖下的用例列表中，選擇一個用例點擊執行。
注意，這個用例的執行是你真實的在你的測試環境中跑一遍用例，而禪道這里只是記錄一下執行過程。在上圖的測試結果中，每一步都通過的話，就不用管，如果某一步失敗了，就會在下面記錄該失敗步驟，並且可以進行提測，如下圖：
如上圖的第三步驟，出現問題的話，就會記錄該bug，此時點擊右下角的轉bug，將bug提交給開發人員。
如下圖的選項中：
- 截止日期這一欄，我們暫時不填，因為我們也不知道開發什么時候修復該bug。
- 當前指派，原則上應該由誰開發則指派給誰。
- 重現步驟，你應該按照提示進行詳細描述bug產生的過程，便於開發復現bug。
在測試視圖的Bug列表中可以發現剛才提交的bug。
上圖中，可以看到該bug此時是處於未確認狀態，即未經過開發確認的狀態。
除了可以在用例執行過程中提bug，我們還可以單獨點提bug安裝來提bug。
很明顯，有了bug，開發就要確確認及修改bug了。
開發修復bug
回到頂部
開發人員修復bug的流程一般是：
- 確認bug的存在
- 實際的解決bug
- 在禪道上修改bug的狀態
來看禪道中的操作。
開發人員登錄。
測試視圖Bug選項中，指派給我的；這里有兩個重要按鈕：
- 確認，可以直接點擊這個按鈕進行確認該bug，你也可以點擊到bug詳情欄點擊確認。
- 解決，確認后，你就可以去真正的解決該bug，完事再來修改該bug的狀態。
確認bug
當你點擊確認按鈕后，可以選擇bug類型，以及填寫備注等操作，然后點擊保存。
此時bug的狀態就變成了已確認狀態；如果此時測試人員登錄，會發現此bug就是已確認狀態，表示開發確認了bug。
當你解決完這個bug后，需要再次來禪道修改bug狀態，點擊解決按鈕。
關於解決方案，有下面幾種，意思就是字面意思，沒啥好解釋的：
- 設計如此
- 重復bug
- 外部原因
- 已解決
- 無法重現
- 延期處理
- 不予解決
由於該bug是測試主管提交的，所以我們將bug的修改結果在指派給測試主管。此時，該bug的狀態是已解決。
再來個測試主管登錄視圖：
OK啦。
現在，開發說解決了這個bug，就真的解決了么？我們還需要對該bug確認測試，也就是回歸測試。
回歸測試
回到頂部
一旦開發人員將bug修復，然后測試人員就要重新進行回歸測試。
此時，由於bug是測試主管發現並提交的，所以，還由測試主管登錄。
測試視圖下的Bug列表，你會發現該bug處於已解決的狀態：
我們可以點bug詳情來查看。
如上圖，有重要的兩個選項：
- 關閉，當開發修復bug后，測試人員需要再次對該bug進行回歸測試，沒有問題，點擊關閉，這個bug的周期就完了。
- 激活，如果測試人員在回歸測試時，發現bug仍然存在，就要激活該bug，讓開發繼續改，流程如下：
- 由於該bug之前開發確認過，此時，開發直接再次修復該bug，然后在他的視圖中將bug狀態改為
以解決。 - 測試繼續進行回歸測試，通過則關閉bug；失敗則繼續激活，直到通過回歸測試。
- 由於該bug之前開發確認過，此時，開發直接再次修復該bug，然后在他的視圖中將bug狀態改為
來演示 一下測試重新激活的流程：
在bug詳情頁面，測試人員點擊激活按鈕：
此時，無論誰登錄查看，該bug的狀態都是激活狀態；然后開發登錄禪道，發現，該bug被重新激活后，直接修復，然后在禪道上重新修改bug至已解決狀態：
PS：上圖為開發人員視圖。
完事后，測試人員，也就是測試主管在進行回歸測試，發現沒有問題，在點擊關閉即可。
然后，bug列表，你會發現，此時bug處於已關閉狀態：
OK，回測測試過程演示完畢。
注意：如果一個bug反復的解決不掉，就不要在禪道上跟開發來回交互，而是直接跟開發線下溝通，注意和氣生財呦！
總結
回到頂部
本篇主要圍繞一般的產品流程來展開的，整個流程開始由：
- 產品經理：
- 收集信息
- 建立產品
- 為產品建立產品計划，加強產品的控制，項目人員掌握產品進度，便於后續安排
- 為了后續方便，在計划周期內，建立模塊，並且將各個模塊分解為一個個需求
- 並且，對需求進行評審，這是一個線下會議
- 評審中，可能會遇到需求變更，要走需求變更流程
- 項目經理：
- 基於產品建立項目
- 組建項目團隊，開發/測試等團隊
- 確認項目中的需求，進行可能的需求修改
- 對需求進行分解為一個個任務，任務類型需要注意的是
事物，一次性將任務指派給多人。
- 開發：
- 統計每天的工作量
- 完成需求任務后：
- 提交版本，版本命名參考
產品名稱_版本號_teta/stable_日期 - 版本關聯需求
- 提交版本，版本命名參考
- 完事后，提測
- 測試：
- 編寫測試用例
- 用例評審，該功能默認是關閉的，需要管理員開啟
- 執行用例：
- 發現問題，轉bug，將bug提交給開發人員
- 開發人員首先要確認bug，然后改完bug后，修改在禪道修改bug狀態
- 測試回歸測試：
- 通過，關閉bug。
- 失敗，再次激活，跟開發再次交互.....，直到回歸測試通過
- 如果遇到bug反復解決不了的， 就不要在禪道上交互了， 直接線下友好溝通，沒准還能交個女朋友！豈不美哉？