Как известно, тестовое покрытие – наиболее важная метрика анализа качества проверяемого ПО. Она являет собой весьма ценную структуру, которая выражается в процентном эквиваленте и отображает текущий уровень плотности покрытия проверками, установленные технические требования или исполняемость написанного программного кода.
Как проверить коробку
Действительно ли нужно оценивать?
Все метрики тестирования – пустая трата ресурсов и сил. На всем протяжении этого времени можно анализировать продукт, находить баги, писать автотесты и прочее.
Но все же, какую именно величину несут метрики тестового покрытия, на которые тестировщики порой выделяют значительную часть своего рабочего времени?
- Нахождение «мертвых» зон. Конечно, всем нужно знать, в какой части программного обеспечения есть проблемы.
- Очень редко по итогам проверки у нас получается 100% показатель продуктивности разработки. Но что тогда исправлять и улучшать? Какой подход подобрать? Насколько увеличился процент эффективности? Как скоро мы получим пресловутые 100%? Все эти вопросы так или иначе связаны с прозрачностью и понятностью процесса тестирования, а вот ответы на них как раз и кроются в оценке качества.
- Фокусировка внимания. Давайте представим, что в вашей сборке есть около 40 функциональных уровней. Появляется новая версия, вы начинаете неспешно тестировать самый первый и сразу же находите в нем баги, пару пикселей вниз и прочие странности. Время на тесты вышло, данная функциональность тщательнейшим образом проверена… А прочие 40? Именно оценка полноценного покрытия позволяет нам максимально приоритизировать задачи исходя из масштабов работы и установленных клиентом сроков.
Логика тестового покрытия
Как верно оценивать?
Перед тем как проводить работу по внедрению выбранной метрики, нужно понять, как вы будете ее использовать. Сначала ответьте именно на этот вопрос – и вы сразу поймете, как лучше всего поступить.
На практике есть два наиболее масштабных и действенных подхода к оценке степени покрытия продукта автоматическими тестами: методика покрытия установленных предписаний (другими словами, что-то схожее с проверкой черного ящика) и работа с программным кодом (процесс тестирования классического белого ящика).
- Покрытие требований – уровень оценки покрытия продукта теста для проверки как производительных, так и нефункциональных требований, устанавливаемых перед разрабатываемым ПО путем создания матриц трассировки.
- Покрытие кода – способ анализа покрытия разработанного кода тестовыми кейсами путем поиска непроверенных на стадии тестирования частей разрабатываемого программного продукта.
Деятельность покрытия тестами программного кода, бесспорно, является наиболее важной метрикой для максимального обеспечения качества при работе с тестируемой средой, особенно когда речь заходит о проверке продукта с очень сложной логикой или большим объемом написанного кода.
Работы для проверки кода, как правило, выполняются с помощью широкого перечня доступного функционального инструментария, благодаря которому можно качественно отследить, какие ветки программного кода были проверены, а какие остались незамеченными при проведении автотестов.
Так, особой популярностью пользуются следующие инструменты:
Именно благодаря анализу покрытия кода можно создать «плотную» базу автоматических тестов для проверки программного компонента, который был передан в отдел QA для тщательнейшего анализа и проверки. При создании базы автотестов мы можем точно оценить плотность покрытия исполняемого кода тестируемой утилиты (ответ на вопрос – какой именно объем тестирования выполняют автотесты).
Процесс покрытия тестами
Кроме этого, при максимально детальном анализе проводимой проверки, команда по обеспечению качества запросто может оценить плотность и качество покрытия тестами отдельных частей сборки и/или ее компонентов (ответ на вопрос – в каком объеме и что именно мы протестировали).
То есть, активно применяя данную методику, мы сразу поймем, для каких проверок нужно создавать новые тестовые случаи, а для каких – просто удалить повторяющиеся проверки, что значительно сэкономит время для финального релиза, а также уменьшит бюджет на разработку. Ну и качество кода соответственно повысится.
Работа по покрытию кода тестами – занятие, что ярко показывает, насколько в процентном соотношении написанный программный код был проверен.
Методика покрытия программного продукта тестами по праву считается одной из самых первых методик для глобального систематического тестирования. Отчет о ее зарождении ведется с 1963 года, когда в публикацию попали первые материалы, касающиеся правильности составления документации для проверки технических продуктов.
Виды измерения покрытия продукта тестами
На сегодняшний день существует сразу несколько типов измерения тестового покрытия, базовыми из которых являются:
- Работа с операторами – каждая ли строчка программного кода была выполнена согласно ТЗ и максимально протестирована на работоспособность?
- Плотность покрытия установленных условий – все ли решения и наработки были выполнены и протестированы?
- Тестирование путей – все ли потенциально допустимые пути выполнения программного кода были проверены и максимально качественно протестированы?
- Работа с функциями – все ли допустимые значения были проанализированы и выполнены?
- Тестирование программных комбинаций – все ли заданные условия и технические комбинации были проверены и выполнены согласно установленной технологической документации?
Во время оценки качества покрытия тестами программного кода производится работа с применением специальных настроек, утилит и даже целых библиотек, которые запускаются и функционируют в однородной среде, чтобы максимально плотно и качественно проверить выполняемость, работоспособность и качество любой из написанных и внедренных функций, логик и технических возможностей.
Подобная работа не только положительно сказывается на общей работоспособности разрабатываемого продукта, но также позволяет разработчикам проверить целостность функций и строк кода, которые при нормальной работе ПО редко используются или играют сугубо второстепенные роли.
Компании по контролю качества могут применять итоги проверки для максимально плотного покрытия разработки вспомогательными тестами или тестовыми данными.
Использование на практике
Традиционно, написанный код подкрепляется тестами, призванными, по идее, всегда выполняться.
Подобный отчет позволяет провести максимально качественный анализ для выяснения, есть ли в продукте невыполняемые области кода. Если да, то совокупность тестового покрытия расширяется и все записанные проверки прогоняются повторно.
Базовая цель данного подхода – получить максимально широкий набор тестов для проведения процедуры регрессивного тестирования, в процессе которого тщательным образом проверяется функциональность каждой строчки написанного кода.
Планка покрытия составленного кода тестами выражается соотношением процентов готового и протестированного функционала.
К примеру, «мы провели тест на 60% кода». Смысл данного высказывания заключается в том, как критерий оценки продукта был использован. Например, 60% тестирования путей будет лучше, чем 60% работы операторов.
Процедура покрытия разработки тестами по своей сути является процессом проверки white box.
Проверяемое ПО собирается в одной виртуальной среде, запускается с целью нахождения недочетов или ошибок. Такая методика позволяет разработчикам и QA найти части платформы, которые при адекватном воспроизведении платформы используются весьма редко или вообще никогда не применяются.
На практике, все инструменты и подключаемые библиотеки, применяемые для максимального покрытия кода, требуют существенных затрат по общей производительности, которые в принципе недопустимы при обыкновенном функционировании программного обеспечения. А значит, применяться они могут исключительно в специализированных условиях.
Зонтики
Управленческое тестирование
Разработка тестов на основе управления – наиболее распространенная методика тестирования пресловутого white box, которая разработана на базе логики выполнения программного кода и разработки выполняемых тест-кейсов для максимального покрытия этих путей.
Основой для данного подхода считается разработка графиков потоков управления, внутри которых основными частями считаются:
- Блок работы – 1 точка входа и 1 точка выхода.
- Альтернативная точка – 1 точка входа и более 2 точек выхода.
- Соединительная точка – 2 и более точек входа, 1 точка выхода.
Для проведения тестирования потоков управления QA используют следующие уровни проверяемого покрытия:
| Планка | Наименование | Краткая характеристика |
|---|---|---|
| Нулевой уровень | — | Тестируем все то, что видим, а остальное пусть тестирует клиент |
| Первый уровень | Работа с операторами | Каждый оператор должен выполняться минимум один раз |
| Второй уровень | Работа с альтернативными частями (ветви) | Альтернативный узел должен выполняться минимум один раз |
| Третий уровень | Работа с условиями | Есть возможность создать условия и альтернативы для каждого проверяемого случая |
| Четвертый уровень | Работа с множественным числом условий | Полная выполняемость альтернатив, условий и логики альтернатив |
| Пятый уровень | «Бесконечное» число путей | Даже если число путей достигает бесконечного исчисления, они все равно должны выполняться |
| Шестой уровень | Работа с путями | Каждый путь должен быть тщательно проверен |
Работая по подобной таблице (методике), вы как сотрудник отдела QA можете качественно спланировать свой будущий уровень тестового покрытия.
Итак, в завершение анализа работы над «идеальным» тестовым покрытием можно выделить аспекты, на которые всегда стоит обращать внимание:
- общая функциональность;
- юзабилити;
- техническая безопасность;
- надежность;
- сопровождаемость.
Конечно же, каждый из вышеописанных критериев имеет ряд дополнительных пунктов и подпунктов. И в данный список особенностей можно добавлять разнообразные характеристики и наработки, которые были приняты на вооружение именно на вашем проекте.
Каждая разработка – уникальна и требует максимально индивидуального подхода к процессу создания полноценного тестового покрытия. И пока еще не придумали универсального сборника по разработке мультифункционального тестового покрытия.
Но каждый уважающий себя тестировщик должен четко понимать, с какой стороны подходить к проверке той или иной системы. Он должен оперативно распоряжаться доступным функционалом и предоставленными ресурсами, а также сосредотачивать свою работу на проверке наиболее уязвимых частей разрабатываемого продукта.
Оставить комментарий