Надежность АСОИУ (1088455), страница 55
Текст из файла (страница 55)
Насколько оптимальны использованные алгоритм мы?Классический анализ алгоритмов вместе с формальной их верификацией даетбыстрые и точные результаты.Множество атрибутов поддержки связано с усилиями по внесениюопределенных изменений в работающее приложение.Анализируемость. Насколько легко определить части, нуждающиеся визменении? Не поддается формализации.Изменяемость. Какие усилия требуются для внесения изменений? Неподдается формализации, уровень может быть установлен априори.Настраиваемость. Можно ли достичь желаемого эффекта без изменениясамой программы, изменяя только настройки? Задача решается тестированиемв реальных условиях.Стабильность.
Как ведет себя программа при внесении изменений налету?Эффективнорешаетсямодельнойверификациейспомощьюнедетерминированных параллельных процессов.Тестируемость, Насколько легко проверяется работа изменившегосяконтура? Решается параллельно с тестированием или превентивно, явнымобразом и к верификации отношения практически не имеет.Множествоатрибутовпереносимостихарактеризуетспособностьпрограммного обеспечения быть перенесенным из одного окружения в другое.Приспособляемость.
Может ли приложение изменяться в соответствии сизменениямиокружения?Взаимодействующиенедетерминированныепоследовательные процессы дают хороший результат, в том числе и вмодельном подходе.Устанавливаемость. Может ли приложение устанавливаться на разныеплатформы или в разные конфигурации? Как правило, явно задается вспецификации и явно реализуется и в проверке не нуждается.Согласованность. Какие стандарты были использованы в приложении? Ненуждается в проверке, однако само соответствие стандартам проверять можно инужно.Заменяемость.
Может ли приложение быть использовано так же, как егоэквивалент от другого производителя? Зависит ли от списка опцийсоответствующих приложений, которые могли бы или должны были бытьреализованы? Это относится к фазе формулирования требований, поэтому вверификации не участвует.Приведенные свойства — это общий список свойств, которые можнопроверить с помощью техник модельной верификации и валила ции, сделав егонаскольковозможнократким.Свойства,неупомянутые(например,масштабируемость или живучесть), но встречающиеся на практике, могут бытьсведены к данному списку.Одним из важных моментов качественного тестирования ПО являетсяпроведение так называемого регрессионного тестирования (тестов регрессии).Часто оно проводится не в полном объеме или не проводится вообще.Под регрессионным тестированием понимают тестирование, котороевыполняется для каждой новой версии программы.
Его цель — убедиться, чтоновая версия программы не содержит ошибок в уже протестированных кодах.По данным зарубежных авторов, количество ошибок, возникающих впроцессеизменениякода(исправленияошибок,внедренияновойфункциональности и т. п.), колеблется от 50 до 80%. Выявить эти ошибки ипомогают тесты регрессии.При регрессионном тестировании широко применяются верификационныетесты (Verification Test).Тести верификации ошибок (Bug Verification Test). Представляют собой тестыдля проверки исправления ошибок. Приведем пример.
Допустим, тест сномером 3 выявил ошибку, что было зафиксировано и передано разработчикудля исправления. Через определенное время от разработчика была полученановая версия программы, с информацией о том, что описанная ошибкаисправлена. Задача — повторить тест с номером 3 для того, чтобы убедиться,что ошибка действительно больше не проявляется. В случае успешногопрохождения теста такая ошибка помечается как Verified, в противном случае— как redo, о чем сообщается разработчику и передается на доработку.Проведение таких тестов является обязательным, так как причин, из-за которыхисправленная ошибка может сохраниться в программе, множество (отошибочного описания, а возможно и понимания проблемы до ошибочногоутверждения о том, что исправление имело место).Тесты верификации версии (Build Verification Test; Build Acceptance Test,Smoke Test, Quick Check). Представляют собой набор тестов для проверкисохранности основной функциональности в каждой новой версии программы.Инымисловами,этократкоетестированиевсехосновныхфункцийразрабатываемого ПО, цель которого — убедиться, что программа «работаетнормально», что основная функциональность программы не нарушена.
Еслихотя бы один из тестов верификации версии выявляет ошибку, то возвращаютсяк последней «рабочей» версии, дальнейшее тестирование новой версиипрекращается, а информация об ошибке вносится в базу и отправляется разработчику. Таким образом, тесты верификации версии представляют собойкраткий набор основных тестов функциональности.Тесты верификации версии широко используются в регрессионномтестировании. Если программа приходит от разработчика в виде полноценнойинсталляции, то тесты верификации начинаются с проверки инсталляции, послечего проводится краткое тестирование функциональности.После успешного прохождения тестов верификации версии проводятсерию тестов верификации ошибок.3.4.
Валидация программного обеспеченияВалидация (validation), или испытание, является важнейшим элементомуправления качеством продукции. В соответствии с ГОСТ 16504-81 подиспытанием программной продукции понимают экспериментальное определениеколичественных и (или) качественных характеристик свойств продукции при еефункционированиивреальнойсредеи(или)моделированиисредыфункционирования. При валидации используют способы поиска ошибок впроцессе выполнения разработанной программы в заданной реальной среде.Цельиспытания—экспериментальноеопределениефактических(достигнутых) характеристик свойств испытываемого программного изделия.Эти характеристики могут быть количественными и качественными. Важно,чтобы на их основе можно было сделать вывод о пригодности данного ПИ киспользованию по назначению.
Если вывод отрицательный, то образец ПИвозвращаетсянадоработку.Такимобразом,перекрываетсядоступнедоброкачественной продукции к пользователю. Непосредственно в ходеиспытаний качество ПИ может и не измениться, так как локализация ошибок неявляется целью испытания. Вместе с тем некоторые дефекты в программах идокументации могут устраняться по ходу испытания.Испытание является завершающим этапом разработки. Ему предшествуетэтап статической и динамической отладки программ.
Основным методомдинамическойотладкислужиттестирование.Вузкомсмыслецельтестирования состоит в обнаружении ошибок, цель же отладки — не только вобнаружении, но и в устранении ошибок. Однако ограничиться лишь отладкойпрограммы, если есть уверенность в том, что все ошибки в ней устранены,нельзя. Цели у отладки и испытания разные. Полностью отлаженная программаможет не обладать определенными потребительскими свойствами и быть непригодной к использованию по своему назначению. Не может служитьальтернативой испытанию и проверка работоспособности программы наконтрольном примере, так как программа, работоспособная в условияхконтрольного примера, может оказаться неработоспособной в других условияхприменения.
Попытки охватить контрольным примером все предполагаемыеусловия функционирования сводятся в конечном счете к тем же испытаниям.В соответствии с ГОСТ 19004-80 под испытанием программ понимаютустановление соответствия программы заданным требованиям и программнымдокументам. Определение построено на предположении, что в техническомзадании на разработку программы указаны все требования (характеристики),обеспечение которых гарантирует пригодность программы к использованию посвоему назначению. Но это редко соблюдается на практике. В некоторыхслучаях, особенно в автоматизированных системах, ТЗ на программное изделиелибо вообще не пишут, либо в них перечисляют лишь функции, которыевозлагаются на ПИ, без указания требований к другим потребительскимсвойствам.
При отсутствии ТЗ на разработку ПИ или полного и обоснованногоперечня требований к характеристикам разрабатываемого ПИ задача егоиспытания становится неопределенной и неконструктивной. Что значитустановить соответствие программы заданным требованиям, если требованияформально не заданы? Какая польза от установления такого соответствия, еслиэти требования заведомо «усечены» и не отражают основных потребительскихсвойств программы? Пользователю будет не легче, если программа функционирует плохо, но это в явном виде не противоречит требованиям ТЗ.При наличии в ТЗ требуемых характеристик основных потребительскихсвойств ПИ приведенные определения термина «испытание» по целииспытания практически совпадают.
Однако и в этом случае первое определениеявляется более конструктивным, так как оно формулирует не только цель, но иосновной метод проведения испытаний — проверка ПИ, функционирующего вреальной или моделируемой, но близкой к реальной среде.В зарубежной литературе, в том числе в стандартах на программноеобеспечение,понятие«испытание»частоотождествляютспонятием«тестирование». Например, в Std IEEE 829 — 1983 «Документация тестовпрограммногообеспечения»(США)даноследующееопределениетестирования: «...процесс активного анализа ПО на предмет обнаружениярасхождения между реальными и требуемыми нормами ПО (т. е.
наличияошибок в программах) и с целью оценки характеристик элементов ПО».Термин «тестирование», используемый в зарубежной литературе, будеминтерпретировать как испытание методом тестирования.Длительность испытания зависит от типа, конфигурации (сложности) ПИ,атакже от целей и степени автоматизации рассматриваемого технологическогопроцесса. При испытании операционных систем она колеблется от одного дошести месяцев. Сложные программные комплексы после интеграции могутиспытываться и болеедлительное время.Основными видами испытания ПИ являются предварительные, приемочные иэксплуатационные испытания, включая опытную эксплуатацию.В зависимости от места проведения различают стендовые и полигонныеиспытания.
Под испытательным стендом понимают совокупность техническихустройств и математических моделей, обеспечивающих в автоматическомрежиме имитацию среды функционирования; поступление входных данных (втомчислеискажающихвоздействий),регистрациюинформацииофункционировании ПИ, а также управление процессом и объектом испытания.Если в основу стендовых испытаний положен принцип моделирования, тосоответствующие испытательные стенды называют моделирующими.Испытательным полигоном называют место, предназначенное для испытанийв условиях, близких к условиям эксплуатации, и обеспеченное необходимымисредствамииспытания.Полигоннымиспытаниямподвергаютсистемы,работающие в реальном масштабе времени.
В полигонных условиях обычносочетаютнатурныеиспытаниясиспользованиемреальныхобъектовавтоматизируемых систем и моделирование некоторых объектов и процессових функционирования. В последнее время в некоторых разрабатывающихорганизациях создают испытательные полигоны, представляющие собойсовокупность специализированных по профилю данной организации испытательныхстендов.Такиеполигоныимеютобщиетехническуюиинформационную базы, а также программные средства проведения испытаний.По степени зависимости испытателей от разработчиков различают зависимыеи независимые испытания.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
