СиППО (24, 29-41) (Ответы на все вопросы), страница 2

Отрывок программы

Xi = 3.5

Ki = 5

if ( z>x) AND (k<c) then k:=k+1

else Ki := k-1

Z:=K*x

нарисуем для него граф

1

  \

   2

     \

     3--4----5

     |    /      /

     |   /     /

     6      /

     |     /

     |   /

     7

цикломатическое число = 3

Цикломатическая сложность графа программы -- это цикломатическое число графа программы

Программа, которая не содержит разветвлений и циклов имеет цикломатическую сложность >1

Таким образом, составить тесты, чтобы все пути были пройдены хотя бы 1 раз

Усложняющее обстоятельство: программа имеет 25 строк, то граф усложняется, кол-во путей растет

Можно тестировать программу по частям (ваш К.О)

Упрощающее обстоятельство:

допустим,

if ( k>50) then p:=1 else p:=-1

z:=4.8

if (k<20) then t:=1 else t:0

z:=p*z

Могут быть противоречивые пути, невозможно подобрать данные, чтобы путь пройти.

Рекомендуют начинать с функционального тестирования. Если результаты хорошие и логическая сложность задачи невелика (мало условных операторов), то этим ограничиваются.

Если в программе есть ошибки и найти их не удалось, или задача обладает высокой структурой, то надо проводить структурное тестирование.

Проектируя тесты пришли к выводу, что надо N тестов. После этого нарисовали граф программы и стали смотреть сколько путей охватывают эти N тестов.

1) N - путей, каждый из тестов соответствует одному пути. Значит эти N тестов надо выполнить

2) M - путей ( != Т),

21 N > M

* <strike>t1</strike>, t2 по одному пути

* t1, t2 - на самом деле разные, но пойдут по одному пути => нашли 1 ошибку

22. N < M

* эти пути противоречивы,и их пройти невозможно

* найден путь, не охваченный тестами => увеличить количество тестов

32.  Совместное тестирование модулей.

Тестирование программных комплексов, построенных функциональной декомпозицией (ФД)

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

Для модуля Б кроме драйвера нужна заглушка или заглушки, которые имитируют работу модулей, которые Б будет вызывать. Алгоритм простой, чтобы не тестировать.

Вывод: n-ной количество драйверов и заглушек.

"+" - возможно тщательное тестирование всех модулей

работу можно распараллелить

уменьшение затрат машинного времени по сравнению с пошаговым тестированием.

Протестируем модули самого нижнего уровня. После этого поднимемся на следующий уровень, но заглушки не использ., в качестве заглушек протестируем модули А1 и Б2 (Снизу Вверх)

Сверху вниз: верхний уровень, нужны заглушки. Так до нижнего.

В большинстве случаев пошаговое тестирование лучше.

В чем преимущество?

1. Можно тщательно протестировать логику 1го уровня

2. при тестировании модулей следующего уровня проверить интерфейс, вместе с этим протестировать модули нижнего уровня

Недостатки: долго не существует программа как целое.

Системные ошибки всплывают относительно позднее.

(тут видимо чувак совсем устал писать и почерк стал нечитаем)

(+) Начинает функционир. раньше, как единое целое (чуть выше было указано взаимоисключающее понятие)

(-) подбирать наверху такие данные чтобы все уровни были

Надо учитывать информационные связи. (??????)

Тестирование информации

Системное тестирование

Цель: проверить решает ли программа задачу, для которой была задумана и обладает ли она заданными характеристиками.

Тестирование программных комплексов, построенных по ООП 

- Тестировать методы в составе классов

- Тестирование классов - взаимодействие классов, иерархии классов

ob1:cl1 ---- message ----- ob3:cl3

         \                           /

          \                       /

               \               /

                 ob2:cl1

объекты передают друг другу сообщения (вызов методов класса-адресата)

ob3 - тестирование примитивных классов.

ОПР: Класс называется примитивным, если он только принимает сообщения (если он не отправляет сообщения)

CL3

Данные

Методы

(все в квадратике и две перекладинки)

Должны убедиться, что класс принимает и обрабатывает направленные на него сообщения.

Проверка интерфейсной части

Занимаемся следующим классом ob2

Проверить принимает ли сообщения и отправляет ли сообщения и корректны ли все данные и т.д. отрабатываем все схемы

- Тестирование иерархии классов

(тут какая-то неприличная картинка)

                     A

                     F() Abstract

                     |

               ------------------

         *         |                |

               B               C

               f()

Всегда сверху - вниз!!!11

Допустим класс А всесторонне проверили:

----> X : B

Если сообщение отрабатывается проверенным методом, то можно не тестировать, т.к. там протестировано (К.О?)

При тестировании методов должны убедиться, что проверены все реализации.

f()

-------> y:C

f()

-------> x:B  -- новая реализация и ее надо проверить

Класс является абстрактным, значит не можем тестировать напрямую:

1. Запомним абстрактные методы в дельфи и чисто виртуальные функции Си++ и проверим

2. Спустимся в (*), считаем комментарии и тестир. абстр методы и т.д. (чо-чо?)

Регрессивное тестирование -- проверка: после разработки новой версии проверяем функциональность старой версии.

33.  Тестирование программ и жизненный цикл программного продукта.

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

Дефект – симптом существования ошибки в программе или возникновение проблем при ее выполнении.

Отладка – выявление причин и устранение ошибок в программах.

Начальное тестирование проводит автор программы. Дальнейшее тестирование должны проводить специалисты, не принявшие участие в реализации, а на заключительной стадии тестирования – специалисты, вообще не участвовавшие в разработке. По принципу «Со стороны виднее». Отладку, «к сожалению», придется выполнить самому автору: кто лучше его знает, где может быть ошибка и как ее устранить?    

Рассмотрим организацию тестирования и его разновидности. Особенности тестирования объектно-ориентированных программ будут рассмотрены в следующей главе. При тестировании необходимо выполнение следующих задач:

·        Планирование тестов для каждой итерации, включая тесты на целостность и системные тесты. Тесты на целостность проводятся после каждого билда,  системные тесты – только в конце итерации.

·        Проектирование и реализация тестов.

·        Проведение тестов и анализ их результатов. Билды, в которых обнаруживаются дефекты, возвращают на доработку и подвергают повторному тестированию.

Процесс тестирования начинается с планирования, которое выполняет инженер по тестированию. Он же проектирует тесты.  Инженер по компонентам реализует тесты. Тестер по целостности проводит тестирование интеграции, а системный тестер – тестирование системы. В завершение процесса инженер по тестированию оценивает его результаты.

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

Регрессионное тестирование – это повторное тестирование части билда, которая уже тестировалась на предыдущем билде. Цель регрессионного тестирования: убедиться в том, что «старая функциональность» из «старого билда» продолжает работать и после добавления «новой функциональности» через «новый билд».

Системные тесты используются для проверки правильности работы системы. Каждый  системный тест проверяет, как варианты использования будут работать в разных условиях.   Многие системные тесты могут быть найдены на основе анализа вариантов использования. На заключительной стадии системные тесты должны соответствовать реальным условиям эксплуатации программного продукта.

Основные процессы жизненного цикла:

1.     заказ,

2.     поставка,

3.     разработка,

4.     эксплуатация,

5.     сопровождение.

Вспомогательные процессы жизненного цикла:

1.     документирование,

2.     управление конфигурацией,

3.     обеспечение качества,

4.     верификация,

5.     аттестация,

6.     совместный анализ,

7.     аудит, решение проблем.

Организационные процессы жизненного цикла:

1.     управление,

2.     создание инфраструктуры,

3.     усовершенствование,

4.     обучение.

Процесс разработки состоит из следующих работ:

1.     подготовка процесса,

2.     анализ требований к системе,

3.     проектирование системной архитектуры,

4.     анализ требований к программным средствам,

5.     проектирование программной архитектуры,

6.     техническое проектирование программных средств,

7.     программирование и тестирование программных средств,

8.     сборка программных средств,

9.     квалификационное испытание программных средств,

10.                       сборка системы,

11.                       квалификационные испытания системы,

12.                       ввод в действие программных средств,

13.                       обеспечение приемки программных средств.

Процесс эксплуатации состоит из следующих работ:

1.     подготовка процесса,

2.     эксплуатационные испытания,

3.     эксплуатация системы,

4.     поддержка пользователя.

Процесс сопровождения состоит из следующих работ:

1.     подготовка процесса,

2.     анализ проблем и изменений,

3.     внесение изменений,

4.     проверка и приемка при внесении изменений,

5.     перенос, снятие с эксплуатации.