移動應用程序的特定故障分類并用于集中質量保證

張文龍，張志翔

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2 文獻中的故障分類

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

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

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

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

圖1 故障分類及其子類

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

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

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

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

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

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

2 討論

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

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

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

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

3 結論和相關工作

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

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

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