Android Урок за тестване на приложения с рамка за автоматизация
Редакционен екип
⚡ Умно обобщение
Android Тестването на приложения проверява компилацията в рамките на фрагментирана среда от устройства, комбинирайки проверки на модули, интеграция, операционни и системни проверки с рамки за автоматизация, които се изпълняват или на устройство, или директно на JVM.
Защо Android Тестване?
Android е най-голямата операционна система в света. В същото време, Android е фрагментиран: има тонове устройства и Android версии, с които вашето приложение трябва да е съвместимо.
Няма значение колко време инвестирате в дизайна и внедряването, грешките са неизбежни и ще се появят бъгове.
Android Стратегия за тестване
Правилно Android стратегията за тестване трябва да включва следното
- Тест за единица
- Интеграционен тест
- Operaционален тест
- Тест на системата
Единични тестове
Модулните тестове са набори от програми, предназначени да проверят атомарна единица от изходния код, като например метод или клас.
- Android платформата е предварително интегрирана с JUnit 3.0 рамка. Това е рамка с отворен код за автоматизация Единично тестванеи позволява на разработчиците да пишат ефективни програми за модулни тестове.
Допълнение към модулното тестване са тестовете на потребителския интерфейс (UI). Те обхващат компонентите на потребителския интерфейс на целевото ви приложение и гарантират, че то връща правилния изход за поредица от потребителски действия на устройството.
Най-често срещаният начин за извършване на UI тестове на устройство е Android Инструментация. Но това има проблеми с производителността. Един от най-добрите инструменти за провеждане на тестване на UI Android is Robotium.
⚠️ Бележка към версията: JUnit 3 класа, като например InstrumentationTestCase бяха остарели в API 24; текущите проекти използват AndroidХ тест, Espresso и UI Automator. Robotium няма издания от 2016 г.
Интеграционни тестове
In Тестване на интеграцията, всички тествани модули се комбинират и проверяват. В Android Това често означава проверка на интеграцията с компоненти като тестване на услуги, дейности и доставчици на съдържание.
Много тестови рамки се използват за провеждане на интеграционни тестове за Android, като например Troyd, Robolectric и Robotium.
Operaционни тестове
OperaФункционалните тестове, наричани още функционални или приемателни тестове, са тестове на високо ниво, които проверяват пълнотата и коректността на приложението.
In Android, FitNesse е рамка с отворен код, която улеснява изпълнението на оперативни тестове срещу целевото приложение.
Системни тестове
In Тестване на системата системата се тества като цяло и се проверява взаимодействието между компонентите, софтуера и хардуера.
In Android, Тестването на системата обикновено включва
- GUI тестове
- Тестове за използваемост
- Тестове за производителност
- Стрес тестове
В горния списък, Тестване на производителността се обръща повече внимание. Можете да използвате инструменти като TracEview да провежда тестове за производителност на AndroidТози инструмент може да ви помогне да отстраните грешки в приложението си и да профилирате неговата производителност. Tracпрегледът вече е остарял в полза на Профилатор на процесора.
Автоматизирана Android Тестване
As Android е фрагментиран, необходимо е тестване на много устройства и това струва пари. Автоматизиран Android Тестването помага за намаляване на тези разходи.
Предимства на автоматизираното Android тестване
- Намалете времето за изпълнение на тестови случаи
- Увеличете производителността на вашия процес на разработка
- Ранно откриване на грешки, спестява разходи за поддръжка на софтуер
- Бързо намиране и отстраняване на грешки при внедряването
- Осигурете качеството на софтуера
Ще проучим следните 2 рамки
- Android Рамка за тестване
- Робоелектрическа рамка за тестване
Android рамка за тестване
Една от стандартните рамки за тестване за Android приложенията са Android рамка за тестване. Тя е добре интегрирана с Android SDK инструменти, а архитектурата му се състои от три части.
- Пакетът с приложения е вашето целево приложение, което трябва да бъде тествано.
- InstrumentationTestRunner е Тестов случай runner, който изпълнява тестови случаи на целевото приложение. Той включва:
- Инструменти за тестване: SDK инструменти за изграждане на тестове. Те са интегрирани в IDE или се изпълняват от командния ред.
- MonkeyRunner: Инструмент, който предоставя API за писане на програми, контролиращи Android устройство или емулатор извън Android код.
- Тестовият пакет е организиран в тестови проекти и следва конвенция за именуване. Ако тестваното приложение има име на пакет „com.mydomain.myapp“, тогава тестовият пакет трябва да бъде „com.mydomain.myapp.test“. Тестовият пакет включва 2 обекта:
- Класове тестови случаи: включете методи за тестване, които да бъдат изпълнени в целевото приложение.
- Фалшиви обекти: включете макетни данни, които ще бъдат използвани като примерни входни данни за тестови случаи.
Android Класове за тестови случаи
- Тестовият случай включва JUnit методи за изпълнение JUnit тест
- TestSuite се използва за изпълнение на набор от тестови случаи
- InstrumentationTestSuite е TestSuite, който инжектира Instrumentation в InstrumentationTestCase, преди да ги изпълни.
- InstrumentationTestRunner изпълнява тестове на целевото приложение.
- AndroidТестовият случай се разширява JUnit TestCase с методи за достъп до ресурси като Activity Context.
- ApplicationTestCase проверява класовете на Application в контролирана среда.
- InstrumentationTestCase проверява определена функция или поведение, например изхода на потребителския интерфейс на приложението.
- ActivityTestCase е базов клас, който поддържа тестване на дейностите на приложението.
- ProviderTestCase е клас за тестване на единичен ContentProvider.
- ServiceTestCase тества класове услуги в тестова среда и поддържа жизнения цикъл на услугата.
- SingleLaunchActivityTestCase се използва за тестване на единична активност с InstrumentationTestCase.
- ДейностЕдиницаТестовКасейс се използва за тестване на единична изолирана активност.
- ДейностИнструментиранеТестовСлучай2 разширява JUnit Клас TestCase и ви свързва с целевото приложение с инструментариум, така че да можете да осъществявате достъп до компоненти на графичния потребителски интерфейс и да изпращате събития от него, като например натискания на клавиши или докосвания.
По-долу е даден пример за ActivityInstrumentationTestCase. Той проверява работата на потребителския интерфейс на приложение Calculator и проверява коректността на изходите от потребителския интерфейс.
Robolectric тестова рамка
Тестване с помощта на Android Тестването на платформата с устройство или емулатор е трудно. Създаването и изпълнението на тестове е бавно и изисква много усилия за разработка. За да се реши този проблем, има друга възможност: платформата за тестване Robolectric.
Robolectric ви позволява да бягате Android тества директно върху JVM, без да е необходимо устройство или емулатор.
Robolectric тестови класове
Robolectric може да извършва следните действия:
- Регистрирайте се и създайте клас Shadow
- Прехващане на зареждането на Android клас
- Можете да използвате Javaпомага за презаписване на телата на методите на Android клас
- Свързване на Shadow обект към Android клас
Това позволява на тествания код да се изпълни без Android среда.
Други рамки за тестване
Освен споменатите по-горе рамки за тестване, има много други, като например:
- Android Доклад на Junit, програма за тестване на персонализирани инструменти за Android който генерира XML отчети за интеграция с други инструменти.
- Espresso
- Appium
Митове за Android Тестване
Много предприятия развиват Android Тестване стратегии, които се основават на често срещани погрешни схващания. Този раздел разглежда няколко популярни мита и реалности за Android тестване.
Мит №1: Всички Android устройствата са едни и същи, така че тестването на емулатори е достатъчно
Едно приложение може да работи перфектно на емулатори, но въпреки това да се срива по време на изпълнение на някои реални устройства.
Емулаторите не са достатъчни за мобилно тестване. Трябва да тествате приложението си на реални устройства.
Мит №2: Тестването на някои често срещани устройства е достатъчно
Приложението ви изглежда различно на различните устройства, защото хардуерът, размерите на екрана и паметта се различават. Тествайте на различни устройства, версии на операционните системи, мрежи на оператори и местоположения.
Мит №3: Проучвателното тестване непосредствено преди пускането на пазара е достатъчно
- В повечето тестове ние проектираме тестови случаи, след което ги изпълняваме; в проучвателното тестване проектирането и изпълнението се случват едновременно.
- Няма план или подготовка, така че тестерът изпълнява каквито тестове избере. Някои функции се тестват многократно, докато други никога не се тестват.
Мит №4: Ако в приложението има някои грешки, потребителите ще ги разберат
- Ако приложението не работи и има грешки, потребителите го деинсталират.
- Проблемите с качеството са първата причина за лоши отзиви в Google Играйте, уронвайки репутацията си и губейки доверието на клиентите.
Ето защо е от съществено значение да има подходящо Android въведена стратегия за тестване.
Най-добри практики в Android Тестване
- Разработчиците на приложения трябва да създават тестовите случаи едновременно с писането на кода
- Всички тестови случаи трябва да се съхраняват в контрола на версиите, заедно с изходния код
- Използвайте непрекъсната интеграция и изпълнявайте тестове при всяка промяна на кода
- Избягвайте да разчитате само на емулатори и руутвани устройства; потвърдете резултатите на реален хардуер с инспектор, като например uiautomatorviewer
