 ПОЗНАВАТЕЛЬНОЕ Сила воли ведет к действию, а позитивные действия формируют позитивное отношение Как определить диапазон голоса - ваш вокал Игровые автоматы с быстрым выводом Как самому избавиться от обидчивости Противоречивые взгляды на качества, присущие мужчинам Вкуснейший "Салат из свеклы с чесноком" Натюрморт и его изобразительные возможности Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д. Как научиться брать на себя ответственность Зачем нужны границы в отношениях с детьми? Световозвращающие элементы на детской одежде Как победить свой возраст? Восемь уникальных способов, которые помогут достичь долголетия Классификация ожирения по ИМТ (ВОЗ) Глава 3. Завет мужчины с женщиной
Оси и плоскости тела человека - Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.
| Лекция 6. Документация, сопровождающая процесс верификации и тестирования
Технологические процессы верификации и роли в проекте, документация, создаваемая в ходе жизненного цикла проекта, ее назначение В ходе работы над проектом по созданию любой сложной программной системы создается большое количество проектной документации. Основное ее назначение: координация совместных действий большого количества разработчиков в течение более или менее длительных промежутков времени - в процессе первоначальной разработки системы, в процессе выполнения работ по ее модификации, в процессе сопровождения. Структурный состав проектной документации в большинстве проектов практически одинаков - это требования к системе различного уровня (системные, функциональные и структурные), описание ее архитектуры, программный код, тесты и документы, сопровождающие процесс внедрения (руководства по установке, настройке, пользовательские руководства). Поскольку верификация программной системы (в оптимальном случае) выполняется в течение всего жизненного цикла разработки достаточно большим коллективом разработчиков, при тестировании создается тестовая документация. Основное ее назначение, помимо синхронизации действий тестировщиков различных уровней, - обеспечение гарантий того, что тестирование выполняется в соответствии с выбранными критериями оценки качества, а также того, что все аспекты поведения системы протестированы. Также тестовая документация используется при внесении изменений в систему для проверки того, что как старая, так и новая функциональность работает корректно. Перед началом верификации менеджером тестирования (test manager) создается документ, называемый планом верификации (или планом тестирования, но это не то же самое, что тест-план). План тестирования - организационный документ, содержащий требования к тому, как должно выполняться тестирование в данном конкретном проекте. В нем определяются общие подходы к согласованию процессов разработки и верификации, определяются методики проведения верификации, состав тестовой документации и ее взаимосвязь с документацией разработчиков, сроки различных этапов верификации, различные роли и квалификация тестировщиков, необходимые для выполнения всех работ по тестированию, требования к инструментам тестирования и тестовым стендам, а также оцениваются риски и приводятся пути для их преодоления. В данном документе также определяются требования собственно к тестовой документации - тест-требованиям, тест-планам, отчетам о выполнении тестирования. Согласно этим требованиям по системным и функциональным требованиям разработчиками тестов (test procedure developers) создаются тест-требования - документы, в которых подробно описано то, какие аспекты поведения системы должны быть протестированы. На основании описания архитектуры создаются низкоуровневые тест-требования, где описываются аспекты поведения конкретной программной реализации системы, которые необходимо протестировать.
На основании тест-требований разработчиками тестов (test developers) создаются тест-планы - документы, которые содержат подробное пошаговое описание того, как должны быть протестированы тест-требования. На основании тест-требований и проектной документации разработчиков также создается тестовое окружение, необходимое для корректного выполнения тестов на тестовых стендах - драйверы, заглушки, настроечные файлы и т.п. По результатам выполнения тестов тестировщиками (testers) создаются отчеты о выполнении тестирования (они могут создаваться либо автоматически, либо вручную), которые содержат информацию о том, какие несоответствия требованиям были выявлены в результате тестирования, а также отчеты о покрытии, содержащие информацию о том, какая доля программного кода системы была задействована в результате выполнения тестирования. По несоответствиям создаются отчеты о проблемах - документы, которые направляются на анализ в группу разработчиков с целью определения причины возникновения несоответствия. Изменения в систему вносятся только после всестороннего изучения этих отчетов и локализации проблем, вызвавших несоответствие требованиям. Для того, чтобы процесс изменений не вышел из под контроля и любое изменение протоколировалось (и связывалось с тестами, обнаружившими проблему), создается запрос на изменение системы. После завершения всех работ по запросу на изменение процесс тестирования повторяется до тех пор, пока не будет достигнут приемлемый уровень качества программной системы. Форматы различных тестовых документов описаны в стандартах IEEE 1012 [14] и IEEE 829 [15], при дальнейшем изложении мы будем придерживаться духа этих стандартов. Следует особо отметить, что все документы должны иметь уникальные идентификаторы и храниться в единой базе документов проекта. Это позволит сохранить управляемость процессом тестирования и поддерживать необходимое качество разрабатываемой системы. Нет ничего хуже ситуации, когда найденная проблема не была исправлена из-за того, что отчет о ней был утерян и не попал к разработчику. Стратегия и планы верификации Первый документ, входящий в состав технологической документации процесса верификации - стратегия тестирования. Стратегия верификации определяет общие подходы и методики верификации, необходимые уровни верификации проектной документации и программного кода, технологии и инструментальные средства. Другой, не менее важный документ, создаваемый перед началом процесса верификации - план верификации. Этот план содержит последовательное описание всех этапов верификации, процедур на каждом этапе и связей с этапами разработки. Для каждого этапа определяется:
Иногда план верификации разделяется на отдельные документы, описывающие более подробно каждый из этапов, например:
Согласно разделу 4 стандарта IEEE 829 [15] основная задача плана тестирования как документа - определение границ тестирования, подхода к тестированию, требуемых для тестирования ресурсов, плана-графика тестирования. План тестирования определяет тестируемые элементы и функции системы, задачи, решаемые в ходе тестирования, сотрудников, ответственных за тестирование, и риски, связанные с этим планом. Такая форма плана тестирования является достаточно полной и включает в себя не только технические аспекты, связанные собственно с описанием тестовых примеров, но и организационные, связанные с общим управлением процессом тестирования. На практике объемы технических и организационных разделов планов тестирования могут достаточно сильно варьироваться. Однако, минимально необходимые элементы, которые рекомендуется включать в каждый план тестирования - это:
Стратегия и планы тестирования несколько отличаются от другой документации, относящейся к процессу тестирования: в этих документах достаточно много внимания уделяется тому, как должен быть организован процесс тестирования, а не тому, как тестировать саму систему. Тест-требования Технологические цепочки и роли участников проекта, использующих тест-требования. Связь тест-требований с другими типами проектной документации. Тест-требования - основной документ для тестировщика, который определяет функциональность системы с точки зрения того, что должно быть проверено, чтобы удостовериться в ее корректном функционировании, а также - на основании какого внешнего эффекта можно убедиться, что проверяемая функция реализована правильно. Существует два подхода к написанию тест-требований - функциональный и структурный. Тест-требования, написанные в рамках функционального подхода, основываются на системных требованиях и требованиях к программному обеспечению системы.
Тест-требования, написанные в рамках структурного подхода, пишутся на основании описания архитектуры системы и принимают в расчет строение исходных текстов системы. Из-за такого различия функциональный и структурный подходы часто называют подходами черного и белого ящиков. Структурные тест-требования важны в том случае, когда к надежности системы предъявляются повышенные требования, т.е. когда важно проверить не только, насколько корректно система в целом отрабатывает сценарии своей работы (корректные и некорректные с точки зрения пользователя), но и как в различных нестандартных ситуациях будут вести себя отдельные ее компоненты. На практике почти всегда применяются оба подхода к разработке тест-требований. В результате в состав документации проекта включаются тест-требования верхнего уровня и тест-требования нижнего уровня, по которым составляются тест-планы (Рис 10.2).
Свойства тест-требований Как уже говорилось выше, тест-требования содержат описание требованиий по проверке всех основных функций системы. Тест-требования должны быть достаточными для построения тест-плана проверки реализации задачи без знакомства с ее программными текстами, т.е. тест-требования должны обладать свойством изоляции от внутренней структуры системы. Как правило, структура тест-требований следует структуре раздела функциональных требований на систему. Задача каждого требования - определение того, что надо проверить. Техника исполнения каждой такой проверки - задача тест-плана. Обычный формат описания отдельного требования следующий: Проверить, что при <описание внешнего воздействия> [происходит] <описание реакции программы>.
Тест-требования, написанные в рамках функционального подхода, обычно разделяют на следующие группы:
Конкретизация программной реализации может потребовать уточнений или расширений реакций на различные ситуации, возникающие при решении задачи. В этом случае рекомендуется оформить дополнительные тест-требования низкого уровня для структурной проверки системы. Совокупность тест-требований должна обладать некоторыми важными свойствами: полнота, верифицируемость и непротиворечивость. Как правило, одному системному или функциональному требованию соответствует минимум одно тест-требование. Если совокупность проверок, задаваемых тест-требованиями, покрывает всю функциональность системы, определенную в системных требованиях и требованиях к программному обеспечению, то говорят о полноте тест-требований. При изменениях требований к системе для поддержания полноты должны меняться и тест-требования. Как системные требования и требования к ПО, так и тест-требования должны обладать свойством верифицируемости. Т.е. для каждого требования должна существовать возможность определить четкий критерий проверки - выполняется это требование в реализованной системе или нет. Примером не верифицируемого требования может служить следующее "требование": Система должна иметь интуитивно понятный пользовательский интерфейс.
Очевидное "тест-требование" будет выглядеть как Проверить, что система имеет интуитивно понятный пользовательский интерфейс
Без четкого определения критериев интуитивной понятности проверить такое требование при помощи написания тестовых примеров не представляется возможным. Однако, если сопроводить такое требование количественными или качественными характеристиками интуитивно понятного интерфейса - написание тестовых примеров по требованиям становится возможным. Так, среди критериев интуитивной понятность могут быть следующие: глубина вложенности меню не более трех, наличие всплывающих подсказок на каждом элементе управления каждой экранной формы и т.п. При большом количестве тест-требований и частых их изменениях может возникнуть ситуация, в которой различные требования перестают быть согласованными. В этом случае такие требования имеют взаимоисключающие друг друга критерии проверки. Т.е., например, в простом случае, одно тест-требование на пользовательский интерфейс может декларировать необходимость проверки того, что введенный пользователем пароль имеет длину не более 16 символов, а тест-требование к базе данных системы - что допустимый размер пароля, сохраняемого в БД - от 4 до 12 символов. В этом случае эти два требования являются противоречивыми. Для того, чтобы устранить это противоречие, нужно проводить анализ системных и функциональных требований с последующей модификацией тест-требований. Тест-требования по которым составляются тест-планы для тестирования системы, обычно обладают свойством непротиворечивости, поскольку противоречия обычно устраняются на уровне верификации проектной документации. Однако противоречия могут быть выявлены и позже, в результате попытки создать адекватные тестовые примеры. Тест-планы Технологические цепочки и роли участников проекта, использующих тест-планы. Связь тест-планов с другими типами проектной документации. На основании тест-требований составляются тест-планы - программы испытаний (проверки, тестирования) программной реализации системы. В отличие от тест-требований в тест-плане описываются конкретные способы проверки функциональности системы, т.е. то, как должна проверяться функциональность. Как правило, тест-план состоит из отдельных тестовых примеров, каждый из которых проверяет некоторую функцию или набор функций системы. Для каждого тестового примера однозначно определяется критерий успешного прохождения (pass/fail criteria), при помощи которого можно судить - соответствует ли поведение системы заданному в требованиях или нет (Рис 11.1).
Критерием качества тест-плана является покрытие (выполнение) всех требований к проверке правильности функционирования программной реализации. Желательной характеристикой тест-плана является проверка исполнения всех веток схемы программной реализации. Структура тест-плана может соответствовать структуре тест-требований или следовать логике внешнего поведения системы. Каждый пункт тест-плана описывает, как производится проверка правильности функционирования программной реализации, и содержит:
В состав тест-плана рекомендуется дополнительно включать пункты, которые служат для проверки ветвей программы, не выполнявшихся при проверке удовлетворения функциональных требований. Такие пункты тест-плана могут иметь указание "Для полноты покрытия" в поле ссылки. Тест-план может готовиться в формализованной форме и служить входным документом для тестовой оснастки, по которому тесты будут выполняться в автоматическом режиме с автоматической фиксацией результатов. В случае, если тест-план готовится в виде текстового документа, возможно только ручное тестирование системы по данному тест-плану. Возможные формы подготовки тест-планов Форма представления тест-плана в первую очередь зависит от того, каким образом тест-план будет использоваться в процессе тестирования. При ручном тестировании удобно представление тест-планов в виде текстовых документов, в которых отдельные разделы представляют собой описания тестовых примеров. Каждый тестовый пример в таком случае включает в себя перечисление последовательности действий, которые необходимо выполнить тестировщику для проведения тестирования - сценария теста, а также ожидаемые отклики системы на эти действия. Такая форма представления тест-плана неудобна для автоматизации тестирования, поскольку описания на естественном языке практически не поддаются формализации. Для автоматизированного тестирования сценарий теста может записываться на каком-либо формальном языке, в этом случае возможно непосредственное использование тест-планов как входных данных для среды тестирования. Другой формой представления тест-планов является таблица. Эта форма наиболее часто используется при четко и формально определенных входных потоках данных системы. Например, каждый столбец таблицы может представлять собой тестовый пример, каждая строка - описание входного потока данных, а в ячейке таблицы записывается передаваемое в данном тестовом примере в данный поток значение. Ожидаемые значения для данного теста записываются в аналогичной таблице, в которой в строках перечисляются выходные потоки данных. И, наконец, третьей формой представления тестовых примеров является определение примеров в виде конечного автомата. Такая форма представления используется при тестировании протоколов связи или программных модулей, взаимодействие которых с внешним миром производится при помощи обмена сообщениями по заранее заданному интерфейсу. Модуль при этом может быть представлен как конечный автомат с набором состояний, а тест-план будет состоять из двух частей - описания переходов между состояниями и их параметров и тестовых примеров, в которых задается маршрут перехода между состояниями, параметры переходов и ожидаемые значения. Такое представление тест-плана может быть пригодно как для ручного, так и для автоматизированного тестирования. Генераторы тестов В некоторых случаях для упрощения процедуры тестирования используются специальные инструментальные средства, автоматически генерирующие тестовые примеры. Эти системы различаются по используемым методам генерации тестовых примеров, а получаемые тестовые примеры различаются по областям применимости. Различают следующие способы генерации тестовых примеров:
Первый способ генерации тестовых примеров приемлем для тестирования системы как "черного ящика", но требует, чтобы тест-требования (или системные/функциональные требования) были подготовлены на специальном формальном языке оформления требований, например, RDL (Requirements Definition Language). Затем по требованиям строятся тестовые примеры, которые проверяют функциональность системы с точки зрения требований, т.е. в этом случае достигается основная цель верификации - проверить, ведет ли себя система в соответствии с требованиями. К сожалению, этот путь достаточно трудоемок и экономия времени от автоматической генерации тестов зачастую сводится на нет необходимостью в выделении дополнительного времени на перевод всех требований в формальную форму. В связи с этим рекомендуется применять данный метод только для тестирования систем, требования на которые могут быть сравнительно легко формализованы с использованием того или иного языка - например, системы поддержки коммуникационных протоколов. Второй метод генерации тестовых примеров - на основе случайных данных. В этом случае не может идти и речи о систематизированном тестировании и гарантиях качества системы. Такой подход может применяться только при необходимости проверить поведение системы в случае передачи в нее большого количества неверных данных или определить количественные параметры поведения системы под большой нагрузкой. Третий метод тестирования основан на анализе исходных текстов системы и построения тестов, которые выполняют каждое логическое условие и каждый оператор системы. В результате достигается очень высокий уровень покрытия программного кода. Однако, в этом случае тесты проверяют не то, что система должна делать в соответствии с требованиями, а то, как она делает уже запрограммированное. Перед тестировщиком в этом случае стоит задача анализа программного кода системы на соответствие требованиям, что зачастую представляет собой задачу не менее сложную, чем ручное написание тестов для проверки требований. Обычно рекомендуется вначале написать все тесты по требованиям, а затем, в случае необходимости, воспользоваться генератором тестов по программному коду. При этом целью использования генератора будет не достижение максимально возможного покрытия любой ценой, а анализ причин непокрытия при выполнении тестов требований и, в случае необходимости, коррекции требований. Отчеты о прохождении тестов Технологические цепочки и роли участников проекта, использующих отчеты о прохождении тестов. Связь отчетов о прохождении тестов с другими типами проектной документации Отчеты о прохождении тестов - основной (а иногда единственный) источник для заключения о соответствии протестированной системы требованиям. После выполнения всех тестов, описанных в тест-планах, среда тестирования создает отчет о том, насколько успешно система выполнила эти тесты. Такой отчет как минимум содержит информацию о каждом выполненном тестовом примере (его идентификатор) и результат его выполнения - успех или неудача. По результатам анализа отчетов о прохождении тестов могут быть выявлены либо дефекты в самой системе, либо некорректно составленные или противоречивые требования. В обоих случаях результаты анализа служат основой для создания запросов на изменение требований и/или кода системы. После корректного исправления дефектов при регрессионном тестировании неуспешно выполненные тестовые примеры должны выполниться успешно (Рис 11.4).
Отчеты о прохождении тестов могут служить основой для отслеживания состояния проекта: если с течением времени количество обнаруживаемых дефектов (неуспешно выполненных тестовых примеров) падает при условии сохранения качества тестирования - это свидетельствует о повышении качества разрабатываемой системы. С другой стороны, при внесении значительных изменений в систему количество дефектов неизбежно возрастает. Таким образом, идеальный график зависимости количества дефектов от времени похож на синусоиду с уменьшающейся амплитудой на каждом полупериоде. Возможные формы представления отчетов о прохождении тестов В предыдущих лекциях уже приводилось несколько примеров отчетов о выполнении тестовых примеров, однако ранее основной уклон делался в сторону общей статистики выполнения тестов. В стандарте IEEE 829 отчет о прохождении тестов разделен на три различных документа и описан в разделах 9 (Test log), 10 (Test incident report) и 11 (Test summary report). В эти разделы включены соответственно общий отчет о прохождении тестов, отчет о проблемах, выявленных в результате выполнения тестов, и общая статистика прохождения тестов. В данном курсе отчет о прохождении тестов считается единым документом, разделенным на три части:
Заголовочная часть отчета о прохождении тестов служит для идентификации отчета и протоколирования того, какая часть разрабатываемой системы подвергалась тестированию, какая ее версия, какая конфигурация тестового стенда использовалась для выполнения тестов. В заголовочную часть отчета о выполнении тестов обычно включается следующая информация: 1. Название проекта или тестируемой системы 2. Общий идентификатор группы тестовых примеров, включенных в отчет 3. Идентификатор тестируемого модуля или группы модулей и номера их версий 4. Ссылку на разделы и версии тест-требований или функциональных требований, на основании чего написаны тесты, для которых сгенерирован отчет 5. Время начала выполнения теста и его продолжительность 6. Конфигурацию тестового стенда, на которой выполнялся тест 7. Имена и фамилии автора тестов и/или лица, выполнявшего тесты. Следующая часть отчета о прохождении тестов должна содержать информацию о результате выполнения каждого тестового примера - завершился ли он успешно или в результате его выполнения были выявлены какие-либо несоответствия с ожидаемым результатом. В некоторых проектах эта часть отчета может быть представлена в одной из двух форм - полной или краткой. Полная форма содержит всю информацию о тестовом примере, краткая - только информацию об обнаруженных в результате выполнения тестового примера несоответствий ожидаемых и реальных выходных значений. Обычно каждая запись о результате прохождения каждого тестового примера в полной форме содержит следующую информацию:
В краткой форме каждая запись обычно содержит следующую информацию:
Завершающая часть отчета о прохождении тестов должна содержать краткую итоговую информацию о выполнении всех тестовых примеров, по которым составлялся отчет. Обычно эта часть отчета содержит следующую информацию: 1. Общее количество выполненных тестовых примеров 2. Количество успешно пройденных тестовых примеров 3. Количество неуспешно пройденных тестовых примеров 4. Общее количество проверенных выходных значений 5. Количество выходных значений, у которых ожидаемое значение не совпало с реальным Часто в отчет о выполнении тестов кроме количественной статистики помещают раздел с подробным объяснением причин неуспешно пройденных тестовых примеров. Каждый пункт такого объяснения обычно содержит следующую информацию: 1. Идентификаторы тестовых примеров, благодаря неуспешному выполнению которых выявлена проблема 2. Ссылка на разделы требований, по которым написаны тестовые примеры 3. Ссылка на участки программного кода в котором выявлена проблема 4. Описание сути проблемы и (опционально) возможные пути ее решения с точки зрения тестировщика Данный раздел может служить основой для создания отчетов о проблемах либо частично заменять их. Автоматическое и ручное тестирование Некоторые тестовые примеры не могут быть выполнены в автоматическом режиме и поэтому требуют ручной работы тестировщика по их выполнению. Результаты выполнения ручных тестовых примеров могут заноситься в тот же самый документ, что и результаты выполнения автоматических тестовых примеров. Особенно часто это делается в случае, если и автоматические, и ручные тесты проверяют одну и ту же функциональную часть тестируемой системы. В этом случае при генерации отчета о прохождении тестов для ручных тестов генерируется форма, в которую тестировщик заносит данные о результатах проведенного им ручного тестирования. Само ручное тестирование может заключаться либо в выполнении тестового сценария, заданного в тест-плане, либо в экспертном анализе участков программного кода системы, которые не могут быть выполнены при автоматическом тестировании на тестовом стенде. Форма для ручного тестирования обычно содержит следующую информацию: 1. Идентификатор ручного тестового примера 2. Описание сценария ручного тестового примера или задачи экспертного анализа 3. Имя лица, проводившего ручное тестирование 4. Версии требований, на основании которых проводилось ручное тестирование 5. Ссылки на участки программного кода, для которого проводится ручное тестирование 6. Информацию о соответствии программного кода требованиям (результат ручного тестирования) - соответствует/не соответствует 7. Информацию о потенциально возможных проблемах внутри допустимого диапазона значений и за его пределами 8. Информацию о возможности покрытия тестируемого вручную программного кода при достижении условий, указанных в требованиях 9. Информацию об итоговом результате ручного тестового примера - успешно/неуспешно Отчеты о покрытии программного кода Технологические цепочки и роли участников проекта, использующих отчеты о покрытии. Связь отчетов о покрытии с другими типами проектной документации Степень покрытия программного кода тестами - важный количественный показатель, позволяющий оценить качество системы тестов, а в некоторых случаях - и качество тестируемой программной системы. Данные о степени покрытия помещаются в отчеты о покрытии, которые генерируются при выполнении тестов инструментальными средствами, поддерживающими процесс тестирования, т.е. по сути, генерируются средой тестирования (Рис 13.1). Формат отчетов о покрытии обычно единый внутри проекта или нескольких проектов и часто зависит от особенностей инструментальных средств тестирования. В отчете о покрытии в стандартизированной форме указываются участки программного кода тестируемой системы (или ее части), которые не были выполнены во время выполнения тестовых примеров, т.е. не были покрыты тестами. Причины непокрытия анализируются тестировщиками, по результатам анализа составляются отчеты о проблемах и запросы на изменение - документы, где описываются объекты разработки, которые необходимо изменить, и причины этих изменений.
Недостаточное покрытие может свидетельствовать о неполноте системы тестов или тест-требований, в этом случае в запросе об изменении указывается на необходимость расширения системы тестов или тест-требований. Другой причиной недостаточного покрытия могут быть участки защитного кода, которые никогда не выполнятся даже в случае нештатной работы системы. В этом случае в запросе на изменения указывается на необходимость модификации исходных текстов либо отмечается, что для этого участка программной системы не требуется покрытие. В качестве третьей причины недостаточного покрытия может выступать рассогласование требований и программного кода системы, в результате которого в коде могут остаться неиспользуемые более участки либо, наоборот, появиться участки, рассчитанные на будущее (и реализующие функциональность, не описанную в требованиях). В этом случае в запросе на изменение указывается на необходимость модификации требований и/или кода системы для приведения их в согласованное состояние. Возможные формы отчетов о покрытии Типичный отчет о покрытии представляет собой список структурных элементов покрываемого программного кода (функций или методов), содержащий для каждого структурного элемента следующую информацию:
Кроме того, отчет о покрытии содержит заголовочную информацию, позволяющую идентифицировать отчет, и общий итог - общую степень покрытия всех функций, для которых собирается информация о покрытии. Отчет о покрытии может создаваться либо для всех функций программного модуля или всего проекта, либо выборочно для определенных функций. В случае, если размер функций, для которых генерируется выборочный отчет, невелик, может применяться другая форма отчета о покрытии, в котором покрытый и непокрытый программный код выделяется различными цветами. Такая форма неприменима для покрытия ветвей и логических условий, но может применяться для покрытия по строкам. Конкретная форма отчета о покрытии определяется инструментарием и технологическими процессами проекта. Отчеты о проблемах Технологические цепочки и роли участников проекта, использующих отчеты о проблемах. Связь отчетов о проблемах с другими типами проектной документации Каждое несоответствие с требованиями, найденное тестировщиком, должно быть задокументировано в виде отчета о проблеме. Вероятность обнаружения и исправления ошибки, вызвавшей это несоответствие, зависит от того, насколько качественно она задокументирована. Отчеты о проблемах могут поступать не только от тестировщиков, но и от специалистов технической поддержки или пользователей, однако их общая цель - указать на наличие проблемы в системе, которая должна быть устранена. Если отчет составлен некорректно, разработчик не сможет устранить проблему, поэтому можно считать этот отчет одним из самых важных документов в цепочке тестовой документации. Главное, что должно быть включено в отчет об ошибке, - это:
Любой отчет о проблеме должен быть составлен немедленно после ее |
