Самым большим расходом на автоматическое тестирование, вероятно, является время. Есть много очень дорогих инструментов, но есть и бесплатные инструменты. Стоимость даже дорогого инструмента вряд ли будет соответствовать стоимости времени, необходимого для правильной настройки автоматического тестирования. Пока руководство понимает, что требуются значительные авансовые затраты, и готово их оплатить, следите за ними при фактической автоматизации тестов:
Ловушки
ремонтопригодность
Долгосрочные затраты на автоматизацию в форме технического обслуживания. Помните, что автоматизированное тестирование - это разработка программного обеспечения . Это означает, что у вас есть все те же потенциальные проблемы, что и у любого другого программного обеспечения. Это также означает, что к автоматизированному тестированию применимы те же методы улучшения сопровождения программного обеспечения. (Вот почему я считаю все эти «профессиональные» инструменты, использующие vbscript вместо правильного языка OO, мусором.)
Автоматизированное тестирование также имеет свои особые проблемы с ремонтопригодностью. Самая большая проблема в том, что вы используете пользовательский интерфейс вместо API. Если вам когда-либо приходилось использовать нестабильный API, вы могли бы начать понимать, насколько сложно запускать программу через постоянно меняющийся интерфейс. К счастью, решение этой проблемы известно, если не всегда хорошо реализовано: сопоставление объектов. В основном у вас есть слой, который соединяется с пользовательским интерфейсом с одной стороны и кодом с другой. Сторона кода остается максимально стабильной, в то время как сторона пользовательского интерфейса может меняться так часто, как это необходимо.
Пример из фреймворка, над которым я работаю:
public Image GoImage
{
get { return Browser.Image(Find.ById("BtnGo")); }
}
В этом примере используется WatiN. При этом я пишу строки в таких сценариях, как GoImage.Click(), и если идентификатор тега изображения когда-либо изменяется, я не изменяю все свои сценарии, я только обновляю отображение.
Тесты, которые не должны быть автоматизированы
Не каждый тест должен быть автоматизирован. Иногда для автоматизации теста может потребоваться больше времени, чем для его запуска вручную. Если это тест, который вы собираетесь выполнить только один или несколько раз, лучше не автоматизировать его вообще. Вы можете уменьшить это, создав способы быстрого создания автоматизированных тестов. Если это уместно, автоматизация тестирования на основе данных - отличный способ сделать это. С помощью нашей инфраструктуры автоматизации тестирования мы можем создавать новые тесты, изменяя около десятка строк в электронной таблице Excel.
Вы также должны колебаться при создании тестовых сценариев, которые только частично автоматизированы. Чаще всего это происходит, когда вы можете автоматизировать шаги теста, но проверка должна быть выполнена вручную. Теоретически, вы можете получить некоторое увеличение скорости, позволяя автоматизации пролетать через пользовательский интерфейс и останавливаться, пока пользователь выполняет свои проверки, но психология мешает. Большинство людей отключаются, когда автоматизация работает, и им требуется столько времени, чтобы выяснить, что они должны проверять, так же как им нужно было бы просто выполнить весь тест вручную.
Подход
Как я уже говорил, автоматизированное тестирование - это разработка программного обеспечения, так что вы подходите к нему. Вот самый простой дизайн для автоматизации тестирования, который я нашел:
Интерфейсная библиотека
Вам нужно что-то, что позволит вам программно контролировать пользовательский интерфейс. Это та часть, которую коммерческие инструменты имеют тенденцию делать хорошо, но недавно появились проекты с открытым исходным кодом, которые также хорошо справляются с этим. Для интерфейсов Windows есть белый . Я никогда не использовал его, но мне нравится API. Веб-автоматизация действительно принадлежит инструментам с открытым исходным кодом, таким как watir и WatiN .
Framework
Framework - это общий термин для всего, что вам нужно создать самостоятельно. Отображение объектов, вспомогательные функции, управляемые данными скрипты. Коммерческие инструменты пытаются предоставить их для вас, но я никогда не нашел инструмент, который делает именно то, что мне нужно. Я всегда катаюсь здесь. Именно здесь проходит большая часть работ по обслуживанию, поэтому я так недоволен инструментами, которые используют слабые языки, такие как vbscript. Я предпочитаю создавать фреймворки с использованием .NET.
Test Runner
Вам нужно что-то для запуска тестов. Коммерческие инструменты обеспечивают это, и здесь они делают достаточно хорошо. Но они на самом деле не лучше, чем программа модульного тестирования. Да, NUnit так же полезен для автоматического тестирования пользовательского интерфейса, как и для модульного тестирования. Вы также можете довольно легко написать пользовательский тестовый прогон.
Ведение журнала и результаты
Вам нужен какой-то способ узнать, был ли тест успешным или нет. Почти любая существующая библиотека журналирования, такая как log4n / log4j, будет работать. У тестовых бегунов также обычно есть это встроенное. Коммерческие инструменты обычно также хороши в результатах, пока вы избегаете проприетарных форматов.
Тестовые сценарии
Очевидно, вам нужны сами тесты.
И последнее, что я хочу сказать. Автоматизация тестирования может сократить время, необходимое для выполнения того же объема тестирования, но она работает лучше, если у вас есть намерение проводить больше тестирования за то же время.