Когда должна начаться автоматизация? - PullRequest
9 голосов
/ 28 апреля 2010

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

Можете ли вы назвать причины, по которым вы бы автоматизировали работу, даже если у вас есть ручные тестеры?

Ответы [ 12 ]

5 голосов
/ 28 апреля 2010

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

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

4 голосов
/ 28 апреля 2010

Вы автоматизируете, потому что нажатие «go» и ожидание результатов в течение 10 минут означает, что ваш тестер может выполнять другую полезную работу в течение этих 10 минут вместо того, чтобы сидеть с ребенком в приложении.

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

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

2 голосов
/ 29 апреля 2010

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

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

2 голосов
/ 28 апреля 2010

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

Я предпочитаю автоматизацию из-за часов (уже упоминалось) и потому, что по большей части вы знаете, что вы получите с этим.

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

2 голосов
/ 28 апреля 2010

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

Ручное тестирование также имеет свое место, но трудно быть столь же убежденным, что оно охватывает все должным образом, и, конечно, не так быстро, как автоматическое тестирование.

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

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

Также было бы очень трудно обеспечить, чтобы любые проверки «на глаз» результатов были такими же хорошими, какими они были раньше, поэтому проверки результатов должны быть автоматизированы. Но если вы собираетесь автоматизировать это, вы можете также автоматизировать все это. Это не сложно.

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

По моему опыту, вам нужно начать тестирование примерно за 2 часа до того момента, когда вы вдруг поймете, что должны были начать тестирование 2 часа назад:)

1 голос
/ 28 апреля 2010

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

0 голосов
/ 14 февраля 2017
  1. каждая компания должна автоматизировать свои тесты.
  2. Автоматизация регрессионных тестов.
  3. Следуйте методологии BDD и POM.
  4. Код должен быть многоразовым.
  5. код всегда должен быть независимым от машины.
  6. метод отчетности должен быть достаточно простым, чтобы владельцы проекта могли легко узнать о нем.
  7. интегрировать CI через JENKINS / cron.
  8. Автоматизация требует затрат на оборудование и времени на автоматизацию.
0 голосов
/ 25 декабря 2014

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

Ниже ссылки Может также помочь:

Предварительные условия для начала тестирования автоматизации

Как спланировать автоматизацию тестирования

0 голосов
/ 29 апреля 2010

Вы должны автоматизировать как можно скорее. Многие исследования показали, что чем позже обнаруживается дефект в цикле разработки, тем дороже его устранять. Как правило, автоматизация позволяет обнаруживать дефекты в кратчайшие сроки (при условии, что вы действительно запустите эти автоматизированные тесты как можно скорее).

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

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

0 голосов
/ 28 апреля 2010

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

Суммарное усилие по тестированию для ручного тестирования будет увеличиваться с квадратом размера программы: из-за повторного тестирования и повторного тестирования.

Если вы не автоматизируете, то не будете выполнять регулярное полное регрессионное тестирование.

...