Как только программный код написан, он должен быть протестирован, чтобы обнаружить и впоследствии обработать все ошибки в нем. Ряд схем используется для целей тестирования.
Другим важным аспектом является соответствие цели программы, которая определяет, служит ли программа цели, для которой она предназначена. Пригодность определяет качество программного обеспечения.
Тестирование объектно-ориентированных систем
Тестирование — это постоянная деятельность при разработке программного обеспечения. В объектно-ориентированных системах тестирование включает три уровня: модульное тестирование, подсистемное тестирование и тестирование системы.
Модульное тестирование
В модульном тестировании тестируются отдельные классы. Видно, реализованы ли атрибуты класса в соответствии с проектом, и являются ли методы и интерфейсы безошибочными. Модульное тестирование является обязанностью прикладного инженера, который реализует структуру.
Подсистема тестирования
Это включает в себя тестирование конкретного модуля или подсистемы и является обязанностью руководителя подсистемы. Он включает в себя тестирование связей внутри подсистемы, а также взаимодействие подсистемы с внешним миром. Тесты подсистемы могут использоваться в качестве регрессионных тестов для каждой недавно выпущенной версии подсистемы.
Тестирование системы
Системное тестирование включает в себя тестирование системы в целом и является обязанностью группы обеспечения качества. Команда часто использует системные тесты в качестве регрессионных тестов при сборке новых версий.
Объектно-ориентированные методы тестирования
Тестирование серой коробки
Различные типы тестовых случаев, которые могут быть разработаны для тестирования объектно-ориентированных программ, называются тестами с серым ящиком. Некоторые из важных типов тестирования серого ящика —
-
Тестирование на основе модели состояния — это охватывает покрытие состояния, покрытие перехода состояния и покрытие пути перехода состояния.
-
Тестирование на основе варианта использования — каждый сценарий в каждом сценарии использования тестируется.
-
Тестирование на основе диаграмм классов. Проверяется каждый класс, производный класс, ассоциации и агрегаты.
-
Тестирование на основе диаграмм последовательности — проверяются методы в сообщениях на диаграммах последовательности.
Тестирование на основе модели состояния — это охватывает покрытие состояния, покрытие перехода состояния и покрытие пути перехода состояния.
Тестирование на основе варианта использования — каждый сценарий в каждом сценарии использования тестируется.
Тестирование на основе диаграмм классов. Проверяется каждый класс, производный класс, ассоциации и агрегаты.
Тестирование на основе диаграмм последовательности — проверяются методы в сообщениях на диаграммах последовательности.
Методы тестирования подсистем
Два основных подхода к тестированию подсистемы:
-
Тестирование на основе потоков — все классы, необходимые для реализации одного варианта использования в подсистеме, интегрированы и протестированы.
-
Тестирование на основе использования — тестируются интерфейсы и сервисы модулей на каждом уровне иерархии. Тестирование начинается с отдельных классов до небольших модулей, состоящих из классов, постепенно, до более крупных модулей и, наконец, всех основных подсистем.
Тестирование на основе потоков — все классы, необходимые для реализации одного варианта использования в подсистеме, интегрированы и протестированы.
Тестирование на основе использования — тестируются интерфейсы и сервисы модулей на каждом уровне иерархии. Тестирование начинается с отдельных классов до небольших модулей, состоящих из классов, постепенно, до более крупных модулей и, наконец, всех основных подсистем.
Категории системного тестирования
-
Альфа-тестирование — это выполняется группой тестирования в организации, которая разрабатывает программное обеспечение.
-
Бета-тестирование — это проводится выбранной группой сотрудничающих клиентов.
-
Приемочное тестирование — это выполняется заказчиком до принятия результатов.
Альфа-тестирование — это выполняется группой тестирования в организации, которая разрабатывает программное обеспечение.
Бета-тестирование — это проводится выбранной группой сотрудничающих клиентов.
Приемочное тестирование — это выполняется заказчиком до принятия результатов.
Гарантия качества программного обеспечения
Качество программного обеспечения
Schulmeyer и McManus определили качество программного обеспечения как «пригодность для использования всего программного продукта». Качественное программное обеспечение делает именно то, для чего оно предназначено, и интерпретируется с точки зрения удовлетворения спецификации требований, установленных пользователем.
Гарантия качества
Обеспечение качества программного обеспечения — это методология, которая определяет степень пригодности программного продукта для использования. Действия, которые включены для определения качества программного обеспечения:
- Аудиторская проверка
- Разработка стандартов и руководств
- Изготовление отчетов
- Обзор системы качества
Факторы качества
-
Правильность. Правильность определяет, правильно ли выполнены требования к программному обеспечению.
-
Юзабилити — юзабилити определяет, может ли программное обеспечение использоваться различными категориями пользователей (начинающих, нетехнических и экспертов).
-
Переносимость — Переносимость определяет, может ли программное обеспечение работать на разных платформах с разными аппаратными устройствами.
-
Ремонтопригодность — ремонтопригодность определяет легкость исправления ошибок и обновления модулей.
-
Возможность повторного использования — возможность повторного использования определяет, можно ли повторно использовать модули и классы для разработки других программных продуктов.
Правильность. Правильность определяет, правильно ли выполнены требования к программному обеспечению.
Юзабилити — юзабилити определяет, может ли программное обеспечение использоваться различными категориями пользователей (начинающих, нетехнических и экспертов).
Переносимость — Переносимость определяет, может ли программное обеспечение работать на разных платформах с разными аппаратными устройствами.
Ремонтопригодность — ремонтопригодность определяет легкость исправления ошибок и обновления модулей.
Возможность повторного использования — возможность повторного использования определяет, можно ли повторно использовать модули и классы для разработки других программных продуктов.
Объектно-ориентированные метрики
Метрики можно в целом разделить на три категории: метрики проектов, метрики продуктов и метрики процессов.
Метрики проекта
Метрики проекта позволяют руководителю проекта программного обеспечения оценить состояние и производительность текущего проекта. Следующие метрики подходят для объектно-ориентированных программных проектов —
- Количество сценариев сценария
- Количество ключевых классов
- Количество классов поддержки
- Количество подсистем
Метрики продукта
Метрики продукта измеряют характеристики программного продукта, который был разработан. Метрики продукта, подходящие для объектно-ориентированных систем:
-
Методы на класс — это определяет сложность класса. Если предполагается, что все методы класса одинаково сложны, то класс с большим количеством методов более сложен и, следовательно, более подвержен ошибкам.
-
Структура наследования. Системы с несколькими небольшими решетками наследования имеют более хорошую структуру, чем системы с одной большой решеткой наследования. Как правило, у дерева наследования не должно быть более 7 (± 2) уровней, и дерево должно быть сбалансировано.
-
Сцепление и когезия — Модули, имеющие низкую связь и высокую когезию, считаются лучше спроектированными, так как они обеспечивают большую возможность повторного использования и ремонтопригодности.
-
Ответ для класса — Он измеряет эффективность методов, которые вызываются экземплярами класса.
Методы на класс — это определяет сложность класса. Если предполагается, что все методы класса одинаково сложны, то класс с большим количеством методов более сложен и, следовательно, более подвержен ошибкам.
Структура наследования. Системы с несколькими небольшими решетками наследования имеют более хорошую структуру, чем системы с одной большой решеткой наследования. Как правило, у дерева наследования не должно быть более 7 (± 2) уровней, и дерево должно быть сбалансировано.
Сцепление и когезия — Модули, имеющие низкую связь и высокую когезию, считаются лучше спроектированными, так как они обеспечивают большую возможность повторного использования и ремонтопригодности.
Ответ для класса — Он измеряет эффективность методов, которые вызываются экземплярами класса.
Метрики процесса
Показатели процесса помогают измерить, как выполняется процесс. Они собраны по всем проектам за длительные периоды времени. Они используются в качестве индикаторов для долгосрочных улучшений программного обеспечения. Некоторые показатели процесса —