Android applications are widely used around the world. Most of these applications contain potential crashes. Many recent academic studies focus on black-box testing of Android applications to detect these crashes. A simple random testing tool, Monkey, detects more crashes than the state-of-the-art black-box testing tools, but can not reach some
activities that are located deep within the application. We propose an hybrid approach that combines our model-learning tool, AndroFrame, and Monkey. With this hybrid approach, we aim to increase activity coverage and improve crash detection. We conduct experiment on 20 Android applications. As a result, our hybrid approach achieves 2% more activity coverage and detects 21 more crashes compared to AndroFrame. Compared to Monkey, our hybrid approach achieves 24% more coverage and detects 5 more crashes. 1
Mobil uygulamalar günlük hayatımızın vazgeçilmez parçalarından biri
olmuşlardır. İstatistikler bir kişinin günde ortalama 3 saat mobil telefon kullandığını ve bu
sürenin de %90’ını mobil uygulamalara harcadığını gösteriyor [
Son on yılda A3E [
Bu çalışmamızda hem aktivite kapsaması, hem de çökme tespiti bakımından
iyi bir performans elde etmek amacıyla AndroFrame-Monkey (AFM) adını
verdiğimiz karma bir otomatik test aracı önermekteyiz. AndroFrame [
AndroFrame aktivite kapsaması bakımından diğer araçlar arasında en iyi, çökme tespiti bakımından ise Monkey ile aşağı yukarı eşittir. AFM aracı, AndroFrame ile çıkarılan TAU yaklaşık bir modeli üzerinden tüm aktiviteleri ziyaret edecek en kısa yolları bulup, bu yollarla ziyaret ettiği aktivitelerin her birinde Monkey aracını ayrı ayrı çalıştırarak çökme tespiti yapmaktadır. Bildiğimiz kadarıyla, AFM, Monkey ile bir başka otomatik test yaratım aracını bir arada kullanan ilk çalışmadır.
Makalenin geri kalanı şu şekilde düzenlenmiştir. Bölüm 2, Android sistem altyapısı hakkında gerekli bilgileri vermektedir. Bölüm 3, detaylı bir akış çizelgesi ve basit bir örnek üzerinden AFM aracının çalışma prensiplerini anlatmaktadır. Bölüm 4, AFM aracının Monkey ve AndroFrame araçları ile kıyaslanması için oluşturduğumuz altyapıyı ve deney sonuçlarını açıklamaktadır. Bölüm 5, çalışmamızın geçerliliği ile ilgili konuları ve dizayn seçimlerimiz hakkında açıklamalar içermektedir. Bölüm 6, ilgili çalışmaları açıklamaktadır. Bölüm 7, çalışmamızı özetleyip gelecek çalışmalar için olası yolları anlatmaktadır. 2
Bu bölümde, kullandığımız yöntemlerin kolay anlaşılabilmesi için Android Grafiksel Kullanıcı Arayüzü (GKA) ve Android uygulamaları hakkında temel bilgiler vermekteyiz.
Android GKA, aktivite (activity) ve olay (event) tabanlıdır. Aktiviteler bir ekrandaki kullanıcı arayüzünü temsil eder ve GKA bileşenlerinden (widget) oluşur. Her bir GKA bileşeni (örn. düğme veya metin girdisi), piksel cinsinden bileşenin sınır koordinatlarını (x1; y1; x2; y2) tanımlayan ve kullanıcının bileşenle hangi eylemler (action) aracılığıyla etkileşime girebileceğini belirten bir takım özelliklere sahiptir. Bu özelliklere, tür, etkin (enabled), tıklanabilir (clickable), uzun tıklanabilir (longclickable), kaydırılabilir (scrollable), ve şifre (password) örnek olarak verilebilir.
Bir kullanıcı, Android sistemi ile GKA bileşenleri üzerinden olaylar aracılığı ile etkileşime girebilir. Olayları temel olarak iki kategoriye ayırabiliriz, sistem olayları ve GKA olayları (GKA eylemleri). Tipik olarak literatürde kullanılanlardan daha kapsamlı bir GKA eylemleri listesini Tablo 1’de göstermekteyiz. Eylemler üç kategoriden oluşmaktadır; bağlamsal olmayan (non-contextual), bağlamsal (contextual) ve özel (special). Bağlamsal olmayan eylemler kullanıcı hareketleriyle tetiklenen eylemlerdir. Tıklama ve uzun tıklama eylemleri, tıklanılacak x ve y koordinatları olmak üzere iki parametre alırlar. Metin girdisi eylemi x, y koordinatları ve girilecek metni belirten üç parametre alır. Kaydırma eylemi beş parametre alır; ilk dört parametre başlangıç ve bitiş koordinatlarını belirtirken, beşinci parametre ise kaydırma hızını ayarlamak için kullanılır. Menü ve Geri eylemleri mobil cihaz üzerindeki ilgili düğmelerin basılmasını temsil eden eylemlerdirler ve herhangi bir parametre almazlar. Bağlamsal eylemler, kullanıcının Test Altındaki Uygulamanın (TAU) bağlamsal durumunu değiştirdiği eylemleri ifade eder. Mobil cihazın global niteliklerinin birleşimi (internet bağlanırlığı, bluetooth durumu, konum, uçak modu ve uyku modu) uygulamanın o anki bağlamsal durumunu oluşturur. Bağlanırlık eylemi mobil cihazın internet bağlanırlığını ayarlar (Wi-Fi veya mobil veri). Bluetooth durumu, konum ve uçuş modu nitelikleri açık ve anlaşılırdır. Uyku eylemi mobil cihazı güç düğmesine basarak uyku moduna alan veya uyku modundan çıkaran eylemdir. Uyku eylemi test edilen uygulamayı duraklatmak ve devam ettirmek için kullanılır. Özel (special) eylem olarak da uygulamayı yeniden yükleyip başlatmaya yarayan yenidenbaşlatmak
Tablo 1. GKA Eylemler Listesi (reinitialize) bulunmaktadır. Sistem olayları sistem tarafından oluşturulan olaylardır; örneğin, pil seviyesi olayları, SMS almak, ve saat/süreölçer olayları gibi.
Son olarak, bir çökmeyi Android sistem kayıtlarında görülen bir ölümcül hata (fatal exception) olarak tanımlıyoruz. Çökmeler, sıklıkla test edilen uygulamanın bir uyarıyla veya uyarısız bir şekilde sonlanmasıyla sonuçlanır. Bazı çökmeler ise yürütmeyi görsel olarak etkilemez, fakat test edilen uygulama sonuç olarak çalışmayı durdurur.
Bir GKA durumu veya kısaca bir durum v aşağıdaki ögelerin bitiştirilmesinden (concatenation) oluşur. 1. Paket adı 2. Aktivite adı 3. Bağlamsal durum 4. GKA bileşenleri
Her durum v için GKA bileşenlerinden elde edilebilen bir etkin eylemler kümesi (v) vardır. Bir GKA eylemi veya kısaca eylem z 2 Z, ancak ve ancak bir v durumunun GKA bileşenlerinden en az biri ile ilişkilendirilebiliyorsa, z eylemi v durumunda etkindir, kısaca z 2 (v), denilir. Bir geçiş, (başlangıç-durumu, bitişdurumu, eylem) olacak şekilde üçlü değişkenler grubu (tuple) olarak tanımlanır. Bir yürütme izi (execution trace) veya kısaca iz (trace) t, bir geçişler dizisidir. Örneğin n uzunluğa sahip bir iz aşağıdaki gibi olabilir.
t = (v1; v2; z1); (v2; v3; z2); : : : ; (vn; vn+1; zn)
Eğer bir iz t’nin ilk durumu, TAU başlatıldığı andaki GKA durumu olan ilk durum v0 ile aynıysa, t bir test örneği dir (test case). Sınama örneklerini içeren kümelere test kümesi (test suite), kısaca T K denilir.
Bu bölümde AFM aracının akış çizelgesi açıklanmaktadır. Akış çizelgesinin daha iyi anlaşılması açısından bir örnek üzerinden detaylı açıklamalar da bulunmaktadır.
Şekil 1. AFM Aracının Akış Çizelgesi (Flowchart) Şekil 1, AFM aracının akış çizelgesini göstermektedir. İlk olarak AndroFrame’in model öğrenme altyapısını kullanarak Test Altındaki Uygulamaların (TAU) sonlu-durum modelleri çıkarılmaktadır. Bu modeller üzerinden genişliköncelikli arama (breadth-first search) yöntemi ile her uygulamanın her farklı aktivitesine giden en kısa izler belirlenir. Daha sonra bu izler AndroFrame’in yeniden çalıştırma (replay) özelliği kullanılarak mobil cihaz üzerinde birer birer çalıştırılır. Her izin çalıştırılmasından sonra, belli bir süre boyunca Monkey çalıştırılarak çökme tespiti ve kapsama analizi yapılır. Monkey’in her aktivite için çalıştırılma süresi, TAU modeli için çıkarılmış izlerin sayısı ile ters orantılıdır. Diğer test araçlarıyla adil bir kıyaslama yapılabilmesi adına AFM’nin çalışma süresi sabit tutulmuş (10 dakika), her iz sonunda Monkey çalıştırma süresi de bu sabit sürenin iz sayısına bölünmesi ile hesaplanmıştır.
Şekil 2, internetteki açık kodlu F-Droid [
uzuntıklama menü
tıklama geri metin tıklama v7/a4 tıklama2 v4/a3
tıklama,uzuntıklama geri
tıklama1 v2/a1 metin
tıklama1 uzuntıklama uzuntıklama
Tablo 2’de, Şekil 2 üzerinde genişlik-öncelikli arama sonucu bulunmuş en kısa izler gösterilmektedir. Bu izlerin her biri uygulamanın 5 farklı aktivitesinden birine gitmektedir. AFM 10 dakika çalıştırılacağından, her izin çalıştırılıp ardından Monkey kullanılması için ikişer dakika ayrılmıştır. Monkey’in sadece bir kere 10 dakikalığına ilk durumdan çağrılmasına kıyasla AFM yöntemi, uygulamanın sonlu-durum modelindeki bütün aktiviteleri kapsamayı garanti etmektedir. Ayrıca Monkey’in tek başına çağrıldığında v3 durumundan geri dönüş yapmak Şekil 3. AndroFrame, Monkey, ve AFM Deney Sonuçları mümkün olmazken, AFM yönteminde iki dakikanın bitiminde hemen başka bir izin çalıştırılmasına geçilir. 4
Bu bölümde AFM’nin kıyaslanması için gerçekleştirdiğimiz deneylerin içeriği ve sonuçları açıklanmaktadır.
Deneylerin çalıştırılması için Android Debugging Bridge (adb) aracının en yeni versiyonu kurulmuştur. Deneyler emulasyon ortamında, Android 4.4.2 versiyonu üzerinde koşulmuştur.
Adil bir kıyaslama yapabilmek adına AndroFrame, Monkey, ve AFM
araçlarının her biri her TAU üzerinde 10 dakika çalıştırılmıştır. Çökme tespiti ve kapsam
analizi kıyaslamaları için 20 adet Android uygulaması F-Droid [
Android GKA Test deneylerinde başarım kriteri olarak ortalama aktivite kapsaması ve çökme tespit sayılarına bakmaktayız. Deneylerimizin rastgelelik içermesinden ötürü tüm deneylerimizi üçer kere tekrarlayıp sonuçlarımızın tekrar ortalamasını Şekil 3 ile raporlamaktayız. AFM, Monkey’e ve AndroFrame’e kıyasla daha fazla hata tespitinde bulunmaktadır. Bunun temel nedeni AFM’nin derinliklerdeki aktivitelerde de çok hata tespiti yapabilen Monkey aracını çalıştırabilmesidir. AFM’nin aktivite kapsaması yine Monkey ve AndroFrame’e göre daha iyi çıkmıştır. AFM, algoritması gereği AndroFrame’in ulaştığı tüm aktivitelere ulaşmaktadır. Bu aktivitelerde Monkey çalıştırılması sonucu daha önce keşfedilmemiş yeni aktivitelere gidilmiştir. Böylece AFM’nin aktivite kapsaması AndroFrame aracına göre daha yüksek çıkmıştır. Sonuç olarak, AFM, 20 adet Android uygulaması içerisinde AndroFrame’e kıyasla %2 daha fazla aktivite kapsamasına ulaşıp ortalamada fazladan yaklaşık 21 çökme tespit etmiştir. Monkey’e kıyasla ise %24 daha fazla aktivite kapsamasına ulaşıp ortalamada fazladan yaklaşık 5 çökme tespit etmiştir.
Monkey sayıca diğer test araçlarına göre daha çok sayıda çökme tespit eden basit
bir rastgele test yaratım aracıdır [
Monkey AndroFrame’e göre daha az aktivite kapsamasına ulaşabilmektedir. Bunun nedeni Şekil 2 ile verilen modelden kolayca anlaşılabilir. Monkey, çok sayıda çökme tespit etmesine rağmen geri dönüşü mümkün olmayan durumlara takılı kaldığı ya da sayıca çok olay arasından aktivite geçişi için gerekli olanı tutturamadığı için, TAU derinliklerinde kalan başka aktivitelere erişememektedir. AFM’yi, Monkey aracının bu aktivitelerde de çalıştırılmasının çökme tespit sayısını artıracağı fikrinden yola çıkarak önermekteyiz.
Monkey hakkındaki bir diğer sorun ise Monkey ile üretilen testlerin kolayca
yeniden çalıştırılabilir betikler (replayable script) haline getirilememesidir [
Monkey çalıştırırken yaratılan bir testte çökmeye hangi olayın neden
olduğuna karar vermek açık bir problemdir [
AndroFrame modüler bir test yaratım aracıdır. AndroFrame içerisinde derinlik-öncelikli, rastgele, ve makine-öğrenmesi tabanlı arama stratejileri kodlanmıştır. Bu çalışmamızda AndroFrame makine-öğrenmesi tabanlı arama yöntemiyle çalıştırılmıştır. AndroFrame içerisindeki makine-öğrenme modülü aktivite kapsamasını artıracak olan olaylara öncelik verecek şekilde eğitilmiştir. Bu sayede AndroFrame, Monkey’e göre daha yüksek aktivite kapsamasına ulaşmaktadır.
AndroFrame’in öğrendiği sonlu-durum modeli tam değildir. Dolayısıyla öğrenilmiş modellerden çıkarılan izlerin istenilen aktivitelere gittiklerini doğrulayıp, 0 2 iis 15 y a iteS 10 v it k A 5 0 x1000 200 0 0 1 0 0 5 0 4 d toeM 03 x000 02 1 0 1 0 Test
F−Droid
Test
F−Droid
Test
F−Droid Test
F−Droid
Test
F−Droid Şekil 4. Test ve F-Droid Uygulama Karakteristiklerinin Dağılımları eğer istenilen aktiviteye ulaşılamamış ise model öğrenirken kullanılan test örneklerinden o aktiviteye ulaştığı bilinen izlerden birini seçmek ilerisi için pratik bir çözüm olabilir. 5.3
Deneylerimizde emulasyon ortamından yararlanmaktayız. Emulasyon ortamı şarj bitmesi gibi sistem olaylarını doğru yansıtmayabilir. Deneylerimizde kullandığımız eylemlerin hepsi emulasyon ortamında desteklenmektedir. Ayrıca tüm araçların aynı koşullar altında çalıştırılması deneylerimizin kuvvetini artırmaktadır.
F-Droid uygulamaları [
F-Droid uygulamaları Mart 2016 ayı itibariyle 4021 adettir ve bu sayı gün geçtikçe artmaktadır. İndirdiğimiz 4021 uygulamadan deneylerimiz için 20 taneyi rastgele seçmiş bulunmaktayız. Seçtiğimiz uygulamaların F-Droid uygulamalarının genelini temsil ettiğini gösterebilmek adına bu uygulamaların komut, metod, aktivite, ve izin sayıları ile megabayt cinsinden boyutlarını ölçtük. Şekil 4 ve Tablo 3, test ettiğimiz 20 uygulamanın (test kümesi) ve tüm F-Droid uygulamalarının karakteristiklerini göstermektedir.
Aktivite kapsaması ölçümü, Android testlerinde yaygın olarak
kullanılmaktadır [
Boyut (MB) 1000 x Komutlar 1000 x Metodlar # Aktiviteler # İzinler fazla ekranı keşfetme anlamına gelmektedir. Daha fazla ekranı keşfetmek ise, uygulamanın daha çok işlevini kapsamaktadır. Bu yüzden, yaratılan test örneklerinin TAU’nun daha çok işlevini kapsaması için daha yüksek aktivite kapsamasını hedeflemekteyiz. Aktivite kapsamasının avantajı, uygulamanın kaynak kodunun değiştirilmesine (instrumentation) gerek duymamasıdır. Komut kapsaması gibi diğer yaygın olarak kullanılan ölçümleri yapabilmek için TAU’nun kaynak kodunun değiştirilmesi gerekmektedir.
Çökme sayıları ve kapsama ölçümleri, yalnızca deney ortamımızda
kullanılan test etme algoritmasından etkilendiği için, gözlemlerimizin içsel geçerliliği
(internal validity) korunmaktadır. Test araçlarının adil bir karşılaştırmasını
yapabilmek adına, çökme ve aktivite kapsamasını bütün araçlarda aynı yöntemleri
kullanarak ölçmekteyiz. Doğruluğu artırmak amacıyla, diğer test araçları da
ortalama olarak benzer bir hızla olay oluşturduğu için, Monkey’i de iki saniyede
bir olay oluşturacak şekilde çalışmaya zorladık. F-Droid uygulamaları, Android
GKA testi çalışmalarında yaygın olarak kullanılmaktadır [
Gözlemlerimiz dışsal geçerliliğini (external validity) de korumaktadır. Kullandığımız uygulamaları, F-Droid uygulama kümesinden rastgele olarak indirdik. Kullandığımız uygulamaların rastgeleliği, çeşitliliği ve sayısı, bu uygulamalar üzerindeki deney sonuçlarının dışsal olarak genellenebilir olduğunu göstermektedir. Uygulama kümemiz, haber, eğlence ve iletişim defteri uygulamaları gibi çeşitli alanlardaki uygulamalardan oluştuğu için kapsamlıdır. Ayrıca kullandığımız TAU’ların ortalama karakteristik özelliklerini de Şekil 4 ile göstermekteyiz. Bu karakteristiklere sahip olduğu sürece, verilen bütün TAU’lar için benzer sonuçları almayı beklemekteyiz. 6
İlgili Çalışmalar AndroFrame test aracını, Test Altındaki Uygulamaların (TAU) sonlu-durum modellerini öğrenmek için kullanmaktayız. AndroFrame yetenekleri itibariyle aşağıda anlatılan son model (state-of-the-art) test araçlarıyla karşılaştırılabilir durumdadır.
A3E [
CrashScope [
SwiftHand [
PUMA [
Baek and Bae [
Bu çalışmamızda model öğrenen AndroFrame aracımızı Monkey ile karma olarak çalıştırarak daha çok aktiviteyi kapsayıp çökme tespit performansını iyileştirdik. Karma yöntemimiz 20 adet Android uygulaması içerisinde AndroFrame’e kıyasla %2 daha fazla aktivite kapsamasına ulaşıp fazladan 21 çökme tespit etmiştir. Monkey’e kıyasla ise %24 daha fazla aktivite kapsamasına ulaşıp fazladan 5 çökme tespit etmiştir.
İlerideki çalışmalarımızda deney sayısını artırmayı, diğer test araçları ile kıyaslama yapmayı, ve deneyleri AndroFrame’in diğer arama stratejileri için de uygulamayı planlıyoruz. Ayrıca, Monkey ile üretilen testlerin yeniden çalıştırılabilir hale getirilip testlerin yeniden çalıştırılarak çökme tespitlerinin doğrulanması da başlıca izleyeceğimiz araştırma yolları arasındadır.
Kaynaklar