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

Материал из GedeminWiki
(Различия между версиями)
Перейти к: навигация, поиск
(Структура таблиц)
Строка 46: Строка 46:
 
|parent
 
|parent
 
|[[dforeignkey]]
 
|[[dforeignkey]]
|Ссылка на родителя.
+
|[[Внешняя ссылка]] на родителя.
 
|}
 
|}
  

Версия 15:22, 30 ноября 2006

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

qa_test
Имя поля Тип данных Описание
id dintkey Первичный ключ.
parent dforeignkey Внешняя ссылка на родителя.

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

Regression testing

Персональные инструменты
Пространства имён

Варианты
Действия
Навигация
Инструменты