Home

Автор: Пол Гриззафи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Определения: стимул, ответ и проверки

Простыми словами, стимул – это действие, вызывающее реакцию. К примеру, удар по барабану вызывает появление звука; удар – это стимул.

В мире тестирования и автоматизации стимулы исходят из различных источников, например:

• Клик по кнопке
• Вызов API
• Ввод команды операционной системы.

Каждое из этих действий вызывает определенную реакцию.

Ответ – это реакция или результат применения стимула; это то, что появляется вследствие стимула. Следуя примеру с барабаном, звук – это реакция на стимул удара по барабану.

Если взять примеры стимулов выше, соответствующие ответы могут быть такими:

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

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

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

Для тест-примеров проверки могут быть такими:

• Перешел ли ты на правильную страницу после клика по кнопке?
• Получил ли ты правильные значения в ответном сообщении после API-вызова?
• Дала ли внешняя программа правильный результат в ответ на вызов операционной системы?

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

Внедрение: абстрагируйте свои шаги

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

Если вы мыслите на достаточно высоком уровне, вы можете абстрагировать свои шаги в поведения, например, "Добавить предмет в корзину" или "Оформить заказ". Возьмем "Добавить товар в корзину" в качестве примера и допустим, что ваш GUI поддерживается веб-сервисным API. В этом случае существует как минимум два способа добавления товара в корзину.

Концептуально можно написать примерно такой тест-скрипт:

cart.addAnItemToCart(item)

Assert.assertTrue(cart.contains(item))

Что интересно в этом псевдокоде – это вызов к addAnItemToCart. Этот метод можно реализовать, взаимодействуя с интерфейсом, или же вызывая соответствующее действие (действия) API.

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

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

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

Как смежные стеки могут помочь

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

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

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

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

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

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

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

Сколько проверок должно быть в скрипте?

Сердцевина автоматизации содержит некоторое количество проверок, но сколько это – "некоторое"?

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

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

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

К примеру:

• Скрипт 1: выполнить шаг А, проверить результат А.
• Скрипт 2: выполнить шаг А, выполнить шаг В, проверить результат В.
• Скрипт 3: выполнить шаг А, выполнить шаг В, выполнить шаг С, проверить результат С.
• И т. д.

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

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

Когда нужно использовать несколько проверок в одном скрипте

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

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

Помимо GUI-тестов, существуют ситуации в API и сообщениях, для которых подходит несколько проверок на тест. Например, вам нужно проверить несколько полей в ответе API. Можно написать тест, проверяющий поле 1, а затем тест для поля 2, и т. д. Да, на уровне сообщений это быстрые тесты, меньше секунды. Однако, если вам нужно проверить 60 полей, то вы добавите примерно 30 секунд к тестированию ответа. Скорее всего, вам понадобится проверять разные конфигурации этого ответа, а также другие ответы. Это может добавить множество минут к каждому прогону тестов. В этом случае имеет смысл писать несколько проверок для одного скрипта.

Проверки и детерминизм

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

Если вы не можете с уверенностью определить успех или неудачу, вы потеряете веру в вашу автоматизацию и данные, которые она дает. Следовательно, полезны только детерминистические проверки, верно? Не совсем.

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

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

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

Обсудить в форуме