Каковы недостатки автоматизированного тестирования?

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

Вот некоторые из них, которые я придумал:

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

Править
Я должен сказать, что я большой сторонник автоматизированного тестирования, и я не хочу быть убежденным, чтобы сделать это. Я стремлюсь понять, в чем недостатки, поэтому, когда я иду в свою компанию, чтобы обосновать это, я не выгляжу так, будто разбрасываю следующую воображаемую серебряную пулю.

Кроме того, я не ищу кого-то, кто бы оспаривал мои примеры выше. Я считаю, что должны быть некоторые недостатки (у всех есть компромиссы), и я хочу понять, что это такое.

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

• Время разработки: При разработке через тестирование это уже рассчитано для модульных тестов, но вам все еще нужны интеграционные и системные тесты, которые также могут нуждаться в коде автоматизации. Код, написанный один раз, обычно тестируется на нескольких последующих этапах.

• Уровень навыков: конечно, инструменты должны поддерживаться. Но это не только ваша собственная команда. В более крупном проекте у вас может быть отдельная группа тестирования, которая пишет тесты для проверки интерфейсов между продуктом вашей команды и продуктами других. Так много людей должны иметь больше знаний.

• Необходимые инструменты: вы на месте. Не так много, чтобы добавить к этому.

• Неудачные тесты: это настоящий пижон (для меня в любом случае). Существует множество разных причин, каждая из которых может рассматриваться как недостаток. И самым большим недостатком является время, необходимое для того, чтобы решить, какая из этих причин действительно относится к вашему проваленному тесту.

  • не удалось из-за реальной ошибки. (только для полноты, поскольку это, конечно, выгодно)
  • не удалось, потому что ваш тестовый код был написан с традиционной ошибкой.
  • не удалось, потому что ваш тестовый код был написан для более старой версии вашего продукта и больше не совместим
  • не удалось, потому что требования изменились, и протестированное поведение теперь считается «правильным»

• Не провальные тесты: это тоже недостаток и может быть довольно плохим. В основном это происходит, когда вы меняете вещи и приближаетесь к тому, что ответил Адам. Если вы изменяете что-то в коде вашего продукта, но тест не учитывает это вообще, то это дает вам «ложное чувство безопасности».

  Важным аспектом несостоявшихся тестов является то, что изменение требований может привести к тому, что предыдущее поведение станет недействительным. Если у вас приличная прослеживаемость, изменение требований должно соответствовать вашему тестовому коду, и вы знаете, что больше не можете доверять этому тесту. Конечно, поддержание этой прослеживаемости является еще одним недостатком. И если вы этого не сделаете, вы получите тест, который не провалится, но на самом деле проверяет, что ваш продукт работает неправильно . Где-то в будущем это ударит вас ... обычно, когда / где вы меньше всего этого ожидаете.

• Дополнительные расходы на развертывание. Вы не просто запускаете юнит-тесты как разработчик на своем компьютере. С помощью автоматизированных тестов вы хотите выполнять их по коммитам других в каком-то центральном месте, чтобы узнать, когда кто-то сломал вашу работу. Это хорошо, но также должно быть настроено и поддержано.

Я только начал пробовать автоматизированные тесты в нашей команде, и самым большим недостатком, который я увидел, является то, что его очень трудно применить к устаревшему коду, который не был разработан с учетом автоматизированного тестирования. Это, несомненно, улучшило бы наш код в долгосрочной перспективе, но уровень рефакторинга, необходимый для автоматизированного тестирования при сохранении здравомыслия, является очень высоким барьером для входа в краткосрочной перспективе, что означает, что мы должны быть очень избирательными в отношении внедрения автоматизированного тестирования. модульное тестирование для выполнения наших краткосрочных обязательств. Другими словами, намного сложнее погасить кредитные карты, когда вы уже глубоко в долгах.

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

Я бы не сказал, что это вполне применимые недостатки, но я столкнулся с несколькими из них:

• Время, необходимое для настройки теста в сложном корпоративном приложении.
• Неправильная обработка старых тестов, другими словами, система эволюционировала, и теперь эти тесты ошибочны.
• Ложная уверенность от пятнистого или неизвестного тестового покрытия.

Повсеместное тестовое покрытие может привести к ложному ощущению безопасности. Если вы проводите рефакторинг и используете тесты, чтобы доказать его достоверность, что доказало, что ваши тесты способны это доказать?

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

Конечно, моя точка зрения - это приложение, которое старше, чем его модульные тесты.

Я бы сказал, что главная проблема с ними заключается в том, что они могут дать ложное чувство безопасности . Если у вас есть модульные тесты, это не значит, что они на самом деле что-то делают, и это включает в себя правильное тестирование требований.

Кроме того, автоматизированные тесты могут также включать сами ошибки , поэтому возникает вопрос о том, нужно ли тестировать себя самим, чтобы тестировать что-либо.

Хотя автоматическое тестирование имеет много преимуществ, оно имеет и свои недостатки. Некоторые из недостатков:

• Требуется умение писать сценарии тестирования автоматизации.
• Отладка тестового сценария является серьезной проблемой. Если в тестовом скрипте присутствует какая-либо ошибка, иногда это может привести к смертельным последствиям.
• Техническое обслуживание теста является дорогостоящим в случае методов воспроизведения. Несмотря на незначительные изменения в графическом интерфейсе, тестовый сценарий необходимо перезаписать или заменить новым тестовым сценарием.
• Обслуживание файлов тестовых данных затруднено, если тестовый скрипт тестирует больше экранов.

Некоторые из вышеперечисленных недостатков часто умаляют выгоду, получаемую от автоматизированных сценариев. Хотя тестирование автоматизации имеет свои плюсы и минусы, оно широко применяется во всем мире.

Недавно я задал вопрос о тестах в разработке игр - это кстати, как я узнал об этом. Ответы там указали на некоторые любопытные, конкретные недостатки:

1. Это дорого делать, когда ваш код должен быть тесно связан .
2. Это трудно сделать, когда вам необходимо знать о различных аппаратных платформах, когда вам нужно проанализировать вывод для пользователя, а результат кода имеет смысл только в более широком контексте .
3. Тестирование UI и UX очень сложно .
4. И, в частности, автоматизированные тесты могут быть более дорогими и менее эффективными, чем набор очень дешевых (или бесплатных) бета-тестеров .

4-й пункт заставляет меня вспомнить некоторый мой опыт. Я работал в очень скудной, ориентированной на XP, управляемой Scrum компании, где настоятельно рекомендовались юнит-тесты. Однако, на пути к более скромному, менее бюрократическому стилю, компания просто пренебрегла созданием команды QA - у нас не было тестеров. Так часто клиенты находили тривиальные ошибки при использовании некоторых систем, даже с охватом тестирования> 95%. Поэтому я бы добавил еще один момент:

• Автоматические тесты могут дать вам понять, что QA и тестирование не важны.

Кроме того, в те дни я думал о документации и представил гипотезу, которая может быть верна (в меньшей степени) для тестов два. Я просто почувствовал, что код развивается так быстро, что довольно трудно создавать документацию, которая следует такой скорости, поэтому более ценно тратить время на то, чтобы сделать код читабельным, чем написание тяжелой, легко устаревшей документации. (Конечно, это не относится к API, а только к внутренней реализации.) Тест немного страдает от той же проблемы: он может быть слишком медленным для записи по сравнению с тестируемым кодом. OTOH, это меньшая проблема, потому что тесты предупреждают, что они устарели, а ваша документация будет молчать, пока вы не перечитываете ее очень, очень осторожно .

Наконец, иногда я сталкиваюсь с проблемой: автоматическое тестирование может зависеть от инструментов, и эти инструменты могут быть плохо написаны. Я начал проект с использованием XUL некоторое время назад, и, боже, просто больно писать модульные тесты для такой платформы. Я запустил другое приложение, используя Objective-C, Cocoa и Xcode 3, и модель тестирования на нем была в основном кучей обходных путей.

У меня есть другой опыт относительно недостатков автоматического тестирования, но большинство из них перечислены в других ответах. Тем не менее, я яростный сторонник автоматизированного тестирования. Это избавило от огромной работы и головной боли, и я всегда рекомендую ее по умолчанию. Я считаю, что эти недостатки - всего лишь детали по сравнению с преимуществами автоматизированного тестирования. (Важно всегда провозглашать свою веру после того, как вы прокомментируете ереси, чтобы избежать auto da fé.)

Два, которые не упомянуты:

• Продолжительность времени, которое может потребоваться для запуска большого набора тестов

Я участвовал в автоматизированной работе по обеспечению качества, когда тестирование проводилось полдня, потому что тесты были медленными. Если вы не будете осторожны в написании своих тестов, ваш набор тестов также может оказаться таким же. Это не имеет большого значения до тех пор, пока вы не управляете тем временем: «О, я только что исправил ошибку, но это займет 4 часа, чтобы доказать правильность».

• Слабость некоторых методов написания теста

Некоторые методы тестирования (например, автоматизация пользовательского интерфейса), кажется, ломаются каждый раз, когда вы поворачиваетесь. Особенно больно, если ваш сценарий, скажем, зависает в процессе тестирования, потому что он ожидает появления кнопки - но кнопка была переименована.

Обе эти вещи можно обойти с помощью хорошей практики тестирования: найдите способы обеспечить быстрый набор тестов (даже если вам приходится выполнять такие хитрости, как распределение тестовых прогонов по машинам / процессорам). Аналогичным образом, можно позаботиться о том, чтобы избежать хрупких методов написания тестов.

Я хочу добавить еще одно, ложное чувство безопасности.

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

Трудно убедить менеджмента / венчурного капиталиста

• Testautomation увеличивает первоначальную стоимость.
• Testautomation увеличивает время выхода на рынок.
• польза от завещания приходит в середине и в середине срока. Жесткая конкуренция больше ориентирована на краткосрочные выгоды.

см. Market Driven Unit Testing для получения более подробной информации.

Один из главных недостатков можно преодолеть с помощью самообучающихся тестов. В этой ситуации все ожидаемые результаты сохраняются в виде данных и могут быть обновлены с минимальным просмотром пользователем набора тестов в режиме самообучения (показать разницу между старым ожидаемым результатом и новым фактическим результатом - обновление ожидается, если нажать y). Этот режим обучения в тестовом комплекте следует использовать с осторожностью, чтобы ошибочное поведение не воспринималось как приемлемое.