Архитектуры и модели программ и знаний
Лекция 10
Тестирование и верификация программ
Сафонов Владимир Олегович
Профессор кафедры информатики Заведующий лабораторией Java-технологии
(http://polyhimnie.math.spbu.ru/jtl)
Санкт-Петербургский государственный университет
Email: vosafonov@gmail.com
WWW: http://www.vladimirsafonov.org
Тестирование программ
Тестирование – систематическая проверка
программы с целью обнаружения ошибок, исследования характеристик программы и объема используемых ею ресурсовЭ. Дейкстра: “Тестирование может доказать лишь
наличие ошибок в программе, но никогда не докажет их отсутствия”
В общем виде задача формальной верификации
программ (вместо их тестирования) до сих пор не решена.
Успешен опыт верификации только для некоторых классов программ (встроенные системы, телекоммуникационные системы)
“Тестирование vs. отладка” : тестирование и
отладка – не одно и то же. Отладка (debugging) – поиск ошибок
Microsoft, 2002: Penetration testing – важная часть
инициативы и парадигмы TWC
Согласно принципам Extreme Programming (XP) ,
Виды и методы тестирования
Тестирование модулей (JUnit, NUnit) и тестирование
системы
В современных интегрированных средах unit-тесты
генерируются автоматически
Регрессионное тестирование – тестирование всех
исправлений ошибок. Все регрессионные тесты должны проходить после каждого исправления ошибки (trustworthy bug fixing)
Тестирование на совместимость (на соответствие
некоторой спецификации); примеры – JCK для Java; TCK для JSR; тесты BSI 5.5 для компилятора Sun
Pascal
Тестирование производительности (benchmarking) –
например, набор тестов SPEC. Тестирование производительности программы во время ее
выполнения
Стрессовое тестирование – тестирование системы
на устойчивость к предельным нагрузкам -
например: миллион генераций объектов; миллион
обращений к серверу
Стратегии тестирования
Белый ящик – исходный код тестируемой
программы доступен. Цель – достижение максимального тестового покрытия (block coverage, branch coverage, condition coverage, method coverage, и т.д.)Черный ящик – исходный код тестируемой
программы недоступен. Цель – достижение 100% покрытия методов и тестирование с использованием “разумного максимума” наборов входных данных
Стратегии выбора входных данных для тестирования (по Г. Майерсу)
Граничные значения – тестирование не граничные
значения, такие как 0, 1, -1, null (nil)
Разбиение на классы эквивалентности – выбор
одного значения из каждого класса эквивалентности
(подмножества значений аргумента). Классы эквивалентности выбираются таким образом, что тестируемая программа, предположительно, ведет
себя одинаково при тестировании с любым значением аргумента, взятым из какого-либо определенного класса
Пример: НОД(x, y), где x > 0 – целое
положительное значение
Для тестирования вызова P(x, y) всего требуется
M * N наборов аргументов, где M – возможное
число значений x; N – возможное число значений y
Статическое и динамическое тестирование
Статическое тестирование (в среднем помогает
обнаружить до 70% ошибок) : многократное
переписывание кода; индивидуальный сквозной просмотр кода; групповой сквозной просмотр кода;
групповая инспекция кода; использование инструментов статической проверки кода
Групповая инспекция кода – анализ кода на типичные
ошибки; при этом может использоваться утилита- верификатор исходного кода (lint, Flexelint и т.д.)Типичные ошибки:
- использование неопределенныого значения
переменной - выход индекса за границу массива
- ошибки при работе с указателями (отсутствие проверки на nil / null, неверное приведение указателя к другому типу и т.д.)
- ошибки интерфейса: например, вызов P(y, x)
вместо P(x, y), где x, y – одного типа - переполнение буфера, например:
strncpy (dest, source, SOURCE_LENGTH); // возможна атака
Контрольный список при инспекции кода (И. Соммервилл)
Для инспекции кода должен использоваться список типичных ошибокЭтот список зависит от языка реализации
системы и содержит характерные ошибки, которые могут быть допущены при программировании на этом языкеВ целом, чем слабее типизация в языке, тем больше контрольный список
Примеры: инициализация, именование констант, завершение цикла, выход за границу массива и т.д.
Проверки при инспекции кода (И. Соммервилл)
Data faults |
Are all program variables initialised before their values are |
|
used? |
|
Have all constants been named? |
|
Should the upper bound of arrays be equal to the size of the |
|
array or Size -1? |
|
If character strings are used, is a de limiter explicitly |
|
assigned? |
|
Is there any possibility of buffer overflow? |
Control faults |
For each conditional statement, is the condition correct? |
|
Is each loop certain to terminate? |
|
Are compound statements correctly bracketed? |
|
In case statements, are all possible cases accounted for? |
|
If a break is required after each case in case statements, has |
|
it been included? |
Input/output faults |
Are all input variables used? |
|
Are all output variables assigned a value before they are |
|
output? |
|
Can unexpected inputs cause corruption? |
Проверки при инспекции кода 2 (И. Соммервилл)
Interface faults |
Do all function and method calls have the correct number |
|
of parameters? |
|
Do formal and actual parameter types match? |
|
Are the parameters in the right order? |
|
If comp onents access shared memo ry, do they have the |
|
same mo del of the shared memo ry structure? |
Storage |
If a linked structure is modified, have all links been |
manageme nt faults |
correctly reassigned? |
|
If dynamic storage is used, has space been allocated |
|
correctly? |
|
Is space explicitly de-allocated after it is no longer |
|
required? |
Exception |
Have all possible error conditions been taken into account? |
manageme nt faults |
|
Критерии инспекции кода (И. Соммервилл)
500 операторов в час – средняя скорость инспекции кода125 операторов в час, при индивидуальной подготовке
90-125 операторов в час – то, чего можно реально ожидатьИнспекция кода – дорогостоящий процессВ Великобритании инспекция 500
строк кода стоит около 40 человеко- часов работы, или примерно £2800