Android Посібник з тестування додатків за допомогою Automation Framework
Томас Гамільтон
⚡ Розумний підсумок
Android Тестування додатків перевіряє збірку на фрагментованому ландшафті пристроїв, поєднуючи перевірки модулів, інтеграції, операційної діяльності та системи з фреймворками автоматизації, які працюють або на пристрої, або безпосередньо на JVM.
Чому Android Тестування?
Android є найбільшою операційною системою у світі. У той же час, Android фрагментований: існує безліч пристроїв і Android версії, з якими має бути сумісна ваша програма.
Неважливо, скільки часу ви вкладаєте в дизайн та впровадження, помилки неминучі, і баги з'являться.
Android Стратегія тестування
Правильно Android Стратегія тестування повинна включати наступне
- Тестовий блок
- Інтеграційний тест
- Operaнаціональний тест
- Тест системи
Блокові тести
Модульні тести – це набори програм, призначених для перевірки атомарної одиниці вихідного коду, такої як метод або клас.
Команда Android платформа попередньо інтегрована з JUnit 3.0 фреймворк. Це фреймворк з відкритим кодом для автоматизації Unit Testing, і це дозволяє розробникам писати ефективні програми для модульного тестування.
Доповненням до модульного тестування є тести інтерфейсу користувача (UI). Вони охоплюють компоненти інтерфейсу користувача вашої цільової програми та гарантують, що вона повертає правильний вивід для послідовності дій користувача на пристрої.
Поширений спосіб проведення тестів інтерфейсу користувача на пристрої – це Android Вимірювальні прилади. Але це має проблеми з продуктивністю. Один із найкращих інструментів для тестування інтерфейсу користувача Android is Robotium.
⚠️ Примітка до версії: JUnit 3 класи, такі як InstrumentationTestCase були застарілими в API 24; поточні проекти використовують AndroidХ-тест, Espresso та Автоматизатор інтерфейсу користувача. 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 Структура тестування
- Robolectric Testing framework
Android рамки тестування
Один із стандартних фреймворків для тестування Android додатки є Android тестова основа. Вона добре інтегрована з Android Інструменти SDK, а їхня архітектура складається з трьох частин.
- Пакет застосунків – це ваш цільовий застосунок, який потрібно протестувати.
- InstrumentationTestRunner – це Тестовий випадок виконавець, який виконує тестові випадки в цільовій програмі. Він включає:
- Інструменти тестування: Інструменти SDK для створення тестів. Вони інтегровані в IDE або запускаються з командного рядка.
- MonkeyRunner: Інструмент, що надає API для написання програм, що керують Android пристрій або емулятор за межами Android Код.
- Тестовий пакет організовано в тестові проекти та відповідає певній домовленості про іменування. Якщо тестований застосунок має назву пакета «com.mydomain.myapp», то тестовий пакет має бути «com.mydomain.myapp.test». Тестовий пакет містить 2 об’єкти:
- Класи тестових випадків: включати методи тестування, які будуть виконані в цільовій програмі.
- Фіктивні об'єкти: включіть макетні дані, які будуть використані як зразки вхідних даних для тестових випадків.
Android Тестові класи
- Тестовий випадок включає JUnit методи запуску JUnit тест
- TestSuite використовується для запуску набору тестових випадків
- InstrumentationTestSuite — це TestSuite, який вводить інструментарій в InstrumentationTestCase перед його запуском.
- InstrumentationTestRunner запускає тестові випадки в цільовій програмі.
- AndroidТестовий випадок розширюється JUnit Тестовий випадок з методами доступу до ресурсів, таких як контекст активності.
- ApplicationTestCase перевіряє класи Application у контрольованому середовищі.
- InstrumentationTestCase перевіряє певну функцію або поведінку, наприклад, вивід інтерфейсу користувача застосунку.
- ActivityTestCase – це базовий клас, який підтримує тестування активностей застосунку.
- ProviderTestCase — це клас для тестування одного ContentProvider.
- ServiceTestCase тестує класи сервісів у тестовому середовищі та підтримує життєвий цикл сервісу.
- SingleLaunchActivityTestCase використовується для тестування окремої активності (Activity) за допомогою InstrumentationTestCase.
- АктивністьUnitTestCase використовується для тестування окремої ізольованої активності.
- ДіяльністьІнструментарійТестовий випадок2 розширює JUnit Клас TestCase та з'єднує вас із цільовою програмою за допомогою інструментарію, щоб ви могли отримати доступ до компонентів графічного інтерфейсу та надсилати події інтерфейсу, такі як натискання клавіш або дотики.
Нижче наведено приклад ActivityInstrumentationTestCase. Він перевіряє роботу інтерфейсу користувача програми Calculator та коректність виводів інтерфейсу.
Robolectric платформа тестування
Тестування за допомогою Android Тестування за допомогою фреймворку з пристроєм або емулятором є складним. Створення та запуск тестів відбувається повільно та вимагає значних зусиль розробника. Щоб вирішити цю проблему, є ще один варіант: фреймворк для тестування Robolectric.
Robolectric дозволяє вам бігати Android тестує безпосередньо на JVM без потреби в пристрої чи емуляторі.
Класи Robolectric Test Case
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
