1樓：Aaron Chen
可以試試ngtesting，比testlink快很多, 喜歡加QQ 四六二八二六
2樓：孫木之
youzan/bugCatcher
提供輕量化的——
專案管理：由需求方發起專案，並按照瀑布流軟體開發模型跟蹤整個專案的完成情況；
用例管理：方便新增和管理測試用例，也支援Excel、Xmind等檔案形式的用例上傳，支援用例篩選，並為專案分配需要執行的用例；
專案質量報表：報表以時間線的方式展示各個專案的質量變化；
自測質量排名：以積分排名的方式展示專案成員自測質量高低；
精細化的許可權控制：精細的角色分離（產品、開發、測試），提供精細化的許可權控制，某角色可以做什麼，不可以做什麼一目了然；
3樓：張小菊
上邊很多同學說了分級，非常正確的方法。另外，將測試用例模組化，被測產品模組化也是很好的方法，我們稱為物件導向測試方法。
在時間不夠的情況下，執行相關測試用例+高風險或高pin測試用例+特殊測試用例可以保證80%的功能完成。
4樓：alexsunmiu
寫個自動測試工具~~~crontab定時~每天下班前半小時自動開始跑，執行失敗的用例自動將現場發回到開發人員公司郵箱~~~
5樓：徐毅
基本上，問題的描述本身就已經給出了解決問題的思路。
乙個產品累積的測試用例越來越多
首先要判斷，越來越多是否正常，如果所有新增加的測試都有其價值，是應該增加的；而現有測試也都是仍有價值的，應該保留，那麼「累積了越來越多的測試用例」這件事情本身就不是問題，應該從後面兩個部分尋找解決問題的突破口。
幸運或者說不幸的是，通常這麼多用例可能並不是都有價值的，那就需要我們加強自身設計能力，減少不必要測試用例的數量。可以考慮借鑑Pairwise、Risk Based Testing等一些思想。
測試用例的數量，一定程度上也可以反應功能特性的數量，測試用例越多，說明系統的功能特性也越多，這個時候，就應該考慮一下是否系統的功能過多，它還是不是乙個簡潔、優雅的解決方案？
跑一次完全的回歸時間越來越長
我相信「回歸時間」在此就是說回歸測試的執行時長，這個時長取決於所執行的測試用例總數，以及單個測試用例的執行所需時長，加起來就是總的回歸時間。
如果，這些回歸測試都是手工執行，那麼我只有乙個建議——趕緊做自動化吧。或者就是乙個次優建議，挑選需要回歸執行的測試用例，通過減少需要執行的用例數量，來減少執行總時間。
如果，這些回歸測試都已經實現自動化，那麼我建議可以考慮檢查是否有需要重構的用例指令碼。我自己曾經親歷的乙個極端案例，某位leader聯絡我說他們有乙個很簡單的測試用例居然要執行1個多小時，調查後發現的原因是因為採取了一些沒有必要的測試手段或者說測試動作所致，經過修改過後，該測試只需要1分多鐘即可執行完畢。另外還有就是，進行自動化實現的時候，模擬了手工執行的測試動作，但這些動作卻並不適合機器自動化執行，以至於事倍功半，拖長了執行時間。
通過採取上述一些動作，多多少少應該都能夠縮短一些總回歸時間。
如何有效管理巨量測試用例
首先，是考慮「管理」，為什麼我們需要管理這些測試用例？如果我們在建立時可以遵循一些規範或約定，是否會有利於後續的管理（與或維護）工作？
或者，是否是「管理工具」阻礙了我們的管理效率，革新我們的測試用例管理理念並選擇相應的工具是否可以簡化我們的管理工作需要？例如，借用Executable Requirements等一些理念，用純文字檔案承載測試用例及指令碼，設定資料夾結構規範，並用SVN、Git等版本控制工具進行管理。
接下來，可以從「巨量」入手。可以試問自己，測試用例的顆粒度是否過於小？是否可運用資料驅動方式減少需要管理的「測試用例」（單個檔案承載同一功能或邏輯的多個測試）？
最後，是否必須由「我們自己」來管理這些測試用例？
6樓：
測試前期準備中難道沒有乙個步驟叫測試用例評審麼？
測試用例評審中的重要步驟，除了測試用例的質量、覆蓋面之外，就是測試用例裁剪呀！
7樓：高學文
對於這個問題，應該先清楚：
1.什麼節點才需要全回歸測試
2.什麼節點做到增量測試
3.測試的粒度到底是什麼,在此基礎上考慮用例的優先順序4.如果是長期專案，功能穩定再考慮自動化
5.考慮如何提高個人效率而非盲目增加測試人員
8樓：jerry zhang
如果可以建議做分析再制定策略，比如用例分布情況、執行耗時情況，找到熱點，根據2/8原則做改進，已有用例整改是有成本的，但是可以在新增用例上做好控制。。
9樓：孔慶雲
用例分級別是一方面，回歸時去除不是非常重要的用例，如果真的全部都很重要的話可以考慮分布式執行測試用例，不同機器上同時執行不同的測試用例，加快回歸的速度。
10樓：qing.yi
我們的經驗是對測試用例進行分級，一般是按重要性來分，自動化測試/回歸測試的時候根據發布需求，能夠選擇不同等級的case跑回歸
如何看待越來越多的跨界產品和思維轉變？
凱納諮詢 凱納就是做跨界戰略諮詢的，可以來簡單答下這個問題。跨界戰略，是一種跨界時代的變革性戰略，是指打破傳統邊界，通過跨界性地戰略植入 碰撞融合和創新重構，開創發展的新思維 新路徑 新格局，從而實現企業跨越式增長和突破創新。而跨界營銷依然是戰術層面的動作，其中的區別大家要了解。跨界營銷是一直以來都...
如何看待越來越多的商家將產品「娘化」，進行的二次元營銷？
非生物 因為某家公司證明了二次元能賺錢，並且是從年輕人手中賺錢，證明這些東西是有人喜歡，並且有廣大受眾的。僅此而已，大家喜歡什麼商家就會做什麼。 魔法老嫗特日日 自問自答，我將拋磚引玉。表面上來講，這是商家對於自家產品的一種二刺螈營銷方式。通過簡單的製造產品娘化形象，吸引到更多的人，以此來獲得更多的...
新版本的測試用例內容需要包括上乙個版本的內容嗎？
不知道你在做的專案有多大，也不清楚新增功能與原有專案關係是否密切，具體有多大的變動，所以沒辦法給出具體答案。從需求和設計方案看，如果要求向上相容，那麼測試必然有同樣的要求，也必然要用到之前的測試案例，最少要保證原有功能能跑通，也就是冒煙測試的這部分案例。再就要看新功能的改動有多大，與之相關的模組也需...