Презентация на тему: Тестирование программных продуктов. Стуктурное и функциональное тестирование

Тестирование программных продуктов. Стуктурное и функциональное тестирование.
Тестирование
Содержание
Зависимость вероятности правильного исправления и его стоимости
Современные технологии тестирования
Тестирование
Тестирование
Основные принципы тестирования
Формирование тестовых наборов
Два различных подхода к формированию тестовых наборов:
Структурный подход
Функциональный подход
Ручной контроль программного обеспечения
Ручной контроль программного обеспечения
Основные методы ручного контроля
Инспекции исходного текста
1. Контроль обращений к данным
2. Контроль вычислений
3. Контроль передачи управления
4. Контроль межмодульных интерфейсов
Сквозные просмотры
Сквозные просмотры
Проверка за столом
Оценка программ
Структурное тестирование
Структурный подход. Недостатки
Формирование тестовых наборов
Покрытие операторов
Покрытие решений (переходов)
Покрытие условий
Покрытие решений/условий
Комбинаторное покрытие условий
Функциональное тестирование
Функциональное тестирование
Функциональное тестирование
Функциональное тестирование
Эквивалентное разбиение
Анализ граничных значений
Анализ причинно-следственных связей
Предположение об ошибке
Тестирования модулей и комплексное тестирование
Восходящее тестирование
Восходящее тестирование. Достоинства и недостатки
Нисходящее тестирование
Нисходящее тестирование
Нисходящее тестирование. Достоинства и недостатки
Комбинированный подход
Тестирование программного обеспечения специалистами
Комплексное тестирование
Критерии завершения тестирования и отладки
Критерии завершения
Критерии завершения
Оценочное тестирование
Оценочное тестирование
Оценочное тестирование. Виды тестирования
1/55
Средняя оценка: 4.2/5 (всего оценок: 61)
Код скопирован в буфер обмена
Скачать (662 Кб)
1

Первый слайд презентации: Тестирование программных продуктов. Стуктурное и функциональное тестирование

1 Лекция 12.11.2020

Изображение слайда
2

Слайд 2: Тестирование

2 Тестирование - очень важный и трудоемкий этап процесса разработки программного обеспечения, так как правильное тестирование позволяет выявить подавляющее большинство ошибок, допущенных при составлении программ. Процесс разработки программного обеспечения предполагает три стадии тестирования : автономное, комплексное и системное, каждая из которых соответствует завершению соответствующей части Системы. Различают два подхода к формированию тестов: структурный и функциональный.

Изображение слайда
3

Слайд 3: Содержание

3 Виды контроля качества разрабатываемого программного обеспечения Ручной контроль программного обеспечения Структурное тестирование Функциональное тестирование Тестирования модулей и комплексное тестирование Оценочное тестирование

Изображение слайда
4

Слайд 4: Зависимость вероятности правильного исправления и его стоимости

4

Изображение слайда
5

Слайд 5: Современные технологии тестирования

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

Изображение слайда
6

Слайд 6: Тестирование

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

Изображение слайда
7

Слайд 7: Тестирование

7 Три стадии тестирования: автономное тестирование компонентов программного обеспечения; комплексное тестирование разрабатываемого программного обеспечения; системное или оценочное тестирование на соответствие основным критериям качества.

Изображение слайда
8

Слайд 8: Основные принципы тестирования

8 предполагаемые результаты должны быть известны до тестирования; следует избегать тестирования программы автором; необходимо досконально изучать результаты каждого теста; необходимо проверять действия программы на неверных данных; необходимо проверять программу на неожиданные побочные эффекты на неверных данных.

Изображение слайда
9

Слайд 9: Формирование тестовых наборов

9 Удачным следует считать тест, который обнаруживает хотя бы одну ошибку. С этой точки зрения хотелось бы использовать такие наборы тестов, каждый из которых с максимальной вероятностью может обнаружить ошибку. Формирование набора тестов имеет большое значение, поскольку тестирование является одним из наиболее трудоемких этапов (от 30 до 60 % общей трудоемкости) создания программного продукта. Причем доля стоимости тестирования в общей стоимости разработки имеет тенденцию возрастать при увеличении сложности программного обеспечения и повышении требований к их качеству.

Изображение слайда
10

Слайд 10: Два различных подхода к формированию тестовых наборов:

Структурный Функциональный 10

Изображение слайда
11

Слайд 11: Структурный подход

11 Структурный подход базируется на том, что известна структура тестируемого программного обеспечения, в том числе его алгоритмы («стеклянный ящик»). Тесты строят так, чтобы проверить правильность реализации заданной логики в коде программы.

Изображение слайда
12

Слайд 12: Функциональный подход

12 Функциональный подход основывается на том, что структура программного обеспечения не известна («черный ящик»). Тесты строят, опираясь на функциональные спецификации. Этот подход называют также подходом, управляемым данными, так как при его использовании тесты строят на базе различных способов декомпозиции множества данных.

Изображение слайда
13

Слайд 13: Ручной контроль программного обеспечения

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

Изображение слайда
14

Слайд 14: Ручной контроль программного обеспечения

14 Исходными данными для таких проверок являются: техническое задание, спецификации, структурная и функциональная схемы программного продукта, схемы отдельных компонентов, алгоритмы, тексты, тестовые наборы. Доказано, что ручной контроль способствует существенному увеличению производительности и повышению надежности программ и с его помощью можно находить от 30 до 70 % ошибок логического проектирования и кодирования. Методы ручного контроля обязательно должны использоваться в каждом программном проекте.

Изображение слайда
15

Слайд 15: Основные методы ручного контроля

15 Основными методами ручного контроля являются: инспекции исходного текста, сквозные просмотры, проверка за столом, оценки программ.

Изображение слайда
16

Слайд 16: Инспекции исходного текста

16 Инспекции исходного текста представляют собой набор процедур и приемов обнаружения ошибок при изучении текста группой специалистов. В эту группу входят: автор программы, проектировщик, специалист по тестированию и координатор. Общая процедура инспекции предполагает следующие операции: участникам группы заранее выдается листинг программы и спецификация на нее; программист рассказывает о логике работы программы и отвечает на вопросы инспекторов; программа анализируется по списку вопросов для выявления исторически сложившихся общих ошибок программирования.

Изображение слайда
17

Слайд 17: 1. Контроль обращений к данным

17 Все ли переменные инициализированы? Не превышены ли максимальные (или реальные) размеры массивов и строк? Не перепутаны ли строки со столбцами при работе с матрицами? Присутствуют ли переменные со сходными именами? Используются ли файлы? Если да, то при вводе из файла проверяется ли завершение файла? Соответствуют ли типы записываемых и читаемых значений? Использованы ли нетипизированные переменные, открытые массивы, динамическая память? Если да, то соответствуют ли типы переменных при «наложении» формата? Не выходят ли индексы за границы массивов?

Изображение слайда
18

Слайд 18: 2. Контроль вычислений

18 Правильно ли записаны выражения (порядок следования операторов)? Корректно ли выполнены вычисления над неарифметическими переменными? Корректно ли выполнены вычисления с переменными различных типов (в том числе с использованием целочисленной арифметики)? Возможно ли переполнение разрядной сетки или ситуация машинного нуля? Соответствуют ли вычисления заданным требованиям точности? Присутствуют ли сравнения переменных различных типов?

Изображение слайда
19

Слайд 19: 3. Контроль передачи управления

19 Будут ли корректно завершены циклы? Будет ли завершена программа? Существуют ли циклы, которые не будут выполняться из-за нарушения условия входа? Корректно ли продолжатся вычисления? Существуют ли поисковые циклы? Корректно ли отрабатываются ситуации «элемент найден» и «элемент не найден»?

Изображение слайда
20

Слайд 20: 4. Контроль межмодульных интерфейсов

20 Соответствуют ли списки параметров и аргументов по порядку, типу, единицам измерения? Не изменяет ли подпрограмма аргументов, которые не должны изменяться? Не происходит ли нарушения области действия глобальных и локальных переменных с одинаковыми именами?

Изображение слайда
21

Слайд 21: Сквозные просмотры

21 Сквозной просмотр, как и инспекция, представляет собой набор способов обнаружения ошибок, осуществляемых группой лиц, просматривающих текст программы. Такой просмотр имеет много общего с процессом инспектирования, но отличается процедурой и методами обнаружения ошибок. Группа по выполнению сквозного контроля состоит из трех-пяти человек: председатель или координатор, секретарь, специалист по тестированию, программист и независимый эксперт.

Изображение слайда
22

Слайд 22: Сквозные просмотры

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

Изображение слайда
23

Слайд 23: Проверка за столом

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

Изображение слайда
24

Слайд 24: Оценка программ

24 Этот метод непосредственно не связан с тестированием, но его использование также улучшает качество программирования. Его используют для анонимной оценки программы в терминах ее общего качества, простоты эксплуатации и ясности. Цель метода - обеспечить сравнительно объективную оценку и самооценку программистов.

Изображение слайда
25

Слайд 25: Структурное тестирование

25 Структурное тестирование. Тестовые наборы формируют путем анализа маршрутов, предусмотренных алгоритмом. Под маршрутами при этом понимают последовательности операторов программы, которые выполняются при конкретном варианте исходных данных. В основе структурного тестирования лежит концепция максимально полного тестирования всех маршрутов программы.

Изображение слайда
26

Слайд 26: Структурный подход. Недостатки

26 Тестовые наборы, построенные по данной стратегии: не обнаруживают пропущенных маршрутов; не обнаруживают ошибок, зависящих от обрабатываемых данных; не дают гарантии, что программа правильна, например, если вместо сортировки по убыванию реализована сортировка по возрастанию

Изображение слайда
27

Слайд 27: Формирование тестовых наборов

27 Формирование тестовых наборов для тестирования маршрутов может осуществляться по нескольким критериям: покрытие операторов; покрытие решений (переходов); покрытие условий; покрытие решений/условий; комбинаторное покрытие условий.

Изображение слайда
28

Слайд 28: Покрытие операторов

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

Изображение слайда
29

Слайд 29: Покрытие решений (переходов)

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

Изображение слайда
30

Слайд 30: Покрытие условий

30 В этом случае формируют некоторое количество тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении были выполнены, по крайней мере, один раз. Однако, как и в случае покрытия решений, этот критерий не всегда приводит к выполнению каждого оператора, по крайней мере, один раз. К критерию требуется дополнение, заключающееся в том, что каждой точке входа управление должно быть передано, по крайней мере, один раз.

Изображение слайда
31

Слайд 31: Покрытие решений/условий

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

Изображение слайда
32

Слайд 32: Комбинаторное покрытие условий

32 Этот критерий требует создания такого множества тестов, чтобы все возможные комбинации результатов условий в каждом решении и все операторы выполнялись, по крайней мере, один раз.

Изображение слайда
33

Слайд 33: Функциональное тестирование

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

Изображение слайда
34

Слайд 34: Функциональное тестирование

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

Изображение слайда
35

Слайд 35: Функциональное тестирование

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

Изображение слайда
36

Слайд 36: Функциональное тестирование

36 При функциональном тестировании различают следующие методы формирования тестовых наборов: эквивалентное разбиение; анализ граничных значений; анализ причинно-следственных связей; предположение об ошибке.

Изображение слайда
37

Слайд 37: Эквивалентное разбиение

37 Область всех возможных наборов входных данных программы по каждому параметру разбивают на конечное число групп - классов эквивалентности. Наборы данных такого класса объединяют по принципу обнаружения одних и тех же ошибок: если набор какого-либо класса обнаруживает некоторую ошибку, то предполагается, что все другие тесты этого класса эквивалентности тоже обнаружат эту ошибку и наоборот.

Изображение слайда
38

Слайд 38: Анализ граничных значений

38 Граничные значения - это значения на границах классов эквивалентности входных значений или около них. Анализ показывает, что в этих местах резко увеличивается возможность обнаружения ошибок. Например, если в программе анализа вида треугольника было записано А + В ≥ С вместо А + В > С, то задание граничных значений приведет к ошибке: линия будет отнесена к одному из видов треугольника.

Изображение слайда
39

Слайд 39: Анализ причинно-следственных связей

39 Анализ причинно-следственных связей позволяет системно выбирать высоко результативные тесты. Метод использует алгебру логики и оперирует понятиями «причина» и «следствие». Причиной – называют отдельное входное условие или класс эквивалентности. Следствием – выходное условие или преобразование системы. Идея метода заключается в отнесении всех следствий к причинам. Данный метод дает полезный побочный эффект, позволяя обнаруживать неполноту и неоднозначность исходных спецификаций.

Изображение слайда
40

Слайд 40: Предположение об ошибке

40 Часто программист с большим опытом находит ошибки, «не применяя никаких методов». На самом деле он подсознательно использует метод «предположение об ошибке». Процедура метода предположения об ошибке в значительной степени основана на интуиции. Основная его идея заключается в том, чтобы перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка составить тесты. Другими словами, требуется перечислить те особые случаи, которые могут быть не учтены при проектировании.

Изображение слайда
41

Слайд 41: Тестирования модулей и комплексное тестирование

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

Изображение слайда
42

Слайд 42: Восходящее тестирование

42

Изображение слайда
43

Слайд 43: Восходящее тестирование. Достоинства и недостатки

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

Изображение слайда
44

Слайд 44: Нисходящее тестирование

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

Изображение слайда
45

Слайд 45: Нисходящее тестирование

45

Изображение слайда
46

Слайд 46: Нисходящее тестирование. Достоинства и недостатки

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

Изображение слайда
47

Слайд 47: Комбинированный подход

47 применяют следующим образом: Модули верхних уровней тестируют нисходящим способом; Модули нижних уровней - восходящим. Этот способ позволяет : Проводить тестирование интерфейса; Обеспечить качественное автономное тестирование модулей низших уровней.

Изображение слайда
48

Слайд 48: Тестирование программного обеспечения специалистами

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

Изображение слайда
49

Слайд 49: Комплексное тестирование

49 Особенностью комплексного тестирования является то, что структурное тестирование для него практически не применимо. В основном на данной стадии используют тесты, построенные по методам эквивалентных классов, граничных условий и предположении об ошибках.

Изображение слайда
50

Слайд 50: Критерии завершения тестирования и отладки

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

Изображение слайда
51

Слайд 51: Критерии завершения

51 Три группы критериев: основанные на методологиях проектирования тестов – определенное количество тестов перестают выявлять ошибки; основанные на оценке возможного количества ошибок - тестирование завершают при нахождении примерно 93-95% ошибок; основанные на исследовании результатов тестирования - строят график зависимости количества обнаруженных ошибок от времени тестирования.

Изображение слайда
52

Слайд 52: Критерии завершения

52 Часто тестирование завершают потому, что закончилось время. Минимальное тестирование предполагает: тестирование граничных значений; тщательную проверку руководства; тестирование минимальных конфигураций технических средств; тестирование возможности редактирования команд и повторения их в любой последовательности; тестирование устойчивости к ошибкам пользователя.

Изображение слайда
53

Слайд 53: Оценочное тестирование

53

Изображение слайда
54

Слайд 54: Оценочное тестирование

54 Цель оценочного тестирования является тестирование программы на соответствие основным требованиям. Эта стадия тестирования особенно важна для программных продуктов, предназначенных для продажи на рынке.

Изображение слайда
55

Последний слайд презентации: Тестирование программных продуктов. Стуктурное и функциональное тестирование: Оценочное тестирование. Виды тестирования

55 тестирование удобства использования; тестирование на предельных объемах; тестирование на предельных нагрузках; тестирование удобства эксплуатации; тестирование защиты; тестирование производительности; тестирование требований к памяти; тестирование конфигурации оборудования; тестирование совместимости; тестирование удобства установки; тестирование надежности; тестирование восстановления; тестирование удобства обслуживания; тестирование документации; тестирование процедуры.

Изображение слайда