Тестирование компонента в Android-приложении SDLC?

"Автоматическое тестирование является неотъемлемой частью жизненного цикла разработки".

В проектах андроид-приложений мы реализовали MVP, Rx с Retrofit и Content Provider/SQLite, кинжал. Все приложения для Android всегда будут иметь связь с сервером, хранение данных в локальной базе данных, сложный ui, такой как ящик навигатора и просмотр ресайклеров и т.д., И сложный поток навигации приложения.

Чего мы хотим достичь?

  • Несколько тестовых примеров, которые нужно тестировать каждый раз, прежде чем мы доставим apk клиенту или выпустим в Play Store (20-30% автоматизировать тестирование)
  • Список тестовых примеров бизнес-логики, которые не могут быть проверены автоматически, потому что любая причина, например, сложный ui, поток навигации и т.д. (ручное тестирование 40-60%)
  • Непрерывная интеграция

Исходя из вышеизложенного, есть несколько вопросов,

  • Что нужно проверить в авто и руководстве, как это решить?
  • В автоматическом тестировании, где тестировать в MVP - уровни Model-View-Presenter?
  • Какая общая бизнес-логика должна автоматически тестироваться для мобильных приложений - например, регистрация, вход в систему, забытый пароль, обновление профиля и т.д.?
  • Какой тип тестирования должен выполняться для приложений Android - модульное тестирование, функциональное тестирование, интеграционное тестирование, ручное тестирование, тестирование производительности, регрессионное тестирование.
  • Какой инструмент использовать - библиотека поддержки тестирования Android, эспрессо, uiautomator, Robotium, roboelectric, appium, selendroid, mockito, JUnit

(Не стесняйтесь улучшать контрольный список, так как мы не знаем лучших практик для тестирования модуля в SDLC для мобильного приложения Android.) Первоначально было задано здесь.

ОТВЕТЫ

Ответ 1

Некоторые ответы на ваши вопросы:

  • Авто и ручное: после того, как были разработаны схемы разработки /dev, автоматические тесты должны быть частью доставки кода перед выпуском. Хороший триггер здесь просто включает тестирование пользовательского интерфейса в определении дела на истории, прежде чем они будут отправлены. Для Android это может быть так же просто, как некоторые тесты Espresso, которые охватывают новые функции.

  • Проверка уровня MVP... unit test ваши ведущие и пользовательский интерфейс проверяют ваши взгляды. который охватывает почти все в моделях, которые не работают, потому что изменения модели редко выполняются в изоляции этих двух слоев. высокий уровень охвата в презентаторе помогает сбалансировать количество тестов пользовательского интерфейса. см. эту статью для углубленного руководства.

  • бизнес-логика: по крайней мере, ВСЕ задачи на критических путях, которые пользователи предпринимают для достижения ключевых целей (т.е. ваш поток доходов, базовое принятие). Так что да, это включает в себя функции регистрации, входа и пароля... но может не охватывать все настройки/настройки и их эффекты.

  • тип тестирования: каждый тип тестирует разные уровни/аспекты вашего приложения, поэтому спросите себя, "какие детали в слоях моего приложения должны меня волновать"?

    • предназначен для базовой проверки кода, так что да, всегда. это просто базовая эффективность dev. высокий охват кода помогает вам быстро ловить ошибки. Интеграция
    • : да, и зависит от того, насколько сложно ваше приложение, но тестирование приложения с зависимостями/без зависимостей помогает изолировать тех, кто виноват, когда тест не удался.
    • функциональные тесты (тесты UI): да, простые взаимодействия или полный рабочий процесс, но это о том, как ваши пользователи работают с вашим приложением. некоторые функции приложения не могут быть протестированы без прохождения ряда других шагов. опять же, согласовываться с фактическим потреблением и ожиданиями бизнеса. сопоставьте свой объем работы с реальностью, показатели использования, влияние на доход и т.д.
    • производительность: это сложно, и есть разные школы мысли. мы видим, что выполнение "проверок" на этом пути необходимо, но полные циклы тестирования производительности часто препятствуют развитию, если в команде /org нет высокой степени зрелости и процесса.
    • регрессия: не оставляйте регрессию до огромной задачи до конца! меньшие наборы регрессии, информированные об изменениях, которые вы внесли, помогают уменьшить количество дефектов, обнаруженных при повторном тестировании в конце цикла. ранее означает меньшее, и не забывайте, что мы имеем дело с очень фрагментированной экосистемой Android, поэтому в регрессионную стратегию необходимо включить несколько устройств/платформ/условий.

  • tools: вы довольно много прибивали текущую инструментальную цепочку. для тестирования Android UI, Espresso/Dagger/mockito - огромная победа. держите эти типы тестов небольшими и целенаправленными. для сквозного тестирования Appium по-прежнему является вашим лучшим другом, но есть вещи, которые даже он не может сделать (например, визуальная проверка и определенные всплывающие окна), которые вам нужно искать за их пределами для автоматизации.

Кроме того, хотя я полностью понимаю ваше утверждение "не может быть проверено автоматически, потому что по какой-то причине", я думаю, что большой красный флаг и детали имеют большое значение. Выбор автоматического и ручного должен быть бизнес-решением о том, как достичь целей скорости, а не технических ограничений и недостатков. Я все время слышу от клиентов, пока они не осознают, что правильная технология позволяет им достичь уровня автоматизации, который им подходит.

В этом году мне помогли два исследования, которые, я думаю, помогут в этом разговоре:

Надеюсь, что это и мои исследования выше помогут вашей работе.