WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 | 4 | 5 |   ...   | 27 |
SemaTESK автоматической генерации множеств тестов для фронт-эндов в трансляторах. Метод ориентирован на тестирование анализаторов статической Пр е д и с л о в и е семантики. Предложенный метод специфицирования статической семантики Очередной сборник трудов Института системного программирования почти позволяет формализовать неформальные требования, содержащиеся в полностью (но не совсем) посвящен проблематике тестирования нормативных документах (например, в стандартах). Метод SemaTESK был компьютерных программных и аппаратных средств.

успешно применен в ряде проектов, в том числе по тестированию анализаторов статической семантики языков C и Java.

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

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

преимуществ и недостатков каждого из них. Рассматриваются области применения существующих решений.

Статья Я.С. Губенко, А.С. Камкина и М.М. Чупилко «Сравнительный анализ современных технологий разработки тестов для моделей аппаратного Статья Н.В. Пакулина и С.А. Смолова «Применение технологии UniTESK для обеспечения» посвящена сравнению современных подходов к разработке функционального тестирования инфаструктурного ПО Грид» посвящена функциональных тестов для моделей аппаратуры: AVM (Advanced Verification вопросам тестирования инфраструктурного программного обеспечения (ИПО, Methodology) от компании Mentor Graphics, OVM (Open Verification middleware) Грид-систем на соответствие стандарту. В статье рассматривается Methodology) — совместной разработки Mentor Graphics и Cadence Design разработка тестовых наборов для ИПО Грид средствами технологии Systems — и технологии UniTESK (Unified TEsting and Specification tool Kit), автоматизированного тестирования UniTESK. Приведены результаты разработанной в Институте системного программирования РАН.

тестирования программного пакет Globus Toolkit 4.2 на соответствие базовому стандарту WSRF 1.2.

В статье Е. В. Корныхина «Генерация тестовых данных для системного функционального тестирования микропроцессоров с учетом кэширования и П.Н. Яковенко и А.В. Сапожников представили статью «Инфраструктура трансляции адресов» рассматривается задача генерации тестовых данных для тестирования веб-сервисов на базе технологии TTCN-3 и платформы.NET», в системного функционального тестирования микропроцессоров (core-level которой обсуждаются вопросы тестирования веб-сервисов с использованием verification), а именно задача построения тестовой программы по заданной ее технологии TTCN-3. Рассматривается отображение языка WSDL в TTCN-3, абстрактной форме (тестовому шаблону). Для решения этой задачи в работе основанное на синхронном (процедурном) взаимодействии тестового предложен алгоритм, сводящий ее к задаче разрешения ограничений.

сценария с веб-сервисом. Предлагается подход к реализации универсального тестового адаптера средствами рефлексии, предоставляемыми платформой Статья И.Б Бурдонова и А.С. Косачева «Полное тестирование с открытым.NET, и средой поддержки времени выполнения языка TTCN-3.

состоянием ограниченно недетерминированных систем» посвящена описанию подхода к проблеме полноты тестирования, под которым понимается проверка В статье А.В. Баранцева, С.В. Грошева и В.А. Омельченко «Генерация соответствия реализации требованиям, описываемым спецификацией.

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

ограниченных классов реализаций и спецификаций, а также при В статье М.В. Архиповой и С.В. Зеленова «Направленная генерация тестовых использовании дополнительных тестовых возможностей, удаётся построить данных для анализаторов статической семантики» представлен метод 5 конечные полные тесты. Предлагаются алгоритмы тестирования и даётся оценка их сложности для конечных спецификаций и конечных реализаций с ограниченным недетерминизмом при тестировании с открытым состоянием.



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

Академик РАН В.П. Иванников увеличили свою масштабируемость лишь примерно на порядок, хотя тестовый набор для сложной программной системы сам по себе также является сложной системой. Возникающее расхождение между масштабами систем, которые мы можем создать, и систем, которые мы в состоянии аккуратно проверить, грозит увеличением количества сбоев в ПО и ущерба от них. О масштабах Организация сложных тестовых наборов возникающих проблем говорят хотя бы следующие цифры, относящиеся к различным программным продуктам компании Microsoft. Тестовый набор для текстового редактора Microsoft Word XP содержал около 35 тысяч тестов [3], а В. В. Кулямин для Windows XP — более 2-х миллионов. Если в разработке Windows NT 4.kuliamin@ispras.ru участвовало около 800 служащих компании, а в ее тестировании — около 700, то у Windows 2000 было около 1400 разработчиков и 1700 тестировщиков, т.е.

Аннотация. Статья посвящена различным способам организации и структуризации соотношение программистов и тестировщиков поменялось на обратное [4].

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

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

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

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

должны учитываться при сопровождении тестов и внесении в них изменений.

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

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

сделать выводы о качестве проверяемой системы и потребность в том, чтобы Однако, с ростом сложности систем, сложность разработки и поддержки в такие выводы были достоверными. Чтобы обеспечить достоверность выводов рабочем состоянии тестовых наборов для них растет гораздо быстрее.





по результатам тестирования, оно должно проводиться так, чтобы все Современные методы разработки ПО позволяют с разумными трудозатратами существенные аспекты поведения тестируемой системы и все факторы, создавать системы объемом до десятков миллионов строк кода [1,2], хотя еще способные повлиять на его корректность, были хоть как-то затронуты. Для двадцать лет назад эта планка была на уровне десятков тысяч строк. В то же сложного программного обеспечения таких аспектов и факторов очень много, время используемые на практике техники создания тестов за это время 9 что и приводит и к большому количеству необходимых тестов, и к сложности нужны на практике. В случае обнаружения ошибки разработчики их самих. системы надеются получить достаточно информации, чтобы легко восстановить и проанализировать возникшую ситуацию. Для этого Чаще всего тестовые наборы организуются в виде комплектов тестовых тестовый вариант хорошо подходит — он представляет собой единый вариантов. Один тестовый вариант представляет собой последовательность сценарий событий, достаточно компактен и формирует ровно одну действий, состоящую из следующих частей.

основную ситуацию, так что для выполняющего отладку разработчика • Сначала выполняются некоторые действия, нацеленные на создание область анализа ограничена.

определенной ситуации, приведение тестируемой системы в определенное состояние. Это преамбула тестового варианта.

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

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

иерархии или каких-то классификаторов.

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

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

состояние.

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

разработчика.

Возможные виды компонентов тестовых систем обсуждаются в профиле универсального языка моделирования UML для разработки тестов (UML Кроме того, такая организация тестов имеет следующие достоинства.

2.0 Testing Profile [6-10]), в предложениях общей архитектуры • Каждый тестовый вариант сам по себе достаточно компактен и легко инструментов тестирования, сформулированных в проекте AGEDIS [11отделяется от остального набора тестов. Поэтому, если необходимо 13], а также в работах, посвященных технологии UniTESK [14-16].

построить тестовый набор, нацеленный на проверку только Техники выделения модулей в модульных тестах (unit tests), как общего определенных функций или определенной части интерфейса характера, так и связанные с подходом к разработке на основе тестируемой системы, соответствующие тестовые варианты можно тестирования (test driven development, TDD), обсуждаются в выделить и использовать отдельно от остальных.

книгах [17,18].

По той же причине достаточно просто выбросить часть тестовых вариантов из набора, если потребуется уменьшить его размер или • Развитие тестируемой системы или потребность в независимом развитии ускорить выполнение тестов.

Pages:     || 2 | 3 | 4 | 5 |   ...   | 27 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.