Введение

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

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

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

Также к статическому тестированию относят тестирование требований , спецификаций , документации .

Регрессионное тестирование

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

Тестовые скрипты

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

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

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

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

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

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

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

Покрытие кода

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

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

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

Цитаты

• «Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.» - Дейкстра , 1970 г.

См. также

• Обратная семантическая трассировка - универсальный метод тестирования любого проектного артефакта

Примечания

Литература

• Гленфорд Майерс, Том Баджетт, Кори Сандлер Искусство тестирования программ, 3-е издание = The Art of Software Testing, 3rd Edition. - М .: «Диалектика», 2012. - 272 с. - ISBN 978-5-8459-1796-6
• Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. - М .: «Вильямс», 2010. - 464 с. - (Addison-Wesley Signature Series). - 1000 экз. - ISBN 978-5-8459-1625-9
• Канер Кем, Фолк Джек, Нгуен Енг Кек Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. - Киев: ДиаСофт, 2001. - 544 с. - ISBN 9667393879
• Калбертсон Роберт, Браун Крис, Кобб Гэри Быстрое тестирование. - М .: «Вильямс», 2002. - 374 с. - ISBN 5-8459-0336-X
• Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. - М .: БИНОМ, 2008. - 368 с. - ISBN 978-5-94774-825-3
• Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. - СПб. : Питер, 2004. - 320 с. - ISBN 5-94723-698-2

Ссылки

• Портал специалистов по тестированию и обеспечению качества ПО (рус.)
• Портал об автоматизированном тестировании ПО (рус.)
• Качество программного обеспечения (рус.)

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

Тестирование программного обеспечения является неотъемлемой частью цикла разработки программного обеспечения.

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

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

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

Методика тестирования

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

3) Системное тестирование

4) Приемочные испытания

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

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

Системное тестирование

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

Приемочные испытания

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

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

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

Тестирование методом черного ящика

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

Тестирование методом белого ящика

Тестирование методом "Белого ящика", в отличие от "черного ящика", учитывает внутреннее функционирование и логику работы кода. Для выполнения этого теста, тестер должен иметь знания кода, чтобы узнать точную часть кода, имеющую ошибки. Этот тест также известен как White-box, Open-Box или Glass box тестирование.

Тестирование методом серого ящика

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

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

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

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

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

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

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

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

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

Основными шагами, участвующими в данной методике тестирования программного обеспечения, являются:

• Анализ потребностей
• Тест дизайна
• Тест реализации
• Тестирование, отладка и проверка кода или продукта
• Внедрение и обслуживание

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

Agile Model

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

Rapid Application Development (RAD). Методология быстрой разработки приложений

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

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

Спиральная модель

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

Rational Unified Process (RUP). Рациональный унифицированный процесс

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

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

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

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

Классификация жизненного цикла процесса разработки программного обеспечения происходит следующим образом:

1. Планирование
2. Анализ
3. Дизайн
4. Разработка программного обеспечения
5. Реализация
6. Развертывание
7. Техническое обслуживание

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

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

Ошибка: ошибка или заблуждение - это человеческое действие, которое производит неправильный или неверный результат.

Дефект (баг, неисправность): сбой в системе или продукте, который может привести к сбою или неисправности компонента.

Отказ: это разница между фактическим и ожидаемым результатом.

Риск: риск - это фактор, который может привести к отрицательным результатам или возможности убытка, или ущерба.

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

1. Обнаружение дефектов
2. Обретение уверенности и предоставление информации об уровне качества
3. Предотвращение дефектов

Область применения тестирования программного обеспечения

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

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

Ключевые понятия

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

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

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

Верификация и Валидация: тестирование программного обеспечения проводится с учетом этих двух факторов.

1. Верификация: проверяет, разработан ли данный продукт согласно спецификации.
2. Валидация: проверяет, соответствует ли продукт требованиям клиентов.

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

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

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

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

Инструкции по сценарию тестирования:

• Black Box (черный ящик) тестирование
• White Box (белый ящик) тестирование
• Gray Box (серый ящик) тестирование

Уровни тестирования программного обеспечения жизненного цикла включают в себя:

• Модульное тестирование
• Интеграционное тестирование
• Системное тестирование
• Приемочное тестирования (альфа-тестирование и бета-тестирование)

Другими видами тестирования программного обеспечения являются:

• Функциональное тестирование
• Тестирование производительности (нагрузочное тестирование и стресс-тестирование)
• Дымовое тестирование
• Санитарное тестирование (проверка согласованности)
• Регрессионное тестирование
• Тестирование восстановления.
• Юзабилити-тестирование
• Тестирование на совместимость
• Тестирование конфигурации
• Исследовательское тестирование

Автоматизированное тестирование

Ручное тестирование - трудоемкий процесс. Автоматизация тестирования предполагает автоматизировать ручной процесс. Автоматизация тестирования - это процесс написания компьютерной программы в виде скриптов для тестирования, который обычно делается вручную. Некоторыми популярными средствами автоматизации являются Winrunner, Quick Test Professional (QTP), LoadRunner, SilkTest, Rational Robot, и т. д. Средства автоматизации также включает в себя сервисные инструменты, такие как TestDirector и многие другие.

Методологии тестирования программного обеспечения

Существуют различные методики тестирования доступные для разработки и тестирования программного продукта. Этими моделями являются:

• Каскадная модель
• V Модель
• Спиральная модель
• Рационального унифицированный процесс
• Гибкая модели
• Быстрая разработка приложений

Тестовые артефакты

В процессе тестирования программного обеспечения можно произвести различные артефакты, такие как:

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

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

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

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

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

Тестовый набор: это сборник тестовых случаев.

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

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

1. Создание плана тестирования
2. Дизайн тест-кейсов
3. Описание тестовых случаев
4. Обзор тестовых случаев
5. Выполнение теста
6. Изучение результатов тестов
7. Составление конечного обзора

Ниже приведены примеры тестирования:

Тестирование программного обеспечения для входа на страницу системы:

цель: пользователь должен иметь возможность перейти на главную страницу.

Предпосылки:

1. Программное обеспечение должно быть совместимо с операционной системой.
2. Должна появиться страница «ввода логина».
3. Текстовые поля идентификатора пользователя и пароля должны быть доступны с соответствующими метками.
4. Должны быть в наличии кнопки «Войти» и «Отмена» с соответствующими подписями.

Тест 1

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

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

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

Тест 2

Название теста: Текстовое поле для идентификатора пользователя следует: 1) разрешить только буквенные символы {от a до z, и от A до Z}, 2) не разрешать специальные символы, такие как {"$","#","!","~","*",...}, 3) не разрешать цифровые символы {0-9}.

Шаги/действия: 1) Пользователь вводит числа в текстовое поле. 2) Пользователь вводит алфавитно-цифровые данные в текстовом поле.

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

Тест 3

Название теста: проверка функциональности текстового поля для пароля: 1) текстовое поле для пароля должно принять шесть или более символов. 2) данные должны отображаться в зашифрованном виде.

Шаги/действия: 1) Пользователь вводит только два символа в текстовом поле пароля. 2) Пользователь вводит более шести символов в текстовом поле пароля. 3) Пользователь проверяет отображаются ли данные в зашифрованном виде.

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

Тест 4

Название теста: проверка функциональности кнопки «Войти».

Шаги/действия: 1) Пользователь проверяет, включена или отключена кнопка «Войти». 2) Пользователь нажимает на кнопку «Войти» и ожидает, просмотра главной страницы приложения.

Ожидаемые результаты: 1) система отображает кнопку «Войти». 2) Система перенаправляет пользователя на главную страницу приложения, как только он нажимает на кнопку «Войти».

Тест 5

Название теста: проверка функциональности кнопки «Отмена».

Шаги/действия: 1) Пользователь проверяет, включена или отключена кнопка «Отмена». 2) Пользователь проверяет, сбрасываются ли текстовые поля ID пользователя и пароль при нажатии кнопки «Отмена».

Ожидаемые результаты: 1) система отображает кнопки «Отмена». 2) система сбрасывает данные текстовых полей идентификатора пользователя и пароля, когда пользователь нажимает на кнопку «Отмена».

Методы поиска неисправностей при тестировании программного обеспечения

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

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

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

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

Метрика программного обеспечения поможет избежать таких подводных камней, как:

1. Перерасход средств
2. Определение, источника проблемы
3. Уточнение целей

Даст ответы на такие вопросы как:

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

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

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

• Покрытие кода
• Цикломатическая сложность
• Сплоченность
• Связь
• Функция точечного анализа
• Время выполнения
• Источник строк кода
• Ошибка в строках кода

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

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

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

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

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

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

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

Рисунок 1. Процесс тестирования дефектов

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

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

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

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

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

Рисунок 2. Тестирование методом черного ящика

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

Рисунок 3. Структурное тестирование

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

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

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

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

Метод тестирования ветвей основывается на графе потоков управления программы. Этот граф представляет собой скелетную модель всех ветвей программы. Граф потоков управления состоит из узлов, соответствующих ветвлениям решений, и дуг, показывающих поток управления. Если в программе нет операторов безусловного перехода, то создание графа - достаточно простой процесс. При построении графа потоков все последовательные операторы (операторы присвоения, вызова процедур и ввода-вывода) можно проигнорировать. Каждое ветвление операторов условного перехода (if-then-else или case) представлено отдельной ветвью, а циклы обозначаются стрелками, концы которых замкнуты на узле с условием цикла. На рисунке 4 показаны циклы и ветвления в графе потоков управления программы бинарного поиска .

Рисунок 4. Граф потоков управления бинарного поиска

Цель структурного тестирования - удостовериться, что каждая независимая ветвь программы выполняется хотя бы один раз. Независимая ветвь программы - это ветвь, которая проходит, по крайней мере, по одной новой дуге графа потоков. В терминах программы это означает ее выполнение при новых условиях. С помощью трассировки в графе потоков управления программы бинарного поиска можно выделить следующие независимые ветви :
1, 2, 3, 8, 9
1, 2, 3, 4, 6, 7, 2
1, 2, 3, 4, 5, 7, 2
1, 2, 3, 4, 6, 7, 2, 8, 9

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

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

С (G) = количество дуг – количество узлов + 2

Для программ, не содержащих операторов безусловного перехода, значение цикломатического числа всегда больше количества проверяемых условий. В составных условиях, содержащих более одного логического оператора, следует учитывать каждый логический оператор. Например, если в программе шесть операторов if и один цикл while, то цикломатическое число равно 8. Если одно условное выражение является составным выражением с двумя логическими операторами (объединенными операторами and или or), то цикломатическое число будет равно 10. Цикломатическое число программы бинарного поиска равно 4.

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

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

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

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

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

В примере на рисунке 5 последовательность тестов T1, Т2 и ТЗ сначала выполняется в системе, состоящей из модулей А и В (минимальная конфигурация системы). Если во время тестирования обнаружены дефекты, они исправляются. Затем в систему добавляется модуль С. Тесты T1, T2 и ТЗ повторяются, чтобы убедиться, что в новой системе нет никаких неожиданных взаимодействий между модулями А и В. Если в ходе тестирования появились какие-то проблемы, то, вероятно, они возникли во взаимодействиях с новым модулем С. Источник проблемы локализован, таким образом упрощается определение дефекта и его исправление. Затем система запускается с тестами Т4. На последнем шаге добавляется модуль D и система тестируется еще раз выполняемыми ранее тестами, а затем новыми тестами Т5 .

Рисунок 5. Тестирование сборки

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

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

На рисунке 6 показаны возможные инструментальные средства тестирования и отношения между ними.

1. Организатор тестов. Управляет выполнением тестов. Он отслеживает тестовые данные, ожидаемые результаты и тестируемые функции программы.
2. Генератор тестовых данных. Генерирует тестовые данные для тестируемой программы. Он может выбирать тестовые данные из базы данных или использовать специальные шаблоны для генерации случайных данных необходимого вида.
3. Оракул. Генерирует ожидаемые результаты тестов. В качестве оракулов могут выступать предыдущие версии программы или исследуемого объекта. При тестировании параллельно запускаются оракул и тестируемая программа и сравниваются результаты их выполнения.
4. Компаратор файлов. Сравнивает результаты тестирования с результатами предыдущего тестирования и составляет отчет об обнаруженных различиях. Компараторы особенно важны при сравнении различных версий программы. Различия в результатах указывают на возможные проблемы, существующие в новой версии системы.
5. Генератор отчетов. Формирует отчеты по результатам проведения тестов.
6. Динамический анализатор. Добавляет в программу код, который подсчитывает, сколько раз выполняется каждый оператор. После запуска теста создает исполняемый профиль, в котором показано, сколько раз в программе выполняется каждый оператор.
7. Имитатор. Существует несколько типов имитаторов. Целевые имитаторы моделируют машину, на которой будет выполняться программа. Имитатор пользовательского интерфейса - это программа, управляемая сценариями, которая моделирует взаимодействия с интерфейсом пользователя. Имитатор ввода/вывода генерирует последовательности повторяющихся транзакций .

Рисунок 6. Инструментальные средства тестирования

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

Для создания полного комплекса инструментального средства тестирования, как правило, требуется много сил и времени. Весь набор инструментальных средств, показанных на рис. 6, используется только при тестировании больших систем. Для таких систем полная стоимость тестирования может достигать 50% от всей стоимости разработки системы. Вот почему выгодно инвестировать разработку высококачественных и производительных CASE-средств тестирования .

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

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

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

С чего же начинать организацию процесса тестирования?

Я выделяю 11 основных критериев в организации процесса тестирования:

1. Цели и область тестирования
2. Команда
3. Управление
4. Коммуникация и взаимодействие
5. Методология тестирования
6. Документированность процесса
7. Управление рисками
8. Измерение процесса
9. Инструменты
10. Тестовые среды
11. Совершенствование процесса

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

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

• Зачем нам нужно тестирование?
• Что мы имеем, чтобы сделать тестирование?
• Какие процессы нужно формализовать или создать?
• Как и что мы должны тестировать?

Только после того, как мы получим ответы на эти вопросы, можно начинать переходить к стандартам.

Я выделяю следующие стандарты, которые действительно нужно изучить перед тем, как начинать строить процесс:

• ISO 29119
• IEEE 829\1008
• TPI Next&TMap
• ISTQB

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

Любой ИТ процесс всегда должен удовлетворять потребностям бизнеса!

Мы разберем основные критерии построения процесса тестирования.

Цели и область тестирования

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

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

Говоря об области тестирования, мы должны прекрасно понимать, что именно нам предстоит тестировать. Это могут быть системы, компоненты, бизнес процессы. Для того, чтобы это понять, то нужно просто ответить на два вопроса:

• Что надо тестировать?
• Что будем тестировать?

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

Команда и управление

Команда — это самая важная составляющая процесса тестирования. Без команды вы, как руководитель, ничего не сделаете. Зачастую к формированию команды подходят несколькими подходами:

Инструменты и инфраструктура

Какой же процесс тестирования без инструментов? Это получается ручной труд ради ручного труда 🙂 Я думаю многие из вас часто слышали о написании тест-кейсов в документах ворд, о построения графиков и диаграмм в экселе. Но, зачем тратить усилия, если рынок предлагает нам готовые продукты управления тестирования, такие как HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr и многие другие.
Поэтому, если вы приступили к организации процесса тестирования, то делайте этот процесс удобным и эффективным. Пишите тест-кейсы в удобных формах готовых продуктов, интегрируйте инструменты с системой управления задачами, настраивайте и т.д.

Подходя к выбору инструмента нужно всегда понимать:

• Какие задачи вы планируете выполнять?
• Какой у вас бюджет на инструменты?

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

Помимо инструментов управления тестирования, к инструментам тестирования также можно отнести:

• Система управления дефектами и задачами (может включаться в систему управления тестированием)
• Вспомогательные инструменты (для скриншотов, снятия логов, работы с БД, SOUP UI для XML и т.д.)
• Инструменты автоматизации ( , Selenium и т.д.)
• Системы управления знаниями (на wiki движке)

Теперь поговорим об инфраструктуре. В текущем контексте своего повествования я подразумеваю тестовые среды.

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

Стандартно я выделяю следующие типы тестовых сред:

• Среда разработки (можно ли ее относить к тестовой?, но тем не менее)
• Среда тестирования системы (может быть развернута одна или несколько систем, компонент, не требует серьезных мощностей)
• Среда интеграции (полноценный интеграционная среда для проверки работоспособности сквозных бизнес процессов)
• Среда (основное требования — соответствие мощностями боевому контуру)
• Среда ПродЛайк/ПреПрод (среда для отладки готового протестированного билда, проведение инсталяционного тестирования)

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

Совершенствование процесса

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

Но это не так. Почему мы должны постоянно совершенствовать процесс тестирования:

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

2. ИТ сфера постоянно развивается. Приходят новые технологи подходы, которые всегда позволяются совершенствовать процесс тестирования.

Как говорится, совершенству нет предела!

Ну а как совершенствовать — это стандартный цикл Демминга.

Запланировали — .Сделали — Проанализировали — Скорректировали

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