Тестирование на основе сценариев что это

Автор: Екатерина Курач

Написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

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

Но, как известно, полностью протестировать программу невозможно по следующим причинам:

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

Т.е. написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

Характеристики хорошего теста:

• Существует обоснованная вероятность выявления тестом ошибки
• Набор тестов не должен быть избыточным
• Тест должен быть наилучшим в своей категории
• Он не должен быть слишком простым или слишком сложным

В настоящее время наблюдается несколько методологий разработки тест кейсов. Они отличаются и теоретическим подходом, и практической реализацией.

Наиболее часто употребляемая методология разработки тестовых случаев — методология, при которой источниками тестовых случаев выступают случаи использования.

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

Случай использования состоит из некоторого множества сценариев: нормальный случай, расширения и исключительные ситуации. Для разработки тест кейсов на основе одного случая использования разрабатываются несколько сценариев, соответственно: Сценарий использования представляет собой оптимистический сценарий, который выбирается чаще других. В раздел Альтернативные пути могут быть включены несколько сценариев, которые отличаются от сценария использования в различных аспектах, однако остаются полноценными путями исполнения. В раздел Исключительные пути попадают те сценарии, которые приводят к возникновению ошибок. Каждый сценарий предусматривает действия, предпринимаемые действующим субъектом, и требует от системы отклика, который соответствует основной части тестового случая. Тестовый случай состоит из некоторого набора предусловий, стимулирующего воздействия (входные данные) и ожидаемого отклика.

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

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

Комбинация рейтингов частоты использования и критичности, применяемая для того, чтоб упорядочить случаи использования, обеспечивает получение определенного критерия качества. Например, можно нарисовать эмблему в правом нижнем углу каждого окна. Это повторяется довольно часто, но если это не получится, система все еще способна выполнять наиболее важные функции для пользователя. Аналогично, соединение с сервером локальной базы данных происходит крайне редко, однако неудача этой операции сделает невозможным успешное выполнение множества других функций. Количество тестовых случаев, приходящихся на один случай использования, выбирается в зависимости от положения этого случая использования в рейтинговой таблице (чем чаще встречается данный случай использования и чем критичней его неверное выполнение для системы — там больше тест кейсов должно быть разработано). На этом этапе тестирования поддерживается проведение тестирования приложения в таком режиме, в каком оно будет использовано на практике.

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

Очень редко все эти действующие субъекты используют систему одним и тем же способом. Поле частоты случая использования представляет собой композицию значений частоты использования отдельных профилей действующих субъектов.

Этот подход весьма полезен для систем, которые ни разу не устанавливались. Он дает более точную оценку того, как действующий субъект будет использовать систему, по сравнению с простым угадыванием того, каким окажется совокупный результат отдельных случаев использования.

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

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

1. Идентификация всех значений, которые вводятся действующими субъектами, содержащимися в модели случая использования
2. Выделение классов эквивалентности значений каждого типа входных данных
3. Построение таблиц, в которые помещен список комбинаций значений из различных классов эквивалентности
4. Построение тестовых случаев, в которых сочетаются одна перестановка значений с необходимыми внешними ограничениями

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

В таблице 1 показаны классы эквивалентности этих трех переменных.

Имя переменной	Тип объекта	Классы эквивалентности
Имя	Строка	Имя, которое выходит за пределы максимальной длины строки Имя, которое в точности соответствует максимальной длине строки Полное имя с оставшимся пустым пространством Пустое имя
Служащий	Штатная единица	Специально созданная штатная единица Ранее существовавшая единица
Авторизация	Код безопасности	Санкционирован только локальный доступ Санкционирован доступ в масштабах всей системы

Спецификация входных значений для системы управления кадрами

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

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

Имя	Штатная единица	Авторизация
Полное имя с остающимся пустым пространством	Ранее существовавшая штатная единица	Санкционирован только локальный доступ
Полное имя с остающимся пустым пространством	Новая штатная единица	Санкционирован только локальный доступ
…	…	…

Перестановки входных данных системы управления персоналом

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

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

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

Второй подход заключается в разработке тестовых случаев большого цикла (grand tour test cases), в котором каждый тестовый случай генерирует данные, которые служат входом для следующего тестового случая. По условиям такого подхода каждый тест переносит тестовые данные через весь жизненный цикл. Полученное при этом состояние базы данных используется в качестве входного для следующего теста. Этот метод особенно эффективен при тестировании жизненного цикла после того, как тестирование нижнего уровня позволило выявить большую часть дефектов, вызывающих отказы. Если выстроить тестовые случаи в соответствующую последовательность, то после успешного выполнения тестового случая 1 устанавливается такое состояние программы, которое ожидается как входное для тестового случая 2. Очевидная проблема в условиях очерченного подхода заключается в том, что неудачное выполнение тестового случая 1 оставляет программу в состоянии, которого мы не ожидали, в результате чего мы не можем выполнять прогон тестового случая 2 или даже вернуть программу в рабочее состояние.

Итак, при разработке тест кейсов на основе случаев использования процедура в общем-то ясна. Однако возникает другой вопрос — что необходимо подвергнуть тестированию? Какие аспекты функционирования системы? Рекомендуется проводить следующие виды тестирования:

• Тестирование на соответствие функциональным требованиям
• Проверка качественных системных атрибутов. Добротная организация разработок программного обеспечения предусматривает методы подтверждения всех системных «требований», включая и претензии на придание программному продукту особых качеств. Существуют два вида претензий, с которыми может столкнуться программа при разработке продукта. Первый вид претензий представляет интерес только для организаций, занимающейся разработкой программных продуктов. Например, утверждение, что «программный код допускает многократное использование». Второй тип претензий представляет интерес для пользователей системы. Например, утверждение о том, что система является более полной, нежели другие системы подобного класса, предлагаемые на текущий момент на рынке программных продуктов. Вполне понятно, что не все эти претензии могут подвергаться проверке через тестирование. Однако на это следует обратить внимание.
• Тестирование механизма развертывания системы
• Тестирование после развертывания системы. Естественное расширение тестирования механизма развертывания системы заключается в добавлении в тестируемый программный продукт функциональных средств самопроверки. Считается, что система «изнашивается» во времени по причине изменений, имеющих место в ее взаимодействии с окружением, примерно так же, как со временем изнашивается механическая система из-за трений между ее компонентами. По мере того, как устанавливаются все более новые версии стандартных драйверов и библиотек, несоответствия возрастают вместе с ростом вероятности возникновения отказов. Каждая новая версия dll-библиотеки привносит возможность появления новых областей нестыковки стандартных интерфейсов или появления состояния гонок между этой библиотекой и приложением. Функциональные средства самотестирования должны обеспечивать выполнение тестов, которые исследуют работу интерфейсов между этими программными продуктами.
• Тестирование взаимодействий окружения
• Тестирование системы безопасности

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

Литература:

1. Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. — Киев: Издательство «Диа Софт», 2001.—544 с.
2. Макгрейгор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие. — Киев: ООО «ТИД «ДС»», 2002.—432 с.

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

• Вступление
• О конфигурации Тестер
• Базовые определения
• Концепция
• Быстрый старт
• Интерфейс
  • Дерево сценариев
  • Вкладка Поля
• Перед внедрением
• Установка
• Базы данных
• Создание и обновление начальной базы
• Эталонная база
• Данные для тестирования
• Структура сценария
• Практика
  • Постановка задачи
  • Разработка
  • Этап 1
  • Этап 2
    • Метод для создания поставщика
    • Метод для создания покупателя
    • Метод для создания товаров
    • Метод для создания складов
    • Метод для создания документа ПоступлениеТоваровУслуг
    • Метод для создания документа РеализацияТоваровУслуг
    • Создание теста ПродажаСДатойСогласования
  • Этап 3
  • Этап 4
• Заключение

Вступление

Независимо от того, какой философии придерживается компания, одно остается неизменным – процесс программирования приложений с пользовательским интерфейсом, включает в себя запуск программы, эмуляцию действий пользователя, зрительный анализ ситуации, возврат к доработке кода, и так далее, с последующим повторением итерации. Принципиально, в этой схеме можно выделить два отрезка времени: программирование и проверка. Время, которое тратится на программирование, превращается в код. Время, которое тратится на проверки, уходит безвозвратно. В силу специфики процесса разработки, когда мы снова и снова запускаем приложение, повторяя итерации, компенсация потерянного времени достигается за счет уменьшения второго временного отрезка, либо сдвига всех проверок на некую «финальную» итерацию или запуск BDD-теста. Отсутствие возможности повторить опыт проверок, отрицательно сказывается на качестве программного продукта.

Во многом, эти вопросы решаются внедрением специальных методик, например, TDD, BDD, организацией дополнительных процессов по тестированию. Однако, везде есть свои нюансы.

Например, TDD существенно пересматривает взгляд программиста на разработку, и в случае интерактивных приложений с глубокой завязкой бизнес-логики на базе данных, особенно при создании конфигураций с гибкой системой прав и функциональных опций, методику применять не просто.

BDD, за счет человеческого языка сценариев Gherkin, идеологически сшивает в одном месте специалистов прикладной и технической областей, а используемая конструкция описания сценариев Given-When-Then универсальна. Однако, BDD больше о процессе создания продукта, а не только о его тестировании. BDD основывается на ролевом взаимодействии сотрудников компании, что делает её требовательной (и в какой-то мере хрупкой) ко всем звеньям цепи разработки. Другой важной проблемой является не высокая эффективность языка Gherkin при разработке сложных (с точки зрения BDD) сценариев. К автоматическому документированию, как бонусу BDD, также, немало вопросов. Руководства пользователя к продуктам известных вендоров, не строятся по принципу Given – When – Then, а с техническим документированием, многие выбирают подход “Лучше устаревшая, но понятная, чем актуальная, но непонятная (или понятная только автору сценариев) документация.

Исторически, TDD, BDD и другие, пришли из мира, где системы 1С нет как класса, где идет очень четкая специализация, и разрыв между понимаем задачи техническим специалистом и бизнесом, как правило, велик. Например, в типовой 1С-франчайзи, очень часто задачи идут конвейером, могут приниматься по телефону, скайпу или электронной почте. Организация заседаний на каждую доработку в формате трех друзей (Three Amigos), выглядит несерьёзно, а значит почти вся методика BDD искажается или даже ломается.

В тоже время, на крупных проектах, эти переговоры необходимы. В идеале там будет аналитик, тестировщик и разработчик (BA+QA+Developer), но там не будет всего отдела программистов. А им, в конечном итоге, писать код, проводить тестирование, зачастую, намного более глубокое, с пограничными значениями, отклонениями, и другими особенностями реализации, возникновение которых рождается в коде и не может быть описано в приемочном тесте или постановке задачи. И это будет не TDD, а реальные сценарные тесты, которые программисты как правило не автоматизируют, а выполняют вручную в рамках процесса кодирования.

Другой пример из жизни программиста 1С: считается вполне типовым сценарий (пример описан не для российского законодательства): Расчет отпуска сотруднику, где нужно учесть предыдущие начисления за прошлые три месяца, включая количество праздников за период расчета, праздников, выпавших на выходные дни, если они предусмотрены графиком его работы, квартальные, годовые и фиксированной суммой премии, которые могут быть начислены не в периоде их расчетов, смена должности и/или графика работы, учет системы прямого табелирования или методом отклонений, а также, период самого отпуска должен быть очищен от праздников. В случае, если сотрудник часть отпуска проболел – следующее продление должно учитывать предыдущие начисления, кроме этого, нужно предусмотреть пересечение периодов начислений (неделя/две недели/месяц/вахта) с периодом отпуска и другие характеристики. В качестве сценария в данном случае, обычно выступает законодательный акт или статья из бухгалтерской периодики, что в большинстве случаев считается для программиста 1С включенной в область его ответственности задачей. Попытка организовать (а не только написать) сценарное тестирование на языке Gherkin для данного, вполне стандартного сценария, может стать настоящим испытанием.

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

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

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

О конфигурации Тестер

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

Возможности:

• Программирование и запуск сложных сценарных тестов в одной среде
• Глубокое тестирование интерфейса и бизнес логики
• Запись работы пользователя с переводом сценария в программный код
• Организация коллективной работы по созданию базы тестов
• Гибкий ролевой доступ, раздельный RLS-доступ пользователей к тестируемым конфигурациям
• Инкрементальная выгрузка/загрузка тестов во внешние файлы
• Формирование протоколов и сводных отчетов по выполненным сценариям
• Настройка рассылки результатов тестов по электронной почте
• Тестирование по расписанию, организация непрерывного процесса прогона тестов в рамках CI

Особенности:

• Быстро устанавливается, не требует специальных (кроме 1С) знаний и программного обеспечения
• Быстро интегрируется в процесс разработки
• Не требует фундаментального пересмотра философии программирования
• Сфокусирован на процесс создания реальных тестов
• Не требует подготовки отдельных баз и эталонных данных

Другое применение:

Тестер может быть использован как автоматизатор рутинных операций, как в процессе разработки, так и в режиме реальной эксплуатации продуктовых баз. Среди таких задач можно выделить:

• Выгрузка загрузка данных, пакетный запуск 1С для административных задач
• Запуск и манипуляции обработками, отчетами. Тестером можно написать сценарий, который будет формировать отчет, проверять какие-то данные или открывать обработку и нажимать там нужные кнопки и выбирать поля
• Формирование начальных или тестовых данных для ваших решений (вместо использования конвертации данных)
• Нагрузочное тестирование. Например, у вас есть доработка и вы хотите проверить работу этого функционала под нагрузкой. Для этого можно написать сценарий запуска Тестера нужное кол-во раз с передачей целевого тестируемого сценария в качестве параметра

Базовые определения

Процесс тестирования приложений при помощи Тестера основывается на взаимодействии Тестера с запущенной конфигурацией 1С в режиме 1С: Предприятие.

При этом считается, что Тестер выступает в роли Менеджера тестирования, а тестируемая конфигурация – в роли Клиент тестирования.

Тестер является системой сценарного тестирования. Это означает, что взаимодействие с тестируемым приложением происходит в режиме эмуляции действий пользователя.

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

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

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

Тестер не является системой TDD, и строго говоря, не является идеологически чистым BDD. Тестер старается не привязываться к религии в разработке, он решает те проблемы, с которыми сталкиваются абсолютно все разработчики программного обеспечения. Тестер старается решать эти задачи максимально эффективно.

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

Предполагаемые пользователи Тестера, это:

Пользователи	Задачи
Программисты	Использование системы в процессе разработки. Эволюция процесса ручного тестирования
Тестировщики с базовыми знаниями программирования на языке 1С	Написание сценариев, максимально приближенных к сценариям работы пользователей. Эти сценарии, обычно не такие глубокие, как у программистов, но более выраженные с точки зрения бизнес-процесса
Бизнес аналитики. Консультанты	Запуск тестов, анализ результатов. Через чтение тестов, понимание работы функционала системы

Концепция

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

Имея на входе информацию по задаче, мы мысленно разбиваем весь процесс кодирования на небольшие транзакции, рывки. Это является для нас неким краткосрочным планом работ (даже если на входе BDD-сценарий). Затем, мы начинаем методично работать по схеме “написание кода – запуск приложения – проверка ожидаемого поведения – возврат к доработке кода”. Количество таких транзакций и степень их завершенности — очень хрупкие сущности, потому что опираются на способность и возможность программиста быть в сосредоточении.

Даже при идеальных условиях выполнения работ по кодированию, опыт этих транзакций без специальных инструментов – не восстановим. Кроме этого, если в середине намеченного пути, возникает непредусмотренная ситуация, ошибка в связанном коде или недоработка используемого механизма, программисту приходится переключаться в другой контекст для разбора проблемы, нередко делая это в спешке, потому что намеченный план работ начинает ускользать из рабочей памяти нашего мозга. При изменении сопутствующего кода, мы стараемся удержать в голове триггер “нужно протестировать потом этот код”.

Можно использовать специальные метки в коде, инструменты среды разработки, делать скриншоты, аудиозаписи, но это лишь точки возврата к проблемам, ментальный контекст на те моменты времени уже не откатить. Можно применять TDD, но результирующее влияние изменений на поведение системы в целом, проверить будет очень сложно. Например, вы изменили запрос заполнения документа Начисление ЗП, который сильно зависим от условий приема сотрудников на работу, отпусков, больничных, изменений кадровых состояний, и при этом, затрагиваются расчеты налогов, в основе которых лежат эти начисления. Вовлеченность десятков таблиц баз данных, огромного количества начальных значений, может сделать TDD очень сложным, а падающие тесты в таких случаях не всегда понятны из-за отсутствия полного сценарного контекста.

Интегрирование в работу инструмента тестирования, потребует от программиста выработки навыка трансляции мысленно составленного плана работ в программный код сценария. Это дает ему возможность “разгружаться” сериализуясь в код теста. Накапливаемые сценарии, всегда можно воспроизвести, что позволяет сосредоточится на качестве выполняемых работ. Рост количества тестов дает свободу действий не только для рефакторинга, но и других существенных изменениях функциональности разрабатываемого приложения, что является одной из важных концепций инструмента.

Быстрый старт

Для быстрого развертывания инфраструктуры тестирования достаточно выполнить следующие шаги (предполагается, что Тестер скачан и прописан в списке информационных баз):

1. Конфигурация Тестер должна быть запущена в режиме 1С: Предприятие с ключом /TESTMANAGER.
   Этот параметр может быть прописан непосредственно в профиле информационной базы Тестера, например так:
   
2. Тестируемая конфигурация должна быть запущена в режиме 1С: Предприятие с ключом /TESTCLIENT.
   Этот параметр может быть прописан непосредственно в профиле тестируемой информационной базы, например так:
   
3. Версия 1С, используемая для тестирования должна быть одинаковой как для Тестера, так и для тестируемой конфигурации.
4. Запуск Тестера и тестируемой конфигурации желательно производить на одном компьютере. Для запуска программ на разных компьютерах, необходимо настроить порт и адрес тестируемого приложения в справочнике Приложения.

С технической точки зрения, для начала разработки тестов и тестирования больше ничего не требуется.

Первый сценарий

Рассмотрим пример создания теста к конфигурации БСП 2.2.
Напишем элементарный тест, который просто откроет форму списка справочника Партнеры.

1. Запускаем Тестер с ключом /TESTMANAGER.
2. Запускаем БСП с ключом /TESTCLIENT.
3. Переключается в Тестер, открываем меню быстрых функций и создаем новое приложение:
   
   
4. Через меню быстрых функций открываем сценарии и создадим новый сценарий:
   1. В поле ID напишем Test1
   2. В тексте сценария напишем:

   3. Подключить (); // Подключаем БСП к Тестеру
      Меню ( "Справочники / Демо: Партнеры" ); // Открываем в БСП форму списка

   4. Переключимся на вкладку Свойства, и в поле Приложение укажем БСП
   5. Нажмем на панели кнопку Основной
   6. Тест готов. Теперь нажмем кнопку Запустить (или F5 ) и запустим его.

В результате, в БСП должна открыться форма списка справочника Демо: Партнеры. Если бы во время открытия справочника, произошла какая-то ошибка, Тестер бы о ней сообщил.

Второй сценарий

Добавим в первый тест создание нового партнера, для этого внесем следующие изменения в сценарий:

// Подключаем БСП к Тестеру
Подключить ();

// Закроем все окна в БСП
ЗакрытьВсё ();

// Открываем в БСП форму списка
Меню ( "Справочники / Демо: Партнеры" );

// Говорим Тестеру, что мы будем сейчас работать с этим окном
Здесь ( "Демо: Партнеры" );

// Нажмем кнопку Создать
Нажать ( "Создать" );

// Говорим Тестеру, что мы будем сейчас работать с этим окном
Здесь ( "Демо: Партнер (создание)" );

// Установим наименование партнера
Установить ( "Наименование", "Мой тестовый партнер" );

// Кликнем на флажок Поставщик
Нажать ( "Поставщик" );

// Нажмем кнопку Записать и закрыть
Нажать ( "Записать и закрыть" );

После выполнения теста, в базе БСП должен быть новый партнер.
После выполнения теста, в окне сообщений Тестера, будет такое предупреждающее сообщение:

14: Поле "Создать" найдено в нескольких местах: ФормаСоздать (Тестируемая кнопка формы / Кнопка командной панели), СписокКонтекстноеМенюСоздать (Тестируемая кнопка формы / Кнопка командной панели) {Тест1[14]}

Сообщение говорит о том, что в 14 строке кода, метод Нажать нашел несколько мест, где можно нажать Создать.
Для того, чтобы задавать однозначно объекты, с которыми требуется взаимодействие, можно использовать идентификаторы, или полный путь.
Например, в 14 строке можно написать так:

// Вариант 1
Нажать ( "!ФормаСоздать" );

// Вариант 2
Нажать ( "!КоманднаяПанель / Создать" );

Для получения идентификаторов и внутреннего содержимого форм тестируемого приложения, см раздел Вкладка Поля.
Следующие разделы посвящены полному обзору функций Тестера.

Интерфейс

Интерфейс Тестера организован с позиций удобного написания и запуска тестов. При первом запуске, на домашнюю страницу выводится справка по системе (выкачивается из интернета) и открывается основной сценарий, если он задан. В левой части системы находится текстовый редактор для ввода кода сценария, справа – дерево сценариев.
К сожалению, на момент подготовки этой документации, система еще не поддерживает синтаксическое цветовое оформление программных модулей. Лишь поначалу это может показаться серьёзной проблемой, но спустя непродолжительное время, вы перестанете обращать на это внимание, потому что изначально, код сценария существенно проще, чем стандартный программный код конфигураций.
Некоторые специалисты ненадолго предпочли использование Visual Studio Code с расширением Language 1C (BSL) или обычный конфигуратор 1С для набора текста сценария, с последующим копированием или загрузкой в Тестер. Однако, практика показала, что ценность цветового оформления существенно ниже возможности взаимодействия программиста с полями и структурой тестируемого приложения, деревом сценариев, помощником и другими функциями, доступными только из Тестера.

Дерево сценариев

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

Типы сценариев, Маркер 1

Левее маркера, в зеленом цвете и специальной пиктограмме, находятся такие узлы как Корзина, Общее, Таблица и другие.
Такое оформление означает, что это библиотеки тестов. Признак, что узел является библиотекой, задается при создании/редактировании теста:

На картинке видно, что кроме библиотеки, тест может быть папкой, сценарием или методом.
Строгой технической привязки и контроля типа сценария в Тестере нет. Главное предназначение типов – это организация визуальной логики взаимосвязи сценариев.
В случае, если это библиотека, подразумевается, что внутри данной папки будут храниться только библиотечные сценарии-методы. Метод – это сценарий, который не должен привязываться к конкретной тестируемой логике приложения. Методы обычно могут принимать параметры, они работают как процедуры/функции. Методы не должны запускаться как отдельные, самостоятельные сценарии (запуск сценариев см. здесь).
Пример метода: ПроверитьОшибкуЗаписи.
Пример использования в коде сценария:

Вызвать ( "Общее.ПроверитьОшибкуЗаписи", "Не заполнен контрагент" );

Группы сценариев, Маркер 2

На этом маркере изображена папка Документы. Папка – это логическая группировка сценариев. Группировка может быть произвольной. Вы можете создавать папки с тестами по принципу тестируемых подсистем, ролей пользователей или технических заданий. Если вы не чувствуете, какая структура тестов вам нужна, тогда универсальным подходом является проецирование структуры тестов на объекты метаданных вашей конфигурации. Смело можно создавать группы Справочники, Документы и так далее. Внутри этих групп, создавать группы с названиями объектов метаданных, а следующим уровнем, располагать конкретные сценарии. В будущем, если потребуется, вы сможете сделать перегруппировку.

Обычный сценарий, Маркер 3

Маркером отмечен стандартный сценарий. В данном случае, это сценарий под названием Начало. Обратите внимание, что пиктограмма левее, имеет небольшой желтый шарик справа, а у сценария на маркере 5 такого шарика нет. Наличие желтого шара означает, что внутри данного сценария, кроме скрипта сценария, находится еще и шаблон. Шаблоны используются для проверки бизнес-логики тестируемого приложения. Подробнее о проверке бизнес-логики см. здесь.

Сценарий-метод, Маркер 4

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

Основной сценарий, Маркер 5

Этим маркером отмечен обычный сценарий. Подчеркивание снизу указывает на то, что данный сценарий в настоящий момент текущий (основной). Основной сценарий, это тот сценарий, над которым сейчас работает программист. Любой сценарий может быть установлен основным (правый клик в дереве / Основной). У каждого пользователя системы Тестер может быть свой основной сценарий. Основной сценарий отличается от остальных тем, что его легко найти в дереве (правый клик в дереве / Найти основной сценарий) и легко запустить на выполнение (см. Запуск тестов). Также, основной сценарий автоматически открывается при запуске новой сессии Тестера.

Приложения, Маркер 6

Под маркером 6 находится колонка с названием приложения, к которому принадлежит соответствующий сценарий.
Приложение устанавливается в форме редактирования сценария, для любого типа сценария:

Поле Приложение можно не устанавливать, оставить пустым. В этом случае, предполагается что сценарий универсальный и может работать для всех приложений в системе.
Обратите внимание, что для библиотечных тестов и групп первого уровня (см. картинку с деревом тестов) приложение не задано, а для группы ЗаказПоставщику, ТестСоздания и т.д. приложение задано. Логика следующая: библиотечные тесты могут работать для любой конфигурации, поэтому при их создании, приложение не задали. Группа тестов Документы тоже будет в любой конфигурации, приложение также не задано. Для группы ЗаказПоставщику, ТестСоздания и т.д. приложение задано, потому что они имеет четкую привязку к тестируемому приложению.
Задавать приложение для сценариев нужно:

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

Хранилище, Маркер 7

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

Запуск тестов

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

При запуске теста по кнопке F5 (или командe Запустить) Тестер всегда запускает сценарий, установленный как основной. Таким образом, вне зависимости от кого, какой сценарий вы в данный момент редактируете, запускаться будет только основной.

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

Вкладка Поля

В процессе написания сценария, может возникать необходимость в анализе внутренней структуры окон тестируемого приложения.
Такой анализ нужен для выделения идентификаторов полей и точного к ним обращения из кода теста. Также, такой анализ может единственным способом разобраться в составе полей тестируемой формы в случаях, когда поля формируются динамически.
Для такой задачи на форме сценария присутствует вкладка Поля (для новых сценариев, вкладка скрыта, сценарий должен существовать):

По порядку следования маркеров:

1. Позволяет получить структуру всех окон тестируемого приложения, которые сейчас открыты на экране.
2. Позволяет получить только текущее окно тестируемого приложения.
3. Позволяет быстро найти в дереве элементов текущий активный элемент тестируемого приложения. Очень удобная функция при написании тестов. Например, можно открыть нужную форму и встать на нужный элемент, затем, в Тестере, получить эту форму (п.2) и нажать Синхронизировать. После этого, Тестер попытается найти и активировать строку в дереве с данным элементом. В случае неудачи, генерируется ошибка.
4. При навигации по дереву, Тестер пытается активировать выделенные элементы в тестируемом приложении. Будьте внимательны, фокус может “прыгать” с дерева на тестируемое приложение.
5. Для выделенного поля можно выполнить метод или получить свойство. Набор методов и свойств зависит от типа выделенного элемента и применяется согласно объектной модели тестируемого приложения платформы 1С. Например, на картинке поле ОтборСостояние имеет тип ТестируемоеПолеФормы. В синтаксис помощнике 1С, можно посмотреть, какие методы и свойства доступны объектам этого типа. Одно из них, свойство ТекстЗаголовка, результат получения которого выведен на картинке выше.

Перед внедрением

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

1. Вы создаете макет, прототип приложения для демонстрации заказчику
2. Вы вносите точечные исправления в старый код, в те механизмы, сценариев к которым нет и не будет, и вся эта работа без перспектив эволюции модулей
3. Вы прощупываете будущую реализацию, когда еще нет четкого понимания, что это должно быть, документ или справочник, отчет или динамический список. В этом случае, программист нередко переключается в режим “потока” и быстро накидывает объекты метаданных для того, чтобы доказать или опровергнуть самому себе достижимость результата выбранным путем. В таких ситуациях, практически невозможно выработать сценарий, но это и не нужно. Строго говоря, пока не сформируется полное представление о способе выполнения задачи, сценарное тестирование применять не стоит

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

Установка

Если вы занимаетесь обслуживанием клиентов частным образом, Тестер имеет смысл установить локально на ваш компьютер или ноутбук, файловый вариант. Если вы работаете в команде, вне зависимости от того, работают все программисты над одним проектом или у каждого свой, Тестер желательно установить в локальной сети или облаке. Если ваш коллектив более 3 программистов, я бы рекомендовал установить клиент-серверный вариант платформы.
Даже если ваша команда сильно распределена, с пингом до ~125мс всё еще можно комфортно работать через интернет, разработка Тестера велась с учетом удаленности программистов. Если по каким-то причинам, облачное решение организовать не получается, можно установить программу локально на каждый компьютер специалиста, файловый вариант. Для организации общего хранилища тестов, можно использовать Git. У Тестера есть возможность инкрементальной выгрузки/загрузки тестов в файловую систему.

Кроме этого, для организации ночного тестирования, потребуется установить на выделенном для этого сервере или виртуальной машине тонкий клиент 1С: Предприятие, с возможностью его подключения к облаку, где ведется разработка тестов. В случае использования Git для хранения тестов, нужно будет обеспечить предварительную закачку тестов на сервер тестирования, с использованием утилит от Git. Подробнее, ночное тестирование описано разделе Запуск тестов по расписанию.

Тестер позволяет в одной базе вести работу с тестами для неограниченного числа приложений (конфигураций). Не стоит создавать отдельную базу с Тестером под каждый проект/конфигурацию/клиента. В Тестере возможна настройка ограничения доступа пользователей к приложениям.

Базы данных

Тестирование при помощи Тестера предполагает наличие двух баз данных: рабочей и начальной.

Рабочая база — это база данных в которой работает программист, и в которой выполняются все тесты. Соответственно, у каждого программиста своя рабочая база.

Начальная база — это база, заполненная начальными данными. Начальная база нужна для того, чтобы периодически создавать/перегружать рабочие базы. Наполненность начальной базы зависит от типа выполняемых работ. Начальная база общая для всех программистов.

Создание и обновление начальной базы

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

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

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

Использовать такой тест удобно в следующих случаях:

• Каждый программист/аналитик/тестировщик может четко проверить консистентность своей рабочей базы перед тем как вообще что-то тестировать (напомню, рабочая база создается на основании начальной)
• Данный тест можно запускать первым в списке тестов для ночного тестирования, по результатам которого, определить целесообразность дальнейшего тестирования
• Тест хорошо работает как напоминание разработчику, какие данные можно брать не думая об их существовании, а какие нужно создавать дополнительно. В процессе работы, рабочая база превращается в хлам, и помнить, какие данные там начальные, а какие нет, сложно. Разворачивать каждый раз начальную базу последней версии – может быть не всегда удобно или возможно, при этом, быстрое определение происхождения данных при написании сценария очень важный момент. Например, в базе есть группа материалов “Детали насосно-компрессорного оборудования”, и если есть тест проверки начальных данных, в нем можно произвести поиск по коду и вычислить, происхождение этой группы, буквально в несколько кликов.

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

Начальную базу нужно подключить к хранилищу, куда сливаются финальные обновления конфигурации. Это необходимо для оперативного обновления начальной базы новым функционалом, обновления и/или заполнения базы новыми начальными данными.

Если над решением трудится коллектив, начальную базу нужно расположить в общедоступном месте, чтобы каждый специалист мог в любой момент «обнулить» свою рабочую базу, загрузив в неё начальную.

Если новый функционал требует обновления/добавления начальных данных, такую задачу можно решить двумя способами:

1. Ответственный разработчик, открывает обновленную начальную базу, дополняет вручную нужными данными, дорабатывает тест проверки начальных данных, запускает этот тест, убеждается в согласованности данных, и выгружает полученную базу в общедоступное место
2. Всё тоже самое что в п.1 с той разницей, что вместо ручного обновления, ответственный разработчик, пишет сценарный тест.

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

Начальные данные желательно использовать в режиме “только чтение» по отношению к тестируемому функционалу. Например, если у вас в начальных данных определена организация по умолчанию, и у вас есть тест, который проверяет механизм ввода новой/изменения/удаления организации, то лучше в этом тесте не использовать в качестве тестовой организации, существующую организацию в начальной базе. Даже если вашим тестом предусмотрен откат изменений к начальному состоянию, нет гарантии, на каком этапе упадет ваш тест. Когда это произойдет, он оставит после себя испорченные начальные данные, что может привести к цепной реакции падения тестов, выполняемых ночью, по расписанию.

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

Например, если ваш тест проверяет работу механизма контроля остатков в зависимости от системной настройки приложения, вашему тесту придётся изменять эту настройку. Если ваш тест упадет, настройка не будет возвращена в первоначальное положение и следующий запуск этого теста уже вряд ли отработает правильно, даже если с функциональной точки зрения всё в порядке. Таким образом, вначале желательно тестом сходить в настройки, установить требуемое значение и затем продолжить основной сценарий. К слову, подобные проверки не всегда требуются в оперативной работе, поэтому их запуск имеет смысл делать по условию, например, по имени пользователя ночного тестировщика, или флагу глобальных настроек (см. API Тестера).

Эталонная база

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

1. Требуется особый уход за эталонными данными, их корректировка в соответствии с изменениями функционала решения
2. Эталонные данные инертны: новый функционал требует новых эталонных данных, которые могут пересекаться с уже существующими эталонными данными. Вытекающая отсюда осторожность при манипуляции с эталонными данными ограничивает или замедляет развитие спектра тестируемого функционала
3. Оперативный прогон тестов практически невозможен, выгружать/обновлять/загружать эталонные базы долго. Под оперативностью понимается тестирование при каждом запуске программистом приложения на выполнение, а не увеличение числа релизов и закачки схемы на CI-сервере с прогоном тестов в течение дня
4. Количество эталонных баз стремится расти, это осложняет их обслуживание и весь процесс тестирования

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

Данные для тестирования

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

Тестовые данные состоят из двух слоёв:

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

Наибольший интерес представляет второй слой. Существует много подходов создания тестовых данных, но в их совокупности можно выделить две стратегии:

1. Выгрузка заготовленных данных из предварительно подготовленных баз или шаблонов, и последующая их загрузка перед началом или во время тестирования. Вариантов выгрузки/загрузки в данном подходе много. Это может быть конвертация данных, универсальный обмен данными, макеты с данными, выгрузки в dt-файлы или обычная сериализация прикладных объектов в JSON или XML.
   Рассмотрим плюсы и минусы такого подхода:

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

2. Формирование тестовых данных самим сценарием. При этом подходе, все тестовые данные должны создаваться, а не храниться для загрузки. Сам процесс создания не должен отличаться от процесса разработки целевых сценарных тестов. Другими словами, сегодня вы пишите тест проверки создания нового товара, а завтра этот тест уже может быть использован как метод для создания тестовых данных, для тестирования создания документа Реализация товаров.
   Плюсы и минусы такого подхода:

   Плюсы	Минусы
   Гибкость создания требуемого окружения тестовых данных под различные вариации тестов. Возможность разработки сложных взаимосвязанных тестов.	Сложно без опыта выстроить структуру библиотечных тестов для создания тестовых данных
   Высокое качество тестов за счет дополнительного тестирование всего стека используемых объектов при подготовке данных. Это очень важный нюанс, потому что создание тестовых данных таким образом, выполняется для разных видов целевых сценариев, что автоматически покрывает тестами разнообразие условий создания объектов. Например, у нас может быть тест-метод создания поставщика. Но поставщик может создаваться из разных контекстов: из формы списка контрагентов или из поля ввода на форме документа. И если тестовые данные загружать “извне”, можно не отловить ошибку создания контрагента из документа. Тест проверки документа пройдет успешно, хотя фактически, пользователь документ ввести не сможет (потому что не сможет создать для документа поставщика).	Требуется первоначальная инвестиция времени в разработку тестов-методов
   Консистентность полученного тестового окружения, заполненность реквизитов, отработка возможных событий и программных оповещений об изменении данных, другими словами — полная штатная эмуляция работы приложения.
   Слабая связанность с изменчивостью структуры метаданных. Если изменяется структура данных объекта, достаточно изменить (если необходимо) один тест-метод, при этом все остальные тестовые данные менять не придётся.
   Простота хранения. Все тест-методы хранятся в одной среде, и не являются внешними по отношению к системе тестирования.
   Использование одних и тех же тестовых данных даже в случае, когда их версии метаданных отличаются. В этом случае, в тест-методах можно организовывать условия по обработке/заполнению полей в зависимости от версии используемой программистом конфигурации (см. функцию МояВерсия ())

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

Структура сценария

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

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

Чтобы быстро прогонять тесты, нужно чтобы они были следующей структуры:

1. Определение окружения
2. Создание окружения
3. Целевая часть

Определение окружения – это функция в модуле вашего сценария, которая задает параметры теста в виде структуры. Примеры параметров теста: список приходуемых товаров, с ценами и количеством, наименование поставщика, валюта договора и т.д.

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

Целевая часть – это непосредственно код, который будет проверять то, что вы запланировали сделать, и ничего более.

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

Яснее на примере. Давайте представим, что вы занимаетесь доработкой документа Списание ТМЗ, который нужно дополнить особыми движениями по регистрам. Для тестирования (неважно как, вручную или нет) вам понадобится материал на складе, себестоимость которого вы знаете, установленные параметры учетной политики, на которые вы полагаетесь, и другие настройки системы, например, вариант контроля остатков. Таким образом, вам нужно будет вручную, как минимум один раз проверить, что настройки системы в порядке. Затем, нужно будет создать несколько материалов, возможно отдельный склад и как минимум одно поступление ТМЗ, и вы не забудете дату поступления сделать днем ранее. Таким образом – вы определяете и создаете окружение, чтобы затем выполнить целевую часть – провести списание и проверить, что особые движения появились и они правильные. Другими словами – выполняются все три описанных выше структурных действия для разработки автоматизированного сценария.

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

Пример. Добавим в описанную задачу необходимость проверки сообщения об ошибке при списании количества материала, большего, чем есть на складе. Я сильно не ошибусь, если предскажу работу смекалки программиста: он просто откроет уже проведенное списание (предварительно добавив его в избранное для максимальной “скорости”), отменит его проведение, в колонку с количеством введет 999999, запишет документ, а потом проведет его и проанализирует сообщение об ошибке. Если сообщения не будет, программист вернется в код, сделает необходимые доработки и будет повторять итерацию до тех пор, пока сообщение об ошибке не появится.

И тут начинаются проблемы. Во-первых, проверить нормальное поведение списания уже так просто не получится. Нужно будет привести данные в порядок, убрать 999999 и вернуть то количество, которое было на момент, когда мы проверяли правильность доработанных движений. И нам уже вряд удастся быстро вспомнить, каким именно было то первоначальное количество. Во-вторых, даже если программист предварительно скопирует документ, перед тем как менять данные – максимум он потом сможет проверить отсутствие ошибок проведения, но расчетные показатели, результат проведения, он проверить уже не сможет.

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

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

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

Практика

Перейдем к практической части: поработаем с Тестером в режиме создания нового функционала для конфигурации УТ11 на базе постановки задачи от бизнес-аналитика.

Постановка задачи

Компания торгует сигарами. Необходимо доработать документ Реализация товаров и услуг (далее Реализация) для возможности указания даты согласования следующих продаж по выбранным позициям.
Предполагается следующий сценарий:
— Менеджер вводит документ реализации, для выбранных позиций, на своё усмотрение он устанавливает дату, когда ему нужно было бы перезвонить клиенту и уточнить, насколько хорошо продаются сигары. Например, из всего перечня, его интересуют только сигары со вкусом ментола.
— У менеджера есть список, который он открывает каждый день и видит, когда, по каким клиентам и каким позициям ему нужно провести переговоры с клиентом для организации следующих поставок интересующих его позиций.
— Менеджер выбирает нужную позицию из списка, звонит клиенту, и вводит в систему результат переговоров

Документ Реализация

Необходимо в документ Реализация, в табличную часть, добавить поле для ввода даты согласования (без времени).
Поле не обязательно для заполнения. Если поле задано – тогда данная позиция считается отмеченной для согласования. По таким позициям необходимо предусмотреть обособленный учет на базе регистра сведений Согласование. Записи в данный регистр производить при проведении документа. При повторном проведении документа, существующие записи регистра сведений не обновлять, только добавлять новые.

Регистр сведений Согласование

Это новый, независимый регистр сведений, с возможностью редактирования.
Регистр должен хранить такие данные:

1. Документ Реализация, Клиент, Менеджер, Товар, Количество, Сумма – автоматически должны заполняться при проведении реализации и не должны быть доступны для редактирования
2. Флаг Отработано – будет устанавливаться пользователем
3. Флаг Комментарий – будет вводиться пользователем и фиксировать результат переговоров. Поле должно быть доступно для редактирования только если флаг Отработано = истина.

Для регистра необходимо разработать форму списка и форму элемента. В форме списка должны быть предусмотрены отборы по менеджеру, клиенту и товару.
Запретить пользователю вводить новые записи в данный регистр интерактивно. Примечание: запрет на ввод нового сделать программно с выводом соответствующего сообщения. Не использовать вместо этого настройку команд и ролей пользователя.
Объект расположить в подсистеме Продажи / Оптовые продажи.

Тесты

Необходимо разработать следующий тест:

1. Ввод одной реализации с двумя позициями, одна из которых будет отмечена для согласования
2. Открытие списка на согласование, отбор по клиенту, открытие формы регистра на редактирование, установка галочки, сохранение и закрытие
3. Убедиться, что позиция ушла из списка

Примечание: данный тест требуется автором технического задания. Исполнитель (программист) волен разработать столько дополнительных тестов, сколько ему потребуется для обеспечения надлежащего качества выполнения работ.

Разработка

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

Можно выделить как минимум четыре этапа:

Этап 1: добавить реквизит Дата согласования в табличную часть, в процедуре ОбработкаПроверкиЗаполнения реализовать проверку, чтобы дата согласования была больше даты документа

Этап 2: доработать процедуру ОбработкаПроведения, добавить туда логику формирования записей по регистру сведений

Этап 3: реализовать форму списка с фильтрами, как требует бизнес-аналитик

Этап 4: реализовать форму редактирования записи регистра для ввода данных по согласованным позициям.

Этап 1

В таблице ниже состыкуем работу по кодированию и тестированию:

Программирование	Тестирование
В Конфигураторе: Добавляем реквизит ДатаСогласования в табличную часть Товары документа Реализация В процедуре ОбработкаПроверкиЗаполнения реализуем проверку даты	В Тестере : Создадим тест ПроверкаДатыСогласования, где: Введем новую реализацию, добавим строку, впишем в строку некорректную дату Попытаемся провести, и в списке сообщений найдем требуемое сообщение об ошибке Затем изменим дату на правильную, проведем и убедимся, что сообщения об ошибке уже нет

Так как это будет наш первый тест для конфигурации УТ11, нам нужно произвести разовую настройку приложения в Тестере.
Необходимо создать приложение УТ11, см. Меню функций / Приложения. Для создаваемого приложения нужно задать актуальную на момент написания теста версию, например так:

Затем, это приложение нужно установить приложением по умолчанию, для этого нужно переключиться в дерево сценариев, открыть Опции, выбрать в поле Приложение УТ11 и нажать кнопку справа:

Следующий шаг – это создание папки РеализацияТоваровУслуг внутри папки Документы, и следом, создание нашего теста ПроверкаДатыСогласования.
В итоге, должно получится так:

Откроем выделенный на картинке сценарий, переключимся в текстовый редактор и введем этот текст:

// Сценарий:
// - Вводим новый документ Реализация
// - Устанавливаем неправильную дату согласования, проверяем наличие ошибки
// - Устанавливаем правильную дату, проверяем отсутствие ошибки

Подключить ();
ЗакрытьВсё ();

// Вводим новый документ
Коммандос ( "e1cib/data/Document.РеализацияТоваровУслуг" );
Здесь ( "Реализация *" );

// Определяем даты
дата = Дата ( Взять ( "!Дата" ) );
плохая = Формат ( дата - 86400, "DLF=D" );
хорошая = Формат ( дата + 86400, "DLF=D" );

// Вводим плохую дату
Нажать ( "!ТоварыДобавить" );
Установить ( "!ТоварыДатаСогласования", плохая );

// Проводим документ
Нажать ( "!ФормаПровести" );
если ( НайтиСообщения ( "Дата согласования*" ).Количество () = 0 ) тогда
	Стоп ( "Должна быть ошибка неверной установки даты согласования" );
конецесли;

// Вводим хорошую дату
товары = Получить ( "!Товары" );
Установить ( "!ТоварыДатаСогласования [1]", хорошая, товары );

// Проводим документ
Нажать ( "!ФормаПровести" );
если ( НайтиСообщения ( "Дата согласования*" ).Количество () > 0 ) тогда
	Стоп ( "Не должно быть ошибок неверной установки даты согласования" );
конецесли;

// Закрываем документ не сохраняя
Закрыть ();
Нажать ( "Нет", "1*" );

Комментарии по коду:

1. В этом тесте у нас нет эталонных данных, мы их формируем кодом сценария. Например, правильную и неправильную дату мы вычисляем согласно дате документа, которая нигде в свою очередь не хранится, а присваивается системой автоматически при вводе нового документа
2. Может показаться, что для простого тестирования корректности даты, сценарий получился большой. В данном конкретном случае, возможно и не стоило создавать специальный тест для такой задачи, ведь мы всё равно следующими шагами будем проверять формирование движений по регистру, и если что-то пойдет не так, оно пойдет не так и в следующих тестах. Однако, с точки зрения подачи информации, и постепенного раскрытия темы, я посчитал нужным наличие этого сценария. Кроме этого, всё-таки этот сценарий теперь у нас навсегда, мы можем запускать еще ночью, и мы можем быть спокойны, что делая какие-то глобальные замены мы не повредим (например) текст сообщения об ошибке
3. В этом тесте нет всей трехступенчатой структуры, которую я описывал ранее (см. здесь), но здесь это и не нужно в силу простоты сценария и как следствие – скорости его прогона

Настало время запуска сценария. Для этого убедитесь, что в конфигураторе настроен запуск приложения в режиме клиента тестирования:

(эта настройка сохраняется и её не придётся устанавливать каждый раз)
Запускаем приложение, затем переключаемся в Тестер, устанавливаем наш сценарий основным и нажимаем кнопку Запустить:

Если вы на момент запуска теста еще не реализовали процедуру проверки даты согласования, наш тест упадет.
Реализуем теперь в модуле реализации, в обработчике ОбработкаПроверкиЗаполнения, такую проверку:

пустая = Дата ( 1, 1, 1 );
для каждого строка из Товары цикл
	согласование = строка.ДатаСогласования;
	если ( согласование = пустая ) тогда
		продолжить;
	иначеесли ( согласование < Дата ) тогда
		Сообщить ( "Дата согласования установлена неверно" );
		Отказ = истина;
	конецесли;
конеццикла;

Запускаем приложения на выполнение, переключаемся в Тестер и жмем там F5. В результате чего, тест должен завершиться без ошибок.

Этап 2

Переходим ко второму запланированному рывку. В таблице ниже состыкуем работу по кодированию и тестированию:

Программирование

Тестирование

В Конфигураторе: Добавляем регистр сведений Согласование Дорабатываем обработку проведения для формирования записей в регистр

В Тестере: Создадим тест ПродажаСДатойСогласования, где: Определим окружение: Наименование Поставщика Наименование Покупателя Товар1 с ценой и количеством Товар2 с ценой, количеством и датой согласования Создадим окружение Создадим поставщика, покупателя и товары Сделаем поступление Создадим и проведем реализацию Целевая часть Откроем список реализаций и найдем там созданную реализацию Откроем реализацию и проведем Откроем регистр согласований и проверим наличие нашей записи

Этот тест сложнее, потому что перед проверкой целевой части, нам потребуется создать окружение. Напомню, что окружение будет создано только один раз, при первом запуске сценария, а затем, будет прогоняться только его целевая часть. Этот трюк будет понятен из кода сценария, который будет разработан в конце этого этапа.

Для создания окружения, нам будут нужны следующие объекты:

1. Поставщик
2. Товар
3. Склад
4. Покупатель
5. Поступление

В реальных проектах, создание окружения простая операция, но мы делаем всё с ноля, у нас еще нет библиотечных тестов, поэтому перед написанием логики окружения, нам нужны тест-методы для создания объектов (о тест-методах см. здесь).

Метод для создания поставщика

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

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

// Вначале вызовем тест-метод для получения параметров
параметры = Вызвать ( "Справочники.Поставщики.Создать.Параметры" );

// Заполняем параметры
параметры.Наименование = "ТОО Ромашка";

// Запускаем главный метод передавая ему параметры
Вызвать ( "Справочники.Поставщики.Создать", параметры );

Справку по всем функциям Тестера см. в разделе API Тестера.
Для создания сценариев-методов, в форме элемента сценария, на вкладке Свойства, нужно назначить соответствующий тип:

Подробнее о дереве и свойствах сценариев см. здесь.
Перейдем в редактор кода сценария Параметры, введем следующий текст:

// Параметры создания нового элемента
//
// Возврат:
// Структура параметров

СтандартнаяОбработка = ложь;

п = новый Структура ();
п.Вставить ( "Наименование" );
п.Вставить ( "Доступ", "Поставщики" );

возврат п;

Затем, откроем редактор сценария Справочники.Поставщики.Создать и введем:

// Создает нового поставщика по переданным параметрам
//
// Параметры:
// Структура параметров, полученная методом "Справочники.Поставщики.Создать.Параметры"
//
// Возврат:
// Код созданного поставщика

Коммандос ( "e1cib/data/Справочник.Партнеры" );

форма = Здесь ( "Партнер (соз*" );

// *********************************************
// Заполнение полей
// *********************************************

Установить ( "!НаименованиеПолноеКомпания", _.Наименование );
Нажать ( "Поставщик" );
Установить ( "!ГруппаДоступа", _.Доступ );

// *********************************************
// Запись, получение кода
// *********************************************

Нажать ( "!ФормаЗаписать" );
код = Взять ( "!Код" );

// *********************************************
// Создание контрагента
// *********************************************

Нажать ( "Контрагенты", ПолучитьСсылки () );
список = Здесь ( "Контрагенты*" );

Нажать ( "!ФормаСоздать" );
Здесь ( "Контрагент (соз*" );
Установить ( "!Наименование", _.Наименование );
Нажать ( "!ФормаЗаписатьИЗакрыть" );
Закрыть ( список );

возврат код;

Параметризированный метод создания нового поставщика готов. Перейдем к созданию остальных методов.

Метод для создания покупателя

Проделаем в дереве сценариев практически те же действия для разработки сценария создания покупателя:

Затем введем код сценариев, Справочники.Покупатели.Создать.Параметры:

// Параметры создания нового элемента
//
// Возврат:
// Структура параметров

СтандартнаяОбработка = ложь;

п = новый Структура ();
п.Вставить ( "Наименование" );
п.Вставить ( "Доступ", "Прочие" );
п.Вставить ( "Сделка", "Произвольная продажа" );

возврат п;

и Справочники.Покупатели.Создать:

// Создает нового покупателя по переданным параметрам
//
// Параметры:
// Структура параметров, полученная методом "Справочники.Покупатели.Создать.Параметры"
//
// Возврат:
// Код созданного поставщика

Коммандос ( "e1cib/data/Справочник.Партнеры" );

форма = Здесь ( "Партнер (соз*" );

// *********************************************
// Заполнение полей
// *********************************************

Установить ( "!НаименованиеПолноеКомпания", _.Наименование );
Нажать ( "!Клиент" );
Установить ( "!ГруппаДоступа", _.Доступ );

// *********************************************
// Запись, получение кода
// *********************************************

Нажать ( "!ФормаЗаписать" );
код = Взять ( "!Код" );

// *********************************************
// Создание контрагента
// *********************************************

Нажать ( "Контрагенты", ПолучитьСсылки () );
список = Здесь ( "Контрагенты*" );

Нажать ( "!ФормаСоздать" );
Здесь ( "Контрагент (соз*" );
Установить ( "!Наименование", _.Наименование );
Нажать ( "!ФормаЗаписатьИЗакрыть" );
Закрыть ( список );

возврат код;

Метод для создания товаров

Справочники.Номенклатура.Создать.Параметры

// Параметры создания нового элемента
//
// Возврат:
// Структура параметров

п = новый Структура ();
п.Вставить ( "Наименование" );
п.Вставить ( "Единица", "шт" );
п.Вставить ( "Вид", "Товар" );
п.Вставить ( "СтавкаНДС", "18%" );
возврат п;

Справочники.Номенклатура.Создать

// Создает новую номенклатуру по переданным параметрам
//
// Параметры:
// Структура параметров, полученная методом "Справочники.Номенклатура.Создать.Параметры"
//
// Возврат:
// Код созданной номенклатуры

Коммандос ( "e1cib/data/Справочник.Номенклатура" );

форма = Здесь ( "Номенклатура (соз*" );

// *********************************************
// Заполнение полей
// *********************************************

//установитьВид ( форма, _.Вид );
Установить ( "!ВидНоменклатурыОбязательныеПоля", _.Вид );
Установить ( "Рабочее наименование", _.Наименование );
Установить ( "Единица хранения", _.Единица );
Установить ( "Ставка НДС", _.СтавкаНДС );

// *********************************************
// Запись, получение кода и завершение
// *********************************************

Нажать ( "!ФормаЗаписать" );
код = Взять ( "!Код" );

Закрыть ();

возврат код;

Метод для создания складов

Справочники.Склады.Создать.Параметры

// Параметры создания нового элемента
//
// Возврат:
// Структура параметров

п = новый Структура ();
п.Вставить ( "Наименование" );
возврат п;

Справочники.Склады.Создать

// Создает новый склад по переданным параметрам
//
// Параметры:
// Структура параметров, полученная методом "Справочники.Склады.Создать.Параметры"

Коммандос ( "e1cib/data/Справочник.Склады" );

форма = Здесь ( "* (соз*" );

// *********************************************
// Заполнение полей
// *********************************************

Установить ( "!Наименование", _.Наименование );
Установить ( "!ТипСкладаОптовый", "Оптовый склад" );

// *********************************************
// Запись, получение кода и завершение
// *********************************************

Нажать ( "!ФормаЗаписатьИЗакрыть" );

Метод для создания документа ПоступлениеТоваровУслуг

Документы.ПоступлениеТоваровУслуг.Создать.Параметры

// Параметры создания нового документа
//
// Возврат:
// Структура параметров

СтандартнаяОбработка = ложь;

п = новый Структура ();
п.Вставить ( "Дата" );
п.Вставить ( "Организация", __.Организация );
п.Вставить ( "Склад" );
п.Вставить ( "Поставщик" );
п.Вставить ( "Товары", новый Массив ); // Массив Документы.ЗаказПоставщику.Создать.Строка
п.Вставить ( "ОставитьОткрытым", ложь ); // Закрыть или оставить на экране форму документа

возврат п;

Документы.ПоступлениеТоваровУслуг.Создать.Товар

// Параметры создания новой строки документа
//
// Возврат:
// Структура параметров

СтандартнаяОбработка = ложь;

п = новый Структура ();
п.Вставить ( "Товар" ); // Наименование или Код товара
п.Вставить ( "Количество" );
п.Вставить ( "Цена" );

возврат п;

Документы.ПоступлениеТоваровУслуг.Создать

// Создает новый документ Поступление товаров и услуг по переданным параметрам
//
// Параметры:
// Структура параметров, полученная методом "Документы.ПоступлениеТоваровУслуг.Создать.Параметры"
//
// Возврат:
// Номер созданного заказа

Коммандос ( "e1cib/data/Документ.ПоступлениеТоваровУслуг" );

форма = Здесь ( "Поступление товаров и услуг (соз*" );

// *********************************************
// Заполнение шапки
// *********************************************

дата = _.Дата;
если ( дата <> неопределено ) тогда
	Установить ( "!Дата", Формат ( дата, "DLF=DT" ) );
конецесли;

Установить ( "!Партнер", _.Поставщик );
Установить ( "!Организация", _.Организация );

значение = _.Склад;
если ( значение <> неопределено ) тогда
	Установить ( "!Склад", значение );
конецесли;

// *********************************************
// Заполнение товаров
// *********************************************

таблица = Фокус ( "!Товары" );
для каждого товар из _.Товары цикл

	Нажать ( "!ТоварыДобавить", таблица );
	Установить ( "!ТоварыНоменклатура", товар.Товар );
	Установить ( "!ТоварыКоличествоУпаковок", товар.Количество );
	Установить ( "!ТоварыЦена", товар.Цена );

конеццикла;

// *********************************************
// Запись документа, получение номера
// *********************************************

Нажать ( "!ФормаЗаписать" );
номер = Взять ( "!Номер" );

// *********************************************
// Проведение документа и возврат номера
// *********************************************

Нажать ( "!ФормаПровести" );

закрыть = не _.ОставитьОткрытым;
если ( закрыть ) тогда
	Закрыть ();
конецесли;

возврат номер;

Метод для создания документа РеализацияТоваровУслуг

Документы.РеализацияТоваровУслуг.Создать.Параметры

// Параметры создания нового документа
//
// Возврат:
// Структура параметров

СтандартнаяОбработка = ложь;

п = новый Структура ();
п.Вставить ( "Дата" );
п.Вставить ( "Организация", __.Организация );
п.Вставить ( "Склад" );
п.Вставить ( "Покупатель" );
п.Вставить ( "Товары", новый Массив ); // Массив Документы.ЗаказПоставщику.Создать.Строка
п.Вставить ( "ОставитьОткрытым", ложь ); // Закрыть или оставить на экране форму документа
п.Вставить ( "Комментарий" );

возврат п;

Документы.РеализацияТоваровУслуг.Создать.Товар

// Параметры создания новой строки документа
//
// Возврат:
// Структура параметров

СтандартнаяОбработка = ложь;

п = новый Структура ();
п.Вставить ( "Товар" ); // Наименование или Код товара
п.Вставить ( "Количество" );
п.Вставить ( "Цена" );
п.Вставить ( "Согласование" );

возврат п;

Документы.РеализацияТоваровУслуг.Создать

// Создает новый документ Реализация товаров и услуг по переданным параметрам
//
// Параметры:
// Структура параметров, полученная методом "Документы.РеализацияТоваровУслуг.Создать.Параметры"
//
// Возврат:
// Номер созданного заказа

Коммандос ( "e1cib/data/Документ.РеализацияТоваровУслуг" );

форма = Здесь ( "Реализация товаров и услуг (соз*" );

// *********************************************
// Заполнение шапки
// *********************************************

дата = _.Дата;
если ( дата <> неопределено ) тогда
	Установить ( "!Дата", Формат ( дата, "DLF=DT" ) );
конецесли;

Установить ( "!Партнер", _.Покупатель );
Установить ( "!Организация", _.Организация );

значение = _.Склад;
если ( значение <> неопределено ) тогда
	Установить ( "!Склад", значение );
конецесли;

значение = _.Комментарий;
если ( значение <> неопределено ) тогда
	Установить ( "!Комментарий", значение );
конецесли;

// *********************************************
// Заполнение товаров
// *********************************************

таблица = Фокус ( "!Товары" );
никогда = Дата ( 1, 1, 1 );
для каждого товар из _.Товары цикл

	Нажать ( "!ТоварыДобавить", таблица );
	Установить ( "!ТоварыНоменклатура", товар.Товар );
	Установить ( "!ТоварыКоличествоУпаковок", товар.Количество );
	Очистить ( "!ТоварыВидЦены" );
	Установить ( "!ТоварыЦена", товар.Цена );
	согласование = товар.Согласование;
	если ( согласование <> никогда ) тогда
		Установить ( "!ТоварыДатаСогласования", Формат ( согласование, "DLF=D" ) );
	конецесли;

конеццикла;

// *********************************************
// Запись документа, получение номера
// *********************************************

Нажать ( "!ФормаЗаписать" );
номер = Взять ( "!Номер" );

// *********************************************
// Проведение документа и возврат номера
// *********************************************

Нажать ( "!ФормаПровести" );

закрыть = не _.ОставитьОткрытым;
если ( закрыть ) тогда
	Закрыть ();
конецесли;

возврат номер;

На этом, подготовка методов закончена.

Создание теста ПродажаСДатойСогласования

Переходим к написанию конечного теста для второго этапа. Для этого, в дереве сценариев, создадим такой тест:

Сделаем его основным, и внесем следующий код:

// Сценарий:
// - Создадим окружение в результате которого будет существовать документ
//  реализация с двумя товарами, для второго товара указана дата согласования
// - Откроем список реализаций
// - Найдем созданную реализацию и (пере)проведем её
// - Откроем регистр согласований и найдем там запись, которую должна была сделать реализация
// - Проверим правильность сформированной записи

Вызвать ( "Общее.Начало" );
ЗакрытьВсё ();

ид = "25C555B6";
тест = окружение ( ид );
создатьОкружение ( тест );

// ************************************
// Целевой сценарий
// ************************************

// Откроем реализации
Коммандос ( "e1cib/list/Документ.РеализацияТоваровУслуг" );
Здесь ( "Документы реализации" );

// Перейдем к нашему документу
Кстроке ( "!СписокРеализацииТоваровУслуг", "Клиент", тест.Покупатель );

// Проведем
Нажать ( "!СписокРеализацииТоваровУслугПровести" );

// Откроем регистр согласований
Коммандос ( "e1cib/list/РегистрСведений.Согласование" );
Здесь ( "Согласование" );

// Перейдем к записи
ок = Кстроке ( "!Список", "Клиент", тест.Покупатель );
если ( не ок ) тогда
	Стоп ( "После проведения реализации не сформировались записи в регистре Согласование" );
конецесли;

// Проверим правильность сформированной записи.
// Выведем стандартный список
Нажать ( "!ФормаВывестиСписок" );
Здесь ( "Вывести список" );

// Включим флажок "Только выделенные"
было = Взять ( "!OnlySelectedElement" );
если ( было = "Нет" ) тогда
	Нажать ( "!OnlySelectedElement" );
конецесли;

// Укажем, что выводить будем в табличный документ
Подобрать ( "!DocumentTypeElement", "Табличный документ" );

// Формируем мини-отчет
Нажать ( "!Ok" );

// Просим тестер проверить этот отчет
Здесь ( "Список" );
ПроверитьШаблон ( "" );

// *********************************************
// Процедуры
// *********************************************

Функция окружение ( ИД )

	дата = ТекущаяДата ();
	п = новый Структура ();
	п.Вставить ( "ИД", ИД );
	п.Вставить ( "Дата", дата );
	п.Вставить ( "Согласование", ТекущаяДата () + 172800 ); // Через два дня
	п.Вставить ( "ДатаПоступления", дата - 86400 );
	п.Вставить ( "Поставщик", "Поставщик " + ИД );
	п.Вставить ( "Покупатель", "Покупатель " + ИД );
	п.Вставить ( "Склад", "Склад " + ИД );
	п.Вставить ( "Товары", определитьТовары ( п ) );
	возврат п;

КонецФункции

Функция определитьТовары ( Тест )

	ид = Тест.ИД;
	список = новый Массив ();
	список.Добавить ( новыйТовар ( "Товар1 " + ид, 5, 150, 250 ) );
	список.Добавить ( новыйТовар ( "Товар2 " + ид, 15, 250, 350, Тест.Согласование ) );
	возврат список;

КонецФункции

Функция новыйТовар ( Товар, Количество, Стоимость, Цена, Согласование = неопределено )

	п = новый Структура ();
	п.Вставить ( "Товар", Товар );
	п.Вставить ( "Количество", Количество );
	п.Вставить ( "Стоимость", Стоимость );
	п.Вставить ( "Цена", Цена );
	п.Вставить ( "Согласование", Согласование );
	возврат п;

КонецФункции

Процедура создатьОкружение ( Тест )

	ид = Тест.ИД;

	// *****************************************************
	// Проверяем, нужно ли создавать данные для тестирования
	// *****************************************************

	если ( Вызвать ( "Общее.ОкружениеСоздано", ид ) ) тогда
		возврат;
	конецесли;

	// ******************************************************************
	// Проверим, чтобы в настройках были отключены соглашения с клиентами
	// ******************************************************************

	Коммандос ( "e1cib/command/Обработка.ПанельАдминистрированияУТ.Команда.Продажи" );
	Здесь ( "Продажи" );
	опция = Взять ( "!ИспользованиеСоглашенийСКлиентами" );
	если ( опция <> "Не использовать" ) тогда
		Стоп ( "В целях обучения, этап создания соглашений с клиентами в сценариях не предусмотрен.
		|В окне, которые сейчас на экране с тестируемым приложением, откройте группу
		|Оптовые продажи и в поле Использование соглашений с клиентами, выберите Не использовать" );
	конецесли;

	// ******************
	// Создаем склад
	// ******************

	п = Вызвать ( "Справочники.Склады.Создать.Параметры" );
	п.Наименование = Тест.Склад;
	Вызвать ( "Справочники.Склады.Создать", п );

	// ******************
	// Создаем поставщика
	// ******************

	п = Вызвать ( "Справочники.Поставщики.Создать.Параметры" );
	п.Наименование = Тест.Поставщик;
	Вызвать ( "Справочники.Поставщики.Создать", п );

	// ******************
	// Создаем покупателя
	// ******************

	п = Вызвать ( "Справочники.Покупатели.Создать.Параметры" );
	п.Наименование = Тест.Покупатель;
	Вызвать ( "Справочники.Покупатели.Создать", п );

	// **************
	// Создаем товары
	// **************

	для каждого товар из Тест.Товары цикл
		п = Вызвать ( "Справочники.Номенклатура.Создать.Параметры" );
		п.Наименование = товар.Товар;
		Вызвать ( "Справочники.Номенклатура.Создать", п );
	конеццикла;

	// *******************
	// Создаем поступление
	// *******************

	товары = новый Массив ();
	для каждого позиция из тест.Товары цикл
		товар = Вызвать ( "Документы.ПоступлениеТоваровУслуг.Создать.Товар" );
		товар.Товар = позиция.Товар;
		товар.Количество = позиция.Количество;
		товар.Цена = позиция.Стоимость;
		товары.Добавить ( товар );
	конеццикла;

	п = Вызвать ( "Документы.ПоступлениеТоваровУслуг.Создать.Параметры" );
	п.Товары = товары;
	п.Дата = тест.ДатаПоступления;
	п.Поставщик = тест.Поставщик;
	п.Склад = тест.Склад;

	Вызвать ( "Документы.ПоступлениеТоваровУслуг.Создать", п );

	// *******************
	// Создаем реализацию
	// *******************

	товары = новый Массив ();
	для каждого позиция из тест.Товары цикл
		товар = Вызвать ( "Документы.РеализацияТоваровУслуг.Создать.Товар" );
		товар.Товар = позиция.Товар;
		товар.Количество = позиция.Количество;
		товар.Цена = позиция.Цена;
		товар.Согласование = позиция.Согласование;
		товары.Добавить ( товар );
	конеццикла;

	п = Вызвать ( "Документы.РеализацияТоваровУслуг.Создать.Параметры" );
	п.Товары = товары;
	п.Дата = тест.Дата;
	п.Покупатель = тест.Покупатель;
	п.Склад = тест.Склад;

	Вызвать ( "Документы.РеализацияТоваровУслуг.Создать", п );

	// ********************************
	// Регистрируем созданное окружение
	// ********************************

	Вызвать ( "Общее.ШтампОкружения", ид );

КонецПроцедуры

Так как это наш главный сценарий для второго этапа, разберем его подробней.
Сценарий начинается с Вызвать ( «Общее.Начало» );. Я делаю этот вызов для задания глобальных переменных и выполнения общих задач перед началом работы любого теста. Посмотрим, что внутри теста Общее.Начало:

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

СтандартнаяОбработка = ложь;

если ( __ = неопределено ) тогда
	__ = новый Структура ();
иначе
	возврат;
конецесли;

// *************************************************************************
// Используем переменную "__" для задания произвольных глобальных параметров
// *************************************************************************

__.Вставить ( "ПроверятьЛогику", истина );
__.Вставить ( "ЛокальнаяВалюта", "РУБ" );

если ( ИмяПриложения = "УТ11" ) тогда
	__.Вставить ( "Организация", "Торговый дом ""Комплексный""" );
конецесли;

// ***********************************************
// Выполняем подключение к тестируемому приложению
// ***********************************************

Подключить ();

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

если ( ИмяПриложения = "УТ11" ) тогда
	__.Вставить ( "Организация", "Торговый дом ""Комплексный""" );
конецесли;

Работает это всё следующим образом. Когда тест ПродажаСДатойСогласования будет запущен, он в свою очередь запустит тест Общее.Начало, который определит несколько переменных и подключится к тестируемому приложению. Все тесты, которые будут запускаться дальше, уже будут знать, что в переменной “__” хранится имя организации, локальная валюта и другие параметры. Это своего рода глобальное параметризирование тестируемой среды (использование двойного подчеркивания в качестве глобальной переменной выбрано для независимости от варианта языка 1С).

Затем, тест закрывает все окна в тестируемом приложении. Это нужно для того, чтобы случайно не активировать те формы, которые используется в процессе работы теста, но находятся в несогласованном с ним состоянии.

Следующие три строки определяют и создают окружение (см. Структура сценария):

// Переменная "ид" задает идентификатор окружения.
// Идентификатор окружения может быть любой, но я рекомендую использовать
// указанный ниже шаблон алфавитно-цифровой последовательности,
// которая может быть автоматически сгенерирована в редакторе модуля
// по комбинации клавиш: Ctrl+Shit+I
// Таким образом, чтобы пересоздать окружение, нужно будет просто сменить "ид".
// Почему это так - будет понятно ниже.
ид = "25C555B6";

// В переменную "тест" функция окружение () вернет структуру с параметрами
// нашего теста. Эти параметры и есть определение окружения.
тест = окружение ( ид );

// Процедура создатьОкружение () выполняет создание необходимых тестовых данных.
// Внутри этой процедуры будут вызываться тесты-методы, которые мы создавали в разделах выше.
создатьОкружение ( тест );

Посмотрим, что происходит внутри функции окружение () :

Функция окружение ( ИД )

	дата = ТекущаяДата ();
	п = новый Структура ();
	п.Вставить ( "ИД", ИД );
	п.Вставить ( "Дата", дата );
	п.Вставить ( "Согласование", ТекущаяДата () + 172800 ); // Через два дня
	п.Вставить ( "ДатаПоступления", дата - 86400 );
	п.Вставить ( "Поставщик", "Поставщик " + ИД );
	п.Вставить ( "Покупатель", "Покупатель " + ИД );
	п.Вставить ( "Склад", "Склад " + ИД );
	п.Вставить ( "Товары", определитьТовары ( п ) );
	возврат п;

КонецФункции

Ничего необычного, готовится структура с параметрами, но концептуальным является использование входящего параметра ИД.

Тестовые данные создаются, а значит, они должны быть уникальны. В противном случае, будут создаваться дубли объектов, которые практически, будет невозможно использовать. Действительно, если мы будем создавать “ТОО Ромашка» каждый раз, какую тогда «ТОО Ромашка» выбрать при создании документа? Таким образом, строки кода «Поставщик » + ИД, «Покупатель » + ИД и другие, гарантируют создание уникальных тестовых данных. Это также позволяет выполнять ваши тесты у других участников разработки, без синхронизации заготовленных шаблонов, использования предзаполненных баз данных и других внешних файлов.

Вероятно, данный подход вызывает недоумение, потому что база со временем превращается в месиво из ничего незначащих идентификаторов. Но на практике, любая база разработчика превращается в обрывки экспериментов из “порванных” данных, это лишь вопрос времени. Если вы в рабочих базах бережно храните некую информацию, на которую опирается ваша разработка – перенести эти данные в начальную базу. Если базы содержат ошибки для воспроизведения – напишите тесты, которые эти ошибки воспроизводят. Другими словами, если у вас в рабочей базе есть что-то ценное с прикладной точки зрения – напишите сценарий. Это высвободит вас от содержания хозяйства из информационных баз, даст возможность другим разработчикам проверить ваши варианты в их базах на любом этапе разработки. Весь полезный опыт, сосредоточенный в данных, лучше перевести в код сценария, что бы его всегда можно было повторить.

Другой, кажущийся тревожным момент – это глубина уникальности тестовых данных и их объем. И тут нужно отметить, что не все тестовые данные нужно делать уникальными. Уникальности требует только то, что вам нужно для тестирования (включая проверку бизнес логики). К примеру, для нашего теста нужна уникальность наименований поставщика, покупателя, склада и товаров. Нам не требуется уникальность единиц измерений, договоров, соглашений, групп товаров и других связанных данных. Рост данных также не будет проблемой. Даже если вы каждые 5 минут запускаете тест создающий окружение (что крайне маловероятно), то в течение дня таких запусков будет не больше 100, что для дневного роста базы ничтожно мало. На практике, необходимость в обнулении рабочей базы загрузкой в неё начальной, возникает примерно раз в полгода. Согласитесь, что программисты, тестирующие всё вручную, примерно с той же периодичностью выводят из строя свои рабочие базы.

Следующий участок кода, процедура создатьОкружение (). Внутри этой процедуры происходит создание тестовых данных. Создание окружения процесс не быстрый, но и не обязательный для каждого запуска сценария в процессе программирования задачи. Для того, чтобы окружение не создавалось каждый раз, можно использовать два подхода.

Первый – комментировать вызов процедуры создатьОкружение () после того, как оно однажды было создано. Однако со временем, это начинает утомлять.

Второй – вначале процедуры, проверять, было ли окружение уже создано, и если нет, в конце процедуры фиксировать факт его создания:

Процедура создатьОкружение ( Тест )

	ид = Тест.ИД;

	// *****************************************************
	// Проверяем, нужно ли создавать данные для тестирования
	// *****************************************************

	если ( Вызвать ( "Общее.ОкружениеСоздано", ид ) ) тогда
		возврат;
	конецесли;

	//...код создания окружения...

	// ********************************
	// Регистрируем созданное окружение
	// ********************************

	Вызвать ( "Общее.ШтампОкружения", ид );

КонецПроцедуры

Для хранения идентификатора созданного окружения можно использовать “простой” объект конфигурации, куда можно легко помещать и извлекать значения. Вот что происходит в библиотечном сценарии Общее.ОкружениеСоздано :

// Описание:
// По переданному ИД определяет было ли создано окружение
//
// Параметры:
// Строка, идентификатор окружения
//
// Возврат:
// Булево, истина - окружение уже создано, ложь - окружение еще не создано

Коммандос ( "e1cib/list/Справочник.Заметки" );
Здесь ( "Заметки" );

попытка
	создано = КСтроке ( "!Список", "Тема", _ );
исключение
	создано = ложь;
конецпопытки;

Закрыть ();
возврат создано;

Таким образом, в качестве объекта для хранения окружения используется справочник Заметки.

Примечание 1: Переход к строке сделан через попытку, потому что в версиях платформы <= 8.3.9 есть ошибка работы метода перехода к строке. В случае отсутствия искомой строки, платформа ошибочно генерирует исключение вместо возврата булевого значения.

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

Остальная и основная часть процедуры создатьОкружение () содержит рутину по заполнению параметров и вызову сценариев-методов. Несмотря на простоту логики создания объектов, может потребоваться многократный запуск кода создания окружения при его разработке. В этом случае, запускать полный цикл теста может быть не эффективно. Одним из часто используемых трюков является временный вынос кода в начало основного сценария, с вставкой оператора возврат; до начала основного теста, например так:

Подключить ();

// Отлаживаем по-быстрому...
п = Вызвать ( "Справочники.Склады.Создать.Параметры" );
п.Наименование = "Тестовый склад";
Вызвать ( "Справочники.Склады.Создать", п );

возврат; // Когда отладим, вырежем этот код в тело процедуры создатьОкружение ()

// Сценарий:
// - Создадим окружение в результате которого будет существовать документ
//  реализация с двумя товарами, для второго товара указана дата согласования
// - Откроем список реализаций
// - Найдем созданную реализацию и (пере)проведем её
// - Откроем регистр согласований и найдем там запись, которую должна была сделать реализация
// - Проверим правильность сформированной записи

Вызвать ( "Общее.Начало" );
ЗакрытьВсё ();

//....

Таким образом, кусок за куском логики можно отлаживать и переносить в процедуру создатьОкружение (). Обратите внимание, что для пересоздания всего окружения, вам просто нужно будет сменить ИД в начале теста.

Я описал определение и создание окружения, перейдем теперь к целевой части сценария ПродажаСДатойСогласования :

// Откроем реализации
Коммандос ( "e1cib/list/Документ.РеализацияТоваровУслуг" );
Здесь ( "Документы реализации" );

// Перейдем к нашему документу
Кстроке ( "!СписокРеализацииТоваровУслуг", "Клиент", тест.Покупатель );

// Проведем
Нажать ( "!СписокРеализацииТоваровУслугПровести" );

// Откроем регистр согласований
Коммандос ( "e1cib/list/РегистрСведений.Согласование" );
Здесь ( "Согласование" );

// Перейдем к записи
ок = Кстроке ( "!Список", "Клиент", тест.Покупатель );
если ( не ок ) тогда
	Стоп ( "После проведения реализации не сформировались записи в регистре Согласование" );
конецесли;

// Проверим правильность сформированной записи.
// Выведем стандартный список
Нажать ( "!ФормаВывестиСписок" );
Здесь ( "Вывести список" );

// Включим флажок "Только выделенные"
было = Взять ( "!OnlySelectedElement" );
если ( было = "Нет" ) тогда
	Нажать ( "!OnlySelectedElement" );
конецесли;

// Укажем, что выводить будем в табличный документ
Подобрать ( "!DocumentTypeElement", "Табличный документ" );

// Формируем мини-отчет
Нажать ( "!Ok" );

// Просим тестер проверить этот отчет
Здесь ( "Список" );
ПроверитьШаблон ( "" );

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

Нажать ( "!ФормаВывестиСписок" );
Здесь ( "Вывести список" );
// и далее...

и возможность Тестера сравнивать табличный документ с макетом, сохраненным в сценарии:

Здесь ( "Список" );
ПроверитьШаблон ( "" );

На картинке совмещено для наглядности тестируемое приложение (находится выше) и Тестер (находится ниже). Как вы понимаете, я немного забежал вперед, шаблон сохраненный в Тестере был предварительно скопирован из тестируемого приложения, на момент готовности программного кода по формированию этих движений, но программированием второго рывка мы еще не занимались. Это вынужденная мера, мне нужно было логически завершить описание трех-структурного подхода к организации сценариев.

Если мы сейчас запустим сценарий на выполнение, он упадет на этапе создания окружения, ведь у нас кроме логики проведения, еще нет реквизита ДатаСогласования в табличной части Товары документа РеализацияТоваровУслуг.

Займемся программированием:
— Добавим нужный реквизит:

— Выведем на форму:

— В процедуру ОбработкаПроведения модуля объекта, добавим код:

Процедура ОбработкаПроведения(Отказ, РежимПроведения)

	с = "
	|выбрать Товары.Ссылка.Менеджер как Менеджер, Товары.Ссылка.Партнер как Клиент,
	|	Товары.Номенклатура как Товар, Товары.Количество как Количество, Товары.Сумма как Сумма,
	|	Товары.КодСтроки как Строка, Товары.ДатаСогласования как ДатаСогласования, &Ссылка как Реализация
	|из Документ.РеализацияТоваровУслуг.Товары как Товары
	|	//
	|	// Согласованные
	|	//
	|	левое соединение РегистрСведений.Согласование как Согласованные
	|	по Согласованные.Строка = Товары.КодСтроки
	|где Товары.Ссылка = &Ссылка
	|и Товары.ДатаСогласования <> датавремя ( 1, 1, 1 )
	|и не isnull ( Согласованные.Отработано, ложь )
	|";
	з = новый Запрос ( с );
	з.УстановитьПараметр ( "Ссылка", Ссылка );
	таблица = з.Выполнить ().Выгрузить ();
	для каждого строка из таблица цикл
		запись = РегистрыСведений.Согласование.СоздатьМенеджерЗаписи ();
		ЗаполнитьЗначенияСвойств ( запись, строка );
		запись.Записать ();
	конеццикла;

//...далее идет типовой код конфигурации

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

Выделите в УТ11 этот макет и скопируйте в Тестер на вкладку Шаблон сценария ПродажаСДатойСогласования. Затем, в Тестере, выделите значимую область, вызовите правым кликом контекстное меню и укажите Отметить область:

Для того, чтобы шаблон не проверялся как есть, нам нужно его параметризировать. Для этого, в каждой ячейке, которая может меняться в зависимости от времени и условий запуска теста, в контекстном меню произведем замену значения на шаблон:

Проделаем так с каждым полем, чтобы получилась в итоге следующая картина:

Обратите внимание, что значения ячеек Количество и Сумма оставлены как есть. Это важно, потому что в отличие от предыдущих полей, которые могу изменяться в зависимости от идентификатора окружения, эта часть фиксированная, прописана в условии теста и должна быть гарантированно такой (более полный пример проверки бизнес логики см. Проверка бизнес логики).
Запускаем сценарий на выполнение и убеждаемся, что тест проходит успешно.
Переходим к следующему запланированному этапу.

Этап 3

В этом рывке нам нужно разработать форму списка для регистра Согласование с фильтрами по клиенту, товару и менеджеру.
В таблице ниже состыкуем работу по кодированию и тестированию:

Программирование

Тестирование

В Конфигураторе: Добавляем форму списка в регистр сведений Согласование Создаем три реквизита формы соответствующих типов, выкладываем их на форму Настраиваем свойства и обработчики Прописываем код обработчиков фильтрации

В Тестере: Создадим тест ФильтрацияСписка, где: Определим окружение: Наименование Поставщика Наименование Покупателя Наименование Потенциального клиента, по которому продаж нет Товар с датой согласования Создадим окружение Создадим поставщика, покупателей и товар Сделаем поступление Создадим и проведем реализацию Целевая часть Откроем список регистра Согласование Установим отбор по покупателю, проверим список Установим отбор по потенциальному клиенту, проверим пустой список Установим/снимем отборы по товару и менеджеру

Для разнообразия, в этот раз начнем с программирования, а затем напишем тест.

— Добавим основную форму списка, добавим реквизиты формы, расположим на форме:

— В модуле формы списка, определим обработчики полей фильтрации:

&НаКлиенте
Процедура КлиентФильтрПриИзменении ( Элемент )

	ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбораДинамическогоСписка(Список,
		"Клиент",
		КлиентФильтр,
		ВидСравненияКомпоновкиДанных.Равно,
		,
		ЗначениеЗаполнено(КлиентФильтр));

КонецПроцедуры

&НаКлиенте
Процедура ТоварФильтрПриИзменении ( Элемент )

	ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбораДинамическогоСписка(Список,
		"Товар",
		ТоварФильтр,
		ВидСравненияКомпоновкиДанных.Равно,
		,
		ЗначениеЗаполнено(ТоварФильтр));

КонецПроцедуры

&НаКлиенте
Процедура МенеджерФильтрПриИзменении ( Элемент )

	ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбораДинамическогоСписка(Список,
		"Менеджер",
		МенеджерФильтр,
		ВидСравненияКомпоновкиДанных.Равно,
		,
		ЗначениеЗаполнено(МенеджерФильтр));

КонецПроцедуры

На этом этапе с программированием всё. Перейдем к разработке теста. Для этого, как и в прошлые разы, в дереве сценариев, создадим новый сценарий. Установим этот сценарий основным, и назовем его ФильтрацияСписка :

Введем следующий код сценария:

// Сценарий:
// - Создадим окружение в результате которого будет существовать проведенный документ
//  реализация с товаром, для которого указана дата согласования
// - Откроем список Согласование
// - Установим отбор по покупателю, убедимся, что в списке есть отфильтрованная запись
// - Установим отбор по потенциальному клиенту, убедимся, что список пуст
// - Очистим фильтры по товару и менеджеру, проверим что они отрабатывают,
//  допускаем, что если нет ошибок тогда фильтрация происходит

Вызвать ( "Общее.Начало" );
ЗакрытьВсё ();

ид = "25CB69CB";
тест = окружение ( ид );
создатьОкружение ( тест );

// ************************************
// Целевой сценарий
// ************************************

// Откроем регистр согласований
Коммандос ( "e1cib/list/РегистрСведений.Согласование" );
Здесь ( "Согласование" );

// Установим фильтр по покупателю
покупатель = тест.Покупатель;
Ввести ( "!КлиентФильтр", покупатель );

// Найдем его в списке
ок = Кстроке ( "!Список", "Клиент", покупатель );
если ( не ок ) тогда
	Стоп ( "В списке не найдена отфильтрованная по клиенту запись" );
конецесли;

// Установим фильтр по потенциальному клиенту
Ввести ( "!КлиентФильтр", тест.ПотенциальныйКлиент );

// Список должен быть пустой
пусто = 0 = Вызвать ( "Таблица.Количество", Получить ( "!Список" ) );
если ( не пусто ) тогда
	Стоп ( "Список должен быть пуст" );
конецесли;
Очистить ( "!КлиентФильтр" );

// Установим и очистим фильтр по товару
Ввести ( "!ТоварФильтр", тест.Товары [ 0 ].Товар );
Очистить ( "!ТоварФильтр" );

// Очистим фильтр по менеджеру
Очистить ( "!МенеджерФильтр" );

// *********************************************
// Процедуры
// *********************************************

Функция окружение ( ИД )

	дата = ТекущаяДата ();
	п = новый Структура ();
	п.Вставить ( "ИД", ИД );
	п.Вставить ( "Дата", дата );
	п.Вставить ( "Согласование", дата + 172800 ); // Через два дня
	п.Вставить ( "ДатаПоступления", дата - 86400 );
	п.Вставить ( "Поставщик", "Поставщик " + ИД );
	п.Вставить ( "Покупатель", "Покупатель " + ИД );
	п.Вставить ( "ПотенциальныйКлиент", "Потенциальный клиент " + ИД );
	п.Вставить ( "Склад", "Склад " + ИД );
	п.Вставить ( "Товары", определитьТовары ( п ) );
	возврат п;

КонецФункции

Функция определитьТовары ( Тест )

	ид = Тест.ИД;
	список = новый Массив ();
	список.Добавить ( новыйТовар ( "Товар1 " + ид, 15, 250, 350, Тест.Согласование ) );
	возврат список;

КонецФункции

Функция новыйТовар ( Товар, Количество, Стоимость, Цена, Согласование = неопределено )

	п = новый Структура ();
	п.Вставить ( "Товар", Товар );
	п.Вставить ( "Количество", Количество );
	п.Вставить ( "Стоимость", Стоимость );
	п.Вставить ( "Цена", Цена );
	п.Вставить ( "Согласование", Согласование );
	возврат п;

КонецФункции

Процедура создатьОкружение ( Тест )

	ид = Тест.ИД;

	// *****************************************************
	// Проверяем, нужно ли создавать данные для тестирования
	// *****************************************************

	если ( Вызвать ( "Общее.ОкружениеСоздано", ид ) ) тогда
		возврат;
	конецесли;

	// ******************
	// Создаем склад
	// ******************

	п = Вызвать ( "Справочники.Склады.Создать.Параметры" );
	п.Наименование = Тест.Склад;
	Вызвать ( "Справочники.Склады.Создать", п );

	// ******************
	// Создаем поставщика
	// ******************

	п = Вызвать ( "Справочники.Поставщики.Создать.Параметры" );
	п.Наименование = Тест.Поставщик;
	Вызвать ( "Справочники.Поставщики.Создать", п );

	// *******************
	// Создаем покупателей
	// *******************

	п = Вызвать ( "Справочники.Покупатели.Создать.Параметры" );
	п.Наименование = Тест.Покупатель;
	Вызвать ( "Справочники.Покупатели.Создать", п );

	п.Наименование = Тест.ПотенциальныйКлиент;
	Вызвать ( "Справочники.Покупатели.Создать", п );

	// **************
	// Создаем товары
	// **************

	для каждого товар из Тест.Товары цикл
		п = Вызвать ( "Справочники.Номенклатура.Создать.Параметры" );
		п.Наименование = товар.Товар;
		Вызвать ( "Справочники.Номенклатура.Создать", п );
	конеццикла;

	// *******************
	// Создаем поступление
	// *******************

	товары = новый Массив ();
	для каждого позиция из тест.Товары цикл
		товар = Вызвать ( "Документы.ПоступлениеТоваровУслуг.Создать.Товар" );
		товар.Товар = позиция.Товар;
		товар.Количество = позиция.Количество;
		товар.Цена = позиция.Стоимость;
		товары.Добавить ( товар );
	конеццикла;

	п = Вызвать ( "Документы.ПоступлениеТоваровУслуг.Создать.Параметры" );
	п.Товары = товары;
	п.Дата = тест.ДатаПоступления;
	п.Поставщик = тест.Поставщик;
	п.Склад = тест.Склад;

	Вызвать ( "Документы.ПоступлениеТоваровУслуг.Создать", п );

	// *******************
	// Создаем реализацию
	// *******************

	товары = новый Массив ();
	для каждого позиция из тест.Товары цикл
		товар = Вызвать ( "Документы.РеализацияТоваровУслуг.Создать.Товар" );
		товар.Товар = позиция.Товар;
		товар.Количество = позиция.Количество;
		товар.Цена = позиция.Цена;
		товар.Согласование = позиция.Согласование;
		товары.Добавить ( товар );
	конеццикла;

	п = Вызвать ( "Документы.РеализацияТоваровУслуг.Создать.Параметры" );
	п.Товары = товары;
	п.Дата = тест.Дата;
	п.Покупатель = тест.Покупатель;
	п.Склад = тест.Склад;

	Вызвать ( "Документы.РеализацияТоваровУслуг.Создать", п );

	// ********************************
	// Регистрируем созданное окружение
	// ********************************

	Вызвать ( "Общее.ШтампОкружения", ид );

КонецПроцедуры

Комментарии по коду теста:

1. Фактически, этот сценарий является упрощенной версией сценария, который мы создали на предыдущем этапе.
2. Я опустил в этом сценарии проверку настройки соглашений с клиентами, в реальном проекте вы эту настройку выделите в отдельный тест проверки окружения и не будете включать в каждый ваш тест.
3. В этом сценарии используется библиотечный тест Вызвать ( «Таблица.Количество», Получить ( «! Список» ) ). Хороший пример того, как можно общую логику по работе с объектами системы выделять в отдельные тесты.
4. Чистого времени на разработку этого теста, у освоившего Тестер программиста уходит до 7 минут.
5. Не стесняйтесь копировать сценарии, всё-таки код сценария не совсем тоже самое, что код решения. Во многих случаях, лучше не злоупотреблять возможностью организации в тестах изощренных зависимостей ради ухода от повторения кода. Ведь тесты падают и время на анализ “почему?” тоже нужно брать в расчет. При сложных зависимостях, это будет сделать не просто (хотя полный стек ошибок и отладчик в Тестере есть).
6. При копировании тестов не забывайте менять идентификатор окружения.

Запустите тест, он должен пройти без ошибок. Этот этап готов, идем дальше.

Этап 4

На этом этапе нам нужно разработать форму редактирования записи для регистра Согласование. Форма для редактирования нужна пользователю для фиксации результатов переговоров с заказчиком (условия задачи были описаны здесь).

В таблице ниже состыкуем работу по кодированию и тестированию:

Программирование

Тестирование

В Конфигураторе: Добавляем форму записи в регистр сведений Согласование Формируем внешний вид Пишем логику работы формы

В Тестере: Создадим тест РедактированиеФормыСогласования, где: Определим окружение: Наименование Поставщика Наименование Покупателя Товар с датой согласования Создадим окружение Создадим поставщика, покупателя и товар Сделаем поступление Создадим и проведем реализацию Целевая часть Откроем список регистра Согласование Установим отбор по покупателю и откроем единственную в списке запись Убедимся, что поле Комментарий недоступно для редактирования Нажмем галку Отработано, убедимся, что поле Комментарий теперь доступно. Сохраним и закроем форму Откроем её еще раз и убедимся, что поле Комментарий доступно Снимем галку Отработано, затем опять включим и убедимся, что поле Комментарий очищено Попробуем в списке создать новую запись Проверим, получил ли пользователь предупреждение о запрете на непосредственный ввод записей в регистр

Этот рывок будем делать комбинированно. Начнем с создания макета формы, в конфигураторе, создадим такую запись регистра:

Запустим приложение. Переключимся в Тестер, и в дереве сценариев создадим и зададим как основной тест РедактированиеФормыСогласования:

И введем такой код:

// Сценарий:
// - Создадим окружение в результате которого будет существовать проведенный документ
//  реализация с товаром, для которого указана дата согласования
// - Откроем список регистра Согласование
// - Установим отбор по покупателю и откроем единственную в списке запись
// - Убедимся, что поле Комментарий недоступно для редактирования (условия задачи были описаны здесь)
// - Нажмем галку Отработано, убедимся, что поле Комментарий теперь доступно.
// - Сохраним и закроем форму
// - Откроем её еще раз и убедимся, что поле Комментарий доступно
// - Снимем галку Отработано, затем опять включим и убедимся, что поле Комментарий очищено
// - Попробуем в списке создать новую запись
// - Проверим, получил ли пользователь предупреждение о запрете на непосредственный ввод записей в регистр

Вызвать ( "Общее.Начало" );
ЗакрытьВсё ();

ид = "25CB8B15";
тест = окружение ( ид );
создатьОкружение ( тест );

// ************************************
// Целевой сценарий
// ************************************

// Откроем регистр согласований
Коммандос ( "e1cib/list/РегистрСведений.Согласование" );
список = Здесь ( "Согласование" );

// Установим фильтр по покупателю
покупатель = тест.Покупатель;
Ввести ( "!КлиентФильтр", покупатель );

// Найдем его в списке
Кстроке ( "!Список", "Клиент", покупатель );

// Откроем запись
Нажать ( "!ФормаИзменить" );
Здесь ( Приложение.ПолучитьАктивноеОкно ().ПолучитьОбъект () );

// Проверим, что с галкой, может с прошлого раза осталась включенной
если ( "Да" = Взять ( "!Отработано" ) ) тогда
	Нажать ( "!Отработано" ); // выключим шалку
конецесли;

// Комментарий должен быть недоступен
ПроверитьСтатус ( "!Комментарий", "Доступность", ложь );

// Жмем галку Отработано
Нажать ( "!Отработано" );

// Комментарий должен быть доступен
ПроверитьСтатус ( "!Комментарий", "Доступность" );

// Вводим что-то в комментарий
Установить ( "!Комментарий", "Тестовый комментарий" );

// Нажимаем Записать и закрыть
Нажать ( "!ФормаЗаписатьИЗакрыть" );

// Возвращаемся в список и опять открываем эту запись
Здесь ( список );
Нажать ( "!ФормаИзменить" );
Здесь ( Приложение.ПолучитьАктивноеОкно ().ПолучитьОбъект () );

// Комментарий должен быть доступен
ПроверитьСтатус ( "!Комментарий", "Доступность" );

// Снимаем галку Отработано и устанавливаем заново
Нажать ( "!Отработано" );
Нажать ( "!Отработано" );

// Комментарий должен быть очищен
Проверить ( "!Комментарий", "" );
Нажать ( "!ФормаЗаписатьИЗакрыть" );

// Закроем форму, вернемся в список и попробуем ввести новую запись
Здесь ( список );
Нажать ( "!ФормаСоздать" );

// Проверим обязательное наличие сообщения об ошибке
если ( НайтиСообщения ( "*формируются автоматически*" ).Количество () = 0 ) тогда
  Стоп ( "Отсутствует сообщение об ошибке" );
конецесли;
Закрыть ();

// *********************************************
// Процедуры
// *********************************************

Функция окружение ( ИД )

	дата = ТекущаяДата ();
	п = новый Структура ();
	п.Вставить ( "ИД", ИД );
	п.Вставить ( "Дата", дата );
	п.Вставить ( "Согласование", дата + 172800 ); // Через два дня
	п.Вставить ( "ДатаПоступления", дата - 86400 );
	п.Вставить ( "Поставщик", "Поставщик " + ИД );
	п.Вставить ( "Покупатель", "Покупатель " + ИД );
	п.Вставить ( "Склад", "Склад " + ИД );
	п.Вставить ( "Товары", определитьТовары ( п ) );
	возврат п;

КонецФункции

Функция определитьТовары ( Тест )

	ид = Тест.ИД;
	список = новый Массив ();
	список.Добавить ( новыйТовар ( "Товар1 " + ид, 15, 250, 350, Тест.Согласование ) );
	возврат список;

КонецФункции

Функция новыйТовар ( Товар, Количество, Стоимость, Цена, Согласование = неопределено )

	п = новый Структура ();
	п.Вставить ( "Товар", Товар );
	п.Вставить ( "Количество", Количество );
	п.Вставить ( "Стоимость", Стоимость );
	п.Вставить ( "Цена", Цена );
	п.Вставить ( "Согласование", Согласование );
	возврат п;

КонецФункции

Процедура создатьОкружение ( Тест )

	ид = Тест.ИД;

	// *****************************************************
	// Проверяем, нужно ли создавать данные для тестирования
	// *****************************************************

	если ( Вызвать ( "Общее.ОкружениеСоздано", ид ) ) тогда
		возврат;
	конецесли;

	// ******************
	// Создаем склад
	// ******************

	п = Вызвать ( "Справочники.Склады.Создать.Параметры" );
	п.Наименование = Тест.Склад;
	Вызвать ( "Справочники.Склады.Создать", п );

	// ******************
	// Создаем поставщика
	// ******************

	п = Вызвать ( "Справочники.Поставщики.Создать.Параметры" );
	п.Наименование = Тест.Поставщик;
	Вызвать ( "Справочники.Поставщики.Создать", п );

	// *******************
	// Создаем покупателей
	// *******************

	п = Вызвать ( "Справочники.Покупатели.Создать.Параметры" );
	п.Наименование = Тест.Покупатель;
	Вызвать ( "Справочники.Покупатели.Создать", п );

	// **************
	// Создаем товары
	// **************

	для каждого товар из Тест.Товары цикл
		п = Вызвать ( "Справочники.Номенклатура.Создать.Параметры" );
		п.Наименование = товар.Товар;
		Вызвать ( "Справочники.Номенклатура.Создать", п );
	конеццикла;

	// *******************
	// Создаем поступление
	// *******************

	товары = новый Массив ();
	для каждого позиция из тест.Товары цикл
		товар = Вызвать ( "Документы.ПоступлениеТоваровУслуг.Создать.Товар" );
		товар.Товар = позиция.Товар;
		товар.Количество = позиция.Количество;
		товар.Цена = позиция.Стоимость;
		товары.Добавить ( товар );
	конеццикла;

	п = Вызвать ( "Документы.ПоступлениеТоваровУслуг.Создать.Параметры" );
	п.Товары = товары;
	п.Дата = тест.ДатаПоступления;
	п.Поставщик = тест.Поставщик;
	п.Склад = тест.Склад;

	Вызвать ( "Документы.ПоступлениеТоваровУслуг.Создать", п );

	// *******************
	// Создаем реализацию
	// *******************

	товары = новый Массив ();
	для каждого позиция из тест.Товары цикл
		товар = Вызвать ( "Документы.РеализацияТоваровУслуг.Создать.Товар" );
		товар.Товар = позиция.Товар;
		товар.Количество = позиция.Количество;
		товар.Цена = позиция.Цена;
		товар.Согласование = позиция.Согласование;
		товары.Добавить ( товар );
	конеццикла;

	п = Вызвать ( "Документы.РеализацияТоваровУслуг.Создать.Параметры" );
	п.Товары = товары;
	п.Дата = тест.Дата;
	п.Покупатель = тест.Покупатель;
	п.Склад = тест.Склад;

	Вызвать ( "Документы.РеализацияТоваровУслуг.Создать", п );

	// ********************************
	// Регистрируем созданное окружение
	// ********************************

	Вызвать ( "Общее.ШтампОкружения", ид );

КонецПроцедуры

Комментарии по коду сценария:

1. Этот тест был создан путем копирования предыдущего, окружение практически не модифицировалось, я убрал создание потенциального клиента
2. Может вызвать интерес такая строка кода: Здесь ( Приложение.ПолучитьАктивноеОкно ().ПолучитьОбъект () );. В данном случае показан пример работы с тестируемым приложением через стандартные методы платформы. В переменной Приложение, Тестер хранит объект ТестируемоеПриложение, через который можно вызывать все остальные методы платформы в режиме клиента тестирования (подробнее см. API Тестера).

Итак, запускаем тест и убеждаемся, что он падает, так как у нас не реализована логика работы формы. Далее, возвращаемся в конфигуратор, переключаемся в модуль формы записи и вводим такой код:

// *****************************************
// *********** События формы

&НаСервере
Процедура ПриЧтенииНаСервере ( ТекущийОбъект )

	оформить ();

КонецПроцедуры

&НаСервере
Процедура оформить ( Зависимость = неопределено )

	если ( Зависимость = неопределено или есть ( Зависимость, "Отработано" ) ) тогда
		Элементы.Комментарий.Доступность = Запись.Отработано;
	конецесли;

КонецПроцедуры

&НаСервере
Функция есть ( Зависимость, Список )

	возврат СтрРазделить ( Список, "," ).Найти ( Зависимость ) <> неопределено;

КонецФункции

&НаСервере
Процедура ПриСозданииНаСервере ( Отказ, СтандартнаяОбработка )

	если ( Запись.ИсходныйКлючЗаписи.Пустой () ) тогда
		ошибка ();
		Отказ = истина;
	конецесли;

КонецПроцедуры

&НаСервере
Функция ошибка ()

	Сообщить ( Нстр ( "ru = 'Записи в данном регистре формируются автоматически, при проведении документа Реализация товаров и услуг'" ) );

КонецФункции

// *****************************************
// *********** Группа Форма

&НаКлиенте
Процедура ОтработаноПриИзменении ( Элемент )

	применитьОтработано ();
	оформить ( "Отработано" );

КонецПроцедуры

&НаКлиенте
Процедура применитьОтработано ()

	если ( не Запись.Отработано ) тогда
		Запись.Комментарий = "";
	конецесли;

КонецПроцедуры

Затем, переключимся в форму и зададим обработчики событий: ПриЧтенииНаСервере, ПриСозданииНаСервере, ОтработаноПриИзменении. Запустите приложение, запустите тест и убедитесь, что он проходит.

Заключение

Мы рассмотрели теоретическую и практическую части применения системы Тестер для организации работы программиста через тестирование управляемого кодом клиентского приложения. Многие выкладки можно найти спорными и даже прямо противоположными учениям авторитетов в области построения процессов тестирования. Не вопреки, а с осознанием этого, готовился данный материал. Основной целью было показать практическое применение методики и средств сценарного тестирования.
Я допускаю, что в каждом разработанном сценарии, кто-то найдет “перебор” по части объема тестируемого функционала, а кто-то “недобор”. Мне остается лишь надеяться, что в этой статье был достигнут баланс между всем надоевшей простотой и малоинтересной сложностью. Не менее важной задачей, было показать, как можно вживить в разработку автоматизированное сценарное тестирование, чтобы оно не казалось аппендиксом или очередной надстройкой над сущностью программирования.

Большое спасибо, что не оставили без внимания этот труд. Удачных вам тестов, друзья!

Что такое тестирование сценария?

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

Давайте изучим это с помощью видео ниже —

Зачем создавать тестовые сценарии?

Тестовые сценарии создаются по следующим причинам:

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

Когда не создать тестовый сценарий?

Тестовые сценарии не могут быть созданы, когда

• Тестируемое приложение является сложным, нестабильным, и в проекте есть время.
• Проекты, которые следуют Agile методологии, такие как Scrum, Kanban, могут не создавать тестовые сценарии.
• Сценарий тестирования не может быть создан для исправления новой ошибки или регрессионного тестирования . В таких случаях сценарии тестирования должны быть уже задокументированы в предыдущих циклах тестирования. Это особенно верно для проектов технического обслуживания.

Как написать тестовые сценарии

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

• Шаг 1 : Прочтите документы с требованиями, такие как BRS, SRS, FRS, тестируемой системы (SUT). Вы также можете сослаться на примеры использования, книги, руководства и т. Д. Приложения, подлежащего тестированию.
• Шаг 2 : Для каждого требования определите возможные действия и цели пользователей. Определить технические аспекты требования. Определите возможные сценарии злоупотребления системой и оцените пользователей с менталитетом хакера.
• Шаг 3: После прочтения Документа с требованиями и проведения надлежащего анализа перечислите различные сценарии тестирования, которые проверяют каждую функцию программного обеспечения.
• Шаг 4: После того, как вы перечислили все возможные сценарии тестирования, создается матрица отслеживания, чтобы убедиться, что каждому требованию соответствует соответствующий сценарий тестирования.
• Шаг 5: Созданные сценарии проверяются вашим руководителем. Позже они также рассматриваются другими заинтересованными сторонами в проекте.

Советы по созданию тестовых сценариев

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

Пример 1. Сценарий тестирования для приложения электронной коммерции

Для приложения электронной коммерции несколько тестовых сценариев

Тестовый сценарий 1: проверка функциональности входа

Чтобы помочь вам понять разницу между сценарием тестирования и тестовыми сценариями, для этого сценария тестирования будут использоваться конкретные тестовые сценарии.

1. Проверьте поведение системы при вводе действительного адреса электронной почты и пароля.
2. Проверьте поведение системы при вводе неверного идентификатора электронной почты и действительного пароля.
3. Проверьте поведение системы при вводе действительного адреса электронной почты и неверного пароля.
4. Проверьте поведение системы при вводе неверного идентификатора электронной почты и неверного пароля.
5. Проверьте поведение системы, если адрес электронной почты и пароль оставлены пустыми и введен вход.
6. Проверить Забыли пароль работает как положено
7. Проверьте поведение системы при вводе действительного / недействительного номера телефона и пароля.
8. Проверять поведение системы, когда установлен флажок «Держать меня в подписи»

Как видно, тестовые случаи являются более конкретными.

Тестовый сценарий 2. Проверка функциональности поиска

Важность тестирования программ

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

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

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

И главный вопрос, который возникает в данной ситуации: “Как?” Как ускорить процесс тестирования без ущерба качеству? Как не попасть в ловушку человеческого фактора и банально не забыть протестировать смежные блоки?

Одним из вариантов решения данной проблемы является автоматизация процессов тестирования. 

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

Речь пойдет о трех видах тестирования: формальное, функциональное и регрессионное. И они будут рассмотрены со стороны процесса тестирования: ручного и автоматического.

Автоматизация тестирования в 1С

Рассматривая данные виды тестирования с точки зрения ручного и автоматизированного процесса тестирования необходимо учитывать стадию разработки тестируемого объекта или блока. Либо это новый разрабатываемый объект или блок, на который ещё не написан автоматизированный тест, либо стабильный протестированный объект или блок, у которого уже есть автоматизированный тест и в который вносятся доработки.

Если объект или блок новый и находится на стадии разработки, то сперва его стоит протестировать формально и функционально вручную. Это необходимо, чтобы понять, какие требования предъявлены объекту или блоку, как правильно он должен работать и, главное, чтобы подготовить план его тестирования. Как говорится, «пощупать на практике».

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

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

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

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

Теперь давайте поговорим про инструменты автоматизации процессов тестирования. Для тестирования программных продуктов в среде «1С» можно выделить два инструмента:

• 1С:Сценарное тестирование, ред. 3.0 — конфигурация от фирмы «1С».
• Vanessa ADD (Automation Driven Development) — open-source проект, являющийся результатом объединения фреймворков xUnitFor1C (дымовое и юнит-тестирование) и Vanessa-Behavior (сценарное тестирование и BDD). Может применяться в связке с 1С:СППР.

В рамках данной статьи будет рассмотрен вариант работы с решением «1С:Сценарное тестирование» по нескольким причинам:

• Решение разрабатывается и находится на постоянной поддержке со стороны фирмы «1С».
• Включает в себя обширный функционал для организации автоматического тестирования.

Использование конфигурации «1С:Сценарное тестирование» для автоматизации процессов тестирования

Основные принципы работы решения

Конфигурация устанавливается обычным способом для всех решений фирмы «1С»: установка шаблонов и развертывание информационной базы из них. Далее в конфигурации необходимо завести пользователей и произвести первоначальные настройки. Целью данной статьи не является полное описание настроек конфигурации для дальнейшей работы, потому не будем останавливаться на данном моменте. Узнать более подробно об первоначальной настройке конфигурации можно в документации на ИТС (https://its.1c.ru/db/kip#content:66:hdoc) и в обучающих видео (https://www.youtube.com/channel/UCbdRui0PGMp9lqhvnVJcRzA) от разработчиков данной конфигурации.

Итак, где же можно создавать сценарии тестирования

Непосредственно в конфигурации «1С:Сценарное тестирование» средствами встроенной обработки для написания сценариев тестирования, либо в любой другой информационной базе используя внешнюю обработку.

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

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

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

В конфигурации «1С:Сценарное тестирование» создание сценариев тестирования происходит непосредственно из справочника Тесты, на закладке Сценарии. По кнопке Создать вызывается обработка для написания сценариев тестирования.

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

Сохраняется два вида обработок: «старая» с именем STest_<номер_версии_СцТ>.epf и интерактивная iSTest_<номер_версии_СцТ>.epf с префиксом «i» в начале имени файла.

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

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

Чем удобнее пользоваться: встроенной или внешней обработкой? Это зависит от поставленных целей. Если, например, необходимо продемонстрировать работу сценария тестирования или проверить работоспособность конфигурации на рабочем месте, где нет доступа к базе «1С:Сценарное тестирование», то удобнее пользоваться внешней обработкой и файлами сценариев. При редактировании сценария тестирования во внешней обработке его легко можно загрузить и обновить в конфигурации «1С:Сценарное тестирование».

При написании сценариев непосредственно в базе «1С:Сценарное тестирование» они сразу создаются и хранятся в ней.

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

Загрузка сценариев тестирования в конфигурацию «1С:Сценарное тестирование» необходимо для их хранения, компоновки в пакеты и запуска данных пакетов по регламенту.

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

Способы написания сценариев тестирования: «накликивание», предопределенные шаги или универсальные макрошаги?

Для ответа на вопрос: «Как писать сценарии тестирования?», необходимо предварительно разобраться с понятиями: сценарий тестирования, шаг сценария и типов шагов.

Отдельно стоит выделить групповой шаг проверки бизнес-логики, который позволяет проверять как правильность заполнения объекта, так и его записи по регистрам.

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

Теперь, когда понятно, что сценарий тестирования состоит из шагов разного типа, перейдем к теме написания сценариев тестирования и рассмотрим подходы к созданию сценариев тестирования.

Выделим три способа написания сценариев. Два способа предлагается самой обработкой для написания сценариев, а третий способ — авторская разработка:

• автоматическая запись сценариев по журналу действий пользователя;
• создание сценария тестирования вручную с использованием предопределенных шагов;
• создание сценария тестирования вручную с использованием универсальных макрошагов.

И рассмотрим данные способы с позиции двух, на наш взгляд, основных критериев:

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

Первый способ — использование автоматической записи сценариев по журналу действий пользователя

Автоматическая запись сценариев по журналу действий пользователя или «накликивание» достаточно простой и понятный способ работы со сценариями тестирования. Суть данного способа заключается в последовательном выполнении нескольких действий:

• Вызов в новом сценарии тестирования журнала действия пользователя;
• Включение записи;
• Переход в тестируемое приложение;
• Выполнение действия, которые необходимо записать;
• Остановка записи.

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

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

Главным достоинством данного способа является именно скорость и простота создания сценариев тестирования: пользователь просто записывает выполнение своих действий на клиенте тестирования, а обработка преобразовывает их в шаги сценария тестирования.

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

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

Второй способ — использование предопределенных шагов

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

Необходимые шаги добавляются в сценарий тестирования вручную.

Как уже было сказано, количество шагов в «старой» и интерактивной обработках отличается, но в основных шагах они схожи. Ниже рассмотрены типы шагов «старой» обработки.

Обработка предоставляет возможность работы со следующими типами шагов:

• интерактивные шаги для работы с формой;
• интерактивные шаги для работы с таблицей;
• интерактивные шаги для работы с табличным документом;
• общие шаги проверки бизнес-логики;
• общие интерактивные шаги;
• общие шаги.

Каждый шаг имеет собственную форму настройки, а ее внешний вид зависит от типа настраиваемого шага.

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

Скорость написания сценария тестирования при помощи предопределенных шагов медленнее, чем в предыдущем способе. Особенно на первоначальной стадии изучения работы обработки. Но это вопрос практики. С каждым новым сценарием скорость написания возрастает. И несмотря на большое количество предопределенных шагов в их настройке можно легко разобраться, так как заложен единый принцип их заполнения.

Зато сценарии тестирования сразу создаются структурированными, более точно и тонко настроенными. Соответственно их проще и быстрее редактировать, при внесении изменений.

Третий способ — использование универсальных макрошагов

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

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

Каждый универсальный макрошаг содержит перечень предопределенных параметров, которые условно делятся на два типа:

• Параметры настроек — указывается путь к внешним файлам, действия, которое нужно совершить с элементом и т. д.
• Параметры реквизитов — указывается имя элемента из конфигуратора или предприятия, с которым подразумевается произвести действие на форме.

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

• Переход в подсистемы и открытие формы списка объектов.
• Изменение реквизитов на формах объектов.
• Поиск в динамическом списке.
• Закрытие всех или конкретного активного окна формы.
• Нажатие любой кнопки на форме, в том числе декораций и гиперссылок командного интерфейса.
• Сравнение табличных документов.

Какие плюсы универсальных макрошагов можно отметить?

• Скорость заполнения одного макрошага
  Макрошаги составлены таким образом, чтобы была возможность выполнять однотипные действия в пределах одной итерации. К примеру, заполнение элементов на форме происходит циклически и не требует постоянного добавления одного и того же шага на каждый элемент. Это сокращает время на поиск формы, поиск самого элемента и т. д.
• Логика заполнения параметров универсальных макрошагов
  Параметры структурированы логической цепочкой, которая позволяет быстро выстраивать алгоритм необходимых действий.
• Меньше лишних действий
  Макрошаги дают защиту «от дурака», когда пользователю нужно оперировать только элементами и необходимыми для его заполнения значениями, не задумываясь как именно макрошаг будет его выбирать и подставлять.
• Количество универсальных макрошагов
  Их всего шесть, в них тяжело запутаться.
• Компактность сценариев тестирования
  Один универсальный макрошаг может покрыть проверкой форму одного объекта, так как в значениях параметров возможно сразу указать несколько элементов формы.
• Дополнительные возможности
  Во-первых, это гид по форме, который позволяет видеть структуру проверяемой формы, копировать из него необходимое имя элемента или по двойному клику на элементе автоматически создавать требуемый универсальный макрошаг с предзаполненными параметрами и значениями в них.
  Во-вторых, это возможность автоматической замены синонимов объектов во всех параметрах макрошагов сценария тестирования (см. Полезные доработки).

Данные плюсы, при минимальной практике, позволяют довольно быстро создавать и редактировать сценарии тестирования.

Организация тестирования 1С:Общепит

Организации тестирования типового отраслевого решения состоит из трех этапов:

• Документирование, то есть создание описания плана тестирования и ведение реестра созданных сценариев тестирования.
• Написание и отладка сценариев тестирования в обработке.
• Создание пакетов тестирования и запуск их вручную или по расписанию.

Пройдемся подробнее по каждому из этапов.

Документирование — реестр и описание созданных сценариев тестирования

В первую очередь в отдельной электронной таблице формируется реестр объектов и блоков, которые планируется протестировать и вносятся соответствующие им написанные сценарии тестирования.

Реестр сценариев — список наименований сценариев тестирования, сгруппированный по определенному принципу, с возможностью отслеживать статусы написания/изменения и глубины раскрытия конкретного сценария тестирования.

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

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

• предусловие,
• сценарий тестирования,
• результат.

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

После того, как сценарий был внесен в реестр и описан, начинается его создание.

Написание сценария тестирования с использованием универсальных макрошагов

Наши сценарии тестирования обязательно включают в себя два важных блока:

• Ряд последовательных шагов, которые приводят к открытию или созданию объекта.
• Групповой шаг проверки бизнес-логики, который является следствием и венцом правильности проверки объекта.

Для написания сценариев тестирования нами используется «старая» обработка.

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

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

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

Здесь следует отметить, что запуск менеджера тестирования и тестируемого клиента происходит под толстым клиентом. Такой режим работы необходим для универсальных макрошагов, использующих методы и объекты, доступные только на толстом клиенте. Так для проверки правильности создания печатных форм используется объект СравнениеФайлов, доступный только на толстом клиенте.

После установки соединения приступаем к написанию сценария тестирования.

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

Универсальный макрошаг чем-то напоминает абстрактный объект, который в зависимости от входных параметров принимает нужное нам значение. В качестве примера можно привести дверь. Двери бывают разных форм, цветов и изготавливаются из различных материалов. Наш универсальный макрошаг, в данному случае, и есть дверь, а то какой она будет формы, цвета и из какого материала определяется входящими в него параметрами и их значениями.

Сам универсальный макрошаг состоит из клиентской процедуры, в которой есть возможность параметризации.

И текста процедуры исполняемого на стороне менеджера тестирования.

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

• КоличествоДобавляемыхСтрок — количество добавляемых строк в табличную часть объекта. Относится к элементу управления табличные части. Заполняется, если необходимо работать с табличной частью объекта.
• Области — области объекта, в которых расположены элементы управления по названию из конфигуратора. Областью являются Шапка объекта, Вкладки. Есть возможность указать несколько областей через точку с запятой. Если область не указывается, то она игнорируется.
• ПроверятьОткрытиеСервисныхОкон — для закрытия типовых сервисных окон, принимает значение Да или Нет. В значении Нет проверка на открытие сервисных окон не происходит. В значении Да закрывает служебные сервисные сообщения нажатием на кнопку ДА в окне сообщения.

  

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

После добавления основных параметров производим заполнение значений параметров используя Гид по форме (см. Полезные доработки). Каждому исполняемому параметру, в зависимости от его типа, проставляется соответствующий префикс, что существенно облегчает поиск необходимого элемента на форме клиентского приложения.

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

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

Дальнейшее заполнение сценария универсальными макрошагами происходит в аналогичном ключе.

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

Добавление бизнес-логики происходит посредством создания группы, где можно выбрать отдельный объект для работы с ним.

После того как групповой шаг бизнес-логики добавится необходимо выбрать тип исследуемого объекта и сам объект.

На текущем этапе появляется проблема, которую рядовой тестировщик не всегда в состоянии решить. В случае, когда выбирается конкретный объект, программно формируется запрос и фиксирует поиск самого объекта по конкретным значениям.

На картинке видно, что фиксируется дата создания документа. В случае, если мы попробуем запустить этот тест завтра, то сформированный документ просто не будет найден. Решить данную проблему помогает привязка к уникальным идентификаторам у объекта. Как пример, можно осуществлять поиск по номеру документа в упорядоченном по убыванию списке. Либо же привязаться к уникальному комментарию в объекте.

В нашем случае запрос упрощается на порядок, осуществляя поиск последнего сформированного документа. Далее становясь на группу бизнес-логики по кнопке Добавить увидим, что появился набор дополнительных шагов.

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

На картинке выше показана форма структуры объекта, в которой возможно управлять отбором реквизитов, по которым необходимо сравнивать объект после его формирования.

На картинке выше можно видеть итоговый результат, состоящий из четырех универсальных макрошагов и одной проверки бизнес-логики для сформированного документа.

Отдельным этапом проверки документа можно выделить сравнение табличных документов. Был разработан отдельный универсальный макрошаг, осуществляющий сверку двух табличных документов на стороне менеджера тестирования при помощи объекта СравнениеФайлов.

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

Данный универсальный макрошаг может выполняться в двух режимах:

• Без логирования, когда результаты сравнения выводятся сразу на экран в менеджере тестирования. Данный режим удобен для использования на этапе создания сценария и его отладки.
• С логированием, когда результаты сравнения выводятся в файл лога. Данный режим удобен для использования при пакетном выполнении.

Для более наглядного примера логирование в примере выше отключено. Это значит, что в случае наличия различий в печатных формах будет выведено соответствующее окно сравнения двух табличных документов.

Загрузка, хранение и пакетный запуск сценариев тестирования

Сценарии тестирования пишутся нами во внешней обработке и сохраняются в файлы формата xml или zip. Для дальнейшего использования их необходимо загрузить в базу «1С:Сценарное тестирование».

Для чего это надо?

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

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

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

Загрузка сценариев тестирования происходит непосредственно в справочнике Тесты на закладке Сценарии по кнопке Создать из файла.

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

После того, как сценарии тестирования загружены в конфигурацию «1С:Сценарное тестирование» можно создавать пакеты. Для этого переходим в справочник Пакетное выполнение и создаем пакет по кнопке Создать.

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

Шаги можно условно поделить на вспомогательные, такие как работа с предприятием, конфигуратором, файлами, служебные действия и непосредственное выполнение интерактивных сценариев.

В своих пакетах мы используем следующие шаги:

• Группа подключения к базе, развернутой на сервере «1С» — в ней указывается расположение и параметры подключения к заранее вручную развернутой серверной базе.
• Загрузка в нее эталонной ИБ — загрузка файла dt, расположенного по указанному пути. Эталонная база — это база, в которой уже предопределены необходимые настройки и есть минимальные данные для отработки сценариев тестирования.
• Обновление ИБ файлом cf — обновление эталонной базы заранее сохраненным файлом cf с актуальными изменениями конфигурации.
• Запуск тестируемого приложения — запуск эталонной базы с параметром клиента тестирования.
• Выполнение интерактивных шагов сценариев тестирования — перечень интерактивных сценариев для выполнения.
• Закрытие тестируемого приложения — закрытие эталонной базы.

Пакет можно запускать двумя способами:

• Вручную по кнопке Выполнить. При этом протокол выполнения данного пакета можно посмотреть на одноименной вкладке Протоколы выполнения.
• Автоматически по расписанию. При этом происходит автоматическая рассылка протокола выполнения для всех указанных пользователей.

Для того, чтобы пакет запустить по расписанию, мы используем планировщик заданий Windows и командную строку для запуска.

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

Настройка планировщика заданий Windows подразумевает указание расписания и два действия, расположенных в определенной последовательности для правильной логики работы:

• Запуск bat-файла для создания актуального cf, который далее будет загружаться шагом пакета Обновление ИБ файлом cf.
• Запуск пакета.

Bat-файл состоит из команд для выгрузки актуального cf из информационной базы, подключенной к хранилищу:

Стоит отметить, что эталонная база и база, из которой выгружается cf — это разные базы. Мы намеренно не делаем подключение эталонной базы к хранилищу, чтобы была возможность вернуться к первоначальному состоянию эталонной базы. У нас эталонная база — это всегда актуальный вышедший релиз.

При запуске пакета возможна рассылка оповещений о результатах тестирования. Мы сделали рассылку через отдельный электронный почтовый ящик. Настройку его можно осуществить в подсистеме Администрирование, Органайзер, Учетные записи электронной почты.

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

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

В наименовании пакета стоит указывать наименование решения, чтобы по заголовку письма было понятно к какому проекту относится протокол выполнения.

В протоколе возможно более подробно посмотреть какие шаги пакета были выполненными с ошибками и узнать причину данных ошибок.

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

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

Таким образом возникает потребность что-то добавить, удалить или упростить, адаптируя уже ранее написанный функционал под свои потребности и особенности.

Здесь мы хотели бы поделиться своим опытом доработок, упрощающих тестировщику работу в написании сценариев тестирования.

Гид по форме

Первой доработкой стала функциональность, позволяющая динамически отрисовывать дерево элементов активной тестируемой формы в отдельном окне на стороне менеджера тестирования. Она получила название Гид по форме. Первоначальная идея была заимствована с open-source проекта Vanessa ADD, который там называется Исследователь формы.

При более подробном изучении, оказалось, что и в интерактивной обработке для написания сценариев конфигурации «1С:Сценарное тестирование» тоже присутствует Исследователь.

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

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

Однако это не всегда действенно, когда речь заходит о большом количестве элементов на одной форме.

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

Специфика некоторых универсальных макрошагов подразумевает иерархический поиск необходимого элемента формы среди множества группировок. Необходимо сначала указывать область поиска (группу), после чего сам элемент. Иногда бывает сложно визуально в форме Гида определить к какой табличной части или группировке принадлежит тот или иной реквизит.

Данная проблема была решена посредством введения дух вещей:

• Динамической подсветкой родителя элемента.
• Добавлением поля реквизита Комментарий, в котором выводится имя выделенного реквизита с префиксом, помогающим идентифицировать тип элемента формы (таблица, группа, поле ввода или кнопка).

И последняя доработка, которая была на данный момент произведена — возможность автоматического создания универсального макрошага по двойному клику на любом из элементов «Гида по форме». Тип универсального макрошага будет зависеть от того, какой тип у элемента. Необходим универсальный макрошаг, который работает с табличной частью объекта — нажимаем на элемент табличной части. Необходимо работать с кнопкой — нажимаем на имя кнопки.

На текущий момент Гид по форме продолжает развиваться и дорабатываться, с каждым разом все больше упрощая тестировщикам процесс создания автотестов.

Замена синонимов в сценарии тестирования

Второй немаловажной доработкой можно назвать функционал замены синонимов объектов конфигурации на их актуальное представление в уже ранее сформированных сценариях тестирования.

Как уже описывалось ранее, при работе с элементами формы универсальные макрошаги могут использовать как заголовки (наименования), так и имена реквизитов из конфигурации. Однако в некоторых случаях оба способа не могут быть действительно стабильны или работоспособны в целом.

Обусловлено это тем, что некоторые элементы формы выстраивают свои наименования/имена динамически, в момент работы «1С:Предприятия» или же напрямую зависят от имени/синонима другого объекта конфигурации.

Так мы столкнулись с проблемой кнопок введения на основании. Наименование кнопки введения на основании здесь напрямую зависит от синонима того объекта, который мы хотим сформировать.

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

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

Решение проблемы оказалось достаточно тривиальным. За основу автозамены старого синонима в сценариях на новый был выбран подход мэппинг, позволяющий в отдельном файле хранить связку ИмяОбъекта — СинонимСтарый — СинонимНовый.

Мапирование (англ. data mapping, иногда маппинг, маппирование, мэппинг) — определение соответствия данных между потенциально различными семантиками одного объекта или разных объектов.(Википедия)

Решение задачи разделили на три этапа:

• Создание на стороне обработки сценарного тестирования отдельной формы для отображения структуры метаданных конфигурации и дальнейшей с ней работы.
• Запись/перезапись файла, где хранится связка объекта метаданных и его синонима.
• Перезаполнение синонимов в параметрах универсальных макрошагов.

Рассмотрим более подробно каждый из этапов:

На основную форму обработки были добавлены и вынесены два новых реквизита:

• Кнопка Синонимы метаданных, открывающая форму отбора метаданных.
• Реквизит Синонимы, куда подтягивается соответствующий файл, с которым нам предстоит работать.

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

По кнопке Сохранить всплывает диалоговое окно, позволяющее определить дальнейшую судьбу объектов и их синонимов в файле.

В случае ответа Нет, в файл добавляются только те объекты, которых там раньше не было и производится попытка поиска и замены старых синонимов в открытом сценарии на новые синонимы из файла, если они там присутствуют.

В случае ответа Да происходит ровно тоже самое за исключением того, что ранее установленные связи СтарыйСиноним‑НовыйСиноним исчезают, оставляя актуальным только последний существующий синоним.

Полномасштабное автоматическое тестирование — This Is the Way

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

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

Конечно можно еще предложить и вовсе не тестировать или тестировать частично, но это забег в пропасть. Мы выбираем путь профессионалов.

Если вам интересна разработка на платформе «1С:Предприятие», вы можете почитать другие статьи от экспертов «1С-Рарус»:

• Jenkins в разработке конфигураций «1С»
• Производительность нового RLS в 1С БСП 3. Переходить или нет?
• Оптимизация перезапуска рабочих процессов на платформе «1С» 8.3.15 и выше

И подписывайтесь на рассылку с новостями компании «1С-Рарус». Рассылка выходит один раз в 2 недели и содержит список актуальных мероприятий, которые мы проводим, и свежих публикаций на сайте.

Any capability that may be tested is defined as a TEST SCENARIO. It’s also known as Test Possibility or Test Condition. As a tester, you should put yourself in the shoes of the end user and determine the Application Under Test’s real-world scenarios and use cases.

In liner statements, a test scenario is a complete list containing test cases that cover end-to-end functionality of a software program. A scenario is defined as a liner statement. The test scenario is a classification of testable requirements at a high level. These criteria are categorized according to a module’s functionality and derived from use cases.

Because there are so many test cases in the scenario, there is a thorough testing process. The tester must evaluate the test cases for each scenario before completing the test scenario. Testers must put themselves in the shoes of the user in the test scenario because they are testing the software application from the user’s perspective. The most important aspect of the process is scenario preparation, which necessitates seeking advice or assistance from customers, stakeholders, or developers.

Important − Because the text scenario process does not include navigation steps or input, the test execution process cannot be done.

These are high-level documents that describe all of the conceivable permutations or various ways or combinations of utilizing the application, with the primary goal of understanding the application’s general flow.

Method of Writing Test Scenario

To build Test Scenarios as a tester, follow these steps —

• Examine the software’s requirement documents, such as SRS (System Requirement Specification), the BRS (Business Requirement Specification), and FRS (Functional Requirement Specification). You could also consult the application’s use cases, books, manuals, and other resources.

• For each requirement, determine all technical aspects and objectives.

• Find every feasible way for the user to interact with the software.

• Determine all possible scenarios in which the system could be exploited, as well as users who could be hackers.

• Make a list of various test cases to check each function of the software after reading the requirement document and completing the scheduled analysis.

• Create a traceability matrix after you’ve identified all of the possible test scenarios to see if each requirement has a matching test scenario or not.

• All possibilities are reviewed by the project supervisor. They are then evaluated by the project’s other stakeholders.

When writing test cases, we had to observe a few rules —

• Always keep a list of the most frequently utilized features and modules.

• We usually begin the scenarios by selecting modules one by one, in order to maintain a good sequence and avoid missing any module levels.

• Scenarios are usually defined at the module level.

• Delete scenario should always be the final resort; else, we will waste a lot of time re-creating data.

• It should be written in plain English.

• Every scenario should be written in a single or two-line format, try not to write in paragraphs.

• Do’s and checks should be included in every scenario.

Reason for creating Test Scenario

One test scenario can cover several test cases. As a result, Test Scenarios and Test Cases have a one-to-many relationship. However, the tester must consider each scenario when developing it. It was created by testers to test the application from the perspective of an end-user. Testers look for crucial information from all developers, stakeholders, and customers.

The following are the reasons for their creation −

• The design of excellent Test Scenarios ensures complete and proper Test Coverage.

• It is necessary to create them in order to investigate a program’s end-to-end functionality.

• They can be used to determine the most significant and critical end-to-end transactions or real-time application usage.

• They can be used as a tool for quickly determining testing workforce, which can then be utilized to assist clients or organizations with proposal creation and testing workforce organization efficiently and effectively.

• Approval of applications is done at multiple levels, including customers, business analysts, developers, and so on, to ensure thorough and proper testing.

When Test Scenario should not be created

There are some conditions in which its production should be prevented —

• It is unlikely to be developed in projects that use Agile Methodologies like Scrum.

• It may be avoided when the applications to be tested are unstable or excessively complicated, or when the project is in a critical-time state.

• Its creation may be prevented for regression testing or a new defect because substantial documentation of them would happen in previous test cycles in maintenance projects.

Features of Test Scenario

• The test scenario is a one-liner that directs testers through the testing process.

• The product’s complexity and repetition are reduced by using a test scenario.

• A test scenario is when you talk and think about tests in great detail yet write them down in liner statements.

• It’s a series of procedures threaded together.

• When the tester does not have enough time to write test cases and the team agrees on a comprehensive liner scenario, the test scenario becomes more significant.

• The test scenario is a useful activity for saving time.

• It is simple to maintain because adding and modifying test scenarios is simple and self-contained.

Test Scenario Examples

We’re using the Gmail application to create test cases for the most often used modules, such as Login, Compose, and inbox

Test Scenarios for the Login module

• Check that the home page is displayed after entering the correct login information (username and password).

• Check for the home page after entering the invalid Username and password.

• Check for an error message if you leave the username and password fields blank.

• Enter a valid Login, click Cancel, and look for the fields to be reset.

• Check that the account has been blocked by entering invalid Login more than three times.

• Check sure the Username is displayed on the home screen after entering a valid Login.

Test Scenario for compose module

• Checks if all users have access to the To, Cc, and Bcc email addresses.

• Check that the entire user has access to the To, Cc, and Bcc fields.

• Prepare a message, send it, and wait for a confirmation message.

• Compose an email, send it, and check the sender’s sent item as well as the inbox.

• Create a message, send it, and check for invalid and legitimate email addresses (valid format) in the sender’s inbox

• Check for conformation messages and check-in draft messages after composing main and then discarding it.

• After you’ve finished writing your email, save it as a draft and look for the confirmation message.

• Compose an email, shut it, and check for confirmation before saving it as a draft.

On the Inbox module, Test scenario.

• Check that all received mail is shown and highlighted in the inbox by clicking on it.

• Check that the sender email id for the most recent received email has been accurately displayed.

• Select the email, reply, and forward it; check the sender’s sent item and the receiver’s inbox.

• Examine any attached attachments to the email to see if they have been downloaded or not.

• Before downloading, be sure the attachment has been properly inspected for malware.

• Select the email, reply, and forward it, then save it as a draft. Check the Draft section for the confirmation message and checks.

• Check that all of the emails that have been marked as read have not been highlighted.

• Verify that all Cc recipients are visible to all users.

• Checks that all Bcc email recipients are hidden from the users.

• Select the message, delete it, and then check the Trash folder.

Any capability that may be tested is defined as a TEST SCENARIO. It’s also known as Test Possibility or Test Condition. As a tester, you should put yourself in the shoes of the end user and determine the Application Under Test’s real-world scenarios and use cases.

In liner statements, a test scenario is a complete list containing test cases that cover end-to-end functionality of a software program. A scenario is defined as a liner statement. The test scenario is a classification of testable requirements at a high level. These criteria are categorized according to a module’s functionality and derived from use cases.

Because there are so many test cases in the scenario, there is a thorough testing process. The tester must evaluate the test cases for each scenario before completing the test scenario. Testers must put themselves in the shoes of the user in the test scenario because they are testing the software application from the user’s perspective. The most important aspect of the process is scenario preparation, which necessitates seeking advice or assistance from customers, stakeholders, or developers.

Important − Because the text scenario process does not include navigation steps or input, the test execution process cannot be done.

These are high-level documents that describe all of the conceivable permutations or various ways or combinations of utilizing the application, with the primary goal of understanding the application’s general flow.

Method of Writing Test Scenario

To build Test Scenarios as a tester, follow these steps —

• Examine the software’s requirement documents, such as SRS (System Requirement Specification), the BRS (Business Requirement Specification), and FRS (Functional Requirement Specification). You could also consult the application’s use cases, books, manuals, and other resources.

• For each requirement, determine all technical aspects and objectives.

• Find every feasible way for the user to interact with the software.

• Determine all possible scenarios in which the system could be exploited, as well as users who could be hackers.

• Make a list of various test cases to check each function of the software after reading the requirement document and completing the scheduled analysis.

• Create a traceability matrix after you’ve identified all of the possible test scenarios to see if each requirement has a matching test scenario or not.

• All possibilities are reviewed by the project supervisor. They are then evaluated by the project’s other stakeholders.

When writing test cases, we had to observe a few rules —

• Always keep a list of the most frequently utilized features and modules.

• We usually begin the scenarios by selecting modules one by one, in order to maintain a good sequence and avoid missing any module levels.

• Scenarios are usually defined at the module level.

• Delete scenario should always be the final resort; else, we will waste a lot of time re-creating data.

• It should be written in plain English.

• Every scenario should be written in a single or two-line format, try not to write in paragraphs.

• Do’s and checks should be included in every scenario.

Reason for creating Test Scenario

One test scenario can cover several test cases. As a result, Test Scenarios and Test Cases have a one-to-many relationship. However, the tester must consider each scenario when developing it. It was created by testers to test the application from the perspective of an end-user. Testers look for crucial information from all developers, stakeholders, and customers.

The following are the reasons for their creation −

• The design of excellent Test Scenarios ensures complete and proper Test Coverage.

• It is necessary to create them in order to investigate a program’s end-to-end functionality.

• They can be used to determine the most significant and critical end-to-end transactions or real-time application usage.

• They can be used as a tool for quickly determining testing workforce, which can then be utilized to assist clients or organizations with proposal creation and testing workforce organization efficiently and effectively.

• Approval of applications is done at multiple levels, including customers, business analysts, developers, and so on, to ensure thorough and proper testing.

When Test Scenario should not be created

There are some conditions in which its production should be prevented —

• It is unlikely to be developed in projects that use Agile Methodologies like Scrum.

• It may be avoided when the applications to be tested are unstable or excessively complicated, or when the project is in a critical-time state.

• Its creation may be prevented for regression testing or a new defect because substantial documentation of them would happen in previous test cycles in maintenance projects.

Features of Test Scenario

• The test scenario is a one-liner that directs testers through the testing process.

• The product’s complexity and repetition are reduced by using a test scenario.

• A test scenario is when you talk and think about tests in great detail yet write them down in liner statements.

• It’s a series of procedures threaded together.

• When the tester does not have enough time to write test cases and the team agrees on a comprehensive liner scenario, the test scenario becomes more significant.

• The test scenario is a useful activity for saving time.

• It is simple to maintain because adding and modifying test scenarios is simple and self-contained.

Test Scenario Examples

We’re using the Gmail application to create test cases for the most often used modules, such as Login, Compose, and inbox

Test Scenarios for the Login module

• Check that the home page is displayed after entering the correct login information (username and password).

• Check for the home page after entering the invalid Username and password.

• Check for an error message if you leave the username and password fields blank.

• Enter a valid Login, click Cancel, and look for the fields to be reset.

• Check that the account has been blocked by entering invalid Login more than three times.

• Check sure the Username is displayed on the home screen after entering a valid Login.

Test Scenario for compose module

• Checks if all users have access to the To, Cc, and Bcc email addresses.

• Check that the entire user has access to the To, Cc, and Bcc fields.

• Prepare a message, send it, and wait for a confirmation message.

• Compose an email, send it, and check the sender’s sent item as well as the inbox.

• Create a message, send it, and check for invalid and legitimate email addresses (valid format) in the sender’s inbox

• Check for conformation messages and check-in draft messages after composing main and then discarding it.

• After you’ve finished writing your email, save it as a draft and look for the confirmation message.

• Compose an email, shut it, and check for confirmation before saving it as a draft.

On the Inbox module, Test scenario.

• Check that all received mail is shown and highlighted in the inbox by clicking on it.

• Check that the sender email id for the most recent received email has been accurately displayed.

• Select the email, reply, and forward it; check the sender’s sent item and the receiver’s inbox.

• Examine any attached attachments to the email to see if they have been downloaded or not.

• Before downloading, be sure the attachment has been properly inspected for malware.

• Select the email, reply, and forward it, then save it as a draft. Check the Draft section for the confirmation message and checks.

• Check that all of the emails that have been marked as read have not been highlighted.

• Verify that all Cc recipients are visible to all users.

• Checks that all Bcc email recipients are hidden from the users.

• Select the message, delete it, and then check the Trash folder.

< Предыдущее сообщение по теме обучения: Мысли об основах тестирования
> Следующее сообщение по теме обучения: Техники анализа классов эквивалентности и граничных значений

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

Определение тест дизайна

Итак, что такое тест дизайн?

Тут все кажется просто – это разработка или придумывание
тестов.

Тест можно определить как эксперимент, направленный на
проверку какого-то предположения или гипотезы.

Давайте приведем пример: что такое гипотеза, что такое тест,
проверяющий гипотезу, что такое разработка тестов.

Предположим, мы видим черный ящик и не знаем, что внутри:

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

• В ящике пусто
• В ящике лежит мяч
• В ящике лежит кот

Чтобы проверить каждое предположение, мы можем провести
несколько экспериментов (тестов):

• Поднять и взвесить
• Послушать
• Потрясти
• Открыть

Каждый тест либо подтверждает, либо опровергает наше
предположение.

Также можно сказать, что есть тесты разной степени
эффективности для разных предположений. Например, для того, чтобы подтвердить,
что кот в ящике, тест «Послушать» может нам ничем не помочь. Зато тест «Открыть
ящик» наверняка будет эффективнее.

Можно провести аналогию с тестированием программного
продукта. Гипотезы, которые мы можем проверять в этом случае:

• Программа работает неправильно
• Программа работает правильно
• Программа удобна
• Программа работает быстро

И возможные тесты по проверке будут такими:

• Проверить работу одной функции
• Проверить работу другой функции программы
• Проверить работу интерфейса
• Измерить время отклика программы на действия
  пользователей

Цели тест дизайна

Можно выделить главные цели тест дизайна: 

1. Придумать тесты, которые обнаружат
   наиболее серьезные ошибки продукта. Да, мы можем придумывать тесты,
   которые находят несерьезные ошибки, но тогда тестирование будет неэффективным. 
2. Минимизировать количество тестов,
   необходимых для нахождения большинства серьезных ошибок. Мы может
   придумать столько тестов, сколько не в состоянии будем выполнить. Поэтому
   перед разработчиками тестов всегда стоит задача – сохранить эффективность
   тестов (то есть их способность обнаруживать серьезные ошибки) без
   увеличения их числа.

Задачи тест дизайна

Например, в эту категорию входит:

• Написание тест кейсов
• Оценка и анализ рисков (то есть проблем, которые
  могут быть при использовании продукта)
• Создание списка приемочных проверок для нового
  функционала
• Анализ требований

Навыки тест дизайнера 

Разработка тестов – это непростое и длительное занятие,
которое требует серьезного погружения.

Если говорить о навыках, необходимых тест дизайнеру, можно
выделить:

• Умение
  разделять систему на составляющие (делать декомпозицию). То есть, нужно
  уметь видеть систему как целое, но и уметь раскладывать ее на составные части. Это
  очень полезный навык для проведения функционального тестирования, где проверяется
  каждая фича продукта.
• Умение
  собирать и анализировать требования к продукту. Если нет формально
  описанных требований – нужно уметь их собирать у разработчиков, у аналитиков, у
  пользователей.
• Умение
  расставлять приоритеты. Тест дизайнер
  должен уметь отличать более важное от менее важного, и расставлять приоритеты
  тестирования.
• Умение
  формулировать свои мысли (письменно и устно). Это умение важно для
  тестировщика в принципе. Тест дизайнеру оно здорово поможет при создании тест
  кейсов.
• Знание
  техник тест дизайна. Основные техники мы коротко обсудим в этом сообщении.
• Умение применять
  их на практике.

Важный вопрос, который мог у вас возникнуть: необходимо ли
тестеру знать, что такое тест дизайн, и уметь разрабатывать тесты?

Конечно, можно и без этого. В больших компаниях бывает так, что тесты пишут тест дизайнеры, а выполняют обычные тестеры.
Но неумением разрабатывать тесты вы
ограничиваете свое развитие в профессии. Для примера, посмотрите
список вакансий тестеров на hh.ru. Почти в каждом втором описании
требуется умение писать тесты.

Техники тест дизайна 

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

Давайте перечислим несколько основных техник тест дизайна:

• Разбиение
  на классы эквивалентности (это метод сокращения числа тестов путем выбора
  одного теста из эквивалентного набора)
• Анализ
  граничных значений (это метод проверки переменных программы на их границах)
• Функциональное
  тестирование (это проверка всех функций продукта, одна за одной)
• Тестирование
  на основе сценариев использования (это проверка продукта по наиболее частым
  и важным сценариям использования – use cases)
• Тестирование
  на основе рисков (это проверка важных проблем, которые могут возникнуть)
• Unit-тестирование
• Регрессионное тестирование
• Тестирование безопасности

Техник разработки тестов очень много, и каждый тестировщик
может придумать свою технику.

Например, есть довольно забавные техники:

• Партизанское тестирование – попытка найти ошибки
  в некоторой области программы, причем тесты выполняются быстрые и вредоносные.
• Есть еду своей собаки – когда продукт
  используется внутри самой компании, в повседневной работе.
• Тестирование глупой обезьяны – беспорядочное
  автоматическое тестирование, когда с клавиатуры вводятся случайные числа и мышь
  кликает по случайным местам экрана.
• Тестирование мыльной оперы – (http://www.logigear.com/logi_media_dir/Documents/Soap_Opera_Testing.pdf) – когда проверяются слегка усложненные и расширенные сценарии реального использования. Главное в одном сценарии проверить как можно больше всего, как в мыльной опере, в которой в одной серии может произойти столько событий, сколько умещается во всей жизни.

Классификация техник

А как можно классифицировать техники?

Считается, что каждая техника может заключать в себе
рекомендации по семи вопросам: 
1.      
Что тестируется?
2.      
Насколько тщательно?
3.      
Кем тестируется?
4.      
Какие проблемы ищутся?
5.      
Как тестируется?
6.      
Как оценивается результат тестов?
7.      
Есть ли определенная цель тестирования?

Но каждая техника обычно дает ответы не на все вопросы, а на
2-3. Остальные нюансы оставляет на наше усмотрение, то есть на усмотрение
тех, кто будет ее использовать.

В зависимости от того, по каким вопросам дает рекомендации
техника, все техники делят на разные категории: 

• Ориентированные на тестовое покрытие (отвечают
  на второй вопрос). Например, функциональное тестирование, разбиение на классы
  эквивалентности.
• Ориентированные на людей, которые выполняют
  тестирование (третий вопрос). Например, пользовательское тестирование, бета
  тестирование.
• Ориентированные на цель (седьмой вопрос).
  Например, верификация билда, приемочное тестирование пользователями,
  сертификация.
• И другие.

Давайте для примера рассмотрим несколько техник,
которые дают нам ответы на некоторые вопросы, но оставляют нам свободу выбора по
остальным.

• Функциональное
  тестирование. Техника говорит нам, что нужно тестировать функции (фичи)
  продукта, одну за одной, по очереди. Причем она рекомендует тестировать все
  функции. Насчет остального (кто выполняет тестирование, какие проблемы ищутся,
  как мы тестируем, как определяем результат тестов) – мы решаем сами. 
• Бета
  тестирование. Техника говорит нам, что тестирование лучше проводить в
  выделенной группе пользователей. Остальные вопросы – на наше усмотрение. 
• Unit-тестирование. Техника говорит нам, что тестируется каждая функция кода, тестирование обычно проводится программистом, тесты выполняются автоматически. Остальное (какие проблемы ищут unit-тесты, насколько они покрывают код) – мы вольны решать сами.

Техники черного и белого ящика

Наверняка, вы слышали про тестирование черного и белого
ящика. Иногда техники тестирования делят по этому признаку. Давайте коротко
обсудим, чем отличаются эти техники.

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

Однозначно сказать, какие техники (белого или черного ящика)
лучше – нельзя. ИМХО, самый хороший вариант – комбинировать эти техники, от этого
тестирование может стать намного эффективнее.

Исследовательское тестирование

Мне бы также хотелось рассказать вам о двух подходах к
тестированию:

• Исследовательском (эксплоративном) тестировании
• Тестировании по тест кейсам

Их очень часто противопоставляют друг другу в литературе по
тестированию.

Давайте начнем с исследовательского
тестирования:

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

Тестирование по тест кейсам

Теперь давайте рассмотрим второй подход, который очень популярен во всем мире – тестирование по тест кейсам (Scripted testing):

Это подход к тестированию, который предполагает формальное описание тестов в форме чеклистов или тест кейсов.

Что такое тест кейс?

Раз уж мы заговорили о тест кейсах, давайте обсудим, что это
такое.

Типичный тест кейс
состоит из следующих частей: 

• Цель.
  То есть, смысл тест кейса, что мы в нем проверяем.
• Предварительные
  шаги (опционально). Содержит список шагов, которые нужно выполнить до начала
  теста.
• Шаги.
  Это описанный по шагам алгоритм выполнения теста. 
• Ожидаемый результат (или результаты). Раздел, который содержит описание поведения продукта, которое мы должны наблюдать после выполнение шагов теста. По ожидаемому результату мы обычно определяем, прошел продукт тест или не прошел.

Также мы упомянули чеклисты.
Что это?

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

Плюсы и минусы эксплоративного тестирования и тестирования по сценариям

Давайте рассмотрим плюсы и минусы исследовательского тестирования
и тестирования по сценариям.

Исследовательское
тестирование: 

• Хорошо развивает навыки, дает тестеру больше
  свободы
• Не требует времени для написания тестовых
  сценариев, все время уделяется тестированию
• Поощряет изучение тестером продукта

Но:

• Неопытным тестерам в первое время бывает трудно
  из-за того, что они предоставлены сами себе, у них нет хотя бы примеров тестов,
  которые нужно выполнять
• Без тест кейсов сложнее оценить тестовое
  покрытие
• Изучение продукта отнимает время от
  непосредственного тестирования

Тестирование по
сценариям: 

• Требует меньше навыков от тестера, который
  выполняет тесты
• Дает возможность легче оценить тестовое покрытие
• Стабильность и неизменяемость тест кейсов дает
  возможность проследить качество продукта с течением времени
• Обеспечивает более структурированный подход к
  тестированию
• Как правило, выполнение тестов не требует дополнительных
  исследований и общения с разработчиками, аналитиками, работы со спецификациями,
  что дает выигрыш по времени

Но:

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

У обоих подходов есть плюсы и минусы. Отсюда можно сделать вывод:

Лучше всего
комбинировать эти два подхода вместе: использовать и исследовательское
тестирование, и тестирование по сценариям.

Например, можно использовать тестирование по тест кейсам для регрессионного тестирования, а новый функционал тестировать эксплоративно.

Что почитать по тест дизайну?

 

Но что-то новое в раздел литературы по тест дизайну я бы добавил:

• Practitioner’s
  Guide to Software Test Design (Lee Copeland) – очень полезная книга по тест дизайну. Она
  понятным языком описывает основные техники тест дизайна, собранные из разных
  источников. Рекомендую, написано интересно! 
• http://www.testingeducation.org/BBST/testdesign/ — сайт одного из курсов
  по обучению тестированию. Здесь есть видео, слайды лекций, статьи по тест
  дизайну. Рекомендую тем, кого не смущает английский язык.

Спасибо за внимание! Надеюсь, было интересно. Буду рад выслушать ваше мнение в комментах.

Подходы к разработке тестов

Рассмотрим разные подходы к разработке тестов, два к выбору тестовых данных и два к реализации тестового кода.

Тестирование спецификации

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

Пример использования спецификации требований для разработки тестов.

Пусть задан следующий фрагмент набора требований для модели обмена транзакциями:

1. Функция DoTransaction должна принимать адрес и данные в соответствии с параметрами, создавать в очереди новый элемент, заполнять его адресную часть и часть полей данных переданной информацией и инициировать транзакцию
2. Функция DoAddressTenure должна принимать адрес в соответствии с параметрами, создавать в очереди новый элемент и заполнять его адресную часть
3. Функция DoDataTenure должна принимать данные в соответствии с параметрами, находить в очереди первый элемент с частично незаполненными полями данных, дополнять его переданной информацией и инициировать транзакцию

Концептуальное описание набора тестов, проверяющего спецификацию, может выглядеть следующим образом:

1. Вызвать DoTransaction с адресом и данными. Проверить появление в очереди еще одного элемента. Проверить появление на шине транзакции с правильными адресом и данными.
2. Вызвать DoAddressTenure с адресом. Проверить появление в очереди еще одного элемента. Проверить отсутствие новой транзакции на шине.
3. Вызвать DoDataTenure с данными. Проверить заполнение полей данных. Проверить появление на шине транзакции с правильными адресом и данными

Тестирование сценариев

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

1. Определяется модель использования, включающая операционное окружение продукта и «актеров». Актером может быть пользователь, другой продукт, аппаратная часть и тому подобное, то есть все, с чем продукт обменивается информацией. Разделение на окружение и актеров условно и служит для описания оптимальных способов использования продукта.
2. Разрабатываются сценарии использования продукта. Описание сценария в зависимости от продукта и выбранного подхода может быть строго определенным, параметризованным или разрешать некоторую степень неопределенности. Например, описание сценария на языке MSC допускает задание параметризованных сценариев с возможностью переупорядочивания событий.
3. Разрабатывается набор тестов, покрывающих заданные сценарии. С учетом степени неопределенности, заложенной в сценарии, каждый тест может покрывать один сценарий, несколько сценариев, или, наоборот, часть сценария.

Использование сценариев не требует наличия полной формальной спецификации требований, но зато может потребовать больше времени на разработку и анализ.

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

Пример использования спецификации требований для разработки тестов.

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

1. Сценарий: пользователь имеет две независимые нити управления, одна из которых отвечает за генерацию полных транзакций посредством DoTransaction, а другая – за сбор транзакций из адресной части и части данных, когда эта информация приходит из разных источников. Таким образом, вторая нитка использует вызовы к DoAddressTenure и DoDataTenure.
2. Описание тестов: Вызвать DoAddressTenure c адресом А1, вызвать DoTransaction с адресом А2 и данными D2, вызвать DoDataTenure с данными D1. Проверить последовательное появление на шине двух транзакций: {А1, D1} и {А2, D2}

При выполнении этого теста было, в частности, обнаружено, что функция DoTransaction была реализована через вызовы к DoAddressTenure и DoDataTenure, что приводило к появлению на шине транзакций вида {А1, D2} и {А2, D1}. Подобный дефект может быть обнаружен с большим трудом, если разрабатывать тесты, основываясь только на спецификации требований.

Ручная разработка тестов

Наиболее распространенным способом разработки тестов является создание тестового кода вручную. Это наиболее гибкий способ разработки тестов, однако характерная для него производительность труда инженеров-тестировщиков в создании тестового кода не намного выше скорости создания кода продукта, а объемы тестового кода на практике зачастую превышают объем кода продукта в 10 раз. Учитывая этот факт, в современной индустрии все больше склоняются к более интеллектуальным способам получения тестового кода, таким как использование специальных тестовых языков (скриптов) и генерации тестов.

Генерация тестов

В настоящее время некоторые языки спецификаций, используемые для описания алгоритмов тестирования, могут быть использованы для генерации тестового кода. Рассмотрим генерацию кода из языка MSC. Тест, описанный выше, формализован на языке MSC (Рис. 9.3). Здесь каждая стрелка с пометкой DoTransaction, DoAddressTenure или DoDataTenure представлет собой вызов соответствующей функции продукта с передачей параметров. Стрелка checkTr соответствует проверке прохождения по шине транзакции с соответствующими параметрами. Каждая из стрелок диаграммы генератором тестов преобразуется в исполнимый код, при этом стрелкам, представляющим собой вызовы функций может соответствовать достаточно простой и маленький участок кода, вызывающий соответствующую функцию и проверяющий ее выходное значение на наличие ошибок.

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

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

Возможна куда более эффективная формализация MSC сценария для генерации тестов. Рис. 9.4 представляет другой способ формализации для теста, выполняющего те
же самые проверки.

В MSC на Рис. 9.4 проверки транзакций сгруппированы с порождающими их вызовами в отдельные фрагменты, а параллелизм, используемый при исполнении фрагментов, задан через Par – формальную конструкцию, применяемую для изображения параллелизма в языке MSC. При генерации тестов по диаграмме Рис. 9.4 тестовый генератор перебирает все возможные и неповторяющиеся варианты вызова тестируемых функций, сохраняя при этом корректность порядка проверок, что в данном примере дает три сгенерированных теста. Несложно видеть, что затраты на создание диаграммы Рис. 9.4 не сильно отличаются от затрат на диаграмму Рис. 9.3, в то время как количество тестов увеличивается в три раза.

Таким образом, использование методики генерации тестового кода по формализованным MSC диаграммам позволяет значительно поднять производительность тестирования, а также преобразовать формализацию (кодировку) сценариев в достаточно интеллектуальную деятельность.

Введение в тестовый сценарий

Тестовый сценарий — это комбинация двух слов, то есть теста и сценария. Тест представляет собой акт проверки или подтверждения, а сценарий представляет собой путешествие пользователя. Любая тестируемая функциональность называется сценарием тестирования. Сценарий тестирования может быть описан как проверка или подтверждение правильности поездки пользователя. Он будет в форме документов, содержащих все тестовые примеры, подробно написанные для проверки сквозной функциональности приложений. Это одна из высокоуровневых категорий требований, которые можно проверить. Это также известно как возможность тестирования или условия тестирования.

Зачем создавать тестовые сценарии?

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

Причина их создания заключается в следующем:

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

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

• Его нельзя создавать в проектах, следующих за гибкими методологиями, такими как Scrum и т. Д.
• Когда тестируемые приложения нестабильны или слишком сложны, или когда проект находится в критическом состоянии, его создания можно избежать.
• Его можно избежать для регрессионного тестирования или для новой ошибки, потому что в проектах технического обслуживания их тяжелая документация может произойти заранее в предыдущих циклах тестирования.

Как тестовые сценарии могут быть написаны?

Следующие шаги могут быть выполнены тестером для создания тестовых сценариев:

• Шаг 1: Документ о требованиях, таких как Спецификация бизнес-требований (BRS), Спецификация функциональных требований (FRS) и Спецификация системных требований (SRS) приложения, подлежащего тестированию, следует внимательно и тщательно прочитать. Руководства, книги, варианты использования и т. Д. Тестируемого приложения могут быть отнесены к тому же.
• Шаг 2: Все возможные цели и действия пользователя должны быть правильно определены для каждого требования. Все технические характеристики каждого требования также должны быть определены.
• Шаг 3: Все возможные причины взлома системы и оценки пользователя должны выполняться с точки зрения хакера. Оценка пользователя может быть выполнена путем нахождения всех возможностей пользовательского управления приложениями.
• Шаг 4: Полный список всех возможных тестовых случаев для проверки всех функциональных возможностей приложения должен быть составлен после полного прочтения документа с требованиями и завершения анализа.
• Шаг 5: После привлечения всех из них для проверки соответствия требования и его сценария тестирования должна быть создана матрица отслеживания.
• Шаг 6: Все созданные тестовые сценарии проверяются и оцениваются супервизором. Это также дополнительно проверяется всеми заинтересованными сторонами.

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

Примеры

Ниже приведены несколько примеров сценария тестирования.

Тестовый сценарий для интернет-магазина приложений Buykart

Сценарии тестирования, которые можно принять во внимание при проверке приложения для онлайн-покупок Buykart, следующие:

Тестовый сценарий 1: проверка работоспособности входа

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при вводе действительного идентификатора входа и действительного пароля можно проверить.
• Поведение приложения при вводе действительного логина и неверного пароля может быть проверено.
• Поведение приложения при вводе неверного логина и действительного пароля можно проверить.
• Поведение приложения при вводе неверного логина и неверного пароля можно проверить.
• Поведение приложения при входе путем ввода идентификатора входа без пароля можно проверить.
• Поведение приложения при входе путем ввода пароля без идентификатора входа можно проверить.
• Поведение приложения при входе в систему без ввода логина и пароля можно проверить.
• Поведение приложения при выборе забытого пароля.

Тестовый сценарий 2. Проверка функциональности поиска

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при поиске действующего товара.
• Поведение приложения при поиске недействительного продукта.

Тестовый сценарий 3: проверка деталей продукта

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе продукта.
• Поведение приложения продукта в списке пожеланий.
• Поведение приложения при добавлении товара в корзину.
• Поведение приложения при выборе опции «Купить сейчас».
• Поведение приложения при вводе неверного адреса.
• Поведение приложения при вводе действительного адреса.
• Поведение приложения при проверке нескольких вариантов оплаты.

Тестовый сценарий 4: проверка функциональности платежа

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе каждого варианта оплаты.
• Поведение приложения, когда выбран правильный способ оплаты.
• Поведение приложения при выборе неверного варианта оплаты.
• Поведение приложения при успешной оплате.
• Поведение приложения при отклонении платежа.

Тестовый сценарий 5: проверка функциональности деталей заказа

Тестовые случаи, которые можно рассмотреть для создания:

• Поведение приложения при выборе каждого заказа.
• Поведение приложения при выборе опции «Возврат товара».
• Поведение приложения при выборе опции отслеживания товара.
• Поведение приложения при выборе опции «Обзор продукта».

Вывод

Он служит надлежащим руководством для тестировщиков и помогает им сделать тестирование более эффективным и действенным. Это помогает уменьшить сложность тестирования и избыточность. Каждый тестовый пример написан подробно для лучшего понимания. Это очень экономит время для тестеров.

Рекомендуемые статьи

Это было руководство к тому, что такое тестовый сценарий. Здесь мы обсудим, как создавать тестовые сценарии на разных примерах. Вы также можете взглянуть на следующие статьи, чтобы узнать больше —

1. Стресс нестабильности работы
2. Мотивированный и посвященный
3. Что такое Agile Testing?
4. Как написать контрольный пример?