1樓：Eye
研發需要跑冒煙測試用例，也就是保證正流程沒問題，才能提交給測試進行接下來的測試，不然，總不能一測乙個致命bug，一測乙個嚴重bug吧
2樓：一座山頭一首曲兒
這裡是程式的單元測試嗎？
如果不是，那這裡的測試用例應該是研發的內測用例。
相對測試使用的測試用例相對粒度要大很多。只是基礎和核心的功能測試通過之後，即可以提給測試開始測試，而測試還有自己的測試用例，要細很多測試的工作量也要大很多。
但是如果這個是測試的系統測試用例給開發來測，那這個工期不僅拖得比較長，而且收效也很小。
或者是你們之前沒有測試，老闆就是想找個測試學一下怎麼測，然後再把測試開了。。。。（腹黑，嘿嘿嘿）
3樓：
可能出現這種情況，比如測試驅動開發（TTD），不過測試不僅僅是功能測試。
效能測試呢，安全測試呢，相容性測試呢
即便是功能測試，也不是全寫在測試案例裡，還有探索性測試（在對專案十分熟悉的基礎之上）
對我而言，有這樣的規定是好事，節省了大量的時間，讓我可以在感興趣的方向上發揮。
關於新手如何編寫測試用例？
王小明 編寫測試用例的常用方法 等價類劃分法 等價類是輸入的集合，比如在註冊時，手機號規定為系統內不存在的手機號，那麼所有已存在的手機號是乙個等價類，所有不存在的手機號是另乙個等價類。在每個等價類中選取一定數目的值作為代表。等價類分為有效等價類和無效等價類，輸入符合條件的值對功能進行檢驗，輸入無效等...
UAT測試用例由甲方編寫還是乙方？
Jack 一定是甲方編寫，因為要組織使用者部門參與，一方不了解甲方公司文化氛圍，可能會導致uat目標發生重大偏差。現在我了解到的uat分兩種，一種真的就是使用者體驗測試，一種就是純粹的測試，黑盒測試。第一種，很簡單，產品很穩定，體驗體驗，提提意見就行。第二種，產品質量不穩定，需要有業務經驗的人來全程...
有什麼缺陷跟蹤 測試用例管理的平台嗎？
BugKing 今天看到乙個開源專案叫 MeterSphere 開源持續測試平台 https 看起來還挺不錯的。按照 Wilson 提到的幾點對比了下 1.用例匯入匯出 批量 用例字段自定義 2.開放介面，方便其他系統對接。3.外掛程式或者其他方式方便二次開發和定製，主要是滿足上游與專案管理 需求管...