Тестирование ПО

Tarkvara kvaliteet ja standardid
L.Joonas,
2012
Тестирование программного обеспечения
Предисловие


Программный комплекс - это
совокупность программных модулей,
предназначенных для решения одной
задачи и составляющих одно целое.
Основными разновидностями контроля
программного обеспечения являются
визуальный, статический и
динамический.
Визуальный контроль


Это проверка программ “за столом“ , без использования компьютера.
На первом этапе визуального контроля осуществляется чтение
программы, причем особое внимание уделяется следующим ее
элементам:





комментариям и их соответствию тексту программы;
условиям в операторах условного выбора ( IF, CASE ) и цикла;
сложным логическим выражениям;
возможности незавершения итерационных циклов ( WHILE, REPEAT, LOOP ).
Второй этап визуального контроля - сквозной контроль программы (ее
ручная прокрутка на нескольких заранее подобранных простых тестах ).
Статический контроль


Это проверка программы по ее тексту (без
выполнения) с помощью
инструментальных средств.
Наиболее известной формой статического
контроля является синтаксический
контроль программы с помощью
компилятора , при котором проверяется
соответствие текста программы
синтаксическим правилам языка
программирования.
Сообщения компилятора обычно делятся на несколько групп в
зависимости от уровня тяжести нарушения синтаксиса языка
программирования :




информационные сообщения и предупреждения , при обнаружении
которых компилятор, как правило, строит корректный объектный код и
дальнейшая работа с программой (компоновка, выполнение) возможна
(тем не менее сообщения этой группы также должны тщательно
анализироваться, так как их появление также может свидетельствовать
об ошибке в программе - например, из-за неверного понимания
синтаксиса языка);
сообщения об ошибках, при обнаружении которых компилятор
пытается их исправить и строит объектный код, но его корректность
маловероятна и дальнейшая работа с ним скорее всего не возможна;
сообщения о серьезных ошибках , при наличии которых построенный
компилятором объектный код заведомо некорректен и его дальнейшее
использование невозможно;
сообщения об ошибках, обнаружение которых привело к прекращению
синтаксического контроля и построения объектного кода .
Статический контроль (2)


Однако, практически любой компилятор пропускает
некоторые виды синтаксических ошибок. Место обнаружения
ошибки может находиться далеко по тексту программы от
места истинной ошибки, а текст сообщения компилятора
может не указывать на истинную причину ошибки.
Одна синтаксическая ошибка может повлечь за собой
генерацию компилятором нескольких сообщений об ошибках
(например, ошибка в описании переменной приводит к
появлению сообщения об ошибке в каждом операторе
программы, использующем эту переменную).
Статический контроль (3)



Второй формой синтаксического контроля может быть
контроль структурированности программ, то есть проверка
выполнения соглашений и ограничений структурного
программирования.
Примером подобной проверки может быть выявление в
тексте программы ситуаций, когда цикл образуется с
помощью оператора безусловного перехода (использования
оператора GOTO для перехода вверх по тексту программы ).
Для проведения контроля структурированности могут быть
созданы специальные инструментальные средства, а при их
отсутствии эта форма статического контроля может
совмещаться с визуальным контролем .
Статический контроль (4)


Третья форма статического контроля - контроль
правдоподобия программы, то есть выявление в ее тексте
конструкций, которые хотя и синтаксически корректны, но
скорее всего содержат ошибку или свидетельствуют о ней.
Основные неправдоподобные ситуации :





использование в программе неинициализированных переменных (то
есть переменных, не получивших начального значения) ;
наличие в программе описаний элементов, переменных, процедур,
меток, файлов, в дальнейшем не используемых в ее тексте;
наличие в тексте программы фрагментов, никогда не выполняющихся;
наличие в тексте программы переменных, ни разу не используемых
для чтения после присваивая им значений;
наличие в тексте программы заведомо бесконечных циклов
Статический контроль (5)


Даже если присутствие в тексте программы неправдоподобных
конструкций не приводит к ее неправильной работе, исправление
этого фрагмента повысит ясность и эффективность программы, т.
е. благотворно скажется на ее качестве.
Для возможности проведения контроля правдоподобия в полном
объеме также должны быть созданы специальные
инструментальные средства, хотя ряд возможностей по контролю
правдоподобия имеется в существующих отладочных и обычных
компиляторах.
Создание инструментальных средств контроля
структурированности и правдоподобия программ

Принципы, используемые при создании:




проведение этих дополнительных форм статического контроля
после завершения компиляции и только для синтаксически
корректных программ ;
максимальное использование результатов компиляции
программы и, в частности, информации, включаемой в листинг
компилятора;
вместо полного синтаксического разбора текста проверяемой
программы построение для нее списка идентификаторов и
списка операторов с указанием всех их необходимых
признаков.
При отсутствии инструментальных средств контроля
правдоподобия эта фаза статического контроля также может
объединяться с визуальным контролем.
Статический контроль (6)



Четвертой формой статического контроля программ
является их верификация, то есть аналитическое
доказательство их корректности.
В интуитивном смысле под корректностью понимают
свойства программы, свидетельствующие об отсутствии в
ней ошибок, допущенных разработчиком на различных
этапах проектирования (спецификации, проектирование
алгоритма и структур данных, кодирование ).
Отличие понятия корректности и надежности программ в
следующем :


надежность характеризует как программу, так и ее
“окружение” ( качество аппаратуры, квалификацию
пользователя и т.п. );
говоря о надежности программы, обычно допускают
определенную, хотя и малую, долю ошибок в ней и оценивают
вероятность их появления.
Статический контроль (7)

Надежность можно представить совокупностью следующих
характеристик :





1) целостность программного средства (способность его к
защите от отказов);
2) живучесть (способность к входному контролю данных и их
проверки в ходе работы) ;
3) завершенность (бездеффектность готового программного
средства, характеристика качества его тестирования);
4) работоспособность (способность программного средства к
восстановлению своих возможностей поле сбоев).
Очевидно, что не всякая синтаксически правильная
программа является корректной в указанном выше смысле,
т. е. корректность характеризует семантические свойства
программ.
Статический контроль (7)

С учетом специфики появления ошибок в программах
можно выделить две стороны понятия корректности :
1) корректность как точное соответствие целям разработки
программы (которые отражены в спецификации) при условии
ее завершения или частичная корректность ;
2) завершение программы , то есть достижение программой в
процессе ее выполнения своей конечной точки.
Статический контроль (8)

В зависимости от выполнения или невыполнения каждого
из двух названных свойств программы различают шесть
задач анализа корректности :
1) доказательство частичной корректности ;
2) доказательство частичной некорректности ;
3) доказательство завершения программы ;
4) доказательство незавершения программы ;
5) доказательство тотальной (полной ) корректности (то есть
одновременное решение первой и третьей задач);
6) доказательство некорректности (решение второй или
четвертой задачи).
Статический контроль (8)


Несмотря на достаточную сложность процесса верификации
программы и на то, что даже успешно завершенная верификация
не дает гарантий качества программы ( т.к. ошибка может
содержаться и в верификации ), применение методов
аналитического доказательства правильности очень полезно для
уточнения смысла разрабатываемой программы, а знание этих
методов благотворно сказывается на квалификации
программиста.
Наконец, динамический контроль программы - это проверка
правильности программы при ее выполнении на компьютере, т.е.
тестирование.
Основные понятия
тестирования



Задача тестирования состоит в том, чтобы найти ошибки
Тест – это набор входных данных и ожидаемый для таких
входных данных набор итоговых результатов
Программа ошибочна, если полученное значение не
соответствует ожидаемому.

Тест считается успешным, если ошибка найдена.

Хороший тест обнаруживает много ошибок.
Основные понятия
тестирования (2)



Тестирование производят не для того, чтобы показать, что в
программе нет ошибок, а для того, чтобы показать, что ошибки
есть.
«Аксиома Шуры-Буры": "В каждой программе есть ошибки.
Если в программе нет ошибок, то они есть в алгоритме. Если же
ошибок нет ни там, ни там, то такая программа никому не
нужна".
Гленфорд Майерс: "Тестирование - это процесс выполнения
программ с целью обнаружения ошибок".
Проектирование процесса тестирования
отвечает на такие вопросы:

Какие входные данные выбрать?

Как оценить полученные данные?

Когда заканчивать тестирование?

Кто будет проводить тесты?

Когда, что и как необходимо тестировать
повторно?
Проблемы тестирования



Разработка программ может оказаться достаточно длительной
- чем в это время должны заниматься тестировщики?
Сколько времени потребуется на завершение продукта, в
котором существует 500 известных ошибок?
Даже однострочное изменение в программе с вероятностью
55% либо не исправляет старую ошибку, либо вносит новую.
Если же учитывать изменения любого объема, то в среднем
менее 20% изменений корректны с первого раза!
Проблемы тестирования
(2)


zero-defect mindset - качество программ проверяется не
post factum, а постоянно в процессе разработки.
Программист не может перейти к разработке новой
функциональности, если существуют известные ошибки
высокого приоритета в частях, разработанных им ранее.
Идеальной кандидатурой на позицию тестировщика
становится наиболее опытный программист в команде.
Основные принципы организации
тестирования

Гленфорд Майерс:
1) необходимой частью каждого теста должно являться описание
ожидаемых результатов работы программы, чтобы можно было
быстро выяснить наличие или отсутствие ошибки в ней;
2) следует по возможности избегать тестирования программы ее
автором, т.к. кроме уже указанной объективной сложности
тестирования для программистов здесь присутствует и тот фактор,
что обнаружение недостатков в своей деятельности противоречит
человеческой психологии ( однако отладка программы эффективнее
всего выполняется именно автором программы ) ;
3) по тем же соображениям организация - разработчик программного
обеспечения не должна “единолично ” его тестировать ( должны
существовать организации, специализирующиеся на тестировании
программных средств);
4) правилом должно являться доскональное изучение результатов
каждого теста, чтобы не пропустить малозаметную на
поверхностный взгляд ошибку в программе;
Основные принципы организации
тестирования (2)
5) необходимо тщательно
подбирать тест не только для правильных (
предусмотренных ) входных данных, но и для неправильных
(непредусмотренных) ;
6) при анализе результатов кождого теста необходимо проверять, не делает ли
программа того, что она не должна делать ;
7) следует сохранять использованные тесты (для повышения эффективности
повторного тестирования программы после ее модификации или установки
у заказчика) ;
8) тестирования не должно планироваться исходя из предположения, что в
программе не будут обнаружены ошибки (в частности, следует выделять
для тестирования достаточные временные и материальные ресурсы) ;
9) следует учитывать так называемый “принцип скопления ошибок” :
вероятность наличия не обнаруженных ошибок в некоторой части
программы прямо пропорциональна числу ошибок, уже обнаруженных в
этой части ;
10) следует всегда помнить , что тестирование - творческий процесс, а не
относиться к нему как к рутинному занятию.
Различные подходы к
тестированию


Метод "черного ящика" - программе подаются некоторые данные
на вход и проверяются результаты, в надежде найти
несоответствия. При этом как именно работает программа
считается несущественным. Даже при таком подходе необходимо
иметь спецификацию программы для того, чтобы было с чем
сравнивать результаты.
Таким способом невозможно найти взаимоуничтожающиеся
ошибки, некоторые ошибки возникают достаточно редко
(ошибки работы с памятью) и потому их трудно найти и
воспроизвести и т.д.
Различные подходы к
тестированию (2)



Тестирование «белого ящика»: методы тестирования, которые
изучают не только внешнее поведение программы, но и ее
внутреннее устройство (исходные тексты)
Некоторые представители этого класса методик: чтение
программ, формальные просмотры программ, инспекции и т.п.).
Основной трудностью подобных методов является сложность
отслеживания вычислений времени выполнения.
Различные подходы к
тестированию (3)



При структурном тестировании (“белый ящик”) происходит
проверка логики программы.
Полным тестированием в этом случае будет такое, которое
приведет к перебору всех возможных путей на графе передач
управления программы (ее управляющем графе). Даже для
средних по сложности программ числом таких путей может
достигать десятков тысяч. Если ограничиться перебором только
линейных не зависимых путей, то и в этом случае
исчерпывающее структурное тестирование практически
невозможно, т. к. неясно, как подбирать тесты, чтобы обеспечить
“покрытие” всех таких путей.
Поэтому при структурном тестировании необходимо
использовать другие критерии его полноты, позволяющие
достаточно просто контролировать их выполнение, но не дающие
гарантии полной проверки логики программы.
Различные подходы к
тестированию (4)

Но даже если предположить, что удалось достичь полного
структурного тестирования некоторой программы, в ней
тем не менее могут содержаться ошибки, т.к.
1) программа может не соответствовать своей внешней
спецификации, что в частности, может привести к тому, что в
ее управляющем графе окажутся пропущенными некоторые
необходимые пути ;
2) не будут обнаружены ошибки, появление которых зависит от
обрабатываемых данных (т.е. на одних исходных данных
программа работает правильно, а на других - с ошибкой).
Различные подходы к
тестированию (5)



Поскольку исчерпывающее структурное тестирование
невозможно, необходимо выбрать такие критерии его
полноты, которые допускали бы их простую проверку и
облегчали бы целенаправленный подбор тестов.
Наиболее слабым из критериев полноты структурного
тестирования является требование хотя бы однократного
выполнения (покрытия) каждого оператора программы.
Более сильным критерием является так называемый критерий
С1 : каждая ветвь алгоритма (каждый переход) должна быть
пройдена (выполнена) хотя бы один раз.
Различные подходы к
тестированию (6)




Использование критерия покрытия условий может вызвать подбор тестов,
обеспечивающих переход в программе, который пропускается при использовании
критерия С1.
С другой стороны покрытие условий может не обеспечивать покрытия всех
переходов.
Практически единственным средством, предоставляемым современными
системами программирования, является возможность определения частоты
выполнения различных операторов программы (ее профилизации). Но с
помощью этого инструмента поддержки тестирования можно проверить
выполнение только слабейшего из критериев полноты - покрытие всех
операторов.
Правда, с помощью этого же инструмента можно проверить и выполнение
критерия С1. Но для этого предварительно текст программы должен быть
преобразован таким образом, чтобы все конструкции условного выбора ( IF и
CASE или SWITCH ) содержали ветви ELSE или DEFAULT, хотя бы и пустые. В
этом случае все ветви алгоритма , не выполнявшиеся на данном тесте будут
“видимы” из таблицы частоты выполнения операторов преобразованной
программы.
Различные подходы к
тестированию (7)


Наиболее эффективные процессы разработки ПО
используют некоторую комбинацию методик "черного
ящика" и "белого ящика".
Тестирование - это любая деятельность, направленная
на обнаружение ошибок в программном продукте
Различные подходы к тестированию
(4)
Название методики
Минимальная
эффективность
Средняя
эффективность
Максимальная
эффективность
Персональные просмотры
проектных документов
15%
35%
70%
Неформальные групповые
просмотры
30%
40%
60%
Формальные просмотры
проектных документов
35%
55%
75%
Формальные инспекции кода
30%
60%
70%
35%
65%
80%
Проверка за партой
20%
40%
60%
Тестирование модулей
10%
25%
50%
Функциональное тестирование
20%
35%
55%
Комплексное тестирование
25%
45%
60%
Тестирование в реальных
условиях
35%
50%
65%
93%
99%
99%
Моделирование и
прототипирование
Применение всех
перечисленных методик
тестирования
Об экономической стороне
тестирования




Тестирование является затратной деятельностью Поэтому в
большинстве случаев разработчики ПО заранее формулируют
какой-либо критерий качества создаваемых программ (так
называемую планку качества), добиваются выполнения этого
критерия и после этого прекращают тестирование и выпускают
продукт на рынок. Такая концепция получила название Good
Enough Quality (достаточно хорошое ПО), в противовес более
очевидной концепции Best Possible Quality (максимально
качественное ПО).
Принцип Good Enough Quality зачастую понимают неправильно,
ближе к формулировке Quality - If Time Permits (качество - если
будет время).
Практика показывает, что пользователи склонны со временем
забывать даже значительные задержки с выпуском продукта, но
плохое качество выпущенного продукта запоминается на всю
жизнь.
Good Enough Quality - это поиск разумного компромисса между
затратами на тестирование, длительностью разработки продукта и
его качеством.
Психологические аспекты
тестирования



Тестирование принципиально отличается от
программирования по своим психологическим
характеристикам. Программирование носит
конструктивистский характер, а тестирование ПО деструктивно по своей природе.
Для тестирования требуется иной склад характера, чем для
программирования.
Программист не должен тестировать свои собственные
программы. Более того, программист не должен
тестировать даже чужие программы.
Верификация и
валидация




Верификация:
«Правильно ли мы создаем продукт?"
ПО должно соответствовать своей спецификации
Валидация:
«Правильный ли продукт мы создаем?"
ПО должно делать то, что от него ожидает потребитель
Верификация и валидация (2)


Верификация - подтверждение посредством представления
объективных свидетельств того, что установленные требования
были выполнены.
Валидация - подтверждение посредством представления
объективных свидетельств того, что требования, предназначенные
для конкретного предполагаемого использования или применения,
выполнены.
Процесс V & V


Процесс V & V должен применяться на каждом
этапе жизненного цикла.
Две основные цели процесса:


Нахождение дефекта в системе
Оценка того – является ли система пригодной к
работе в данной ситуации?
Статическая и динамическая верификация


Инспекция ПО – связана с анализом представления статических
систем для нахождения проблем (статическая верификация)

Может быть дополнена документацией о средствах
разработки и анализом кода

Подробнее будет рассмотрено далее
Тестирование ПО – связано с изучением поведения продукта и
наблюдением над ним (dynamic verification)

Система запускается с тестовыми даннами и наблюдается ее
поведение.
Статические и
динамические V&V
Static
verification
Requirements
specification
Prototype
High-level
design
Formal
specification
Detailed
design
Program
Dynamic
validation
Тестирование программ



Ищет наличие ошибок, не их отсутствие
Успешный тест находит одну или много ошибок
Используется во взаимодействии со статической
верификацией для обеспечения полного процесса
V&V
Типы тестирования

Тестирование дефектов



Тесты конструируются для поиска дефектов.
Успешный тест для поиска дефектов должен найти дефекты в
системе
Статистическое тестирование

Тест разработан для моделирования последовательности
пользовательских запусков. Используется для оценки
надежности
Валидация ПО



Верификация и валидация рассчитаны на то, чтобы
показать, что система соответствует своей
спецификации и отражает требования пользователей
системы
Включает в себя проверку и обзор процессов и
тестирование системы
Тестирование системы включает в себя работу системы
с таким набором тестовых данных, которые
определяются спецификацией, как реальные данные, с
которыми будет работать система
Процесс тестирования
Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing
Component
testing
Integration testing
User
testing
Стадии тестирования





Unit testing
 Тестирования отдельных элементов
Module testing
 Тестируется набор связанных друг с другом элементов
Sub-system testing
 Модули соединяются в подсистемы и тестируются.
Фокусировка на тестировании интерфейса
System testing
 Тестирование всей системы. Тестирование
неожиданных ситуаций
Acceptance testing
 Тестирование с пользовательскими данными. Оценка
пригодности системы
Фазы тестирования
Requirements
specification
System
specification
System
integration
test plan
Acceptance
test plan
Service
System
design
Acceptance
test
Detailed
design
Sub-system
integration
test plan
System
integration test
Sub-system
integration test
Module and
unit code
and tess
Тестирование дефектов

Тестирование программ для
установления присутствующих
дефектов
Виды тестирования
Тестирование дефектов
 Интегрированное тестирование
 Объектно-ориентированное
тестирование
 Стендовое тестирование

Процесс тестирования


Тестирование компонентов

Тестирование индивидуальных компонентов

Входит в компетенцию разработчика компонентов (за
исключением критических систем)

Тесты, явившиеся результатом опытов разработчика
Интегрированное тестирование

Тестирование групп компонентов, собранных в системы или
подсистемы

Входит в компетенцию независимой команды тестеров

Тесты базируются на спецификации системы
Фазы тестирования
Component
testing
Integration
testing
Software developer
Independent testing team
Тестирование дефектов



Целью тестирования является обнаружение
дефектов в программе
Успешный тест на дефекты – это тест, который
провоцирует программы вести себя аномальным
образом
Тест показывает наличие, а не отсутствие дефектов.
Приоритеты тестирования




Только полное, исчерпывающее тестирование может
показать, что программа свободна от ошибок. Полное
тестирование невозможно.
Тест должен исследовать возможности целой системы
больше, чем возможности компонентов системы
Тестирование старых возможностей более важно, чем
тестирование новых возможностей
Тестирование типичных ситуаций более важно, чем
тестирования пограничных ситуаций.
Тестовые данные и наборы
тестовых данных


Test data - Тестовые данные - Входные данные,
созданные для тестирования системы
Test cases – наборы тестовых данных – входные данные
для тестирования системы и результаты, ожидаемые для
этих входных данных в случае, если система работает в
соответствии со спецификацией.
Процесс тестирования
дефектов
Test
cases
Design test
cases
Test
data
Prepare test
data
Test
results
Run program
with test data
Test
reports
Compare results
to test cases
«Черный ящик»
Вариант тестирования, при котором
программа считается «черным
ящиком»
 Набор данных теста базируется на
спецификации
 Планирование теста осуществлятся
на ранней стадии процесса
создания ПО

«Черный ящик» (2)
Input test data
I
Inputscausing
anom
alous
behaviour
e
System
O
utputtest results
O
e
O
utputsw
hichreveal
thepresenceof
defects
Эквивалентные классы



Исходные данные и результаты часто попадают в
разные классы, в которых члены класса связаны
между собой
Для каждого из этих эквивалентных классов
программа ведет себя одинаково для каждого члена
класса
Наборы данных должны быть выбраны из каждого
класса
Эквивалентные классы
(2)
Invalid inputs
System
Outputs
Valid inputs
Руководство по тестированию
(последовательности)




Протестируйте ПО для последовательностей,
которые имеют только одно значение
В различных тестах используйте
последовательности разных размеров
В тестах должны быть использованы и начальный
и конечный элемент последовательности
Использоватть последовательности нулевой
длины
Структурное тестирование



Иногда называемое тестирование с помощью белого
ящика
Наборы данных создаются в соответствии со
структурой программы. Знание кода используется для
создания наборов данных
Целью теста является проверить все операторы
программы
Белый ящик
Test data
Tests
Derives
Component
code
Test
outputs
Path testing



Задачей тестирования является убеждение в том, что набор
тестовых данных таков, что каждый путь в программе
используется хотя бы один раз
Стартовой точкой тестирования является управляющий граф
программы
Условные операторы, таким образом, являются узлами такого
графа
Управляющий граф программы



Описывает логику программы. Каждая ветвь
показывается, как отдельный путь и циклы показаны
стрелками, замыкающимися на узле условия
Используется как основа вычисления cyclomatic
complexity – сложности организация циклов в
программе
Cyclomatic complexity = Количество углов –
количество узлов +2
Cyclomatic complexity




Число тестов для тестирования всех операторов равно
cyclomatic complexity
Cyclomatic complexity равно числу всех условий в
программе
Полезно при осторожном использовании
Даже при прохождении всех путей не проходятся все
комбинации путей
1
bottom > top
while bottom <= top
2
3
if (elemArray [mid] == key
4
8
5
(if (elemArray [mid]< key
6
9
7
Binary search flow graph
Независимые пути





1, 2, 3, 8, 9
1, 2, 3, 4, 6, 7, 2
1, 2, 3, 4, 5, 7, 2
1, 2, 3, 4, 6, 7, 2, 8, 9
Тестовые данные должны быть выбраны таким образом, чтобы
обеспечить прохождение всех этих путей.
Ключевые положения




Тестируйте часто используемые части программы больше, чем
используемые редко
Эквивалентные разделы – это наборы тестовых данных, при
которых программа ведет себя одинаково
Тестирование черного ящика основано на системной
спецификации
Структурное тестирование определяет наборы данных, при
которых проходятся все пути программы
Ключевые положения (2)


Полное тестирование означает, что все операторы будут
пройдены хотя бы один раз
Дефекты интерфейса возрастают из-за неверного прочтения
спецификации, непонимания, ошибок, недостаточности
времени для изучения спецификации.