Архив за Июль, 2005

Выявление сценариев для тестирования ссылочной целостности.

Вторник, Июль 5th, 2005

Определить список тестовых сценариев для данного вида тестирования можно, используя:

  • Спецификации на ПО
  • Здравый смысл
  • Схему базы данных

Учитывая повальный дефицит качественной документации, приходится ориентироваться в первую очередь на схему базы данных. Основной информацией служат внешние ключи. Следует учесть, что некоторые внешние ключи могут быть не созданы. В этом случае, тестер может неформально рассуждать о зависимости между объектами системы. Другой путь – это формальный просмотр схемы БД в поисках ошибок. Так если, есть таблицы document с полем bankID и таблица bank, а внешнего ключа нет, то, скорее всего, это ошибка структуры БД. Такие ситуации достаточно часты, но не всегда это приводит к ошибкам приложения. [1]

Узнать общее число сценариев можно при помощи простого запроса (пример для MSSQL):

SELECT     COUNT(*) AS Expr1
FROM         sysforeignkeys

Полный список (пример для MSSQL):

select t1.*, t2.referencedTable, t2.referencedColumn
from
(SELECT   k.constid, k.keyno, t.name referencingTable, c.name referencingColumn
  FROM    sysforeignkeys k, sysobjects t, syscolumns c
 Where t.id=c.id and t.id = k.fkeyid and c.colid=k.fkey) t1 
JOIN
(SELECT   k.constid, t.name referencedTable, c.name referencedColumn, k.keyno
 FROM    sysforeignkeys k, sysobjects t, syscolumns c
 Where t.id=c.id and t.id = k.rkeyid and c.colid=k.rkey) t2
on t1.constid = t2.constid and t1.keyno=t2.keyno
Order by t1.referencingTable

Внешний ключ из нескольких столбцов представлен строками с одинаковыми значениями в поле constid и возрастающими значениями keyno.
Каждая строка, кроме keyno>1 соответствует одному возможному сценарию [2]. Для хорошо спроектированной БД таким скриптом можно выявить 70-90 процентов необходимых сценариев тестирования ссылочной целостности, а остальные придется дописывать после тщательного изучения системы.

Формируем список сценариев. Каждый из них включает следующую информацию:

  • удаляемая запись / объект
  • зависимая запись / объект
  • ожидаемое поведение системы
  • в каких таблицах смотреть не осталось ли “мусора”

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

При заполнении чеклиста, в случае провала теста, настоятельно рекомендую указывать номер ошибки.
————————————————————————————
[1] Возможна реализация ссылочной целостности через код или есть дополнительная таблица, через которую и идет контроль. Подчеркну, что речь идет не реализации связи многие ко многим через промежуточную таблицу и два внешних ключа, а именно дополнительная таблица, одна на всю базу (аналог sysforeignkeys для MSSQL). Характерно для БД, не поддерживающих FK.
[2] Полученный список избыточен, но проще выкинуть лишние строки, чем дописывать недостающие.

Базовые термины.

Пятница, Июль 1st, 2005

Мы достаточно часто спорим об определениях, или еще хуже, бросаемя в бой, не договорившись о предмете спора. Что делать, точные определения - это удел невероятно скучных, многотомных исследований. Но попробуйте их осилить. Уверею вас, что многие задаваемые вопросы или задачи, над которыми люди бьются неделями решаются просто “по определению”.

Материал взят из работ Анисимова. Большое спасибо моему другу Сергею Середе, приславшему эти определения.
(more…)