Аннотация: Лекция посвящена процессу тестирования программного кода. Определяются его задачи и цели, перечисляются основные методы и подходы к тестированию программного кода. Вводится понятие тестового окружения, рассматриваются его компоненты и различные виды окружения. Цель данной лекции: дать представление о процессе тестирования программного кода, его видах. Определить методы построения тестового окружения, необходимого для выполнения тестирования
3.1. Задачи и цели тестирования программного кода
Тестирование программного кода — процесс выполнения программного кода, направленный на выявление существующих в нем дефектов. Под дефектом здесь понимается участок программного кода, выполнение которого при определенных условиях приводит к неожиданному поведению системы (т.е. поведению, не соответствующему требованиям). Неожиданное поведение системы может приводить к сбоям в ее работе и отказам, в этом случае говорят о существенных дефектах программного кода. Некоторые дефекты вызывают незначительные проблемы, не нарушающие процесс функционирования системы, но несколько затрудняющие работу с ней. В этом случае говорят о средних или малозначительных дефектах.
Словарь тестировщика: что такое #тестирование ПО и какие цели тестирования
Задача тестирования при таком подходе — определение условий, при которых проявляются дефекты системы, и протоколирование этих условий. В задачи тестирования обычно не входит выявление конкретных дефектных участков программного кода и никогда не входит исправление дефектов — это задача отладки, которая выполняется по результатам тестирования системы.
Цель применения процедуры тестирования программного кода — минимизация количества дефектов (в особенности существенных) в конечном продукте. Тестирование само по себе не может гарантировать полного отсутствия дефектов в программном коде системы. Однако, в сочетании с процессами верификации и валидации, направленными на устранение противоречивости и неполноты проектной документации (в частности — требований на систему), грамотно организованное тестирование дает гарантию того, что система удовлетворяет требованиям и ведет себя в соответствии с ними во всех предусмотренных ситуациях.
При разработке систем повышенной надежности, например, авиационных, гарантии надежности достигаются с помощью четкой организации процесса тестирования, определения его связи с остальными процессами жизненного цикла , введения количественных характеристик, позволяющих оценивать успешность тестирования. При этом чем выше требования к надежности системы (ее уровень критичности), тем более жесткие требования предъявляются.
Таким образом, в первую очередь мы рассматриваем не конкретные результаты тестирования конкретной системы, а общую организацию процесса тестирования, используя подход «хорошо организованный процесс дает качественный результат». Такой подход является общим для многих международных и отраслевых стандартов качества, о которых более подробно будет рассказано в конце данного курса. Качество разрабатываемой системы при таком подходе является следствием организованного процесса разработки и тестирования, а не самостоятельным неуправляемым результатом.
Тестировщик с нуля | Урок 3 | Цели тестирования
Поскольку современные программные системы имеют весьма значительные размеры, при тестировании их программного кода используется метод функциональной декомпозиции. Система разбивается на отдельные модули (классы, пространства имен и т.п.), имеющие определенную требованиями функциональность и интерфейсы. После этого по отдельности тестируется каждый модуль — выполняется модульное тестирование . Затем происходит сборка отдельных модулей в более крупные конфигурации — выполняется интеграционное тестирование , и наконец, тестируется система в целом — выполняется системное тестирование .
С точки зрения программного кода, модульное, интеграционное и системное тестирование имеют много общего, поэтому пока основное внимание будет уделено модульному тестированию, особенности интеграционного и системного тестирования будут рассмотрены позднее.
В ходе модульного тестирования каждый модуль тестируется как на соответствие требованиям, так и на отсутствие проблемных участков программного кода, которые могут вызвать отказы и сбои в работе системы. Как правило, модули не работают вне системы — они принимают данные от других модулей, перерабатывают их и передают дальше. Для того, чтобы с одной стороны, изолировать модуль от системы и исключить влияние потенциальных ошибок системы, а с другой стороны — обеспечить модуль всеми необходимыми данными, используется тестовое окружение.
Задача тестового окружения — создать среду выполнения для модуля, эмулировать все внешние интерфейсы, к которым обращается модуль . Об особенностях организации тестового окружения пойдет речь далее в данной лекции.
Типичная процедура тестирования состоит в подготовке и выполнении тестовых примеров (также называемых просто тестами). Каждый тестовый пример проверяет одну «ситуацию» в поведении модуля и состоит из списка значений, передаваемых на вход модуля, описания запуска и выполнения переработки данных — тестового сценария и списка значений, которые ожидаются на выходе модуля в случае его корректного поведения. Тестовые сценарии составляются таким образом, чтобы исключить обращения к внутренним данным модуля, все взаимодействие должно происходить только через его внешние интерфейсы.
Выполнение тестового примера поддерживается тестовым окружением, которое включает в себя программную реализацию тестового сценария. Выполнение начинается с передачи модулю входных данных и запуска сценария. Реальные выходные данные , полученные от модуля в результате выполнения сценария, сохраняются и сравниваются с ожидаемыми. В случае их совпадения тест считается пройденным, в противном случае — не пройденным. Каждый не пройденный тест указывает на дефект либо в тестируемом модуле, либо в тестовом окружении, либо в описании теста.
Совокупность описаний тестовых примеров составляет тест-план — основной документ, определяющий процедуру тестирования программного модуля. Тест-план задает не только сами тестовые примеры, но и порядок их следования, который также может быть важен. Структура и особенности тест-планов, а также проблемы, связанные с порядком следования тестовых примеров, будут рассмотрены в следующих лекциях.
При тестировании часто бывает необходимо учитывать не только требования к системе, но и структуру программного кода тестируемого модуля. В этом случае тесты составляются таким образом, чтобы детектировать типичные ошибки программистов, вызванные неверной интерпретацией требований. Применяются проверки граничных условий, проверки классов эквивалентности. Отсутствие в системе возможностей, не заданных требованиями, гарантировано различными оценками покрытия программного кода тестами, т.е. оценками того, какой процент тех или иных языковых конструкций выполнен в результате выполнения всех тестовых примеров. Обо всем этом пойдет речь в завершение рассмотрения процесса тестирования программного кода.
3.2. Методы тестирования
3.2.1. Черный ящик
Основная идея в тестировании системы как черного ящика состоит в том, что все материалы, которые доступны тестировщику, — требования на систему, описывающие ее поведение, и сама система, работать с которой он может, только подавая на ее входы некоторые внешние воздействия и наблюдая на выходах некоторый результат. Все внутренние особенности реализации системы скрыты от тестировщика, — таким образом, система представляет собой «черный ящик», правильность поведения которого по отношению к требованиям и предстоит проверить.
С точки зрения программного кода черный ящик может представлять с собой набор классов (или модулей) с известными внешними интерфейсами, но недоступными исходными текстами.
Основная задача тестировщика для данного метода тестирования состоит в последовательной проверке соответствия поведения системы требованиям. Кроме того, тестировщик должен проверить работу системы в критических ситуациях — что происходит в случае подачи неверных входных значений. В идеальной ситуации все варианты критических ситуаций должны быть описаны в требованиях на систему и тестировщику остается только придумывать конкретные проверки этих требований. Однако в реальности в результате тестирования обычно выявляется два типа проблем системы.
- Несоответствие поведения системы требованиям
- Неадекватное поведение системы в ситуациях, не предусмотренных требованиями.
Отчеты об обоих типах проблем документируются и передаются разработчикам. При этом проблемы первого типа обычно вызывают изменение программного кода, гораздо реже — изменение требований. Изменение требований в данном случае может потребоваться из-за их противоречивости (несколько разных требований описывают разные модели поведения системы в одной и той же самой ситуации) или некорректности (требования не соответствуют действительности).
Проблемы второго типа однозначно требуют изменения требований ввиду их неполноты — в требованиях явно пропущена ситуация, приводящая к неадекватному поведению системы. При этом под неадекватным поведением может пониматься как полный крах системы, так и вообще любое поведение, не описанное в требованиях.
Тестирование черного ящика называют также тестированием по требованиям, т.к. это единственный источник информации для построения тест-плана.
3.2.2. Стеклянный (белый) ящик
При тестировании системы как стеклянного ящика тестировщик имеет доступ не только к требованиям к системе, ее входам и выходам, но и к ее внутренней структуре — видит ее программный код.
Доступность программного кода расширяет возможности тестировщика тем, что он может видеть соответствие требований участкам программного кода и определять тем самым, на весь ли программный код существуют требования. Программный код, для которого отсутствуют требования, называют кодом, не покрытым требованиями. Такой код является потенциальным источником неадекватного поведения системы. Кроме того, прозрачность системы позволяет углубить анализ ее участков, вызывающих проблемы — часто одна проблема нейтрализует другую, и они никогда не возникают одновременно.
3.2.3. Тестирование моделей
Тестирование моделей находится несколько в стороне от классических методов верификации программного обеспечения. Причина прежде всего в том, что объект тестирования — не сама система, а ее модель, спроектированная формальными средствами. Если оставить в стороне вопросы проверки корректности и применимости самой модели (считается, что ее корректность и соответствие исходной системе могут быть доказаны формальными средствами), то тестировщик получает в свое распоряжение достаточно мощный инструмент анализа общей целостности системы. На модели можно создать такие ситуации, которые невозможно создать в тестовой лаборатории для реальной системы. Работая с моделью программного кода системы, можно анализировать его свойства и такие параметры системы, как оптимальность алгоритмов или ее устойчивость.
Однако тестирование моделей не получило широкого распространения именно из-за трудностей, возникающих при разработке формального описания поведения системы. Одно из немногих исключений — системы связи, алгоритмический и математический аппарат которых достаточно хорошо проработан.
3.2.4. Анализ программного кода (инспекции)
Во многих ситуациях тестирование поведения системы в целом невозможно — отдельные участки программного кода могут никогда не выполняться, при этом они будут покрыты требованиями. Примером таких участков кода могут служить обработчики исключительных ситуаций. Если, например, два модуля передают друг другу числовые значения и функции проверки корректности значений работают в обоих модулях, то функция проверки модуля-приемника никогда не будет активизирована, т.к. все ошибочные значения будут отсечены еще в передатчике.
В этом случае выполняется ручной анализ программного кода на корректность, называемый также просмотрами или инспекциями кода. Если в результате инспекции выявляются проблемные участки, то информация об этом передается разработчикам для исправления наравне с результатами обычных тестов.
3.3. Тестовое окружение
Основной объем тестирования практически любой сложной системы обычно выполняется в автоматическом режиме. Кроме того, тестируемая система обычно разбивается на отдельные модули, каждый из которых тестируется вначале отдельно от других, затем в комплексе.
Это означает, что для выполнения тестирования необходимо создать некоторую среду, которая обеспечит запуск и выполнение тестируемого модуля, передаст ему входные данные , соберет реальные выходные данные , полученные в результате работы системы на заданных входных данных. После этого среда должна сравнить реальные выходные данные с ожидаемыми и на основании данного сравнения сделать вывод о соответствии поведения модуля заданному (Рис 3.1).
увеличить изображение
Рис. 3.1. Обобщенная схема среды тестирования
Тестовое окружение также может использоваться для отчуждения отдельных модулей системы от всей системы. Разделение модулей системы на ранних этапах тестирования позволяет более точно локализовать проблемы, возникающие в их программном коде. Для поддержки работы модуля в отрыве от системы тестовое окружение должно моделировать поведение всех модулей, к функциям или данным которых обращается тестируемый модуль .
Поскольку тестовое окружение само является программой (причем зачастую реализованной не на том языке программирования, на котором написана система), оно само должно быть протестировано. Целью тестирования тестового окружения является доказательство того, что тестовое окружение никаким образом не искажает выполнение тестируемого модуля и адекватно моделирует поведение системы.
Источник: intuit.ru
Тестирование: цели и принципы
Откуда вообще возникла необходимость в тестировании? Люди совершают ошибки. Одни из них могут быть незначительными, другие иметь самые разрушительные последствия. Все, что производится человеком, может содержать ошибки (так уж мы, люди, устроены). Именно поэтому любой продукт нуждается в проверке – тестировании.
Если не тестировать, есть вероятность выпуска некачественного продукта, который пользователь даже не сможет нормально запустить. Если говорить обо мне, то я не буду пользоваться продуктом, который плохо работает и в котором постоянно всплывают ошибки и мешают работе в нем. А вы?)
Тестирование — это …
Тестирование (testing) — это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов [глоссарий ISTQB].
Давайте разберем это определение по частям.
Во-первых, тестирование, это процесс исследования или изучения программы.
Во-вторых, исследуем мы зачем? Чтобы проверить, что программа соответствует ожиданиям, то есть мы запускаем программу и смотрим, что весь ее функционал соответствует техническому заданию.
И наконец, в третьих, как мы это будет делать? С помощью заранее написанных или подготовленных проверок.
Если все это совместить и сказать простым языком, то получим следующее определение.
Тестирование — это процесс исследования программы с целью определить, что программа работает в соответствии с заявленными требованиями с помощью заранее подготовленных проверок.
Цели тестирования
Цели тестирования сильно зависят от целей самого проекта. Но можно выделить основные общие цели:
- Проверка, все ли указанные требования выполнены.
Что это значит? У каждого продукта есть техническое задание (ТЗ) в том или ином виде. Именно оно определяет, как будет выглядеть программа. ТЗ задает соответствующие требования, а мы, как тестировщики, должны проверить, что все требования из ТЗ не только реализованы, но и работают правильно. - Создание уверенности в уровне качества объекта тестирования.
Напрямую тестирование не влияет на качество продукта. Грубо говоря, качество — это удовлетворение ожиданий пользователей. А удовлетворение зависит от очень многих факторов.
Тем не менее, поиск и исправление дефектов позволяет продукту работать именно так, как он был задуман. И, как минимум, можно сказать, что если программа работает корректно и соответствует заданным критериям, то достигнут определенный уровень качества объекта тестирования. - Предотвращение дефектов.
Тестирование — не только поиск багов на уже реализованном продукте. Существует также тестирование на более ранних этапах, например, тестирование документации.
Заранее протестировав тоже ТЗ, тестировщик может указать на потенциальные проблемы, которые могут появиться в результате разработки программы. А зная о таких проблемах заранее, можно избежать вполне реальных багов в будущем. - Обнаружение отказов и дефектов.
Здесь все просто: поиск багов в программном обеспечении (ПО) является неотъемлемой частью тестирования. - Предоставление заинтересованным лицам достаточной информации, позволяющей им принять обоснованные решения (особенно в отношении уровня качества объекта тестирования).
Тестирование — это все-таки услуга. Мы, как тестировщики, не влияем напрямую на исправление дефектов. Но можем показать текущее состояние продукта, выраженное в количестве багов, путем оформления баг-репортов. Заинтересованные лица (например, руководитель проекта) могут оценить текущие проблемы и принять решение о выпуске или не выпуске продукта. - Снижение уровня риска ненадлежащего качества программного обеспечения (например, пропущенные сбои в работе).
Чем лучше тестирование, тем меньший риск пропуска критичных багов. А значит, что риск возникновения ненадлежащего качества ПО уменьшается.
Принципы тестирования
За последние пятьдесят лет был предложен ряд принципов тестирования, которые являются общим руководством для тестирования в целом:
- Тестирование демонстрирует наличие дефектов, а не их отсутствие.
Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, тестирование не доказывает его корректности. Почему? Потому что есть пункт 2. - Исчерпывающее тестирование недостижимо.
Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо попытки исчерпывающего тестирования должны использоваться анализ рисков, методы тестирования и расстановка приоритетов, чтобы сосредоточить усилия по тестированию.
Элементарно, попробуйте посчитать сколько усилий необходимо приложить, чтобы проверить все комбинации калькулятора. И даже если вы продумаете абсолютно все варианты, то всегда найдется еще один, о котором вы не знаете. - Раннее тестирование сохраняет время и деньги.
Активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения. Это как раз позволяет находить дефекты на ранних стадиях.
Раннее тестирование иногда называют «сдвигом влево» по ISTQB. Тестирование на ранних этапах жизненного цикла разработки программного обеспечения помогает сократить или исключить дорогостоящие изменения. Хотя бы потому что вовремя замеченную ошибку в ТЗ исправить намного проще, чем когда по этому ТЗ уже будет разработана функциональность. - Кластеризация дефектов (Скопление дефектов).
Обычно небольшое количество модулей содержит большинство дефектов, обнаруженных во время тестирования перед выпуском. То есть баги имеют свойство скапливаться где-то в одном месте и, если нашли интересную ошибку в функционале, есть очень большая вероятность найти рядом еще одну. - Парадокс (эффект) пестицида.
Если одни и те же тесты будут выполняться снова и снова, в конечном счете эти тесты больше не будут находить новых дефектов. Для обнаружения новых ошибок может потребоваться изменение существующих тестов и тестовых данных, а также написание новых тестов.
Тесты больше не эффективны при обнаружении дефектов, так же как пестициды через некоторое время больше не эффективны при борьбе с вредителями. - Тестирование зависит от контекста.
Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение управления производством, в котором критически важна безопасность, тестируется иначе, чем мобильное приложение электронной коммерции. - Заблуждение об отсутствии ошибок.
Некоторые организации ожидают, что тестировщики смогут выполнить все возможные тесты и найти все возможные дефекты, но принципы 2 и 1 говорят нам, что это невозможно.
Кроме того, ошибочно ожидать, что простое нахождение и исправление большого числа дефектов обеспечит успех продукту. Например, тщательное тестирование всех указанных требований и исправление всех обнаруженных дефектов может привести к созданию системы, которая будет трудной в использовании, не будет соответствовать потребностям и ожиданиям пользователей или будет хуже по сравнению с другими конкурирующими системами.
Итак, сегодня мы разобрали что такой тестирование и зачем оно необходимо, выяснили его цели и принципы. В следующей статье мы поговорим об этапах тестирования.
Источник: sedtest-school.ru
Тестирование программ
Результативным считается тест, который приводит к обнаружению ошибки. Тестирование – деструктивный процесс.
Тест – набор входных данных, набор ожидаемых результатов, набор условий, разработанных для проверки определенного пути выполнения программы.
Особенности
1) Частое отсутствие полностью определенного эталона, которому должны соответствовать результаты
2) Высокая сложность программ исключает исчерпывающее тестирование (проверка всех возможных маршрутов выполнения)
3) Невысокая формализация критериев завершения тестирования
Основные принципы тестирования
1) Нельзя планировать тестирование в предположении, что ошибки отсутствуют
2) Следует избегать тестирования программы ее автором
3) Описание предполагаемых значений результатов должно быть неотъемлемой частью теста
4) Тесты для неправильных входных данных следует разрабатывать также тщательно, как и для правильных
5) Следует понимать, сто вероятность наличия необнаруженных ошибок пропорциональна числу уже обнаруженных
6) Не следует выбрасывать тесты, даже если программа уже не используется
Объекты тестирования. Категории тестов
1) Спецификации программных модулей, групп программ и программных комплексов
— полнота и согласованность функций программных компонент
— согласованность интерфейсов программных компонент (для групп программ и комплексов)
2) Программные модули
— преобразование данных, выполняемое модулем
— полнота функций, выполняемых модулем
3) Группы программ, объединенные для решения законченной функциональной задачи
— то же, что и для модулей
— интерфейс между программами
— тестирование потребления ресурсов
4) Программный комплекс, используемый для решения нескольких функциональных задач
— полнота решения функциональных задач
— функционирование программ в критических ситуациях
— тестирование потребления ресурсов
— оценка надежности работы комплекса
— эффективность защиты от искажения общих данных
5) Программное средство, сдаваемое в опытную эксплуатацию
— то же, что и для 4)
— удобство инсталляции рабочей версии программы
— проверка работы при изменении конфигурации оборудования
— проверка наличия и корректности документации
— испытание на соответствие техническому заданию
6) Программное средство на стадии сопровождения
— удобство модификации, типа расширения функциональности и повышения эффективности
3 – Группы программ
4 – Программные комплексы на стадии отладки
5 – Программные комплексы как продукты
Виды и методы тестирования
Особенности нисходящего тестирования:
— с самого начала выполняется проверка главных функций – концептуальная проверка
— необходимость разработки заглушек, часто достаточно интеллектуальных
— параллельная разработка модулей различных уровней не всегда обеспечивает возможность нужной последовательности тестирования модулей разных уровней
Особенности восходящего тестирования
— для тестирования используются готовые модули нижних уровней
— необходимость разработки тест-драйверов для управления работой нижних уровней с верхних
— отложенная проверка основной концепции функционирования комплекса
1) Модульное тестирование. Включает проверку:
— корректности структуры модуля
— корректности основных конструктивных компонент
— полноты и качества реализации функций обработки данных
Структурная корректность проверяется структурными методами по принципу «белого ящика»
2) Интеграционное тестирование. Проверка:
— корректности объединения модулей в группу или комплекс программ
Проводится на основе 2-х подходов:
— монолитное тестирование, при котором модули сразу объединяются в единый комплекс и после этого вместе тестируются
— инкрементальное (пошаговое), модули подключаются друг к другу последовательно (снизу вверх или сверху вниз)
Использует структурную проверку подключаемых модулей и функциональную проверку полноты и качества реализации функций. Функциональные проверки осуществляются по принципу «черного ящика»
3) Системное тестирование. Обеспечивает проверку соответствия программного средства специфицированным требованиям в заданной среде и режимах функционирования. Предусматривает следующие виды тестирования:
— стрессовое тестирование (тестирование на повышенных нагрузках по использованным ресурсам)
— тестирование безопасности (защита от несанкционированного доступа)
— тестирование восстановления при сбоях
В последнее время стало широко применяться альфа и бета тестирование – это виды тестирования, выполняемые с участием заказчика. Альфа тестирование выполняется на территории разработчика в условиях ограниченного времени (не более недели). Бета тестирование выполняется после введения программы в опытную эксплуатацию на территории заказчика, проводится достаточно долго (норма 1 год).
Статистика ошибок в программных продуктах по типам.
Ошибки представления и обработки данных
Полнота и корректность функций
Все методы делятся на две неравнозначных группы:
Основные методы ручного:
Методы статического тестирования
Общая черта – они используют визуальный контроль программы по ее тексту группой из 3-4 человек, один из которых автор программы. Целью проверки является обнаружение ошибок, но не их устранение. Основная концепция – наличие ошибок не есть вина автора программы, а несовершенство средств разработки программы и сложность программы как некоторой системы. При нормальном проведении статические методы тестирования позволяют обнаруживать 30-70% первоначальных ошибок в программе. Они, в отличие от машинных, позволяют обнаруживать типовые группы ошибок автора.
Инспекция кода. В группу входит 4 человека: руководитель проведения инспекции, автор программы, проектировщик и тестировщик. За неделю до инспекции руководитель раздает всем участникам листинг программ, которые будут инспектироваться.
1) автор рассказывает логику работы программы и отвечает на вопросы, преследующие цель обнаружения ошибок
2) программа анализируется по типовому списку часто встречающихся ошибок:
— ошибки обращения к данным (неинициализирование данных, выход индексов за границы массивов, ссылки на пустую память)
— ошибки описания данных, соответствие заданных типов и значений
— ошибки передач управления (зацикливание, корректность завершения программы)
— ошибки интерфейса (ошибки, связанные с взаимодействием частей друг с другом)
Результат инспекции кода:
— обучение автора улучшенным методам кодирования программ
Сквозной просмотр. Начинается так же как и инспекции кода, но в процессе заседания группы ознакомление с программой выполняется путем небольшого числа сеансов ручного тестирования программы на простых данных.
Структурное тестирование программных модулей
При структурном тестировании проверяется
— прохождение тестов по логике программы, в качестве элементов которой выступают вершины, дуги, маршруты, условия и комбинации условий управляющего графа программы
— в последнее время проверяется прохождение потока данных по информационному графу программы, которое выявляет аномалии в обработке данных
Тестирование на основе потока управления
Вводят критерии отбора элементов для тестирования:
1) покрытие операторов (покрытие вершин УГП, покрытие строк кода). Необходимо проверить выполнение каждого оператора хотя бы один раз. Нужно реализовать путь a-c-e (например при тестовом наборе a=2, b=0, x=3, результат x=2.5). Не проверяется прохождение пути a-b-d. Не проверяются отдельные условия, например OR вместо 1 будет x
3) Критерий покрытия условий. Каждое условие, используемое в программе должно выполняться хотя бы один раз. Используются следующие условия: A>1, B=0, A=2, x>1. Нужно реализовать проверки: A>1, A1, x
4) Комбинированный критерий «условий/решений», который должен проверять все условия в программе и хотя бы один раз пройти по каждой дуге.
Следующие тестовые наборы: (A=2, B=0, x=4) a-c-e, (A=1, B=1, x=1) a-b-d.
5) Комбинаторное покрытие условий. Должны быть покрыты следующие комбинации условий:
6) Критерий покрытия вызовов. Обеспечивает проверку корректности вызова каждой процедуры или функции в программе.
7) Критерий покрытия путей. Применяется в ограниченном варианте, когда при использовании циклов рассматриваются только отдельные варианты проверки цикла: тело цикла не выполняется ни разу, тело цикла выполняется один раз, тело цикла выполняется k раз (k
Структурное тестирование на основе потока данных
Работа любой программы представляется как обработка потока данных, передаваемых от ее входа на выход. Если имеется управляющий граф программы вида
Информационный граф программы представляется пунктирными линиями.
Для каждой вершины i УГП можно определить множество def(i) – данных, определенных в этой вершине и множество use(i) – данных, используемых в этой вершине.
Для тестирования надо выделить DU цепочки, которые имеют следующий вид DU=(Data, i, j), Data – данное, i – вершина, в которой создается данное, j – вершина, в которой используется данное.
Для нашего примера множество DU цепочек:
После формирования набора DU цепочек выполняется отображение DU цепочек во фрагменты УГП, соответствующие путям определения и использования данной цепочки.
Для цепочки (a, 1, 4) путь 1-2-3-4. По информационному графу программы порождается путь в управляющем графе программы, который тестируется. Этот способ называется «стратегия требуемых пар»
Недостаток: трудность выбора минимального количества тестов, обеспечивающих эффективную проверку всех DU цепочек.
Функциональное тестирование (ФТ)
Структурное тестирование не позволяет проверить все функции, возлагаемые на программу, потому что некоторые функции могут просто отсутствовать в предложенной реализации.
Функциональное тестирование – это тестирование, необходимое для проверки соответствия программного продукта функциональным требованиям, заданным в спецификации. При выполнении ФТ логика работы программы игнорируется и все внимание фокусируется на выходных значениях, полученных в результате обработки заданных входных наборов. Обычно ФТ обнаруживаются следующие виды ошибок:
1) некорректные или отсутствующие функции
2) ошибки интерфейса
3) ошибки потребления ресурсов (превышение занимаемых памяти или времени выполнения)
4) ошибки инициализации или завершения программы
Для проведения ФТ необходимо иметь: наборы входных данных, приводящих к аномалиям выполнения программы, наборы выходных данных, позволяющих обнаруживать дефекты в работе программы.
Методы ФТ должны обеспечивать:
1) сокращение необходимого числа тестовых вариантов (проверки выполняются динамически)
2) выявлять классы ошибок, а не отдельные ошибки
Методы ФТ как правило применяются на более поздних стадиях тестирования, чем структурные.
Метод разбиения на классы эквивалентности.
Область входных данных разбивается на классы эквивалентности (КлЭ), представляющие собой набор данных с общими свойствами, обработка которых программой производится совершенно одинаково. При обработке используются одни и те же операторы и одни и те же связи. КлЭ делятся на правильные (допустимые) и неправильные. КлЭ определяются по спецификации на программу, например следующим образом: 2000080000. Разработка тестов состоит из 2 этапов:
1) разбиение на КлЭ
2) построение тестов
Выделение КлЭ по спецификации – процесс эвристический
1) если проверяемое входное данное представлено в виде диапазона значений, то строится один правильный класс (внутри диапазона) и два неправильных
2) если конкретное значение, то строится один правильный и два неправильных КлЭ
3) если входное условие описывает множество значений m=, то строится по одному правильному классу для каждого из значений и один неправильный класс для значений, не принадлежащих множеству (m!=a)(m!=c)
4) если есть основание считать, что элементы КлЭ трактуются программой неодинаково, то этот класс необходимо разбить на меньшие классы с разнесением по-разному трактуемых элементов
1) Каждому КлЭ присваивается уникальный номер
2) Строятся тесты для правильных КлЭ, чтобы каждый тест покрывал как можно больше этих классов
3) Строятся тесты для неправильных классов, которые должны быть индивидуальны, поскольку проверки с ошибочными входами могут скрывать друг друга.
Анализ граничных условий.
Метод является развитием предыдущего в том смысле, что под граничными условиями понимаются ситуации, возникающие на границах входных и выходных КлЭ.
Отличается от предыдущего
1) при выборе элементов КлЭ используются значения на и вблизи границ классов -1.0
2) метод должен рассматривать не только входные, но КлЭ для выходных значений.
Общее правило использования метода:
1) построить тесты для значений, лежащих на границе области, и тесты с неправильными данными, немного выходящих за пределы границ
2) если обрабатывается определенное количество файлов в заданном диапазоне, то построить тесты для граничных значений файлов, на 1 больше и меньше верхней и нижней границы соответственно
3) применить подходы 1, 2 для каждого из выходных значений
4) если проверяется упорядоченное множество значений, то необходимо выполнить проверки первого и последнего элементов.
Недостатками рассмотренных методов является то, что они не позволяют проверять комбинации условий.
Метод функциональных диаграмм (метод диаграмм причинно-следственных связей ДПС)
Метод позволяет формально генерировать результативные тесты, позволяющие обнаруживать неоднозначность требований спецификаций при комбинировании входных условий
Функциональная диаграмма – это формальный графо-аналитический язык, позволяющий описывать спецификации, написанные на естественном языке.
Методика построения функциональных диаграмм
1) спецификация разбивается на «рабочие участки», т.е. такие участки, для которых диаграмма не будет слишком громоздкой
2) спецификации выделяются причины и следствия. Причина – отдельное входное условие или КлЭ входных условий, следствие – выходное условие, результат выполнения программы. Каждой причине и следствию присваивается уникальный номер
3) анализируется семантика информации, заданной в спецификации, и строится булевский граф, связывающий причины и следствия, который является функциональной диаграммой. Каждый узел графа может принимать 2 значения: 1 – присутствует (выполняется)
Для представления диаграмм используются следующие базовые символы:
Задана спецификация. Файл обновляется, если символ, считываемый в позиции 1 равен а А или Б, а символ в позиции 2 стоит цифра. Если первый символ ошибочный, то сообщение Х1, если второй не цифра, то сообщение Х2.
1) символ в позиции 1 равен А
2) символ в позиции 1 равен Б
3) символ в позиции 2 цифра
1) файл обновляется
2) выдается сообщение Х1
3) выдается сообщение Х2
В приведенной диаграмме есть проблема: никак не ограничено применение причин 1 и 2.
Для учета невозможных комбинаций причин или следствий предусмотрены дополнительные базовые элементы.
Е – не могут быть одновременно
I – не могут быть одновременно 0
R – требует (a=1, то и b=1)
M – запрещает (a=1, то b=0)
Генерация таблицы решений
Использование столбцов таблицы решений в качестве тестов
Генерация таблицы решений:
1) Формируются строки, соответствующие причинам и следствиям
2) Выбирается некоторое следствие, которое имеет значение 1
3) Находятся комбинации причин, которые обеспечивают такое значение следствия
Незаполненные элементы строк причин могут принимать любые значения
Источник: studfile.net