公路工程外業(yè)調(diào)查APP自動化測試方法

摘 "要：四川省交通勘察設計研究院有限公司自研的公路工程外業(yè)調(diào)查APP顛覆傳統(tǒng)的公路外業(yè)調(diào)查方式，以數(shù)據(jù)電子查看、填報、傳輸和存儲為手段為勘察設計人員提質(zhì)增效。該APP采用敏捷型開發(fā)模式，通過頻繁的版本迭代滿足用戶的使用需求。手動進行回歸測試會耗費大量的時間和人力，因此，發(fā)明一種適用于該外業(yè)調(diào)查APP的自動化測試方法。該方法以Python為編程語言，Pytest為框架，根據(jù)該APP的特點進行自動化運行流程的編寫和斷言，采用Allure輸出測試報告和Jenkins進行自動化集成。最終有效地提高該APP的回歸測試效率，節(jié)省成本。

關鍵詞：敏捷型開發(fā)；自動化測試技術；用例運行流程；斷言；外業(yè)調(diào)查App

中圖分類號：TP274 " " "文獻標志碼：A " " " " "文章編號：2095-2945（2025）10-0138-04

Abstract： The self-developed Highway Engineering Field Survey APP by Sichuan Communication Surveyingamp;Design Institute Co.，Ltd. has revolutionized the traditional highway field survey methods by enhancing efficiency and quality for survey and design personnel through digital data viewing， reporting， transmission， and storage. The APP follows an agile development model， with frequent version iterations to meet user requirements. Manual regression testing consumes significant time and manpower. Therefore， an automated testing method suitable for this field survey APP has been invented. This method uses Python as the programming language and Pytest as the framework. It writes and asserts the automated running process according to the characteristics of the APP. It uses Allure to output test reports and Jenkins for automated integration. In the end， the regression testing efficiency of the APP was effectively improved and costs were saved.

Keywords： agile development; automated testing technology; use case execution process; assertion; field survey APP

四川省交通勘察設計研究院有限公司自主研發(fā)，運用于公路工程的外業(yè)調(diào)查APP借助互聯(lián)網(wǎng)有效地幫助了勘察設計人員采集、查看、共享和存儲外業(yè)數(shù)據(jù)，極大地為外業(yè)工作提質(zhì)增效。

取得這樣明顯的效果，得益于外業(yè)系統(tǒng)以用戶需求為導向的開發(fā)模式。每次用戶使用外業(yè)調(diào)查APP進行野外外業(yè)勘測時，開發(fā)團隊都會派遣一名技術支持人員到現(xiàn)場指導用戶，搜集一線用戶的使用需求和習慣。外業(yè)調(diào)查APP建立有專門的技術支持團隊，該團隊會利用互聯(lián)網(wǎng)及時跟進用戶問題和需求。該APP以敏捷型開發(fā)為基本模型，會根據(jù)用戶需求進行頻繁的修改和更新。

1 "傳統(tǒng)回歸測試存在的問題

在開發(fā)完新功能之后，測試人員會對APP進行測試。測試分為對新功能的功能測試和原有功能的回歸測試。

功能測試檢查新功能是否能按照用戶需求和設計的要求正常運行，有無Bug?；貧w測試是檢測引入了新的功能后，原有功能是否受到了影響。傳統(tǒng)回歸測試是通過手動測試對原有主要功能進行功能性驗證，但若采用手動測試，對外業(yè)調(diào)查系統(tǒng)進行回歸測試存在2方面的問題。

第一，外業(yè)調(diào)查APP涉及的功能繁多。每次采用手動測試將耗費大量的時間及人力。

第二，采用手動測試的方式效率低，無法保證產(chǎn)品按時上線供用戶使用。涉及頻繁的回歸測試也讓測試人員陷入了重復單一的勞動中。

針對外業(yè)調(diào)查APP敏捷型開發(fā)模式的特點及傳統(tǒng)回歸測試存在的弊端，需研發(fā)出一套針對外業(yè)調(diào)查系統(tǒng)進行回歸測試的自動化測試方法。

2 "自動化測試的必要性

自動化測試擁有自動執(zhí)行，操作自動化、標準化、高效化，報告自動化輸出等優(yōu)勢。節(jié)省了人力及時間成本，對測試敏捷型開發(fā)模式的APP尤其友好。

外業(yè)調(diào)查APP適合使用自動化測試。

3 "測試技術的使用

3.1 "運用Jenkins實現(xiàn)自動化集成

基于外業(yè)調(diào)查系統(tǒng)頻繁更新的特點，要求開發(fā)者一旦提交正式代碼，APP就能自動更新進行回歸測試。并且為保證APP能夠穩(wěn)定運行，要求外業(yè)調(diào)查APP每周進行2次額外的回歸測試。

為保證每周回歸測試能夠準時、順利、自動地進行，將Jenkins自動集成工具安裝于測試機。設置時輸入啟動測試的代碼，將執(zhí)行時間設置為每周二凌晨十二點和每周四凌晨十二點。將Jenkins與外業(yè)調(diào)查APP的正式代碼倉庫相關聯(lián)，一旦代碼倉庫中的代碼有變化，Jenkins將自動調(diào)用啟動測試代碼的命令，進行自動化測試。最后，將自動生成測試報告的Allure插件下載到Jenkins，并進行測試報告生成相關的設置。

通過上述操作，將外業(yè)調(diào)查APP的測試代碼進行了自動化集成。一旦代碼倉庫有變化或到每周二或每周四凌晨十二點整，測試機會自動運行測試用例，進行外業(yè)調(diào)查APP的自動化測試。測試完成后，Jenkins自動生成測試報告，以郵件的形式發(fā)送給項目負責人，相關測試人員和相關開發(fā)者。

3.2 "使用Pytest搭建測試框架

Pytest以其靈活性，強大的功能備受青睞。

Pytest的靈活性：不同于Unitest必須將前置后置語句放置于Python模塊文件所有用例的前后，Pytest框架提供了靈活的夾具，以全局或局部的Conftest文件進行統(tǒng)一管理。只要在自定義方法函數(shù)上方加上@pytest.fixture（）裝飾器，那么驅(qū)動方法driver就可以存放在conftest文件當中，并且在用例中進行使用。在@pytest.fixture（）裝飾器的括號中加入驅(qū)動方法driver的作用范圍，@scope=module或@scope=session，那么驅(qū)動器就會根據(jù)設置的范圍自動管理運行的代碼。例如測試外業(yè)系統(tǒng)的“調(diào)查信息的新增”完成后，需重新啟動一次APP進行調(diào)查信息的編輯，這時設置夾具@scope=module。調(diào)查信息新增測試完成之后，能夠重啟外業(yè)調(diào)查APP進行調(diào)查信息的編輯測試。以此來降低代碼之間的耦合性，提高測試用例的穩(wěn)定性。

Pytest強大的功能：外業(yè)調(diào)查APP在不同的手機之間可能會出現(xiàn)不同的問題，因此在測試時需同一時間連接多個不同的手機進行并發(fā)兼容性測試。由于Python語言提供了各種強大的庫，并且Pytest提供了靈活的fixture，使得并發(fā)測試成為了可能。

利用Pytest的鉤子函數(shù)pytest_adoption分別讀取設備的信息并運用到測試驅(qū)動器Appium當中，利用Python提供的庫multiprocessing讓Appium以多個進程運行，實現(xiàn)同時在多個設備上進行外業(yè)調(diào)查APP的并發(fā)兼容性測試。

3.3 "使用Appium作為測試工具

在進行外業(yè)調(diào)查APP自動化測試前，比較了3種用于該APP的自動化測試工具，分別是Airtest、Monkeyrunner與Appium。

Airtest：盡管Airtest提供了較強的兼容性，能夠在Android平臺和iOS平臺上同時運行，并且提供了圖像識別功能[1]，但經(jīng)過實踐，發(fā)現(xiàn)Airtest定位元素的效率很低，通常需要7～8 s，無法滿足外業(yè)調(diào)查App快速回歸測試的需求。

Monkeyrunner：Monkeyrunner提供了直接的API進行多機并行測試[2]，使用Python進行腳本編寫。但與Appium相比，其執(zhí)行速度依然較慢，尤其是在處理復雜操作時，并且相比于Appium，缺少一些更高級的功能和更廣泛的社區(qū)支持。

Appium：經(jīng)過實踐測試，Appium的執(zhí)行速度最快，單個操作的執(zhí)行速度能夠控制在1.5 s以內(nèi)，滿足外業(yè)調(diào)查APP快速進行回歸測試的要求。

并且Appium同時支持Android和iOS平臺，能夠?qū)Π惭b于Android或iOS平臺的外業(yè)調(diào)查APP的手機分別進行測試。

鑒于Appium強大的運行效率、兼容性和可彌補的缺點，外業(yè)調(diào)查APP采用Appium作為測試工具。

4 "自動化測試用例運行流程及斷言

外業(yè)調(diào)查APP主要用于外業(yè)勘測數(shù)據(jù)的采集，自動化測試用例的編寫針對采集數(shù)據(jù)的3種方式，即現(xiàn)場快照、標記點、調(diào)查表單。

4.1 "現(xiàn)場快照的新增

現(xiàn)場快照作為外業(yè)調(diào)查APP信息采集的方式之一，用于對現(xiàn)場點位情況進行快速記錄。

測試用例運行流程首先以點擊地圖界面，新增現(xiàn)場快照圖標開始。當進入現(xiàn)場快照新增頁面時，斷言頁面頂部是否有“現(xiàn)場快照”的字樣，確認是否已進入現(xiàn)場快照的新增頁。然后斷言進入的外業(yè)調(diào)查項目是否為演示項目。

默認定位方式為“我的位置”。選擇關聯(lián)路線為K線，斷言路線版本、對應樁號、中線左右側和距中線距離是否與預期結果相符；斷言行政歸屬、鄉(xiāng)鎮(zhèn)街道、位置信息是否與測試點的相關信息相符。這時，切換中線左右側，斷言能否切換成功。

改變關聯(lián)路線為K1線，斷言路線版本、對應樁號、中線左右側和距中線距離是否改變且是否符合預期。

改變定位方式為地圖選點，使用地圖選點位置查詢功能，輸入四川省樂山市井研縣，定位到該位置。不改變關聯(lián)的路線，斷言對應樁號、中線左右側、與中線距離、行政歸屬、鄉(xiāng)鎮(zhèn)街道和位置信息是否改變且與預期結果相符。

現(xiàn)場快照中的附件信息主要是音視頻數(shù)據(jù)的采集記錄。測試附件中的數(shù)據(jù)主要是測試其增刪改查操作的結果是否符合預期。

點擊“拍照”功能，拍照，使用照片，這時會進入照片編輯頁面。分別操作“編輯涂鴉”，添加“箭頭”，“裁剪”，添加“文字”，并“保存”。斷言附件中是否有該照片記錄。若有，證明操作流程正常；若無，證明操作流程有誤。這時在斷言附件中是否有該照片記錄時添加異常處理，若流程異常導致未發(fā)現(xiàn)該條照片記錄，則該條用例失敗，測試用例繼續(xù)進行。

測試“連拍”功能。連拍2張照片并點擊“保存”，斷言附件中是否有該2張照片的記錄，選擇拍攝方向分別為“前進方向”和“后退方向”。并斷言選擇是否符合預期結果。

測試在本地手機“添加照片”功能。從手機相冊中選擇2張照片進行編輯后上傳，斷言附件中是否有這2張照片的信息，若有，選擇拍攝方向分別為“路線左側”，“路線右側”，斷言其拍攝方向是否符合預期。

刪除連拍中的第二張照片和從本地選擇的第一張照片。斷言，若在附件中無法定位到這2張照片的信息，則說明刪除成功。

分別從手機本地選擇視頻，錄制視頻，錄音。斷言附件中是否有相關的數(shù)據(jù)信息，若有，證明添加成功。

添加涂鴉，在涂鴉中添加照片、文本、箭頭和方框和手寫圖案，并保存。斷言附件中是否有涂鴉信息。經(jīng)過多次測試，用例運行到涂鴉，很容易造成崩潰閃退。因此，用例設計為涂鴉功能報錯，則測試程序直接終止，不再往下運行。若斷言到附件中有涂鴉信息，則用例通過。

所有信息添加完成后，點擊“上傳”按鈕對現(xiàn)場快照信息進行上傳。

4.2 "現(xiàn)場快照的上傳及查看

現(xiàn)場快照的上傳斷言是通過“上傳隊列”功能完成的。在測試開始前，上傳隊列設置為“僅在連接到Wi-Fi網(wǎng)絡時上傳”。

關閉“僅在連接到Wi-Fi網(wǎng)絡時上傳”，斷言“等待上傳”中這條數(shù)據(jù)是否不存在。若不存在，切換到“上傳完成”，斷言是否有該條快照數(shù)據(jù)。若有，證明該條快照上傳成功。

查看現(xiàn)場快照數(shù)據(jù)，斷言上傳的現(xiàn)場快照數(shù)據(jù)是否與填報時的數(shù)據(jù)一致。返回現(xiàn)場快照列表，進入該條現(xiàn)場快照的詳情頁。在現(xiàn)場快照新增時，新增2個夾具set_global_data（）和get_global_data（）和1個全局字典global_data，在存放填報的現(xiàn)場快照數(shù)據(jù)時，調(diào)用set_global_data（）函數(shù)將填表的數(shù)據(jù)放入全局字典。在斷言查看的現(xiàn)場快照數(shù)據(jù)時，使用get_global_data（）將預期結果從字典里取出，與查看現(xiàn)場快照的實際結果數(shù)據(jù)進行對比，斷言上傳后的現(xiàn)場快照數(shù)據(jù)是否與填報時的一致。

新增現(xiàn)場快照時，通過給附件中的數(shù)據(jù)添加備注信息標記數(shù)據(jù)。斷言已上傳的現(xiàn)場快照附件信息時，通過標記來判斷附件數(shù)據(jù)是否與上傳之前一致。

判斷上傳后的音視頻文件能夠正常播放，是通過點擊音視頻文件，延時2 s后，斷言播放時間是否為0。若播放的時間不為0，則說明音視頻文件可以正常播放。

4.3 "現(xiàn)場快照的編輯

為降低代碼的耦合性，提高測試用例的穩(wěn)定性和質(zhì)量，將驅(qū)動器夾具driver的作用域設置為了module，使得現(xiàn)場快照的新增及查看測試完成后，軟件重啟測試現(xiàn)場快照的編輯。因此，在現(xiàn)場快照新增和查看的測試過程中，出現(xiàn)了重大的Bug，也不會影響現(xiàn)場快照編輯的正常測試。

現(xiàn)場快照編輯的測試思路為：首先新增一個不做任何修改的現(xiàn)場快照，上傳后編輯。與新增和查看現(xiàn)場快照時的操作流程和斷言方式一樣，進行測試。若編輯時的信息和編輯上傳后查看的信息一致，證明編輯成功。

4.4 "標記點的新增

標記點用于在地圖上做標記，以提醒用戶該點需要被調(diào)查。其與現(xiàn)場快照的區(qū)別在于沒有路線相關的信息，但有“關注標記點”。輸入“提示距離”，當用戶行駛到距離標記點提示距離時，將會收到用戶調(diào)查該點的提示。

進入地圖界面，點擊地圖界面新增標記點按鈕進入標記點新增界面。斷言界面頂部是否為“標記點”，關聯(lián)項目是否為“經(jīng)天路圖演示項目”。

定位方式默認為“我的位置”，斷言經(jīng)緯度是否為測試人員手機所在位置的經(jīng)緯度。斷言位置信息是否正確。修改定位方式為“地圖選點”，選擇“自貢市永安鎮(zhèn)”，斷言經(jīng)緯度和位置信息是否正確。

輸入標記點名稱，標記點描述，將關注標記點設置為“否”，斷言是否出現(xiàn)“提示距離”和“僅提醒一次”，然后將關注標記點設置為“是”，斷言是否出現(xiàn)“提示距離”和“僅提醒一次”。添加“提示距離”為100 m和“僅提醒一次”選擇為“是”。

附件的測試方法與現(xiàn)場快照的測試方法一樣，不再贅述。

4.5 "標記點的上傳及查看

標記點的上傳與現(xiàn)場快照的上傳測試方式相同，都是通過“上傳隊列”中的“上傳完成”是否有該標記點數(shù)據(jù)來判斷其是否上傳成功。

查看標記點與查看現(xiàn)場快照的原理也相同，都是通過將新增標記點的預期內(nèi)容儲存到全局字典，然后與查看標記點時的實際結果做對比，斷言其新增時填報的內(nèi)容與上傳后查看的內(nèi)容是否一致。

查看附件的斷言方式與現(xiàn)場快照一致。

4.6 "標記點的編輯

標記點的編輯主要針對的是標記點的關注和取消關注。

在標記點列表界面“取消關注”標記點，進入標記點編輯界面，斷言“關注標記點”是否為“否”。再次返回標記點列表界面，“關注標記點”，添加“提示距離”為150 m，勾選“僅提醒一次”，進入標記點編輯界面，斷言“關注標記點”是否為“是”，提示距離是否為“150”，是否為“僅提醒一次”。

標記點其余測試內(nèi)容的測試方法與現(xiàn)場快照一致。

4.7 "調(diào)查表單的新增、查看、編輯

測試調(diào)查表單的專業(yè)信息是否正常，需考慮到所有控件的可能性。因此，需設計一個“測試調(diào)查專業(yè)”，將所有控件的所有功能可能性全部包含進去進行測試斷言。

新增專業(yè)信息時，將最終填報的內(nèi)容存入全局字典，上傳后，將新增的內(nèi)容與上傳后查看的內(nèi)容進行斷言對比，以此來判斷上傳后的數(shù)據(jù)是否與上傳之前一致。

編輯調(diào)查表單仍然采用新增調(diào)查表單而后編輯修改的方式。若編輯時的信息能夠正確填報，并且與編輯上傳后的各種數(shù)據(jù)一致，證明編輯功能正常。

5 "結論

采用自動化的方式對外業(yè)調(diào)查APP主要功能進行測試，有效地提高了效率。原有一次手動回歸測試的時間在180 min左右（表1），一次自動化回歸測試的時間控制在了40 min，效率提高77%，滿足了外業(yè)調(diào)查APP快節(jié)奏的頻繁更新需求。

自動化測試的標準化操作減少了手動測試可能導致的遺漏，使得每一個點都會按照既定的程序進行測試。

自動生成的測試報告，既有圖表分析，也有詳細的測試結果展示。錯誤日志清楚地指明了錯誤點，便于測試人員定位錯誤，開發(fā)人員修改錯誤。

采用Jenkins自動集成自動化測試流程，無需人工干預。在約定時間進行自動化測試，完成后自動發(fā)送報告給相關開發(fā)人員和測試人員，提高了用例運行的自動化率。

參考文獻：

[1] 張娜，蔡樂俊，徐曼，等.Airtest平臺自動化測試方案設計與實現(xiàn)[J].軟件導刊，2021（12）：88-92.

[2] 王佳明，駱德漢.基于Monkeyrunner的Android應用自動化測試框架的研究[J].電腦知識與技術，2019（15）：234-236，245.