Тестирование, верификация и документирования ИСО 1

Верификация - это процесс определения, выполняют ли программные средства и их компоненты требования, наложенные на них в последовательных этапах жизненного цикла разрабатываемой программной системы 2

Каскадная модель жизненного цикла 3

V-образный жизненный цикл 4

Спиральный жизненный цикл 5

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

Тип жизненного цикла Длина цикла Верификация и внесение изменений Интеграция отдельных компонент системы Каскадный Все этапы разработки системы. Длинный В конце разработки всей системы. Изменения вносятся редко Четко определенные до начала кодирования интерфейсы V-образный Все этапы разработки системы. Длинный В конце полной разработки каждого из этапов системы. Изменения вносятся со средней частотой Редко изменяемые интерфейсы Спиральный Разработка одной версии системы. Средний В конце разработки каждого из этапов версии системы. Изменения вносятся со средней частотой Периодически изменяемые интерфейсы, редко меняемые в пределах версии XPРазработка одной истории. Короткий В конце разработки каждой истории. Изменения вносятся очень часто Часто изменяемые интерфейсы 7

Стандарты комплекса ГОСТ 34 на создание и развитие АС - обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. Международный стандарт ISO/IEC на организацию жизненного цикла продуктов программного обеспечения (ПО) содержит общие рекомендации по организации жизненного цикла, не постулируя при этом его жесткой структуры. 8 Основные стандарты

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

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

Тестирование - процесс выполнения программы с целью обнаружения ошибки. Тестовые данные - входы, которые используются для проверки системы. Тестовая ситуация (test case) - входы для проверки системы и предполагаемые выходы в зависимости от входов, если система работает в соответствии со спецификацией требований. Хорошая тестовая ситуация - та ситуация, которая обладает большой вероятностью обнаружения пока еще необнаруженной ошибки. Удачный тест - тест, который обнаруживает пока еще необнаруженную ошибку. Ошибка - действие программиста на этапе разработки, приводящее к тому, что в программном обеспечении содержится внутренний дефект, который в процессе работы программы может привести к неправильному результату. Отказ - непредсказуемое поведение системы, приводящее к неожидаемому результату, которое могло быть вызвано дефектами, содержащимся в ней. Валидация программной системы - целью этого процесса является доказательство того, что в результате разработки системы мы достигли тех целей, которые планировали достичь благодаря ее использованию. Иными словами, валидация - это проверка соответствия системы ожиданиям заказчика. Вопросы, связанные с валидацией, выходят за рамки данного учебного курса и представляют собой отдельную интересную тему для изучения. 11 Определения

12 Документация, создаваемая на различных этапах жизненного цикла

Модульное тестирование Интеграционное тестирование Системное тестирование Нагрузочное тестирование Формальные инспекции 13 Типы процессов тестирования и верификации

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

Стеклянный (белый) ящик Тестирование моделей Черный ящик 15

Обобщенная схема среды тестирования 16

Вызов тестируемого модуля 1 + передача в тестируемый модуль входных значений и прием результатов 2 + вывод выходных значений 3 + протоколирование процесса тестирования и ключевых точек программы 17 Функции драйвера

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

19 Схема взаимодействия частей реальной системы

20 Схема взаимодействия тестового окружения и тестируемого ПО

Драйвер создает один или больше объектов тестируемого класса, все обращения к объектам происходят только с использованием их внешнего интерфейса. Текст драйвера в этом случае представляет собой т.н. тестирующий класс, который содержит по одному методу для каждого тестового примера. Процесс тестирования заключается в последовательном вызове этих методов. Вместо заглушек в состав тестового окружения входит программный код реальной системы, соответственно, отсутствует изоляция тестируемого класса. Однако, именно такой подход к тестированию принят сейчас в большинстве методологий и сред разработки. Аналогично предыдущему подходу, но для всех классов, которые использует тестируемый класс, создаются заглушки Программный код тестируемого класса модифицируется таким образом, чтобы открыть доступ ко всем его свойствам и методам. Строение тестового окружения в этом случае полностью аналогично окружению для тестирования структурных программ. Используются специальные средства доступа к закрытым данным и методам класса на уровне объектного или исполняемого кода - скрипты отладчика или accessors в Visual Studio. 21 Тестовые классы

Монолитные программы, содержащие в своем коде все необходимые для своей работы инструкции. Обмен данными внутри таких программ производится при помощи передачи параметров функций и использования глобальных переменных. При запуске таких программ образуется один процесс, который выполняет всю необходимую работу. Модульные программы, которые состоят из отдельных программных модулей с четко определенными интерфейсами вызовов. Объединение модулей в программу может происходить либо на этапе сборки исполняемого файла (статическая сборка или static linking ), либо на этапе выполнения программы (динамическая сборка или dynamic linking ). Преимущество модульных программ заключается в достижении некоторого уровня универсальности - один модуль может быть заменен другим. Однако, модульная программа все равно представляет собой один процесс, а данные, необходимые для решения задачи, передаются внутри процесса как параметры функций. Программы, использующие межпроцессное взаимодействие. Такие программы образуют программный комплекс, предназначенный для решения общей задачи. Каждая запущенная программа образует один или более процессов. 22 Генераторы сигналов (событийно- управляемый код)

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

24 Пример конечного автомата процесса приема-передачи данных

Допустимые данные Граничные данные Отсутствие данных Повторный ввод данных Неверные данные Реинициализация системы Устойчивость системы Нештатные состояния среды выполнения 25 Типы тестовых примеров

Значение внутри диапазона Минимальное значение Максимальное значение Значение внутри диапазона Минимальное значение Минимальное значение + 1 Максимальное значение Максимальное значение Граничные условия

Минимальное значение - 1 Максимальное значение + 1, 27 Проверка робастности (выхода за границы диапазона)

Значение из середины интервала. Граничные значения. Недопустимые значения за границами интервала. 28 Классы эквивалентности

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

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

Длина имени меньше 11 символов Длина имени равна 11 символам Длина имени больше 11 символов 31 По длине имени

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

33 Возможности MVSTE по ручному тестированию и описанию тестовых примеров (Manual Testing)

AuthoringTest.txt Примечания о создании тестов, включающие инструкции по добавлению дополнительных тестов к проекту. UnitTest1. cs Пустая структура unit test класса, куда помещаются дополнительные тесты. ManualTest1. mht Шаблон в формате Word, который заполняется инструкциями при ручном тестировании. 34

35 Solution Explorer

36 Добавление теста

37

Единая схема идентификации и трассировки тестовых примеров Объединение тестовых примеров в смысловые группы Внесение изменений в тестовые примеры Определение последовательности тестирования Тест-планы 38

Тестовый пример 1 Номер тест-требования: 2 а, 2b Описание теста: В данном тесте проверяется правильность вычисления значения контрольной суммы (поля CRC) при непустом значении поля CRC и нулевых значениях элементов записи. Входные данные: CRC = 12345, A=0, B=0, C=0, D=0 Ожидаемые выходные данные: CRC = 0, A=0, B=0, C=0, D=0, Empty = TRUE Сценарий теста: 1. Установка значения поля CRC в Установка значений полей A-F в 0 3. Вызов функции Set_CRC 4. Проверка значений CRC на 0 и Empty на TRUE 39 Типовая структура тест-плана

Тестовый пример 2 Номер тест-требования: 2a Описание теста: В данном тесте проверяется соответствие алгоритма вычисления поля CRC, заданному в спецификации требований. Входные данные: CRC = 0, A-D заполнены байтами b Ожидаемые выходные данные: CRC = b, Empty = FALSE Сценарий теста: 1. Установка значения поля CRC в 0 2. Заполнение байт полей A-D байтами b 3. Вызов функции Set_CRC 4. Проверка значений CRC на b и Empty на FALSE 40

Тестовый пример 3 Номер тест-требования: 2a Описание теста: В данном тесте проверяется неизменность полей A-F записи при вычислении поля CRC (подсчете контрольной суммы). Входные данные: CRC = 0, A-D заполнены байтами b Ожидаемые выходные данные: A-D заполнены байтами b, Сценарий теста: 1. Установка значения поля CRC в 0 2. Заполнение байт полей A-D байтами b 3. Вызов функции Set_CRC 4. Проверка значений байт полей A-D на b 41

Вывод количества пройденных и количества не пройденных тестовых примеров, а также их общего количества. 180 test cases passed 20 test cases failed 200 test cases total 1 + вывод идентификаторов не прошедших тестовых примеров. Позволяет локализовать тестовые примеры, потенциально выявившие дефект. Invoking test case 1 … Passed Invoking test case 2 … Failed Invoking test case 3 … Failed Invoking test case 200 … Passed Final stats: 180 test cases passed 20 test cases failed 200 test cases total 42 Оценка качества тестируемого кода

2 + вывод не совпавших ожидаемых и реальных выходных данных. Позволяет проводить более глубокий анализ причин неуспешного прохождения тестового примера. Invoking test case 1 … Passed --- Invoking test case 2 … Failed Expected values: Actual values: A = 200 A = 0 B = 450 B = 0 Message = "Submenu 1" Message = "" --- Invoking test case 3 … Failed Expected values: Actual values: A = 0 A = 200 B = 0 B = 300 Message = "" Message = "Main Menu" --- Invoking test case 200 … Passed --- Final Stats 180 test cases passed 20 test cases failed 200 test cases total 43

2 + вывод всех ожидаемых и реальных выходных данных. Вариант предыдущего пункта. Invoking test case 1 … Passed --- Invoking test case 2 … Failed Expected values: Actual values: A = 200 A = 0 FAIL B = 450 B = 0 FAIL C = 500 C = 500 P D = 600 D = 600 P Message = "Submenu 1" Message = "" FAIL --- Invoking test case 3 … Failed Expected values: Actual values: A = 0 A = 200 FAIL B = 0 B = 300 FAIL C = 500 C = 500 P D = 600 D = 600 P Message = "" Message = "Main Menu" FAIL --- Invoking test case 200 … Passed --- Final Stats 180 test cases passed 20 test cases failed 200 test cases total 44

Invoking test case 1 … Passed A = 0 A = 0 P B = 0 B = 0 P C = 500 C = 500 P D = 600 D = 600 P Message = "" Message = "" P --- Invoking test case 2 … Failed Expected values: Actual values: A = 200 A = 0 FAIL B = 450 B = 0 FAIL C = 500 C = 500 P D = 600 D = 600 P Message = "Submenu 1" Message = "" FAIL --- Invoking test case 3 … Failed Expected values: Actual values: A = 0 A = 200 FAIL B = 0 B = 300 FAIL C = 500 C = 500 P D = 600 D = 600 P Message = "" Message = "Main Menu" FAIL --- Invoking test case 200 … Passed Message = "Submenu 1" Message = "Submenu 1 P Prompt = ">" Prompt = ">" P --- Final Stats 180 test cases passed 20 test cases failed 200 test cases total 45 Полный вывод

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

Каждый оператор был выполнен хотя бы один раз Вход: condition = true; Ожидаемый выход: *p = 123. int* p = NULL; if (condition) p = &variable; *p = 123; 47 Уровни покрытия. По строкам программного кода (Statement Coverage)

Если в состав тестов не будет входить тестовый пример, проверяющий работу фрагмента при значении condition = false, код будет покрыт. Однако, в случае condition = false выполнение фрагмента вызовет ошибку. Проблемы возникают при проверке циклов do … while - при данном уровне покрытия достаточно выполнение цикла только один раз, Метод совершенно к логическим операторам || и && Зависимость уровня покрытия от структуры программного кода. Проблемы могут возникнуть при покрытии следующего фрагмента программного кода: if (condition) functionA(); else functionB(); 48 Минусы

Каждая точка входа и выхода в программе и во всех ее функциях должна быть выполнена по крайней мере один раз, и все логические выражения в программе должны принять каждое из возможных значений хотя бы один раз a = 0; if (condition) { a = 1; } 49 По веткам условных операторов (Decision Coverage)

Вход: condition = true; Ожидаемый выход: a = 1; Вход: condition = false; Ожидаемый выход: a = 0; 50 Тестовые примеры

Не учитываются логические выражения if ( condition1 && ( condition2 || function1() ) ) statement1; else statement2; 51 Минусы

1. Вход: condition1 = true, condition2 = true 2. Вход: condition1 = false, condition2 = true/false (любое значение) 3. Вход: condition1 = true, condition2 = false. 52 Доработки

Каждая компонента логического условия в результате выполнения тестовых примеров должна принимать все возможные значения, но при этом не требуется, чтобы само логическое условие принимало все возможные значения if (condition1 | condition2) functionA(); else functionB(); 53 Покрытие по условиям (Condition Coverage)

(1) Вход: condition1 = true, condition2 = false (2) Вход: condition1 = false, condition1 = true. 54 Тестовые примеры

Значение логического условия будет принимать значение только true, таким образом, при полном покрытии по условиям не будет достигаться покрытие по веткам 55 Минусы

Для обеспечения полного покрытия необходимо, чтобы как логическое условие, так и каждая его компонента приняла все возможные значения 1. Вход: condition1 = true, condition2 = true 2. Вход: condition1 = false, condition1 = false. 56 Покрытие по веткам/условиям (Condition/Decision Coverage)

Не позволят протестировать правильность логической функции - вместо OR в программном коде могла быть ошибочно записана операция AND 57 Минусы

Должны быть проверены все возможные наборы значений компонент логических условий. Т.е. в случае n компонент потребуется 2 n тестовых примеров, каждый из которых проверяет один набор значений, Тесты, необходимые для полного покрытия по данному методу, дают полную таблицу истинности для логического выражения. 58 Покрытие по всем условиям (Multiple Condition Coverage)

Сложность Избыточность зависимость количества тестовых примеров от структуры логического выражения. a && b && (c || (d && e)) ((a || b) && (c || d)) && e потребуется разное количество тестовых примеров. Для первого случая для полного покрытия нужно 6 тестов, для второго Минусы

каждое логическое условие должно принимать все возможные значения; каждая компонента логического условия должна хотя бы один раз принимать все возможные значения; должно быть показано независимое влияние каждой из компонент на значение логического условия, т.е. влияние при фиксированных значениях остальных компонент. 60 Метод MC/DC для уменьшения количества тестовых примеров при 3-м уровне покрытия кода

Целью анализа полноты покрытия кода является выявление участков кода, которые не выполняются при выполнении тестовых примеров. Тестовые примеры, основанные на требованиях, могут не обеспечивать полного выполнения всей структуры кода. Поэтому для улучшения покрытия проводится анализ полноты покрытия кода тестами, и при необходимости проводятся дополнительные проверки, направленные на выяснение причины недостаточного покрытия и определение необходимых действий по его устранению. Обычно анализ покрытия выполняется с учетом следующих соглашений: анализ должен подтвердить, что полнота покрытия тестами структуры кода соответствует требуемому виду покрытия и заданному минимально допустимому проценту покрытия; анализ полноты покрытия тестами структуры кода может быть выполнен с использованием исходного текста, если программное обеспечение не относится к уровню A. Для уровня А необходимо проверить объектный код, сгенерированный компилятором, и выяснить, трассируется ли он в исходный текст или нет. Если объектный код не трассируется в исходный текст, должны быть проведены поверки объектного кода на предмет правильности генерации последовательности команд. Примером объектного кода, который напрямую не трассируется в исходный текст, но генерируется компилятором, может быть проверка выхода за заданные границы массива; анализ должен подтвердить правильность передачи данных и управления между компонентами кода. 61 Анализ покрытия

62 Тестовое окружение

Поиск и документирование несоответствий требованиям Поддержка разработки и рефакторинга низкоуровневой архитектуры системы и межмодульного взаимодействия. Поддержка рефакторинга модулей. Поддержка устранения дефектов и отладки. 63 Модульное тестирование

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

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

ГОСТ 19 ххх ГОСТ 24 ххх ГОСТ 34 ххх Документирование 66