теория_общая_3 (Методичка и инструкции на ЛР №8)
Описание файла
Файл "теория_общая_3" внутри архива находится в следующих папках: Методичка и инструкции на ЛР №8, Инструкции, Задание_3. Документ из архива "Методичка и инструкции на ЛР №8", который расположен в категории "". Всё это находится в предмете "технологии разработки программного обеспечения (по)" из 10 семестр (2 семестр магистратуры), которые можно найти в файловом архиве МГТУ им. Н.Э.Баумана. Не смотря на прямую связь этого архива с МГТУ им. Н.Э.Баумана, его также можно найти и в других разделах. Архив можно найти в разделе "лабораторные работы", в предмете "технологии разработки по" в общих файлах.
Онлайн просмотр документа "теория_общая_3"
Текст из документа "теория_общая_3"
6.1. Тест-планы
Тест-план представляет собой документ, в котором перечислены либо все тестовые примеры, необходимые для тестирования системы, либо часть тестовых примеров, объединенных по определенному признаку.
Тест-план может быть написан на естественном или формальном языке; в последнем случае возможна передача тест-плана на вход тестового окружения для автоматического выполнения определенных в тест-плане тестовых примеров.
6.1.1. Типовая структура тест-плана
Рассмотрим типовую структуру тест-плана, написанного на естественном языке и содержащего тестовые примеры для проверки работы модуля расчета контрольных сумм.
Каждый тестовый пример в этом тест-плане имеет уникальный номер и ссылку на тест-требование, на основе которого он написан.
Общее описание теста помогает при сопровождении тест-планов - внесении изменений при изменении системы, инспекциях тест-планов, выявляющих несогласованность и т.п.
Также в каждом тестовом примере обязательно перечислены все входные значения и ожидаемые выходные значения, а также сценарий, описывающий последовательность действий, которые необходимо выполнить тестовому окружению для выполнения тестового примера.
Тест-план
Тестовый пример 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 в 12345
2. Установка значений полей A-F в 0
3. Вызов функции Set_CRC
4. Проверка значений CRC на 0 и Empty на TRUE
Тестовый пример 2
Номер тест-требования: 2a
Описание теста: В данном тесте проверяется соответствие
алгоритма вычисления поля CRC, заданному в спецификации требований.
Входные данные: CRC = 0, A-D заполнены байтами 01010101b
Ожидаемые выходные данные: CRC = 0111100b, Empty = FALSE
Сценарий теста:
1. Установка значения поля CRC в 0
2. Заполнение байт полей A-D байтами 01010101b
3. Вызов функции Set_CRC
4. Проверка значений CRC на 0111100b и Empty на FALSE
Тестовый пример 3
Номер тест-требования: 2a
Описание теста: В данном тесте проверяется неизменность
полей A-F записи при вычислении поля CRC (подсчете контрольной суммы).
Входные данные: CRC = 0, A-D заполнены байтами 01010101b
Ожидаемые выходные данные: A-D заполнены байтами 01010101b,
Сценарий теста:
1. Установка значения поля CRC в 0
2. Заполнение байт полей A-D байтами 01010101b
3. Вызов функции Set_CRC
4. Проверка значений байт полей A-D на 01010101b
Такая структура тест-плана позволяет описывать тестовые примеры с совершенно различными наборами входных и выходных данных и сценариями, однако при большом количестве тестовых примеров эта схема станет слишком громоздкой.
6.2. Оценка качества тестируемого кода - статистика выполнения тестов
В результате выполнения каждого тестового примера тестовое окружение сравнивает ожидаемые и реальные выходные значения. В случае, если эти значения совпадают, тест считается пройденным, т.к. система выдала именно те выходные значения, которые ожидались; в противном случае тест считается не пройденным.
Каждый непройденный тест потенциально указывает на потенциальный дефект в тестируемой системе, а общее их количество позволяет оценивать качество тестируемого программного кода и объем изменений, которые необходимо в него внести для устранения дефектов.
Для построения такой интегральной оценки после выполнения всех тестовых примеров тестовым окружением собирается статистика выполнения, которая, как правило, записывается в файл отчета о выполнении тестов.
6.3. Покрытие программного кода
6.3.1. Понятие покрытия
Одна из оценок качества системы тестов - это ее полнота, т.е. величина той части функциональности системы, которая проверяется тестовыми примерами. Обычно за меру полноты берут отношение объема проверенной части системы к ее объему в целом. Полная система тестов позволяет утверждать, что система реализует всю функциональность, указанную в требованиях, и, что еще более важно, - не реализует никакой другой функциональности.
К анализу покрытия программного кода можно приступать только после полного покрытия требований. Полное покрытие программного кода не гарантирует того, что тесты проверяют все требования к системе. Одна из типичных ошибок начинающего тестировщика - начинать с покрытия кода, забывая про покрытие требований.
6.3.2. Уровни покрытия
6.3.3. По строкам программного кода (Statement Coverage)
Для обеспечения полного покрытия программного кода на данном уровне необходимо, чтобы в результате выполнения тестов каждый оператор был выполнен хотя бы один раз.
6.3.3.1. По веткам условных операторов (Decision Coverage)
Для обеспечения полного покрытия по данному методу каждая точка входа и выхода в программе и во всех ее функциях должна быть выполнена по крайней мере один раз, и все логические выражения в программе должны принять каждое из возможных значений хотя бы один раз, - таким образом, для покрытия по веткам требуется как минимум два тестовых примера.
6.3.3.2. По компонентам логических условий
Для более полного анализа компонент условий в логических операторах существует несколько методов, учитывающих структуру компонент условий и значения, которые они принимают при выполнении тестовых примеров.
6.3.3.3. Покрытие по условиям (Condition Coverage)
Для обеспечения полного покрытия по данному методу каждая компонента логического условия в результате выполнения тестовых примеров должна принимать все возможные значения, но при этом не требуется, чтобы само логическое условие принимало все возможные значения. Так, например, при тестировании следующего фрагмента:
if (condition1 | condition2)
functionA();
else
functionB();
для покрытия по условиям потребуется два тестовых примера:
(1) Вход: condition1 = true, condition2 = false
(2) Вход: condition1 = false, condition1 = true.
При этом значение логического условия будет принимать значение только true, таким образом, при полном покрытии по условиям не будет достигаться покрытие по веткам.
6.3.3.4. Покрытие по веткам/условиям (Condition/Decision Coverage)
Данный метод сочетает требования предыдущих двух методов - для обеспечения полного покрытия необходимо, чтобы как логическое условие, так и каждая его компонента приняла все возможные значения.
Для покрытия рассмотренного выше фрагмента с условием condition1 | condition2 потребуется 2 тестовых примера:
1. Вход: condition1 = true, condition2 = true
2. Вход: condition1 = false, condition1 = false.
Однако, эти два тестовых примера не позволят протестировать правильность логической функции - вместо OR в программном коде могла быть ошибочно записана операция AND.
6.3.3.5. Покрытие по всем условиям (Multiple Condition Coverage)
Для выявления неверно заданных логических функций был предложен метод покрытия по всем условиям. При данном методе покрытия должны быть проверены все возможные наборы значений компонент логических условий. Т.е. в случае n компонент потребуется 2n тестовых примеров, каждый из которых проверяет один набор значений, Тесты, необходимые для полного покрытия по данному методу, дают полную таблицу истинности для логического выражения.
Несмотря на очевидную полноту системы тестов, обеспечивающей этот уровень покрытия, данный метод редко применяется на практике в связи с его сложностью и избыточностью.
Еще одним недостатком метода является зависимость количества тестовых примеров от структуры логического выражения. Так, для условий, содержащих одинаковое количество компонент и логических операций:
a && b && (c || (d && e))
((a || b) && (c || d)) && e
потребуется разное количество тестовых примеров. Для первого случая для полного покрытия нужно 6 тестов, для второго - 11.
6.3.4. Метод MC/DC для уменьшения количества тестовых примеров при 3-м уровне покрытия кода
Для уменьшения количества тестовых примеров при тестировании логических условий фирмой Boeing был разработан модифицированный метод покрытия по веткам/условиям (Modified Condition/Decision Coverage или MC/DC) [25, 26]. Данный метод широко используется при верификации бортового авиационного программного обеспечения согласно процессам стандарта DO-178B [7].
Для обеспечения полного покрытия по этому методу необходимо выполнение следующих условий:
-
каждое логическое условие должно принимать все возможные значения;
-
каждая компонента логического условия должна хотя бы один раз принимать все возможные значения;
-
должно быть показано независимое влияние каждой из компонент на значение логического условия, т.е. влияние при фиксированных значениях остальных компонент.
6.3.5. Анализ покрытия
Целью анализа полноты покрытия кода является выявление участков кода, которые не выполняются при выполнении тестовых примеров. Тестовые примеры, основанные на требованиях, могут не обеспечивать полного выполнения всей структуры кода. Поэтому для улучшения покрытия проводится анализ полноты покрытия кода тестами, и при необходимости проводятся дополнительные проверки, направленные на выяснение причины недостаточного покрытия и определение необходимых действий по его устранению. Обычно анализ покрытия выполняется с учетом следующих соглашений:
-
анализ должен подтвердить, что полнота покрытия тестами структуры кода соответствует требуемому виду покрытия и заданному минимально допустимому проценту покрытия;
-
анализ полноты покрытия тестами структуры кода может быть выполнен с использованием исходного текста, если программное обеспечение не относится к уровню A. Для уровня А необходимо проверить объектный код, сгенерированный компилятором, и выяснить, трассируется ли он в исходный текст или нет. Если объектный код не трассируется в исходный текст, должны быть проведены поверки объектного кода на предмет правильности генерации последовательности команд. Примером объектного кода, который напрямую не трассируется в исходный текст, но генерируется компилятором, может быть проверка выхода за заданные границы массива;
-
анализ должен подтвердить правильность передачи данных и управления между компонентами кода.
Анализ полноты покрытия тестами может выявить часть исходного кода, которая не исполнялась в ходе тестирования. Для разрешения этого обстоятельства могут потребоваться дополнительные действия в процессе проверки программного обеспечения.