лекции

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

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

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

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

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

Такие модели могут изменяться со временем, поскольку изменяются потребностииндустрии производства ПО, появляются новые группы возможностей или вниманиеразработчиков привлекается к новым аспектам качества, ранее считавшимсянесущественными.Наиболее широко на данный момент используется модель качества ПО, зафиксированнаяв наборе стандартов ISO 9126 [1-4]. В несколько упрощенном виде эта модель определяет 6основных характеристик качества программного обеспечения.

Каждая характеристикауточняется при помощи некоторого набора атрибутов.ФункциональностьСпособность к взаимодействиюФункциональная пригодностьСоответствие стандартамЗащищенностьТочностьПереносимостьАдаптируемостьУдобство заменыСпособность к сосуществованиюСоответствие стандартамУдобство установкиУдобство сопровожденияУдобство измененийСоответствие стандартамУдобство проверкиАнализируемостьСтабильностьНадежностьКачествоПОЗрелостьСпособность к восстановлениюСоответствие стандартамУстойчивость к отказамУдобство использованияСоответствие стандартамУдобство обученияПривлекательностьУдобство работыПонятностьПроизводительностьСоответствие стандартамВременная эффективностьЭффективность использованияресурсовРисунок 1.

Характеристики и атрибуты качества ПО по ISO 9126.••••Функциональность.Эта характеристика обозначает способность ПО решать определенный круг задач..Это качественная характеристика, определяющая, что именно делает данная программа.Атрибутами функциональности являются, например, точность производимыхвычислений и защищенность ПО — способность предотвращать доступ к его функциямтем людям или другим системам, у которых нет прав на это.Надежность.Это способность ПО поддерживать определенный уровень работоспособности взаданных условиях.Надежность является вероятностной характеристикой работоспособности ПО.Атрибутами ее являются, например, вероятность работы без ошибок на заданноминтервале времени и среднее время восстановления после сбоя.Удобство использования.Удобство использования показывает, насколько ПО привлекательно, удобно в обученииработе с ним и при выполнении самой работы.К атрибутам удобства использования относятся, например, среднее время обученияпользователя выполнению определенных задач с помощью данной системы, а такжеусилия, затрачиваемые на решение фиксированной задачи.Производительность.Это способность ПО обеспечивать необходимую работоспособность по отношению квыделяемым для этого ресурсам.

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

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

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

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

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

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

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

Если же это не так,то есть иногда сбой может рассматриваться как корректное поведение системы (если,скажем, вводятся совсем некорректные исходные данные), то подобное тестирование можетпривести к неправильным выводам о наличии ошибок в системе.Чтобы требования к программному обеспечению можно было уверенно использовать приего разработке и тестировании, они должны обладать рядом характеристик, которыезафиксированы в стандартах, регламентирующих разработку программного обеспечения.Два таких стандарта — IEEE 830 [5] и IEEE 1233 [6] — определяют следующиехарактеристики правильно составленных требований к ПО.•Адекватность, соответствие реальным потребностям пользователей ПО.•Однозначность, отсутствие двусмысленностей и возможностей разного толкования.•Полнота — отражение в требованиях всех существенных потребностей и всех ситуаций,в которых система должна будет функционировать.•Непротиворечивость или согласованность между разными элементами требований.•Систематичность представления — требования должны быть описаны в рамкахнекоторой системы с четким указанием места каждого требования среди остальных, сопределением связей и зависимостей между ними и приоритетности для различныхзаинтересованных лиц.•Прослеживаемость — требования должны иметь четко определенные связи с модулямиразрабатываемой системы, частями проектной документации и тестами, чтобы всегдаможно было определить, для выполнения или проверки каких требований созданкаждый из этих элементов и насколько он им соответствует.•Проверяемость или возможность для каждого требования однозначно установить припомощи того или иного анализа системы, выполнено это требование или нет.•Модифицируемость или возможность внесения изменений в набор требований сбыстрым исправлением всех возникающих при этом дефектов с точки зрения другиххарактеристик.В ходе работы над создаваемой программной системой или переработки ужесуществующей всегда, в том или ином виде, проводится анализ требований, цель которого— подготовить представление требований к ПО, имеющее все указанные характеристики.Анализ требований обычно включает следующие виды деятельности.•Выделение требований.