# Шаблон для тестирования Описание шаблона для создания сценариев тестирования. ## 🔍 Содержание тестового сценария **Тестовый сценарий** - представляет собой набор действий , выполняемых для проверки конкретной функции или функциональности вашего приложения. Тестовый набор содержит шаги теста, данные теста, предварительное условие, постусловие, разработанное для конкретного тестового сценария для проверки любого требования. - Каждый тестовый сценарий должен быть привязан как минимум к одному требованию (***ссылаться на конкретное требование***) или пользовательской истории в соответствии с методологией проекта. - Перед созданием тестового сценария, который проверяет несколько требований одновременно, убедитесь, что у вас есть тестовый сценарий, который проверяет это требование изолированно. - Избегайте создания слишком сложных тестовых сценариев, охватывающих несколько требований. :::info **✏️ Например:** **Номер или ID требования:** Req_Id_03 **Тестовый сценарий**: Проверка функциональности пополнения и вывода средств - **Сценарии и данные:** Пользователь зарегистрирован в системе под ID - 101 и имеет на балансе кошелька 100 токенов DAI. *Тестовые примеры:* - Проверить поведение системы при пополнении баланса с условием наличия средств на кошельке; - Проверить поведение системы при пополнении баланса с условием отсутсвия средств на кошельке; - Проверить поведение системы при выводе средств на кошелек с ненулевым балансом; - Проверить поведение системы при выводе средств на кошелек с нулевым балансом; - **Постусловие:** - При пополнении и выводе средств - балансы на кошельке и в системе должны эквивалентно меняться ::: :::warning :bulb: **Обратите внимание** - хотя заголовки и описания сценариев могут помочь идентифицировать тестовые примеры, рассмотрите возможность использования идентификационных номеров во всем проекте. Идентификационные номера могут помочь найти и изучить определенные тестовые случаи при использовании точной документации. ::: <br> ## 📋 Базовое описание тестового примера (составляющих <br>тестовый сценарий) **Тестовый пример** включает в себя конкретные переменные или условия, с помощью которых инженер-тестировщик может сравнить ожидаемые и фактические результаты, чтобы определить, функционирует ли программный продукт в соответствии с требованиями заказчика. 1. Описать цель теста, совершаемое действие или последоватедльность действий пользователя > **Например:** Получить ссылку на аватар пользователя 2. Указать в каком контексте исполняется тестируемая функция и с какими данными > **Например:** Для пользователя еще не установлен аватар 3. Указать ожидаемый результат работы функции(-й) > **Например:** Получение строки содержащей *http* ссылку на картинку с аватаром пользователя 4. Привести конкретные входные и, по возможности, прокомментировать выходные данные. Обозначить *успешное/неудачное* завершение работы. :::warning :bulb: **Обратите внимание** - чаще всего порядок действий в тестировании указывается при работе с пользовательским (графическим) интерфейсом или необходимости выполнения ряда функций, для достижения результата в данном сценарии. ::: :::info **✏️ Например:** **Идентификатор теста:** TU01 (Test Unit 01) **Сценарий примера**: Пополнить баланс в системе при наличии средств на кошельке - **Тестовые данные:** пользователь зарегистрирован и авторизован в системе. ID пользователя - **101**; Начальный баланс кошелька: **100 DAI** - **Порядок действий** 1. Ввести адрес токена для пополнения; 2. Ввести количество токенов к пополнению; 3. Отправить запрос на пополнение; 4. Проверить пополнение баланса в системе. - **Ожидаемый результат:** баланс пользователя в системе пополнится, а на кошельке эквивалентно уменьшится. - **Входные данные:** ```node= forceDelta.addToPayment("0x9908Ea27465af9d86dF38aCA16FFce67a3c33A1c", "100").then(console.debug) forceDelta.getBalanceInPayment("0x9908Ea27465af9d86dF38aCA16FFce67a3c33A1c").then(console.log) ``` - **Выходные данные:** ```node= 100.0 // Комментрарии: // Вывод соответсвует количеству токенов пополненных пользователем. // Тест отработал без ошибок. ``` ::: <br> ## 🌜 🌛 Избегайте дублирования тестовых сценариев Не повторяйте тестовые сценарии. Если для выполнения какого-либо другого теста требуется уже протестированный функционал, то вызовите тестовый пример по его идентификатору в качестве предварительного условия. :::warning **✏️ Например:** Для тестирования перевода средств внутри системы, необходимо пополнить баланс пользователя, но мы уже протестировали функционал пополнения и вывода средств. В данном случае в сценарий тестирования переводов, поместим предварительное условие: :::info **Номер или ID требования:** Req_Id_04 **Тестовый сценарий**: Проверка функциональности перевода средств - **Сценарии и данные:** Пользователь зарегистрирован в системе под ID - 101. Получатель зарегистрирован в системе под ID - 102. Согласно ***TU01*** пользовательский баланс в системе составляет 100 DAI. *Тестовые примеры:* - Проверить поведение системы при переводе средств другому пользователю; - Проверить поведение системы при пустом переводе другому пользователю; - Проверить ... - и.т.д - **Постусловие:** - При переводе средств - балансы на кошельке отправителя и получателя должны эквивалентно меняться. ::: <br> ## 💱 Работа с транзакциями В сценариях где происходят транзакции, необходимо указать: 1. Ссылку на транзакцию в сети или хеш транзакции, 2. Статус подтверджения транзакции (*прошла/отменена*). :::info **✏️ Например:** В ходе выполнения функции ниже, происходит транзакция: ```= forceDelta.activationPack(3).then(console.log) ``` При успешной транзакции пользователь получит об этом сообщение и сможет просмотреть данные по транзакции (номер блока, штамп времени, израсходованный газ, статус самой транзакции, адрес отправителя и.т.д.) [***Ссылка на транзакцию***](https://mumbai.polygonscan.com/tx/0x51994f004728816ad1c9f19921e7e24a66ef4a553f8db7e2e9626538aea378a8) ::: <br> ## 🧰 Используйте методы тестирования Различные методы тестирования могут помочь вам сэкономить время в процессе проверки. Некоторые из этих методов включают в себя: - **Анализ граничных значений:** этот метод проверяет границы для различных диапазонов значений. Например, вы можете определить, что конкретное поле всегда будет иметь номер, а не проверять поле для каждого отдельного типа ввода. - **Раздел эквивалентности:** Метод разделения эквивалентности делит поля на части, которые проверяют одинаковые типы значений. Например, после разделения полей на две группы вы можете использовать один тест для каждого поля, в котором используются числовые значения, и другой тест для каждого поля, в котором используются буквенные значения. - **Переход состояния:** Методы перехода состояния помогают разработчикам тестировать программное обеспечение, которое изменяет одно состояние полей (например, числовое) на другое (например, буквы). Этот метод может помочь запустить отдельные проверки для сценариев с несколькими изменениями, а не организовывать несколько тестов для каждого изменения. - **Предположение об ошибках:** Предположение об ошибках — это метод прогнозирования, который помогает сэкономить время во время тестирования. Это позволяет разработчикам предположить, что одна ошибка может привести к аналогичным другим.