Преимущества модульного тестирования

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

- Тесты позволяют рефакторить код без риска его сломать.

- Тесты могут использоваться в качестве документации.

- Тесты улучшают дизайн кода.

- Тесты способствуют повышению квалификации разработчиков.

- Тесты ускоряют процесс разработки.

5. Дефект. Виды дефектов. ЖЦ дефекта. [вверх]

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

1. Критичные (Critical)

2. Важные (Major)

3. Средние (Average)

4. Маловажные (Minor)

5. Незначительные (Exception)

Представленный на рисунке жизненный цикл включает в себя следующие состояния дефекта:

- Submitted – Заведен.

- Assigned – Назначен

- Resolved – Исправлен

- Rejected – Отклонен

- Re-Opened – Переоткрыт

- Closed – Закрыт

На практике это выглядит следующим образом. Тестировщик обнаруживает дефект и заводит его в системе учета дефектов. В этот момент дефект находится в состоянии Submitted. После этого назначается человек, ответственный за исправление этого дефекта, и дефект переводится в состояние Assigned. Ответственный человек либо исправляет дефект и переводит его в состояние Resolved, либо отклоняет дефект (признает данную ситуацию нормальной или уже исправленной) и переводит дефект в состояние Rejected. Далее человек, который завел дефект проверяет правильность исправления и либо закрывает дефект (состояние Closed), либо переоткрывает его (состояние Re-Opened).

6. Баг-трекинг системы. [вверх]

Система отслеживания ошибок (bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения учитывать и контролировать ошибки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.

Свободно распространяемые:

– Redmine

– BUGS - the Bug Genie

– Bugzilla

– GNATS

– Mantis

– Flyspray

Проприетарные:

– Atlassian JIRA

– Bontq

– PVCS Tracker

– Project Kaiser

– TrackStudio Enterprise

7. Требования к программному обеспечению. Виды. Методы выявлений. [вверх]

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

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

- Customer Requirements – набор требований, предпочтений и ограничений со стороны заказчика.

- Product Requirements – структурированный набор функциональных и нефункциональных требований к системе. Должны быть полными, непротиворечивым и проверяемыми.

- Component Requirements – требования к логической и физической структуре системы, ее отдельным компонентам.

Методы выявления требований:

- Интервью, опросы, анкетирование

- Мозговой штурм, семинар

- Наблюдение за производственной деятельностью, рабочего дня

- Анализ нормативной документации

- Анализ моделей деятельности

- Анализ конкурентных продуктов

- Анализ статистики использования предыдущих версий системы

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

Существуют следующие проблемы требований:

- Двусмысленность

- Неполнота

- Несогласованность

8. Управление требованиями. [вверх]

Управление требованиями (requirements management) – процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоритезацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц.

Управление требованиями – непрерывный процесс на протяжении всего проекта.

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

Управление требованиями включает:

- выявления и анализа целей и ограничений заказчика

- поддержку требований

- интеграцию требований

- организацию работы с требованиями

Управление требованиями включает общение между проектной командой и заинтересованными лицами с целью корректировки требований на протяжении всего проекта. Требования не являются чем-то постоянным. В процессе жизненного цикла ПО требования могут меняться. Изменения в требованиях должны отслеживаться.

Технические средства управления требованиями:

- IBM Rational RequisitePro

- Borland CaliberRM

- Sybase PowerDesigner

9. RUP: Основные принципы. [вверх]

Дата добавления: 2015-04-24