Порядок разбиения сценариев тестирования

#1

Допустим, в конфигурации имеем Документ1.
Необходимо доработать Документ2 и Документ3. Используется ввод на основании Документ1->Документ2->Документ3.

На первый взгляд проще написать один сценарий, который будет включать в себя:

  • создание Документ1
  • создание Документ2 на основании
  • создание Документ3 на основании

т.е. одним сценарием можно работу интерфейсов всех (2-х) доработанных документов + проверить корректность ввода на основании, проведения, проверок заполнения и т.п.
а если еще освоить “параметризированные сценарии”, то можно вообще все варианты проверить в одном сценарии.

есть ощущение, что это некрасиво,
если разбить на 2 сценария под каждый документ Документ2 и Документ3, то получиться,

  1. что необходимо выполнять сценарий для Документ2 в сценарии для Документ3,
  2. либо обеспечить наличие необходимых данных БД до выполнения сценария по Документу3, но тут проблема, если поменяем что-то при формировании Документ2, то эти данные нужно будет обновлять, а в первом варианте сценарий “подцепится”

И так почти в каждой задаче.
Как правильно?

#2

ИМХО - если у вас сценарное (BDD) тестирование, то делать единый сценарий.

Если модульное - то заготовить макет с документом 2 и делать отдельный тест на ввод документа 3 на основании. (макет естественно грузить в режиме “обменДанными.Загрузка”, чтобы не падал по пустякам)
Что у вас там меняется “при формировании” документа 2 в сценарии для ввода документа 3 не важно, если на него не влияет. А если влияет - то это изменение контракта для Док3 и тесты к нему нужно переписывать, это нормально.

#3

Всегда начинайте с формирования списка возможных сценариев.
Далее выставляйте их приоритеты в порядке важности/полезности/ценности/подмешайте что-нужно.
Далее самый верхний/первый начинайте формулировать в виде фичи.
Сначала верхнеуровневые шаги для понимания работы сценария - человеко-читаемый текст без лишних подробностей.
А вот затем уже добавляйте технические шаги, экспортные сценарии и т.п.

#4

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

у нас только ввод на основании или что-то еще есть?

#5

Я делал для тестирования интерфейса каждого документа отдельные интерфейсные сценарии.
А для проверки ввода на основании, нужные документы создавал программно, т.к они там нужны как “Дано”
И один сценарий верхнего уровня, где все в одном.

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

На выходе получаю несколько модульных тестов, несколько интеграционных (ввод на основании), и один системный.

#6

На самом деле пример, хоть и из жизни, но общий,
т.е. например, имеем модуль OneScript для работы с файлами 2-х типов .1CD и .cf, операция 1 берет файл .1CD и обеспечивает файл .cf, операция 2 идет дальше и из файла .cf “делает следующий результат”. Хотелось бы проверить обе операции, но операция 2 работает по сути с результатом операции 1;
Вероятно можно сказать, что вопрос про тестирование последовательных операций.

Как я понял ваши ответы (поправьте если не верно):
решать нужно по ситуации исходя из необходимости одновременно видеть работающий функционал и не работающий, т.е. если функционал “монолитный”, то можно сделать и 1 сквозной сценарий, но если функционал может использоваться частично, т.е. например операция 2 без операции 1 - отдельные тесты с отдельными исходными данными (т.е. исходные данные для операции 2 должны быть корректны и использование операции 1 для их формирования уже не надежно).
Для исходного примера на документах: если Документ3 может быть только введен на основании Документа2, то можно обойтись и сквозным сценарием, т.к. функционал не будет доступен, если ошибка будет при создании Документа2. Соответственно, интерфейсные и другие тесты отдельно.

#7

Не совсем так, но в целом хорошее понимание.

“монолитность” функционала не так важна, важно понимать нужные сценарии и их составные части.

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