Автоматизация процесса регрессионного тестирования в разработке программного обеспечения

Что такое регрессионное тестирование?

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

  • Когда код изменяется в соответствии с изменением потребности в требовании
  • При добавлении нового функционала
  • При устранении дефектов
  • При устранении проблем с производительностью

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

Давайте рассмотрим пример и то, как выполнить регрессионное тестирование в этой ситуации:
В начале проекта, если у нас есть шесть разработчиков и два тестировщика. Модель Agile настраивается каждые две недели для спринта. Все началось.
В первом спринте мы начинаем с базовых функций (например, около десяти функций), тестировщики начинают разрабатывать сценарии тестирования для тестирования (например, около 100 сценариев). Самый первый Спринт получает хорошую оценку от клиентов.
Во втором спринте разработчики продолжают создавать новые фичи — около 10, а тестировщики тоже делают то же, что и в первом спринте — со 100 новыми скриптами плюс 100 старых сценариев, которые необходимо повторно протестировать. Ну всего 200 скриптов, все еще на контроле.
В следующем спринте разработчикам необходимо сделать восемь новых функций и обновить две старые функции в связи с новыми требованиями клиентов. На этом этапе два тестировщика должны не только разработать тестовые сценарии для 8 новых функций, но также протестировать и обновить 200 старых сценариев. Вся реализация составляет около 300 сценариев. Вы чувствовали, что что-то не так?
В течение следующих нескольких спринтов три разработчика по-прежнему соответствуют количеству функций и изменяющимся требованиям, но с двумя тестировщиками количество сценариев, которые необходимо создать и обновить, намного больше. Усталость начинает распространяться. Нехватка времени и риск промахнуться все выше и выше. Возникает слишком много проблем.
Таким образом, автоматизация регрессионного тестирования позволяет тестировщикам проверять различные изменения и необычные случаи в производственной среде. Не все регрессии вызваны новыми функциями или последствиями рутинных исправлений ошибок; обновления базы данных или новые версии браузера также могут вызывать их. Регрессия также может быть проблемой с эффективностью и скоростью. Автоматизация тех случаев, которые являются стабильными и воспроизводимыми, позволяет специалистам по ручному тестированию тратить больше времени на тестирование различных сред и на объединение более сложных случаев на более высоком уровне.
Более того, регрессионный анализ является ключом к успеху. Он должен иметь дело с интеллектом, а не с тяжелой работой.

  • Наивысшая отдача: выполняйте тесты, которые способствуют лучшему покрытию требований, а затем любые другие…
  • Быстрое снижение риска: выполняйте тесты для самых важных требований, а затем для любых других…
  • Практически безопасно: выполните тесты для всех критических требований, а затем для любых других…
    Тем более, что часто ~20% тестовых случаев покрывают ~80% ценности для бизнеса.

Как улучшить автоматическое регрессионное тестирование?

Наиболее часто используются два подхода к автоматическому регрессионному тестированию: тестирование на основе данных и тестирование на основе ключевых слов.
Тестирование на основе данных — это платформа, в которой тестовые входные и выходные значения считываются из файлов данных (пулы данных, источники ODBC, файлы CSV, файлы Excel, объекты DAO, объекты ADO и т. д.) и загружаются в переменные в захваченных или написанных вручную сценариях. В этом подходе переменные используются как для входных значений, так и для выходных проверочных значений. Навигация по программе, чтение файлов данных и регистрация состояния теста и информации — все это закодировано в тестовом сценарии. Давайте рассмотрим простой пример управляемого данными сценария для настройки учетных записей администратора в системе:

private void Auto_ID_400_test()
{
     Common.InitializeWebDocument();
     DataInit.Init();
     BasePage.NavigateToHomePage();
     HomePage.NavigateToSettings();
     SettingBasePage.NavigateToBase();
     Base.AdminSection.AddNewAdmin(Data.Read("NewAdmin"));
}
public static void AddNewAdmin(DataTable dataTable)
{
     Report.Log(ReportLevel.Info, "Add new Admin:");
     OpenAddnewAdminPopUp();
     FillNewAdminData(dataTable);
     ConfirmAdmin(Read(dataTable.GetValue"NewAdminName"));
}

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

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

Подробнее об этом подходе см.

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *