В ходе работы над проектом по созданию любой сложной программной системы создается большое количество проектной документации. Основное ее назначение: координация совместных действий большого количества разработчиков в течение более или менее длительных промежутков времени - в процессе первоначальной разработки системы, в процессе выполнения работ по ее модификации, в процессе сопровождения. Структурный состав проектной документации в большинстве проектов практически одинаков - это требования к системе различного уровня (системные, функциональные и структурные), описание ее архитектуры, программный код, тесты и документы, сопровождающие процесс внедрения (руководства по установке, настройке, пользовательские руководства).
Поскольку верификация программной системы (в оптимальном случае) выполняется в течение всего жизненного цикла разработки достаточно большим коллективом разработчиков, при тестировании создается тестовая документация. Основное ее назначение, помимо синхронизации действий тестировщиков различных уровней, - обеспечение гарантий того, что тестирование выполняется в соответствии с выбранными критериями оценки качества, а также того, что все аспекты поведения системы протестированы. Также тестовая документация используется при внесении изменений в систему для проверки того, что как старая, так и новая функциональность работает корректно (Рис 10.1).
Перед началом верификации менеджером тестирования (
В данном документе также определяются требования собственно к тестовой документации - тест-требованиям, тест-планам, отчетам о выполнении тестирования.
Согласно этим требованиям по системным и функциональным требованиям разработчиками тестов (
(рис 10.1) Документация, сопровождающая процесс верификацииНа основании тест-требований разработчиками тестов (test developers) создаются тест-планы - документы, которые содержат подробное пошаговое описание того, как должны быть протестированы тест-требования.
На основании тест-требований и проектной документации разработчиков также создается тестовое окружение, необходимое для корректного выполнения тестов на тестовых стендах - драйверы, заглушки, настроечные файлы и т.п.
По результатам выполнения тестов тестировщиками (testers) создаются отчеты о выполнении тестирования (они могут создаваться либо автоматически, либо вручную), которые содержат информацию о том, какие несоответствия требованиям были выявлены в результате тестирования, а также отчеты о покрытии, содержащие информацию о том, какая доля программного кода системы была задействована в результате выполнения тестирования.
По несоответствиям создаются отчеты о проблемах - документы, которые направляются на анализ в группу разработчиков с целью определения причины возникновения несоответствия.
Изменения в систему вносятся только после всестороннего изучения этих отчетов и локализации проблем, вызвавших несоответствие требованиям. Для того, чтобы процесс изменений не вышел из под контроля и любое изменение протоколировалось (и связывалось с тестами, обнаружившими проблему), создается запрос на изменение системы. После завершения всех работ по запросу на изменение процесс тестирования повторяется до тех пор, пока не будет достигнут приемлемый уровень качества программной системы.
Форматы различных тестовых документов описаны в стандартах IEEE 1012 [14] и IEEE 829 [15], при дальнейшем изложении мы будем придерживаться духа этих стандартов.
Следует особо отметить, что все документы должны иметь уникальные идентификаторы и храниться в единой базе документов проекта. Это позволит сохранить управляемость процессом тестирования и поддерживать необходимое качество разрабатываемой системы. Нет ничего хуже ситуации, когда найденная проблема не была исправлена из-за того, что отчет о ней был утерян и не попал к разработчику.
Первый документ, входящий в состав технологической документации процесса верификации - стратегия тестирования. Стратегия верификации определяет общие подходы и методики верификации, необходимые уровни верификации проектной документации и программного кода, технологии и инструментальные средства.
Другой, не менее важный документ, создаваемый перед началом процесса верификации - план верификации. Этот план содержит последовательное описание всех этапов верификации, процедур на каждом этапе и связей с этапами разработки.
Для каждого этапа определяется:
Иногда план верификации разделяется на отдельные документы, описывающие более подробно каждый из этапов, например:
Согласно разделу 4 стандарта IEEE 829 [15] основная задача плана тестирования как документа - определение границ тестирования, подхода к тестированию, требуемых для тестирования ресурсов, плана-графика тестирования. План тестирования определяет тестируемые элементы и функции системы, задачи, решаемые в ходе тестирования, сотрудников, ответственных за тестирование, и риски, связанные с этим планом. Такая форма плана тестирования является достаточно полной и включает в себя не только технические аспекты, связанные собственно с описанием тестовых примеров, но и организационные, связанные с общим управлением процессом тестирования. На практике объемы технических и организационных разделов планов тестирования могут достаточно сильно варьироваться. Однако, минимально необходимые элементы, которые рекомендуется включать в каждый план тестирования - это:
Стратегия и планы тестирования несколько отличаются от другой документации, относящейся к процессу тестирования: в этих документах достаточно много внимания уделяется тому, как должен быть организован процесс тестирования, а не тому, как тестировать саму систему.
Тест-требования - основной документ для тестировщика, который определяет функциональность системы с точки зрения того, что должно быть проверено, чтобы удостовериться в ее корректном функционировании, а также - на основании какого
Существует два подхода к написанию тест-требований - функциональный и структурный. Тест-требования, написанные в рамках функционального подхода, основываются на системных требованиях и требованиях к программному обеспечению системы.
(рис 10.2) Место тест-требований среди проектной документацииТест-требования, написанные в рамках структурного подхода, пишутся на основании описания архитектуры системы и принимают в расчет строение исходных текстов системы. Из-за такого различия функциональный и структурный подходы часто называют подходами черного и белого ящиков. Структурные тест-требования важны в том случае, когда к надежности системы предъявляются повышенные требования, т.е. когда важно проверить не только, насколько корректно система в целом отрабатывает сценарии своей работы (корректные и некорректные с точки зрения пользователя), но и как в различных нестандартных ситуациях будут вести себя отдельные ее компоненты.
На практике почти всегда применяются оба подхода к разработке тест-требований. В результате в состав документации проекта включаются тест-требования верхнего уровня и тест-требования нижнего уровня, по которым составляются тест-планы (Рис 10.2).
Как уже говорилось выше, тест-требования содержат описание требованиий по проверке всех основных функций системы. Тест-требования должны быть достаточными для построения тест-плана проверки реализации задачи без знакомства с ее программными текстами, т.е. тест-требования должны обладать свойством изоляции от внутренней структуры системы.
Как правило, структура тест-требований следует структуре раздела функциональных требований на систему. Задача каждого требования - определение того, что надо проверить. Техника исполнения каждой такой проверки - задача тест-плана. Обычный формат описания отдельного требования следующий:
Проверить, что при <описание внешнего воздействия> [происходит] <описание реакции программы>.
Тест-требования, написанные в рамках функционального подхода, обычно разделяют на следующие группы:
Конкретизация программной реализации может потребовать уточнений или расширений реакций на различные ситуации, возникающие при решении задачи. В этом случае рекомендуется оформить дополнительные тест-требования низкого уровня для структурной проверки системы.
Совокупность тест-требований должна обладать некоторыми важными свойствами: полнота, верифицируемость и непротиворечивость.
Как правило, одному системному или функциональному требованию соответствует минимум одно тест-требование. Если совокупность проверок, задаваемых тест-требованиями, покрывает всю функциональность системы, определенную в системных требованиях и требованиях к программному обеспечению, то говорят о полноте тест-требований. При изменениях требований к системе для поддержания полноты должны меняться и тест-требования.
Как системные требования и требования к ПО, так и тест-требования должны обладать свойством верифицируемости. Т.е. для каждого требования должна существовать возможность определить четкий критерий проверки - выполняется это требование в реализованной системе или нет.
Примером не верифицируемого требования может служить следующее "требование":
Система должна иметь интуитивно понятный пользовательский интерфейс.
Очевидное "тест-требование" будет выглядеть как
Проверить, что система имеет интуитивно понятный пользовательский интерфейс
Без четкого определения критериев интуитивной понятности проверить такое требование при помощи написания тестовых примеров не представляется возможным. Однако, если сопроводить такое требование количественными или качественными характеристиками интуитивно понятного интерфейса - написание тестовых примеров по требованиям становится возможным. Так, среди критериев интуитивной понятность могут быть следующие: глубина вложенности меню не более трех, наличие всплывающих подсказок на каждом элементе управления каждой экранной формы и т.п.
При большом количестве тест-требований и частых их изменениях может возникнуть ситуация, в которой различные требования перестают быть согласованными. В этом случае такие требования имеют взаимоисключающие друг друга критерии проверки. Т.е., например, в простом случае, одно тест-требование на пользовательский интерфейс может декларировать необходимость проверки того, что введенный пользователем пароль имеет длину не более 16 символов, а тест-требование к базе данных системы - что допустимый размер пароля, сохраняемого в БД - от 4 до 12 символов. В этом случае эти два требования являются противоречивыми. Для того, чтобы устранить это противоречие, нужно проводить анализ системных и функциональных требований с последующей модификацией тест-требований. Тест-требования по которым составляются тест-планы для тестирования системы, обычно обладают свойством непротиворечивости, поскольку противоречия обычно устраняются на уровне верификации проектной документации. Однако противоречия могут быть выявлены и позже, в результате попытки создать адекватные тестовые примеры.
В ходе работы над проектом по созданию любой сложной программной системы создается большое количество проектной документации. Основное ее назначение: координация совместных действий большого количества разработчиков в течение более или менее длительных промежутков времени - в процессе первоначальной разработки системы, в процессе выполнения работ по ее модификации, в процессе сопровождения. Структурный состав проектной документации в большинстве проектов практически одинаков - это требования к системе различного уровня (системные, функциональные и структурные), описание ее архитектуры, программный код, тесты и документы, сопровождающие процесс внедрения (руководства по установке, настройке, пользовательские руководства).
Поскольку верификация программной системы (в оптимальном случае) выполняется в течение всего жизненного цикла разработки достаточно большим коллективом разработчиков, при тестировании создается тестовая документация. Основное ее назначение, помимо синхронизации действий тестировщиков различных уровней, - обеспечение гарантий того, что тестирование выполняется в соответствии с выбранными критериями оценки качества, а также того, что все аспекты поведения системы протестированы. Также тестовая документация используется при внесении изменений в систему для проверки того, что как старая, так и новая функциональность работает корректно (Рис 10.1).
Перед началом верификации менеджером тестирования (
В данном документе также определяются требования собственно к тестовой документации - тест-требованиям, тест-планам, отчетам о выполнении тестирования.
Согласно этим требованиям по системным и функциональным требованиям разработчиками тестов (
(рис 10.1) Документация, сопровождающая процесс верификацииНа основании тест-требований разработчиками тестов (test developers) создаются тест-планы - документы, которые содержат подробное пошаговое описание того, как должны быть протестированы тест-требования.
На основании тест-требований и проектной документации разработчиков также создается тестовое окружение, необходимое для корректного выполнения тестов на тестовых стендах - драйверы, заглушки, настроечные файлы и т.п.
По результатам выполнения тестов тестировщиками (testers) создаются отчеты о выполнении тестирования (они могут создаваться либо автоматически, либо вручную), которые содержат информацию о том, какие несоответствия требованиям были выявлены в результате тестирования, а также отчеты о покрытии, содержащие информацию о том, какая доля программного кода системы была задействована в результате выполнения тестирования.
По несоответствиям создаются отчеты о проблемах - документы, которые направляются на анализ в группу разработчиков с целью определения причины возникновения несоответствия.
Изменения в систему вносятся только после всестороннего изучения этих отчетов и локализации проблем, вызвавших несоответствие требованиям. Для того, чтобы процесс изменений не вышел из под контроля и любое изменение протоколировалось (и связывалось с тестами, обнаружившими проблему), создается запрос на изменение системы. После завершения всех работ по запросу на изменение процесс тестирования повторяется до тех пор, пока не будет достигнут приемлемый уровень качества программной системы.
Форматы различных тестовых документов описаны в стандартах IEEE 1012 [14] и IEEE 829 [15], при дальнейшем изложении мы будем придерживаться духа этих стандартов.
Следует особо отметить, что все документы должны иметь уникальные идентификаторы и храниться в единой базе документов проекта. Это позволит сохранить управляемость процессом тестирования и поддерживать необходимое качество разрабатываемой системы. Нет ничего хуже ситуации, когда найденная проблема не была исправлена из-за того, что отчет о ней был утерян и не попал к разработчику.
Первый документ, входящий в состав технологической документации процесса верификации - стратегия тестирования. Стратегия верификации определяет общие подходы и методики верификации, необходимые уровни верификации проектной документации и программного кода, технологии и инструментальные средства.
Другой, не менее важный документ, создаваемый перед началом процесса верификации - план верификации. Этот план содержит последовательное описание всех этапов верификации, процедур на каждом этапе и связей с этапами разработки.
Для каждого этапа определяется:
Иногда план верификации разделяется на отдельные документы, описывающие более подробно каждый из этапов, например:
Согласно разделу 4 стандарта IEEE 829 [15] основная задача плана тестирования как документа - определение границ тестирования, подхода к тестированию, требуемых для тестирования ресурсов, плана-графика тестирования. План тестирования определяет тестируемые элементы и функции системы, задачи, решаемые в ходе тестирования, сотрудников, ответственных за тестирование, и риски, связанные с этим планом. Такая форма плана тестирования является достаточно полной и включает в себя не только технические аспекты, связанные собственно с описанием тестовых примеров, но и организационные, связанные с общим управлением процессом тестирования. На практике объемы технических и организационных разделов планов тестирования могут достаточно сильно варьироваться. Однако, минимально необходимые элементы, которые рекомендуется включать в каждый план тестирования - это:
Стратегия и планы тестирования несколько отличаются от другой документации, относящейся к процессу тестирования: в этих документах достаточно много внимания уделяется тому, как должен быть организован процесс тестирования, а не тому, как тестировать саму систему.
Тест-требования - основной документ для тестировщика, который определяет функциональность системы с точки зрения того, что должно быть проверено, чтобы удостовериться в ее корректном функционировании, а также - на основании какого
Существует два подхода к написанию тест-требований - функциональный и структурный. Тест-требования, написанные в рамках функционального подхода, основываются на системных требованиях и требованиях к программному обеспечению системы.
(рис 10.2) Место тест-требований среди проектной документацииТест-требования, написанные в рамках структурного подхода, пишутся на основании описания архитектуры системы и принимают в расчет строение исходных текстов системы. Из-за такого различия функциональный и структурный подходы часто называют подходами черного и белого ящиков. Структурные тест-требования важны в том случае, когда к надежности системы предъявляются повышенные требования, т.е. когда важно проверить не только, насколько корректно система в целом отрабатывает сценарии своей работы (корректные и некорректные с точки зрения пользователя), но и как в различных нестандартных ситуациях будут вести себя отдельные ее компоненты.
На практике почти всегда применяются оба подхода к разработке тест-требований. В результате в состав документации проекта включаются тест-требования верхнего уровня и тест-требования нижнего уровня, по которым составляются тест-планы (Рис 10.2).
Как уже говорилось выше, тест-требования содержат описание требованиий по проверке всех основных функций системы. Тест-требования должны быть достаточными для построения тест-плана проверки реализации задачи без знакомства с ее программными текстами, т.е. тест-требования должны обладать свойством изоляции от внутренней структуры системы.
Как правило, структура тест-требований следует структуре раздела функциональных требований на систему. Задача каждого требования - определение того, что надо проверить. Техника исполнения каждой такой проверки - задача тест-плана. Обычный формат описания отдельного требования следующий:
Проверить, что при <описание внешнего воздействия> [происходит] <описание реакции программы>.
Тест-требования, написанные в рамках функционального подхода, обычно разделяют на следующие группы:
Конкретизация программной реализации может потребовать уточнений или расширений реакций на различные ситуации, возникающие при решении задачи. В этом случае рекомендуется оформить дополнительные тест-требования низкого уровня для структурной проверки системы.
Совокупность тест-требований должна обладать некоторыми важными свойствами: полнота, верифицируемость и непротиворечивость.
Как правило, одному системному или функциональному требованию соответствует минимум одно тест-требование. Если совокупность проверок, задаваемых тест-требованиями, покрывает всю функциональность системы, определенную в системных требованиях и требованиях к программному обеспечению, то говорят о полноте тест-требований. При изменениях требований к системе для поддержания полноты должны меняться и тест-требования.
Как системные требования и требования к ПО, так и тест-требования должны обладать свойством верифицируемости. Т.е. для каждого требования должна существовать возможность определить четкий критерий проверки - выполняется это требование в реализованной системе или нет.
Примером не верифицируемого требования может служить следующее "требование":
Система должна иметь интуитивно понятный пользовательский интерфейс.
Очевидное "тест-требование" будет выглядеть как
Проверить, что система имеет интуитивно понятный пользовательский интерфейс
Без четкого определения критериев интуитивной понятности проверить такое требование при помощи написания тестовых примеров не представляется возможным. Однако, если сопроводить такое требование количественными или качественными характеристиками интуитивно понятного интерфейса - написание тестовых примеров по требованиям становится возможным. Так, среди критериев интуитивной понятность могут быть следующие: глубина вложенности меню не более трех, наличие всплывающих подсказок на каждом элементе управления каждой экранной формы и т.п.
При большом количестве тест-требований и частых их изменениях может возникнуть ситуация, в которой различные требования перестают быть согласованными. В этом случае такие требования имеют взаимоисключающие друг друга критерии проверки. Т.е., например, в простом случае, одно тест-требование на пользовательский интерфейс может декларировать необходимость проверки того, что введенный пользователем пароль имеет длину не более 16 символов, а тест-требование к базе данных системы - что допустимый размер пароля, сохраняемого в БД - от 4 до 12 символов. В этом случае эти два требования являются противоречивыми. Для того, чтобы устранить это противоречие, нужно проводить анализ системных и функциональных требований с последующей модификацией тест-требований. Тест-требования по которым составляются тест-планы для тестирования системы, обычно обладают свойством непротиворечивости, поскольку противоречия обычно устраняются на уровне верификации проектной документации. Однако противоречия могут быть выявлены и позже, в результате попытки создать адекватные тестовые примеры.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.