Промежуточные коды результата тестирования

8. Тестирование конформности в системе
стандартов окружений открытых систем
POSIX (POSIX OSE)
Лаборатория Открытых информационных технологий
Проф. В.А. Сухомлин
1. Методология тестирования конформности POSIX
(Стандарт IEEE P2003)
(ISO/IEC 13210:1999 (IEEE Std 2003-1997),
Information technology&Requirements and
Guidelines forTest 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 Процесс установления конформности для одного стандарта
IEEE
2003 Std
Base
Standard
Test Method
Implementation
Developer
Test Method
Implementation
Test
Method
Specification
ITCR
CTCR
FTCR
No
All Test
Result Codes
Match?
NonConforming
IUT
YES
Conforming IUT
5. Шаги процесса установления конформности
систематический анализ текста стандарта и
выделение из него фрагментов, выражающих
требования конформности;
2. формулировка требований конформности в виде
одного
или
нескольких
более
точно
сформулированных утверждений (assertions);
3. записи утверждений конформности в стандартной
синтаксической нотации и определение для
утверждений эталонных результирующих значений
(Conforming Test Results Codes);
4. возможное
дополнение методов тестирования
неавтоматическими
методиками
проверки
и
требованиями к документации;
1.
5. Шаги процесса установления конформности
реализация методов тестирования в виде комплектов
тестов (Conforming Test Suites), а также инсталляция,
конфигурирование, исполнение комплектов тестов и
протоколирование результатов прогонов;
6. анализ значений промежуточных кодов результата
тестирования (Intermediate Test Result Codes - ITRC) и
их отображение в конечные коды результата
тестирования (Final Test Result Codes - FTRC);
7. проверка конформности реализации посредством
сопоставления полученных значений конечных кодов
результата тестирования с эталонными значениями
кодов конформности (Conforming Test Result Codes CTRC);
8. вынесение вердикта о конформности реализации.
5.
5 Процесс установления конформности для одного стандарта
6. Синтаксис для представления утверждений
В
подходе
POSIX
используется
специальный
синтаксис
для
записи
утверждений конформности.
Все утверждения должны иметь по меньшей
мере три компоненты.
- идентификатор утверждения;
текст
утверждения,
достаточно
детальный для реализации тестов;
конформные
или
эталонные
коды
результата тестирования.
6. Синтаксис для представления утверждений
Набор
утверждений
составляет
спецификацию
метода тестирования (TMS),
TMS должна:
обеспечивать
полное
покрытие
требований
конформности базового стандарта;
иметь
структуру
построения,
идентичную
базовому стандарту;
-- содержать утверждения, написанные только для
требований конформности и только для них
-- содержать утверждения, сформулированные таким
образом, чтобы код результата тестирования PASS («тест
прошел») указывал на конформность стандарту.
6. Синтаксис родового утверждения
For <Elemenr_1>, ..., <Element_n>:
If <Applicable_Standard> then
If <Option> then
If <Test_Support> then
(Setup: <Setup_Requirements>)*
Test: <Test_Text>
(TR: <Testing_Requirements>)*
(FTS: <Formal_Test_Specification>)*
(Note: <Notes>)*
Else <No_Test_Support>
Else <No_Option>
Else <No_Applicable_Standard>
{*
единственным
обязательным
элементом
<Generic_Assertion> является <Test_Text>}.
для
6. Элементы родового утверждения
For:
Применяется,
когда
тело
(текст)
утверждения применяется к некоторому набору
элементов.
Заголовок
“For”
обычно
используется при определении утверждений
типа “general”.
If Then Else: Конструкция ‘If <precondition>,
Then ... Else <outcome>’ используется для
задания
условий
применимости
текста
утверждения.
Applicable
Standard:
Определяет
базовые
стандарты,
которые
применяются
для
тестирования данного утверждения.
Option: Определяет дополнительные возможности
(опции) базового стандарта, которые должны
быть включены в реализацию для тестирования
данного утверждения.
6. Элементы родового утверждения
Test Support: Определяет оборудование или
программное обеспечение, не связанные с
базовым стандартом, но необходимые SUT для
тестирования данного утверждения
Setup Requirements: Определяет действия или
условия, которые необходимо выполнить перед
началом
тестирования
для
подготовки
соответствующей среды
Test Text: Текст тестируемого утверждения. Как
правило, тест утверждения имеет следующую
форму: <action> <result>
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()
3.1.1 Process Creation
Function: fork().
3.1.1.2 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) Анализируются выделенные фрагменты для решения
вопроса, определяют они требования конформности или
нет и, если определяют, данные фрагменты выделяются
таким же цветом, как и фрагменты, явно определяющие
требования.
14.3 Идентификация требований конформности
В процессе анализа особое внимание следует уделить
выявлению
условных
требований,
часто
определяемых с помощью связок
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. Отчет о результатах тестирования
Дополнительно должна быть включена следующая
информация:
•
Результат тестирования каждого утверждения;
•
Описание всех внесенных изменений в методы
тестирования;
•
Информация о том, как воспроизвести результаты
тестирования.
•
Тестируемая реализация соответствует стандарту
или профилю, когда каждый окончательный код
результата теста, полученный в результате
исполнения реализации метода тестирования,
отображается в некоторый конформный код
результата тестирования.