Учебно-методическое пособие "Управление качеством разработки программного обеспечения"



страница8/18
Дата18.10.2016
Размер1.92 Mb.
ТипУчебно-методическое пособие
1   ...   4   5   6   7   8   9   10   11   ...   18

Виды требований по уровням


  • Бизнес-требования — определяют назначение программного обеспечения

  • Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)

  • Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе

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

Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).

К системным ограничениям относятся ограничения на программные интерфейсы, требования к атрибутам качества, требования к применяемому оборудованию и программному обеспечению.


Виды требований по характеру


  • Функциональные требования — требования к поведению системы («ЧТО» она делает)

  • Нефункциональные требования — требования к характеру поведения системы («КАК» она это делает)

Типы документов требований


В зарубежной и российской практике встречаются следующие типы документов требований:

  • Концепция программы

  • Требования к программному обеспечению

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

За создание требований к программному обеспечению чаще всего в российской практике отвечает Системный аналитик, иногда — Бизнес-аналитик.

Для графических моделей требований исторически использовались диаграммы: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD)

5. Тестирование программного обеспечения.

5.1. Цели и задачи. Основные определения.


«Тестирование – процесс выполнения программы с намерением найти ошибки.» (Майерс)

«Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.» (Дейкстра, 1970 г)

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

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

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

Конечной целью любого процесса тестирования является обеспечение такого ёмкого (совокупного) понятия как Качество, с учётом всех или наиболее критичных для данного конкретного случая составляющих.

Тестирование программного обеспечения — попытка определить, выполняет ли программа то, что от неё ожидают. Как правило, никакое тестирование не может дать абсолютной гарантии работоспособности программы в будущем.

Задачи тестирования программного обеспечения – снизить стоимость разработки путем раннего обнаружения дефектов.

5.1.1 Методологии тестирования


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

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

Рис. 11. Метод белого ящика

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

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

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

Помимо методов тестирования «белый ящик» и «черный ящик» различают тестирование методом «серого ящика».

Рис. 13. Метод серого ящика



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



Каталог: shared -> files -> 201211
201211 -> 1. 1 Предмет и содержание курса 2 Вопросы стандартизации систем
201211 -> Учебное пособие 10 часть Основы общей теории управления. Функциональный и процессный подходы к управлению организацией 15
201211 -> Учебное пособие Санкт-Петербург 2012
files -> Технологические подходы к разработке по [Алексеев П. С.]
files -> Статья 48. Архитектурно-строительное проектирование
files -> Программа дисциплины вычислительная геометрия Цели изучения дисциплины
files -> Методы расчета расходов на it совокупная стоимость владения


Поделитесь с Вашими друзьями:
1   ...   4   5   6   7   8   9   10   11   ...   18


База данных защищена авторским правом ©grazit.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал