Что Ваш подход к тестированию iPhone / приложения для iPad?
Когда разработка для iPhone/iPad делает Вас
- Тестирование единицы/интеграции/и т.д.?
- Какую платформу (платформы) Вы используете?
- Что другую платформу (платформы) Вы попробовали (если Вы решили не использовать их, почему нет?)
ПРИМЕЧАНИЕ. Это основано на вопросе, спросил несколько дней назад (который был с тех пор в большой степени отредактирован). Вопрос генерировал некоторые интересные ответы, которые могут быть полезными для агрегации в одном месте.
5 ответов
Вот мой текущий подход к тестированию перед отправкой приложения.
1) Создавайте и анализируйте с помощью встроенного в Xcode анализатора Clang.
Это полезно во многих отношениях, оно выявляет множество мелких глупостей, а также некоторые утечки памяти (хотя иногда его результаты содержат ложные срабатывания).
2) Тщательно проверьте все предупреждения. Некоторые из них могут быть действительно вредными. По возможности удалите предупреждения.
3) Используйте инструменты для проверки утечек памяти, объема памяти во время выполнения и т. Д.
4) Используйте Shark для выявления проблем с производительностью, когда я чувствую, что это необходимо.
5) Выполните (вручную) всю предопределенную серию тестов, чтобы убедиться, что и пользовательский интерфейс, и базовый код работают должным образом. При добавлении новых функций в приложение всегда снова выполняйте регрессионные тесты, чтобы убедиться, что все работает плавно и правильно. Я давно отказался от модульных тестов из-за невероятного количества времени, необходимого для их настройки и запуска.
6) Отправьте специальную версию приложения альфа-тестерам, сообщив об исправлении ошибок, затем снова отправьте приложение альфа- и бета-тестерам и исправьте ошибки.
7) Финальный тест проведен лично на разных устройствах, на данный момент iPhone 3GS, iPhone 3G и iPod Touch.
- Нет
- Неприменимо
- Неприменимо
Честно говоря, я обнаружил, сколько работы требуется для создания единого блока тест, чтобы быть полной болью. Даже для самых простых тестов требуется масса насмешек. Кроме того, в iPhone было сложно разделить модели, представления и контроллеры. А учитывая, что мое приложение было довольно маленьким, оно не стоило времени.
Если / когда я писал что-то большее, я бы снова исследовал модульное тестирование.
С учетом сказанного, я провел тонну пользовательского тестирования и тестирования стиля. Наблюдая, как другие используют приложение (действительно полезно!), Я использую приложение и т. Д. Вы не сможете сэкономить там, если будете экономить на модульных тестах!
Я провел модульное тестирование своих приложений. Но поскольку у меня калькулятор, его проще тестировать по сравнению с другими более сложными приложениями. Я считаю, что это невероятно полезно, когда я нахожу случай, который не работает должным образом (обычно из-за ручного тестирования), затем я пишу тест, чтобы (надеюсь, неясный) случай всегда проверялся в будущем. Таким образом, я больше не буду повторять ошибки.
Лично я провожу только модульное тестирование классов и / или методов, которые имеют смысл для модульного тестирования и стоят затраченных усилий. На мой взгляд, это сводится к следующим типам кода:
- Чистые вычислительные алгоритмы
- Анализатор данных различных видов (файлы, интернет-данные и т. Д.)
- Методы, которые имеют отношение ввода / вывода
- И, наверное, еще об одном или двух я забыл.
Я редко использую модульное тестирование для тестирования кода, связанного с графическим интерфейсом пользователя.
До сих пор я использовал только платформу OCUnit / SenTesting, поставляемую с iPhone.
Я также обнаружил, что составление краткого контрольного списка того, что нужно сделать в процессе выпуска, компенсирует длительное тестирование. Часто проблемы в продукте возникают не из-за того, что напрямую связано с тестированием, а из-за небольших (забытых) шагов в процессе сборки / выпуска.
Единственное, что нужно сделать для тестирования, - это приложение Instruments, и то только иногда.