Привет, ребята! Когда вы пишете тестовые наборы, сталкиваетесь ли вы с проблемой совместного использования тестовых наборов с членами вашей команды или использования нескольких цветов для тестовых наборов?
У меня есть решение для этих проблем, которое состоит в том, чтобы поддерживать ваши тестовые наборы в Лист Excel.

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

Преимущества использования тестовых наборов в таблицах Excel

  1. Легко обрабатывайте тестовые примеры на листе.
  2. Легко прикрепляйте ссылки.
  3. Легко делитесь листами с членами команды.
  4. Легко используйте несколько цветов на листе.

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

  • Если мы создаем тестовый пример для любого приложения, которое не принадлежит какому-либо конкретному модулю, тогда идентификатор будет начинаться как TEST_ID 1.
  • Если мы делаем тестовые примеры для какого-либо конкретного модуля, тогда ID будет использоваться как MOD_ID 1.
  • Если тестовый пример имеет более одного ожидаемого результата, мы можем использовать тестовые примеры как TEST_ID 1.1, TEST_ID 1.2 и т. д. Все эти тестовые примеры являются частью TEST_ID 1.

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

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

  1. Feature Of Product: это поле определяет характеристику продукта для того типа продукта, который мы используем. Основное преимущество сохранения этого поля заключается в том, что в будущем, если какие-либо требования изменятся, мы можем легко рассчитать, как это влияет на многие тестовые случаи, и мы изменим или удалим тестовые случаи.**
  2. Описание функции. В этом поле указывается, какую функцию мы будем тестировать при каких условиях.**
  3. Шаги для выполнения. Это шаги, которые необходимо выполнить в тестируемой системе, чтобы получить ожидаемые результаты. Шаги должны быть понятными и правильными. Они пишутся и выполняются в соответствии с последовательностью.**
  4. Ожидаемый результат. Это желаемые результаты выполненных шагов выполнения. Результаты должны быть четко определены для каждого шага. Он определяет, каковы спецификации и что мы получим от конкретной спецификации.
  5. Фактический результат. В этом поле отображается реальный результат после выполнения шагов выполнения в тестируемой системе. Если результат совпадает с ожидаемым результатом, мы можем написать, как и ожидалось.
  6. Пройдено/не пройдено: если результат соответствует ожидаемому, отметьте его как пройденный, а если результат не соответствует ожидаемому, отметьте результат как неудовлетворительный. Вы используете цвет для статуса. Используйте зеленый цвет для Pass и красный цвет для Fail.
  7. Комментарий. Этот столбец предназначен для дополнительной информации, например. если статус установлен на «невозможно протестировать», то тестер может указать причину в этой колонке.**

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

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

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

  • Резюме
  • Матрица прослеживаемости
  • Сводка. В этом разделе содержится сводка требований, таких как

1.1 Элемент: это поле содержит краткие описания элементов, которые будут протестированы.
1.2 Название продукта: содержит название продукта, который вы хотите протестировать.< br /> 1.3 Версия продукта: содержит версию продукта, которую вы хотите протестировать.
1.4 Предварительные требования: Предварительные требования — это требования к системе, которые
необходимо, прежде чем мы начнем тестирование. Предпосылками могут быть:

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

1.5 Предпосылки для изменения: изменения, которые не были необходимы раньше, но теперь необходимы для системы.
1.6 Критерии выхода: это поле содержит требования, которые должны быть выполнены< br />, чтобы объявить о завершении тестирования.
1.7 Сводка теста: это поле содержит статус продукта: сколько тестовых случаев пройдено, сколько не выполнено, сколько находятся на удержании или сколько являются недействительными и т. д.

Как показано на изображении ниже:

Идентификатор требования REQ_ID 1, охватываемый тестовым набором с идентификатором TEST_ID 1 и TEST_ID 2
Идентификатор требования REQ_ID 2, охватываемый тестовым набором с идентификатором TEST_ID 3, TEST_ID 4, TEST_ID 5

Преимущества использования матрицы прослеживаемости

  1. Легко определить недостающую функциональность.
  2. Легко покрыть все требования клиента.
  3. Убедитесь, что все требования выполнены разработчиками в тестовых примерах
  4. Если будет сделан какой-либо запрос на изменение, мы можем легко изменить его в тестовых примерах.

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

Первоначально опубликовано на https://www.loginradius.com.