Пол Гриззаффи, архитектор QE Automation, Cognizant Softvision

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

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

Итак, как мы должны использовать мягкие утверждения?

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

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

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

Итак, как мы решаем, когда нам не следует продолжать? В общем, если продолжение после ошибки утверждения не дает никакой ценности, мы должны вызвать сбой тестового сценария на этом утверждении. Например, в тесте графического интерфейса, если мы нажмем кнопку, которая должна привести нас на определенную страницу, мы можем написать утверждение, чтобы убедиться, что мы перешли на нужную страницу. Если это утверждение не выполняется, скорее всего, мы находимся не на нужной странице или веб-сайт вернул ошибку, например страницу 404. В любом случае продолжение других тестовых шагов, скорее всего, не принесет никакой пользы, потому что все, что мы пытались сделать на предполагаемой странице, не может быть сделано на реальной странице. Что еще хуже, некоторые из действий, которые мы хотели выполнить на предполагаемой странице, могут успешно выполняться на реальной странице, позволяя сценарию двигаться дальше; сценарий, скорее всего, потерпит неудачу позже в потоке, когда будет сложнее диагностировать проблему.

Резюме:

  • Если у вас есть одно условие утверждения, обычно правильным выбором является жесткое утверждение.
  • Если вы проверяете несколько связанных значений, подходящим кандидатом является мягкое утверждение.
  • Если после отказа условия X вы все еще хотите проверить условие B, подходящим кандидатом является мягкое утверждение.
  • Если после невыполнения условия X нет смысла проверять условие Y или выполнять последующие этапы тестирования, правильным выбором является либо использование жесткого утверждения, либо вызов функции мягкого утверждения «сбой тестового сценария, если мягкое утверждение не выполнено» сразу после Состояние Х.

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

Получите дополнительную информацию от наших инженеров и дизайнеров на нашем веб-сайте!