Введение в Анализ информационных технологий окружений открытых систем POSIX (POSIX OSE) Тестирование конформности в системе стандартов окружений открытых.

Презентация:



Advertisements
Похожие презентации
Жизненный цикл программного обеспечения Лекция 4.
Advertisements

SOFTWARE DEVELOPMENT PODGOTOVIL TVOU ZHOPY K SDACHE.
Разработка программного обеспечения (Software Engineering) Часть 2. Создание ПО.
ГОСТЕХКОМИССИЯ РОССИИ РУКОВОДЯЩИЙ ДОКУМЕНТ Защита от несанкционированного доступа к информации.
2 Основным понятием программной инженерии является понятие жизненного цикла ПО. Жизненный цикл ПО (software lifecycle) – это период времени, который начинается.
Жизненный цикл программного обеспечения Подготовил студент 1 курса Лось Павел.
Разработка программного обеспечения (Software Engineering) Ian Sommervillle Часть 8. Управление качеством.
Этапы компьютерного моделирования. 1. Описание задачи Задача формулируется на обычном языке; Определяется объект моделирования; Представляется конечный.
Документирование ПО Совокупные затраты на документирование крупных программных продуктов могут достигать 20 – 30% от общей трудоемкости проекта.
Стандарт ISO Общие критерии оценки безопасности информационных технологий.
Языки и методы программирования Преподаватель – доцент каф. ИТиМПИ Кузнецова Е.М. Лекция 7.
Канадские критерии безопасности Созданы в 1993г. Цель разработки Единая шкала критериев Единая шкала критериев Основа для разработки спецификаций безопасных.
Тесты Особенности содержания и структуры контрольных измерительных материалов определяются целями, поставленными перед ЕГЭ Цель единого государственного.
1 Документирование как основа тестирования. 2 Проблемы терминологии В современной IT-промышленности терминология, касающаяся QA и тестирования, весьма.
Положение об отделе В.Андреев, Д.Сатин. Штат отдела начальник отдела; бизнес-аналитик; проектировщик пользовательских интерфейсов; специалист по анализу.
Методы тестирования Впрактике тестирования используются методы: статический, детерминированный, стохастический ивреальном масштабе времени. Статическое.
От сложного – к простому. От непонятного – к понятному.
Анализ проекта [Проект] [Докладчик]. Исполнение и цели Цель: укажите исходные цели или цели проекта –Перечислите критерии оценки успешного выполнения.
Внутренний аудит в ТПУ1 ПРАКТИЧЕСКИЙ ОПЫТ ВНУТРЕННИХ АУДИТОВ ТПУ.
ТЕСТИРОВАНИЕ МЕТОД «ЧЕРНОГО ЯЩИКА» ВЫПОЛНИЛ СТУДЕНТ ГР. ИВТ-51 з БАННИКОВА Н.Р.
Транксрипт:

Введение в Анализ информационных технологий окружений открытых систем POSIX (POSIX OSE) Тестирование конформности в системе стандартов окружений открытых систем POSIX (POSIX OSE) В.А. Сухомлин Проф. МГУ им. Ломоносова

1. Методология тестирования конформности POSIX (Стандарт IEEE P2003) (ISO/IEC 13210:1999 (IEEE Std ), Information technology&Requirements and Guidelines for Test Method Specifications and Test Method Implementations for Measuring Conformance to POSIX Standards)

1. Методология тестирования конформности POSIX Разрабатываемые посредством стандарта POSIX 2003 методы тестирования конформности реализаций стандартам и POSIX профилям включают следующие компоненты: - программное обеспечение тестирования конформности (Conformance Test Software - CTS), включающее комплекты тестов конформности (Conformance Test Suites) -- процедуры тестов конформности (Conformance Test Procedure for POSIX - PCTP) - набор методик, дополняющий процесс автоматического тестирования посредством исполнения тестовых комплектов; -- проверку документации требованиям конформности (Conformance Documents for POSIX - PCD)

2. Подход тестирования конформности POSIX Цель подхода POSIX - обеспечить высокую степень уверенности в том, что реализация конформна стандарту(ам)/профилям Н е гарантирует абсолютную конформность реализации стандарту, т.к. для этого требуется осуществление исчерпывающего тестирования (exhaustive), которое не осуществимо ни технически, ни экономически В подходе POSIX акцент делается на критерии основательности тестирования (comprehensive), что подразумевает требование разработки содержательного теста (группы тестов) для каждого элемента функциональности тестируемой реализации. При этом тестирование комбинаций элементов API рассматриваемый стандарт не требует!

3. Основные элементы методологии тестирования конформности POSIX Основные аспекты методологии тестирования конформности POSIX: система понятий модель процесса установления конформности; синтаксис языка спецификации утверждений конформности коды результатов тестирования методика разработки утверждений конформности отчет о тестировании

4. Определения Утверждение (assertion) – спецификация для тестирования требования конформности (conformance requirement) IUT, представленная в стандартной форме, определенной данным стандартом. Утверждение определяет что нужно тестировать для проверки конформности IUT и что приводит к истинному результату, в случае конформности тестируемой системы соответствующим требованиям. Тест утверждения (assertion test) – программное обеспечение или процедурные (ручные) методы, результатом применения которых являются коды результатов тестирования, используемые для установления факта конформности реализации некоторому утверждению.

4 Определения (продолжение) Документ конформности (conformance document) – документ, удовлетворяющий требованиям данного стандарта (P2003). Требование конформности (conformance requirement) – требование, установленное в базовом стандарте и определяющее недвусмысленным и конструктивно проверяемым образом существенные для реализации свойства и ограничения. Процедура тестирования конформности (Conformance Test Procedure - CTP) – выполняемые человеком действия, обычно, в сочетании с другими методами тестирования, обеспечивающие проверку конформности реализации требованию (требованиям) стандарта.

4 Определения (продолжение) Конформная реализация (conforming implementation) – реализация, удовлетворяющая всем релевантным требованиям конформности. Конформные коды результата тестирования (conforming test result codes) – полный список связанных с утверждениями кодов результата тестирования, который будет продуцирован при выполнении CTS в случае конформной реализации. Окончательные коды результата тестирования (final test result code) – такие коды результата тестирования, которые получены в результате выполнения тестов утверждений и не требуют дальнейшей обработки.

4 Определения (продолжение) Промежуточные коды результата тестирования (intermediate test result code) – коды результата тестирования, полученные в результате выполнения тестов утверждений и требующие последующей обработки для определения окончательных кодов результата тестирования. Утверждение документируемости (documentation assertion) – утверждение, отражающее требование базового стандарта документировать специфические свойства и поведение реализации. Тестируемая реализация (implementation under test - IUT) – реализация стандарта(ов), тестируемая на соответствие исходному стандарту (исходным стандартам).

4 Определения (продолжение) Tест (test case) – спецификация действий, требуемых для достижения одной или нескольких целей тестирования. Реализация метода тестирования (test method implementation) – программное обеспечение, процедуры или другие средства, используемые для измерения степени конформности. Спецификация метода тестирования (test method specification) – документ, который содержит утверждения, определяющие функциональность и поведение, задаваемые стандартом, а также содержит полный набор конформных (эталонных) кодов результата тестирования.

4 Определения (продолжение) Цель теста (test purpose) – словесное описание узко определенной задачи тестирования, фокусирующееся на единственном требовании конформности Отчет о тестировании (test report) – документ, который представляет результаты тестирования и другую информацию, относящуюся к применению тестового метода к IUT Тестовое программное обеспечение (test software) – программное обеспечение, которое используется для тестирования реализации.

5 Процесс установления конформности стандарта

5. Шаги процесса установления конформности 1.систематический анализ текста стандарта и выделение из него фрагментов, выражающих требования конформности 2.формулировка требований конформности в виде одного или нескольких более точно сформулированных утверждений (assertions) 3.записи утверждений конформности в стандартной синтаксической нотации и определение для утверждений эталонных результирующих значений (Conforming Test Results Codes) 4.возможное дополнение методов тестирования неавтоматическими методиками проверки и требованиями к документации

5. Шаги процесса установления конформности 5.реализация методов тестирования в виде комплектов тестов (Conforming Test Suites), а также инсталляция, конфигурирование, исполнение CTS и протоколирование результатов прогонов; 6.анализ значений промежуточных кодов результата тестирования (Intermediate Test Result Codes - ITRC) и их отображение в конечные коды результата тестирования (Final Test Result Codes - FTRC); 7.проверка конформности реализации посредством сопоставления полученных значений конечных кодов результата тестирования с эталонными значениями кодов конформности (Conforming Test Result Codes - CTRC); 8.вынесение вердикта о конформности реализации.

5 Общий процесс установления конформности

6. Синтаксис для представления утверждений В подходе POSIX используется специальный синтаксис для записи утверждений конформности Все утверждения должны иметь по меньшей мере три компоненты идентификатор утверждения текст утверждения, достаточно детальный для реализации тестов конформные или эталонные коды результата тестирования

6. Синтаксис для представления утверждений Набор утверждений составляет спецификацию метода тестирования (TMS TMS должна: - обеспечивать полное покрытие требований конформности базового стандарта - иметь структуру построения, идентичную базовому стандарту - - содержать утверждения, написанные только для требований конформности и только для них -- содержать утверждения, сформулированные таким образом, чтобы код результата тестирования PASS («тест прошел») указывал на конформность стандарту

6. Синтаксис родового утверждения For,..., : If then (Setup: )* Test: (TR: )* (FTS: )* (Note: )* Else {* единственным обязательным элементом для является }

6. Элементы родового утверждения For: Применяется, когда тело (текст) утверждения применяется к некоторому набору элементов. Заголовок For обычно используется при определении утверждений типа general If Then Else: Конструкция If, Then... Else используется для задания условий применимости текста утверждения Applicable Standard: Определяет базовые стандарты, которые применяются для тестирования данного утверждения Option: Определяет дополнительные возможности (опции) базового стандарта, которые должны быть включены в реализацию для тестирования данного утверждения

6. Элементы родового утверждения Test Support: Определяет оборудование или программное обеспечение, не связанные с базовым стандартом, но необходимые SUT для тестирования данного утверждения Setup Requirements: Определяет действия или условия, которые необходимо выполнить перед началом тестирования для подготовки соответствующей среды Test Text: Текст тестируемого утверждения. Как правило, тест утверждения имеет следующую форму: Testing Requirements (TR): Определяет минимально допустимый уровень тестирования данного утверждения Notes: Дополнительная информация о методе тестирования

6. Типы утверждений Основной (Basic), используемый для представления одного или нескольких требований стандарта, относящихся к единственному элементу (функции) Общий (General), использумый для представления утверждений, относящихся к нескольким элементам стандарта Ссылочный (Reference), используемый для ссылок на уже существующие утверждения Документации (Documentation), используемый для представления требований конформности к документу; Общая Документация (General Documentation), используемый для представления требований конформности к группе документов.

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

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

7. Промежуточные коды результата тестирования Промежуточный код INCOMPLETE соответствует ситуации, когда тест утверждения не может привести ни к результату PASS, ни к FAIL (например, случай зависания системы тестирования). Все вышеуказанные ситуации предполагают необходимость выполнения дополнительных действий (например, повторного исполнения теста, выполнение процедуры экспертного анализа) для разрешения неопределенности с целью приведения промежуточных кодов к одному из конечных кодов.

8. Состав конечных кодов результатов тестирования PASS - IUT удовлетворяет требованиям, определенным утверждением конформности; FAIL - IUT не удовлетворяет требованиям; NO_APPLICABLE_STANDARD - стандарт, требуемый для тестирования утверждения, не поддерживается IUT; NO_OPTION - опция базового стандарта, требуемая для тестирования утверждения не поддерживается IUT; NOT_APPLICABLE - утверждение не применимо к профилю; NO_TEST_SUPPORT - отсу тствует дополнительное программное обеспечение или оборудование, необходимое для тестирования данного утверждения; UNTESTED – отсутствует тест для данного утверждения; NO_TEST - Нет теста для данного утверждения.

8. Пример утверждений для функции fork() Process Creation Function: fork() Description 1 IF PCTS_sem_init() THEN TEST: Any semaphores that are open in the parent process when it makes a fork() call shall also be open in the child process. ELSE NO_OPTION Conformance for fork: PASS, NO_OPTION 3 FOR: mlock() and mlockall() IF PCTS_function THEN TEST: A child process shall not inherit any address space memory locks established by the parent process via calls to function() after a fork() call. ELSE NO_OPTION Conformance for fork: PASS, NO_OPTION

9. Идентификация требований конформности 1)В исходном тексте стандарта выявляются вхождения слов shall, may, should, can, implementation-defined, undefined и unspecified 2)Фрагменты текста, содержащие данные вхождения выделяются цветными фломастерами для последующего анализа являются ли они определениями требований конформности или нет 3)Также выделяются цветом явные определения требований, сформулированные посредством синтаксических и семантических определений сущностей, специфицируемых стандартом 4)Анализируются выделенные фрагменты для решения вопроса, определяют они требования конформности или нет и, если определяют, данные фрагменты выделяются таким же цветом, как и фрагменты, явно определяющие требования

Идентификация требований конформности В процессе анализа особое внимание следует уделить выявлению условных требований, часто определяемых с помощью связок may- shall. Например, следующее утверждение в спецификации: The implementation may do either A or B / Реализация может делать A или B/. If A occurs, then A1 shall... / Если A имеет место, тогда A1 должно.../. определяет условное требование конформности, применяемое к реализации только в том случае, когда имеет место А.

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

10. Отчет о результатах тестирования Результаты исполнения реализации метода тестирования, представляются в итоговом документе «Отчет тестирования», включающий: Название и редакцию исходного стандарта Названия и номера версий используемых реализаций метода тестирования Спецификации метода тестирования, реализации которых используются для тестирования Название, модель и конфигурация тестируемых компьютерных систем, и название, версия и конфигурация реализации Название и версия документа конформности реализации (CD), аудит которого выполнялся дату тестирования

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

Модель области ИТ Система Стандарта- зации Пространство спецификаций ИТ (Спецификации ИТ, стандарты, Профили, сценарии) Пространство реализаций ИТ (Продукты, ИТ-системы, сервисы) Аппарат конформности