Инструкция по проверке работы по

Способы тестирования программного обеспечения

Всем привет! Уже на следующей неделе мы запускаем новый поток по курсу «Автоматизация веб-тестирования». Этому и будет посвящен сегодняшний материал.

В этой статье рассматриваются различные способы тестирования программного обеспечения, такие как модульное тестирование (unit testing), интеграционное тестирование (integration testing), функциональное тестирование (functional testing), приемочное тестирование (acceptance testing) и т.д.

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

Тестирование: ручное или автоматизированное?

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

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

Автоматизированные тесты – это ключевой компонент непрерывной интеграции (Continuous Integration) и непрерывной доставки (continuous delivery), а также хороший способ масштабировать ваш QA процесс во время добавления нового функционала для вашего приложения. Однако в ручном тестировании все равно есть своя ценность. Поэтому в статье мы обязательно поговорим об исследовательском тестировании (exploratory testing).

Различные типы тестов

Модульные тесты

Модульные тесты считаются низкоуровневыми, близкими к исходному коду вашего приложения. Они нацелены на тестирование отдельных методов и функций внутри классов, тестирование компонентов и модулей, используемых вашей программой. Модульные тесты в целом не требуют особых затрат на автоматизацию и могут отрабатывать крайне быстро, если задействовать сервер непрерывной интеграции (continuous integration server).

Интеграционные тесты

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

Функциональные тесты

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

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

Сквозные тесты (End-to-end tests)

Сквозное тестирование имитирует поведение пользователя при взаимодействии с программным обеспечением. Он проверяет насколько точно различные пользователи следуют предполагаемому сценарию работы приложения и могут быть достаточно простыми, допустим, выглядеть как загрузка веб-страницы или вход на сайт или в более сложном случае – подтверждение e-mail адреса, онлайн платежи и т.д.

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

Приемочное тестирование

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

Тесты производительности

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

Тесты производительности по своей природе проводить достаточно затратно, но они могут помочь вам понять, какие внешние факторы могут уронить вашу систему.

Дымовое тестирование (Smoke testing)

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

Дымовые тесты могут оказаться полезными сразу после сборки нового билда для проверки на то, можете ли вы запустить более дорогостоящие тесты, или сразу после развёртывания, чтобы убедиться, что приложение работает нормально в новой среде.

Как автоматизировать тесты

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

Для автоматизации тестирования, вам для начала придется написать их на каком-то из языков программирования с использованием фреймворка для тестирования, который подойдет для вашего приложения. PHPUnit , Mocha, RSpec – это примеры фреймворков для тестирования, которые вы можете использовать для PHP, Javascript и Ruby, соответственно. В них есть множество возможностей для каждого языка, поэтому вам стоит немного позаниматься исследованием самостоятельно и проконсультироваться с сообществами разработчиков, чтобы понять, какой фреймворк подойдет вам лучше всего.

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

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

Исследовательское тестирование

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

Вопрос заключается в том, надо ли вообще в таком случае проводить ручное тестирование? Короткий ответ – да, и оно должно быть сфокусировано на том, что называется «исследовательское тестирование» (exploratory testing), которое помогает выявить неочевидные ошибки.

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

Заметка о тестировании

Перед тем, как закончить эту статью, я хочу поговорить о цели тестирования. С одной стороны, очень важно удостовериться, что пользователи смогут использовать ваше приложение («Я не могу войти в систему», «Я не могу сохранить данные» и т.п.), но с другой стороны не менее важно проверить, что ваша система не ломается при вводе неверных данных или неожиданных действиях. Вам нужно предвидеть, что произойдет, когда пользователь сделает опечатку, попытается сохранить неполную форму или использует неправильный API. Вам нужно проверить, сможет ли кто-то из пользователей легко скомпрометировать данные, получить доступ к тому или иному ресурсу, к которому у него не должно быть доступа. Хороший набор тестов должен попытаться сломать ваше приложение и помочь понять предел его возможностей.

И, наконец, тесты – это тоже код! Так что не забывайте о них во время code review, поскольку они могут быть последним этапом перед выпуском продукта на потребительский рынок.

По устоявшейся традиции ждем ваши комментарии и приглашаем всех на день открытых дверей, который уже 18 марта проведет наш преподаватель — ведущий автоматизатор в тестировании в Group-IB — Михаил Самойлов.

О чем речь? Тестирование программного обеспечения – это необходимый процесс в ходе разработки, во время которого выявляются все проблемы в работе софта. Какими бы классными не были программисты, ошибки будут всегда, поэтому необходима регулярная проверка.

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

Необходимость тестирования программного обеспечения

Перечислим классические программные ошибки:

• Пользователь вбивает в поле ответ на вопрос и жмет клавишу Далее программа завершает работу, а информация не сохраняется. То же самое происходит и при следующей попытке.
• Пользователь играет в шутер. Вдруг персонажи начинают странно двигаться, подергиваться и т.д. Сначала программа попросту не реагирует на нажатие клавиш, а потом и вовсе выдаёт «Game over».
• Пользователь заходит в личный кабинет интернет-магазина и нажимает «Оплатить». Однако его перебрасывает на главную страницу. Кроме того, в аккаунт приходится заново входить.

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

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

Формы тестирования программного обеспечения

Выделяют два вида тестирования программного обеспечения: ручное и автоматическое. В первом случае человек либо самостоятельно проверяет функциональность программы, либо делает это с помощью специального ПО и API с использованием некоторого набора инструментов.

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

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

Данный способ намного стабильнее и точнее, чем ручной. Но стоит учитывать, что эффективность автоматического тестирования зависит от правильности тестовых скриптов.

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

Виды тестирования ПО

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

Функциональное и нефункциональное

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

Как правило, тестируются только готовые функции, которые уже должны правильно работать. Однако объектами проверки могут стать и «неожидаемые» функций и варианты поведения приложения.

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

Статическое и динамическое

Статическая проверка выполняется с выключенной программой. Специалисты открывают документацию приложения, анализируют указанные в ней функции, а затем изучают код для оценки качества реализации.

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

Обе эти стадии являются необходимыми.

Прочие разновидности тестирования

Можно выделить и некоторые другие типы проверки. Каждая, даже самая маленькая, задача может быть выделена как отдельная разновидность. Однако мы приведем список только самых распространённых вариантов:

• Нагрузочное. Речь идёт о тестировании программы в условиях высоких нагрузок, которые могут быть больше, чем планировали разработчики. Эти тесты обязательны для онлайн-сервисов, которые должны правильно работать даже при наличии большого числа посетителей на пиковой или регулярной основе (онлайн-магазины во время распродаж, новостные ресурсы при резонансных событиях и т.д.).
• Тестирование UX. В этом случае специалист сосредотачивается на пользовательском опыте. Тестировщику необходимо поставить себя на место клиента. На основе составленных им замёток в процессе взаимодействия с приложением будут вноситься соответствующие изменения.
• Конфигурационное. Это проверка совместимости программы с аппаратным обеспечением и прочими software-элементами (различными версиями OS и процессоров). Конфигурационное тестирование необходимо для межплатформенных программ и в процессе перехода поставщика платформы на принципиально новую аппаратную базу (яркий пример — появление ноутбуков с чипами М1 от Apple).

Тестирование «белого ящика» и «чёрного ящика»

При проверке программного и аппаратного обеспечения термины «тестирование белого ящика» и «тестирование чёрного ящика» указывают на то, есть ли у разработчика тестов доступ к исходному коду программы (если нет, то проверка выполняется посредством пользовательского интерфейса или прикладного программного интерфейса, предоставленного тестируемым модулем).

Тестирование белого/прозрачного ящика (от английского white-box testing) подразумевает, что у разработчика теста есть доступ к исходному коду приложения и он имеет возможность писать код, связанный с библиотеками тестируемого ПО. Такое положение дел часто встречается при юнит-тестировании (англ. unit testing). В этом случае проверке подвергаются лишь определенные элементы системы.

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

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

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

Скачать
файл

Чаще всего такое тестирование выполняется с применением спецификаций или иных документов, в которых указаны требования к системе. Критерий покрытия формируются из покрытия структуры входных данных, покрытия требований и покрытия модели (при проверке на базе моделей).

Понятия «альфа-тестирование» и «бета-тестирование» связаны с этапом до выпуска продукта, объёмом тестирующего сообщества и ограничениями по способам проверки. Тестирование «белого ящика» и «чёрного ящика» относятся к методам, которыми пользуется специалист.

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

Таким образом, тестировщик может проводить мероприятия по тестированию белого ящика даже после того, как программа перейдет на этап «бета». Однако это возможно в том случае, если специалист не является частью «бета-тестирования» (группы/процесса).

Место тестирования в процессе создания ПО

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

Многое зависит и от принятой модели развития. К примеру, модель «Водопад» предполагает, что формальное тестирование выполняется на этапе тестирования. Если же используется инкрементальная модель, то проверка осуществляется в конце каждого приращения/итерации и вся программа тестируется на конечном этапе.

Тестирование программного обеспечения выполняется в различных формах на каждой стадии SDLC:

• На стадии сбора требований тестированием является проверка этих требований.
• На стадии проектирования тестированием является проверка проекта для повышения качества дизайна.
• После написания кода тестированием считается итоговая проверка.

Этапы тестирования программного обеспечения

Анализ тестирования

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

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

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

На данной стадии тестировщики рассматривают и анализируют требования, а также формируют соответствующие тесты. Кроме того, они определяют приоритеты для проверки — членов команды.

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

Планирование и подготовка теста

На этой стадии разрабатываются план тестирования, тестовый набор, данные теста. Кроме того, выполняется подготовка среды тестирования.

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

Параллельно с этим специалисты подготавливают тестовые наборы и тестовые данные.

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

Это делается с помощью матрицы прослеживаемости требований (RTM) — документа, который сравнивает требования с тестовыми примерами. Нужно это для того, чтобы удостовериться в полноценном выполнении проверки.

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

Эрик Д. Свайн создал метод генерации тестовых случаев, в котором применяются соответствующие диаграммы последовательности. Данный способ позволяет выявить ограничения для конкретных артефактов. Техники генерации тестовых наборов имеют смысл при необходимости выявления синхронизации и зависимости вариантов использования и сообщений, взаимодействия объектов и недочетов функционирования.

Подготовка тестовой среды — крайне важная стадия. После написания фрагмента кода его необходимо проверить с помощью инструмента управления конфигурацией. Далее подготавливается тестовая сборка.

Выполнение теста

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

Закрытие теста

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

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

Документация для тестирования ПО

Тест план (Test Plan) представляет собой документ, в котором указываются все необходимые для тестирования мероприятия. В нем описываются объект, стратегии, расписания, критерии начала и завершения проверки, указывается требуемое оборудование и специальные знания, а также выполняется оценка рисков.

В данном документе должны иметься ответы на нижеперечисленные вопросы:

• Что нужно протестировать?
• Каким образом должно осуществляться тестирование?
• Когда будет выполняться проверка?
• Каковы критерии начала тестирования?
• Каковы критерии завершения тестирования.

Важнейшие разделы:

• Идентификатор тест плана (Test plan identifier).
• Введение (Introduction).
• Объект тестирования (Test items).
• Функции, которые следует проверить(Features to be tested).
• Функции, которые не нужно проверять (Features not to be tested).
• Тестовые подходы (Approach).
• Критерии прохождения тестирования (Item pass/fail criteria).
• Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements).
• Результаты тестирования (Test deliverables).
• Задачи тестирования (Testing tasks).
• Ресурсы системы (Environmental needs).
• Обязанности (Responsibilities).
• Роли и ответственность (Staffing and training needs).
• Расписание (Schedule).
• Оценка рисков (Risks and contingencies).
• Согласования (Approvals).

Нельзя не упомянуть чек-лист (check list). В данном документе указываются объекты, которые необходимо протестировать. При этом чек-листы могут различаться по степени детализации.

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

Тестовый сценарий (test case) представляет собой артефакт, в котором описывается комплекс мероприятий, определенных условий и параметров, требуемых для проверки реализации тестируемой функции или её элемента.

Перечислим составные части тест кейса:

• Предусловия (PreConditions). Это перечень операций, которые необходимы для приведения системы к пригодному для выполнения основного теста состоянию. Иногда под PreConditions подразумевается набор условий, реализация которых указывает на то, что система пригодна для проведения основного теста.
• Шаги (Steps). Речь идет о перечне операций, с помощью которых одно состояние системы сменяется другим. Это нужно для того, чтобы получить результат, с помощью которого можно будет сделать вывод об удовлетворении реализации поставленным требованиям.
• Ожидаемый результат (Expected result). Это то, что необходимо получить в конечном итоге.

Правила качественного тестирования ПО

Перечислим правила, которым нужно следовать для эффективного выполнения проверки:

• Не стоит пренебрегать ручным тестированием. Автоматические проверки помогут отыскать лишь те ошибки, которые предусмотрены в скрипте тестирования. С помощью ручных методов можно найти непредсказуемые дефекты.
• Следует писать тестовые примеры на простом языке или псевдокоде вместе с вашим кодом. В противном случае новым специалистам и менеджерам придётся тратить много времени на синтаксический анализ сценария проверки.
• Необходимо применять только контролируемые изолированные испытательные среды во избежание влияния извне. Если вы будете пользоваться ПК или открытым облаком, то на тесты могут повлиять посторонние факторы. Это скажется на производительности и результате.
• Нужно выбирать конкретные метрики, которые подвергаются количественной оценке. Показатели должны описывать лишь один атрибут и строиться из чисел, дабы упростить процесс формирования отчетов. Это относится как к спецификациям, так и к тестовым случаям.
• Стоит провести тестирование до того, как вы приступите к проверке качества. Благодаря такому подходу вы распределите рабочую нагрузку тестирования по всему процессу и снизите потери времени на исправление ошибок в центральном компоненте.
• Не забывайте про пошаговые тесты. Разработайте подусловия в своих тестах. Это позволит выявить места, в которых приложение не проходит проверку.
• Лучше обеспечить как можно большее тестовое покрытие. Если вы проверите все варианты применения программы, то продукт будет готов к самым разным входам и средам.

Навыки и качества специалиста по тестированию программного обеспечения

Система тестирования программного обеспечения не будет правильно работать, если у специалиста отсутствуют определенные личностные качества. Рассмотрим необходимые для данной работы характеристики:

• Усидчивость и настойчивость. Специалист должен быть достаточно терпеливым, чтобы длительное время выполнять поиск ошибок. Профессионал своего дела знает, что не существует безошибочных приложений. Если в программе не было найдено никаких дефектов, то это указывает на низкое качество тестирования.
• Критическое мышление, способность работать с информацией.
• Умение подмечать даже самые, на первый взгляд, незначительные детали. Тестировщику необходимо проверять все возможные сценарии.
• Коммуникабельность и навыки командной работы. Специалисту нужно будет общаться с разработчиками, дизайнерами, бизнес-аналитиками, представителями заказчика.
• Самоконтроль. Разработчики далеко не всегда настроены на исправление дефектов, поэтому тестировщикам приходится по нескольку раз повторять, что была найдена ошибка. Таким образом, специалист должен сочетать в себе настойчивость и дипломатичность.
• Ответственность и педантичность. Благодаря этим качествам тестировщик будет пытаться довести свою работу до конца.
• Способность грамотно формулировать свои мысли. Это позволит разработать качественный план и тест-кейс. При обнаружении дефекта специалисту необходимо донести до разработчиков все нюансы его появления.
• Желание оттачивать свои навыки. Специалист должен быть нацелен на обучение новым техникам тестирования. Для этого ему нужно работать с соответствующей литературой, ездить на конференции, семинары, проходить курсы и т.д.

Профессионал должен знать:

• основы тестирования, его разновидности и техники;
• способы разработки тест-кейсов, тест-планов;
• языки запросов SQL, базы данных;
• языки программирования;
• системы контроля версий: Git, CVS ипр.

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

• Системы для разработки тест-кейсов и обнаружения ошибок.
• Файловые менеджеры, текстовые и XML-редакторы.
• Генераторы тестовых данных итак далее.

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

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

Лучшие курсы по специальности тестировщика ПО

• Инженер по тестированию PRO

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

• Инженер по ручному тестированию

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

• Инженер по тестированию Мастер

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

• Инженер по тестированию

Программа рассчитана на 1 год. Участники получат теоретическую базу, смогут определиться со специализацией, найдут работу или откроют свое дело в сфере ИТ. При этом трудоустройство возможно уже через полгода после начала обучения.

• Инженер по автоматизированному тестированию

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

• Специалист по тестированию

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

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

• Р. Калбертсон, К. Браун, Г. Кобб «Быстрое тестирование»

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

Насколько надежны приложения, которые вы используете каждый день? Хотите научиться обнаруживать баги и гарантировать качество ПО? Присоединяйтесь к курсу и освойте основы ручного и автоматизированного тестирования. Вы научитесь находить и документировать ошибки, разрабатывать эффективные тестовые сценарии и работать с профессиональными инструментами. Станьте незаменимым экспертом в обеспечении качества программного обеспечения.

• С. Круг «Не заставляйте меня думать»

В книге объясняется, как проверять мобильные приложения и веб-сайты по критерию удобства пользования. Текстовую информацию дополняют исчерпывающие иллюстрации. Данное практическое руководство изобилует яркими пояснениями.

• А.Купер «Психбольница в руках пациента»

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

• Дж. Арбон, Дж. Каролло, Дж. Уиттакер «Как тестируют в Google»

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

• Э. Дастин, Д. Рэшка, Дж. Пол. «Автоматизированное тестирование программного обеспечения»

В пособии описываются различные детали процесса автоматического тестирования. Книга освещает тему увеличения скорости тестовых процедур на web-серверах. При этом авторы объясняют различные нюансы проектирования, разработки и выполнения тестов.

• Станислав Куликов «Тестирование программного обеспечения. Базовый курс»

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

• С. Слукин «Введение в тестирование программного обеспечения»

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

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

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

Нашли ошибку в тексте? Выделите нужный фрагмент и нажмите
ctrl
+
enter

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

Playwright — это инструмент для автоматического тестирования веб-приложений, разработанный командой Microsoft. Он предоставляет возможности для проверки работы сценариев в интерфейсе продукта на различных платформах, включая Windows, macOS и Linux. Используя Playwright, разработчики и тестировщики могут создавать автоматические тесты, которые выполняются в реальных браузерах Chrome, Firefox и Safari.

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

Основные сценарии работы с интерфейсом продукта

При тестировании интерфейса продукта в Playwright можно рассмотреть несколько основных сценариев, которые помогут проверить его функциональность и удобство использования:

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

Ручная проверка сценариев

При ручной проверке рекомендуется следующий подход:

1. Комплексное тестирование: Проверьте функциональность продукта в различных сценариях, уделяя внимание каждой его части. Убедитесь, что все разделы работают должным образом и взаимодействуют между собой без ошибок.
2. Воспроизведение предыдущих проблем: Проверьте, были ли ранее обнаружены и исправлены проблемы. Попробуйте воспроизвести их снова, чтобы убедиться, что они действительно исправлены.
3. Граничные случаи: Протестируйте продукт в экстремальных ситуациях, помимо обычных сценариев использования. Проверьте, как ведет себя продукт при непредвиденных обстоятельствах, таких как большое количество данных или низкое соединение.
4. Взаимодействие с другими платформами: Если продукт взаимодействует с другими платформами или приложениями, проверьте работу этого взаимодействия. Убедитесь, что передача данных или коммуникация происходит без ошибок и согласно требованиям.

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

Автоматизация проверки

Для автоматизации проверки можно использовать Playwright — инструментарий для автоматизации браузерных приложений. Он обеспечивает доступ к различным браузерам (Chrome, Firefox, WebKit) и позволяет выполнять действия, такие как ввод текста, нажатие на кнопки и проверка содержимого страницы.

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

Для автоматизации проверки с различными сценариями в Playwright вы можете использовать такие функции, как «click», «type», «fill», «waitForNavigation» и другие. С помощью этих функций вы можете взаимодействовать с элементами интерфейса, вводить текст, нажимать на кнопки и ожидать перехода на следующую страницу.

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

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

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

Использование Playwright для работы с различными сценариями

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

Playwright обеспечивает широкий спектр возможностей для проверки работы сценариев в вашем приложении. Он поддерживает несколько языков программирования, включая JavaScript, TypeScript и Python, что делает его доступным для разработчиков с различным опытом.

Преимущества использования Playwright заключаются в его простоте использования, мощных возможностях и кросс-браузерной совместимости. Он позволяет проводить тестирование веб-приложений в разных браузерах, включая Chrome, Firefox, Safari и другие.

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

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

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

Техники работы с Playwright

1. Создание и выполнение тестовых сценариев: Playwright позволяет создавать и выполнять тестовые сценарии, которые имитируют взаимодействие пользователя с веб-приложением. Вы можете создавать сценарии, которые проверяют различные сценарии использования продукта, такие как регистрация пользователя, добавление товара в корзину или оформление заказа. Это позволяет вам убедиться, что интерфейс продукта работает правильно во всех возможных сценариях.

2. Создание множественных конфигураций: Playwright позволяет создавать множественные конфигурации для проверки работы интерфейса в разных браузерах и на разных платформах. Это позволяет вам убедиться, что ваш продукт работает надежно в различных средах.

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

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

5. Проверка работы с AJAX и WebSocket: Playwright позволяет проверять работу с AJAX-запросами и WebSocket-соединениями. Вы можете проверить, что ваш продукт корректно взаимодействует с сервером и обрабатывает полученные данные.

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

Полезные советы

При проверке работы с различными сценариями в интерфейсе продукта с использованием Playwright, важно учитывать несколько полезных советов:

1. Составьте список основных сценариев, которые хотите проверить. Это поможет вам быть организованным и не упустить важные кейсы.

2. Создайте набор тестовых данных, представляющих различные сценарии использования продукта. Убедитесь, что вы включили в него данные для позитивных и негативных сценариев.

3. Проверьте функциональность продукта на разных платформах и браузерах. Используйте настройки Playwright для запуска тестов на разных операционных системах и устройствах.

4. Разделите тесты на логические группы и назначьте им теги. Теги помогут вам легко фильтровать и запускать отдельные группы тестов, что сделает процесс отладки более эффективным.

5. Включите в тесты проверку отображения элементов интерфейса, таких как текст, изображения, ссылки и кнопки. Убедитесь, что все элементы отображаются корректно и соответствуют заданным ожиданиям.

6. Используйте функциональность Playwright для взаимодействия с элементами интерфейса. Выполняйте действия, такие как ввод текста, нажатие на кнопки и переход по ссылкам, для проверки их функциональности и корректности работы.

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

8. Обратите внимание на производительность проверяемого продукта. Используйте инструменты Playwright для измерения времени отклика и загрузки страницы, а также для проверки масштабируемости при работе с большим объемом данных.

9. Включите в тесты проверку отображения ошибок и исключений. Убедитесь, что продукт корректно обрабатывает ошибки и отображает соответствующие сообщения пользователю.

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

В фундаментальную концепцию проектирования ПС входят базовые положения, стратегии, методы, которые применяются на процессах ЖЦ и обеспечивают тестирование (верификацию) на множестве тестовых наборов данных. К методам проектирования ПС относятся структурные, объектно-ориентированные и др. Их основу составляют теоретические, инструментальные и прикладные средства, которые влияют на процесс тестирования.

Теоретические средства определяют процесс программирования и тестирования программного продукта. К ним относятся методы верификации и доказательства правильности спецификации программ (см.
«Формальные спецификации,
доказательство и верификация программ»
), метрики измерения (Холстеда, цикломатичная сложность Маккейба и др.) в качестве отдельных характеристик как формализованных элементов теории определения правильности и гарантии свойств конечного ПО. Например, концепция » чистая комната » базируется на формализмах доказательства и изучения свойств процессов кодирования и тестирования программ. Что касается тестирования как процесса, то это проверка правильности работы программы по заданным описаниям тестов и покрытия данными соответствующих критериев программы [7.1-7.5].

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

При проверке правильности программ и систем рассматриваются процессы верификации, валидации и тестирования ПС, которые регламентированы в стандарте ISO/IEC 12207 [7.7] жизненного цикла ПО. В некоторой зарубежной литературе процессы верификации и тестирования отождествляются. С теоретической точки зрения верификация была рассмотрена в
«Формальные спецификации,
доказательство и верификация программ»
, здесь же будут определены задачи и действия, соответствующих процессов ЖЦ.

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

7.1. Процессы ЖЦ верификация и валидация программ

Верификация и валидация, как методы, обеспечивают соответственно проверку и анализ правильности выполнения заданных функций и соответствия ПО требованиям заказчика, а также заданным спецификациям. Они представлены в стандартах [7.7-7.8] как самостоятельные процессы ЖЦ и используются, начиная от этапа анализа требований и кончая проверкой правильности функционирования программного кода на заключительном этапе, а именно, тестировании.

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

Процесс верификации. Цель процесса — убедиться, что каждый программный продукт (и/или сервис) проекта отражает согласованные требования к их реализации. Этот процесс основывается:

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

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

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

Процесс валидации. Цель процесса — убедиться, что специфические требования для программного продукта выполнены, и осуществляется это с помощью:

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

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

На других процессах ЖЦ выполняются дополнительные действия:

• проверка и контроль проектных решений с помощью методик и процедур просмотра хода разработки;
• обращение к CASE-системам [7.10], которые содержат процедуры проверки требований к продукту;
• просмотры и инспекции промежуточных результатов на соответствие их требованиям для подтверждения того, что ПО имеет корректную реализацию требований и удовлетворяет условиям выполнения системы.

Таким образом, основные задачи процессов верификации и валидации состоят в том, чтобы проверить и подтвердить, что конечный программный продукт отвечает назначению и удовлетворяет требованиям заказчика. Эти процессы взаимосвязаны и определяются, как правило, одним общим термином «верификация и валидация» или «Verification and Validation» (V&V) [7.7].

V&V основаны на планировании их как процессов, так и проверки для наиболее критичных элементов проекта: компонент, интерфейсов (программных, технических и информационных), взаимодействий объектов (протоколов и сообщений), передач данных между компонентами и их защиты, а также оставленных тестов и тестовых процедур.

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

7.2. Тестирование программ

Тестирование можно рассматривать, как процесс семантической отладки (проверки) программы, заключающийся в исполнении последовательности различных наборов контрольных тестов, для которых заранее известен результат. Т.е. тестирование предполагает выполнение программы и получение конкретных результатов выполнения тестов [7.1-7.5, 7.11, 7.12].

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

Исторически первым видом тестирования была отладка.

Отладка — это проверка описания программного объекта на ЯП с целью обнаружения в нем ошибок и последующее их устранение. Ошибки обнаруживаются компиляторами при их синтаксическом контроле. После этого проводится верификация по проверке правильности кода и валидация по проверке соответствия продукта заданным требованиям.

Целью тестирования — проверка работы реализованных функций в соответствии с их спецификацией. На основе внешних спецификаций функций и проектной информации на процессах ЖЦ создаются функциональные тесты, с помощью которых проводится тестирование с учетом требований, сформулированных на этапе анализа предметной области. Методы функционального тестирования подразделяются на статические и динамические.

7.2.1. Статические методы тестирования

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

Инспекция ПО — это статическая проверка соответствия программы заданным спецификациями, проводится путем анализа различных представлений результатов проектирования (документации, требований, спецификаций, схем или исходного кода программ) на процессах ЖЦ. Просмотры и инспекции результатов проектирования и соответствия их требованиям заказчика обеспечивают более высокое качество создаваемых ПС.

При инспекции программ рассматриваются документы рабочего проектирования на этапах ЖЦ совместно с независимыми экспертами и участниками разработки ПС. На начальном этапе проектирования инспекция предполагает проверку полноты, целостности, однозначности, непротиворечивости и совместимости документов с исходными требованиями к программной системе. На этапе реализации системы под инспекцией понимается анализ текстов программ на соблюдение требований стандартов и принятых руководящих документов технологии программирования.

Эффективность такой проверки заключается в том, что привлекаемые эксперты пытаются взглянуть на проблему «со стороны» и подвергают ее всестороннему критическому анализу.

Эти приемы позволяют на более ранних этапах проектирования обнаружить ошибки или дефекты путем многократного просмотра исходных кодов. Символьное тестирование применяется для проверки отдельных участков программы на входных символьных значениях.

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

7.2.2. Динамические методы тестирования

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

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

Дадим краткую их характеристику.

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

Цель динамического тестирования программ по принципу «черного ящика» — выявление одним тестом максимального числа ошибок с использованием небольшого подмножества возможных входных данных.

Методы «черного ящика» обеспечивают:

• эквивалентное разбиение;
• анализ граничных значений;
• применение функциональных диаграмм, которые в соединении с реверсивным анализом дают достаточно полную информацию о функционировании тестируемой программы.

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

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

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

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

• (а) критерий покрытия операторов — набор тестов в совокупности должен обеспечить прохождение каждого оператора не менееодного раза;
• (б) критерий тестирования ветвей (известный как покрытие решений или покрытие переходов) — набор тестов в совокупности должен обеспечить прохождение каждой ветви и выхода, по крайней мере, один раз.

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

Тестирование по принципу «белого ящика» ориентировано на проверку прохождения всех путей программ посредством применения путевого и имитационного тестирования.

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

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

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