伴隨著互聯網信息技術的高速發(fā)展以及手持設備逐步廣泛化運用，出現了很多移動運用，涵蓋了小程序、APP、H5網站等等，體現了多元化發(fā)展。在此過程中，小程序的類型增多，數量也獲得了高速增長，尤其是微信用戶基數非常大，微信小程序應用數量持續(xù)增加。

1 方案設計

隨著社會的不斷進步，微信小程序被廣泛的運用到各行各業(yè)中。在此過程中，框架設計所創(chuàng)設的標簽語言能夠融合出基礎組件部門、事件系統內容等，創(chuàng)設出符合頁面需求的結構體。根據系統業(yè)務流程，滿足功能需求：（1）點標打卡；（2）個人信息管理；（3）定向越野規(guī)則分析。

2 系統實現

2.1 系統說明

德州云軟物聯科技有限公司開發(fā)的系統中，主要是運用了JAVAWebServlet技術來達成所需功能；相對來說，JAVAWebServlet與微信小程序開展數據交互非常方便，小程序端能夠在JS中直接運用，獲得相應的數據信息。另外，可以最大化降低后臺中對響應性能方面的影響，大部分的邏輯處理往往是在小程序端JS中開展，而后臺往往只是輔助數據信息的獲取。本系統數據主要是位于阿里云服務器中，Java在本地開展關于云數據庫的連接與操作過程中往往都離不開JDBC，本地數據也是運用了tomcat進行接收。

2.2 定向越野活動模塊

在用戶完成個人信息之后，能夠在頁面活動管理中進行活動內容的發(fā)布。在創(chuàng)建活動過程中，必然需要填寫相關的名稱信息、活動時間、活動報名截止信息、活動報名人數的限制等等內容，此類信息屬于系統運行過程中的必填項目，假如并沒有填寫以上就上傳項目，則

系統中會出現相應的錯誤提示。另外，活動報名截止時間要早于活動開始時間，活動開始時間則不必一定早于系統當前時間。

2.3 點標生成模塊

一直以來，用戶能夠在系統中的頁面點標管理中看到用戶提前設置好的點標集；假如沒有設置點標，則可以在頁面下方的添加按鈕中進入點標集添加頁面，在添加過程中根據用戶來選擇點標的個人情況，在完成選擇之后能夠自動生成序號信息，代號則是從31號開始的點

標集內容，在點標集生成之后可以刪除個別點標，在完成刪除之后，序號逐步往前發(fā)展，代號則沒有改變。

2.4 二維碼掃描模塊

在活動開始之后，用戶能夠進入到活動的頁面中，在頁面中添加管理按鈕。一旦用戶需要開展點標打卡過程時，則需要點擊掃一掃按鈕，掃描完成打卡的同時記錄具體打卡的時間，在二維碼掃描完成之后則顯示為點標代號。尤其是在活動開始的過程中，二維碼掃描完成以后，可以與提前設定好的點標進行對比分析，假如打卡順序并沒有根據原有的點標順序，則會判定成績無效。另外，在總體打卡過程中，超過活動時間，成績也會自動判為無效。

3 關鍵技術運用

3.1 配置文件

從某種意義上來說，每一個項目都是運用了pages.json文件進行配置，其中涉及到了項目中的各個頁面路徑、樣式、不同的主題顏色、背景顏色、各種資源的圖片等等。換句話而言，配置文件幾乎相當于是應用過程中的核心內容，不同的配置內容都是在此文件中進行。

3.2 組件復用設計

在開發(fā)中，針對通用模塊所創(chuàng)設的單獨組件，不同方式下的內容則是運用傳入參數的模式或者是設計插槽（slot）展開處置。

（1）頂部導航復用

一直以來，頂部導航屬于一種通用的模塊，數據展示信息、鏈接等等各不相同，在此過程中能夠將其設計成為一個組件，在運用過程中能夠達成不同參數的運輸。在各個模塊中的頂部導航欄，具體來說樣式存在一定的差異性、部分導航項目也存在一定的差異性，鏈接也各不相同。在此背景下，將導航欄進行抽取，最終形成頂部導航組件部分，真正的達成代碼復用之目的。

（2）內容列表復用

相對來說，內容展示列表屬于通用模塊，在數據展示過程中的鏈接也并不相同，能夠形成完整的組件，在各個不同的模塊的內容中，由于樣式、列表內容不同，鏈接也并不相同，在此背景下，需要將內容列表項進行優(yōu)化調整，最終構成列表項組件。

3.3 自適應設備屏幕

Uhelp應用可以以微信小程序方式訪問，同時也可以以手機網站訪問，但是這兩種訪問方式訪問相同內容呈現出的界面是不一樣，在不同平臺中所體現出的效果也各不相同，因此需要德州云軟物聯科技有限公司在開發(fā)過程中進行優(yōu)化調整。為了完成屏幕調整，最為常用的方式往往是平臺識別，相對來說不同平臺所運用的方式也各不相同。

3.4 Axios二次封裝

UHelp應用主要是采用了Axios與服務器端口完成通信功能。Axios本身屬于根據Promise瀏覽器以及Promise。本質上來說，此方面屬于原生XHR的一種封裝方式，其本身也屬于Promise的一種完成模塊，幾乎符合ES最新方式，存在如下的幾個特征：

（1）從瀏覽器中創(chuàng)建XMLHttpRequests；（2）從node.js創(chuàng)建http請求；（3）支持PromiseAPI；（4）攔截請求和響應；（5）轉換請求數據和響應數據；（6）取消請求；（7）自動轉換JSON數據；（8）客戶端支持防御XSRF。

4 系統測試

在軟件正式進入生產運營階段之前，系統測試的主要目標則是最大程度發(fā)現軟件運行中可能存在的問題。通常而言，軟件測試存在黑盒測試與白盒測試兩種測試方法。在黑盒測試過程中，通常是將程序視為一個黑盒，不考慮程序內部的結構與具體處理方式，換句話而言，黑盒測試是在程序界面開展測試，只是檢測程序功能是否滿足規(guī)范需求。而白盒測試則與黑盒測試截然相反，其將程序視為透明的盒子，測試者完全清楚程序結構與處理方式，該方法是基于程序內部邏輯的背景下測試，在程序測試過程中，往往是根據預訂路徑來進行執(zhí)行。在該系統中，測試主要是根據黑盒測試法來進行。

結語：基于相關測試結構，本系統幾乎完成了系統原有的功能需求。在此系統中，各個功能的模塊可以有效的執(zhí)行，同時在執(zhí)行過程中并沒有呈現出明顯錯誤。在系統運行過程中，各類情況良好、頁面的響應速度相對十分快速，保障了系統運用的安全性。總而言之，本系統真正展現出了基本的功能需求，系統也可以保障流暢運行，順利通過了系統測試。