Архив рубрики 'Целостность данных'

Каскадное удаление данных. Обработка попытки удаления объекта, на который есть ссылки.

Четверг, Сентябрь 28th, 2006

С точки зрения программиста все просто. Навешиваем констрейны на базу данных. При попытке удаления перехватываем эксепшен и делаем ролбек транзакции.
А пользователь вместо элементарной последовательности:
Вызов меню / попытка нажатия на кнопку удаления. Все приехали, вижу что невозможно.
вынужден идти по длинному пути:
Вызов меню -> отдание команды на удаление -> подтверждение команды.
Расчет времени по GOMS [1] дает 2.4 - 3.6 секунды в первом случае и 8.4 во втором. В случае же Web приложения во втором варианте добавляются еще две задержки приложения 2-6 секунд. А это уже очень серьезно. Одно дело за 2.5 секунды понять, что удаление невозможно и совсем другое в течение 10 - 15 секунд заниматься нудной работой, забыть, что же делать дальше и выяснить, что все это напрасно.
Выдача пользователю информации о блокирующих объектах легко решается. Раз приложение знает, почему нельзя удалять, то этот список уже есть. Значит можно показывать его во всплывающей подсказке.
Пожалуй, еще один довод в пользу плохого интерфейса - это разгрузка сервера. Необходимость считать возможность удаления для всех элементов, даже если пользователь ничего удалять не собирается накладно. Но это обходится введением дополнительного свойства объекта «Есть ли ссылки?». Пропадает информативность? Хорошо, добавим команду «показать список блокирующих элементов»
Как это ни странно, но иногда использование констрейнов приводит к усложнению структуры базы данных.
Итак, все сводится к некоему усложнению кодирования. Что перевесит: удобство программирования или удобство использования? Пока в подавляющем количестве случаев программеры одерживают верх над конечными пользователями.
И это еще одна истина из длинного списка неприятных, поскольку «утаить их - нечестно, сказать же правду - значить, вызвать огонь на себя».

———————————————-
[1] Метод GOMS предложен в 1983г. Этот метод неплохо описан в книге “Дизайн пользовательского интерфейса” Влада Головача.

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

Вторник, Июль 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] Полученный список избыточен, но проще выкинуть лишние строки, чем дописывать недостающие.

Магические числа.

Пятница, Июнь 17th, 2005
При прогоне приемочных тестов была обнаружена ошибка. Приложение падало при попытке сохранения новой формы.
Рассмотрим форму, о которой идет речь [1].
form_1.PNG
Форма, как форма. «Название организации» обязательно к заполнению, «Комментарий» необязателен, «Форму собственности» нельзя не выбрать (комбобокс без неопределенного значения).
Приемочный тест: Заполнить обязательные поля и сохранить.
Это было странно. Данный участок кода ранее был хорошо оттестирован и не нуждался в доработке. Беседа с программистами еще более увеличила удивление. Очень давно в код не вносилось изменений. Структура БД так же не менялась. Но приложение падает. Стектрейс говорит о нарушении ссылочной целостности. При этом в БД такая форма есть.
В ходе дальнейшего тестирования выясняется, что приложение не падает, если войти в комбобокс и выбрать форму собственности. Можно даже ту же самую.
Дальнейшее исследование показывает:
• Если форму собственности не выбирать, то значение не устанавливается и передается NULL
• В БД данных запрещен ввод неопределенного значения в данное поле и проставлено значение по умолчанию «2»
• Ранее такой идентификатор имела запись в справочнике форм собственности, но в связи с изменением политики идентификаторов, ей был присвоен другой номер.

Ошибки программирования. Несмотря на отображаемое значение по умолчанию, форма передает неустановленное значение. Это плохая практика. Если отображаешь значение по умолчанию, то устанавливай его принудительно в форме, на уровне пользовательского интерфейса. Все остальные уровни: бизнес логика, ядро, БД – должны получать правильные данные. Но самое отвратительное, это способ постановки заплатки. Программист перенес часть логики программы на уровень хранимых данных, использовав магическое число “2″. Это примерно то же самое, как если бы правила умножение в Excel, зависели от введенных данных [2].

И самый главный вывод для тестера:
Даже если оттестированный код и структура БД не менялись, и вы проверили это лично, не надеясь на заверения программиста, приемочные тесты прогнать все-таки стоит.
——————————————————————————
Примечания.
[1] Форма упрощена.
[2] Иногда, без магических чисел не обойтись.