某公司一部分是marketing，一部分分成產品product
marketing目前是pm和客戶交流，解決客戶的痛點，及時作出反應，需要做什麼來解決客戶的痛點。
一次任務，乙個週期，大概2周，到乙個月，【主要是人天】來完成這些工作。一次任務叫做乙個cr，全稱是change request
一次任務，既有開發指定的介面，也有etl資料匯入匯出，也有編寫儲存過程來規範複雜的取數條件和處理
一次任務，如果是活動，即大促，需要部署新的更好的環境，並進行效能測試等
對於測試用例管理平台來說，不僅僅是說，檢視你對於每個專案，或者某個介面的測試用例，她更希望看到我這個cr，這次任務，你設計了多少測試用例，花費了多長時間。以此來作為測試人員的績效。
說的更多一些，已經並不是想要你完成確認，這個介面，這個系統，測試通過了，而是你做了什麼，你花了多長時間，你們的流程，你們設計了多少測試用例，回歸測試，效能測試，你測試的bug，你測試的bug誰解決了，等等一切要對我透明。
當然，日常工作，除了有新的cr, 也有內部工作， 也有問題重現，也有bug fix，也有回歸測試等等
新的cr總不能要求測試都滿足自動化的，對常用介面的自動化測試也要做的。
cr空檔期，也是要有產出的。
看了ones和testin的測試用例管理平台，也不像再在檢視其它測試用例平台上浪費時間了。
測試專案的名稱
本次的cr
本次cr對應的
測試用例設計與測試用例管理平台開發指南
測試用例的設計，是測試中每天必須面臨的乙個問題。無論是自動化測試，還是測試平台的開發，都基於測試用例而來的，而 bug，缺陷的發現，是測試用例的對比發現的。而測試用例的編寫，卻易寫難全。本場 chat 會聚焦測試用例。本場 chat 主要包含 針對一道幾乎必考測試用例設計的面試題，展開講解 調研市場...
測試用例管理
對於應用軟體測試可以參考軟體開發模式來管理測試用例。乙個應用軟體產品對應的業務規則在很長一段時間是不會改變的。我們可以根據的這個特點來管理測試用例。舉個例子 比如銀行軟體，有存款 取款 匯款幾項業務。在使用過程中往往是在進行了多個業務之後的賬戶就很容易出錯。問題1 2次存款 3次取款後，利息計算錯誤...
測試用例的管理
測試用例一般組成 功能路徑 用例編號 用例名稱 用例說明 預置條件 輸入資料 操作步驟 預期結果 實際結果 yes,no 優先順序 缺陷編號 備註一 用例命名規則 用例編號的規則 前四個字母為功能模組的前四個字拼音的第乙個字母 第5 6位代表該功能模組下第乙個子功能 最後2位用數字代表該子功能的第x...