Автоматизиция тестирования

Тестирование — проверка соответствия между реальным и ожидаемым поведением программы.

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

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

Чтобы не проверять все возможные случаи вручную и быть уверенным, что «новая фича» не сломала часть приложения, можно без проблем и надо использовать автоматические тесты.

Написание автоматических тестов:

  • сократит время на проверку изменений;
  • сократит кол-во багов;
  • можно использовать многократно;
  • при неудаче покажет в каком месте приложения изменилось поведение;
  • будет подтверждением того, что приложение работает как задумано.

Из этого следует, что тесты следует писать в случае, если приложение будет изменяться и развиваться.

Как убедить заказчика платить за тестирование?

Никак. Просто расчитайте время с учетом написания тестов и не говорите ему про это. Хотя если у вас метод, можете поделиться им в комментариях.

Виды тестирования для разработчиков

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

Модульный тест(Unit test, Block test, Component test)

Модульный тест тестирует отдельный участок системы(возможность, процедуру, способ, класс или модуль) изолированый от внешних частей программы. Для изоляции модуля мы используем так называемые заглушки(stubs) и макеты(mocks) . Данные тесты выполняются быстро и в идеальном мире должны составлять большую часть всех тестов на проекте.

Интеграционный тест(Integration test, Backend test, Contract test, API driven test)

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

Функциональный тест(Functional or End-to-End test, GUI test, Walk-Through test)

Данные тесты в полном объеме эмулируют поведение посетителей. в браузере. Пишется пошаговый тест, как посетитель должен себя вести в приложении. На какую страницу приложения он зайдет, какую инфорацию заполнит, какую кнопку нажмет и т.д. Чаще всего такие тесты пишут тестировщики, но иногда и разработчики в зависимости от требований компании. Хорошим тоном будет, когда такие тесты можно без проблем запускать без GUI- оболчки, чтобы в дальнейшем можно без труда было использовать как часть процесса CI(Continuous Integration).

Ручное тестирование(Manual Testing)

Самый понятный вид тестирования. Надеюсь вы проверяете сделаную работу хотя бы так.

Тестирование на проекте

Чаще всего на проектах тестирование происходит примерно так:

Автоматизиция тестирования

Мануальное тестирование занимает львиную долю всех тестов на проекте, а иногда кроме мануального тестирования не используется ничего. Тестирование занимает много времени. Одни и теже действия необходимо делать при каждом релизе. Разработчики при создании новой фичи ломают старую функциональность.

Чтобы достичь хороших результатов необходимо действовать в следующем направлении:

Автоматизиция тестирования

Тестировщики занимаются автоматизацией функциональных тестов, а программисты тестируют часть при помощи юнит-тестов и интеграционных тестов.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *