Современные технологии тестирования

Современные технологии тестирования

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

С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам. Как одна из основных фаз процесса разработки программного продукта ( Дизайн приложения — Разработка кода — Тестирование), тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. Широко известна оценка распределения трудоемкости между фазами создания программного продукта: 40%-20%-40%.

С точки зрения математики тестирование можно рассматривать как интерпретацию некоторой формулы и проверки ее истинности на некоторых множествах. Действительно, программу можно представить в виде формулы f = f1* f2* f3*. * fn , где f1 , f 2 , . fn — операторы языка программирования, а их суперпозиция — программа .

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

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

Статическое тестирование выявляет формальными методами анализа без выполнения тестируемой программы неверные конструкции или неверные отношения объектов программы (ошибки формального задания) с помощью специальных инструментов контроля кода — CodeChecker.

Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования — Testbed или Testbench.

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

Классы критериев тестирования

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

  • Условие критерия тестирования команд (критерий С0) — набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза.
  • Условие критерия тестирования ветвей (критерий С1) — набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза.
  • Условие критерия тестирования путей (критерий С2) — набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз.

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

Выделяют следующие частные виды функциональных критериев :

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

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

Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.

Метод мутационного тестирования состоит в том, что в разрабатываемую программу P вносят мутации (мелкие ошибки), т.е. искусственно создают программы- мутанты P1, P2. . Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X, Y).

Если на наборе (X, Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы- мутанты ошибки, то набор тестов (X, Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной. Если некоторые мутанты не выявили всех мутаций, то надо расширять набор тестов (X, Y) и продолжать тестирование.

Фазы тестирования

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

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

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

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

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

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

Этапы тестирования

Каждая фаза тестирования включает в себя следующие этапы:

  1. Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т. п.
  2. Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов . Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы.
  3. Разработка тестов (тестового кода для тестируемой системы).
  4. Выполнение тестов: реализация тестовых циклов .
  5. Анализ результатов.

Тестовый цикл — это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса. Тестовый цикл заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build.

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

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

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

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

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

Типы тестов

В тестовом плане определяются и документируются различные типы тестов.

Типы тестирования по виду подсистемы или продукта таковы:

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

Типы тестирования по способу выбора входных значений:

  1. Функциональное тестирование, при котором проверяется:
    • покрытие функциональных требований;
    • покрытие сценариев использования.

Test Driven Development

Рассмотрим подход к тестированию, несколько отличающийся от приведенного выше. Разработка через тестирование ( Test Driven Development — TDD) — процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.

TDD задает следующий порядок этапов программирования:

  • Красный — напишите небольшой тест, который не работает, а возможно, даже не компилируется.
  • Зеленый — заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.
  • Рефакторинг — удалите из написанного вами кода любое дублирование.
  • Освоив TDD, разработчики обнаруживают, что они пишут значительно больше тестов, чем раньше, и двигаются вперед маленькими шагами, которые раньше могли показаться бессмысленными.
Читайте также:  Всероссийская олимпиада школьников в 2021 2022 какие предметы

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

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

Итоги

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

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

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

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

Источник

Этапы тестирования ПО

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

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

Всего принято выделять 7 этапов тестирования:

  1. Работа с требованиями. Знакомство с требованиями заказчика, что должен из себя представлять итоговый продукт, обсуждение.
  2. Разработка стратегии тестирования . Оценка сроков тестирования, выявление среды тестирования, объединение всей информации, полученной при работе с требованиями.
  3. Создание тестовой документации. Написание сценариев, которые позволят проверить функционал.
  4. Тестирование прототипа. Тестирование основного функционала продукта, корректировка целей, добавление фичей.
  5. Основное тестирование . Выполнение общей проверки продукта.
  6. Стабилизация . На данном этапе происходит работа над устранением багов.
  7. Эксплуатация. Проводится регресс-тестирование, устранение ошибок, которые нашел конечный пользователь.

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

Этап 1. Работа с требованиями

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

Тщательное изучение требований должно:

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

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

Этап 2. Разработка стратегии тестирования и планирование процедур контроля качества

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

Тест — лид должен:

  1. резюмировать полученную информацию,
  2. оценить сроки тестирования,
  3. разработать стратегию тестирования: определить виды тестирования, которые можно применить к проекту, проанализировать имеющиеся среды и ресурсы, что имеется для проведения тестирования, описать приоритеты для непредвиденных ситуаций, как и где будет вестись тестовая документация;
  4. определение среды тестирования: какое оборудование необходимо для тестирования,
  5. составить план, который содержит описание, с чего начинается и чем заканчивается тестирование, и что будет тестироваться.

Этап 3. Создание тестовой документации

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

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

Тестовая документация может состоять из:

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

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

Этап 4. Тестирование прототипа

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

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

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

Этап 5. Основное тестирование

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

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

Этап 6. Стабилизация

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

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

Этап 7. Эксплуатация и поддержка

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

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

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

Источник

Тестирование: цели и принципы

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

Все статьи будут выходить с хештегом #базоваятеория@zapiskisedogotestera. Это позволит найти их среди прочих.

Предлагаю начать с определения тестирования, его целей и принципов.

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

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

Читайте также:  Как сделать запрос из PHP к базе данных

Тестирование — это …

Тестирование (testing) — это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов [глоссарий ISTQB].

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

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

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

Цели тестирования сильно зависят от целей самого проекта. Но можно выделить основные общие цели:

  1. Проверка, все ли указанные требования выполнены.
    Что это значит? У каждого продукта есть техническое задание (ТЗ) в том или ином виде. Именно оно определяет, как будет выглядеть программа. ТЗ задает соответствующие требования, а мы, как тестировщики, должны проверить, что все требования из ТЗ не только реализованы, но и работают правильно.
  2. Создание уверенности в уровне качества объекта тестирования.
    Напрямую тестирование не влияет на качество продукта. Грубо говоря, качество — это удовлетворение ожиданий пользователей. А удовлетворение зависит от очень многих факторов.
    Тем не менее, поиск и исправление дефектов позволяет продукту работать именно так, как он был задуман. И, как минимум, можно сказать, что если программа работает корректно и соответствует заданным критериям, то достигнут определенный уровень качества объекта тестирования.
  3. Предотвращение дефектов.
    Тестирование — не только поиск багов на уже реализованном продукте. Существует также тестирование на более ранних этапах, например, тестирование документации.
    Заранее протестировав тоже ТЗ, тестировщик может указать на потенциальные проблемы, которые могут появиться в результате разработки программы. А зная о таких проблемах заранее, можно избежать вполне реальных багов в будущем.
  4. Обнаружение отказов и дефектов.
    Здесь все просто: поиск багов в программном обеспечении (ПО) является неотъемлемой частью тестирования.
  5. Предоставление заинтересованным лицам достаточной информации, позволяющей им принять обоснованные решения (особенно в отношении уровня качества объекта тестирования).
    Тестирование — это все-таки услуга. Мы, как тестировщики, не влияем напрямую на исправление дефектов. Но можем показать текущее состояние продукта, выраженное в количестве багов, путем оформления баг-репортов. Заинтересованные лица (например, руководитель проекта) могут оценить текущие проблемы и принять решение о выпуске или не выпуске продукта.
  6. Снижение уровня риска ненадлежащего качества программного обеспечения (например, пропущенные сбои в работе).
    Чем лучше тестирование, тем меньший риск пропуска критичных багов. А значит, что риск возникновения ненадлежащего качества ПО уменьшается.

Принципы тестирования

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

  1. Тестирование демонстрирует наличие дефектов, а не их отсутствие.
    Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, тестирование не доказывает его корректности. Почему? Потому что есть пункт 2.
  2. Исчерпывающее тестирование недостижимо.
    Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо попытки исчерпывающего тестирования должны использоваться анализ рисков, методы тестирования и расстановка приоритетов, чтобы сосредоточить усилия по тестированию.
    Элементарно, попробуйте посчитать сколько усилий необходимо приложить, чтобы проверить все комбинации калькулятора. И даже если вы продумаете абсолютно все варианты, то всегда найдется еще один, о котором вы не знаете.
  3. Раннее тестирование сохраняет время и деньги.
    Активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения. Это как раз позволяет находить дефекты на ранних стадиях.
    Раннее тестирование иногда называют «сдвигом влево» по ISTQB. Тестирование на ранних этапах жизненного цикла разработки программного обеспечения помогает сократить или исключить дорогостоящие изменения. Хотя бы потому что вовремя замеченную ошибку в ТЗ исправить намного проще, чем когда по этому ТЗ уже будет разработана функциональность.
  4. Кластеризация дефектов (Скопление дефектов).
    Обычно небольшое количество модулей содержит большинство дефектов, обнаруженных во время тестирования перед выпуском. То есть баги имеют свойство скапливаться где-то в одном месте и, если нашли интересную ошибку в функционале, есть очень большая вероятность найти рядом еще одну.
  5. Парадокс (эффект) пестицида.
    Если одни и те же тесты будут выполняться снова и снова, в конечном счете эти тесты больше не будут находить новых дефектов. Для обнаружения новых ошибок может потребоваться изменение существующих тестов и тестовых данных, а также написание новых тестов.
    Тесты больше не эффективны при обнаружении дефектов, так же как пестициды через некоторое время больше не эффективны при борьбе с вредителями.
  6. Тестирование зависит от контекста.
    Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение управления производством, в котором критически важна безопасность, тестируется иначе, чем мобильное приложение электронной коммерции.
  7. Заблуждение об отсутствии ошибок.
    Некоторые организации ожидают, что тестировщики смогут выполнить все возможные тесты и найти все возможные дефекты, но принципы 2 и 1 говорят нам, что это невозможно.
    Кроме того, ошибочно ожидать, что простое нахождение и исправление большого числа дефектов обеспечит успех продукту. Например, тщательное тестирование всех указанных требований и исправление всех обнаруженных дефектов может привести к созданию системы, которая будет трудной в использовании, не будет соответствовать потребностям и ожиданиям пользователей или будет хуже по сравнению с другими конкурирующими системами.

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

Источник



ЦЕЛИ , ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ .

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

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

Визуальный контроль — это проверка программ “ за столом “ , без использования компьютера. На первом этапе визуального контроля осуществляется чтение программы, причем особое внимание уделяется следующим ее элементам:

1. комментариям и их соответствию тексту программы ;

2. условиям в операторах условного выбора ( IF, CASE ) и цикла;

3. сложным логическим выражениям;

4. возможности незавершения итерационных циклов ( WHILE, REPEAT, LOOP ).

Второй этап визуального контроля — сквозной контроль программы

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

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

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

1. информационные сообщения и предупреждения , при обнаружении которых компилятор, как правило, строит корректный объектный код и дальнейшая работа с программой (компоновка, выполнение) возможна (тем не менее сообщения этой группы также должны тщательно анализироваться, так как их появление также может свидетельствовать об ошибке в программе — например, из-за неверного понимания синтаксиса языка);

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

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

4. сообщения об ошибках , обнаружение которых привело к прекращению синтаксического контроля и построения объектного кода .

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

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

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

1. использование в программе неинициализированных переменных (то есть переменных, не получивших начального значения) ;

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

3. наличие в тексте программы фрагментов, никогда не выполняющихся;

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

5. наличие в тексте программы заведомо бесконечных циклов ;

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

Читайте также:  Тест по теме quot Эволюционное учение quot 11 класс тест по биологии 11 класс на тему

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

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

упрощено при применении следующих принципов:

1) проведение этих дополнительных форм статического контроля после завершения компиляции и только для синтаксически корректных программ ;

2) максимальное использование результатов компиляции программы и, в частности, информации, включаемой в листинг компилятора;

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

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

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

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

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

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

Надежность можно представить совокупностью следующих характеристик :

1) целостность программного средства (способность его к защите от отказов);

2) живучесть (способность к входному контролю данных и их проверки в ходе работы) ;

3) завершенность (бездеффектность готового программного средства, характеристика качества его тестирования);

4) работоспособность (способность программного средства к восстановлению своих возможностей поле сбоев).

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

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

— корректность как точное соответствие целям разработки программы (которые отражены в спецификации) при условии ее завершения или частичная корректность ;

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

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

1) доказательство частичной корректности ;

2) доказательство частичной некорректности ;

3) доказательство завершения программы ;

4) доказательство незавершения программы ;

5) доказательство тотальной (полной ) корректности (то есть одновременное решение первой и третьей задач);

6) доказательство некорректности (решение второй или четвертой задачи).

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

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

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

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

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

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

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

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

Наконец, динамический контроль программы — это проверка правильности программы при ее выполнении на компьютере, т.е. тестирование.

ЦЕЛИ , ПРИНЦИПЫ И ЭТАПЫ ТЕСТИРОВАНИЯ .

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

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

Другое определение тестирования ( у Г. Майерса ) тестирование — это процесс выполнения программы с целью обнаружения в ней ошибок. Такое определение цели стимулирует поиск ошибок в программах. Отсюда также ясно, что “удачным” тестом является такой, на котором выполнение программы завершилось с ошибкой. Напротив, “неудачным можно назвать тест, не позволивший выявить ошибку в программе.

Определение Г. Майерса указывает на объективную трудность тестирования : это деструктивный ( т.е. обратный созидательному ) процесс. Поскольку программирование — процесс конструктивный, ясно, что большинству разработчиков программных средств сложно “переключиться” при тестировании созданной ими продукции.

У Майерса сформулированы также основные принципы организации тестирования :

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

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

3) по тем же соображениям организация — разработчик программного обеспечения не должна “единолично ” его тестировать ( должны существовать организации, специализирующиеся на тестировании программных средств ) ;

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

5) необходимо тщательно подбирать тест не только для правильных ( предусмотренных ) входных данных, но и для неправильных (непредусмотренных) ;

6) при анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать ;

7) следует сохранять использованные тесты (для повышения эффективности повторного тестирования программы после ее модификации или установки у заказчика) ;

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

9) следует учитывать так называемый “принцип скопления ошибок” : вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части ;

10) следует всегда помнить , что тестирование — творческий процесс, а не относиться к нему как к рутинному занятию.

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

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

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

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

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

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

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

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

· тестирование отдельных модулей ;

· совместное тестирование модулей ;

· тестирование функций программного комплекса (т.е. поиск различий между разработанной программой и ее внешней спецификацией ) ;

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

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

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

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

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

1) построение эффективного множества тестов ;

2) выбор способа комбинирования (сборки) модулей при создании трестируемого варианта программы .

Источник