Автоматическое тестирование - это важное действие по тестированию в течение жизненного цикла разработки программного обеспечения, поскольку оно может обеспечить быструю обратную связь с командой при разработке новой функции.
Это также снимает нагрузку с QA по многократному запуску регрессионных тестов, что экономит время QA, чтобы сосредоточиться на других действиях по тестированию.
Если все сделано правильно, автоматизация тестирования может быть очень полезной для команды. Приведенные ниже советы помогут вам получить максимальную отдачу от процесса и деятельности автоматического тестирования и укажут на подводные камни, которых следует избегать при запуске автоматизации тестов.
Избегайте сравнения ручного и автоматического тестирования. Оба они необходимы, поскольку каждый служит своей цели. Автоматические тесты - это набор инструкций, написанных человеком для выполнения определенной задачи. Каждый раз, когда запускается автоматический тест, он будет выполнять точно те же шаги, что и инструкции, и проверять только то, что требуется проверить.
С другой стороны, во время ручного тестирования мозг тестировщика задействован и может обнаружить другие сбои в системе. Шаги тестирования не обязательно могут быть одинаковыми каждый раз, поскольку тестер может изменять потоки во время тестирования; это особенно верно в случае исследовательского тестирования.
Основная причина, по которой вы хотите автоматизировать тест заключается в том, что вы хотите повторно выполнять тест при каждом новом выпуске. Если тест требуется выполнить только один раз, то усилия по автоматизации тестирования могут перевесить преимущества.
Регрессионные тесты необходимо выполнять повторно по мере развития тестируемого программного обеспечения. Это может занять очень много времени и быть скучной задачей для QA, чтобы выполнять регрессионные тесты каждый день. Регрессионные тесты - хорошие кандидаты для автоматизации тестирования.
Перед тем, как приступить к автоматизации тестов, всегда рекомендуется создавать тестовые наборы и сценарии. Это хороший дизайн теста, который может помочь в выявлении дефектов, автоматические тесты выполняют только дизайн теста.
Опасность перехода сразу к автоматизации заключается в том, что вы заинтересованы только в том, чтобы скрипт работал, и обычно автоматизируете только положительные и счастливые сценарии, а не думаете о других возможных сценариях, которые можно проверить.
Кроме того, не сокращайте объем тестирования только для того, чтобы тест прошел успешно или прошел успешно.
Одним из ключевых моментов автоматизированного тестирования является способность давать согласованные результаты, чтобы мы могли быть уверены, что что-то действительно пошло не так, когда тест не прошел.
Если автоматический тест проходит в одном прогоне и терпит неудачу в следующем прогоне без каких-либо изменений в тестируемом программном обеспечении, мы не можем быть уверены, вызван ли сбой приложением или другими факторами, такими как проблемы тестовой среды или проблемы в сам тестовый код.
Когда возникают сбои, мы должны проанализировать результаты, чтобы увидеть, что пошло не так, а когда у нас есть много противоречивых или ложноположительных результатов, это увеличивает время анализа.
Не бойтесь удалять нестабильные тесты из пакетов регрессии; вместо этого стремитесь к стабильным чистым результатам, на которые вы можете положиться.
Вы будете встревожены огромным количеством устаревших автоматических тестов, просто не проверяйте ничего или не проверяйте самые важные проверки!
Это может быть признаком того, что вы сразу переходите к автоматизации, не тратя достаточно времени на предварительное планирование того, что необходимо сделать, и на разработку хороших сценариев тестирования.
Всегда есть коллега, который проверяет автоматизированные тесты на валидность и вменяемость. Убедитесь, что тесты актуальны.
По мере разработки новой функции или функциональности многие вещи могут пойти не так, и даже функция может перестать быть применимой, потому что компания изменила свое мнение.
Если вы начали автоматизировать тесты во время разработки функции, тесты необходимо обновлять много раз по мере развития функции, и может быть довольно сложно не отставать от всех изменений. И если функция больше не применима, все усилия по автоматизации тестирования будут потрачены зря.
Поэтому всегда лучше автоматизировать функцию после того, как она стабилизирована и менее подвержена изменениям.
Основная причина автоматизации тестирования состоит в том, чтобы освободить время QA для интересного исследовательского тестирования и дать команде уверенность в том, что приложение все еще находится в хорошем состоянии по мере появления новых изменений.
Не ждите, что автоматизация обнаружит много ошибок . Фактически, количество ошибок, обнаруживаемых автоматизацией, всегда намного меньше, чем при ручном и исследовательском тестировании.
Автоматические регрессионные тесты могут дать команде чувство уверенности, потому что регрессионные тесты все равно должны проходить по мере появления новых функций. Команда начинает полагаться на тесты, и наличие хорошего набора регрессионных тестов может действовать как подстраховка.
Однако обратите внимание, что не все тесты автоматизированы или могут быть автоматизированы, поэтому всегда сопровождайте автоматизированные тесты исследовательским тестированием.
Иногда изменение в программном обеспечении не проходит проверку; однако, если все тесты проходят успешно, это означает, что дефект пропущен, а из-за отсутствия призыва к действию дефект остался незамеченным.
Быстрая обратная связь - одна из целей автоматизированных тестов, потому что разработчики хотят знать, работает ли то, что они разработали, и не нарушает ли текущая функциональность.
Чтобы получить этот быстрый цикл обратной связи, тесты необходимо автоматизировать на уровне компонентов или API, не полагаясь на пользовательский интерфейс.
Тесты, выполняемые в пользовательском интерфейсе, намного медленнее и подвержены ошибкам из-за изменений графического интерфейса. Другими словами, функциональность по-прежнему работает, как ожидалось, но тесты не проходят из-за изменений в пользовательском интерфейсе. Следовательно, тесты могут стать ненадежными.
Тесты можно автоматизировать на любом уровне: модуле, API, службе, графическом интерфейсе. Каждый слой служит разным целям для тестирования.
Модульные тесты гарантируют, что код работает на уровне класса, компилируется и логика соответствует ожиданиям. Тесты на этом уровне - больше проверка, чем валидация.
Тесты API или тесты интеграции гарантируют, что набор функций и классов может работать вместе, а данные могут передаваться от одного класса к другому.
GUI-тесты, с другой стороны, тестируют пользовательские потоки и пути. Как правило, мы не тестируем функциональность пользовательского интерфейса. Делать это нужно на нижних слоях.
Основная цель тестов пользовательского интерфейса - убедиться, что вся система работает в соответствии с некоторыми общими пользовательскими сценариями и вариантами использования. Тестирование на этом уровне - это скорее проверка, чем проверка.
На уровне пользовательского интерфейса мы автоматизируем сценарии, а не истории.
100% тестовое покрытие невозможно, так как могут быть миллионы комбинаций. Мы всегда выполняем подмножество возможных тестов. Тот же принцип применим к автоматическому тестированию.
Для создания автоматизированного сценария требуются время и усилия, а для того, чтобы «автоматизировать каждый тест», нам требуется много ресурсов и времени, что во многих случаях невозможно.
Вместо этого используйте подход, основанный на оценке рисков, чтобы определить, какие тесты следует автоматизировать. Чтобы получить максимальную отдачу от автоматизации, автоматизируйте только самые важные бизнес-кейсы и сценарии.
Кроме того, большое количество автоматических тестов увеличивает стоимость обслуживания и затрудняет обслуживание.
Еще одно замечание: не все тесты можно автоматизировать. Некоторые тесты очень сложны по своей природе, требуют множества последующих проверок системы и могут быть непоследовательными. В таких случаях лучше оставить эти проверки для ручного тестирования.
Методы тестирования, которые вы изучили в ISTQB, предназначены не только для ручного тестирования. Они также применимы к автоматизированному тестированию. Такие методы, как анализ граничных значений, разделение на эквивалентность, тестирование перехода состояний, парное тестирование, могут обеспечить множество преимуществ при автоматизированном тестировании.
Чтобы получить максимальную отдачу от автоматизированного тестирования, необходим хороший процесс контроля качества. Если процесс контроля качества носит хаотический характер и мы добавляем к этому хаосу автоматическое тестирование, все, что мы получаем, - это более быстрый хаос.
Попробуйте ответить на такие вопросы, как, что автоматизировать, Когда автоматизировать , Когда выполнять автоматизированные тесты, кто должен автоматизировать тесты, какие инструменты следует использовать для автоматизации тестирования и т. Д.
Эти советы основаны в основном на опыте тестировщика автоматизации и некоторых передовых методах, которым следуют другие.
Есть ли у вас какие-нибудь советы по автоматизации тестирования, которые можно добавить в этот список?