Тестирование прав доступа
Важная функция "большой" системы - ограничение доступа к данным. На этапе разработки тестирование можно выполнить вручную. Но в работающей системе, которая активно развивается, ручное тестирование прав очень трудоемкое и его очень не интересно делать. Особенно это касается регресса. Не буду говорить, что если у пользователя после обновления исчезли права, это стресс только для пользователя. Тогда как в ситуации когда пользователь вдруг получил дополнительный доступ к чувствительным данным, у всех будет стресс.
С важностью тестирования определились теперь рассмотрим, что можно тестировать. Рассмотрим 2 крупные возможности платформы: доступ к объектам и доступ на уровне записи.
Важно проверить возможность/не возможность создания и записи нужных объектов. Запись справочников и проведение документов приводят к записи вспомогательные данных, доступ к которым тоже важно проверить.
Тестовые сценарии будут содержать позитивные сценарии, которые проверяют доступ ко всем разрешенным объектам, и негативные сценарии, которые проверят запрет доступа к ключевым объектам, все запрещенные объекты проверять нет смысла.
В данном случае недостаточно проверить доступен ли объект, нужно проверить состав разрешенных данных и соответствуют ли они разрешению. Как правило доступ к объектам ограничиваться по ключевым аналитикам. Состав данных можно проверить через формы списков. Тест открывает форму списка и проверят, что в нем есть все разрешенные объекты и отсутствуют запрещенные.
Подошли к тому, как провести тестирование и какое требуется тестовое окружение. В первую очередь должно быть создано нужное количество пользователей. Количество пользователей должно соответствовать количеству профилей доступа. Данную информацию можно взять из матрицы доступа.
Рассмотрим гипотетический пример торговой системы в которой есть профили:
- менеджер по закупкам (МЗ) - пользователи с профилем МЗ должны видеть все документы Заказы поставщикам и Поступления товаров.
- менеджер по продажам (МП) - пользователи с профилем МП должны видеть все документы Заказы покупателей и Реализация товаров.
- бухгалтер (БУ) - пользователи с профилем БУ должны видеть все документы, но с ограничением по Организации.
Тестовое окружение будет выглядеть так:
- 3 пользователя: МЗ, МП, БУ
- 2 Организации
- профилю БУ дать разрешение на 1 Организацию
- создать по 1 одному документу с "запрещенной" Организацией
- создать по 1 одному документу с "разрешенной" Организацией
Тестовые сценарии будут следующими:
Сценарии для проверки доступа МЗ
- Позитивный: создать, записать и провести документ Заказы поставщикам
- Позитивный: создать, записать и провести документ Поступления товаров
- Негативный: создать документ Заказы покупателей
- Негативный: создать документ Реализация товаров
Сценарии для проверки доступа МП
- Позитивный: создать, записать и провести документ Заказы покупателей
- Позитивный: создать, записать и провести документ Реализация товаров
- Негативный: создать документ Заказы поставщикам
- Негативный: создать документ Поступления товаров
Сценарии для проверки доступа БУ
- Позитивный: список документов Заказы поставщикам содержит все документы с разрешенной Организацией
- Позитивный: список документов Поступления товаров содержит все документы с разрешенной Организацией
- Позитивный: список документов Заказы покупателей содержит все документы с разрешенной Организацией
- Позитивный: список документов Реализация товаров содержит все документы с разрешенной Организацией
- Негативный: список документов Заказы поставщикам НЕ содержит документов с запрещенной Организацией
- Негативный: список документов Поступления товаров НЕ содержит документов с запрещенной Организацией
- Негативный: список документов Заказы покупателей НЕ содержит документов с запрещенной Организацией
- Негативный: список документов Реализация товаров НЕ содержит документов с запрещенной Организацией
Далее запуск каждого сценария выполняется под пользователем, для которого предназначен сценарий.