 Популярные статьи | |
| Сейчас на сайте |  Гостей: 3
На сайте нет зарегистрированных пользователей
Пользователей: 9,955
новичок: Logyattella
|
|
| 9.5. Инженерия разработки программного продукта |
4. Каждый программный модуль, прежде чем будет считаться готовым, проходит экспертную оценку и модульное тестирование.
См. группу ключевых процессов «Экспертные оценки».
5. Программный код помещается в систему управления конфигурацией.
См. группу ключевых процессов «Управление конфигурацией ПО».
6. При любом изменении требований к ПО или архитектуры ПО соответствующие изменения вносятся и в программный код.
Операция 5 Тестирование ПО выполняется в соответствии с производственным процессом проекта.
1. Разработка критериев тестирования и их проверка происходит с участием заказчика и, при необходимости, конечных пользователей.
2. Тестирование ПО осуществляется с помощью эффективных методов.
3. Адекватность тестирования определяется следующими факторами:
уровень выполняемого тестирования,
Примеры уровней тестирования:
модульное тестирование,
интеграционное тестирование,
системное тестирование,
приемочное тестирование.
выбранная стратегия тестирования,
Примеры стратегий тестирования:
функциональная («черный ящик»),
структурная («прозрачный ящик»),
статистическая.
достигаемое тестовое покрытие,
Примеры тестового покрытия:
покрытие операторов,
покрытие путей,
покрытие ветвей,
профиль использования.
4. Для каждого уровня тестирования ПО устанавливаются и используются критерии готовности к тестированию.
Примеры критериев, определяющих готовность к тестированию:
до проведения интеграционного тестирования программные модули должны успешно пройти экспертную оценку и модульное тестирование,
для системного тестирования ПО должно прежде успешно пройти интеграционное тестирование, перед приемочным тестированием проводится проверка тестовой готовности.
5. При необходимости на каждом уровне выполняется регрессионное тестирование, если происходят изменения в самой программе или в ее операционной среде.
6. Планы, процедуры и сценарии тестирования, прежде чем будут считаться готовыми, подвергаются экспертной оценке.
См. группу ключевых процессов «Экспертные оценки».
7. Документы планов, процедур и сценариев тестирования должны быть управляемыми и контролируемыми.
«Управляемый и контролируемый» означает, что в любой момент времени (прошлый или настоящий) известна версия используемого промежуточного продукта, а внесение изменений происходит управляемым образом. Если желательно реализовать еще большую степень формальности, промежуточный продукт может быть помещен в условия полномасштабного управления конфигурацией, как это описано в группе ключевых процессов «Управление конфигурацией ПО».
8. При любых изменениях установленных требований, требований к ПО, архитектуры ПО или тестируемого кода соответствующие изменения должны вноситься в планы, процедуры и сценарии тестирования.
Операция 6 Планирование и выполнение интеграционного тестирования ПО проводится в соответствии с производственным процессом проекта.
1. Составляются и документируются планы интеграционного тестирования, основанные на плане разработки ПО.
2. Интеграционные сценарии и процедуры тестирования рассматриваются сотрудниками, ответственными за требования к ПО, архитектуру ПО, системное и приемочное тестирование.
3. Интеграционное тестирование ПО выполняется в соответствии с определенной версией документа требований к ПО и документа архитектуры ПО.
Операция 7 Планирование и выполнение системного и приемочного тестирования ПО в целях демонстрации его соответствия требованиям.
Системное тестирование позволяет убедиться в том, что созданный продукт удовлетворяет требованиям к ПО.
Приемочное тестирование проводится в целях демонстрации заказчику и конечным пользователям того, что ПО удовлетворяет установленным требованиям.
1. Ресурсы для тестирования ПО должны выделяться заранее, чтобы обеспечить соответствующую подготовку тестов.
Примеры работ по подготовке тестирования:
подготовка тестовой документации,
резервирование ресурсов для проведения тестирования,
разработка тестовых драйверов,
разработка симуляторов.
2. Системное и приемочное тестирование документируются в плане тестирования, который рассматривается и утверждается заказчиком и, при необходимости, конечными пользователями.
План тестирования раскрывает следующие вопросы:
общий подход к тестированию и проверке;
сферы ответственности разрабатывающей организации, субподрядчиков, заказчика и, при необходимости, конечных пользователей;
требования к испытательному оборудованию, оснащению и поддержке процесса тестирования;
критерии приемки.
3. Тестовые сценарии и процедуры планируются и готовятся группой тестирования, которая независима от разработчиков ПО.
4. Тестовые сценарии документируются, после чего рассматриваются и утверждаются заказчиком и, при необходимости, конечными пользователями до начала тестирования.
5. Тестирование выполняется для программной системы, находящейся в базовой линии, и на основе также находящихся в базовой линии установленных требований и требований к ПО.
6. Проблемы, выявленные при тестировании, документируются и отслеживаются до устранения.
Основные практики, связанные с документированием и отслеживанием проблем, содержатся в описании Операции №9 группы ключевых процессов «Отслеживание хода проекта и контроль над ним» и Операции №5 группы ключевых процессов «Управление конфигурацией».
7. Результаты тестов документируются и используются для определения, насколько ПО соответствует выдвинутым к нему требованиям. 8. Документы результатов тестирования должны быть управляемыми и контролируемыми.
Операция 8 Документация, используемая при эксплуатации и поддержке ПО, разрабатывается и ведется в соответствии с производственным процессом проекта.
1. Для разработки документации используются соответствующие методы и инструменты.
Примеры методов и инструментов:
использование текстовых процессоров,
изучение сценариев,
повторное использование документации.
2. Специалисты по созданию документации принимают активное участие в планировании, разработке и ведении документации.
3. Предварительные версии документации разрабатываются на ранних стадиях жизненного цикла ПО и передаются на рассмотрение заказчику, конечным пользователям и, при необходимости, специалистам по поддержке ПО в целях получения отзывов.
Примеры документации: документация по обучению работе с системой, интерактивная документация, руководство пользователя, руководство оператора, руководство по сопровождению.
4. Окончательные версии документации сверяются с базовыми линиями ПО для приемочного тестирования.
5. Документация подвергается экспертной оценке. См. группу ключевых процессов «Экспертные оценки».
6. Документация должна быть управляемой и контролируемой.
7. Окончательная документация рассматривается и утверждается заказчиком, конечными пользователями, и при необходимости, специалистами по поддержке ПО.
Операция 9 Сбор и анализ данных по дефектам, выявленным при экспертной оценке и тестировании, выполняются в соответствии с производственным процессом проекта.
Примеры собираемых и анализируемых данных:
описание дефекта,
категория дефекта,
серьезность дефекта,
модули, содержащие дефект,
модули, подверженные влиянию дефекта,
операция, в которой проявился дефект,
экспертная оценка или тестовые сценарии, выявившие дефект,
описание сценария, при выполнении которого был выявлен дефект,
ожидаемые и фактические результаты, выявляющие дефект.
Операция 10 Поддержка согласованности всех промежуточных программных продуктов, включая планы разработки ПО, описания процессов, установленные требования, требования к ПО, архитектуру ПО, планы и процедуры тестирования.
1. Промежуточные программные продукты документируются, а к созданной документации имеется постоянный доступ.
2. Требования к ПО, архитектура ПО, программный код и тестовые сценарии отслеживаются от источника их происхождения до продуктов последующих операций разработки ПО.
3. Документация, отслеживающая установленные требования до требований к ПО, архитектуры, кода и тестовых сценариев, должна быть управляемой и контролируемой.
4. По мере роста понимания разрабатываемого продукта предлагаются, анализируются и внедряются изменения промежуточных программных продуктов, планов, описания процессов и операций.
Влияние изменений на ход проекта определяется до того, как эти изменения будут реализованы.
При необходимости изменения установленных требований, эти изменения утверждаются и реализуются до начала изменения каких-либо связанных с этим промежуточных программных продуктов. |
|
| Страница 3 из 4 |
< |
1 |
2 |
3 |
4 |
> |
| Комментарии |
| Добавить комментарий |
|
Пожалуйста залогиньтесь для добавления комментария.
|
| Рейтинги |
|
Рейтинг доступен только для пользователей.
Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.
Нет данных для оценки.
|
|
| Гость |
Вы не зарегистрированны? Нажмите здесь для регистрации.
Забыли пароль? Запросите новый здесь.
|
| Мини-чат | Вам необходимо залогиниться.
Нет присланных сообщений.
|
|
