Защо тестване на Android?
Android е най-голямата операционна система в света. В същото време Android е фрагментиран. има много устройства и версии на Android, с които приложението ви трябва да е съвместимо.
Няма значение колко време инвестирате в проектиране и изпълнение, грешките са неизбежни и ще се появят грешки.
В този урок ще научите -
- Защо тестване на Android?
- Стратегия за тестване на Android
- Единични тестове
- Интеграционни тестове
- Експлоатационни тестове
- Тестове на системата
- Автоматизирано тестване на Android
- Рамка за тестване на Android
- Роболектрична рамка за тестване
- Митове за тестване на Android
- Най-добри практики в Android Testing
Стратегия за тестване на Android
Правилната стратегия за тестване на Android трябва да включва следното
- Единичен тест
- Тест за интеграция
- Оперативен тест
- Тест на системата
Единични тестове
Единичните тестове включват набори от една или повече програми, предназначени да проверят атомна единица на изходния код, като метод или клас.
Платформата за Android идва с предварително интегрирана рамка Junit 3.0. Това е рамка с отворен код за автоматизиране на Unit Testing. Android Testing Framework е мощен инструмент за разработчика да напише ефективната програма за модулно тестване.
Интеграцията на Android и JUnit рамка
Допълнение към Unit Testing са тестовете на потребителския интерфейс (UI). Тези тестове са свързани с UI компоненти на вашето целево приложение. Тестовете на потребителския интерфейс гарантират, че вашето приложение връща правилния изход на потребителския интерфейс в отговор на последователност от действия на потребителя върху устройството.
Общи действия на потребителския потребителски интерфейс върху приложението
Общият начин за тестване на потребителския интерфейс на устройството е Android Instrumentation. Но това има проблеми с производителността. Един от най-добрите инструменти за провеждане на тестване на потребителски интерфейс на Android е Robotium.
Интеграционни тестове
При интеграционното тестване всички модулни тестове се комбинират и проверяват. В Android тестовете за интеграция често включват проверка на интеграция с компоненти на Android като тестване на услуги, тестване на активност, тестване на доставчик на съдържание и т.н.
Видове тест за интеграция на Android
Има много рамки за тестване, които се използват за провеждане на интеграционен тест за Android като Troyd, Robolectric, Robotium.
Експлоатационни тестове
- Експлоатационните се наричат още функционални тестове или тестове за приемане. Те са тестове на високо ниво, предназначени да проверят пълнотата и коректността на приложението.
- В Android FitNesse е рамка с отворен код, която улеснява провеждането на оперативни тестове за целево приложение.
Тестове на системата
При тестване на системата системата се тества като цяло и се проверява взаимодействието между компонентите, софтуера и хардуера.
В Android системното тестване обикновено включва
- GUI тестове
- Тестове за използваемост
- Тестове за ефективност
- Стрес тестове
В горния списък на тестването на ефективността е обърнат по-голям фокус. Можете да използвате инструменти като Traceview за провеждане на тест за ефективност на Android. Този инструмент може да ви помогне да отстраните грешки в приложението си и да профилирате неговата ефективност.
Автоматизирано тестване на Android
Тъй като Android е фрагментиран, е необходимо тестване на множество устройства. Но това също ще ви струва пари. Автоматизираното тестване на Android може да помогне за намаляване на разходите
Предимства на автоматизираното тестване на android
- Намалете времето за изпълнение на тестови случаи
- Увеличете производителността на вашия процес на развитие
- Ранно откриване на грешки, спестете разходи за поддръжка на софтуера
- Намерете бързо и отстранете грешките при изпълнението
- Осигурете качеството на софтуера
Ще проучим следните 2 рамки
- Рамка за тестване на Android
- Роболектрична рамка за тестване
Рамка за тестване на Android
Един от стандартните рамки за изпитване на заявление Android е тестване рамка Android . Това е мощна и лесна за използване рамка за тестване, която е добре интегрирана с инструментите за Android SDK.
Архитектура на рамката за тестване на Android
- Пакетът за приложения е вашето целево приложение, което трябва да бъде тествано
- InstrumentationTestRunner е бегач на тестови случаи, който изпълнява тестов случай на целевото приложение. Включва:
2а) Тестови инструменти: Инструменти за SDK за изграждане на тест. Те са интегрирани в Eclipse IDE или се изпълняват като команден ред.
2b) MonkeyRunner: Инструмент, който предоставя API за писане на програма, която контролира устройство с Android или емулатор извън кода на Android.
- Тестовият пакет се организира в тестови проекти. Този пакет следва конвенцията за именуване. Ако тестваното приложение има име на пакет "com.mydomain.myapp", тогава тестовият пакет трябва да бъде "com.mydomain.myapp.test". Тестовият пакет включва 2 обекта, както е показано по-долу:
3а) Класове на тестови случаи: включват тестови методи, изпълнявани в целевото приложение.
3б) Фиктивни обекти: включва фалшиви данни, които ще бъдат използвани като примерни данни за тестови случаи.
Класове за тестови случаи на Android
Диаграма на класа на AndroidTestCase
- TestCase включва JUnit методи за стартиране на JUnit тест
- TestSuite се използва за стартиране на набор от тестови случаи
- InstrumentationTestSuite е TestSuite, който инжектира Instrumentation в InstrumentationTestCase, преди да ги стартира.
- InstrumentationTestRunner е бегач на тестови случаи, който изпълнява тестов случай на целевото приложение.
- AndroidTestCase разширява JUnit TestCase. Той съдържа методи за достъп до ресурси като контекст на дейността.
- ApplicationTestCase проверява класовете на приложения в контролирана среда.
- InstrumentationTestCase проверява определена характеристика или поведение на целевото приложение, например, проверява изхода на потребителския интерфейс на приложението.
- ActivityTestCase е основен клас, който поддържа тестване на Приложните дейности.
- ProviderTestCase е клас за тестване на единичен ContentProvider.
- ServiceTestCase се използва за тестване на класове за обслужване в среда за тестване. Той също така поддържа жизнения цикъл на услугата.
- SingeLauchActivityTestCase се използва за тестване на единична активност с InstrumentationTestCase.
- ActivityUnitTestCase
се използва за тестване на единична изолирана активност. - ActivityInstrumentationTestCase2
разширява класа JUnit TestCase. Той ви свързва към целевото приложение с инструментариум. С този клас можете да осъществите достъп до GUI компонента на приложението и да изпратите UI събитие (натискане на клавиш или събитие при докосване) към потребителския интерфейс.
По-долу е даден пример за ActivityInstrumentationTestCase. Той проверява работата на потребителския интерфейс на приложението Калкулатор, проверява коректността на изходите на потребителския интерфейс.
Пример за тестване на ActivityInstrumentationTestCase2
Роболектрична рамка за тестване
Тестването с помощта на Android Testing framework с устройство или емулатор е трудно. Тестът за изграждане и изпълнение е бавен и изисква много усилия за разработка. За да се реши този проблем, има друг избор - рамка за тестване на Robolectric .
Robolectric framework ви позволява да стартирате тестове за Android директно на JVM, без да е необходимо устройство или емулатор.
Предварителни функции на Robolectric
Роболектрични класове за изпитвания
Работа на Robolectric
- Както е показано по-горе, Robolectric може да извършва следните действия:
- Регистрирайте се и създайте клас Shadow
- Прихващайте зареждането на Android клас
- Използва javaassist, за да замени телата на методите от клас Android
- Обвържете Shadow обект с Android клас
- Това позволява на тествания код да се изпълнява без Android среда.
Други рамка за тестване
Освен тестовите рамки, които бяха споменати по-горе, има и много други тестови рамки като:
- Android Junit Report, персонализиран инструмент за тестване на инструментариум за Android, който генерира XML отчети за интеграция с други инструменти.
- Експресо
- Апиум
Митове за тестване на Android
Много предприятия разработват стратегии за тестване на android, които се основават на често срещани заблуди. Този раздел разглежда няколко популярни мита и реалностите на тестването на Android.
Мит # 1: Всички устройства с Android са еднакви ... тестът за емулатори е достатъчен
Нека започнем с прост пример. Приложението работи перфектно на емулатор, но на някои реални устройства се срива по време на изпълнение
Приложението се срива по време на изпълнение на реално устройство
Емулаторите не са достатъчни за вашето мобилно тестване. Трябва да тествате приложението си на реални устройства.
Мит # 2: Тестването на някои често срещани устройства е достатъчно
- На различни устройства вашето приложение изглежда различно, защото различните устройства имат различен хардуер, размери на екрана, памет и т.н. Трябва да тествате приложението си на различни устройства, версии на операционната система, мрежи и местоположения на оператора.
Мит 3: Достатъчно е проучвателно тестване непосредствено преди старта
- Като цяло при всички тестове ние проектираме тестовите случаи, след което ги изпълняваме. Но при изследователските тестове, проектирането и изпълнението на тестовете всичко ще бъде направено заедно.
- При изследователските тестове няма план и няма подготовка, тогава тестващият ще направи тестове, които иска да направи. Някои функции ще бъдат тествани многократно, докато някои функции няма да бъдат тествани изцяло.
Мит # 4: Ако има някои грешки в приложението, потребителите ще разберат
- Ако приложението не работи и има грешки, потребителите деинсталират приложението ви
- Проблемите с качеството са първата причина за лош преглед в Google Play. Това се отразява на вашата репутация и вие губите доверието на клиента.
Следователно е от съществено значение да има правилна стратегия за тестване на Android
Най-добри практики в Android Testing
- Разработчиците на приложения трябва да създават тестовите случаи по едно и също време, когато пишат кода
- Всички тестови случаи трябва да се съхраняват в контрол на версиите заедно с изходния код
- Използвайте непрекъсната интеграция и изпълнявайте тестове при всяка промяна на кода
- Избягвайте да използвате емулатори и вкоренени устройства