Home

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

В популярной культуре США снежный человек – это легендарное, скрытное создание, изредка наблюдаемое  на тихоокеанском северо-западе. В мире разработки ПО у нас есть своя версия снежного человека – раздражающие и иногда катастрофичные баги, которые трудно воспроизвести.

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

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

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

Вот как работает периодическая автоматизация.

ПО со множеством связей подвержено плавающим проблемам

Современное ПО имеет множество связей – как с компонентами в вашей сети, так и с серверами и компонентами вне ее. К примеру, аналитика, платежная система и сервисы социальных сетей часто находятся вовне сети вашего приложения. Опора на эти сервисы усложняет тестирование вашего окружения.

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

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

Чем чаще смотришь, тем больше видишь

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

Это базовый принцип периодической автоматизации: если чаще прогонять автотесты, выше шанс воспроизведения плавающих багов. Ее можно периодически запускать множеством способов – начиная с простого скрипта командной строки или .bat-файла, который запускается по таймеру, и заканчивая настроенным по расписанию событием в инструменте непрерывного развертывания. Это не должно быть чем-то неописуемо красивым, вам просто нужно чаще прогонять тесты.

Рожденный в академии

"Чем чаще смотришь – тем больше видишь" – это логика, но сердце этого подхода основано на науке. Воркшоп по преподаванию тестирования-2013 определил автоматизированное тестирование высокого объема (HiVAT) как "семейство техник тестирования, позволяющих создавать, прогонять и оценивать результаты сколь угодно многих тестов".

Одна из целей HiVAT – помочь выявить проблемы, связанные с определенным временем; они, как правило, плавающие и, следовательно, трудновоспроизводимы. Один из способов воспроизвести такие баги – использовать то, что в HiVAT называется "регрессионное тестирование длинной последовательности" (LSRT).

Этот подход прост:

• Выберите автоматизированные регрессионные скрипты, которые точно пройдут.
• Прогоняйте эти тесты в длинной последовательности (то есть прогоните каждый из них 1000 раз)
• Исследуйте падения.

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

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

Берегитесь усталости от падений

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

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

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

Три способа минимизировать эту усталость:

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

Подойдет ли это вам?

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

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

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

Обсудить в форуме