Просмотр исходного текста страницы Регрессионное тестирование настроек (постановка)

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

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

== Пользовательский интерфейс ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== qa_test ===

{| border="1" cellpadding="2" cellspacing="0" style="border-collapse:collapse;"
!style="background:#ffdead;" width="130px"| Имя поля 
!style="background:#ffdead;" width="200px"| Тип данных
!style="background:#ffdead;"| Описание
|- valign="top"
|id
|[[dintkey]]
|[[Первичный ключ]].
|- valign="top"
|parent
|[[dforeignkey]]
|[[Внешняя ссылка]] на родителя.
|- valign="top"
|lb
|[[dlb]]
|Левая граница интервала.
|- valign="top"
|rb
|[[drb]]
|Правая граница интервала.
|- valign="top"
|name
|[[dname]]
|Наименование теста.
|- valign="top"
|required_ruid
|[[druid]]
|[[РУИД]] настройки, от которой зависит данный тест. Если такая [[Настройка|настройка]] на базе не установлена, то тест выполняться не будет.
|- valign="top"
|functionkey
|[[dforeignkey]]
|Внешняя ссылка на скрипт-функцию теста.
|- valign="top"
|ismandatory
|[[dboolean]]
|Признак обязательного теста. Если флаг установлен и тест не выполнен (возникла ошибка), то все последующие тесты этого же уровня и всех вложенных уровней будут пропущены. Данный флаг полезен, например, в таком случае, когда некоторая функция подготавливает данные для последующих тестовых функций. Очевидно, что если она закончится неуспехом, то нет смысла выполнять последующие функции, так как без соответствующих данных они либо закончатся с ошибкой, либо приведут к ложноположительным результатам.
|- valign="top"
|timelimit
|[[time]]
|Если указано -- предельное время выполнения теста.
|}

=== qa_manual_test ===

{| border="1" cellpadding="2" cellspacing="0" style="border-collapse:collapse;"
!style="background:#ffdead;" width="130px"| Имя поля 
!style="background:#ffdead;" width="200px"| Тип данных
!style="background:#ffdead;"| Описание
|- valign="top"
|id
|[[dintkey]]
|[[Первичный ключ]].
|- valign="top"
|parent
|[[dforeignkey]]
|[[Внешняя ссылка]] на родителя.
|- valign="top"
|lb
|[[dlb]]
|Левая граница интервала.
|- valign="top"
|rb
|[[drb]]
|Правая граница интервала.
|- valign="top"
|name
|[[dname]]
|Наименование теста.
|- valign="top"
|required_ruid
|[[druid]]
|[[РУИД]] настройки, от которой зависит данный тест. Если такая [[Настройка|настройка]] на базе не установлена, то тест выполняться не будет.
|- valign="top"
|functionkey
|[[dforeignkey]]
|Внешняя ссылка на скрипт-функцию теста.
|- valign="top"
|ismandatory
|[[dboolean]]
|Признак обязательного теста. Если флаг установлен и тест не выполнен (возникла ошибка), то все последующие тесты этого же уровня и всех вложенных уровней будут пропущены. Данный флаг полезен, например, в таком случае, когда некоторая функция подготавливает данные для последующих тестовых функций. Очевидно, что если она закончится неуспехом, то нет смысла выполнять последующие функции, так как без соответствующих данных они либо закончатся с ошибкой, либо приведут к ложноположительным результатам.
|}

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

* [http://en.wikipedia.org/wiki/Regression_testing Regression testing]
* [http://www.s-test.elistel.net/Articles/regtest.htm Регрессионное тестирование]
* [http://dn.codegear.com/article/33979 The Drive for Quality Products]

[[Category:Постановка]]