2. Ролі в процесі веріфікації програмного забезпечення.

1) заказчик – имеет право изменять требования продукта, читать проектную документацию, работать только с менеджером проекта.

2) менеджер проекта – отвечает за коммуникацию между заказчиком и проектной группой. Его осн. задача определить и обеспечить выполнение требований заказчика. Может изменять требования к продукту и финальную документацию.

3) менеджер программы – координатор внутри проектной команды. Разрабатывает ф-ные спецификации, ведет график проекта, отчитывается о его состоянии, может изменять ход реализации проекта и распределять ресурсы по задачам.

4) Разработчик – создает продукт

5) специалист по тестированию – определяет стратегию по тестированию, тестовые требования, тестовый план для каждой фазы проекта

6) специалист по контролю качества – контролирует сам процесс разработки и его соответствие стандартам.

7) специалист по сертификации – обеспечивает взаимодействие между проектной командой и сертификационными органом.

8) специалист по внедрению и сопровождению – устанавливает и настраивает ПО на площадке пользователя/заказчика

9) специалист по безопасности

10) инструктор – обучает работе с программой

11) технический писатель – пишет руководство пользователя

2. Кількісні характеристики програмного забезпечення та його надійності.

Количественные характеристики ПО:

1. Объем программы.

2. Количество условий.

3. Количество точек входа-выхода.

4. Количество процедур.

5. Количество комментариев.

2. Функціональні критерії вибору тестів.

Функциональный критерий – обеспечивает контроль степени выполнения требований заказчика в программном продукте.

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

Используется модель "черного ящика".

Основная проблема – трудоемкость.

Базовые типы функциональных критериев:

1. Тестирование пунктов спецификации - набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.

2. Тестирование входных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза.

3. Тестирование правил. В качестве правила понимается соответствие между входом и выходом. Поэтому необходимо осуществить проверку кода не менее 1 раза.

4. Тестирование классов выходных данных - обеспечить проверку представителя не менее 1 раза.

5. Тестирование функций - обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза.

6. Комбинированные критерии для программ и спецификаций - в совокупности используются рассмотренные выше критерии.

2. Класифікація програмних помилок.

ОПР: Расхождение между программой и ее спецификацией является ошибкой только тогда, когда спецификация существует и она правильная.

Помимо этого определения существует еще 2 (Майерс и Бейзер)

1. Если программа не делает того, чего пользователь от нее вполне обосновано ожидает, значит на лицо программная ошибка

2. Не существует ни абсолютного определения ошибок, ни точного критерия наличия их в программе. Можно лишь сказать на сколько программа не справляется со своей задачей (это исключительно субъективная характеристика).

Рассмотренные 3 определения задают понятия программной ошибки с точки зрения конечного пользователя.

Категории программных ошибок (с точки зрения пользователя):

1. Ошибки пользовательского интерфейса

- функциональность

- взаимодействие программы с пользователем

- организация программы

- пропущенные команды

- производительность

- производительность

- выходные данные

- обработка ошибок

- ошибки, связанные с обработкой граничных условий

- ошибки вычислений

- начальное и последовательное состояние (бывает, что при выполнении какой-то программы, бывает ошибка только при первом обращении к этой функции)

2. Ошибки управления потоком (когда ошибка в вызове методов класса, модулей интерфейса и т.д.)

3. Ошибки передачи и интерпретации данных ( неверная передача д. от одной компоненты к другой)

4. Ситуация гонок (предположим в программе ожидается 2 события а и б, б – завершение программы. Программист при написании кода считает, что всегда вначале активируется событие а и не ожидает что произойдет б, которое закрывает программу)

5. Перегрузки (объемы данных, с которыми она не справляется)

6. Аппаратное обеспечение

7. Контроль версий

8. Документация

9. Ошибки тестирования