Автоматическое приемочное тестирование - интерфейс или API? - PullRequest
14 голосов
/ 26 июля 2011

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

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

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

Может быть достаточно попадания на бизнес-уровень с помощью служб приложений?

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

Спасибо, что поделились!

Ответы [ 6 ]

14 голосов
/ 26 июля 2011

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

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

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

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

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

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

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

9 голосов
/ 26 июля 2011

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

3 голосов
/ 25 июня 2016

Я могу говорить только за тестирование пользовательского интерфейса, стиль вопросов и ответов:

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

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

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


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

Боже, нет!

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

2) Определите, какие из них являются автоматическими (80)

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

4) Сначала автоматизируйте блокирующие и критические (скажем, 20/80)

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


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

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

enter image description here

3 голосов
/ 02 апреля 2015

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

1 голос
/ 01 августа 2011

Создание интерфейса для тестирования - «мечта тестировщиков», но его включение / отключение станет кошмаром для развертывания. Вам могут потребоваться «тестовые сборки» и «развертывание сборок» с различными тестами дыма. Но любой компромисс хорош, если вы ограничиваете автоматизацию тестирования пользовательского интерфейса.

0 голосов
/ 21 мая 2019

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

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

...