Лекция 2. Основные задачи и виды тестирования (Лекции)

Тестирование на основе моделейВ. В. КуляминЛекция 2. Основные задачи и виды тестированияВ прошлой лекции тестирование было определено как проверка соответствия поведенияпрограммной системы требованиям, выполняемая по результатам реальной работы этойсистемы в некотором конечном наборе заранее определенных ситуаций [1].Таким образом, основная задача тестирования — проверка требований. Ее решение чащевсего сводится к последовательному решению ряда промежуточных задач. Кроме того, длярешения этих задач в различных обстоятельствах необходимы разные подходы,определяемые технической спецификой и внешними целями — для чего именнотестирование нужно в контексте заданного проекта. Данная лекция посвящена основнымцелям и задачам тестирования, различным способам его проведения.Цели тестированияТестирование является одним из видов деятельности жизненного цикла программногообеспечения и в рамках всего процесса разработки и сопровождения ПО можетиспользоваться для достижения нескольких целей.•Наиболее очевидная цель тестирования — поиск ошибок, то есть расхождений междунаблюдаемым поведением ПО и требованиями к нему.Это наиболее понятная и простая цель, которая первой приходит на ум при разговоре отестировании.Даже весьма опытные разработчики ПО часто считают, что это — его единственнаяцель.

Классическая фраза Дейкстры «тестирование может использоваться длядемонстрации наличия ошибок в программе, но не может использоваться длядемонстрации их отсутствия» часто интерпретируется именно в том смысле, чтоединственная польза от тестирования — найденные ошибки.•Менее очевидная и более сложная для понимания цель тестирования — общая оценкакачества ПО. Помимо прямого обнаружения ошибок, оно должно давать информациюо том, где, скорее всего, находятся еще не найденные ошибки, насколько они могут бытьсерьезны, насколько тестируемая система надежно и корректно работает в целом,насколько корректны и стабильны ее отдельные функции и компоненты.Если единственной целью тестирования считать нахождение ошибок, то терпеливое,аккуратное и систематическое тестирование, в ходе которого ошибок не обнаруживается— бесполезно.

Это не так, просто потому, что результатом такой работы являетсяценная информация о свойствах системы, недоступная из других источников, если,конечно, не относиться серьезно к уверенности разработчиков в собственнойнепогрешимости (обычно считается, что «уж в основном-то все правильно, так, мелочивсякие могут еще не работать»). Такое тестирование, если оно действительноаккуратное и систематическое, показывает, что тестируемая система — достаточнохороша. Даже если в ней и есть ошибки (что их нет, доказать при помощи тестированиядействительно невозможно), они достаточно редки и случаются в очень специфическихситуациях. Однако проведение подобного тестирования — непростая задача, основнаятрудность которой — достижение такого уровня аккуратности и систематичности,который позволяет обоснованно делать соответствующие выводы.Другой возможной проблемой при понимании тестирования как деятельности,нацеленной только на поиск ошибок, является отсутствие рациональных аргументов дляопределения момента, когда нужно прекратить тестирование.

Если тестировщикизанимаются только поиском ошибок, они не могут предоставить руководству проектаобоснованную информацию о том, что «в системе еще очень много недоделок» или,•наоборот, «система уже достаточно надежна». В этом случае решение об остановкетестирования принимается только на основе наличия ресурсов, то есть по остаточномупринципу: есть еще есть время и деньги — продолжаем тестировать, нет — прекращаем.Такого рода решения не связаны с реальным качеством системы, и поэтому способныпринести большой урон репутации организации-разработчика ПО.

Кроме того, онизакрепляют плохую практику управления проектами, способствуя перемещению всебольшей и большей части ресурсов проектов в разработку без тестирования, ведь оттестирования «нет прямой пользы» и его можно проводить на «остатки» ресурсов.Если руководитель проекта принимает подобные решения, это может означать либо, чтоон недостаточно компетентен и не воспринимает поступающую от тестировщиковинформацию, либо, что тестировщики недостаточно компетентны, чтобы такуюинформацию предоставить, и тестирование проводится хаотичным, недостаточноэффективным образом, несмотря даже на то, что оно выявляет важные ошибки, — ведьостается непонятным риск наличия еще невыявленных ошибок.Методом проб и ошибок на практике были выработаны рекомендации по организациитестирования, согласно которым ресурсы для проведения разработки тестов итестирования необходимо выделять заранее.

Их размер варьируется от 20% ресурсоввсего проекта при создании достаточно простых систем до 80-90% при разработкекритически важных и сложных систем реального времени с жесткими требованиями ких надежности и качеству в целом.Еще более редко упоминаемая и долговременная цель тестирования — обеспечениестабильного развития системы, предоставление средств для отслеживания измененийв ней и предсказания возможных проблем системы после внесения в нее тех или иныхизменений.Хорошие наборы тестов на практике становятся не только средством оценки качестватестируемой системы и сертификации ее пригодности для определенных задач, но иинструментом отслеживания важных изменений при развитии системы и измерения ееобщей стабильности и надежности.

Для этого, однако, необходимо поддерживать набортестов в работоспособном состоянии, соответствующем текущим требованиям ксистеме. При наличии нескольких поддерживаемых версий системы необходимо иметьлибо соответствующие версии тестового набора, либо средства его настройки,позволяющие тестировать функциональность, специфичную для каждой из версий. Длясложных систем это возможно только при использовании специфических образцоворганизации тестов, о которых пойдет речь в следующей лекции.Задачи тестированияЧтобы достигать указанных целей управляемым и предсказуемым образом, необходимоуметь решать ряд задач.

Эти задачи специфичны для тестирования как особого видадеятельности и всегда должны решаться при его проведении, тем или иным способом.Однако прежде, чем формулировать их необходимо проанализировать точный смысл рядатерминов, повсеместно используемых при разработке тестов и тестировании.Как уже говорилось, тестирование всегда проводится в некотором конечном наборезаранее определенных ситуаций. Такие ситуации называются тестовыми ситуациями иобычно включают несколько элементов.•Набор внешних воздействий, которые оказываются на систему в такой ситуации.

Этивоздействия называют тестовыми воздействиями. Примерами тестовых воздействиймогут служить вызов интерфейсной функции системы или метода одного из ее объектов,нажатие на кнопку графического интерфейса пользователя, выполнение команды вкомандной строке, передача сообщения системе по одному из каналов, по которым онатакие сообщения ожидает. Обычно воздействия связаны с некоторыми данными,которые они передают в систему — это, например, аргументы вызванной функции или••метода, опции выполненной команды, содержимое полей редактирования формы, гденажимается кнопка, данные пересланного в систему сообщения. Эти данные называюттестовыми данными.Внутреннее состояние системы в этой ситуации.

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

Поэтому для управления внутренним состояниемво время тестирования используют различные последовательности тестовыхвоздействий, называемые тестовыми последовательностями. Таким образом, задачаприведения системы в заданное состояние сводится к построению приводящей тудапоследовательности воздействий.Например, при тестировании класса, реализующего очередь каких-либо объектов,необходимо проверить корректность операций добавления и удаления объекта не одинраз, а в рамках разных последовательностей, в которых эти операции выполняются приразных заполнениях очереди.В еще более сложных случаях, например, при тестировании распределенных систем,состоящих из нескольких работающих параллельно компонентов, состояние, откоторого зависят результаы работы в данной ситуации, может включать в себя не тольковнутренние состояния отдельных компонентов, но и текущее состояние среды передачисообщений между ними — в каком (необязательно согласованном) состоянии находятсяобщие данные, какие сообщения уже переданы полностью, какие находятся в стадииприема, какие лежат в буферах для передачи, т.е., уже отправлены, какие еще толькопередаются в буфер, а какие еще не переданы.

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