作者 |熊一衡 華東師范大學(xué)軟件工程學(xué)院博士

蘇亭 華東師范大學(xué)軟件工程學(xué)院教授

版塊 |鑒源論壇 · 觀模

01什么是面向界面的圖形化測(cè)試（GUI Testing）

圖形用戶界面(GUI) 是一種通過圖形化方式呈現(xiàn)信息、數(shù)據(jù)、功能和操作的用戶界面，旨在提供更加直觀、友好、易用的體驗(yàn)，以滿足用戶的需求和期望。圖形用戶界面通常由窗口、菜單、按鈕、文本框、圖標(biāo)、標(biāo)簽等組件構(gòu)成，用戶可以通過鼠標(biāo)、鍵盤等輸入設(shè)備進(jìn)行交互和操作。GUI界面的設(shè)計(jì)和布局需要考慮用戶的習(xí)慣、視覺效果、易用性等因素，以提供最佳的用戶體驗(yàn)。

面向界面的圖形化測(cè)試是一種常用的軟件測(cè)試方法，旨在驗(yàn)證用戶界面是否符合業(yè)務(wù)規(guī)范和用戶需求，以及驗(yàn)證應(yīng)用程序的功能是否正確響應(yīng)用戶操作，以保證應(yīng)用程序的質(zhì)量和穩(wěn)定性。圖形化測(cè)試通常在開發(fā)的中后期進(jìn)行，可以確保應(yīng)用程序的功能和用戶界面的質(zhì)量，提高用戶體驗(yàn)，降低用戶投訴和退款率。此技術(shù)可以有效地提高測(cè)試效率和測(cè)試質(zhì)量，在各種應(yīng)用程序的測(cè)試中得到廣泛應(yīng)用。

例如，如果一個(gè)用戶訪問京東商城的網(wǎng)站主頁(yè)，他將看到導(dǎo)航欄、搜索欄、推薦欄和其他諸多組件。測(cè)試人員可以針對(duì)不同的關(guān)注點(diǎn)來對(duì)這個(gè)網(wǎng)頁(yè)進(jìn)行圖形化測(cè)試。例如，點(diǎn)擊“免費(fèi)注冊(cè)”按鈕，網(wǎng)站是否能彈出相應(yīng)的注冊(cè)網(wǎng)頁(yè)，包括導(dǎo)航、搜索、表單、購(gòu)物車、支付等功能是否能正常響應(yīng)用戶操作。

通過圖形化測(cè)試，可以發(fā)現(xiàn)應(yīng)用中的問題和缺陷，提高應(yīng)用的質(zhì)量和用戶體驗(yàn)，增強(qiáng)用戶的滿意度和忠誠(chéng)度，從而提高應(yīng)用的價(jià)值和競(jìng)爭(zhēng)力。

02常見的面向界面的圖形化測(cè)試技術(shù)

2.1 基于人工的測(cè)試

基于人工的測(cè)試是一種傳統(tǒng)的軟件測(cè)試方式，測(cè)試人員通過手動(dòng)操作應(yīng)用程序的用戶界面，模擬用戶的行為和操作，來發(fā)現(xiàn)和報(bào)告應(yīng)用的問題和缺陷。在實(shí)際應(yīng)用中，應(yīng)用系統(tǒng)級(jí)的功能性問題很大程度上是依靠人工測(cè)試找到 [1]。基于人工的圖形化測(cè)試需要有經(jīng)驗(yàn)的測(cè)試人員，能夠全面地覆蓋測(cè)試用例和測(cè)試場(chǎng)景。然而，測(cè)試的效率和準(zhǔn)確性很大程度上受到測(cè)試人員的技能水平和經(jīng)驗(yàn)的影響。基于人工的測(cè)試主要包括以下步驟：

（1）理解項(xiàng)目需求和制定測(cè)試計(jì)劃：測(cè)試人員必須分析所有的需求文檔，以便識(shí)別軟件的預(yù)期行為和需要測(cè)試的確切內(nèi)容。測(cè)試人員根據(jù)需求和規(guī)格說明書，制定測(cè)試計(jì)劃和測(cè)試用例。

（2）測(cè)試環(huán)境和測(cè)試數(shù)據(jù)準(zhǔn)備：測(cè)試人員準(zhǔn)備測(cè)試環(huán)境和測(cè)試數(shù)據(jù)，包括安裝和配置測(cè)試軟件、準(zhǔn)備測(cè)試數(shù)據(jù)、設(shè)置測(cè)試工具和設(shè)備等，以確保測(cè)試環(huán)境的一致性和穩(wěn)定性。

（3）手動(dòng)測(cè)試執(zhí)行：測(cè)試人員按照測(cè)試計(jì)劃和測(cè)試用例，手動(dòng)操作應(yīng)用程序的用戶界面，模擬用戶的行為和操作，包括點(diǎn)擊、輸入、選擇、拖拽等，以驗(yàn)證應(yīng)用程序的功能和性能，并記錄測(cè)試結(jié)果和異常情況。

（4）缺陷報(bào)告和總結(jié)：當(dāng)測(cè)試人員發(fā)現(xiàn)缺陷的時(shí)候，需要根據(jù)測(cè)試團(tuán)隊(duì)所制定的報(bào)告模版生成缺陷報(bào)告，包括缺陷的描述、缺陷分類、缺陷級(jí)別等等，并跟蹤和確認(rèn)缺陷的修復(fù)和驗(yàn)證。在測(cè)試完成之后，測(cè)試人員根據(jù)測(cè)試的結(jié)果生成測(cè)試報(bào)告并提交給項(xiàng)目團(tuán)隊(duì)。

基于人工的測(cè)試的優(yōu)點(diǎn)包括：測(cè)試靈活性高，人工測(cè)試可以基于一個(gè)功能自己構(gòu)建不同的測(cè)試用例，并且適應(yīng)不同的程序表現(xiàn)；測(cè)試準(zhǔn)確性高，自動(dòng)化測(cè)試工具沒有測(cè)試人員經(jīng)驗(yàn)豐富，人工測(cè)試可以更加準(zhǔn)確判斷一個(gè)應(yīng)用表現(xiàn)是否為一個(gè)程序錯(cuò)誤；測(cè)試反饋及時(shí)，可以及時(shí)發(fā)現(xiàn)和報(bào)告軟件缺陷和問題。

然而，基于人工的測(cè)試也存在一些缺點(diǎn)，如測(cè)試效率低，需要較長(zhǎng)的測(cè)試時(shí)間和測(cè)試人員的工作量，當(dāng)短時(shí)間內(nèi)需要生成大量測(cè)試用例時(shí)，不適合用人工測(cè)試；測(cè)試成本高，相對(duì)于自動(dòng)化測(cè)試，人工測(cè)試需要耗費(fèi)大量人力和時(shí)間；測(cè)試可重復(fù)性差，測(cè)試結(jié)果可能受到測(cè)試人員的主觀因素的影響；測(cè)試覆蓋率有限，可能無法涵蓋所有的測(cè)試用例和測(cè)試場(chǎng)景。

2.2 基于錄制回放的測(cè)試

基于錄制回放的測(cè)試通過記錄用戶在圖形界面上的操作，生成測(cè)試腳本，然后回放測(cè)試腳本到目標(biāo)應(yīng)用上來模擬用戶的操作并驗(yàn)證應(yīng)用程序的功能。錄制回放測(cè)試技術(shù)屬于自動(dòng)化測(cè)試的一種形式，不需要人工編寫測(cè)試腳本，減少工作人員的工作量，適用于需要重復(fù)執(zhí)行相同測(cè)試用例的場(chǎng)景，如回歸測(cè)試、性能測(cè)試等。錄制回放測(cè)試技術(shù)主要包括以下步驟：

（1）錄制測(cè)試腳本：測(cè)試人員打開測(cè)試工具，啟動(dòng)錄制功能，然后在應(yīng)用程序的用戶界面上進(jìn)行操作和事件，如點(diǎn)擊按鈕、輸入文本、選擇菜單等，測(cè)試工具會(huì)自動(dòng)捕捉和記錄用戶的操作和事件，并生成測(cè)試腳本。

（2）編輯測(cè)試腳本：測(cè)試人員可以對(duì)生成的測(cè)試腳本進(jìn)行編輯和優(yōu)化，如添加斷言、調(diào)整等待時(shí)間、修改參數(shù)等，以確保測(cè)試腳本能夠正確地模擬用戶的操作和驗(yàn)證應(yīng)用程序的功能和性能。

（3）回放測(cè)試腳本：測(cè)試人員啟動(dòng)回放功能，測(cè)試工具會(huì)自動(dòng)執(zhí)行測(cè)試腳本，模擬用戶的操作并驗(yàn)證應(yīng)用程序的功能和性能，同時(shí)記錄測(cè)試結(jié)果和異常情況。

（4）生成測(cè)試報(bào)告：測(cè)試人員分析測(cè)試結(jié)果，包括測(cè)試通過率、測(cè)試覆蓋率等，發(fā)現(xiàn)軟件缺陷和問題，并向開發(fā)團(tuán)隊(duì)提供測(cè)試報(bào)告。

錄制回放測(cè)試技術(shù)的優(yōu)點(diǎn)包括：測(cè)試成本低，不需要會(huì)編寫測(cè)試腳本的專業(yè)人員，測(cè)試效率高，可以根據(jù)測(cè)試人員的錄制自動(dòng)化生成測(cè)試腳本并自動(dòng)執(zhí)行測(cè)試；測(cè)試準(zhǔn)確性高，可以模擬真實(shí)用戶的操作并驗(yàn)證應(yīng)用程序的功能和性能；測(cè)試可維護(hù)性高，可以快速修改和更新測(cè)試腳本和測(cè)試數(shù)據(jù)。

然而，錄制回放測(cè)試技術(shù)也存在一些缺點(diǎn)，如測(cè)試腳本的可靠性和穩(wěn)定性受到應(yīng)用程序的變化和測(cè)試環(huán)境的影響，需要保證測(cè)試環(huán)境的一致性和穩(wěn)定性；測(cè)試腳本的維護(hù)成本較高，應(yīng)用程序代碼和界面在不斷變化，因此需要不斷更新和優(yōu)化測(cè)試腳本和測(cè)試數(shù)據(jù)來適應(yīng)這些改變；測(cè)試覆蓋度有限，依賴于測(cè)試人員的錄制，測(cè)試人員一般偏向于錄制一些核心功能和核心步驟。

Selenium IDE [2] 是Selenium Suite下的一款非常受歡迎的開源Web自動(dòng)化測(cè)試工具，其核心功能是錄制回放測(cè)試。它不需要用戶有任何編程知識(shí)，只需記錄用戶與瀏覽器的交互從而可以快速地創(chuàng)建、執(zhí)行和調(diào)試自動(dòng)化測(cè)試腳本。Selenium IDE提供了一個(gè)簡(jiǎn)單的界面，可以通過簡(jiǎn)單的拖放操作和錄制功能，快速創(chuàng)建自動(dòng)化測(cè)試腳本，無需編寫任何代碼。它支持多種瀏覽器，包括Chrome、Firefo等。此外，Selenium IDE還可以導(dǎo)出測(cè)試腳本為多種編程語言的代碼，如Java、C#和Python等。

2.3 基于模型的測(cè)試

基于模型的測(cè)試是一種自動(dòng)化測(cè)試方法，它利用模型來描述被測(cè)試系統(tǒng)的行為和結(jié)構(gòu)，從而生成測(cè)試用例，驗(yàn)證系統(tǒng)的正確性和可靠性。基于模型的測(cè)試可以提高測(cè)試效率和覆蓋率，減少測(cè)試人員的工作量，適用于復(fù)雜和多變的應(yīng)用程序，如嵌入式系統(tǒng)、軟件系統(tǒng)、網(wǎng)絡(luò)系統(tǒng)等。

基于模型的測(cè)試主要包括以下步驟：

（1）建模：測(cè)試人員使用建模工具，根據(jù)需求和規(guī)格說明書，構(gòu)建被測(cè)試系統(tǒng)的模型，包括功能模型、狀態(tài)模型、數(shù)據(jù)模型等，以描述被測(cè)試系統(tǒng)的行為和結(jié)構(gòu)。

（2）模型分析：測(cè)試人員對(duì)模型進(jìn)行分析和驗(yàn)證，包括模型檢查、模型仿真、模型測(cè)試等，以發(fā)現(xiàn)和修復(fù)模型中的錯(cuò)誤和問題。

（3）測(cè)試用例生成：測(cè)試人員利用模型生成測(cè)試用例，包括基于覆蓋率的測(cè)試用例、隨機(jī)測(cè)試用例、符號(hào)執(zhí)行測(cè)試用例等，以覆蓋模型中的所有路徑和狀態(tài)，并達(dá)到測(cè)試目標(biāo)和測(cè)試要求。

（4）自動(dòng)化測(cè)試執(zhí)行：測(cè)試人員使用自動(dòng)化測(cè)試工具，執(zhí)行生成的測(cè)試用例，對(duì)被測(cè)試系統(tǒng)進(jìn)行自動(dòng)化測(cè)試，包括功能測(cè)試、性能測(cè)試、安全測(cè)試等，以檢驗(yàn)被測(cè)試系統(tǒng)的正確性和可靠性。

（5）測(cè)試報(bào)告和總結(jié)：測(cè)試人員整理測(cè)試結(jié)果和問題報(bào)告，生成測(cè)試報(bào)告和總結(jié)，包括測(cè)試通過率、測(cè)試覆蓋率、缺陷統(tǒng)計(jì)、測(cè)試建議等，以提供給項(xiàng)目團(tuán)隊(duì)和管理者參考和決策。

基于模型的測(cè)試的優(yōu)點(diǎn)包括：測(cè)試效率高，可以自動(dòng)生成測(cè)試用例和測(cè)試腳本，并自動(dòng)執(zhí)行測(cè)試；測(cè)試覆蓋率高，可以覆蓋模型中的所有路徑和狀態(tài)；測(cè)試可重復(fù)性好，可以多次執(zhí)行相同的測(cè)試用例和測(cè)試腳本；測(cè)試結(jié)果準(zhǔn)確性高，可以自動(dòng)化地驗(yàn)證被測(cè)試系統(tǒng)的正確性和可靠性。

然而，基于模型的測(cè)試也存在一些缺點(diǎn)，如模型的建立和維護(hù)成本高，需要投入大量的人力和物力資源，并且需要建模人員非常了解待測(cè)試應(yīng)用；門檻高，模型的構(gòu)建需要有非常專業(yè)的建模人員，熟練使用各種專業(yè)技能 [3]；模型的應(yīng)用范圍有限，可能無法覆蓋所有的測(cè)試需求和測(cè)試場(chǎng)景。因此，在實(shí)際測(cè)試中，應(yīng)根據(jù)測(cè)試需求和應(yīng)用程序的特點(diǎn)，綜合選擇不同的測(cè)試方法和工具，以提高測(cè)試效率和質(zhì)量。

Fastbot [4] 是一款由字節(jié)跳動(dòng)Quality Lab研發(fā)的一款開源的基于模型的GUI測(cè)試工具，用于發(fā)現(xiàn)手機(jī)app中的穩(wěn)定性問題。Fastbot將app的GUI信息抽象成模型中的state，將執(zhí)行的動(dòng)作抽象成模型中的action，然后基于構(gòu)建的模型生成測(cè)試用例，并提供多種算法策略，目標(biāo)是達(dá)到較高的 Activity 覆蓋率及較強(qiáng)的問題發(fā)現(xiàn)能力。同時(shí)，F(xiàn)astbot還支持跨平臺(tái)測(cè)試，在海量設(shè)備上多機(jī)協(xié)同測(cè)試。Fastbot也利用了圖像檢測(cè)技術(shù)來支持較豐富的圖像 UI 異常檢測(cè)能力（黑白屏、圖像重疊、控件遮擋等等）。

03面向界面的圖形化測(cè)試的挑戰(zhàn)

根據(jù)statista網(wǎng)站上的報(bào)道，48%的移動(dòng)應(yīng)用測(cè)試人員將圖形化界面看作主要的測(cè)試關(guān)注點(diǎn)[5]。面向界面的圖形化測(cè)試在應(yīng)用的功能和質(zhì)量起著至關(guān)重要的作用，在實(shí)際應(yīng)用中也存在不少挑戰(zhàn)：

（1）代碼和設(shè)計(jì)變更：鑒于應(yīng)用界面以及功能的頻繁更新，測(cè)試人員需要不斷調(diào)整測(cè)試腳本以適應(yīng)新的測(cè)試場(chǎng)景。

（2）錯(cuò)誤處理：當(dāng)測(cè)試復(fù)雜應(yīng)用程序時(shí)，可能會(huì)遇到各種程序問題，來干擾測(cè)試進(jìn)行，如何處理這些問題是一個(gè)常見的難題。

（3）測(cè)試工具與被測(cè)軟件的同步問題：測(cè)試工具與測(cè)試對(duì)象之間如果同步出了問題，很可能會(huì)導(dǎo)致測(cè)試失敗，影響測(cè)試結(jié)果的準(zhǔn)確性 [6]。

（4）依賴于測(cè)試工具：首先需要選用合適的測(cè)試工具，并對(duì)測(cè)試的應(yīng)用進(jìn)行相應(yīng)的定制和配置。

（5）需要專業(yè)技能：需要具備一定的編程和測(cè)試技能，才能進(jìn)行測(cè)試腳本編寫和自動(dòng)化測(cè)試工具的配置和使用。

（6）多樣性：不同的軟件界面設(shè)計(jì)不同，測(cè)試人員需要熟悉各種不同的界面風(fēng)格和交互方式。

04總結(jié)

面向界面的圖形化測(cè)試技術(shù)已經(jīng)成為各種應(yīng)用程序測(cè)試的重要手段之一。這種測(cè)試技術(shù)廣泛應(yīng)用于各種應(yīng)用程序的測(cè)試中，特別是對(duì)于那些用戶界面比較復(fù)雜、交互性比較強(qiáng)的應(yīng)用程序，如游戲、手機(jī)app、網(wǎng)站等。此技術(shù)可以有效地提高測(cè)試效率和測(cè)試質(zhì)量。盡管取得了巨大進(jìn)展，但該測(cè)試技術(shù)仍然面臨著許多挑戰(zhàn)，學(xué)術(shù)界和工業(yè)界也在不斷探索嘗試各種新的技術(shù)和方法，以提高測(cè)試的效率和質(zhì)量。

參考文獻(xiàn)：

[1] Itkonen J, Mantyla M V, Lassenius C. How do testers do it? An exploratory study on manual testing practices[C]//2009 3rd International Symposium on Empirical Software Engineering and Measurement. IEEE, 2009: 494-497.

[2] Selenium IDE

[3] Dias Neto A C, Subramanyan R, Vieira M, et al. A survey on model-based testing approaches: a systematic review[C]//Proceedings of the 1st ACM international workshop on Empirical assessment of software engineering languages and technologies: held in conjunction with the 22nd IEEE/ACM International Conference on Automated Software Engineering (ASE) 2007. 2007: 31-36.

[4] Fastbot https://github.com/bytedance/Fastbot_Android.

[5] “Focus areas for testing mobile applications from 2013 to 2017”

[6] Alégroth E, Feldt R, Ryrholm L. Visual gui testing in practice: challenges, problemsand limitations[J]. Empirical Software Engineering, 2015, 20: 694-744.

審核編輯黃宇