Часть VII

7.6 Коды результатов тестирования

    В методе тестирования конформности POSIX используются два типа кодов результатов тестирования: промежуточные (intermediate) и конечные (final).

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

    В рассматриваемом стандарте определено два значения промежуточных кодов:

• UNRESOLVED
• INCOMPLETE

    Промежуточный код UNRESOLVED соответствует таким ситуациям, как, например:

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

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

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

    Состав конечных кодов результатов тестирования следующий:

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

    Состав рассмотренных выше кодов может при необходимости расширяться.

    В целом рассмотренная методология широко применяется для разработки стандартных методов тестирования (Standard Test Methods) и методов тестирования спецификаций для стандартов POSIX. Она применима также для разработки спецификаций методов тестирования конформности широкого класса API-интерфейсов.

    Ниже приведены примеры записи утверждений различных типов, взятых из документа IEEE Std 2003.1b-2000 (IEEE Standard for Information Technology-Test Methods Specifications for Measuring Conformance to POSIX-Part 1: System Application Program Interface (API)-Amendment 1: Realtime Extension [C Language]). Этот документ определяет спецификацию метода тестирования для базового стандарта IEEE Std 1003.1b-1993 (расширение API IEEE Std 1003.1 для реального времени).

    В методе тестирования, из которого далее мы будем рассматривать отдельные примеры определения утверждений конформности, используются так называемые PCTS-переменные (PCTS-variables, в большинстве своем булевского типа). Они используются в управляющих структурах "IF... Otherwise" совместно с символьными константами периода компиляции {_POSIX_}. Если символьные константы указывают на включение в реализацию тех или иных дополнительных возможностей (опций), то PCTS-переменные указывают на выбор для реализации некоторых отдельных функций из опций. Например, если реализация включает функцию sem_init(), но не поддерживает другие функции опции {_POSIX_SEMAPHORES_}, то для описания релевантной конфигурации потребовалось бы использование символьной переменной PCTS_sem_init со значением TRUE.

    Пример 1. Утверждения конформности основного типа, определяющие требования конформности для системных функций управления процессами.

:
Section 3: Process Primitives
3.1 Process Creation and Execution
3.1.1 Process Creation
Function: fork().

:
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

2 IF PCTS_sem_open THEN
IF PCTS_GAP_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_TEST_SUPPORT
ELSE NO_OPTION
Conformance for fork: PASS, NO_TEST_SUPPORT, NO_OPTION

    Пример 2. Применение механизма макросов для порождения утверждений конформности общего типа (GA), определяющих требования конформности к переносимости имени файла, используемого в качестве фактического параметра в вызовах системных функций.

:
M_GA_portableFilenames(function())=
TEST: The interface function () supports filenames containing any of the characters in the portable
filename character set.
TR: Test for filenames containing the following characters:
A B D C E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -The last three characters are the period, underscore, and hyphen, respectively.

GA_portableFilenames
FOR: execl(), execle(), execv(), execve(), exelp(), execvp(), opendir(), chdir(), open(), creat(), link(), existing, link() new, mkdir(), mkfifo(), unlink(), rmdir(), rename(), old, rename(), new, stat(), access(), chmod(), chown(), utime(), pathconf(), fopen(), freopen(), remove(), tar format creating utility, and cpio format creating utility.
M_GA_portableFilenames(function())
Conformance for definition: PASS

    Пример 3. Утверждение ссылочного типа, определяющее требования конформности для системных функций управления семафорами.

:
2.2.2.108 semaphore lock operation:

R_1 FOR: sem_init() and sem_open()
IF PCTS_sem_wait THEN
IF PCTS_function THEN
SETUP: Create a semaphore using function ().
TEST: When a call to sem_wait (sem) completes successfully, the interface returns a value of 0, and the semaphore designated by sem is locked by the semaphore lock operation.
TR: When testing for sem_init(), perform the test consistent with the flag PCTS_GAP_sem_init; that is, generate a NO_TEST_SUPPORT test result code if there is no way to get appropriate privilege to call sem_init().
NOTE: The assertion is to be tested once for each function specified in the FOR clause. The assertion is to be read by substituting function() with the current function specified in the FOR clause. The name of the function also is to be substituted for each occurrence in the construct PCTS_function.
ELSE NO_TEST_SUPPORT
ELSE NO_OPTION
SEE: Assertion sem_wait in 11.2.7.2

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

:
3.2.2 Terminate a Process
Function: _exit().
:
1 IF PCTS_sem_open THEN
IF PCTS_sem_trywait and PCTS_sem_getvalue THEN
SETUP: Create {PCTS_SEM_NSEMS_MAX} named semaphores with large initial values and lock each one at least once.
TEST: After a call to _exit(), all open named semaphores in the calling process have no effect on the state of such semaphores.
ELSE NO_TEST_SUPPORT
ELSE NO_OPTION
Conformance for _exit: PASS, NO_TEST_SUPPORT, NO_OPTION

2 FOR: mlock() and mlockall()
IF PCTS_function() THEN
IF PCTS_GAP_function() THEN
SETUP: Lock all pages of the process in memory.
TEST: Any memory locks established by the process via calls to function() are removed after a call to _exec().
NOTE: The assertion is to be tested once for each function specified in the FOR clause. The assertion is to be read by substituting function() with the current function specified in the FOR clause. The name of the function also is to be substituted for each occurrence in the construct PCTS_function.
ELSE NO_TEST_SUPPORT
ELSE NO_OPTION
Conformance for _exit: PASS, NO_TEST_SUPPORT, NO_OPTION

:
4 IF PCTS_mmap THEN
TEST: Memory mappings created in the process are unmapped before the process is destroyed after a call to _exec().
ELSE NO_OPTION
Conformance for _exit: PASS, NO_TEST, NO_OPTION
:
6 IF {_POSIX_ASYNCHRONOUS_IO} THEN
TEST: Those asynchronous I/O operations that are not canceled after a call to _exit() completes, as if the _exit() operation had not yet occurred, but any associated signal notifications are suppressed.
NOTE: There is no known portable test method for this assertion.
ELSE NO_OPTION
Conformance for _exit: PASS, NO_TEST, NO_OPTION
:

Пример 5. Утверждения типа документация, определяющие необходимость документирования зависящих от реализации семантических аспектов выполнения функции завершения процессов в конформной требованиям документации, соответствующей реализации стандарта IEEE Std 1003.1b (PCD.1b).

:
D_1 IF a PCD.1b documents the following THEN
TEST: A PCD.1b that documents whether or not the _exit() operation itself blocks awaiting the completion of asynchronous I/O does so in 3.2.2.2.
ELSE NO_OPTION
Conformance for _exit: PASS, NO_OPTION

D_2 TEST: The PCD.1b documents whether any asynchronous I/O is canceled, and which asynchronous I/O may be canceled upon a call to _exit() in 3.2.2.
Conformance for _exit: PASS

Пример 6. Применение механизма макросов для порождения утверждений конформности типа общей документации (GD), определяющих необходимость документирования отличий интерфейса системных функций от требований стандарта языка С.

:
1.3.3.3 Common-Usage C Language-Dependent System Support
:
M_GD_CommonC_diffs (function) =
FOR: function ()
IF the implementation does not provide C Standard {2} support THEN
TEST: Subclause 8.1 of the POSIX.1b contains the details of all differences between the interface function () provided and that required by the C Standard {2}.
ELSE NO_OPTION

GD_CommonC_diffs
FOR: function ()
M_GD_CommonC_diffs (function)
Conformance for conformance: PASS, NO_OPTION