最好是開源的,可以本地安裝的那種。


就我自己使用過的幾個來說,像PingCode-Testhub、zephyr for Jira都是覺得不錯的測試用例管理工具,當然也不止這些,下面就國內的一些測試用例管理工具做了簡單的調研對比,開源和不開源的都有,僅供參考:

一、功能對比

  • 僅從功能數量對比來看 ,PingCode 產品的 Testhub 功能是比較全面的,但是它在測試自動化,以及Open Api 這塊基本上都不支持,這塊是弱於Jira的
  • Jira在測試自動化,以及OpenApi做的比較好,這是其它幾個產品不具備的,但是Jira對本土化的支持不是很友好,行為習慣和國內的用戶有一些差距。
  • 禪道是開源的,用戶可以自己下載搭建,但有一定的使用門檻,筆者不太喜歡它的界面風格,當然對於有代碼控的人除外。

簡單的功能對比過後,可能你還是不知道如何選,那可以接著往下看。

二、面對市場上各有特色的測試管理工具如何選?

這就回到了工具選型的老問題:你要用這個工具來做什麼的,達到什麼目的?畢竟沒有最好的,只有最適合的。

聊到這我們再來聊點題外話而通常來說,企業的測試需求大體可以分為三個階段:

廣義測試的第一階段

有的人說測試用Excel就足以,通過Excel來維護測試用例,每次產品發布,按照Excel裡面的用例,把產品功能過一遍,這樣做也沒問題,但是你想過沒有,隨著項目的迭代,複雜度的增加,Excel的缺點就顯而易見了,工作的效率及其低下,並且不能多人合作,用例的版本維護亂七八糟的,並且無法與缺陷做到實時關聯,可以說用Excel來測試的團隊,是那種及其小的團隊,一個測試人員而已,或者沒有專門的測試人員,由產品來代勞。

廣義測試的第二階段

而在一些稍具規模的公司,測試團隊大概在20人以內的,基本上都會選擇一個成熟的測試管理工具來管理整個產品的質量,達到多人協作,包括用例評審,討論,版本,測試和需求,缺陷的關聯,測試報告 以及後續的統計分析,能更好的支持反饋和跟蹤,持續提高產品的質量,保證產品的穩定性。

廣義測試第三階段

除了上面的兩個階段外,大家會覺的測試應該還有更高級的階段,沒錯,你想的是對的,性能測試,壓力測試,負載測試,自動化測試,以及集成到流水線,我們把這個稱為廣義測試第三階段吧,筆者目前所就職的公司基本上是處於這個階段的,但在性能測試,壓力測試這塊基本上是0,也可能是目前的數據量和用戶量沒達到一定的級別的原因吧,也是需要持續改進的。

在以上三個階段中,可能大多數中小型公司都處在廣義測試的第二階段,而這階段的公司,以上說到的幾個工具基本都在可選範圍,但無論從免費的角度還是綜合的體驗的角度,我個人是比較推薦PingCode-Testhub,這也是我司現在的工具。

推薦理由:

1、25人以下團隊免費

2、Testhub只是PingCode項目、任務、需求、缺陷、迭代規劃、測試、目標管理全流程管理環節中的子產品之一,如果公司後續有其他研發管理工具需求,為打通互聯提供便捷。

3、支持自定義,能夠適應多變的業務,這也對於對擴展有情結的人來說非常重要

缺點:不開源

OK,除了上面的對比,我也給出使用過程中的一些具體細節,讓大家能有一個更詳細的考量;

三、測試全流程的使用體驗總結

  • 創建用例庫: 能用來存儲所有的用例,按照不同項目統一的管理,查找和調用比之前方便不少。對於公用的用例,也支持建立一個公共的用例庫,可共享用例庫實現公用,減少用例重複維護的工作量

  • 創建測試用例: 支持按照所測試的功能點建立對應的測試用例,支持書寫用例步驟,設置用例的級別,維護人,用例的類型,備註等,用例的步驟支持複製,同時用例支持連續創建,這個功能點用起來還是比較爽的

  • 導入測試用例 : 支持 Excel 和腦圖導入,腦圖的導入這個功能也還行

  • 用例列表的維護:面對很多用例的時候,有一個維護頁面,在這個界面,可以批量設置維護人,刪除用例,把用例移動,複製到其它用例庫,同時還支持各種條件的搜索

  • 用例和用戶故事關聯:支持測試用例和用戶故事的關聯,就是說這個用例是測試那些用戶故事的場景的,且能查看所關聯的用戶故事的信息,狀態,等

  • 用例評審:可能部分公司像我司一樣會有一個新用例評審的環節,大家通過評審,共同去梳理這些測試用例的規範以及全面性,提高測試的能力,而PingCode是支持建立評審的。

  • 評審結果展示:

  • 測試計劃:用例維護好了之後,支持建立測試計劃來完成一次的功能測,並且能把所測的功能對應的用例規划進來。

  • 執行用例:按照計劃規劃好測試用例之後,進入到一個個功能測試階段,而這個過程中,PingCode支持填寫在真實的測試過程的實際值是不是符合用例的期望值,是不是功能有缺陷,測試是否通過,等等

  • 用例與缺陷關聯: 測試的過程中發現的缺陷,可以在執行用例的上面創建一個缺陷,提交到缺陷系統中,同時這個缺陷和這次的測試關聯起來,做到可以追溯,開發人員修正缺陷之後,測試人員也可以進一步的回顧測試。

  • 用例的自定義配置: 用戶可以定義自己需要的任何場景的測試用例,支持定製化

  • 用例的模板: 用戶在寫完一個測試用例之後,可以把它保存稱模塊,在書寫其他用例的時直接使用模板,然後改一改就可以了,非常節省時間(對於測試人員來說,有些測試用例測試步驟大體上是一樣的,只是有一些細微的差別,這點挺好)

  • 輸出完整的測試報告:測試團隊的leader更關心的整體報告,測試的覆蓋率,缺陷的統計,以及每個測試人員測試了多少用例,在PingCode也是能實現的。

更多的使用細節,就不一一介紹了,雖然不開源,但也很值得嘗試。

而且25人以下免費,這對預算有限的創業公司來說,是個不錯的選擇。

PingCode


MeterSphere 值得一試。


讓開發重構Testlink,然後你們補充想要的需求咯


目前業內可用的測試用例工具都是收費的,開源的方案感覺就禪道體驗是最好的。

我目前採用的方式是xmind加禪道,先在xmind中寫用例並且進行測試用例評審。然後將xmind轉成excel,然後導入禪道。

不過禪道的測試用例管理能力也比較雞肋,比如:不能過去測試用例通過率。當然也可以考慮自己去開發一個測試用例平台,這種就可以想怎麼玩就怎麼玩了。


自己開發適合自己的,其他人合適的不一定適合你們,更何況大部分公司都已經開始自研測試平台了,最終都是用來賣錢的,真正的開源都是測開用來鍛煉自己技術的產物,這是一條測試未來轉型的道路,從功能走向測開


用思維導圖工具即可,例如xmind


現在市面大大小小的測試用例管理工具已經非常多了說一說我自己對測試用例管理的經歷和理解吧

Excel,這是在一家航空公司,傳統行業,版本迭代周期半年吧,設計用例和用例評審有1個月的時間,所以那會兒似乎不怎麼覺得效率低下,只要生產不出問題,用例花多少時間都值得。

Mercury旗下的一款產品,原諒我想不起他的名字,是在一家保險公司,終於用上了工具來管理了,但是模版、欄位限制比較多,不夠靈活,執行的體驗也不太好,感覺是為了用工具而寫用例。

TAPD,這是在一家互聯網公司了,發布節奏比較快,沒有太多時間寫用例,看中了TAPD的思維導圖能直接生成測試用例的功能,但是目前為止,功能還不完善,只有子節點才能生成用例,也就是說,要提前設計好所有的功能模塊,模塊下的功能點,將這些全都生成好對應的用例之後,再思維導圖下再設計用例,才能用上導圖轉用例的功能。期待完善吧,現在是推廣不起來的。

MeterSphere,是個開源產品,在testhome群里被推薦的,一鍵部署,體驗了下,測試用例模塊中規中矩,但是能把測試用例和介面用例、性能測試用例直接關聯,這個點還是蠻好的,還有個瀏覽器插件,執行功能測試的用時,插件會錄製全部請求,請求導入到平台上,就是一個介面測試用例了,進行參數話處理之後,還能直接生成一個性能測試用例,有點小驚喜。

測試用例管理
測試計劃,執行測試用例
介面測試用例
性能測試用例

如果要把功能的測試用例包括手工測試、介面測試、性能測試,在一個平台進行管理,那目前看來MeterSphere是具備這些條件的,加了官方交流群,後面還要上UI測試和移動端測試,感覺可以期待一下。


最近在用AgileTC,滴滴開源的一個用例管理工具,安裝起來很方便,幾乎沒有遇到障礙。xmind編輯用例的那種,用著還不錯,可以多人一起編輯。用xmind用慣了,這個還是蠻舒服的,不過目前開源出來的部分沒有項目管理啥的,只能管理和執行用例、展示一些進度和完成情況的打標,本地自己使用or單純用例管理or加到公司的項目里還是不錯的。


推薦閱讀:
相关文章