Тестирование ПО. Лекции.md

Дополнительные материалы:

• Бындью Александр "Модульные отладки на примере разработки отчетов".
• IOC-контейнер.
• Попов TDD
• Вигерс "Разработка требований к ПО"

Лекция 2

Основные критерии тестирования (класс 1)

1. Условие критерия тестирования команд (критерий C0). Набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий используется в больших программных системах, где другие критерии применить не возможно.
2. Условия критерия тестирования ветвей (критерий С1). Набор тестов в совокупности должен обеспечить прохождение каждого критерия не менее одного раза. Но применяется при тестировании ветвей. Это достаточно экономичный критерий, поскольку множество ветвей в тестируемом приложении конечно и не так велико. Используется в системах автоматизации систем.
3. Условие критерия тестирования путей (критерий C2). Набор тестов в совокупности должен обеспечить прохождения одного пути не менее одного раза. Если программа содержит цикл, в особенности с неявно заданным числом итераций, то число итераций ограничивается константой.

public void Method(ref int x)
{
    if (x > 17)
        x = 17-x;
    if (x >= -13)
        x = 0;
}

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

(X, Y) = { (x_in = 30, x_out = 0) }

Покрывает все операторы трассы 1 - 2 - 3 - 4 - 5 -6

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

(X, Y) = { (30, 0), (17, 17) }

Удовлетворяет критерию ветвей C1 и добавляет к множеству C0 и трассу 1 - 2 - 4 - 6. Трасса 1 - 2 - 3 - 4 - 5 - 6 проходит через все ветви, достижимые в операторах if при условии true. А трасса 1 - 2 - 4 - 6 через все ветви, достижимые в операторах if при условии false.

Тестовый набор из четырех тестов удовлетворяет критерию C2.

(X, Y) = { (30, 0), (17, 17); (13, 0), (21, -4) }

Критерий C2 программу более тщательно, чем критерий C1. Однако даже в случае, если он удовлетворен нет оснований утверждать, что программа реализована в соответствии со спецификацией. Например, если спецификация задает условие, что

|x| <= 100

то невыполнимость такого условия можно подтвердить на значении -177. Операторы 3 и 4 не изменят величину и результат не будет соответствовать спецификации.

	(30, 0)	(17, 1)	(-13, 0)	(21, -4)
if (x>17)	>	<	<	>
if (x == -13)	=	!=	=	!=

Структурные критерии не проверяют в соответствии со спецификацией, если оно не отражено в структуре программы, поэтому при успешном тестировании программы по критерию C2 можно не заметить ошибку, связанную с невыполнением условием требования спецификации.

Функциональный критерий. Обеспечивает контроль степени выполнения требования заказчика, в программном продукте. Посколько требование формируется к продукту в целом функциональные критерии используют, в основном, модель черного ящика. Проблема функционального тестирования - трудоемкость. Это связанно с software requirment specification и functional specification.

Основыне виды функциоанльных критериев (класс 2)

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

Стохастические критерии (класс 3)

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

Критерии стохастического тестирования:

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

ААА в действии

var reporter = new Reporter();          // Arrange
int CountReport = report.SendReports(); // Act
Assert.AreEqual(2, CountReport);        // Assert

Фрейморвки для тестирования: XUnit, NUnit

Лекция 3. Оценка тестированности проекта: метрики и методика интегральной оценки

Оценка покрытия программы и проекта

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

M = {m_1, ..., m_k}

по элементам или связям. При этом

T = {t_1, ..., t_n}_ - кортеж неизбыточных тестов

Тест t_j не избыточен, если существует покрытый им компонент m_i из пар программы и критерия: M(P, C) непокрытый ни одним из предыдущих тестов t_1, ..., t_(j-1) каждому t_j соответсвует неизбыточный путь p_i, при этом p_i - последовательность вершин от выхода или входа программ. Здесь j = 1..n

V(P, C) - сложность тестирования P по критерию C. Измеряется максимальным числом неизбыточных тестов, покрывающих все элементы множества M(P, C)

DV(P, C) - остаточная сложность тестирования P по критерию C. Измеряется максимальным числом неизбыточных тестов, покрывающих элементы множества M(P, C), оставшиеся непокрытыми после прогона набора тестов T. Величина DV строго и монотонно убывает от V до 0.

TV(P, C, T) = (V - DV) / V - оценка степени тестрованния P по критерию C.

Критерий окончания тестирования: TV(P, C, T) ≥ L; (0 ≤ L ≤ 1) задан в требованиях к программноому продукту

Методика интегральной оценки тестрованности

Включает в себя 8 шагов:

1. Выбор критерия C и приемочные оценки тестрованности программного проекта L
2. Построение дерева классов проекта и построение графа управления для каждого модуля
3. Модульное тестирование и оценка степени тестрованности TV на модульном уровне
4. Построение графо-управления, интегрирующего модули в единую иерарахическую модель проекта.
5. Выбор тестовых путей для проведения инетграционного или системного тестирования.
6. Генерация тестов, покрывающих тестовые пути на 5 шаге.
7. Интегральная оценка тестированности проекта с учетом оценки тестированности модулей компонент.
8. Повторение шага 5-7 до достижения заданного уровня тестированности L

Лекция 4.

IoC (Invertional control) - штука для вынесения создание самих объектов на самый верх (в итоге через конфиг файл)

Лекция 5. Верификация тестирования и оценивание корректности программных компонентов

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

Назначение верификации — последовательно проверить, что:

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

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

Результаты верификации должны быть включены следующие документы:

• Выполненные процедуры верификации
• Описание отчет о квалификационном тестировании программного средства и его компоненты

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

1. Полностью определены функции информационной системы, которые должно выполнять программное средство
2. Требования по функциональности, эффективности и качеству системы детализированы в исходных требованиях высокого уровня и что правильно определены производные требования и обоснована их необходимость.
3. Каждое требование высокого уровня программного средства является точным, однозначным и достаточно детализированным, при этом требования не конфликтуют друг с другом.
4. Не существует никаких конфликтов между требованиями высокого уровня и возможностями аппаратных и программных средств, особенно такими, как время реакции системы и характеристики аппаратуры ввода-вывода.
5. Процесс разработки требований к программному средству полностью соответствует стандартам на создание спецификации требований и любые отклонения от стандартов обоснованы.
6. Функциональные и конструктивные характеристики качества, предназначенные для программной реализации полностью включены в требования высокого уровня программного средства.

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

Имеет 2 цели:

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

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

Включает в себя 2 шага:

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

Взаимосвязь разработки и тестирования (V-диаграмма)

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

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

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

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

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

Лекция 7

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

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

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

Возможно модели двух типов:

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

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

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

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

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

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

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

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

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

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

1. Формализованных спецификаций требований на программные и информационные модули, на группы программ и на программные комплексы.
2. Программные модули, подготовленных к тестированию, на уровне исходных текстов программ и на уровне объектных кодов.
3. Автономных групп программных модулей и компонент, решающих законченные функциональные задачи.
4. Функциональных компонентов в составе программных средств.

Лекция 8

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

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

Автономное тестирования функциональных компонентов с исполнением программ

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

Интеграционное тестирование

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

Тестирование функциональных компонентов в составе программных средств

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