КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Преимущества модульного тестирования
- Искать ошибки в меняющемся исходном коде лучше с помощью ранее созданных модульных тестов. - Тесты позволяют рефакторить код без риска его сломать. - Тесты могут использоваться в качестве документации. - Тесты улучшают дизайн кода. - Тесты способствуют повышению квалификации разработчиков. - Тесты ускоряют процесс разработки. 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; Просмотров: 1054; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |