① 軟體測試用例管理工具和bug管理工具有沒有免費下載的啊
可以上bugfree官網看看，我們一直在用，感覺挺不錯的。
網址就不貼了，要不還得審核半天...耽誤時間
直接網路搜索bugfree3.0.2就行。希望能幫到你
最後，求採納，先謝了！
② 用例圖的作用
用例圖主要的作用有三個：（1）獲取需求；（2）指導測試；（3）還可在整個過程中的其它工作流起到指導作用。
元素之間的關系用例圖中包含的元素除了系統邊界、角色和用例，另外就是關系。關系包括用例之間的關系，角色之間的關系，用例和角色之間的關系。
角色之間的關系
角色之間的關系。由於角色實質上也是類，所以它擁有與類相同的關系描述，即角色之間存在泛化關系，泛化關系的含義是把某些角色的共同行為提取出來表示為通用的行為。
用例之間的關系：
包含關系：基本用例的行為包含了另一個用例的行為。基本用例描述在多個用例中都有的公共行為。包含關系本質上是比較特殊的依賴關系。它比一般的依賴關系多了一些語義。在包含關系中箭頭的方向是從基本用例到包含用例。在UML1.1中用例之間是使用和擴展這兩種關系，這兩種關系都是泛化關系的版型。在UML1.3以後的版本中用例之間是包含和擴展這兩種關系。
泛化關系：代表一般與特殊的關系。它的意思和面向對象程序設計中的繼承的概念是類似的。不同的是繼承使用在實施階段，泛化使用在分析、設計階段。在泛化關系中子用例繼承了父用例的行為和含義，子用例也可以增加新的行為和含義或者覆蓋父用例中的行為和含義。
擴展關系的基本含義和泛化關系類似，但在擴展關系中，對於擴展用例有更多的規則限制，基本用例必須聲明擴展點，而擴展用例只能在擴展點上增加新的行為和含義。與包含關系一樣，擴展關系也是依賴關系的版型。在擴展關系中，箭頭的方向是從擴展用例到基本用例，這與包含關系是不同的。
用例的泛化、包含、擴展關系的比較。一般來說可以使用「is a」和「has a」來判斷使用那種關系。泛化和擴展關系表示用例之間是「is a」關系，包含關系表示用例之間是「has a」關系。擴展與泛化相比多了擴展點，擴展用例只能在基本用例的擴展點上進行擴展。在擴展關系中基本用例是獨立存在。在包含關系中在執行基本用例的時候一定會執行包含用例。如果需要重復處理兩個或多個用例時可以考慮使用包含關系，實現一個基本用例對另一個的引用。當處理正常行為的變形是偶爾描述時可以考慮只用泛化關系。當描述正常行為的變形希望採用更多的控制方式時，可以在基本用例中設置擴展點，使用擴展關系。擴展關系比較難理解，如果把擴展關系看作是帶有更多規則限制的泛化關系，可以幫助理解。通常先獲得基本用例，針對這個用例中的每一個行為提問：該步驟會出什麼差錯？該步驟有不同的情況工作怎樣以不同的方式進行等，把所有的變化情況都標識為擴展。通常基本用例很容易構造，而擴展用例需要反復分析、驗證。當我們發現已經存在的兩個用例間具有某種相似性時，可以把相似的部分從兩個用例中抽象出來單獨作為一個用例，該用例被這兩個用例同時使用，這個抽象出的用例和另外兩個用例形成包含關系。
用例之間的關系舉例
包含：業務中，總是存在著維護某某信息的功能，如果將它作為一個用例，那新建、編輯以及修改都要在用例詳述中描述，過於復雜；如果分成新建用例、編輯用例和刪除用例，則劃分太細。這時包含關系可以用來理清關系。
擴展：系統中允許用戶對查詢的結果進行導出、列印。對於查詢而言，能不能導出、列印查詢都是一樣的，導出、列印是不可見的。導出、列印和查詢相對獨立，而且為查詢添加了新行為。
泛化：子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。
用例圖展示了用例之間以及同用例參與者之間是怎樣相互聯系的。用例圖用於對系統、子系統或類的行為進行可視化，使用戶能夠理解如何使用這些元素，並使開發者能夠實現這些元素。
將每個系統中的用戶分出工作狀態的屬性和工作內容，方便建模，防止功能重復和多餘的類。
用例圖定義了系統的功能需求，它是從系統的外部看系統功能，並不描述系統內部對功能的具體實現。
③ UML用例圖中用例一般控制在多少個左右為宜
這個沒固定標准吧，系統大了肯定用例多。
但是要注意以下幾點：內
1 用例止於系統容邊界，邊界可想像成界面或對外介面。用例決不能包含邊界以內的東西，那是系統分析、設計的工作。用例設計是需求分析的工作。
2 用例的粒度適中。當用例進入到邊界以內就說明太細了，要調整。
3 用例是有意義的目標
4 用例結果由系統生成。至於怎麼生成的那是邊界以內的事，目前不考慮。
5 用例的步驟必須能讓參與者觀察到，既所謂的事件流。
④ 有沒有好點的測試用例的管理工具
我目前用的是Testlink來管理測試用例的，要是想到導出excel可以用testlinkconvert將在testlink中導出的xml的文件轉化為excel，個人用起來非常方便。
⑤ 淺談如何維護軟體測試用例
軟體產品的版本是隨著軟體的升級而不斷變化的，而每一次版本的變化都會對測試用例集產生影響，所以測試用例集也需要不斷地變更和維護，使之與產品的變化保持一致。以下原因可能導致測試用例變更： 1）軟體需求變更：軟體需求變更可能導致軟體功能的增加、刪除、修改等變化，應遵循需求變更控制管理方法，同樣變更的測試用例也需要執行變更管理流程。 2）測試需求的遺漏和誤解：由於測試需求分析不到位，可能導致測試需求遺漏或者誤解，相應的測試用力也要進行變更。特別是對於軟體隱性需求，在測試需求分析階段容易遺漏，而在測試執行過程中被發現，這時需要補充測試用例。 3）測試用例遺漏：在測試過程中，發現測試用例未覆蓋全部需求，需要補充相應的測試用例。 4）軟體發布後，用戶反饋的缺陷：表明測試不全面，存在尚未發現的缺陷，需要補充或者修改測試用例。 對於提供軟體服務的產品，其多個版本常常共存，而對應的測試用例也是共存的，而且測試用例需要專人定期維護，並遵循以下原則： 1）及時刪除過時的測試用例 需求變更可能導致原有部分測試用例不再適合新的需求要求。例如，刪除了某個功能，那麼針對該功能的測試用例也不再需要。所以隨著需求的每一次變更，都要刪除那些不再使用的測試用例。 2）及時刪除冗餘的測試用例 在設計測試用例時，可能存在兩個或者多個用例測試相同內容，降低回歸測試效率，所以要定期整理測試用例集，及時刪除冗餘的測試用例。 3）增加新的測試用例 由於需求變更、用例遺漏或者版本發布後發現缺陷等原因，原有的測試用例集沒有完全覆蓋軟體需求，需要增加新的測試用例。 4）改進測試用例 隨著開發工作進行，測試用例不斷增加，某些用例隨著系統輸入和當前狀態的變化而變得不再適用，這些用例難以重用，影響回歸測試的效率，需要進行改進，使之可重用可控制。 總之，測試用例的維護是一個長期的過程，也是一個不斷改進和完善的過程。
⑥ 如何用confluence對用例管理
Confluence為團隊提供一個協作環境。在這里，團隊成員齊心協力，各擅其能，協同地編內寫容文檔和管理項目。從此打破不同團隊、不同部門以及個人之間信息孤島的僵局，Confluence真正實現了組織資源共享。
Confluence使用簡單，但它強大的編輯和站點管理特徵能夠幫助團隊成員之間共享信息、文檔協作、集體討論。
⑦ 什麼是測試用例，它是由哪些基本元素組成
1、測試用例來是為某個特殊源目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。
2、測試用例的基本元素：
測試索引，測試環境，測試輸入，測試操作，預期結果，評價標准。
知識點延伸：
測試用例是將軟體測試的行為活動做一個科學化的組織歸納，目的是能夠將軟體測試的行為轉化成可管理的模式；同時測試用例也是將測試具體量化的方法之一，不同類別的軟體，測試用例是不同的。不同於諸如系統、工具、控制、游戲軟體，管理軟體的用戶需求更加不同的趨勢。
⑧ testlink中沒有版本管理這個功能
在「測試計劃管理」中先創建一個測試計劃，並且一定要勾選上「活動」「公共」，創建完成回到主頁後就有「版本管理」選項和「編輯/刪除里程碑」選項了。
⑨ 敏捷開發中的測試用例管理工具
可以試試統御項目管理軟體oKit，到oKit官網看看，可以做多項目管理，可以做測試用例管理，可以和缺陷管理功能結合，記錄測試活動中發現的缺陷和改進建議，並可形成分析報告和詳細報表。
⑩ 哪個用例管理工具適合selenium自動化測試
IBM Rational Quality Manager（RQM）是一款基於 Web 的出色的質量管理軟體，用於貫穿軟體生命周期的綜合測試規劃和測試資源管理。它提供了多種適配器與其他工具集成，使 RQM 能夠管理並運行由其他工具創建的自動化測試腳本。 Selenium 是一款基於 Web 應用的開源測試工具，它能夠支持多種瀏覽器和多種編程語言，同時它提供了快速、輕量級的瀏覽器模擬器，為用戶提供了最優秀框架的最佳途徑。它的諸多優勢，令 Selenium 成為當下非常流行的 Web 應用程序的自動化測試工具。 RQM4.0 版本中，提供了 JUnit Selenium Adapter 來實施與 Selenium 的集成，使 RQM 可以運行 Selenium 2.0 WebDriver JUnit4 的測試件。 當 JUnit Selenium Adapter 運行時，該 Adapter 會對 RQM 伺服器進行輪詢，以獲取運行 Selenium 測試的請求。請求中包括要運行的 Java 類（例如，JUnit 測試套件或測試用例）、必需的任何其他類路徑值以及要為用於運行測試的 Java 虛擬機 (JVM) 設置的任何 Java 系統屬性（可選）。運行測試後，Adapter 會將執行結果以及關聯的附件上傳到伺服器。