16. Ручные методы тестирования.

Ручные методы.

• Индивидуальное ручное тестирование;

• Коллективный сквозной просмотр текста;

• Коллективная инспекция текста.

Статические методы.

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

Динамические методы.

Вручную моделируется процесс выполнения программы при заданных исходных данных.

Исходными данными таких проверок являются:

• техническое задание;

• спецификации;

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

• схемы отдельных компонентов;

• на более поздних этапах – алгоритмы и тексты программ и тестовые наборы данных.

17. Машинные методы тестирования.

Детерминированное тестирование.

Требует многократного выполнения на ЭВМ программы с использованием определенных, специально подобранных тестовых наборов данных.

18. Методы структурного тестирования

Детальное изучение текста программы и построение входных тестовых наборов данных (ТНД) осуществляется на основе одного из 4 критериев:

• покрытие операторов

• покрытие узлов ветвлений (покрытие решений)

• покрытие условий

• комбинаторное покрытие условий

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

Покрытие операторов – выбирается такой ТНД, который вызывает выполнение каждого оператора в программе хотя бы один раз.

Покрытие решений - требует создать такой ТНД, в котором в каждом узле ветвления должен быть обеспечен переход по веткам «истина-ложь» хотя бы один раз.

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

Комбинаторное покрытие условий – создать такое число ТНД, чтобы все возможные комбинации результатов условия в каждом решении выполнялись хотя бы один раз.

19. Методы функционального тестирования.

Методы «черного ящика»:

• эквивалентного разбиения

• анализа граничных значений

• функциональных диаграмм

1. Метод эквивалентных разбиений:

Два этапа: выделение классов эквивалентности и построение тестов

Класс эквивалентности (КЭ) – множество входных значений, каждое из которых имеет равную вероятность обнаружения конкретного типа ошибок. КЭ выделяются путем анализа входного условия и разбиением его на две или более групп. Для любого входного условия выделяются два класса: правильный КЭ (правильные входные данные) и неправильный (ошибочные) КЭ.

Для нахождения классов эквивалентности используют следующие правила:

• если входное условие описывает область значений, то определяются один правильный и два неправильных КЭ

• если входное условие описывает ситуацию «должно быть», то один правильный и один неправильный КЭ

• если входное условие описывает конечное число конкретных значений и есть основания полагать, что каждое значение программа трактует особо, то определяется правильный КЭ для каждого значения и один неправильный

На основании КЭ строятся тестовые наборы данных (ТНД), причем надо стремиться для правильных КЭ к минимальному числу наборов, т.е. каждый тест должен по возможности покрывать большее число правильных КЭ. Для каждого неправильного КЭ строится хотя бы один ТНД.

2. Метод анализа граничных значений:

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

3. Метод построения функциональных диаграмм:

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

Метод построения функциональных диаграмм предполагает реализацию следующих процедур:

1. В спецификации программы выделяются причины и следствия (причина – отдельное входное условие или КЭ входных условий, следствие – выходное условие или результат преобразования).

2. Каждой причине и следствию присваивается уникальный номер.

3. Анализируется семантическое содержание спецификаций, которые преобразуются в булевский граф, который связывает причину и следствие.

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

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

6. Столбцы решений преобразуются в тесты

20. Тестирование модулей.

Тестированию подвергается:

• Интерфейс модулей

• Внутренние структуры данных

• Независимые пути

• Пути обработки ошибок

• Граничные условия

При тестировании путей выполнения обнаруживаются следующие категории ошибок:

• Ошибочные вычисления

• Некорректные сравнения

• Неправильный поток управления

Модуль не является автономной системой, поэтому для реализации тестирования модуля требуются дополнительные средства: драйвер, заглушка.

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

Заглушки замещают вызываемые модули.

21. Тестирование комплексов программ.

1. Тестирование функций (поиск различий программы и её спецификаций)

2. Тестирование системы (сопоставление результатов с исходными целями)

1. удобства использования

2. на предельных объёмах

3. на предельных нагрузках

4. удобства эксплуатации

5. защиты

6. производительности

7. требований к памяти

8. конфигурации оборудования

9. совместимости или конверсии

10. удобства установки

11. надёжности

12. восстановления

13. удобства обслуживания

14. документации

3. Приёмо-сдаточные испытания (процесс сравнения программы с исходным документом, отображающим требования и текущие нужды конечных пользователей данного ПС)

22. Отладка программ.

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

Составляющие процесса отладки:

• действия, направленные на выявление ошибок (тестирование);

• диагностика и локализация ошибок (определение характера и местонахождения ошибок);

• внесение исправлений в программу с целью устранения ошибок.

Чтобы понять, где возникла ошибка, приходится:

• узнавать текущие значения переменных;

• выяснять, по какому пути выполнялась программа.

23. Документирование ПС.

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

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

• Возможность использования на различных этапах проектирования и эксплуатации ПС;

• Обладание некоторыми качествами, способствующими обозримости построения и использования на любом этапе проектирования и эксплуатации, обновляемости по мере использования автоматизации поиска и коррекции и т.д.