禪道項目管理軟件 漏洞（項目管理系統 禪道）

本篇文章給大家談談禪道項目管理軟件 漏洞，以及項目管理系統 禪道對應的知識點，希望對各位有所幫助，不要忘了收藏本站喔。 今天給各位分享禪道項目管理軟件 漏洞的知識，其中也會對項目管理系統 禪道進行解釋，如果能碰巧解決你現在面臨的問題，別忘了關注本站，現在開始吧！

本文目錄一覽：

• 1、軟件測試管理神器之zentao(禪道)-BUG管理
• 2、禪道管理/禪道管理軟件 是什么？優缺點是什么？
• 3、軟件測試的項目有哪些常用的缺陷管理工具？
• 4、禪道項目管理軟件的功能特點
• 5、禪道項目管理軟件的簡介
• 6、六問禪道1：為什么任務的剩余工時不自動更新

軟件測試管理神器之zentao(禪道)-BUG管理

禪道在遵循其管理方式基礎上，結合國內研發現狀，整合了bug管理，測試用例管理，發布管理，文檔管理等功能，完整的覆蓋了軟件研發項目的整個生命周期。在禪道軟件中，明確的將產品、項目、測試三者概念區分開，產品人員、開發團隊、測試人員，三者分立，互相配合，又互相制約，通過需求、任務、bug來進行交相互動，終通過項目拿到合格的產品。

禪道是一個軟件全生命周期管理工具，但作為測試人員，可能梗關注其中的bug管理及測試用例管理的模塊， 本文就重點說下bug管理。

禪道里面的bug基本流程是：? 測試人員提出bug - 開發人員解決bug - 測試人員驗證關閉 。

下面我們來演示下具體的使用方法。

一、創建產品

使用 bug管理功能之前，需要先創建產品，禪道里面設計的理念是bug主要附屬在產品概念下面的，添加產品的入口有多個，可以在所有產品頁面點擊右側的“添加產品”按鈕。

新增產品的時候，需要設置產品的名稱、代號，幾個負責人信息，可以根據具體情況選擇填寫必填項。

二、提交bug單到禪道

有了產品之后，我們就可以來創建bug了， 在禪道里面提交bug的方式有兩種，一種是測試用例的執行結果為失敗時，轉bug；另一種是不依賴測試用例的bug，可以直接進行提交 。

1、由執行測試用例的測試用例直接轉bug單

通過【用例】模塊的不通過用例的【轉bug】按鈕后，可以打開一個bug提交頁面。輸入相應的缺陷信息后，點擊【保存】即可完成缺陷的提交。

2、直接提交bug單

這樣的bug提交方式是不依賴于測試用例的。可以直接通過【bug】模塊內的【提bug】進行bug提交，提交bug的頁面和轉bug頁面基本一致，但是提bug頁面中沒有預先填寫的信息，這里需要一項一項的輸入。輸入完成后點擊【保存】按鈕完成缺陷的提交。

3、兩種方式的區別

用【轉bug】生成的bug單，在bug 的信息里面有一項數據是關于【來源用例】，用來展示該bug 是由哪一個測試用例轉來的。

直接提交的bug單，沒有【來源用例信息】，和系統中的測試用例沒有任何關系。

最好的方式就是依據測試用例的執行結果進行bug的提交，這樣也可以溯源，就算是通過探索方法發現的缺陷，也可以補充一條用例進行關聯的；

三、bug單的生命周期管理

Bug的生命周期在課程中是一個重中之重，當一個bug被提交就表明他的生命周期的開始，之后指派給某一位研發人員之后，由開發來確認、解決這個bug。

一般bug的處理流程是：

1、確認bug單

確認該bug確實存在后，可以將其指派給某人，并指定bug類型、優先級、備注、抄送等。

2、解決bug單

當bug修復解決后，點擊解決，指定解決方案、日期、版本，并可將其再指派給測試人員。

3、關閉bug單

當研發人員解決了bug之后，bug會重新指派到bug的創建者頭上。這時候測試人員可以來驗證這個bug是否已經修復。如果驗證通過，則可以關閉該bug。（bug列表頁和詳情頁中都有“關閉”按鈕。）

4、激活bug單

如果一個bug沒有被修復，解決之后或者關閉之后，也可以對其進行激活。

四、總結

關于禪道工具的使用，還有很多，官方也提供了很詳細的說明，可以自行查閱。

官方幫助文檔： https://www.zentao.net/book/zentaopmshelp/

歡迎關注作者，如果覺得寫的還不錯，就給點個贊同、喜歡、收藏（后續持續更新）。

禪道管理/禪道管理軟件 是什么？優缺點是什么？

比較雜的軟件：
1, 模塊比較多禪道項目管理軟件 漏洞，感覺缺乏有機的整合。比如，問題管理如何與缺陷管理銜接禪道項目管理軟件 漏洞？問題管理如何與項目對接。文檔管理與項目成果對接等。總的感覺比較雜亂，屬于堆積功能的。
2，各個模塊不夠精細，太粗糙。比如質量管理太簡單了，基本上無法使用；需求管理也不是很理想；產品管理的理念是什么？是IPD還是其禪道項目管理軟件 漏洞他？沒有理念就沒有靈魂。
優點：入門級的簡單項目管理軟件，不計算成本、不管理項目組合，只是一個task管理還可以。

軟件測試的項目有哪些常用的缺陷管理工具？

1.QC
QC的全稱Quality center, 質量中心的意思，它是一款缺陷管理工具，可以組織和管理一個項目所有的測試階段.
2.Bugzilla，
Bugzilla是一個Bug追蹤系統設計用來幫助你管理軟件開發。
Bugzilla是一開源Bug Tracking System，是專門為Unix定制開發的。但是在windows平臺下依然可以成功安裝使用.
3.Bugfree，
BugFree是借鑒微軟的研發流程和Bug管理理念，使用PHP+MySQL獨立寫出的一個Bug
管理系統。簡單實用、免費并且開放源代碼(遵循GNU GPL)。
4.JIRA
JIRA是集項目計劃、任務分配、需求管理、錯誤跟蹤于一體的商業軟件。
JIRA功能全面，界面友好，安裝簡單，配置靈活，權限管理以及可擴展性方面都十分出色。
JIRA創建的默認問題類型包括New Feature、Bug、Task和Improvement四種，還可以自己定義，所以它也一是過程管理系統。
Jira融合了項目管理、任務管理和缺陷管理，許多著名的開源項目都采用了JIRA。
JIRA 是目前比較流行的基于Java架構的管理系統，由于Atlassian公司對很多開源項目實行免費提供缺陷跟蹤服務，因此在開源領域，其認知度比其他的產品要高得多，而且易用性也好一些。同時，開源則是其另一特色，在用戶購買其軟件的同時，也就將源代碼也購置進來，方便做二次開發。
5.Mantis
Mantis是一個基于PHP技術的輕量級的缺陷跟蹤系統，其功能與前面提及的JIRA系統類似，都是以Web操作的形式提供項目管理及缺陷跟蹤服務。在功能上可能沒有JIRA那么專業，界面也沒有JIRA漂亮，但在實用性上足以滿足中小型項目的管理及跟蹤。更重要的是其開源，不需要負擔任何費用。不過目前的版本還存在一些問題，期待在今后的版本中能夠得以完善。
6.Readmine
Redmine是用ruby開發的基于web的項目管理軟件，免費。JIRA收費
Redmine可以創建子任務，而jira不易創建子任務。
Redmine來管理項目，但它沒有用例管理.
7.禪道
禪道項目管理軟件是開源，集產品管理、項目管理、質量管理、文檔管理、組織管理和事務管理于一體，是一款功能完備的項目管理軟件，完美地覆蓋了項目管理的核心流程。
8.TAPD
TAPD項目管理軟件是基于敏捷開源，隸屬騰訊開發出來的，集產品管理、項目管理、質量管理、文檔管理、組織管理和事務管理于一體，是一款功能完備的項目管理軟件，完美地覆蓋了敏捷項目管理的核心流程。
9.TESTLINK
略
10.TD
略
如果想這塊內容增強的小伙伴參考網上的相關知識(黑馬程序員論壇等)

禪道項目管理軟件的功能特點

一體化研發管理
禪道項目管理軟件主要管理思想基于應用最為廣泛的敏捷開發方法Scrum，同時又增加了Bug管理，測試用例管理，發布管理，文檔管理等必需功能，覆蓋了研發類項目管理的核心流程，為IT企業或正在進行信息化的企業提供了一個一體化的集成管理工具。
概念清晰，功能完備
30多個功能模塊，200多個功能點，滿足項目管理方方面面的需求。在scrum基本的流程基礎上，我們創造性地實現了需求、任務、bug、用例、todo之間的互選轉換和輪轉：需求分解為任務、bug可以轉換為需求、bug可以導入到項目中作為任務跟蹤、用例執行結果可以生成bug、bug可以轉為用例。bug和任務可以轉換為個人的todo。
輕量級實現
從功能上來講，我們只提供研發類項目管理所必需的功能，概念簡潔。
從實現上來講，我們堅持用最少的代碼提供更多的功能，給用戶提供可以維護的代碼。
從運行環境與來講，我們提供了windows平臺(不足10M)和linux平臺的集成運行環境(不足20M)，方便用戶快速下載部署。
可擴展的系統
禪道里面的擴展除了鉤子機制之外，還提供了通過面向對象機制實現的繼承和覆蓋，通過禪道的擴展機制您可以對禪道所有地方進行擴展。
每一個頁面都可以通過API進行調用，方便其他語言集成。
內置插件應用平臺，可以快速瀏覽已有插件并選擇安裝、升級、卸載等操作。
可靠及時的技術支持
禪道項目管理軟件入手簡單，集成一鍵安裝包傻瓜式安裝，讓非IT專業的人員也能輕松使用。
網站的問答反饋系統可以保證您的問題或者建議得到及時有效的處理和反饋。
開源免費的系統
禪道一直走的是開源路線，從下載到使用不需任何費用，強大的管理功能適用于國內外大部分項目管理及產品開發，開源的軟件更能夠根據企業自身需求在源碼的基礎上進行修改，讓國內外眾多企業節省項目管理成本，免費的軟件更為企業節約了系統采購成本，更是廣大中小企業的福音。

禪道項目管理軟件的簡介

禪道是第一款國產禪道項目管理軟件 漏洞的優秀開源項目管理軟件。先進的管理思想禪道項目管理軟件 漏洞，合理的軟件架構，簡潔實效的操作，優雅的代碼實現，靈活的擴展機制，強大而易用的api調用機制，多語言支持，多風格支持，搜索功能，統計功能——這一切，您通過禪道，都可以擁有禪道項目管理軟件 漏洞！禪道在手，項目無憂！
為什么用“禪道(ZenTao)”這個名字禪道項目管理軟件 漏洞？
禪和道是中國文化中極具代表意義的兩個字，是中國傳統文化的結晶。我們之所以選用“禪道”作為我們軟件的名字，是希望通過這兩個字來傳達我們對管理的理解和思考。我們希望通過禪道來進行的管理，可以摒棄繁文縟節，摒棄官本位的畸形，還原事情的本質！
英文里面的禪為Zen，道為Tao，所以我們軟件的英文名字為zentao，記住這個單詞吧！

六問禪道1：為什么任務的剩余工時不自動更新

我自己從2010年8月開始接觸和使用 禪道項目管理軟件 ，由剛開始的只使用測試--Bug管理模塊，到現在的所有模塊均有在使用。

在不斷的使用過程中，加上長期混跡在禪道QQ技術交流群，對禪道的使用，項目管理也有了深入的理解。

在QQ群里，同樣的問題經常被問起，看起來是個小問題，其實里面卻蘊含了項目管理的一些大道理。

因此，我以禪道使用為背景，再加上自己的拙見，整理了“六問禪道項目”系列使用分享，希望能達到拋磚引玉的效果。

歡迎吐槽指正。

今天來說說任務工時更新問題。

不少童鞋都有在問：禪道里記錄任務工時，輸入日期和工時后，為什么還要輸入剩余，這么簡單的加減系統不會自動計算嗎？

也就是說很多童鞋對任務工時有 誤讀 ，單純的認為任務 預計剩余工時?= 最初預計工時 — 已經消耗工時。

具體解答問題之前，我們先來了解一下禪道里的工時概念：

最初預計： 創建任務時的最初預計工時。
已經消耗： 開發這個任務已花費的工時。
預計剩余： 完成這個任務還需要的工時。

套用一句老話“計劃沒有變化快”，以我的個人經歷來說比較常見的任務開發狀況：

1、某個任務最初預計工時是10，coding了5小時后，重新估算還要9小時才能完成，系統自動計算剩余工時的話是3小時。

2、某個任務最初預計工時是10，coding了5小時后，任務完成了，剩余工時為0，系統自動計算剩余工時的話還是3小時。

3、某個任務最初預計工時是10，coding了5小時后，重新估算還要1小時就可完成。系統自動計算剩余工時的話依舊是3小時。

或許你會反駁我，難道就不存在任務很完美的按預期開發并完成，最初預計與總消耗工時一致的情況嗎？有，這種理想狀況出現的頻率足以讓我們忽略掉它的存在。

還有個類似的問題：關于任務已消耗工時的自動更新。有不少童鞋說這個任務我coding了1天，已消耗工時就應該自動記為8小時呀。

錯！鬼才知道這一天你都coding了些什么。

讓系統自動更新任務已消耗和剩余工時，不僅是錯誤的認識，而且還會引發一些問題：

1、不能反映出任務的真實開發狀況，導致任務剩余工時統計有誤。

2、項目進度和燃盡圖不能真實反映當前項目進展。禪道里項目進度（進度=項目任務總消耗工時/（項目任務總消耗工時+項目任務總剩余工時））和燃盡圖都是通過統計任務的剩余工時來繪制的。

3、錯誤的數據讓項目經理對項目全局的掌控有偏差，對項目的調整和決策出現失誤。進而會導致出現項目延期，人員分工不合理，沒有測試就匆忙發布，交付的產品Bug頻出等一系列問題。

所以嚴格按照任務開發實際狀況記錄工時是很有必要的，而不能簡單的讓系統自動計算掩蓋掉真實的數據。

關于任務工時更新，我比較推薦的做法：

1、最初預計工時在任務開始后，就不要再做修改。

2、開發人員每天及時更新任務狀態和工時。

3、更新任務工時，結合實際開發狀況重新估算剩余工時并記錄。

4、允許任務的最初預計工時和總消耗工時存在偏差。任務完成后，二者對比以糾正自己的工時估算。

總結下來就是： 及時更新，重新估算，真實填寫。

最后，簡短粗暴的回答： 禪道里任務最初預計工時 ≠ 已經消耗工時 + 預計剩余工時。

關于禪道項目管理軟件 漏洞和項目管理系統 禪道的介紹到此就結束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關注本站。 禪道項目管理軟件 漏洞的介紹就聊到這里吧，感謝你花時間閱讀本站內容，更多關于項目管理系統 禪道、禪道項目管理軟件 漏洞的信息別忘了在本站進行查找喔。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。