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