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

1 方案設(shè)計(jì)

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

2 系統(tǒng)實(shí)現(xiàn)

2.1 系統(tǒng)說(shuō)明

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

2.2 定向越野活動(dòng)模塊

在用戶完成個(gè)人信息之后，能夠在頁(yè)面活動(dòng)管理中進(jìn)行活動(dòng)內(nèi)容的發(fā)布。在創(chuàng)建活動(dòng)過(guò)程中，必然需要填寫相關(guān)的名稱信息、活動(dòng)時(shí)間、活動(dòng)報(bào)名截止信息、活動(dòng)報(bào)名人數(shù)的限制等等內(nèi)容，此類信息屬于系統(tǒng)運(yùn)行過(guò)程中的必填項(xiàng)目，假如并沒(méi)有填寫以上就上傳項(xiàng)目，則

系統(tǒng)中會(huì)出現(xiàn)相應(yīng)的錯(cuò)誤提示。另外，活動(dòng)報(bào)名截止時(shí)間要早于活動(dòng)開(kāi)始時(shí)間，活動(dòng)開(kāi)始時(shí)間則不必一定早于系統(tǒng)當(dāng)前時(shí)間。

2.3 點(diǎn)標(biāo)生成模塊

一直以來(lái)，用戶能夠在系統(tǒng)中的頁(yè)面點(diǎn)標(biāo)管理中看到用戶提前設(shè)置好的點(diǎn)標(biāo)集；假如沒(méi)有設(shè)置點(diǎn)標(biāo)，則可以在頁(yè)面下方的添加按鈕中進(jìn)入點(diǎn)標(biāo)集添加頁(yè)面，在添加過(guò)程中根據(jù)用戶來(lái)選擇點(diǎn)標(biāo)的個(gè)人情況，在完成選擇之后能夠自動(dòng)生成序號(hào)信息，代號(hào)則是從31號(hào)開(kāi)始的點(diǎn)

標(biāo)集內(nèi)容，在點(diǎn)標(biāo)集生成之后可以刪除個(gè)別點(diǎn)標(biāo)，在完成刪除之后，序號(hào)逐步往前發(fā)展，代號(hào)則沒(méi)有改變。

2.4 二維碼掃描模塊

在活動(dòng)開(kāi)始之后，用戶能夠進(jìn)入到活動(dòng)的頁(yè)面中，在頁(yè)面中添加管理按鈕。一旦用戶需要開(kāi)展點(diǎn)標(biāo)打卡過(guò)程時(shí)，則需要點(diǎn)擊掃一掃按鈕，掃描完成打卡的同時(shí)記錄具體打卡的時(shí)間，在二維碼掃描完成之后則顯示為點(diǎn)標(biāo)代號(hào)。尤其是在活動(dòng)開(kāi)始的過(guò)程中，二維碼掃描完成以后，可以與提前設(shè)定好的點(diǎn)標(biāo)進(jìn)行對(duì)比分析，假如打卡順序并沒(méi)有根據(jù)原有的點(diǎn)標(biāo)順序，則會(huì)判定成績(jī)無(wú)效。另外，在總體打卡過(guò)程中，超過(guò)活動(dòng)時(shí)間，成績(jī)也會(huì)自動(dòng)判為無(wú)效。

3 關(guān)鍵技術(shù)運(yùn)用

3.1 配置文件

從某種意義上來(lái)說(shuō)，每一個(gè)項(xiàng)目都是運(yùn)用了pages.json文件進(jìn)行配置，其中涉及到了項(xiàng)目中的各個(gè)頁(yè)面路徑、樣式、不同的主題顏色、背景顏色、各種資源的圖片等等。換句話而言，配置文件幾乎相當(dāng)于是應(yīng)用過(guò)程中的核心內(nèi)容，不同的配置內(nèi)容都是在此文件中進(jìn)行。

3.2 組件復(fù)用設(shè)計(jì)

在開(kāi)發(fā)中，針對(duì)通用模塊所創(chuàng)設(shè)的單獨(dú)組件，不同方式下的內(nèi)容則是運(yùn)用傳入?yún)?shù)的模式或者是設(shè)計(jì)插槽（slot）展開(kāi)處置。

（1）頂部導(dǎo)航復(fù)用

一直以來(lái)，頂部導(dǎo)航屬于一種通用的模塊，數(shù)據(jù)展示信息、鏈接等等各不相同，在此過(guò)程中能夠?qū)⑵湓O(shè)計(jì)成為一個(gè)組件，在運(yùn)用過(guò)程中能夠達(dá)成不同參數(shù)的運(yùn)輸。在各個(gè)模塊中的頂部導(dǎo)航欄，具體來(lái)說(shuō)樣式存在一定的差異性、部分導(dǎo)航項(xiàng)目也存在一定的差異性，鏈接也各不相同。在此背景下，將導(dǎo)航欄進(jìn)行抽取，最終形成頂部導(dǎo)航組件部分，真正的達(dá)成代碼復(fù)用之目的。

（2）內(nèi)容列表復(fù)用

相對(duì)來(lái)說(shuō)，內(nèi)容展示列表屬于通用模塊，在數(shù)據(jù)展示過(guò)程中的鏈接也并不相同，能夠形成完整的組件，在各個(gè)不同的模塊的內(nèi)容中，由于樣式、列表內(nèi)容不同，鏈接也并不相同，在此背景下，需要將內(nèi)容列表項(xiàng)進(jìn)行優(yōu)化調(diào)整，最終構(gòu)成列表項(xiàng)組件。

3.3 自適應(yīng)設(shè)備屏幕

Uhelp應(yīng)用可以以微信小程序方式訪問(wèn)，同時(shí)也可以以手機(jī)網(wǎng)站訪問(wèn)，但是這兩種訪問(wèn)方式訪問(wèn)相同內(nèi)容呈現(xiàn)出的界面是不一樣，在不同平臺(tái)中所體現(xiàn)出的效果也各不相同，因此需要德州云軟物聯(lián)科技有限公司在開(kāi)發(fā)過(guò)程中進(jìn)行優(yōu)化調(diào)整。為了完成屏幕調(diào)整，最為常用的方式往往是平臺(tái)識(shí)別，相對(duì)來(lái)說(shuō)不同平臺(tái)所運(yùn)用的方式也各不相同。

3.4 Axios二次封裝

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

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

4 系統(tǒng)測(cè)試

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

結(jié)語(yǔ)：基于相關(guān)測(cè)試結(jié)構(gòu)，本系統(tǒng)幾乎完成了系統(tǒng)原有的功能需求。在此系統(tǒng)中，各個(gè)功能的模塊可以有效的執(zhí)行，同時(shí)在執(zhí)行過(guò)程中并沒(méi)有呈現(xiàn)出明顯錯(cuò)誤。在系統(tǒng)運(yùn)行過(guò)程中，各類情況良好、頁(yè)面的響應(yīng)速度相對(duì)十分快速，保障了系統(tǒng)運(yùn)用的安全性?？偠灾?，本系統(tǒng)真正展現(xiàn)出了基本的功能需求，系統(tǒng)也可以保障流暢運(yùn)行，順利通過(guò)了系統(tǒng)測(cè)試。