Эволюция среды автоматизации тестирования

Инструменты автоматизации тестирования на основе сценариев существуют с начала 1990-х годов. Фактически, Visual Test 1.0 от Microsoft был выпущен в 1992 году. Многие из инструментов, которые у нас есть сейчас, восходят к той эпохе. Начиная с QTP, Rational Functional Tester, Winrunner и многих других, они используют различные виды инфраструктуры автоматизации тестирования графического интерфейса. Эта структура претерпела коренные изменения за последние два десятилетия. Они развивались, чтобы улучшить автоматизацию тестирования. Они разработаны для минимизации затрат на обслуживание, предоставляют проверенные и надежные сценарии тестирования и предлагают более простые способы разработки автоматизации тестирования. В этой статье мы ограничимся этой структурой и вернемся к тому, почему она канула в лету.

Запись и воспроизведение:

Хотя это не требует написания кода или требует минимального написания кода, простота управления кодом автоматизации делает запись / воспроизведение прибыльной только в небольших масштабах. Основная проблема этого подхода — проблема масштаба. Если нам нужен еще один автоматический тест, мы сохраним еще один сценарий, что в конечном итоге приведет к сохранению двух сценариев, поскольку интерфейс AUT со временем изменился. Чем больше тестов мы записываем, тем больше кода автоматизации необходимо поддерживать, что будет слишком тяжелым бременем для бюджета тестирования. Во время записи и воспроизведения каждый автоматический тестовый пример представляет собой последовательность операций с жестко закодированными тестовыми данными. Во-первых, это плохой подход к разработке программного обеспечения. Во-вторых, поворот в автоматизации начинается, когда мы воссоздаем ту же автоматизацию для тестирования последующих версий приложения. Однако при таком подходе каждый тест запускается один раз для каждого выпуска и не используется несколько раз для увеличения тестового покрытия. Следовательно, управление таким кодом автоматизации делает этот подход непрактичным для крупномасштабной автоматизации. Поэтому только ради затрат на обслуживание автоматизация тестирования вышла за рамки записи и воспроизведения.

На основании данных:

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

На основе ключевых слов:

Это выводит автоматизацию тестирования на новый уровень. Теперь не сценарий управляет тестированием, а сами тестовые данные. В тестовых данных используются ключевые слова для определения последовательности действий, которые необходимо выполнить. При запуске автоматизированного тестового примера он считывает тестовые данные и запускает соответствующий сценарий, указанный в ключевом слове, передавая AUT данные для этой строки. Следовательно, ключевые слова — это сценарии, написанные специалистами по тестированию для выполнения всех необходимых шагов для тестирования бизнес-задачи / функциональной задачи, для которой был написан этот сценарий. Благодаря такому подходу тестировщики имеют полный контроль над тем, что делать и в каком порядке. Но разработка кода автоматизации по-прежнему специфична для AUT. Скорость и количество изменений пользовательского интерфейса AUT, а также обслуживание сценариев. Следовательно, в случае крупномасштабной автоматизации тестирования нам все еще нужно найти способы уменьшить потребность в регулярном обслуживании скриптов.

На основе карты объектов пользовательского интерфейса:

Стремясь улучшить автоматизацию тестирования, платформа UI Object Map решает все три проблемы, связанные с автоматизацией тестирования. Это решает проблему ремонтопригодности, надежности и простоты создания тестовых сценариев. Эта структура берет инструкции из тестовых данных, распознает класс объекта, над которым нужно действовать, а затем выполняет указанное действие над этим объектом, вызывая сценарий для этого конкретного класса объекта, передавая ему действия и данные. Это означает, что сценарии больше не относятся к AUT, а относятся к классу объектов пользовательского интерфейса. Нет сценария для указанного экземпляра объекта, кроме класса объекта. После того, как вы напишете сценарий для класса объекта пользовательского интерфейса, вы можете повторно использовать его в любом проекте автоматизации, в котором используется этот класс объекта пользовательского интерфейса. С помощью этой структуры сценарии автоматизируют класс объектов пользовательского интерфейса. Каждый раз, когда AUT изменяется, необходимо изменять только карту объектов и данные, а не сценарии для класса объектов пользовательского интерфейса. Единственный раз, когда вам нужно изменить это, — это когда вы вводите новые объекты пользовательского интерфейса или меняете поведение существующих классов объектов пользовательского интерфейса.

Поделиться ссылкой:

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

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

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

Программное обеспечение для управления контактами по недвижимостиПрограммное обеспечение для управления контактами по недвижимости

Программное обеспечение для управления контактами в сфере недвижимости — это эффективный инструмент, предназначенный для профессионалов в сфере недвижимости, брокеров и агентов. Это поможет вам вести свой бизнес более эффективно и

Бизнес-аналитика и анализ первопричин с помощью CRM-решенийБизнес-аналитика и анализ первопричин с помощью CRM-решений

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

Автоматизация маркетинга и тенденцииАвтоматизация маркетинга и тенденции

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