Лекции. Тестирование ПО (all in one) (1186159), страница 8

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 8)

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

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

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

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

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

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

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

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

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

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

Чаще всегопри разработке тестов приходится заодно уточнять требования к тестируемой системе идорабатывать представляющие их документы, делая их более ясными и полными, а такжеустраняя имеющиеся противоречия.Для построения систематичных и корректных тестов нужно адекватное пониманиетребований, то есть понимание того, что именно они означают, что из этого может бытьпроверено и, наконец, что именно должно быть проверено в каждой конкретной тестовойситуации.Рассмотрим, например, функцию abs(x), вычисляющую абсолютную величину числа.Вроде бы ясно, что при этом вычисляется — должен возвращаться x, если он неотрицателен,или –x иначе. На языках C, С++, Java или C# это может быть передано так: ( x >=0 )? x : -x.Можно, например, проверять, что abs(x) >= 0 для любого x.Попробуем взять x = –2147483648, например, в Java. Каков будет результат?Правильный ответ: –2147483648.Этот неожиданный результат — отрицательное число в качестве абсолютной величины— объясняется тем, что в машинной арифметике 32-битных целых чисел выполненосоотношение –(–2147483648) = –2147483648.

Приведенное выше определение abs(x) остаетсяправильным, неверно только заключение о том, что abs(x) >= 0.Чтобы объяснить полученное «странное» соотношение, надо понимать, чемруководствовались создатели целочисленной машинной арифметики. Им нужно было целыечисла, которых бесконечно много, представить в машине как некоторое конечное множество.При этом, однако, надо сохранить основополагающие свойства арифметических действий —сложения, вычитания и умножения.

Характеристики

Список файлов лекций