СДЕЛАЙТЕ СВОИ УРОКИ ЕЩЁ ЭФФЕКТИВНЕЕ, А ЖИЗНЬ СВОБОДНЕЕ

Благодаря готовым учебным материалам для работы в классе и дистанционно

Скидки до 50 % на комплекты
только до

Готовые ключевые этапы урока всегда будут у вас под рукой

Организационный момент

Проверка знаний

Объяснение материала

Закрепление изученного

Итоги урока

Тестирование потока управления. Тестирование комплексов программ

Категория: Информатика

Нажмите, чтобы узнать подробности

Просмотр содержимого документа
«Тестирование потока управления. Тестирование комплексов программ»

Тестирование потока управления. Тестирование комплексов программ

Тестирование потока управления. Тестирование комплексов программ

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

Тестирование на основе потока управления

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

  • покрытие  операторов (вершин графа) –  заключается в выполнении  каждого оператора программы  хотя бы  один раз . Этот критерий является весьма слабым (пропускает много ошибок), так как выполнение каждого оператора программы хотя бы один раз есть  необходимое, но не достаточное условие для приемлемого тестирования по методу  «белого ящика» ;
  • покрытие  ветвей (решений)  – при использовании этого критерия  каждая дуга должна быть пройдена хотя бы один раз . Критерий покрытия решений обычно удовлетворяет критерию покрытия операторов, поскольку каждый оператор лежит на некотором пути.
покрытие  условий  –  каждое логическое условие  в программе  должно выполняться хотя бы один раз . покрытие  условий/решений  – поскольку критерии покрытия решений и условий не заменяют друг друга, поэтому их можно объединить, получив критерий покрытия  условий/решений . Он требует такого набора тестов, чтобы все возможные результаты каждого условия в решении выполнялись по крайней мере один раз и все результаты каждого решения выполнялись по крайней мере один раз.   Недостатком  критерия покрытия  решений/условий  является  невозможность  его  применения для выполнения всех результатов всех условий (некоторые условия могут быть скрыты другими условиями).   Например, результаты условий при выполнении операций  И  и  ИЛИ  могут блокировать действия других условий. Так, если условие  И  есть  ложь , то никакое из последующих условий в выражении не будет выполнено. Аналогично, если условие  ИЛИ  есть   истина , то никакое из последующих условий в выражении не будет выполнено.
  • покрытие  условий  –  каждое логическое условие  в программе  должно выполняться хотя бы один раз .
  • покрытие  условий/решений  – поскольку критерии покрытия решений и условий не заменяют друг друга, поэтому их можно объединить, получив критерий покрытия  условий/решений . Он требует такого набора тестов, чтобы все возможные результаты каждого условия в решении выполнялись по крайней мере один раз и все результаты каждого решения выполнялись по крайней мере один раз.   Недостатком  критерия покрытия  решений/условий  является  невозможность  его  применения для выполнения всех результатов всех условий (некоторые условия могут быть скрыты другими условиями).   Например, результаты условий при выполнении операций  И  и  ИЛИ  могут блокировать действия других условий. Так, если условие  И  есть  ложь , то никакое из последующих условий в выражении не будет выполнено. Аналогично, если условие  ИЛИ  есть   истина , то никакое из последующих условий в выражении не будет выполнено.
2) & (A  могут быть реализованы только три комбинации условий. Набор тестов, удовлетворяющий критерию комбинаторного покрытия условий, удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий; покрытие  путей –  каждый путь хотя бы один раз (это  наиболее полный, но нереализуемый критерий ); покрытие функций - каждая функция должна быть выполнена хотя бы один раз; покрытие  вызовов  – каждый вызов каждой функции хотя бы один раз. " width="640"
  • комбинаторное покрытие условий –  требует такого набора тестов, чтобы  все возможные комбинации результатов условия  в каждом решении  выполнялись по крайней мере один раз . Слово  возможные  употреблено потому, что не все комбинации условий могут быть реализуемыми; например, в выражении  (A2) & (A  могут быть реализованы только три комбинации условий. Набор тестов, удовлетворяющий критерию комбинаторного покрытия условий, удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий;
  • покрытие  путей –  каждый путь хотя бы один раз (это  наиболее полный, но нереализуемый критерий );
  • покрытие функций - каждая функция должна быть выполнена хотя бы один раз;
  • покрытие  вызовов  – каждый вызов каждой функции хотя бы один раз.
  Тестирование комплексов программ Невозможность исчерпывающего тестирования . Из-за высокой сложности программ и ограниченности ресурсов для этого проводится проверка в минимально необходимых объёмах.  Невозможность создания единственного универсального метода тестирования . На практике применяют ряд различающихся методов и критериев тестирования.  Важность раннего тестирования . Чтобы найти неисправности как можно раньше, активности по тестированию должны быть начаты на ранних стадиях разработки. 

Тестирование комплексов программ

  • Невозможность исчерпывающего тестирования . Из-за высокой сложности программ и ограниченности ресурсов для этого проводится проверка в минимально необходимых объёмах. 
  • Невозможность создания единственного универсального метода тестирования . На практике применяют ряд различающихся методов и критериев тестирования. 
  • Важность раннего тестирования . Чтобы найти неисправности как можно раньше, активности по тестированию должны быть начаты на ранних стадиях разработки. 
Цели тестирования . Они включают выявление ошибок и недочётов, проверку соответствия программы требованиям и спецификациям, улучшение надёжности и оптимизацию производительности.  Основные принципы тестирования . Например, описание предполагаемых значений выходных данных или результатов должно быть неотъемлемой частью теста, а результаты каждого теста нужно досконально изучать. 
  • Цели тестирования . Они включают выявление ошибок и недочётов, проверку соответствия программы требованиям и спецификациям, улучшение надёжности и оптимизацию производительности. 
  • Основные принципы тестирования . Например, описание предполагаемых значений выходных данных или результатов должно быть неотъемлемой частью теста, а результаты каждого теста нужно досконально изучать. 
Тестирование потока управления  — это подход к тестированию на основе структуры, при котором тестовые сценарии описывают выполнение определённых последовательностей событий. 
  • Тестирование потока управления  — это подход к тестированию на основе структуры, при котором тестовые сценарии описывают выполнение определённых последовательностей событий. 
При тестировании потока управления используются различные техники : Тестирование альтернатив .  Тестирование условий .  Тестирование путей . Для каждого из них имеются определённые подходы и уровни покрытия потока управления. 
  • При тестировании потока управления используются различные техники :
  • Тестирование альтернатив
  • Тестирование условий
  • Тестирование путей . Для каждого из них имеются определённые подходы и уровни покрытия потока управления. 
Тестирование потоков управления проводится в соответствии с принципом «белого ящика» , при котором известна структура программы и доступен исходный код. Тестовая оснастка реализуется в теле проверяемого элемента программной системы. 
  • Тестирование потоков управления проводится в соответствии с принципом «белого ящика» , при котором известна структура программы и доступен исходный код. Тестовая оснастка реализуется в теле проверяемого элемента программной системы. 
Выделяют ряд частных критериев , используемых при тестировании потоков управления: Тестирование команд (критерий C0) . Тестовый набор должен обеспечить выполнение каждого оператора хотя бы один раз.  Тестирование ветвей (критерий C1) . Обеспечивает исполнение каждой ветви хотя бы один раз.  Тестирование маршрутов (критерий C2) . Тестовые наборы, построенные в соответствии с данным критерием, должны обеспечивать исполнение каждого пути программы как минимум один раз.
  • Выделяют ряд частных критериев , используемых при тестировании потоков управления:
  • Тестирование команд (критерий C0) . Тестовый набор должен обеспечить выполнение каждого оператора хотя бы один раз. 
  • Тестирование ветвей (критерий C1) . Обеспечивает исполнение каждой ветви хотя бы один раз. 
  • Тестирование маршрутов (критерий C2) . Тестовые наборы, построенные в соответствии с данным критерием, должны обеспечивать исполнение каждого пути программы как минимум один раз.
Тестирование ИС  – деятельность по проверке программного кода и документации. Она должна заранее планироваться и систематически проводиться тестировщиками. Этапы тестирования: 1) Проверка требований к ПП на полноту. 2) Определение методов тестирования. 3) Разработка стратегии тестирования. 4) Разработка плана тестирования. 5) Создание наборов тестов. 6) Создание отчета о тестировании.
  • Тестирование ИС  – деятельность по проверке программного кода и документации. Она должна заранее планироваться и систематически проводиться тестировщиками.
  • Этапы тестирования:
  • 1) Проверка требований к ПП на полноту.
  • 2) Определение методов тестирования.
  • 3) Разработка стратегии тестирования.
  • 4) Разработка плана тестирования.
  • 5) Создание наборов тестов.
  • 6) Создание отчета о тестировании.
Виды тестирования ИС: Блочное тестирование  – это тестирование полного класса, метода или небольшого приложения, выполняемое отдельно от прочих частей системы. Тестирование компонента  – это тестирование класса, пакета, небольшого приложения или другого элемента системы, выполняемое в изоляции от остальных частей системы. Интеграционное тестирование  – это совместное выполнение двух или более классов, пакетов, компонентов или подсистем. Регрессивное тестирование  – это повторное выполнение тестов, направленное на обнаружение дефектов в программе, уже прошедшей этот набор тестов. Тестирование системы  – это выполнение ПО в его окончательной конфигурации, интегрированного с другими программными и аппаратными системами.
  • Виды тестирования ИС:
  • Блочное тестирование  – это тестирование полного класса, метода или небольшого приложения, выполняемое отдельно от прочих частей системы.
  • Тестирование компонента  – это тестирование класса, пакета, небольшого приложения или другого элемента системы, выполняемое в изоляции от остальных частей системы.
  • Интеграционное тестирование  – это совместное выполнение двух или более классов, пакетов, компонентов или подсистем.
  • Регрессивное тестирование  – это повторное выполнение тестов, направленное на обнаружение дефектов в программе, уже прошедшей этот набор тестов.
  • Тестирование системы  – это выполнение ПО в его окончательной конфигурации, интегрированного с другими программными и аппаратными системами.
Разработка и выполнение тестов Требования к хорошему тесту: 1)   Должна быть достаточной вероятность выявления тестом ошибки . Разрабатывая тестовые примеры, необходимо проанализировать все возможные варианты сбоев программы или ее некорректной работы. 2)   Набор тестов не должен быть избыточным . Если два теста предназначены для выявления одной и той же ошибки, то достаточно выполнить только один из них. 3)   Тест должен быть наилучшим в своей категории . В группе похожих тестов одни могут быть эффективнее других. Поэтому нужно выбирать тот тест, который с наибольшей вероятностью выявит ошибку. 4)   Тест не должен быть слишком простым или слишком сложным . Большой и сложный тест трудно понять, выполнить и долго создавать. Поэтому лучше всего разрабатывать простые, но всё же не совсем элементарные тестовые примеры.  
  • Разработка и выполнение тестов
  • Требования к хорошему тесту:
  • 1)   Должна быть достаточной вероятность выявления тестом ошибки . Разрабатывая тестовые примеры, необходимо проанализировать все возможные варианты сбоев программы или ее некорректной работы.
  • 2)   Набор тестов не должен быть избыточным . Если два теста предназначены для выявления одной и той же ошибки, то достаточно выполнить только один из них.
  • 3)   Тест должен быть наилучшим в своей категории . В группе похожих тестов одни могут быть эффективнее других. Поэтому нужно выбирать тот тест, который с наибольшей вероятностью выявит ошибку.
  • 4)   Тест не должен быть слишком простым или слишком сложным . Большой и сложный тест трудно понять, выполнить и долго создавать. Поэтому лучше всего разрабатывать простые, но всё же не совсем элементарные тестовые примеры.
  •