Статическое и динамическое тестирование
По критерию запуска программы (исполняется ли программный код) выделяют еще два типа тестирования: статическое и динамическое.
1. Статическое тестирование
Статистическое тестирование –тип тестирования, который предполагает, что программный код во время тестирования не будет выполняться. При этом, само тестирование может быть как ручным, так и автоматизированным.
Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации. Для этого типа тестирования в некоторых случаях даже не нужен компьютер, например, при проверке требований.
Большинство статических техник могут быть использованы для «тестирования» любых форм документации, включая вычитку кода, инспекцию проектной документации, функциональной спецификации и требований.
Даже статическое тестирование может быть автоматизировано, например, можно использовать автоматические средства проверки синтаксиса программного кода.
Виды статического тестирования:
2. Динамическое тестирование
Динамическое тестирование – тип тестирования, который предполагает запуск программного кода. Таким образом, анализируется поведение программы во время ее работы.
Для выполнения динамического тестирования необходимо, чтобы тестируемый программный код был написан, скомпилирован и запущен. При этом, может выполняться проверка внешних параметров работы программы: загрузка процессора, использование памяти, время отклика и т.д., то есть ее производительность.
Динамическое тестирование является частью процесса валидации программного обеспечения.
Кроме того, динамическое тестирование может включать разные подвиды, каждый из которых зависит от:
Автоматическое тестирование программ
Введение
Долгое время считалось, что динамический анализ программ является слишком тяжеловесным подходом к обнаружению программных дефектов, и полученные результаты не оправдывают затраченных усилий и ресурсов. Однако, две важные тенденции развития современной индустрии производства программного обеспечения позволяют по-новому взглянуть на эту проблему. С одной стороны, при постоянном увеличении объема и сложности ПО любые автоматические средства обнаружения ошибок и контроля качества могут оказаться полезными и востребованными. С другой – непрерывный рост производительности современных вычислительных систем позволяет эффективно решать все более сложные вычислительные задачи. Последние исследовательские работы в области динамического анализа такие, как SAGE, KLEE и Avalanche, демонстрируют, что несмотря на присущую этому подходу сложность, его использование оправдано, по крайней мере, для некоторого класса программ.
Динамический vs Статический анализ
Применение
Автоматическое тестирование в первую очередь предназначено для программ, для которых работоспособность и безопасность при любых входных данных являются наиважнейшими приоритетами: веб-сервер, клиент/сервер SSH, sandboxing, сетевые протоколы.
Fuzz testing (фаззинг)
Фаззинг – методика тестирования, при которой на вход программы подаются невалидные, непредусмотренные или случайные данные.
Фаззеры нового поколения (обзор)
Логическим, но не таким простым продолжением идеи автоматического тестирования стало появление подходов и программ, позволяющих накладывать ограничения на мутируемые входные данные с учетом специфики исследуемой программы.
Отслеживание помеченных данных в программе
Вводится понятие символических или помеченных (tainted) данных – данных, полученных программой из внешнего источника (стандартный поток ввода, файлы, переменные окружения и т. д.). Распространенным решением этой задачи является перехват набора системных вызовов: open, close, read, write, lseek (Avalanche,KLEE).
Инструментация кода
Код исследуемой программы приводится к виду, удобному для анализа. Например, используется внутреннее независимое от аппаратной платформы представление valgrind (Avalanche) или анализируется удобный для разбора сам по себе llvm-байткод программы(KLEE).
Инструментированный код позволяет легко находить потенциально опасные инструкции (например, деление на ноль или разыменование нулевого указателя) и их операнды, а также инструкции ветвления, зависящие от помеченных данных. Анализируя инструкции, инструмент составляет логические условия на помеченные данные и передает запрос на выполнимость “решателю” булевских формул (SAT Solver).
Решение булевских ограничений
SAT Solvers – решают задачи выполнимости булевых формул. Отвечают на вопрос: всегда ли выполнена заданная формула, и если не всегда, то выдается набор значений, на котором она ложна. Результаты работы подобных решателей используется широким набором анализирующих программ, от theorem provers до анализаторов генетического кода в биоинформатике. Подобные программы интересны сами по себе и требуют отдельного рассмотрения. Примеры: STP, MiniSAT.
Моделирование окружения
Перебор путей в программе
O(2^n), где n – количество условных переходов, зависящих от входных данных), но все еще остается значительной. Анализаторы вынуждены использовать различные эвристики для приоритезации анализа некоторых путей. В частности, различают выбор пути, покрывающего наибольшее количество непокрытых (новых) базовых блоков (Avalanche, KLEE) и выбор случайного пути (KLEE).
Avalanche
Avalanche – инструмент обнаружения программных дефектов при помощи динамического анализа. Avalanche использует возможности динамической инструментации программы, предоставляемые Valgrind, для сбора и анализа трассы выполнения программы. Результатом такого анализа становится либо набор входных данных, на которых в программе возникает ошибка, либо набор новых тестовых данных, позволяющий обойти ранее не выполнявшиеся и, соответственно, еще не проверенные фрагменты программы. Таким образом, имея единственный набор тестовых данных, Avalanche реализует итеративный динамический анализ, при котором программа многократно выполняется на различных, автоматически генерированных тестовых данных, при этом каждый новый запуск увеличивает покрытие кода программы такими тестами.
Общая схема работы
Инструмент Avalanche состоит из 4 основных компонент: двух модулей расширения (плагинов) Valgrind – Tracegrind и Covgrind, инструмента проверки выполнимости ограничений STP и управляющего модуля.
Ограничения
Результаты
unsigned mod_opt ( unsigned x, unsigned y ) <
if ( ( y & −y ) == y ) // power of two?
return x & ( y− 1 ) ;
else
return x % y ;
>
unsigned mod ( unsigned x, unsigned y ) <
return x % y ;
>
int main ( ) <
unsigned x,y ;
make symbolic ( & x, sizeof ( x ) ) ;
make symbolic ( & y, sizeof ( y ) ) ;
assert ( mod ( x,y ) == mod_opt ( x,y ) ) ;
return 0 ;
>
Запустив KLEE на данном примере, можно убедится в эквивалентности двух функций во всем диапазоне входных значений (y!=0). Решая задачу на невыполнение условия в ассерте, KLEE на основе перебора всех возможных путей приходит к выводу об эквивалентности двух функций на всем диапазоне значений.
Результаты
Для получения реальных результатов тестирования авторы проанализировали весь набор программ пакета coreutils 6.11. Средней процент покрытия кода составил 94%. Всего программа сгенерировала 3321 набор входных данных, позволяющих покрыть весь указанный процент кода. Так же было найдено 10 уникальных ошибок, которые были признаны разработчиками пакета как реальные дефекты в программах, что является очень хорошим достижением, так как этот набор программ разрабатывается более 20 лет и большинство ошибок было устранено.
Ограничения
Предварительные выводы
Безусловно, динамический анализ найдет свою нишу среди инструментов помогающих отдельным программистам и командам программистов решать поставленную задачу, т.к. является эффективным способом нахождения ошибок в программах, а так же доказательством их отсутствия! В в некоторых случаях подобные инструменты просто жизненно необходимы (Mission critical software: RTOS, системы управления производством, авиационное программное обеспечение и так далее).
Общая картина модульного тестирования
Это не руководство, какие символы нужно ввести в редакторе кода, чтобы получились модульные тесты. Это — пища для ума, которую необходимо употребить до того, как предпринимать упомянутые действия.
Тема модульного тестирования не так проста, как может показаться. Многие из нас, разработчиков, приходят в модульное тестирование под давлением клиентов, сотрудников, коллег, своих кумиров и так далее. Мы быстро понимаем его ценность, и, закончив технические приготовления, забываем об общей картине, если вообще когда-либо её понимали. В этой статье я вкратце расскажу о том, чем является и чем не является модульное тестирование как в целом, так и в PHP, а заодно опишу, какое место занимает модульное тестирование в сфере QA.
Что такое тестирование?
Прежде чем углубляться в модульные тесты, нужно изучить теорию самого тестирования, чтобы не делать ошибок вроде той, что совершили авторы одного из самых популярных PHP-фреймворков: на своём сайте они показали интеграционные тесты и назвали их модульными. Нет, Laravel, это не модульные тесты. Хотя это не мешает мне всё ещё любить этот фреймворк.
Тестирование ПО определяется как «расследование, проведённое с целью предоставления заинтересованным сторонам информации о качестве продукта». Этому противопоставляется «тестирование ПО — это пустая трата бюджета проекта разработчиками, которые не делают ничего важного, а затем просят ещё времени и денег, потому что «ничего» может быть весьма дорогим». Тут ничего нового.
Вот моя краткая история становления тестирования:
Чем на самом деле является тестирование?
Есть разные классификации тестирования ПО. Чтобы лучше понимать место модульного тестирования, упомяну лишь о наиболее широкораспространённых подходах.
Тесты бывают: статические и динамические, «ящичные» (белый ящик, чёрный ящик, серый ящик), уровни и типы. В рамках каждого подхода используются разные критерии классификации.
Статическое и динамическое тестирование
Статическое тестирование проводится без исполнения кода. Сюда относится корректура, проверка, ревизия кода (при наблюдении за работой другого / парном программировании), критический анализ, инспекции и так далее.
Динамическое тестирование для получения корректных результатов требует исполнять код. Например, для модульных тестов, интеграционных, системных, приёмочных и прочих тестов. То есть тестирование проводится с использованием динамических данных, входных и выходных.
«Ящичный» подход
Согласно этому подходу, все тесты ПО делятся на три вида ящиков:
Уровни тестирования
Их количество варьируется, обычно, в диапазоне от 4 до 6, и все они полезны. Названия тоже бывают разные, в зависимости от принятой в компании культуры вы можете знать «интеграционные» тесты как «функциональные», «системные» тесты как «автоматизированные», и так далее. Для простоты я опишу 5 уровней:
Типы тестирования
Каждый тип тестирования, вне зависимости от его уровня, также может подразделяться на другие типы. Существует больше 20 общепринятых типов. Самые распространённые:
Теперь вы знаете, что модульные тесты являются динамическими, относятся к классу «белый ящик», выполняются на уровне модулей, представляют собой регрессионные тесты, но при этом под модульными тестами можно понимать многие разновидности тестов. Так что же такое на самом деле модульные тесты?
Что такое модульное тестирование?
V-модель — это графическое представление вышеупомянутых уровней, типов и их назначения в жизненном цикле разработки ПО.
После проверки и утверждения подробных требований к продукту, когда уже начали писать код, первой линией защиты от любых несоответствий становятся модульные тесты. Поэтому компании, понимающие, что они делают, заставляют разработчиков использовать модульные тесты или даже TDD, поскольку гораздо дешевле исправить баги на начальных этапах, чем на более поздних.
И это справедливо. У модульных тестов масса достоинств. Они:
Я часто обсуждал с коллегами и клиентами, что такое хороший модульный тест. Он:
Что нужно подвергать модульному тестированию?
В нормальных системах модульные тесты нужно писать для:
Так что вы сами можете определять, что для вас является модулем. Или можете тестировать методы один за другим, упростив жизнь тому парню, что потом будет работать с кодом.
Если вы не проводите модульное тестирование, предлагаю заняться этим после возникновения следующего большого бага. Проверьте, с каким методом он будет связан, напишите сбойный тест с правильными аргументами и результатом, исправьте баг, снова запустите модульный тест. Если он будет пройден, то можете быть уверены, что этот баг пришлось исправлять в последний раз (с учётом ваших определённых входных сценариев).
Такой подход помогает легче понять модульное тестирование. Проанализируйте отдельно каждый метод. Поставщики данных могут помочь определить входные и выходные данные для любых сценариев, которые могут прийти вам в голову, поэтому что бы ни произошло, вы будете знать, чего ожидать.
Что НЕ нужно тестировать
Чуть сложнее определить, что тестировать не нужно. Я постарался собрать список элементов, которые не нужно подвергать модульному тестированию:
Как писать модульные тесты?
Но ответить на первый вопрос (как писать код, пригодный для модульного тестирования) гораздо легче, и вряд ли ситуация сильно изменится со временем:
В заключение: модульные тесты очень важны как для разработчиков, так и для бизнеса. Их нужно писать, существуют отработанные методики, которые помогут вам легко покрыть модули тестами, в основном с помощью подготовки самих модулей. Но все эти методики не имеют смысла без знания теории тестирования, описанной в этой статье. Нужно уметь отличать модульные тесты от тестов других типов. И когда у вас в голове будет ясное понимание, то и писать тесты вам станет гораздо легче.
говориМ о тестировании
простым языком
Виды тестирования по запуску кода
Тестирование не всегда предполагает взаимодействие с работающим приложением. Отсюда и классификация тестирования по запуску кода на исполнителя.
По критерию запуска программы (исполняется ли программный код) выделяют 2 вида тестирования: статическое и динамическое.
Статическое тестирование
Статическое тестирование (static testing) — тестирование без запуска кода на исполнение.
Оно представляет собой процесс или технику, которые выполняются для поиска потенциальных дефектов в программном обеспечении. Это также процесс обнаружения и устранения ошибок и дефектов в различных сопроводительных документах (например, спецификации требований к программному обеспечению).
Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.
Можно поделить статическое тестирование на 2 типа:
1. Обзоры (Review)
2. Статический анализ (Static Analysis)
Обзоры
Обзоры (Review) – проверка обычно используется для поиска и устранения ошибок или неясностей в документах. Это могут быть требования, дизайн, тестовые случаи и так далее.
В свою очередь обзоры делятся на:
Статический анализ
Статический анализ (Static Analysis) – код, написанный разработчиками, анализируется на наличие структурных дефектов, которые могут привести к ошибкам.
Статический анализ включает оценку качества кода, написанного разработчиками. Для анализа кода и сравнения его со стандартом используются разные инструменты. Статический анализ хорошо помогает найти такие ошибки, как:
— неиспользуемые переменные,
— мертвый код,
— бесконечные циклы,
— переменные с неопределенными значениями,
— неправильный синтаксис.
Статический анализ состоит из 3-х частей:
Анализ может производится как вручную, так и с помощью специальных инструментов. Например, можно использовать автоматические средства проверки синтаксиса программного кода.
Целью анализа является наиболее раннее выявление ошибок и потенциальных проблем в программном продукте. Как правило, код ревью выполняется самим разработчиком.
Примерами ошибок, которые потенциально можно выявить с помощью автоматического статического тестирования, могут быть:
— утечки ресурсов (утечки памяти, неосвобождаемые файловые дескрипторы и т.д.),
— возможность переполнения буфера (buffer overflows),
— ситуации частичной (неполной) обработки ошибок.
Как правило, результатом автоматического анализа кода является список рекомендаций для ручного review некоторых участков кода, потенциально содержащих ошибки.
В рамках этого подхода тестированию могут подвергаться:
Плюсы и минусы
Преимущества статического тестирования
Недостатки статического тестирования
Динамическое тестирование
Динамическое тестирование (dynamic testing) — тестирование с запуском кода на исполнение. Запускаться на исполнение может как код всего приложения целиком (системное тестирование), так и код нескольких взаимосвязанных частей (интеграционное тестирование), отдельных частей (модульное или компонентное тестирование) и даже отдельные участки кода.
Основная идея этого вида тестирования состоит в том, что проверяется реальное поведение (части) приложения.
Проще говоря, динамическое тестирование выполняется путем фактического использования приложения и определения того, работает ли функциональность так, как ожидается.
Динамическое тестирование включает в себя тестирование ПО в режиме реального времени путем предоставления входных данных и изучения результата поведения программы. Проверка осуществляется с помощью ручного или автоматического выполнения заранее подготовленного набора тестов. Оно является частью процесса валидации программного обеспечения.
Если рассмотреть функции, предлагаемые динамическим тестированием, можно легко понять причины его выполнения в течение жизненного цикла тестирования программного обеспечения. С помощью этого тестирования можно проверить различные критические аспекты программного обеспечения. Если оставить их без какой-либо оценки, они могут повлиять на производительность, функционирование, а также надежность программного продукта.
Плюсы и минусы
Преимущества динамического тестирования
Недостатки динамического тестирования
Сравнение
Статическое тестирование требует много времени на бурные дискуссии и встречи. Однако оно помогает предотвращать появления дефектов на последних этапах разработки продукта. Поэтому статическое тестирование по праву считается важным шагом на пути к разработке ПО без ошибок.
Но и динамическое тестирование не менее важно. Благодаря непосредственному выполнению тестов программного обеспечения (проверки функционального поведения, производительности, надежности и других важных аспектов) команда может проверить и подтвердить качество и эффективность ПО.
Основы тестирования и отладки приложений на смартфоне
Для грамотной организации тестирования имеет смысл использовать подходящие технологии, таких технологий существует целое множество, но в этом множестве можно выделить две основные группы: статическое и динамическое тестирование.
Динамическое тестирование — процесс тестирования, производимый над работающей системой или подсистемой, не может быть осуществлено без запуска программного кода приложения. Этапы динамического тестирования:
Любая технология предполагает наличие набора методов, в тестировании обычно выделяют два самых распространенных метода: метод «черного ящика» и метод «белого ящика».
Метод «черного ящика» (англ. Black-box testing ), предполагает доступ к программному обеспечению только через те интерфейсы, которые доступны (или будут доступны) пользователю. Как правило, тестирование черного ящика ведется с использованием спецификаций или иных документов, описывающих требования к системе.
В некоторых случаях используется метод «серого ящика» (англ. Gray-box testing ), представляющий собой нечто среднее между методами белого и черного ящиков. Разработчик тестов имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.
Процесс тестирования должен когда-то закончиться, но при выборе момента окончания тестирования необходимо руководствоваться некоторыми критериями. В теории тестирования выделяется такое понятие как критерии покрытия, которые позволяют определить степень покрытия разрабатываемого продукта тестами.
При тестировании функциональных требований можно выделить два типа покрытия: покрытие, основанное на спецификации, и покрытие, основанное на коде. Рассмотрим эти два типа подробнее.
Покрытие, основанное на коде (Code-Based Coverage). Этот критерий относится к потоку управления и потоку данных программы. Можно выделить следующие критерии покрытия кода:
Метрики и критерии определяются в процессе разработки стратегии тестирования наряду с остальными составляющими процесса.
Рассмотрим классификацию тестирования. Дело в том, что тесты существенно различаются по задачам, которые с их помощью решаются и по используемой технике. По различным категориям можно выделить несколько классификаций тестирования, рассмотрим наиболее значимые из них.
Классификация по объектам (элементам) тестирования. Часто разделение на виды тестов по данному критерию называют разделением тестирования на уровни.
