Недостаки UML

При полном использовании UML цена проекта возрастает в несколько раз. Ни один заказчик на это не идет.

Поэтому часто используется только Class , Use Cases.

Модульное тестирование

Объектом модульного тестирования может быть как отдельный класс , метод , функция и т.п.

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

Модульное тестирование

Unit тестирование используется для проверки маленького фрагмента программы.

(как правило проверка кода на функциональность). Введем некоторые термины

Рефакторинг кода – т.е. перепрограммирование с целью сделать код более легким для чтения.

Реинжиниринг - создание новой функциональности кода.

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

.Выводы

.Выводы

Модульное тестирование

Модульное тестирование используется на этапе кодирования (или после этапа кодирования)

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

Различают : 1 вариант.

Ручное тестирование - проводиться максимально просто по заранее составленному документу (плану тестирования) с пошаговыми инструкциями.

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

Кроме того: ручное тестирование требует много времени.

Модульное тестирование

2 вариант.

Автоматизированное тестирование. (Unit -тестирование)

Автоматизированное тестирование заключается в использовании специально разработанных тестовых сред, которые проверяют работу модуля и выявляют ошибки в данном модуле.

Особенности автоматизированного модульного тестирования.

1. Для каждой функциональной части составляется отдельный модульный тест.

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

(т.е. тесты не должны дублироваться и т.о. каждый тест проверяет только одно поведение функционала или один кейс).

Модульное тестирование

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

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

4.Тесты должны проверять как позитивные , так и негативные сценарии.

5.Соблюдение граничных условий.

Методы.

Часто используется метод «белого ящика».

Модульное тестирование

Рассмотрим метод «белого» ящика 1 этап модульного тестирования.

Разработчик-тестировщик изучает внутреннюю структуру кода ,

функционал и поведение исследуемого компонента(если разработчик-тестировщик не участвовал в создании данного кода).

2 этап.

Создание тест-кейса. (тест-кейс представляет собой модель и сценарий поведения проверяемого модуля на практике.

Т.е. кейс-тесты создают исскуственную среду, максимально близкую к реальной обстановке , но без привлечения внешних ресурсов (напр. веб-серверов , баз данных и т.д.)

3 этап. Тестирование модуля

Модульное тестирование

3 этап Тестирование модуля

Проверяемый компонент (модуль) , предварительно изолированный от ядра данного приложения и других компонентов , запускается в тест-кейсе.

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