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