Часть XV

15.2. Принципы функционирования лаборатории тестирования

    15.2.1. Назначение и направление деятельности

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

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

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

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

    - организации-разработчики реализаций ИТ;

    - организации-поставщики реализаций ИТ;

    - организации-пользователи реализаций.

    15.2.2. Основные задачи

    Основными типовыми задачами ЛТК являются:

    - предоставление гармонизированных удовлетворяющих требованиям международных стандартов услуг в области тестирования конформности продуктов ИТ;

    - организация и проведение тестирования реализаций ИТ с целью установления их конформности исходным спецификациям (в частности, базовым стандартам и профилям), а также с целью сертификации продуктов ИТ на соответствие стандартам;

    - организация и проведение тестовых испытаний с целью оценки и демонстрации свойств открытости продуктов ИТ таких, как, например, переносимость, интероперабельность, масштабируемость;

    - внедрение и развитие методов и средств тестирования конформности продуктов ИТ, включая разработку комплектов тестов (test suites), средств автоматизации генерации тестовых программ и тестовых наборов данных, средств поддержки тестовых испытаний;

    - создание и сопровождение базы данных для хранения и обработки информации о проводимых испытаниях и их результатах;

    - взаимодействие с международными организациями по стандартизации и другими лабораториями и центрами тестирования;

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

    Для более полного понимания характера деятельности ЛТК рассмотрим на концептуальном уровне модель ее функционирования.

    15.2.3. Участники процесса установления конформности

    Следуя стандарту ISO/IEC 9646-5, будем выделять следующие потенциально возможные категории участников процесса установления конформности, различая их по отношению к тестируемой реализации и результатам ее тестирования:

    1) поставщики продуктов;

    2) разработчики тестовых спецификаций;

    3) создатели (реализаторы) тестовых комплектов;

    4) тестовые лаборатории;

    5) клиенты тестовых лабораторий.

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

    Рассмотрим роли участников этого процесса подробнее.

    Поставщики реализаций (продуктов)

    Поставщики, в общем случае, представляют собой фирмы, осуществляющие создание продуктов ИТ на основе базовых стандартов или профилей и объявляющие свои продукты конформными исходным стандартным спецификациям. Заявка на конформность реализаций стандартам осуществляется посредством документа стандартизованной формы - ICS (Implementation Conformance Statement), подтверждающего, что данная реализация поддерживает все обязательные средства исходных стандартов, а также определяющего какие дополнительные возможности (options) в ней реализованы.

    Разработчики тестовых спецификаций

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

    Создатели тестов

    Создатели (реализаторы) тестов осуществляют разработку для заданных абстрактных комплектов тестов соответствующие им средства тестирования (Means of Testing). Средства тестирования могут содержать одну или более систем тестирования (тестовых окружений) и исполнимый (на этих системах тестирования) комплект тестов.

    Лаборатория тестирования

    Тестовые лаборатории предоставляют сервис в области тестирования конформности реализаций ИТ. Тестируемые продукты ИТ проходят испытания в лабораториях в соответствии с выбранным и согласованным между лабораторией и клиентом абстрактным методом тестирования. По типу тестируемого продукта и типу выбранного метода тестирования определяется соответствующий данной ситуации абстрактный комплект тестов, для которого тестовой лабораторией подбираются соответствующие средства тестирования (исполнимый комплект тестов и система тестирования). Результатом испытаний тестируемой реализации служит итоговый отчет о тестировании конформности реализации (System Conformance Test Report), а также более детальные частные отчеты.

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

    Клиенты лаборатории

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

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

    Процесс установления конформности, реализуемый ЛТК, распадается на следующие три основные фазы:

    - подготовка к процессу тестирования;

    - тестовые операции;

    - составление отчета о тестировании.

    В рамках данного процесса возможны итерации как внутри каждой фазы, так и между фазами.

    Фаза подготовки

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

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

    Клиент также несет ответственность за составление другого документа, содержащего дополнительную информацию о тестировании реализации. Данный документ имеет сокращенное название IXIT (implementation extra information for testing). Этот документ дополняет ICS информацией, необходимой для выполнения тестирования, включая, например, адресную информацию, пароли, информацию о требуемых файлах, а также информацию о том, как абстрактные примитивы, упоминаемые в абстрактном комплекте тестов отображаются реальные события, связанные с тестируемой реализацией.

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

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

    Тестовые операции

    После подготовительной фазы, или, возможно, во время ее, лабораторией тестирования проводится так называемый анализ статической конформности (Static Conformance Review), т.е. статических требований конформности. Он включает проверку ICS и IXIT на согласованность и полноту, а также выявление любых явных нарушений конформности. В результате такого обзора могут обнаруживаться факторы, которые делают исследуемый продукт полностью или частично не тестируемым. На данном этапе возможно прекращение процесса тестирования, если результаты обзора статических требований показывают бессмысленность продолжения данного процесса.

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

    После отбора актуальных тестов, они должны быть параметризованы при помощи информации, полученной из IXIT, и содержащей значения параметров, необходимые для настройки комплекта тестов. Данный шаг фактически представляет собой отображение множества абстрактных тестовых ситуаций на множество исполнимых тестов. В результате выполнения действий селекции и параметризации тестов получается параметризованный исполнимый комплект тестов (Parameterized Executable Test Suite) или, сокращенно, PETS, который и подлежит исполнению.

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

    Составление отчета о тестировании

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

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

    И, наконец, на основе детального отчета о выполнении комплекта тестов составляется итоговый документ - SCTR или отчет о тестировании конформности системы.

    Вердикты выполнения тестов

    Тест обычно имеет своим результатом один из трех вердиктов: “прошел” (Pass), “не прошел” (Fail), “не закончен” (Inclusive). Вердикт “прошел” показывает, что цель теста была успешно достигнута и не было обнаружено неконформного поведения. Вердикт “не прошел” показывает, что либо тест потерпел неудачу по отношению к цели теста, либо было обнаружено неконформное поведение. Вердикт “не закончен” соответствует ситуации, когда выполненному тесту не может быть присвоен ни вердикт “прошел”, ни вердикт “не прошел”, и, следовательно, требуется дальнейший анализ.

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

    Если, однако повторяется вердикт “не закончен”, то должна быть произведена проверка того, что это не является результатом ошибки тестовой системы или теста. Если это не так, т.е. средства тестирования невиновны в ошибке, то вердикт “не закончен” фиксируется в отчете о тестировании.

    Если тест отмечет как невыполненный из-за ошибки, то возможны следующие причины ошибки: ошибка в абстрактном тесте, ошибка исполнимого теста, неправильное завершение теста.

    Схематическая иллюстрация процесса установления конформности и распределение ответственности ролей на протяжении этого процесса приведена на рис. 15.1.

Рис. 15.1. Модель процесса установления конформности и распределение ответственности ролей на протяжении этого процесса

    15.2.5. Комплекты тестов

    Наиболее важной для технологии конформности формой тестов являются абстрактные комплекты тестов (abstract test suite) или ATS, каждый их который воплощает все возможные аспекты выбранного абстрактного метода тестирования. ATS определяется в форме, независимой от конкретной системы тестирования, но на достаточно детальном уровне, чтобы специфицировать присвоение вердикта для каждой возможной последовательности тестовых событий. На основе ATS создаются исполнимые комплекты тестов (executable test suite) или ETS для конкретной системы тестирования. Каждый тест в ETS по существу представляет собой реализацию одного соответствующего теста из ATS, хотя может случиться так, что некоторые абстрактные тесты могут оказаться нереализуемыми на данной системе тестирования.

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

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

     преамбулу теста,

     тело теста и

     постамбулу или суффикс теста.

     Преамбула теста приводит реализацию (тестируемый продукт) к правильной начальной установке для выполнения цели теста.

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

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

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

     Структура тестового комплекта иллюстрируется на рис. 15.2.

Рис. 15.2. Структура тестового комплекта

    15.2.6. Методы тестирования

    В методологии тестирования ISO/IEC 9646 вводятся понятия верхнего и нижнего тестеров (upper и lower testers), что иллюстрируется на рис. 15.3.

    • Верхний тестер (upper tester - UT) представляет собой средства, обеспечивающие контроль и наблюдение на верхней IUT в процессе тестирования IUT.

    • Нижний тестер (lower tester - LT) представляет собой средства, обеспечивающие контроль и наблюдение за поведением IUT через нижележащего поставщика сервиса.

Рис. 15.3. Взаимосвязь IUT, нижнего и верхнего тестеров

     Абстрактные методы тестирования обычно описываются в терминах точек контроля и наблюдения (PCOs), которые принадлежат системе тестирования, и с помощью которых осуществляется анализ поведения тестируемого продукта и управления им. На рис. 15.4 показана обобщенная архитектура тестирования с указанием позиций для PCOs. Несмотря на то, что данная архитектура основана на методологии OSI, она может иметь более широкое трактовку и применяться для тестирования других типов интерфейсов. На рис. изображены три типа точек PCOs.

     Классификация абстрактных методов тестирования зависит от комбинации используемых PCOs и особенностей их применения.

     Если PCOs доступны только в позиции А, то обычный метод тестирования называется Удаленным методом тестирования (Remote test method), так как внутри тестируемой системы (т.е. системы, в которой располагается продукт, подвергающийся процессу тестирования конформности) нет точек контроля и наблюдения.

     Если, однако, над тестируемой системой отсутствует какая-либо функциональность, тогда метод тестирования называется Методом тестирования ретрансляционных компонент (Relay Component test method). Он используется для тестирования продуктов типа ретрансляторов с помощью двух или большего числа внешних тестеров.

     Если PCOs доступны как в позиции А, так и в позиции В, тогда говорят, что используется Распределенный метод (Distributed method), в котором тесты специфицируют поведение как внешнего, так и внутреннего тестеров, показанных на рисунке.

     Если, однако, тестируемая система может также поддерживать стандартный протокол управления тестированием (Test Management Protocol) или TMP как реализацию процедуры координации тестов, тогда может быть использован Координированный метод тестирования (Coordinated test method); в этом случае тесты нужны только для определения поведения внешнего тестера, включающего использование TMP, с помощью которого отражается соответствующее поведение внутреннего тестера.

     Когда PCOs доступны для внешнего контроля и наблюдения в позициях B и C, тестовый метод называется Локальным тестовым методом (Local test method), и в этом случае внутренний тестер располагается внутри тестируемой системы.

     Если при тестировании конформности используются PCOs в позиции либо B, либо C, необходимо установить связь между абстрактными событиями в этих PCOs, специфицированных в ATS, и реальными событиями, являющимися их реализацией в тестируемой системе. Данная связь обеспечивается клиентом с помощью документа IXIT.

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

Рис.15.4. Обобщенная архитектура тестирования