Автоматизированное приемочное тестирование - интерфейс или API?

Я изучаю автоматическое приемочное тестирование в течение последних нескольких дней, узнавая о BDD и JBehave, FitNesse и Slim, Selenium и WebDriver и т.д.

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

Я должен спросить: какая альтернатива? Мартин, похоже, подразумевает, что тесты должны ударять по скрытому слою, который будет управлять бизнес-слоем приложения. Я понимаю, что для этого потребуется дополнительная работа, не говоря уже о том, что она откроет новый API, который необходимо будет защищать один раз в рабочей среде.

Может ли хватать бизнес-уровень через службы приложений?

Каков был ваш опыт?

Спасибо за обмен!

Ответ 1

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

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

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

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

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

В противном случае вам придется использовать пользовательский интерфейс для проверки этих вещей. Один из подходов заключается в использовании пользовательского интерфейса для тестирования дыма, чтобы ответить на следующий вопрос (ы): Является ли это программное обеспечение проверяемым? Подумайте об общих вещах, которые вам приходится тестировать каждый раз, когда вы получаете сборку от разработчика. Могу ли я войти в систему, я могу выйти из системы, появится ли главная страница, могу ли я сделать простой заказ? Выберите 5 или 6 из этих вещей и создайте автоматизированный набор тестов, чтобы проверить эти вещи. Используйте эти тесты как руководство относительно того, сколько функций вы действительно можете проверить через пользовательский интерфейс и насколько это полезно.

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

Ответ 2

К сожалению, вам нужны оба. В общем, вы хотели бы автоматизировать тесты бизнес-уровня с чем-то вроде фитнеса. Избегание пользовательского интерфейса в основном дает вам уверенность в том, что определенные бизнес-правила всегда работают. Автоматизация через пользовательский интерфейс может потребовать гораздо большего обслуживания. Но с другой стороны, поскольку большая часть пользовательского интерфейса использует механизмы, предоставляемые платформой (например, С#/Winforms), основная часть ваших тестов пользовательского интерфейса может быть только тогда, когда будут сделаны изменения, если вы хорошо охвачены другими типами тестов (например, бизнес-уровня), Автоматические тесты необходимо поддерживать и обновлять, но тесты UI, как правило, требуют дополнительного обслуживания и часто менее надежны с течением времени.

Ответ 3

Я решительно выступаю за использование неавтоматического режима автоматизации для приемочных испытаний. Проблема, с которой вы можете столкнуться, заключается в продаже идеи традиционным кодовым слепым тестировщикам, которые найдут концепцию не визуальной проверки критериев приемлемости неадекватной. Я предпочитаю средний путь, где критерии приемлемости проверяются двумя наборами тестов. Первый набор имеет чисто логическую направленность и, следовательно, реализован на уровне API/Service/Remote. Этот набор на 100% автоматизирован. Второй набор - это проверка пользовательского интерфейса того же требования. Мое личное мнение заключается не в том, чтобы автоматизировать второй набор по причинам, указанным в других ответах. Что касается слоя для написания тестов, это зависит от команды. Если команда действительно привержена качеству, они будут рассматривать это как важную часть разработки продукта. Однако, в реальном мире, это тяжелая продажа. Если это не будет открыто вызвано началом проекта, было бы сложно модифицировать такой интерфейс в запущенном проекте. Я бы предложил, если вы хотите внедрить автоматические приемочные испытания, сделайте это как можно раньше. По мере того, как возраст продукта возрастает, вероятность реализации таких хаков резко уменьшается.

Ответ 4

Я могу говорить только для тестирования пользовательского интерфейса, Q & A style:

A) Является ли наш пользовательский интерфейс уже стабильным или все еще может сильно измениться?

Стабильный - автоматизация приносит дополнительную ценность

Скорее всего, измените - не автоматизируйте, вы потратите больше времени на поддержание (повторение) этих тестов.

B) Наш пользовательский интерфейс стабилен, нужно ли автоматизировать как можно больше его возможностей?

Бог Нет!

1) Возьмите все тестовые скрипты (скажем, 100)

2) Решите, какие автоматы (80)

3) Сортируйте их по приоритету (блокировщики, критические, второстепенные)

4) Сначала автоматизировать блокаторы и критические (например, 20/80)

Посмотрите, как это работает, и автоматизируйте больше, если потребуется.

C) Какие еще факторы следует учитывать при автоматизации UI?

Все, как показано ниже (тестовая пирамида - это концепция, разработанная Майком Кон):

Ответ 5

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

Ответ 6

Что касается Mobile Automation, я считаю, что нам не нужен отдельный интерфейс для тестов, не связанных с пользовательским интерфейсом. В наши дни существуют способы написания кода с использованием шаблонов, чтобы код можно было тестировать модулем (например, внедрение зависимостей и способ предоставления даже частных методов, доступных в тестах. (Например, @VisibleForTesting).

Примечание: я еще никогда не писал тесты не-пользовательского интерфейса, и я никогда не использовал эту аннотацию. , но с нетерпением жду этого. Я просто хотел поделиться информацией о @VisibleForTesting, чтобы сломать представление о том, что нам нужны отдельные методы в качестве интерфейса для тестирования.) Несколько постов: https://medium.com/@vadimpushtaev/how-to-test-private-methods -4bc57d4410ff