ПРОЕКТИРОВАНИЕ БАЗЫ ЗНАНИЙ ЭКСПЕРТНОЙ СИСТЕМЫ ТЕСТИРОВАНИЯ API

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

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

Альтернативным решением является применение интеллектуальных систем на двух видах искусственного интеллекта (ИИ): нейронные сети (НС) и экспертная система (ЭС).

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

При решении задач с применением НС используются апостериорные знания (знания, полученные с помощью органов чувств), а с применением ЭС - априорные знания (логические утверждения, математические законы и т.д.).

Тестирование ПО, в частности API, не требует органов чувств, а базируется на логических суждениях, поэтому применение ЭС в качестве интеллектуальной системы является наиболее предпочтительным.

Знания, образующие целостное описание, информируют ЭС о рассматриваемом объекте или задаче. Формально их можно разделить на процедурные, декларативные и неявные:

• процедурные знания - “как делать”;
• декларативные знания - “является ли это истиной или ложью”;
• неявные знания - уровень подсознания, в том числе и экспертные знания (навыки эксперта в определённой предметной области, которые необходимо преобразовать в процедурные и декларативные знания, чтобы ЭС могла их использовать при решении задач).

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

В данном случае, процедурными знаниями будут знания проверки входных параметров API. Например, параметр является целым числом, то для ЭС нужны знания по тестированию целого числа:

• число меньше 0;
• число больше 0;
• вместо целого числа использовать дробное;
• вместо цифр использовать буквенные символы, например “qwerty”.

Декларативные знания в ЭС могут использоваться при составлении отчета по тестированию. После запроса метода API приходит ответ, который может содержать в себе данные. Проверка вносимых данных и будет говорить об истинности ответа от сервиса, тем самым, обеспечивая сравнение между ожидаемым и фактическим результатом.

Неявные знания в такой системе отсутствуют, за исключением экспертных знаний. Экспертными знаниями могут выступать знания различных техник и методик тестирования, техники тест дизайна (“тестирование граничных значений” и “классы эквивалентности”).

Для представления знаний в ЭС используются различные способы и методы. Классический способ представления - Семантические сети (СС).

С математической точки зрения, СС - это помеченный ориентированный граф, в котором узлы - объекты, а дуги - связи с отношениями.

При проектировании разработчики сталкиваются со следующими СС проблемами:

• Ограничения со стандартом именования названий узлов и связей, из-за чего появляются затруднения в понимании, для чего была создана какая-то конкретная сеть и правильно ли она создана. Были придуманы внутренние стандарты разработки (“IS-A” - “это”, “HAS-A” - “имеет”, “AKO” - “разновидность”). При этом используют триплет (“объект - атрибут - значение”), где связь “IS-A” между значением и атрибутом, связь “HAS-A” между объектом и атрибутом, связь “AKO” между объектами триплетов [3, с. 148]. На рисунке 1 представлена простая семантическая сеть с вышеперечисленными связями.

Рисунок 1. Семантическая сеть со связями IS-A, HAS-A, AKO (A-KIND-OF)

• При осуществлении поиска по узлам может возникнуть эффект резкого (взрывного) роста временной сложности алгоритма. Это происходит при отрицательном ответе на запрос. В этом случае потребуется выполнение поиска по многим или даже всем связям в сети. Если представлен полный граф, то количество связей в такой сети растёт по факториалу n!-1, где n - количество узлов в сети.
• Данные сети неприменимы для эвристических методов.

«После исследований СС было установлено, что такие сети хорошо применимы для бинарных отношений…» [3, c. 159], но вышеперечисленные проблемы ограничивают использование данной методологии.

Одним из основных методов тестирования является использование типовых наборов тестов, включающих следующие зависимости:

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

С учётом вышеперечисленных замечаний для решения задачи интеграционного тестирования нами был выбран другой вид представлений - фрейм. Фрейм - это сценарий, который является упорядоченной во времени последовательностью.

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

         Существуют нескольких типов фреймов:

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

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

Тестирование API сводится к двум основным знаниям: корректность данных и смысл данных.

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

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

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

Поскольку фреймы описывают объект полностью, мы не используем его в первоначальном виде. Для ЭС по тестированию API необходимо объект разбить на свойства и объединить в один фрейм. При этом необходимо указать:

• "что ожидать" - для прогнозирования ошибки (ситуативный фрейм);
• "что делать" - для создания набора тестов (фреймы действий).

В нашем случае запрос к API содержит имя метода, в котором указаны все необходимые параметры и их значения. Ранее в статье говорилось о том, что параметры состоят из простых элементов - текст, числа, списки. На рисунке 2 представлена сеть фреймов для описания объекта "число".

Рисунок 2. Фрейм описания свойств объекта "число" для метода в API

Для всех параметров метода в API есть несколько одинаковых свойств. В таком случае необходимо сделать отдельный фрейм "общие свойства параметров". Прохождение по этому фрейму поможет сгенерировать тесты и подготовить для них анализ ошибок. Например, если параметр является обязательным для метода, а он не включён в тест, то ЭС должна спрогнозировать, что должна быть ошибка "обязательный параметр". Так как полный набор тестов будет включать оба варианта, в случае, если оба варианта ведут к ошибке, то ЭС должна спрогнозировать ошибку "Иное". Поскольку ошибок может быть большое количество, необходимо тщательно продумать прогнозирование и определить все возможные ситуации. На рисунке 3 представлена разработанная нами часть обработки и прогнозирования ошибок различных параметров метода.

Рисунок 3. Фрейм обработки общих свойств разных параметров

После того, как ЭС дойдёт до определения типа параметра, для каждого конкретного параметра были реализованы свои проверки. На рисунке 4 представлен фрейм проверок объекта "число".

Такое разбиение объекта на свойства поможет вписать ситуативные фреймы, тем самым обеспечив логику прогнозирования и анализа ошибки при тестировании метода API. Некоторые из участков нашего фрейма, например, техника тест-дизайна "граничные условия", содержит в себе так же разбиение на различные этапы проверок и действий. Такой подход похож на выделение абстрактных классов и дальнейшее наследование в ООП.

Рисунок 4. Фрейм обработки свойств объекта "число"

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

Список литературы:

1. Брукинг А., Джонс П., Кокс Ф. и др. Экспертные системы. Принципы работы и примеры. М.: Радио и связь, 1987. – 224 с.
2. Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных систем. СПб.: Питер, 2000. ‒ 384 с.
3. Джарратано Джозеф, Райли Гари. Экспертные системы: принципы разработки и программирование ‒ 4-е изд. Пер. с англ. ‒ М.: "И.Д. Вильямс", 2007. – 1152 с.
4. Майерс Г., Баджетт Т., Сандлер К. Искусство тестирования программ ‒ 3-е изд. Пер. с англ. ‒ М.: "И.Д. Вильямс", 2016. – 272 с.