2010-04-27 5 views
8

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

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

+0

Звучит так, будто вы пытаетесь создать платформу тестирования, которая автоматизирует то, что делают ваши тестеры QA (тестирование GUI). У вас уже есть тестирование более низкого уровня (единица/интеграция)? Очень важно иметь их перед автоматизацией графического интерфейса. –

+0

Спасибо всем за ваши ответы. Они были очень полезны. Прямо сейчас я смотрю на Селен и Руби. Уверен, вы увидите, как скоро я напишу больше вопросов. – onesith

+0

Посмотрев на мой последний вопрос, я прищурился. Это должно быть «Когда», а не почему. еще раз спасибо. – onesith

ответ

2

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

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

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

+0

Он ответил, когда мне нужно автоматизировать. Все остальные дали мне отличную возможность использовать автоматизацию. – onesith

0

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

4

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

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

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

5

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

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

1

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

0

автоматическое тестирование может также эталонные и идентифицировать проблемы с UI ... , что вручную не может быть даже щелкнул thaaat быстро :)

0

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

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

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

2

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

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

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

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

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

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

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

2

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

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

0

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

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

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

0

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

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

Pre-requisites to start automation testing

How to plan test automation

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