張文龍，張志翔

（四川大學計算機學院，成都 610065）

0 引言

由于移動設備的不斷發(fā)展和擴散，幾乎所有領域都在開發(fā)新的應用程序。特別是在移動商務應用的領域，應該充分利用某些優(yōu)點，如更高的可用性、新信息的快速分發(fā)和更快的反應時間。這些特征表明，移動商務應用程序不僅僅是一個轉移的桌面應用程序、游戲應用程序或內(nèi)容查看應用程序。移動商務應用程序通常是根據(jù)移動設備如智能手機或平板電腦（不是筆記本電腦），集成到現(xiàn)有的IT 基礎設施，是面向任務的和集中于一個清晰的和有限的功能范圍，以及基于公司業(yè)務流程的流動潛力[1]。事實上，考慮到當今市場上有大量的應用程序執(zhí)行顯著的相似功能[2]，應用程序的設計和用戶體驗往往是導致成功或失敗的區(qū)別因素[3]。

因此，移動商務應用程序的質(zhì)量是非常重要的，以避免損失收入或降低效率等負面影響。設想一個用于生產(chǎn)過程控制的移動應用程序，它提供關于當前狀態(tài)的信息來監(jiān)視生產(chǎn)并提供決策支持，例如，環(huán)境參數(shù)的收集和解釋。如果應用程序失敗，它可能會導致錯誤的決策或意外的生產(chǎn)效果，由于生產(chǎn)過程的高啟動時間而造成非常嚴重的后果。

Muccini 等人[5]認為，智能手機和平板電腦等移動設備上的應用程序的主要特點是：有限的資源（如電池）、用戶界面（如觸摸屏）、上下文感知（如移動連接）和多樣性（如設備和操作系統(tǒng)）。此外，該論文貢獻了一個研究問題：移動應用程序是否不同于傳統(tǒng)應用程序，是否需要不同的、專門的新測試技術。討論移動應用程序的特點和結論（關于測試的移動應用程序），存在著許多挑戰(zhàn)與移動應用程序的上下文環(huán)境和移動性有關，而且性能、安全性、可靠性和能量都受到移動設備所處環(huán)境變化的強烈影響。

因此，移動商務應用程序的失敗與桌面應用程序的失敗是不同的。關于移動應用程序的典型故障模式的類型，發(fā)生的頻率，及其在質(zhì)量保證方面的考慮，還沒有確定的規(guī)則。所以，這對移動應用程序質(zhì)量保證造成了一點的負面影響，并可導致：

●移動應用程序中存在的潛在故障風險

●重復的修復移動應用程序的這個迭代過程將對公司的開發(fā)過程產(chǎn)生代價高昂的結果

在現(xiàn)有的移動應用程序的故障類型中，是從面向編程的角度來對故障進行分類的[6-10]，這就要求分析人員具備一點專業(yè)的IT 知識，才能正確的去識別這些故障類型。假如我們從人視覺分析的角度去考慮這個問題，將移動應用程序故障輕量化，僅僅只考慮GUI 圖形，那么對于移動應用程序的質(zhì)量保證會不會產(chǎn)生正面積極的影響？

假設經(jīng)典桌面應用的質(zhì)量保證方法與移動應用的質(zhì)量保證方法沒有顯著差異，那么移動應用的故障

模式存在哪些主要的、有區(qū)別的特征，這導致了研究問題：

●RQ1：如何對檢測到的移動設備故障進行分類?

●RQ2：存在哪些典型故障類型，如何將它們集成到故障分類中?

1 典型的移動應用程序故障

關于分類，本文使用術語fault 作為故障的起源，并使用術語fault aspect 作為導致移動應用程序特定故障的測試用例的焦點。

1.1 移動設備故障的文獻綜述

根據(jù)Kitchenham[6]的一篇文獻綜述，作者闡述了這種技術的現(xiàn)狀，并回答了關于移動應用程序失敗的問題。

包含IEEE Xplore 和ACM 數(shù)字圖書館內(nèi)容的書目數(shù)據(jù)庫 Scopus[7]在 2006 年 1 月至 2014 年 1 月期間發(fā)表了計算機科學領域的1001 項結果。查找相關出版物的搜索字符串是基于失敗和移動相關的術語。2006年和2014 年的搜索結果中沒有相關的出版物。從數(shù)據(jù)庫的結果可以找出26 份出版物來支持這項貢獻。來自這些出版物的信息將被考慮用于故障分類，包括典型故障方面。其他相關的出版物也在故障檢測和故障方面支持了這一貢獻，但是它們描述的觀點基本相似。

支持這一貢獻的部分出版物主要介紹了基于度量的移動電話故障特征，并確定了移動應用程序的主要故障類型，研究了錯誤報告中報告的故障，或集中于具體的錯誤主題，如資源限制器或觸發(fā)器。

1.2 文獻中的故障分類

Mauser 等人在文獻[7]中收集了有關移動應用程序領域之外的故障（故障、錯誤等）分類的相關工作，重點是人機接口（Human Machine Interfaces，HMI）?？紤]到移動設備也是HMIs，與HMI 相關的出版物基本都與這一貢獻相關。在這里，失敗分類的主要類是行為、設計和內(nèi)容，它們根據(jù)上下文被劃分為子類。這項工作的分類是由IBM[8]在20 世紀90 年代早期創(chuàng)建的正交缺陷分類（ODC）所開發(fā)的。

IEEE 軟件異常的標準分類[9]描述了一種基于每個故障報告屬性列表的方法。其目的是定義一個通用的詞匯表，不同的人和組織可以使用它進行交流，并建立一套通用的屬性，以支持分析軟件缺陷和故障數(shù)據(jù)[6]的行業(yè)技術。這不是本文的目標，本文主要關注一種更輕量級的分類方法。然而，該標準中的故障屬性值包含了可能的錯誤、丟失和額外值的section 模式，這被認為是移動應用程序故障子類的一個有說服力的劃分。

1.3 基于GGUUII的移動應用程序故障分類

從相關工作的研究和質(zhì)量保證項目的經(jīng)驗中獲得的見解使基于GUI 的故障分類成為可能，其中包括到典型故障方面的映射。首先，無論移動應用程序處于開發(fā)之前還是投入使用期間，移動應用程序通常采用圖形用戶界面（GUI）的形式來表示，所以，我們可以根據(jù)基于GUI 來找出存在于移動應用程序中的顯著故障。故障方面的類別定義如圖1 所示。

圖1 故障分類及其子類

一個完整的移動應用程序由很多個屏幕原型組成，這些屏幕存在著嵌套的關系，而每一個屏幕原型都是由相對應的組件組成，如，在Android Studio[11]開發(fā)中頻繁使用的 View、TextView、Button、EditText 組件和在Apple's Xcode IDE[12]開發(fā)中頻繁使用的UIView、UILabel、UIButton、UITextField 控件，他們僅僅只是因為操作系統(tǒng)的不同，而導致對象名不同，而實質(zhì)上是同一個組件。因此，移動應用程序故障的分類可以根據(jù)組件進行故障分類。

因為一個組件有其特有唯一的屬性，包括有在屏幕上顯示的位置，包含以下信息：①＜x-position，y-position＞、②＜height，width＞、③＜text＞、④＜image＞。這里四個元素述了組件的邊界框的左上角的位置，而高度和寬度屬性描述了邊界框的大小。文本屬性對應于組件顯示的文本，而圖像屬性表示組件的圖像，其邊界依附于前兩個屬性。

由于每一個組件都有一個且唯一的元素屬性，我們可以設定某一種閾值對其進行比較，來對移動應用程序中屏幕出現(xiàn)的故障進行判定和分類。

在本文的故障分類中，可以有效的進行第一類故障類別是布局故障。要檢測布局故障的類別，主要與兩個屬性有關：①組件位置（即＜x，y＞的位置），和②尺寸（即邊界框的＜h，w＞）。通過比較 x 或 y 維度中數(shù)值的差異是否大于某一個布局閾值，從而判斷是否出現(xiàn)布局故障，同時輸出故障類型。

可以有效地識別出的第二類故障類別是文本故障。通過對以下屬性進行處理：①組件位置（即＜x，y＞的位置）、②尺寸（即邊界框的＜h，w＞）、③文本（即＜text＞顯示內(nèi)容）。首先對基于文本位置的邊界框大小進行裁剪，然后對裁剪后的推行進行圖形處理，得到基于像素的差異，就可以判斷其是否存在字體顏色和樣式故障。其次，為了檢測不正確文本故障，可以對文本text的內(nèi)容進行預處理，以處理空白和規(guī)格化字母大小，并執(zhí)行字符串比較。如果字符串匹配失敗，則輸出不正確文本的故障類型2c。

同樣的，可以準確的分類的第三類故障類別是資源故障。需預處理4 個元素的所有信息，然后進行合理分析、解釋，最后給出與其對應的輸出類型。假如我們現(xiàn)在存在一個缺失的控件，那么在屏幕中，在對應的＜x，y＞位置上就不存在一定＜h，w＞的邊界框，從而出是資源故障中的缺失或額外組件。同理，可以根據(jù)屬性中的＜image＞信息，進行圖像預處理技術，得到其對應的故障類型。

2 討論

在實際開發(fā)過程中，故障的發(fā)生通常主要以屏幕中的某一區(qū)域的組件由于某種不可控的原因而導致其發(fā)生改變造成的，比如：水平方向的移動可能使用應用程序時發(fā)生故障。這樣的問題在很多情況下不是由開發(fā)人員引起的，而是由需求工程師引起的。由于缺少規(guī)范，就像在這個故障方面的情況中一樣，允許對功能進行解釋或忽略。

通過對項目的實證研究，這證實了基于GUI 的故障分類的充分性，并導致了子類的派生，以及在應用于評估中移動應用程序后對典型故障方面的擴展。關于子類的擴展總是關于調(diào)整子類的定義。對于用于應用分類的移動應用程序，沒有必要再細分，只需要對故障方面進行少量擴展。最終，每個報告的故障都可以鏈接到一個已定義的故障類。沒有不相關的故障報告。由于開發(fā)者沒有實時報告每次檢測到的故障，為了評估在應用程序集中的分類的完整性，以及每個被訪談的開發(fā)人員的個人開發(fā)經(jīng)驗，我們與幾個在程序開發(fā)領域有幾年相關工作經(jīng)驗的開發(fā)人員討論了分類。

因此，本文提供了一個初始分類，如果需要，可以根據(jù)故障類及其相應的故障方面的集合和定義對其進行調(diào)整和擴展。

有關特定于移動設備的故障類及其與每個故障類的典型故障方面的關系的知識可用于集中質(zhì)量保證活動，如系統(tǒng)和集成測試。Holl[7]已經(jīng)提出了一種適合的質(zhì)量保證方法，該方法基于使用檢驗和測試技術的整體方法。該方法能夠?qū)y試用例進行有重點的推導，考慮到頻繁的故障模式和通過檢查方法進行的缺陷檢測，該方法適用于通常不充分且不斷變化的需求規(guī)格。

3 結論和相關工作

這項工作產(chǎn)生了一個基本的基于GUI 的故障特定分類，它可以用來集中質(zhì)量保證，從而減少移動應用程序中遺留的，潛在的故障風險。這可以防止依賴于業(yè)務流程范圍的代價高昂的后果。此外，派生的分類鼓勵對未來工作主題的研究。

第一個研究問題是，如何對檢測到的移動設備故障進行分類?根據(jù)項目經(jīng)驗和故障分類的相關工作回答。第二個研究問題，存在哪些典型的故障方面，如何將它們整合到故障分類中?根據(jù)項目經(jīng)驗和有關移動設備故障的文獻綜述，回答了這個問題。對這兩個研究問題的研究導致了信息的重疊和信息的互補。結合其他分類方案的知識，可以創(chuàng)建基本的特定于移動設備的故障分類，包括分類典型故障方面。將此分類應用于多個移動應用程序開發(fā)，可以成功地對其進行評估和優(yōu)化。

作為未來的工作，對開源項目報告數(shù)據(jù)庫的調(diào)查將是全面評估這一分類的下一步工作之一，如果能夠找到新的見解，還可以擴展它。此外，還將探討可能根據(jù)故障報告中所報告的頻率來推導故障分布的可能性。進一步的步驟將是提出的質(zhì)量保證方法[7]，基于派生的故障分類，以評估整體集中的質(zhì)量保證方法。