【正文】 指定、刪除采購員、商品的打標簽。 應用場景：采購人員實時更新商品的狀況如商品的上架下架缺貨，從而及時更新微信前端的數(shù)據(jù)變化，以免客戶下單的水果采不到；及時更新水果的價格；指定單個商品采購人員；當采購人員在市場上逛是可以添加商品的市場行情 這樣有利于第二天的采購；增加商品的屬性，例如紅提，產(chǎn)地：湖北、湖南、河北。其中紅提為商品名稱，產(chǎn)地為商品屬性名稱，湖北、湖南、河北為商品屬性值名稱。 SKU 是指同一商品不同屬性值的排列組合，同時設置 SKU 的價格等信息；商品打標簽是指：熱銷、推薦、特價等類型來設置商品的前臺展示的效果；商品詳情編輯主要是針對普通商品和預售商品； 按日期查找采購單、采購單按量降序、根據(jù)采購人員不同或得不同的采購單、采購小票的上傳、已上傳采購小票的查找 應用場景：采購人員從采購果行采購完水果后對采購小票的數(shù)據(jù)上傳，有利 于跟果行老板進行按月結算賬單。對與采購單數(shù)據(jù)進行按降序排列，默認排列；對采購單數(shù)據(jù)按照人員排列； 市場人員調查行情是實時把市場重要消息推送的微信端 B、 C 端用戶 按照日期進行訂單查詢、訂單詳情查詢、訂單補損登記 使用場景：配送人員可以按照日期查詢配送的訂單、也可根據(jù)訂單號查詢詳情訂單、其中訂單詳情中的商品可以進行補損登記，即當水果果品不好的時候進行果品的補損等級；補損等級主要是對需要補損的商品進行拍照文字描述等從而方便配送人員到達水果店時店鋪老板進行驗貨處理； 果行情查看 使用場景：這里的水果行情查看主要是為了方便采購人員實時掌控市場動態(tài)，以免采購出了高價或者果品差的貨物，從而造成不必要的損失 根據(jù)不同類型查看不同類型的報損，例如：新報損、已處理的報損、以完成的報損、訂單詳情查看、報損處理 使用場景：此功能是跟訂單查詢中的訂單報損進行關聯(lián)起來，當訂單中的訂單報損提交處理時在訂單報損中進行查看，報損又分為：全部，新報損、已處理、已完成這些，其中新報損中的補損詳情可以進行處理。 三、 系統(tǒng) 功能分析 整個 APP 分為 7 大模塊， 店鋪管理、商品管理、消息推送、采購小 票管理、訂單查詢、查詢行情、報損處理 其中商鋪地圖模塊主要針對的使用對象為市場調查人員和送貨人員 。商品管理模塊主要針對的使用對象為商品采購人員和商品維護人員；采購單管理模塊主要針對的使用對象為采購人員；市場動態(tài)模塊主要針對的使用對象為采購人員和商品維護人員；消息推送主要的使用對象是采購人員。 模塊流程圖： ： ： 第四章 系統(tǒng)總體設計 系統(tǒng)功能設計 功能總體流程圖如下： 登錄：點擊登錄、記住密碼、環(huán)境切換、版本檢查 登錄：提交表單，用戶名、密碼 環(huán)境切換：正式環(huán)境、測試環(huán)境、內部環(huán)境 版本檢測，作用用于版本更新 店鋪管理： 地圖標記 /查看：當用戶在地圖沒有被標記時，可以進行標記；當用戶已經(jīng)被標記時可以進行查看；地圖上的功能地圖覆蓋物、實時路況、長按地圖標記（點擊地圖標記可以移動重新標記） 新增店鋪：新增一個店鋪 店鋪表單：店鋪名稱、地址、聯(lián)系人、等級 、備注 返回的表單是 ：返回碼 、 返回信息 地圖標記表單：店鋪 ID、經(jīng)度、緯度 店鋪詳情表單： 商戶 ID、商戶名稱、地址、聯(lián)系人、電話、訂單次數(shù)、店鋪等級、備注 訪問記錄表單： 訪問人員、訪問時間、訪問內容 基本信息編輯表單： 商戶 ID、商戶名稱、地址、聯(lián)系人、電話、訂單次數(shù)、店鋪等級、備注 商品管理： 新加商品表單： 圖片 PIC、類目、狀態(tài)（上架、下架、缺貨）、計費方式（按件計費、按重計費）、商品類型（普通商品、預售商品）、商品名稱、查詢標簽、副標題、商品單價、銷售規(guī)格、每件約重、商品序號、商品詳情 (其中預 售商品多了三個字段：開始時間、結束時間、送貨時間 ) 商品詳情基本信息表單： 圖片 PIC、類目、狀態(tài)（上架、下架、缺貨）、計費方式（按件計費、按重計費）、商品類型（普通商品、預售商品）、商品名稱、查詢標簽、副標題、商品單價、銷售規(guī)格、每件約重、商品序號、商品詳情 (其中預售商品多了三個字段：開始時間、結束時間、送貨時間 ) 商品屬性 表單 ：屬性 ID、屬性名稱、排序、屬性值（屬性 id,類目 id、屬性名稱、排序） 商品 SKU 屬性 表單 ：類目 ID、創(chuàng)建時間、價格、屬性數(shù)組、屬性值、屬性數(shù)值名稱、數(shù)量、備注、 skuid、狀態(tài) 、重量 指導供應商： 供應商名稱、序號 添加市場行情 ：商品名稱、時間、價格、果行名稱、信息等級、備注 添加商品屬性表單： 屬性序號、名稱、屬性值序號、屬性值、屬性描述 添加 SKU 表單： 名稱、單價、數(shù)量、重量、備注、狀態(tài) 修改 SKU 表單： sku、單價、重量、庫存、重量、商品狀態(tài)、描述 新增 SKU 表單： 商品屬性、價格、重量、庫存、商品狀態(tài)、描述 指定采購員： 采購員名稱 id 訂單管理： 訂單列表： 訂單 id、名稱、時間 訂單詳情： 訂單 ID、時間、送達時間、配送時間、支付方式、商品總價、物流信息（送車號 聯(lián)系人、 電話）、商品清單（名稱、價格、數(shù)量）、客戶信息（店鋪名稱、果批名稱、電話） 物流信息產(chǎn)看表單： 運車號、聯(lián)系人 商品補損登記： 商品標題、添加圖片、損耗情況說明 報損登記： 報損訂單詳情表單： 訂單 ID、下單時間、報損時間、報損原因、貨號、圖片、處理狀態(tài)、處理方式、處理人、處理說明、店鋪、聯(lián)系電話 根據(jù)分類查詢不同類訂單： 全部、新報損、已處理、已完成 采購小票管理： 采購小票錄入表單： 名稱、參考價、日期、編號、供應商、單價、總價、數(shù)量、重量、行費、押金、計價方式、付款狀態(tài) 采購小票查看表單： 名稱、參 考價、日期、編號、供應商、單價、總價、數(shù)量、重量、行費、押金、計價方式、付款狀態(tài) 行情查看： 行情查看表單：名稱、副標題、價格、來源、時間 消息推送： 消息推送表單：標題、圖片 PIC、跳轉連接、用戶 ID、內容 數(shù)據(jù)庫設計 采購小票管理模塊，用到了本地數(shù)據(jù)庫。原因是采購小票是按人員分組，和按照排序進行所以用到了本地數(shù)據(jù)庫，其中主要用了到兩個表： 采購單（ 名稱、參考價、日期、編號、供應商、單價、總價、數(shù)量、重量、行費、押金、計價方式、付款狀態(tài) ） 商鋪（店鋪主碼，聯(lián)系人，創(chuàng)建時間，查詢標 簽，名稱，備注，狀態(tài)，電話） ER 圖如下： 從而產(chǎn)出了一個管理表 , 管理表（ _ID,店鋪 ID，貨號，查詢標簽） 第五章 詳細設計與實現(xiàn) 公共類 設計 主界面實現(xiàn)：整體是線性布局，每個模塊分別是一個 Relativelayout,每個Relativelayout 實現(xiàn) Ontouchlistener 接口，界面代碼如下： 運行界面如下： 數(shù)據(jù)庫處理 與訪問 數(shù)據(jù)庫有兩個類： 、 為了避免多個線程同時操作多個數(shù)據(jù)庫實例的問題，則 SQLITEOPENTHELPER 用到了單例模式，同時創(chuàng)建 sqliteopenhelper 時是放到全局的 application 中。具體代碼如下 類如下： 類如下： 店鋪管理界面： 具體實現(xiàn)部分代碼如下： 以下是店鋪詳情界面、店鋪編輯界面、新建訪問記錄： 部分關鍵代碼如下： 商品管理 商品列表界面、商品新增界面、商品搜索界面、商品詳情頁 重要部分代碼如下： 消息推送 消息的提交 拍照的核心代碼如下： 彩票小票管理 部分功能界面如下： 采購小票管理、采購小票錄入、按日期查找 核心代碼如下： 訂單查詢 訂單詳情頁如下： 核心代碼如下： 查看行情 核心代 碼如下： 報損處理 核心代碼如下： 第六章 系統(tǒng)測試 系統(tǒng)測試方法 當進行 APP 測試時，我一般把 APP 的測試分為以下類型： （ 1）接口協(xié)議測試 （ 2）易用性測試 （ 3）功能測試 （ 4）終端適配測試 （ 5）性能測試 （ 6）網(wǎng)絡測試 在 APP 客戶端開發(fā)設計時，一般服務端會提供相應的接口協(xié)議文檔，接口協(xié)議文檔的質量，決定了 APP 的開發(fā)進度。此部分的測試，應首先檢測接口的完整性， 根 據(jù)APP 需求，檢查是否所有數(shù)據(jù)都有相應的接口返回；其次正確性驗證，驗證返回的接口信息是否正確，提示代碼是否符合要求；第三：可采用 Postman 等工具，對設計的測試用例進行測試。 易用性測試可分為 UI原型和高保正圖檢測和 APP 測試。 UI 原型和高保真圖可通過評審會議的形式檢測； APP 易用性是 APP開發(fā)完成之后，可發(fā)布 Beta 版給公司內部員工或客戶，并收集使用者的反饋信息。 APP 的開發(fā)模型一般為敏捷開發(fā)模型，所以測試也應是敏捷測試。測試過程我設計為三個階段（ 1） 冒煙測試（ 2）探測性測試 用例（ 3）回歸測試； 首先對每個提交的功能模塊快速進行冒煙測試，到可組合成完整功能模塊時，進行探測性測試，當所有功能模塊完成之后，進行相應的系統(tǒng)測試。若是運營級的產(chǎn) 品，可適當利用 Robotium等自動化工具實現(xiàn)功能自動化測試。 因為手機操作系統(tǒng)類型，版本較多，生產(chǎn)廠家也五花八門的，所以對手機 APP進行終端適配測試決對是個體力活。對這部分的應試，應選擇一定的策略，我一般分內部測試、云測試和用戶測試三方面進行，具體如下： 手機 APP 對平臺的性能要求較嚴格，若存在性能問題，可能會出現(xiàn)嚴重的 Crash 問題，因此，對 APP 進行性能檢測試很有必要的。進行性能測試時，我們 可分五個階段進行（ 1） Monkey 壓力測試，（ 2）手機內存泄漏檢測，（ 3）手機 CPU 使用率檢測，（ 4）手機緩存檢測，（ 5）服務器性能測試。 此部分測試，主要目的是發(fā)現(xiàn)各業(yè)務模塊的業(yè)務流量，當添加第三方管理模塊時，是否大量增加流量，可通過 Sniffer+虛擬機工具進行檢測。 輸入?yún)?shù)測試：針對輸入的參數(shù)進行測試，也 可以說是假定接口參數(shù)的不正確性進行的測試，確保接口對任意類型的輸入都做了相應的處理：輸入?yún)?shù)合法，輸入?yún)?shù)不合法，輸入?yún)?shù)為空，輸入?yún)?shù)為 null，輸入?yún)?shù)超長； 功能測試：接口是否滿足了所提供的功能，相當于是正常情況測試，如果一個接口功能復雜時推薦對接口用例進行結構劃分，這樣子用例具有更好的可讀性和維護性。 邏輯測試：邏輯測試嚴格講應為單元測試，單元測試應保持內部邏輯的正確性，可單元測試和接口測試界限并不是那么清楚，所以我們也可以從給出的設計文檔中考慮內部邏輯錯誤的分支情況和異常； 異常情況測試： 接口實現(xiàn)是否對異常情況都進行了處理，接口輸入?yún)?shù)雖然合法，但是在接口實現(xiàn)中，也會出現(xiàn)異常，因為內部的異常不一定是輸入的數(shù)據(jù)造成的，而有可能是其他邏輯造成的，程序需要對任何的異常都進行處理。 測試過程 其中部分 BUG 列表如下 整個 所有客戶端 BUG 解決問題反饋：