Надежность АСОИУ (1088455), страница 54
Текст из файла (страница 54)
Восходящий этап тестирования по методусандвича решает эту проблему для модулей нижних уровней, но она может попрежнему оставаться открытой для нижней половины верхней частипрограммы. В модифицированном методе нижние уровни также тестируютсястрого снизу вверх. А модули верхних уровней сначала тестируютсяизолированно, а затем собираются нисходящим методом.
Таким образом,модифицированный метод сандвича также представляет собой компромиссмежду восходящим и нисходящим подходами.Инструменты тестирования ПО. Расширение масштабов использованияпрограммныхпотребовалопродуктовсозданиявразличныхспециальногосферахдеятельностиинструментариядлячеловекатестированияпрограммных разработок, начиная с инструментов тестирования программобщего назначения.
Инструментарий для тестирования ПО впервые сталприменяться в программных системах спецназначения, некоторые егокомпоненты уже используются для тестирования ПО систем общегоназначения.Современные программные продукты для сферы тестирования ПО можноразделить на следующие группы.Генераторы тестов. Вкачествевходнойинформациииспользуютформальную модель тестируемого ПО и набор директив, управляющихпроцессом генерации. На выходе генератора тестов формируется набор тестов,состоящих из последовательности кодовых сигналов, подаваемых на входтестируемой системы, и ожидаемых (в соответствии с моделью) реакций на этисигналы.Генераторы входных данных тестов. Для использования таких инструментовнеобходимо иметь средства моделирования поведения тестируемого ПО.
Вкачестве примера можно привести системы AETG (компании TelcordiaTechnologies) и DGL (компании Maurer).Среды автоматического тестирования. В данных системах тестированияавтоматически запускаются наборы тестов для проверки соответствующего ПО.Примерами могут служить системы Rational Robot, WinRunner (компанииMercury), Таи Tester (компании Telelogic) и т. д.Инструменты моделирования.
Служат для создания входных данных длягенераторов тестов (формальных моделей систем) и в общем случае непредоставляют функции генерации тестовых сценариев. Примеры: RationalRose, Objecteering, Poseidon, Together Control Centre, Statemate Magnum,AutoFocus, SimuLink, SCR и Telelogic Tau.К инструментам тестирования можно также отнести: UNITESK (разработка Института системного программирования Российской академии наук),Tvec, Cjnformig test generator, Reactis, Jcontract, Tau Ttcn Suite, Testmaster, Gotha- Tcbtans, Ucbt - salt, Toster, TGV/CADP и др.Таким образом, в настоящее время известны примеры эффективногоиспользования отдельных методов и методик в отраслях с достаточнымуровнем формализации соответствующих предметных областей, которыйпозволяет точно формулировать функциональные требования к ПО.
Это, впервую очередь, отрасли, предприятия, которые осуществляют разработкусистем реального времени, баз и банков графических данных, научныхвычислений, банковских систем, программных приложений для редакционноиздательской деятельности и других областей деятельности человека.3.3. Верификация программного обеспеченияВерификация (verification), или контроль, проводится с целью нахожденияошибки в процессе выполнения программы в тестовой или моделируемойсреде.Впроцессеверификации,согласностандартуISO9000-2000,осуществляется проверка программного продукта на соответствие входнымданным, в том числе требованиям и спецификациям.Верификация реализуется на основе статических методов без исполненияпрограммных кодов.
При такой проверке программного изделия широкоиспользуются группы методов STR (Software Technical Reviews — методыпрограммно-технической проверки).В общем случае верификация удостоверяет, что объект внутренненепротиворечивисоответствуетстандартам.Основноедостоинствоверификации состоит в обнаружении ошибок на ранних этапах разработки, дотого как они попадут на следующую стадию. Это уменьшает временные иэкономическиезатратынаразработкупрограммногообеспечения.Верификация применима ко всем объектам (как к тестовым моделям, так и кспецификациям).Методыверификациивключаютэкспертныеоценки,формальный контроль, формальное доказательство (formal verification) свойствПО и проверки на непротиворечивость.Сегодня используются два подхода к верификации программного обеспечения.Первыйподход,дедуктивный,представлентакиминаправлениямиисследований, как автоматическое доказательство теорем, использованиемультимножеств и графов, а также разнообразных специализированных алгебр.Программная система описывается в рамках некоего формализма, после чеговыполняется строгое математическое доказательство обладания даннойсистемой тех или иных свойств.
Второй подход — модельный; егопоследователи не стремятся вписать систему в рамки теории, а вместо этогостроят модель системы, которую можно рассматривать как машину илиавтомат. Любое требование к системе проверяется для каждого возможногосостояния автомата.Модельный подход поддерживает не только полную, но и частичнуюверификацию, которая может быть направлена на проверку только одногосвойства. Иными словами, для проведения верификации не обязательнодобиваться формализации всех без исключения требований спецификации.Процесс проверки моделей не требует ни ручного управления со стороныпользователя, ни высокого уровня профессионализма.
Имея модель, можноавтоматически проверять па ней необходимые свойства. Процесс проверкиинтегрируется в стандартный цикл проектирования, позволяя уменьшить времясоздания приложений с учетом проведения рефакторинга программного кода.Однако у модельного подхода есть и слабые стороны. Верификацияосуществляется по модели, а не по реальной системе, поэтому ценностьполученного результата напрямую зависит от корректности модели, чтотребует высокого уровня подготовки персонала, создающего модели программ.Так как данные имеют тенденцию принимать значения из бесконечныхмножеств, главную роль играет поток управления, а не поток данных.
Такаяориентация уменьшает возможности универсального применения, однакообычно это не столь существенно при разработке больших аппаратнопрограммных комплексов, поскольку практически все виды модульныхприложений, из которых складываются подобные комплексы, можно либопривести к модели «потока управления», либо корректировать методикутестирования для каждого конкретного модуля.Модельный подход не может эффективно применяться без точныхалгоритмов принятия решений. Нет гарантий полноты: проверяются только тесвойства, которые указаны явно. Построение моделей и формулировкатребований предполагают высокий уровень знаний и умения их применять.Примеры успешного применения модельного подхода можно обнаружить,изучая процесс разработки сложных систем, оперирующих большими потокамиданных, например СУБД, комплексов потоковой обработки речевой итекстовой информации, систем обеспечения информационной безопасности.Модельный подход к верификации программного обеспечения позволяет (приправильном разбиении всего комплекса) при проектировании и разработкемодулей и более мелких составляющих выявлять логические ошибки еще наэтапе проектирования.
Так, при разработке программного обеспеченияпотоковой обработки растровых изображений в рамках модельного подходабыла сформирована модель для верификации менеджера заданий дляпотоковой обработки и обработчиков заданий, позволившая выявить ошибки впроектировании протоколов взаимодействия модулей комплекса и алгоритмеопределения обработчика атомарного задания.Использование качественных характеристик. Еще не так давно всетребования к приложениям делились на функциональные и нефункциональные.Первые, как правило, были представлены двоичным значением «работает/ неработает», а вторые — длинным списком свойств, верифицируемыхсубъективно (например, «дружелюбность», «устойчивость», «безопасность»).
Впоследнее время ситуация изменилась, и полный список типов возможныхтребований был стандартизирован в рамках ISO 9126.Говоряофункциональности,обычноподразумеваютнекотороемножество атрибутов, рассчитанных на существование определенного наборафункций и их специальных свойств, достигающих поставленных целей.Пригодность. Выполняет ли приложение предназначенную ему задачу?Можетбытьверифицированопутеммоделированияправильногосопутствующего окружения (подход, аналогичный тестированию).Точность. Насколько точны результаты работы приложения? Труднореализуется при модельном подходе; логическая верификация в данном случаебудет более эффективна.Безопасность. Не происходит ли неавторизованной утечки информации?Верифицируется напрямую с формулированием соответствующих запросов.Существует также целый ряд немодельных верификаторов, решающих эту жезадачу.СоответствуетСоответствие.лиреализованнаяфункцияданномустандарту? Стандарт используется как спецификация (источник требований),реализация функции моделируется.Совместимость.
Может ли данное приложение общаться с соответствующими программными продуктами от других производителей? Близкимприближением является подразумеваемая совместимость при соответствиистандартуинеобходимостиотсутствииболеенедокументированныхточнойпроверкивозможностей.выполняетПриавтоматическоедизассемблирование и эмуляцию заданных участков программного кода,ручную отладку, построение графа передачи управления и данных.Множествопрограммногоатрибутовобеспечениянадежностиподдерживатьхарактеризуютспособностьопределенныйуровеньпредоставляемых услуг при данных условиях и в течение заданногопромежутка времени.Завершенность.
Является ли изначально предоставляемый уровень услугдостаточным? Все ли было реализовано? Это свойство по определению неможет быть проверено формальным тестированием: на каждую ожидаемуюфункцию формулируется требование или множество требований, которыепроверяются на модели.Устойчивость к ошибкам. Ведет ли себя программа адекватно в случаепредставления заведомо неверных входных данных? Очень неэффективно игромоздко реализуется в модельном подходе, существуют неплохие методытестирования, решающие эту проблему.Устойчивость к окружению (прочность). Может ли приложение работатьнормально в нестандартном или неустойчивом окружении? Модельный подходв данном случае применяется только при наличии возможности моделированияокружения.
Однако корректное моделирование стресс ситуации — весьманетривиальная задача.Восстанавливаемость. Может ли приложение продолжать работу послесбоя? Как правило, это свойство явно прописывается в программе и нуждаетсятолько в проверке. Может быть проверено как модельной верификацией, так итестированием.Множество атрибутов по удобству пользования характеризует трудностипри использовании программного обеспечения и их субъективную оценку темили иным множеством пользователей.Понятность. Насколько интуитивно ясен пользовательский интерфейсприложения? Не поддается научной формализации, несмотря на то что менееформальныеправиласуществуютужедавно,модельнаяверификацияневозможна.ПриспосабливаетсяОбучаемость.липриложениекспецификепользователя? Используются алгоритмы искусственного интеллекта, которыемогут быть верифицированы, соответственно может быть верифицирован ипризнак.Управляемость.
Легко ли управлять работой приложения? Эта задача,традиционная для бета тестирования, в последнее время возлагается наспециалистов по пользовательским интерфейсам.Множествоатрибутов производительностивыявляет связь уровняпредоставляемых приложением услуг с объемом используемых при этомресурсов.Поведение в о времени. Адекватен ли временной график использованияресурсов? В данном случае нужно тестировать реальную систему, а не еемодель (например, для нахождения утечки памяти). Абсолютно не подходитдля модельной верификации.Использование ресурсов. Эффективно ли используются ресурсы? Имеетсянаправленность на реальную систему, и существуют эффективные методыформального тестирования, которые в основном базируются на сочетании сетейПетри и специализированных языков описания моделей верификации, припрогонкекоторыхпроисходитколичественнаяоценкапотенциальноиспользуемых ресурсов; максимальное значение дает вполне эффективнуюоценку, пригодную для большинства реализаций.Алгоритмизация.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
