將業務需求分解成功能需求
了解業務背景（做這個需求的目的是什麼）
業務需求:需求的大致邏輯
功能需求:為了實現業務需求，軟體應有的功能。
有的是需求文件明確寫出來的；有的是需求文件中未提及的，未提及到的則需要我們根據自身的軟體測試經驗來進行補充並想產品確認----這個過程，可以用寫思維導圖體現
測試需求:為了實現本期所有功能以及相容舊使用者使用，所進行一系列測試活動。
包含本期所有的功能需求、以及涉及到可能影響的功能模組（主要包括上下游模組和公用方法模組）、舊資料的相容、非功能性測試（相容、效能）–編寫測試子任務
積分使用
抵扣金額上限可以配置(暫定為 300,當前版本不做後台介面,寫在資料庫中),單次
積分抵扣金額上限不能大於 300 且不能大於罰息+利息總和,取兩者最小值進行折扣。
使用者使用積分抵扣金額時,若使用者當前可用積分小於可抵扣上限,則使用使用者所有可用
積分進行抵扣;若使用者當前可用積分大於可抵扣上限,則使用可抵扣積分上限進行抵扣。
積分與披索的兌換比例是由後台配置的(暫定為 1:1,當前版本不做後台介面,寫在資料庫中)
使用者使用積分抵扣金額間隔時間必須大於 14 天,即當前日期-上次抵扣成功扣除積分日期》14 天。
積分在使用者勾選了積分抵扣金額項後,還款成功時扣除使用者積分。
積分的扣除邏輯:系統確認使用者該筆還款明細為成功時才扣除積分
1、業務需求
2、功能需求
需求文件中未提及到的功能需求
使用者在14天內重複使用積分還款的提示，放在那個節點?
使用者在14天內重複使用積分還款的提示形式
使用者在14天內重複使用積分還款的提示語
還款明細頁面增加乙個減免後應還金額字段，預設怎麼顯示，勾選減免按鈕和不勾選減免按鈕顯示有什麼區別
選擇還款門店和生成還款碼頁面的還款金額的顯示
將業務需求進行補充變成測試需求
所有測試功能（需求文件明確提到和進行補充的）
積分減免直接影響的是還款模組，部分減免的金額會影響到使用者的最大可抵扣積分數
舊使用者測試–不涉及
相容測試–不涉及
需求工程 功能與需求之區別 原創
我們做軟體是需要有個較規範的流程的，即是是乙個小軟體 除非只是乙個小功能 也是需要的，如果沒有流程，隨便搞的話，就會出現很多預期不到的問題。在軟體流程前期有個需求階段，在需求階段，很多朋友常常搞不清或者容易把功能和需求給混淆了。那麼接下來我們談談功能和需求的區別，以及關係吧。下面這些定義是需求工程領...
功能測試之熟悉測試流程
1.1 步驟 1 了解業務特性 是做什麼的 2 了解使用者和角色 給誰做 3 了解組織架構圖 模組有哪些 4 了解技術棧 用了什麼技術 2.2 組織架構圖 啥你要tpshop組織架構圖？給你看前面的，不要偷偷看屁屁哦。2.1 需求評審 需求評審，簡單來說就開會，再簡單來說就是鬥地主 產品經理是地主，...
軟體架構非功能需求 可測試性
可靠性是指軟體有效且高效地進行測試的能力。有效地進行測試 指測試有深度且高質量，即通過測試可以全面檢測軟體的質量。高效地進行測試 指測試所需要的成本和勞力較少，即能夠花費較少的成本快速地檢查軟體的質量。隨著軟體體積的增大和軟體複雜程度的加深，測試的難度會越來越大，所需成本也會越來越高。因此我們要求軟...