禪道項目管理軟件測試單（禪道項目管理工具）

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

本文目錄一覽：

• 1、禪道項目管理軟件的功能列表
• 2、禪道項目測試不了
• 3、軟件測試的項目有哪些常用的缺陷管理工具？
• 4、六問禪道1：為什么任務的剩余工時不自動更新
• 5、禪道項目管理軟件的功能特點
• 6、軟件測試的流程是什么？

禪道項目管理軟件的功能列表

1. 產品管理：包括產品、需求、計劃、發布、路線圖等功能。
2. 項目管理：包括項目、任務、團隊、build、燃盡圖等功能。
3. 質量管理：包括bug、測試用例、測試任務、測試結果等功能。
4. 文檔管理：包括產品文檔庫、項目文檔庫、自定義文檔庫等功能。
5. 事務管理：包括todo管理，我的任務、我的Bug、我的需求、我的項目等個人事務管理功能。
6. 組織管理：包括部門、用戶、分組、權限等功能。
7. 統計功能：豐富的統計表。
8. 搜索功能：強大的搜索，幫助您找到相應的數據。
9. 靈活的擴展機制，幾乎可以對禪道的任何地方進行擴展。
10. 強大的api機制，方便與其他系統集成。
也許您已經"眾里尋她千百度"，那么讓禪道帶給您“驀然回首，那人卻在燈火闌珊處”的驚喜吧！Let's zentao!

禪道項目測試不了

禪道項目測試不了是版本過期禪道項目管理軟件測試單，重新安裝最新版本即可。禪道項目管理軟件是國產的開源項目管理軟件禪道項目管理軟件測試單，專注研發項目管理禪道項目管理軟件測試單，內置需求管理、任務管理、bug管理、缺陷管理、用例管理、計劃發布等功能。

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

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
略
如果想這塊內容增強的小伙伴參考網上的相關知識(黑馬程序員論壇等)

六問禪道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、允許任務的最初預計工時和總消耗工時存在偏差。任務完成后，二者對比以糾正自己的工時估算。

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

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

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

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

軟件測試的流程是什么？

需求分析與架構設計禪道項目管理軟件測試單：

我們做的是某一移動公司內部使用的項目禪道項目管理軟件測試單，需求分析與架構全部由項目經理完成禪道項目管理軟件測試單，之后由項目經理給具體某個開發人員分配任務，具體對某個功能模塊的實現。這個對項目經理的經驗與技術要求很高，禪道項目管理軟件測試單他既然擔任了需求分析師，又擔任架構師的角色。

程序員編碼禪道項目管理軟件測試單：

因為我們開發語言用的是JAVA 語言，IDE用MyEclipse中自帶的CVS版本管理工具，開發人員完成代碼后，提交到版本庫中。

測試：

我入職后的第一個任務是搭建缺陷管理工具，禪道項目管理，通過推廣對發現的問題進行跟蹤。后來正明效果并不好，因為對于一個六七人的開發團隊項目，開發人員更喜歡測試人員能當面反饋，這樣更能提高效率。對一個小 bug 通過當面交流的方式就可以將問題修復。

對于當時的環境，并沒有測試環境。開發人員在本機上將項目進行部署運行。測試人員通過局域網訪問開發人員的機子進行測試?；蛟跍y試人員本機上進行部署測試。這也是一個致命的缺點。因為開發人員測試人員使用的電腦存在太多不穩定因素，這些都會造成問題的出現，有時候難以判定是系統問題還是環境問題。

上線：

經過測試人員測試通過后，開發人員部署上線。

A程序員流程

你會發現在流程圖中，A程序員是先發上線之后，再進行測試。這是我們一個面向大眾用戶的網站，上面給與測試人員的定位是測試兼用戶體驗，測試將發現的bug和體驗問題提交到缺陷管理系統，由經理對問題進行分析，指派開發人員解決。定期對系統進行更新。

流程分析：

這個流程唯一的優點，就是能快速的發現并修復問題。

缺點就非常多了，相信許多小軟件公司也有類似的流程。

這個流程中，項目經理是核心，項目經理也確實是有多年開發與項目經驗的牛人，他喜歡不定期分享上些前沿的技術。

對于測試來說，需求很不明確，測試文檔與用例也是可有可無的產物，沒有需求文檔，或非常簡陋，根據需求文檔根本無法編寫用例。我只能收集一些通用的測試用例，如登錄、文件上傳下載、列表翻頁、日期選擇、輸入框驗證、搜索等有一些“通用型”用例，以便在測試過程中做參考。功能測試的多了，拿到一個功能，測試思路也就出來了。

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

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

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