какие существуют разновидности структурных критериев
Критерии выбора тестов
Функциональные критерии (класс II)
Спецификация требований может содержать сотни и тысячи пунктов требований к программному продукту и каждое из этих требований при тестировании должно быть проверено в соответствии с критерием не менее чем одним тестом
Следует заметить, что грамматика должна быть достаточно простой, чтобы трудоемкость разработки соответствующего набора тестов была реальной (вписывалась в сроки и штат специалистов, выделенных для реализации фазы тестирования )
При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
Очень популярный на практике критерий, который, однако, не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту).
При этом все комбинации непротиворечивых условий надо подтвердить, а условия противоречий следует обнаружить и ликвидировать.
Пример применения функциональных критериев тестирования для разработки набора тестов по критерию классов входных данных
Пусть для решения задачи тестирования системы «Система управления автоматизированным комплексом хранения подшипников» (см. Приложение 1, FS) был разработан следующий фрагмент спецификации требований:
Теперь рассмотрим тестовые случаи:
Тестовый случай 1 (покрывает класс 4):
Система запрашивает статус склада (вызов функции GetStoreStat ) и получает 32
Тестовый случай 2 (покрывает класс 5):
Система запрашивает статус склада (вызов функции GetStoreStat ) и согласно пункту спецификации при ошибочном значении статуса склада в журнал добавляется сообщение «СКЛАД : ОШИБКА : Неопределенный статус».
Оценка Покрытия Программы и Проекта
Мутационный критерий (класс IV)
Стохастические критерии (класс III)
Функциональные критерии (класс II)
Структурные критерии (класс I).
Классы критериев
Требования к идеальному критерию тестирования
Три фазы тестирования
Реализация тестирования разделяется на три этапа:
· Создание тестового набора (test suite) путем ручной разработки или автоматической генерации для конкретной среды тестирования (testing environment).
· Прогон программы на тестах, управляемый тестовым монитором (test monitor, test driver [IEEE Std 829-1983]) с получением протокола результатов тестирования (test log).
· Оценка результатов выполнения программы на наборе тестов с целью принятия решения о продолжении или остановке тестирования.
Требования к идеальному критерию:
1. Критерий должен быть достаточным, т.е. показывать, когда некоторое конечное множество тестов достаточно для тестирования данной программы.
2. Критерий должен быть полным, т.е. в случае ошибки должен существовать тест из множества тестов, удовлетворяющих критерию, который раскрывает ошибку.
3. Критерий должен быть надежным, т.е. любые два множества тестов, удовлетворяющих ему, одновременно должны раскрывать или не раскрывать ошибки программы
4. Критерий должен быть легко проверяемым, например вычисляемым на тестах
Для нетривиальных классов программ в общем случае не существует полного и надежного критерия, зависящего от программ или спецификаций.
Поэтому мы стремимся к идеальному общему критерию через реальные частные.
1. Структурные критерии используют информацию о структуре программы (критерии так называемого «белого ящика»)
2. Функциональные критерии формулируются в описании требований к программному изделию (критерии так называемого «черного ящика»)
3. Критерии стохастического тестирования формулируются в терминах проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической гипотезы.
4. Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.
Структурные критерии используют модель программы в виде «белого ящика», что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Структурная информация понятна и доступна разработчикам подсистем и модулей приложения, поэтому данный класс критериев часто используется на этапах модульного и интеграционного тестирования (Unit testing, Integration testing).
Структурные критерии базируются на основных элементах УГП, операторах, ветвях и путях.
Функциональный критерий – важнейший для программной индустрии критерий тестирования. Он обеспечивает, прежде всего, контроль степени выполнения требований заказчика в программном продукте. Поскольку требования формулируются к продукту в целом, они отражают взаимодействие тестируемого приложения с окружением. При функциональном тестировании преимущественно используется модель «черного ящика». Проблема функционального тестирования – это, прежде всего, грудоемкость; дело в том, что документы, фиксирующие требования к программному изделию (Software requirement specification, Functional specification и т.п.), как правило, достаточно объемны, тем не менее, соответствующая проверка должна быть всеобъемлющей.
Ниже приведены частные виды функциональных критериев.
• Тестирование пунктов спецификации – набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.
Спецификация требований может содержать сотни и тысячи пунктов требований к программному продукту, и каждое из этих требований при тестировании должно быть проверено в соответствии с критерием не менее чем одним тестом.
• Тестирование классов входных данных – набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза. При создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что, перебирая в соответствии с критерием величины входных переменных (например, различные файлы – источники входных данных), мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия – процесс трудоемкий, что создает сложности для применения критерия
• Тестирование правил – набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики. Следует заметить, что грамматика должна быть достаточно простой, чтобы трудоемкость разработки соответствующего набора тестов была реальной (вписывалась в сроки и штат специалистов, выделенных для реализации фазы тестирования).
• Тестирование классов выходных данных – набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out).
При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
• Тестирование функций – набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза.
Очень популярный на практике критерий, который, однако, не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту). Критерий тестирования функций отчасти объединяет особенности структурных и функциональных критериев. Он базируется на модели «полупрозрачного ящика», где явно указаны не только входы и выходы тестируемого компонента, но также состав и структура используемых методов (функций, процедур) и классов.
• Комбинированные критерии для программ и спецификаций – набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза.
При этом все комбинации непротиворечивых условий надо подтвердить, а условия противоречий следует обнаружить и ликвидировать.
Стохастическое тестирование применяется при тестировании сложных программных комплексов – когда набор детерминированных тестов (X,Y) имеет громадную мощность. В случаях, когда подобный набор невозможно разработать и исполнить на фазе тестирования, можно применить следующую методику:
Разработать программы – имитаторы случайных последовательностей входных сигналов <х>.
Вычислить независимым способом значения <у>для соответствующих входных сигналов <х>и получить тестовый набор (X,Y).
Протестировать приложение на тестовом наборе (X,Y), используя два способа контроля результатов:
♦ Детерминированный контроль – проверка соответствия вычисленного значения увк <у>значению у, полученному в результате прогона теста на наборе <х>– случайной последовательности входных сигналов, сгенерированной имитатором.
♦ Стохастический контроль – проверка соответствия множества значений <ув>, полученного в результате прогона тестов на наборе входных значений <х>, заранее известному распределению результатов F(Y).
В этом случае множество Y неизвестно (его вычисление невозможно), но известен закон распределения данного множества.
Критерии стохастического тестирования:
♦ Статистические методы окончания тестирования – стохастические методы принятия решений о совпадении гипотез о распределении случайных величин. К ним принадлежат широко известные: метод Стьюдента (St), метод Хи-квадрат (х 2 ) и т.п.
♦ Метод оценки скорости выявления ошибок – основан на модели скорости выявления ошибок [12], согласно которой тестирование прекращается, если оцененный интервал времени между текущей ошибкой и следующей слишком велик для фазы тестирования
Постулируется, что профессиональные программисты пишут сразу почти правильные программы, отличающиеся от правильных мелкими ошибками или описками типа – перестановка местами максимальных значений индексов в описании массивов, ошибки в знаках арифметических операций, занижение или завышение границы цикла на 1 и т.п. Предлагается подход, позволяющий на основе мелких ошибок оценить общее число ошибок, оставшихся в программе.
Подход базируется на следующих понятиях:
Мутации – мелкие ошибки в программе.
Мутанты – программы, отличающиеся друг от друга мутациями.
Метод мутационного тестирования – в разрабатываемую программу Р вносят мутации, т.е. искусственно создают программы-мутанты Р1,Р2. Затем программа Р и ее мутанты тестируются на одном и том же наборе тестов (X,Y).
Если на наборе (X,Y) подтверждается правильность программы Р и, кроме того, выявляются все внесенные в программы-мутанты ошибки, то набор тестов (X, Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной.
Если некоторые мутанты не выявили всех мутаций, то надо расширять набор тестов (X,Y) и продолжать тестирование.
Тестирование программы Р по некоторому критерию С означает покрытие множества компонентов программы Р М=
T=
Тест ti неизбыточен, если существует покрытый им компонент mi из М(Р,С), не покрытый ни одним из предыдущих тестов t1. ti-1. Каждому ti соответствует неизбыточный путь рi – последовательность вершин от входа до выхода.
V(P,C) – сложность тестирования Р по критерию С – измеряется max числом неизбыточных тестов, покрывающих все элементы множества М(Р,С).
DV(P,C,T) – остаточная сложность тестирования Р по критерию С – измеряется max числом неизбыточных тестов, покрывающих элементы множества М(Р,С), оставшиеся непокрытыми, после прогона набора тестов Т. Величина DV строго и монотонно убывает от V до 0.
TV(P,C,T) = (V-DV)/V – оценка степени тестированности Р по критерию С.
Критерий окончания тестирования TV(P,C,T) ³ L, где (0 £ L £ 1). L – уровень оттестированности, заданный в требованиях к программному продукту.
Рис. 1.1. Метрика оттестированности приложения
Рассмотрим две модели программного обеспечения, используемые при оценке оттестированноси.
Для оценки степени оттестированности часто используется УГП – управляющий граф программы. УГП многокомпонентного объекта G (рис. 1.2, рис. 1.8), содержит внутри себя два компонента G1 и G2, УГП которых раскрыты.
Рис. 1.2. Плоская модель УГП компонента G
В результате УГП компонента G имеет такой вид, как если бы компоненты G1 и G2 в его структуре специально не выделялись, а УГП компонентов G1 и G2 были вставлены в УГП G. Для тестирования компонента G в соответствии с критерием путей потребуется прогнать тестовый набор, покрывающий следующий набор трасс графа G (рис. 1.3):
Набор трасс, необходимых для покрытия плоской модели УГП компонента G
| Pi(G) | = 1-2-3-4-5-6-7-10; |
| P2(G) | = 1-2-3-4-6-7-10; |
| P3(G) | — 1-2-11-16-18-14-15-7-10; |
| P4(G) | = 1-2-11-16-17-14-15-7-10; |
| P5(G) | = 1-2-11-16-12-13-14-15-7-10; |
| P6(G) | = 1-2-19-20-23-22-7-10; |
| P7(G) | = 1-2-19-20-21-22-7-10; |
Рис. 1.4. Иерархическая модель УГП компонента G
УГП компонента G, представленный в виде иерархической модели, приведен на рис. 1.4 и рис. 1.9. В иерархическом УГП G входящие в его состав компоненты представлены ссылками на свои УГП G1 и G2 (рис. 1.10 и рис. 1.9)
Рис. 1.5. Иерархическая модель: УГП компонентов G1 и G2
Для исчерпывающего тестирования иерархической модели компонента G в соответствии с критерием путей требуется прогнать следующий набор трасс (рис. 1.6):
| P 1 (G) | = 1-2-3-4-5-6-7-10; |
| P 2 (G) | = 1-2-3-4-6-7-10; |
| P 3 (G) | = 1-2-8-7-10; |
| P 4 (G) | = 1-2-9-7-10. |
Рис. 1.6. Набор трасс, необходимых для покрытия иерархической модели УГП компонента G
Приведенный набор трасс достаточен при условии, что компоненты G1 и G2 в свою очередь исчерпывающе протестированы. Чтобы обеспечить выполнение этого условия в соответствии с критерием путей, надо прогнать все трассы рис. 1.7.
Рис. 1.7. Набор трасс иерархической модели УГП, необходимых для покрытия УГП компонентов G1 и G2
Оценка степени тестированности плоской модели определяется долей прогнанных трасс из набора необходимых для покрытия в соответствии с критерием С.
– тестовый путь (tj) в графе G плоской модели равен 1, если он протестирован (прогнан), или 0, если нет.
Например, если в УГП (рис. 1.5) тесты t6 и t8, которым соответствуют трассы Р6 и Р8, не прогнаны, то в соответствии с соотношением (1) для TV(G,C) степень тестированности будет оценена в 0.71.
Оценка тестированности иерархической модели определяется на основе учета оценок тестированности компонентов. Если трасса некоторого теста tj УГП G включает узлы, представляющие компоненты Gj1. Gjm, оценка TV степени тестированности которых известна, то оценка тестированности PTj(G) при реализации этой трассы определяется не 1, а минимальной из оценок TV для компонентов.
Интегральная оценка определяется соотношением (2):
, где
PTi(G) – тестовый путь (ti) в графе G равен 1, если протестирован, или 0, если нет. В путь РТ <графа G может входить j узлов модулей Gij со своей степенью тестированности TV(Gij,C) из которых мы берем min, что дает худшую оценку степени тестированности пути.
ответы интуит 4 экзамен
Можно ли гарантировать остановку программы на любом тесте?
в общем случае нет
возможно в частных случаях
задача в общей постановке алгоритмически неразрешима
Сколько тестов потребуется для проверки программы, реализующей задержку на неопределенное количество тактов?
один
неопределенное количество
зависит от критерия достаточности проверок
Какие существуют способы получения эталонных значений теста?
предсказание ожидаемого результата
независимое вычисление результата
подстановка в тест результата вычисления тестируемой программы
Что такое путь в УГП?
последовательность вершин и дуг УГП с фиксированными начальной и конечной вершиной
последовательность ветвей УГП с фиксированными начальной вершиной первой ветви и конечной вершиной последней ветви пути
множество связанных дуг УГП
Какие существуют методы анализа и локализации ошибки?
выполнение программы в уме
метод контрольных точек и анализа трасс
Какие подходы используются для обоснования истинности программ?
доказательство программы 234
эксперимент над программой 3
формальный и интерпретационный 1234
использование аналогий 34
Является ли программа аналогом математической формулы?
да
нет
математические формулы и программы не сводятся друг к другу
Каковы особенности разработки тестового набора?
определение областей эквивалентности входных параметров
анализ покрытия тестами всех возможных случаев поведения
проверка граничных значений
Какие существуют фазы процесса тестирования?
разработка тестового набора
прогон программы на тестовом наборе
анализ результатов тестирования
доказательство правильности программы
Что такое ветвь УГП?
последовательность вершин и дуг УГП с фиксированными начальной и конечной вершиной, которые кодируют либо условные операторы, либо первый и последний операторы УГП соответственно
часть пути, в котором все внутренние вершины кодируют линейные операторы
начальная и конечная вершина пути
Отметьте верные утверждения:
нереализуемый путь недоступен при корректном исполнении программы
нереализуемый путь доступен при реализации недопустимых состояний переменных программы
нереализуемый путь доступен при сбое
Зачем нужен Log-файл?
для изучения результатов тестирования в режиме on-line
для фиксации результатов прогона test-suite
для записи комментариев после прогона тестов
Возможно ли тестирование программы на всех допустимых значениях параметров?
возможно в отдельных случаях
Какова мощность множества тестов, формально необходимая для тестирования операции в машине с 32-разрядным машинным словом?
2 32
4 9
2 64
Зачем нужна спецификация тестирования?
для формирования команды тестировщиков
для разработки тестового набора
для понимания смысла программы
Отметьте верные утверждения
тестирование – процесс поиска ошибок
в фазу тестирования входят поиски и исправление ошибок
отладка – процесс локализации и исправления ошибок
Что такое управляющий граф программы (УГП)?
множество операторов программы.
множество операторов управления
Какие предъявляются требования к идеальному критерию тестирования?
Какая оценка мощности покрытия для следующих пар критериев правильна?
C0
Какие существуют разновидности структурных критериев?
критерий тестирования команд
критерий тестирования ветвей
критерий тестирования путей
критерий тестирования циклов
Какие классы частных критериев тестируемости известны?
Назовите недостатки структурных критериев.
не проверяется соответствие со спецификацией
не проверяется соответствие со спецификацией, не зафиксированное в структуре программы
не проверяются ошибки в структурах данных
Назовите полный и надежный критерий для нетривиальных классов программ.
такого критерия не существует
сценарный критерий
критерий «черного ящика»
Назовите критерии стохастического тестирования.
cтохастический метод Хи-квадрат
cтохастический метод Стьюдента
метод оценки скорости выявления ошибок
метод особых состояний
Каковы особенности плоской модели УГП?
не выделяются структурные компоненты в виде отдельных подграфов УГП3
для тестирования требуется осуществить весь перебор трасс 12
оценка оттестированности не зависит от ранее собранных оценок оттестированности УГП компонентов 13
Какая оценка мощности покрытия для следующих пар критериев правильна?
тестирование пунктов спецификаций Тестирование классов входных данных
Какая информация должна собираться при тестировании для применения метода оценки скорости выявления ошибок?
интервалы между моментами обнаружения ошибок
оценка плотности ошибок в проблемной области
данные из исторической базы данных проектов
Чем отличается оценка оттестированности проекта от оценки для модуля?
оценка проекта интегрирует оценки оттестированности модулей
оценка проекта может вычисляться инкрементально
в результате получаем наихудшую оценку оттестированности
в результате получаем наилучшую оценку оттестированности
Перечислите метрики оценки оттестированности программного проекта?
сложность тестирования программы по заданному критерию
остаточная сложность тестирования программы
оценка степени оттестированности программы по заданному критерию
Какая информация должна собираться при тестировании для применения метода оценки скорости выявления ошибок?
интервалы между моментами обнаружения ошибок
оценка плотности ошибок в проблемной области
данные из исторической базы данных проектов
Перечислите разновидности функциональных критериев.
тестирование пунктов спецификации
тестирование классов входных данных
тестирование классов выходных данных
Какой подход используется в методе мутационного тестирования?
оценка числа ошибок в программе на основе искусственно внесенных мелких ошибок
создание программ-мутантов с функциональными дефектами
создание программ-мутантов на основе изменения модульной структуры основной программы
Каковы особенности иерархической модели УГП?
УГП структурных компонентов выделяются и выносятся из общего УГП проекта
для тестирования требуется осуществить перебор трасс упрощенного УГП
оценка оттестированности зависит от ранее собранных оценок оттестированности УГП компонентов
На основе каких принципов строятся тесты для модульного тестирования?
анализ потоков управления модуля
анализ потоков данных модуля
анализ покрытия в соответствии с заданным критерием С
Каковы фазы процесса построения тестовых путей?
выбор тестовых путей
генерация тестов, соответствующих выбранным тестовым путям
Каковы особенности восходящего тестирования?
минимизация разработки заглушек
запаздывание в проверке функциональности реализуемого приложения
необходимость разработки среды управления очередностью вызовов модулей
Каково выражение для оценки сложности интеграционного тестирования?
(P, C1) = 
V(Modi, C1)
Какие существуют разновидности тестирования?