Техники тест-дизайна для 1С и Vanessa Automation

Техники тест-дизайна применяются в процессах разработки и внедрения IT-продуктов. QA-инженеры или тестировщики 1С разрабатывают тест-кейсы, чтобы устранять баги и ошибки до выпуска релиза. Тест-дизайн — модное слово, за которым скрывается обычная работа по покрытию тестами IT-продукта.

Тесты программного обеспечения делятся на виды: модульные, интеграционные, функциональные, регрессионные, нагрузочные. В хорошем проекте задействуется большинство видов тестирования, причем часто тесты пересекаются между собой. В 1С для тестирования в основном используются фреймворки, таки как 1С:Сценарное тестирование, 1С:Тестер и конечно же Vanessa Automation.

Тестировщики 1С разрабатывают и проверяют наборы тестовых сценариев, или как их называют тест-кейсы. Необходимо разработать тест-кейсы таким образом, чтобы покрыть большиство сценариев работы программы. Для этого существуют фреймворки, или подходы по разработки тестов, а именно техники тест-дизайна. Далее разберем самые распрастраненные техники тест-дизайна применительно в 1С:

1. Эквивалентное разбиение (Equivalence Partitioning)

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

Например, перед нами стоит задача протестировать диапазоны предоставляемых скидок в зависимости от суммы продажи. У нас есть диапазоны:

• до 1000 рублей — 5%
• 1000-5000 рублей — 10%
• свыше 5000 рублей — 15%

В этом случае тестировщику необходимо проверить 3 случая, выбрав суммы входящие в соответствующие диапазоны:

• до 1000 рублей — 5% — 750 рублей
• 1000-5000 рублей — 10% — 2500 рублей
• свыше 5000 рублей — 15% — 7000 рублей

Таким образом, всего 3 тест-кейса покроют любое поведение пользователя 1С. В Vanessa Automation рекомендуется вынести весь бизнес-процесс в отдельную процедуры, а значения из диапазонов тестирования передавать в качестве параметров. Данный способ уменьшает количество дублированного кода сценариев тестирования.

2. Граничные значения (Boundary Value Analysis)

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

Касательно нашего предыдущего примера, дополнительно нужно проверить следующие значения

• до 1000 рублей — 5% — 999 рублей
• 1000-5000 рублей — 10% — 1000 рублей и 5000 рублей
• свыше 5000 рублей — 15% — 5001 рублей

Часто возникают коллизии, если диапазоны указаны с пересечением. Это в корне не верно и требуется корректировка программного обеспечения, либо использования дополнительных параметров. В 1С при настройке скидок обычно уже контроллируется, чтобы диапазоны сумм не пересекались.

3. Таблица принятия решений (Decision Table Testing)

Можно говорить, что таблица принятия решений это частный случай эквивалентного разбиение. Только в качестве диапазонов у нас выступают точки бизнес-процесса. Например, разберем цепочки закупки и продажи товара в 1С для торговой организации и обозначим следующие точки бизнес-процесса:

1. Заказ покупателя
2. Заказ поставщику (ООО Торговый Дом) и Заказ поставщику (ООО ТоргСервис)
3. Приобретение товаров и услуг
4. Реализация товаров и услуг

Мы принимаем заказ от покупателя и создаем 2 одинаковых заказа поставщикам. В случае если у поставщика есть товар и он может нам его поставить, то продолжаем работать с первым поставищиком. Если первый поставщик нам не может поставить товар, то работаем со вторым поставищиком.

Подобную технику тест-дизайна удобно реализовывать, если бизнес-процессы хорошо описаны, например в нотации BPMN. В случае разработки сценариев тестирования на Vanessa Automation необходимо применять условные операторые перехода для реализации всех веток процесса. Причем для уменьшения дублирования кода рекомендуется мелкие подсценарии оформлять в виде процедур и выносить в отдельные feature-файлы.

4. Попарное тестирование (Pairwise Testing)

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

Следующая информация взята из статьи на Хабре Нестеровой Анастасии: Pairwise тестирование. Почему, зачем и как?

Эмпирически было замечено:

• Одним параметром вызывается 67% ошибок
• Одним параметром или взаимодействием двух параметров вызывается 93% ошибок
• Одним параметром или взаимодействием двух параметров или взамодействием трех параметров вызывается 98% ошибок

Таким образом, если одному параметру сопоставить пару из двух других, то получим покрытие ошибок в 98%. Для примера возьмем тест отображения веб-страницы на разных операционных системах, браузере и виде устройства:

1. Операционные системы: Windows, Ubuntu
2. Браузеры: Chrome, Firefox
3. Вид устройства: Desktop и Mobile

Если мы попытаемся покрыть все возможные тест-кейсы то получим 8 различных тест-кейсов.

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

Поэтому предлагается, часть параметров скомпоновать по парам. Таким образом получится следующая таблица тест-кейсов:

5. Тестирование перехода состояний (State Transition Testing)

Тестирование перехода состояний позволяет определить как система реагирует на изменения статусов от одного к другому. Например возьмем документ в 1С:ERP Заказ клиента. В самой простой настройке заказ клиента имеет два статуса: На согласовании и К Выполнению. Поэтому при разработке тест-кейсов необходимо обработать оба состояния.

Этот метод обеспечивает уверенность в том, что программа 1С работает корректно при всех последовательных операциях. Данная техника тест-дизайна тесно связана с общим покрытием тестами бизнес-процессов описанных нотации BPMN.

6. Предугадываение ошибок (Error Guessing)

Довольно спорная техника, можно сказать что слишком субъективная. Предугадывание ошибок основывается на опыти и интуиции тестировщика 1С.

Одним из примеров являются позитивные и негативные сценарии тестирования, например ввода ИНН контрагента в 1С:ERP. ИНН состоит не просто из числа, а в нем определенным образом спратана контрольная сумма. То есть, если ввести рандомное число в поле ИНН, программа выдаст ошибку. Подобное поведение должно присутствовать и у поля Банковский счет. Однако, в некоторых типовых конфигурациях 1С, такая валидация специально отсутствует.

Техника предугадывания ошибок может использоваться как дополнение, чтобы улучшить качество покрытия тестами 1С. В Vanessa Automation можно генерировать случайные значения для подстановки в поля ввода и проверять, сработали ли валидация на стороне 1С.

Заключение

Выбор правильной техники тест-дизайна зависит от контекства вашего проекта, предметной области и ресурсов. Хорошей практикой будет сочетание нескольких вариантов. Что касается 1С, то для построения тест системы применяют фреймворк Vanessa Automation. Но просто написать сценарии на Vanessa Automation — недосточно. Очень быстро вы поймете, что их нужно где-то версионировать. Для этих целей подоходит Git или Gitlab. Для лучшей управляемости и параметризации тестов применяют связку 1С:СППР и Vanessa Automation.