К основному контенту

Ручное и автоматизированное тестирование

В блоге "LoadTest тонкого и толстого клиента в VS" были описаны практические навыки автоматизированного нагрузочного тестирования. По этой причине в данном блоге рассмотрим классификацию тестирования по степени автоматизации.
На рис. 1 представлено всего 2 вида: ручное и автоматизированное, но в некоторых источниках встречается еще полуавтоматизированное тестирование.
Рисунок 1. Классификация тестирования
Ручное тестирование — тестирование, в котором тест-кейсы выполняются человеком вручную, без использования средств автоматизации. Это процесс поиска дефектов в работе программы, когда тестировщик проверяет работоспособность всех компонентов программы, как если бы он был пользователем. Для точности проверки, тестировщик использует заранее заготовленный план тестирования, в котором отмечены наиболее важные аспекты работы программы.
Автоматизированное тестирование - выполнение тестов, реализуемое при помощи заранее записанной последовательности тестов. Тест-кейсы частично или полностью выполняет специальное инструментальное средство, однако разработка тест-кейсов, подготовка данных, оценка результатов выполнения, написания отчётов об обнаруженных дефектах — всё это и многое другое по-прежнему делает человек. Главное преимущество
автоматизированного тестирования состоит в возможности повторного прогона тестов без участия человека.
Полуавтоматизированное тестирование – ручное тестирование с частичным использованием средств автоматизации - программного обеспечения (например, средств захвата/воспроизведения) для контроля выполнения тестов, сравнения полученных результатов с эталонными, установки предусловий тестов и других функций контроля тестирования и организации отчетов. 
Автоматизация начинается с ручного тестирования. То есть для того, чтобы начать процесс автоматизирования тестирования, нужно точно знать, что и как вы собираетесь делать. Идеальный автотест базируется на ручном тест-кейсе с должным уровнем детализации.
Я думаю, что начинать автоматизацию можно с регрессионного тестирования. Ведь тестирование компонентов, которые уже не должны изменяться (ни функционально, ни интерфейс), можно доверить программе, так как сократится время, затрачиваемое на проверку рабочей (по крайней мере должно так быть) части.
Необходимо правильно выбирать этап разработки ПО для автоматизирования тестирования (рис. 2). Иначе цена поддержки автотестов будет выше, чем их использование.
Рисунок 2. Диаграмма этапов разработки
Преимуществами автотестирования являются:
1) Скорость выполнения тест-кейсов может в разы и на порядки превосходить возможности человека.
2)  Отсутствие влияния человеческого фактора в процессе выполнения тест-кейсов (усталости, невнимательности и т.д.)
3) Минимизация затрат при многократном выполнении тест-кейсов (участие человека здесь требуется лишь эпизодически).
4) Способность средств автоматизации выполнить тест-кейсы, в принципе непосильные для человека в силу своей сложности, скорости или иных факторов. Ярким примером является нагрузочное тестирование, так как выполнять одновременно 1000 запросов, с 1000 машин и с длительностью в 24 часа, никто из людей не согласится =)
5) Способность средств автоматизации собирать, сохранять, анализировать, агрегировать и представлять в удобной для восприятия человеком форме колоссальные объёмы данных.
6) Способность средств автоматизации выполнять низкоуровневые действия с приложением, операционной системой, каналами передачи данных и т.д.
Но есть и недостатки:
·       Необходим высококвалифицированный персонал в силу того факта, что автоматизация — это «проект внутри проекта» (со своими требованиями, планами, кодом и т.д.)
·         Высокие затраты на сложные средства автоматизации, разработку и сопровождение кода тест-кейсов.
·         Автоматизация требует более тщательного планирования и управления рисками, т.к. в противном случае проекту может быть нанесён серьёзный ущерб.
·         Средств автоматизации крайне много, что усложняет проблему выбора того или иного средства и может повлечь за собой финансовые затраты (и риски), необходимость обучения персонала (или поиска специалистов).
·   В случае ощутимого изменения требований, смены технологического домена, переработки интерфейсов (как пользовательских, так и программных) многие тест-кейсы становятся безнадёжно устаревшими и требуют создания заново. 

Комментарии

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:   1) Test plan identifier (идентификатор);   2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования);   3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключе

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия – заключительные ша