Регрессионное тестирование настроек (постановка)

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

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

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

Классификация ошибок

Рассмотрим категории ошибок применительно к платформе Гедымин и способы их тестирования.

Ошибки в логике программы

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

1. Создание экземпляра объекта;
2. Ввод исходных данных;
3. Вызов методов, выполнение заданного алгоритма;
4. Получение выходных данных и сверка их с эталонным результатом.

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

Ошибки на уровне пользовательского интерфейса

Ошибки в логике взаимодействия экранных элементов, а так же проверка их свойств (например, порядка табуляции). Применительно к Гедымину проблема усложняется тем, что мы не можем получить доступ к диалоговым окнам из кода макроса. Решить ее предлагается следующим образом: для тестирования формы создавать локальный макрос с зарезервированным именем qa_loc_ui_test. Изменить поведение формы таким образом, чтобы после ее создания и инициализации осуществлялась проверка на некоторый глобальный флаг тестирования. Если идет тестирование, то форма пытается отыскать локальный макрос с определенным именем и в случае успеха выполняет его.

Ошибки в отчетах

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

Ошибки в данных

Проверка полноты и корректности данных в базе. Например, в справочнике валют должны быть указаны наименования в необходимых падежах и числах для основных валют: белорусского рубля, доллара США, евро, украинской гривны, польского злотого и т.п.

Производительность

...

Ручное тестирование

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

Пример инструкции пошагового тестирования:

1. Вызвать команду "Исследователь" из меню "Окна" главного окна программы. На экране должно открыться и стать активным окно Исследователя системы;
2. Перейти в раздел "Сервис"-"Администратор". Установить курсор на позицию "Пользователи". Нажать клавишу Enter. Должно открыться окно со списком пользователей системы;
3. На панели инструментов найти и вызвать команду "Пересоздать всех пользователей". Гедымин должен выполнить операцию пересоздания, которая может занять несколько десятков секунд. Если операция прошла успешно на экран не будет выдано никаких сообщений.

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

Структура таблиц

qa_test

Имя поля	Тип данных	Описание
id	dintkey	Первичный ключ.
parent	dforeignkey	Внешняя ссылка на родителя.
lb	dlb	Левая граница интервала.
rb	drb	Правая граница интервала.
name	dname	Наименование теста.
required_ruid	druid	РУИД настройки, от которой зависит данный тест. Если такая настройка на базе не установлена, то тест выполняться не будет.
functionkey	dforeignkey	Внешняя ссылка на скрипт-функцию теста.
ismandatory	dboolean	Признак обязательного теста. Если флаг установлен и тест не выполнен (возникла ошибка), то все последующие тесты этого же уровня и всех вложенных уровней будут пропущены. Данный флаг полезен, например, в таком случае, когда некоторая функция подготавливает данные для последующих тестовых функций. Очевидно, что если она закончится неуспехом, то нет смысла выполнять последующие функции, так как без соответствующих данных они либо закончатся с ошибкой, либо приведут к ложноположительным результатам.
timelimit	time	Если указано -- предельное время выполнения теста.

qa_manual_test

Имя поля	Тип данных	Описание
id	dintkey	Первичный ключ.
parent	dforeignkey	Внешняя ссылка на родителя.
lb	dlb	Левая граница интервала.
rb	drb	Правая граница интервала.
name	dname	Наименование теста.
required_ruid	druid	РУИД настройки, от которой зависит данный тест. Если такая настройка на базе не установлена, то тест выполняться не будет.
functionkey	dforeignkey	Внешняя ссылка на скрипт-функцию теста.
ismandatory	dboolean	Признак обязательного теста. Если флаг установлен и тест не выполнен (возникла ошибка), то все последующие тесты этого же уровня и всех вложенных уровней будут пропущены. Данный флаг полезен, например, в таком случае, когда некоторая функция подготавливает данные для последующих тестовых функций. Очевидно, что если она закончится неуспехом, то нет смысла выполнять последующие функции, так как без соответствующих данных они либо закончатся с ошибкой, либо приведут к ложноположительным результатам.

Ссылки по теме

• Regression testing
• Регрессионное тестирование
• The Drive for Quality Products