Lecture02 (Лекции в ПДФ)

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

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

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

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

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

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

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

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

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

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

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

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

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