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

49

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

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

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

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

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

RationalGeek
источник
18
«Требуется сложный анализ ...» тест не является причиной сбоя, это индикатор. Сказать, что у вас нет тестов, означает, что не требуется сложный анализ отказов, это не лучше, чем застревать в грязи.
P.Brian.Mackey
1
* более длительное время сборки, когда тесты запускаются при каждой сборке, и повторение кода, когда тесты находятся на очень низком уровне (тестирование геттеров и сеттеров)
ratchet freak
2
1. если разработчик тратит время на тестирование новых функций, риск их отказа снижается, что означает, что ваш продукт более стабилен. 2. Хорошая вещь - научить членов вашей команды ориентироваться на тестирование, они могут использовать эти знания для других дел в работе (и в жизни). 3. Создайте автоматическую установку для тестовой среды. 4. Это говорит мне, что 1 тест делает слишком много.
CS01
1
Если тот же разработчик кодирует тесты, как и сам код, то он будет думать только о тех же тестовых примерах, для которых будут написаны тесты, о тех, о которых они думали, когда кодировали.
Пол Томблин
Я только что опубликовал ответ на соответствующий вопрос и чувствую, что должен хотя бы прокомментировать этот вопрос. ИМО, почти все недостатки, упомянутые здесь (и в ответах), выглядят ложными и вводящими в заблуждение, если мы говорим о реальном живом проекте, а не о чем-то, что вы быстро программируете и забываете. Я боюсь, что такой вопрос может быть использован в качестве предлога для разработки без автоматических тестов, и во многих случаях это приведет к гибели проекта или полной переустановке.
Борис Серебров

Ответы:

26

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

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

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

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

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

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

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

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

Фрэнк
источник
1
На неудачных тестах, если изменение требований приводит к сбою текущих тестов, тест проходит, потому что предыдущая реализация больше не действительна, если она не сработала, это будет означать, что реализация не соответствует требованиям ...
CS01
Случай 4 (b) - это основа разработки, основанной на тестировании: вы пишете неудачный тест, затем расширяете продукт, а затем проверяете, что это изменение делает тест успешным. Это защищает вас от ошибочно написанного теста, который всегда проходит успешно или всегда терпит неудачу.
Килиан Фот
@ Спасибо за ответ. Там много понимания. Я особенно ценил различия различных причин неудачных испытаний. Дополнительные затраты на развертывание - еще один отличный момент.
RationalGeek
Забавная вещь, которую я обнаружил, заключается в том, что мой коэффициент ошибок на LOC намного хуже для тестов, чем для реального кода. Я трачу больше времени на поиск и исправление ошибок тестирования, чем на настоящие. :-)
Брайан Кноблаух
не удалось, потому что ваш тестовый код был написан для более старой версии вашего продукта и больше не совместим - если ваши тесты ломаются из-за этого, то, скорее всего, ваши тесты проверяют детали внедрения, а не поведение. CalculateHighestNumber v1 должен по-прежнему возвращать тот же результат, что и CalculateHighestNumber v2
Том Сквайрс
29

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

Карл Билефельдт
источник
2
Как человек, который работает с 80% очень большой базы устаревшего кода, я не мог согласиться с этим. Однако, чтобы смягчить это, я использовал кое-что из этого в [ссылка] amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/… .
DevSolo
1
Это действительно хорошая книга, я многое из нее получил. Три основных момента, попробуйте, понемногу. Некоторые хорошие тесты лучше, чем никаких тестов. Оставайтесь в поле зрения, не проводите рефакторинг всего, что требует рефакторинга сразу. Будьте предельно ясны, где находятся границы между тестируемым и непроверяемым кодом. Убедитесь, что все остальные тоже это знают.
Тони Хопкинсон
21

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

Росс Паттерсон
источник
Хорошая мысль, Росс, это интересный способ выразить это.
RationalGeek
Согласен, хотя, по моему опыту, время, сэкономленное благодаря модульным тестам, мгновенно обнаружившим потенциальные ошибки во вновь написанном коде (т. Е. Регрессионные тесты), перевесило это дополнительное время обслуживания.
dodgy_coder
15

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

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

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

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

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

Адам Хоулдсворт
источник
ОП уже рассмотрел время и устаревший код в вопросе.
P.Brian.Mackey
@ P.Brian.Mackey на самом деле элемент времени субъективен. Время, затрачиваемое на кодирование теста, отличается от времени, необходимого для понимания требований теста и правильного кодирования теста.
Адам Хоулдсворт
@ AdamHouldsworth Спасибо, это хорошие примеры недостатков. Я действительно не рассматривал угол ложной уверенности.
RationalGeek
9

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

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

billy.bob
источник
Разработка через тестирование помогает в первую очередь, требуя провального теста перед написанием кода функции. Теперь вы знаете, что если функция сломается, тест будет сломан. Во-вторых, сложный тестовый код - это запах кода. Опять же, сначала написав тест, вы можете попытаться упростить его и поместить сложную работу в код функции, которая исправляет тест.
Дэвид Харкнесс
Код, который трудно проверить, не является запахом кода. Самый простой код для тестирования - это гигантская цепочка вызовов функций, маскирующихся под классы.
Эрик Реппен
4

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

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

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

jameswood037
источник
Благодарю. Хорошие моменты. Я отредактировал твой пост для грамматики и форматирования. Надеюсь, ты не возражаешь.
RationalGeek
3

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

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

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

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

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

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

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

brandizzi
источник
3

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

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

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

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

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

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

RyanWilcox
источник
2

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

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

Джим С
источник
0

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

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

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

k3b
источник
-1

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

Ричард Кей
источник