Генератор тестов InputSpace TestGenerator. Часть 1.

О систематическом тестировании

Подход

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

Когда мы говорим о полном или исчерпывающем тестировании, то имеем в виду, что проверены все возможные варианты использования программного средства. Понимая невыполнимость в общем случае  решения такой задачи, необходимо рассматривать её как идеал, к которому нужно стремиться, проводя систематическое тестирование программного объекта. В качестве приближения к нему естественно ввести определение систематического тестирования как тестирования, охватывающее все «ветви» приложения или всю его инфраструктуру на уровне, по-крайней мере, классов эквивалентности.  Другими словами, здесь систематичность рассматривается в первую очередь как «равномерность», а не «плотность» охвата в качестве исходного приоритета.

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

Входное пространство приложения

Использование программного средства для решения задач конечного пользователя предполагает определенные физические манипуляции пользователя с конкретным экземпляром запущенного программного продукта (которые абстрактно можно назвать командами и вводами). При этом инфраструктура (все её внешние интерфейсы, внешнее строение) программного средства определяет тот горизонт, в рамках может действовать пользователь. Для оценки «полноты тестирования» необходимо ввести понятие потенциально полного входного пространства приложения как формального представления всех возможных манипуляций (вводов и команд) конечного пользователя (актора), допускаемых конструктивно соответствующим этому приложению программным средством. «Структура» этого пространства будет определяться строением инфраструктуры конкретного программного средства. Если мы выделяем, имея в виду инструмент InputSpace TestGenerator, систематическое тестирование вход/выход в отдельную подзадачу, то в общем случае, необходимо сформулировать условия корректности такого выделения (выделения без потери хотя бы потенциальной полноты полного входного пространства).

Методическая часть. Операции вход/выход в модели приложения

Методическая часть имеет целью формулировку условий встройки тестирования вход/выход, обеспечиваемое инструментом InputSpace TestGenerator, в рамки полного системного тестирования при сохранения требования систематичности.

Предлагается типовая модель системного тестирования программного средства   с графическим пользовательским интерфейсом (ГПИ).  Эта модель строится на основе декомпозиции инфраструктуры программного средства и на этой основе разбиения общей задачи систематического тестирования на отдельные виды.

Об инфраструктуре прикладного программного обеспечения

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

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

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

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

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

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

Отделение графического пользовательского интерфейса

Ограничимся рассмотрением приложений, ориентированных на графический пользовательский интерфейс (ГПИ).

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

Рисунок 1: инфраструктура приложения с ГПИ.

Инфраструктуру приложения с ГПИ можно рассматривать в двух разрезах: «вертикальном» (команды, обмен данными)  и «горизонтальном» (навигация по приложению).

В первом случае (рисунок 1) можно абстрагироваться от манипуляционного аспекта и рассматривать его как средство обмена данными между пользователем и приложением. Это в основном статический аспект рассмотрения. С этой точки зрения правильность ГПИ можно рассматривать как соответствие между внешними  входами и выходами в приложение и, обратного, между «внутренними» входами и средствами отображения. Во втором случае рассматривается динамический аспект приложения - обеспечения навигации для реализации сценариев решения пользовательских задач.

Программное гнездо

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

Единичный ввод в гнездо представляет собой совокупность значений информационных параметров, соответствующих отдельным входам гнезда.  Мы будем называть эту совокупность вектором входных значений, а специальную совокупность входных значений, используемую для тестирования - вектором тест-значений (ВТЗ).

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

Таблица 1. Организация гнезда и вводов.

Второй уровень - это транзакции вход/выход. Тестирование вход/выход охватывает основную прикладную функциональность программного средства. Основное назначение программного средства InputSpace TestGenerator  - контролируемая разработчиком тест-проекта генерация тест-наборов для тестирования вход/выход на уровне программных гнезд. Центральное значение при этом имеет гипотетическое структурирование входного пространства программного гнезда для выделения приоритетных подмножеств тестовых примеров.

Сценарии использования

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

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

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

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

Тестирование вход/выход и тестирование управления программным объектом (горизонтальный разрез) в общем случае не являются независимыми. По характеру управления прикладных программ можно выделить два крайних случая.

1. Поток управления не связан с потоком данных. Управление сводится к простому включению требуемых функций. Пример - управление типа меню. В этом случае тестирование вход/выход не зависит от потока данных.

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

Одно и то же гнездо входов в дизайне ГПИ может, вообще говоря, находиться в более, чем одном состоянии (изменение числа активных входов, изменение параметров доменов). Это связано с тем, что такое гнездо может использоваться в разных пользовательских сценариях. Кроме того, состояние гнезда может зависеть от внешних глобальных параметров (например, настроек).

Итоги

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

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

3. Тестирование потока внешнего управления выделяется в отдельную подзадачу. В рамках нее проводится сценарный анализ операций вход/выход. Он включает:

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

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