Определить список тестовых сценариев для данного вида тестирования можно, используя:
- Спецификации на ПО
- Здравый смысл
- Схему базы данных
Учитывая повальный дефицит качественной документации, приходится ориентироваться в первую очередь на схему базы данных. Основной информацией служат внешние ключи. Следует учесть, что некоторые внешние ключи могут быть не созданы. В этом случае, тестер может неформально рассуждать о зависимости между объектами системы. Другой путь – это формальный просмотр схемы БД в поисках ошибок. Так если, есть таблицы 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] Полученный список избыточен, но проще выкинуть лишние строки, чем дописывать недостающие.
