Финальный отчет о тестировании

Итоговый отчет тестирования (Test summary report)

Итоговый отчет тестирования имеет целью документировать результат исполнения плана тестирования. Итоговый отчет тестирования выпускается для каждой выпускаемой версии разрабатываемого программного обеспечения.

 

Название раздела	Описание
Идентификатор отчета (Identifier)	Указывается уникальный идентификатор, присвоенный отчету
Резюме (Summary)	Приводится ссылка на оттестированную подсистему (систему) и ее версию. Приводится ссылка на план тестирования или часть плана (главы) для которого выпускается отчет. Приводятся итоговые данные по полноте тестирования в соответствии с планом и результирующие данные по уровню не исправленных ошибок.
Отклонения (Variances)	Указывается все отклонения принятые в тестовых спецификациях и тестовых процедурах относительно плана тестирования. Приводятся причины или обоснования принятых отклонений.
Оценка полноты тестирования (Comprehensiveness Assessment)	Проводится оценка полноты тестирования. Дается список пунктов плана, которые выполнены не полностью. Приводятся причины неполного тестирования.
Суммарные результаты (Summary Results)	Дается общее описание неразрешенных ошибок.
Оценка (Evaluation)	Приводится общая оценка результатов тестирования по всем элементам тестирования (полнота тестирования, плотность неразрешенных ошибок)

 

Жизненный цикл дефектов

Итак, мы нашли баг. Может даже блокер. Что же с ним может случится, на всём его нелегком жизненном пути?

• Обнаружен (Submitted) – тестировщик нашел баг. Состоялось «рождение» дефекта в QA-мире.

• Новый (New) – дефект успешно занесен в систему.

После этого, в зависимости от решения менеджера проекта, баг может быть:

• Отклонен (Declined). По разным причинам дефект может и не считаться дефектом или считаться неактуальным дефектом, что вынуждает отклонить его.

• Отложен (Deferred). Исправление этого бага не несет ценности на данном этапе разработки или по другим, отсрочивающим его исправление причинам.

• Открыт (Opened). Ответственное лицо признало дефект дефектом, при чем таким, который нужно исправить.

Когда наличие дефекта неопровержимо, его путь может привести к следующим статусам:

• Назначен (Assigned). Исправление текущего бага возложено на плечи определенного разработчика.

• Исправлен (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.

В зависимости от того, исправил ли разработчик дефект, дефект может быть:

• Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект, или все-таки разработчик безответственный. Если бага больше нет, он получает данный статус.

• Повторно открыт (Reopened). Если опасения тестировщика оправданы и баг в новом билде не исправлен – он все так же потребует исправления, поэтому заново открывается.

• Закрытый (Fixed). В результате определенного количества циклов баг все-таки окончательно устранен и больше не потребует внимания команды – он объявляется закрытым.

Это и есть основные этапы жизненного цикла дефекта.

 

46. Информирование о дефектах

 

Важной частью решений дефектов есть собраниеь и представиление надлежащей информации в подходящем докладе о дефектах. Отчет о дефекте описывает некоторую ситуацию, поведение, или событие, которое произошло во время тестирования, что требует дальнейшего изучения. Во многих случаях, отчет о дефектах состоит из одного или двух разделах, полных информации, собранной с помощью инструмента отслеживания ошибок и хранения в базе данных. Эта информация может быть основана на статическом испытании, который обнаруживает дефект или на динамическом испытании, который показывает отказ, как правило, с меньшим количеством информации, необходимой ранее (например, требования обзоры и блок тест), хотя это менее общие для статических дефектов тестирования, чтобы управлять с помощью инструментов управления дефектами.

В начале этой лекции, мы выделили три основные цели, для которых служат отчеты о дефектах. Для первой цели, а именно, предоставление информации для команды проекта, чтобы исправить дефект эффективно (с точки зрения усилий, затрат и продолжительности

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

Различные виды отчетов дефектов требует различную информацию, и инструменты управления дефектами должны быть достаточно гибкими, чтобы запрашивать соответствующие поля в зависимости от типа дефекта. Данные должны быть записаны в различных областях, в идеале поддерживается проверки данных для того, чтобы избежать сбоев при вводе данных и обеспечения эффективной отчетности. Чем больше и определены поля, то легче сообщить отдельные дефекты, а также для создания отчетов о тенденциях и другие сводные отчеты.

Структура отчета падающего кроется в 829-1998 IEEE Std стандарта для Software документации. План предполагает, что доклад должен содержать следующие разделы:

· Протокол испытаний инцидента ID: Уникальный идентификатор, присвоенный этому докладу падающего тест

· Краткое изложение: изложение инцидента, в котором подробно,как ожидалось, и фактические результаты

· Описание: Подробное описание инцидента, который должен включать входы, ожидаемые результаты, фактические результаты, аномалии, дату и время, порядок шаг, окружающей среды, пытается повторить, тестер комментарии, замечания наблюдателей. Она также должна включать любую информацию о возможных причинах и решениях

· Влияние: Если известно, какое влияние оказывает на работу продукта

 

47.Атрибуты баг-репорта

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

Итак, как только мы обнаруживаем баг, нам необходимо его задокументировать для продолжения жизненного цикла дефекта (который мы рассматривали ранее). Документ, который описывает баг, называется – баг репорт.

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

В общем случае, баг репорт состоит из:

Шапка.

• Короткое описание (короткое описание проблемы).

• Проект (название текущего проекта).

• Компонент приложения (в котором возник дефект).

• Версия (версия билда, в котором найден баг).

• Серьезность (градация степени влияния на приложение бага).

• Приоритет (очередь исправления бага).

• Статус (отображает статус бага в своем жизненном цикле).

• Автор (автор баг репорта).

• Назначение (кто должен исправить дефект).

Окружение.

• Операционная система, разрядность, Сервис Пак, браузер, его версия и т.д.

Описание.

• Шаги воспроизведения (описание пути, который приводит к возникновению дефекта).

• Фактический результат (результат, к которому приходим выполнив все шаги воспроизведения).

• Ожидаемый результат (результат, который быть в соответствии с требованиями).

Дополнения.

• Прикрепленный файл (логи, скриншоты, другие документы, которые могут помочь воспроизвести проблему или решить ее).

Несмотря на такое большое количество пунктов баг репорта, можно выделить несколько основных полей, присутствие которых необходимо:

• Краткое описание. Поле, в котором нужно поместить весь смысл всего баг репорта. Чаще всего, в коротком описании лаконично отвечают на 3 вопроса: «Где?», «Что?», «Когда?» (именно в такой последовательности, как бы не хотелось изменить ее по примеру всем известной игры).

• Серьезность. Дефект либо полностью останавливает работоспособность приложения, либо только часть функциональности, либо иное.

• Шаги к воспроизведению. Точное и понятное описание всех шагов, которые приводят к появлению дефекта, с учетом всех необходимых входных данных и т.д.

• Фактический результат.

• Ожидаемый результат.

48. Атрибуты качества в разных типах тестирования

Виды тестирования:

модульное тестирование тестируют конкретные программные модули -

одну подсистему из всей системы. Тестирование проводит в общем случае разработчик, занимающийся реализацией модуля. Модуль должен быть протестирован прежде, чем его проинтегрируют в остальную систему. Тестируя модуль, необходимо следить, чтобы он отвечал при анализе поставленным требованиям. Целью тестирования модуля является все же нахождение ошибок, а не установление соответствия требованиям пользователя. Например, работают ли корректно добавленные в модуль функции и возвращают ли правильные ответы. Модули тестируют на основе данных: верных, неполных и ошибочных. Обычно производится так называемое тестированием типа «белый ящик», то есть тестировщик знает внутреннее строение и логику работы тестируемого программного обеспечения.

интеграционное тестирование тестируют совместную работу между модулями - проверяют, работают ли объединенные друг с другом модули, и не генерируют ли самостоятельно работающие без ошибок модули совместные ошибки. В качестве тестировщика обычно используют независимого тестировщика, то есть тестировщика, который сам не разрабатывал проверяемые модули. Примером интеграционного теста является еженощная компиляция, чтобы проконтролировать поведение разрабатываемого продукта.

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

Регрессионное тестирование - это тестирование любых типов программного обеспечения, которое используют после введенных изменений кода / системы. Например, при добавлении новой функциональности, изменении конфигурации, обновлении. Цель регрессионного тестирования - убедиться, что изменения и исправления ошибок не порождают в системе новые ошибки. Тестируют измененные модули (модульное тестирование), связанные с ними модули и функциональность всей системы (функциональное тестирование). Основным методом является повторный запуск уже используемых тестов с тем, чтобы убедиться, что система работает, старые ошибки не повторяются, и не возникают новые. В случае регрессионного тестирования полезно автоматизировать работу для уменьшения общей рабочей нагрузки.

Тестирование производительности и нагрузочные тесты предназначены для проверки соответствия данной системы техническим требованиям. Тестирование производительности можно проводить несколькими способами - путем измерения производительности каждого компонента, либо экспериментируя с большой совокупностью тестовых данных при обычном использовании системы. Цель тестов производительности - распознать критические места, где может возникнуть перегрузка и потратить время на оптимизацию этих мест.

 

 

49.Тестирование производительности

Увеличение числа пользователей и объёма обрабатываемой информации ставит вопрос о стабильности работы приложения под нагрузкой. Тестирование производительности исследует этот вопрос в разных аспектах, позволяя найти узкие места системы, которые могут привести к её нестабильной работе или отказу.

Комплекс работ по тестированию производительности позволяет спрогнозировать появление проблем и заранее планировать методы их предупреждения.

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

В зависимости от исследуемых характеристик системы тестирование производительности подразделяется на несколько типов:

На начальном этапе выясняются цели тестирования, затем выбираются виды тестирования. После подготовки идёт проектирование модели нагрузки, затем решается проблема выбора инструментальных средств автоматизации тестирования производительности.

 

 

50.Нагрузочное тестирование

Современное программное обеспечение просто обязано бесперебойно работать под колоссальными нагрузками. Любого рода проблемы, связанные с плохой производительностью, могут стать причиной отказа клиентов от использования вашего ПО. В связи с этим, проведение качественного нагрузочного тестирования должно стать обязательным, для обеспечения стабильности работы ваших приложений.

Нагрузочное тестирование (Load Testing) или тестирование производительности (Performance Testing) - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.

Начиная работу в области нагрузочного тестирования, следует четко понимать, что это не просто запись и прогон (Record and Playback) скриптов, а более сложный процесс:

• Во-первых, нагрузочное тестирование - это серьезная исследовательская и аналитическая работа
• Во-вторых - это реальное автоматизированное тестирование, требующее серьезных навыков программирования, а также знания сетевых протоколов и различных серверов приложений и баз данных
• В-третьих - существуют разные виды нагрузочного тестирования, ставящие перед собой разные цели

 

 

Требования к ПО

 

Виды требований по уровням

 

· Бизнес – требования определяют назначение ПО, описываются в документе о видении(vision) и границах проекта(scope).

· Пользовательские требования - определяют набор пользовательских задач, которые должна решать программа, а так же способы (сценарии) их решать в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй(user story), сценариев взаимодействия.

· Функциональные требования – охватывают предполагаемое поведение системы, определяя действия которые система способна выполнять. Описывается в системной спецификации.

 

Виды требований по характеру

 

· Функциональный характер — требования к поведению системы

· Бизнес-требования

· Пользовательские требования

· Функциональные требования

· Нефункциональный характер — требования к характеру поведения системы

· Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойствавтоматизируемого объекта (предприятия)

· Системные требования и ограничения — определения элементарных операций, которые должна иметьсистема, а также различных условий, которым она может удовлетворять. К системным ограничениямотносятся ограничения на программные интерфейсы, требования к атрибутам качества, требования кприменяемому оборудованию и ПО.

· Атрибуты качества

· Внешние системы и интерфейсы

· Ограничения

 

 

52. Анализ требований

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

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

 

Анализ требований включает три вида деятельности:

 

Выявление требований: задача коммуникации с пользователями для определения их требований. Также это называют сбором требований.

Анализ требований: выявление недостатков требований (неточностей, неполноты, неоднозначностей или противоречий) и их исправления.

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

Анализ требований может быть долгим и трудным процессом требующая использования тонких психологических навыков. Новые системы меняют среду и отношение между людьми, поэтому важно распознать все заинтересованные стороны, учесть все их потребности, и убедиться что они понимают последствия которые приносит новая система. Аналитики могут использовать несколько методов чтобы получить от потребителя требования. Исторически это включает проведение интервью, или фокус-групп (которую в этом контексте чаще называют как мастерская требований) и создание списков требований. К современных подходов относят прототипирования, и прецеденты. При необходимости аналитик использует комбинацию этих методов чтобы установить точные требования заинтересованных сторон, так чтобы система отвечала бизнес-потребностям.

 

53. Типы ошибок в требованиях

Типы ошибок в требованиях напрямую вытекают из требований

• Полнота и соответствие действительности. Любые требования должны содержать описание именно той функциональности, которая присутствует в приложении. И данное описание должно касаться абсолютно всей функциональности, а не только наиболее значимой.

• При написании требований следует использовать ясную простую краткую и последовательную речь. В частности, следует быть внемательным при умотреблении таких слов, как “shall” (т.е. обязательно), “should” (т.е. желательно), and “must” (лучше избегать или использовать как синоним для ”shall”)

• Требования должны быть написаны ясно и четко, чтобы избежать многочисленных и неоднозначных толкований.

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

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

• Инструкции должны присутствовать везде. Даже при выполнении абсолютно одинаковых манипуляций с программой – необходимо пошаговое описание действий во всех случаях. Это может быть, как и прямое повторение инструкций, так и ссылка на уже существующие.

• Термины и их значение. В любых требованиях может использоваться масса терминов, аббревиатур и сокращений. Каждый из этих сущностей должно иметь свое значение и расшифровку.

• Если требования созданы и для иностранных специалистов – необходимо привлечение работников данного лингвистического сектора, вплоть до носителей языка.

54. Тест-кейсы. Структура. Проектирование

Test Case – это тестовый артефакт, суть которого заключается в выполнении некоторого количества действий и/или условий, необходимых для проверки определенной функциональности разрабатываемой программной системы.

Структура данного артефакта заключается в «троице»:

Выполняемое действие (Action) – Ожидаемый результат (Expected result) – Фактический результат (Test result).

Непосредственно сам тестовый случай состоит из 3 частей:

• PreConditions (Предусловия) – либо список шагов, которые приводят проверяемую систему в состояние, пригодное для тестирования, либо список проверок условий того, что система уже находиться в необходимом состоянии.

• Test Case Description (Описание тестового случая) – список действий, с помощью которых осуществляется основная проверка функционала (после которой и сверяется фактический результат с ожидаемым).

• PostConditions (Постусловия) –список действий, которые возвращают систему в исходное состояние.

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

Написание тест кейсов на основе спецификации требований

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