OOAD - Тестирование и обеспечение качества

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

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

Тестирование объектно-ориентированных систем

Тестирование - это непрерывная деятельность во время разработки программного обеспечения. В объектно-ориентированных системах тестирование включает три уровня: модульное тестирование, тестирование подсистем и тестирование системы.

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

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

Подсистема тестирования

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

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

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

Объектно-ориентированные методы тестирования

Тестирование серого ящика

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

State model based testing - Сюда входят покрытие состояния, покрытие перехода состояния и покрытие пути перехода состояния.
Use case based testing - Каждый сценарий в каждом варианте использования тестируется.
Class diagram based testing - Каждый класс, производный класс, ассоциации и агрегаты тестируются.
Sequence diagram based testing - Методы в сообщениях на диаграммах последовательности проверены.

Методы тестирования подсистем

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

Thread based testing - Все классы, необходимые для реализации одного варианта использования в подсистеме, интегрированы и протестированы.
Use based testing- Тестируются интерфейсы и сервисы модулей на каждом уровне иерархии. Тестирование начинается с отдельных классов к небольшим модулям, состоящим из классов, постепенно к более крупным модулям и, наконец, ко всем основным подсистемам.

Категории системного тестирования

Alpha testing - Это выполняется группой тестирования в организации, которая разрабатывает программное обеспечение.
Beta testing - Это осуществляется избранной группой сотрудничающих клиентов.
Acceptance testing - Это выполняется заказчиком перед принятием результатов.

Гарантия качества программного обеспечения

Качество программного обеспечения

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

Гарантия качества

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

Auditing
Разработка стандартов и руководств
Составление отчетов
Обзор системы качества

Факторы качества

Correctness - Правильность определяет соответствие требованиям к программному обеспечению.
Usability - Удобство использования определяет, может ли программное обеспечение использоваться разными категориями пользователей (новичками, нетехническими и экспертами).
Portability - Переносимость определяет, может ли программное обеспечение работать на разных платформах с разными аппаратными устройствами.
Maintainability - Ремонтопригодность определяет легкость исправления ошибок и обновления модулей.
Reusability - Возможность повторного использования определяет, можно ли повторно использовать модули и классы для разработки других программных продуктов.

Объектно-ориентированные показатели

Метрики можно условно разделить на три категории: метрики проекта, метрики продукта и метрики процесса.

Показатели проекта

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

Количество сценариев сценария
Количество ключевых классов
Количество классов поддержки
Количество подсистем

Показатели продукта

Метрики продукта измеряют характеристики разработанного программного продукта. Метрики продукта, подходящие для объектно-ориентированных систем:

Methods per Class- Это определяет сложность класса. Если предполагается, что все методы класса одинаково сложны, то класс с большим количеством методов будет более сложным и, следовательно, более подверженным ошибкам.
Inheritance Structure- Системы с несколькими маленькими решетками наследования более хорошо структурированы, чем системы с одной большой решеткой наследования. Как правило, дерево наследования не должно иметь более 7 (± 2) уровней, и дерево должно быть сбалансированным.
Coupling and Cohesion - Модули, имеющие низкое сцепление и высокую когезию, считаются более сконструированными, поскольку они обеспечивают большую возможность повторного использования и ремонтопригодность.
Response for a Class - Он измеряет эффективность методов, вызываемых экземплярами класса.

Метрики процесса

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

Количество KLOC (килограмм строк кода)
Эффективность устранения дефектов
Среднее количество сбоев, обнаруженных во время тестирования
Количество скрытых дефектов на один KLOC