Технологии тестирования на основе рисков

Понятие чеклистов

 

Что такое чек-лист?

Чек-лист (check list)— это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта.

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

Зачем нужен чек-лист?

· Не забыть что-то протестировать.

· Помогает осуществлять контроль за тестированием.

Что должно быть в чек-листе?

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

Пример:

 

25. Факторы, влияющие на конечный результат ревью

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

Технические факторы

Технические факторы, влияющие на успех review включают в себя:

· Убедитесь, что определенный процесс для типа review следует правильно, особенно для более формальных типов review.

· Запишите расходы review, в том числе время, проведенное, и те преимущества, которые получает организация.

· Просмотрите ранние проекты или частичное документы. Это может помочь выявить и предотвратить модели дефектов, прежде чем они встроены в весь документ

· Следуя правилам

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

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

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

· Просмотрите или проверьте документы, на которых есть важные решения.

· Для больших документов, образец ограниченное подмножество

Организационные факторы

Организационные факторы, влияющие на успех отзывы включают в себя:

· Вопросы управления

· Нужен лидер, тот, кто будет вести процесс над проектом или организационном уровне. В него должен быть опыт, энтузиазм и практический склад ума для того, чтобы направлять модераторов и участников. Ее власть должна быть ясно всей организации

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

· Документы должны быть выбраны для review, которые наиболее важны в проекте

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

· Убедитесь, что процесс совершенствования процесса обзора включает в себя механизм, чтобы признать и праздновать достигнутого повышения

 

 

26. Тестирование, основанное на структуре

Тестирование, основаное на структуре, так же известно как white-box или code-based test techniques, является тестированием, в котором код, данные, архитектуру или потом систем используется в качестве базы для получения динамических тест-кейсов, что образуют структуру. Проще говоря, данный метод тестирование предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику. Выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех особенностей тестируемой программы и ее реализации – обязательны для этой техники.

 

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

Метод белого ящика используется для изучения системы или компонента структуры на нескольких уровнях:

· Уровень компонента: интересующие структуры это структуры компонент, структуры программного обеспечения, то есть заявления, решения, филиалы или даже отдельные дорожки

· Уровень интеграции: интересующие структуры могут быть вызывающими структуру (например, дерево вызовов, схема, в которой модули вызывают другие модули); мы можем быть заинтересованы в изучении способов взаимодействия компонент друг с другом

· Системный уровень: интересующей структурой может быть структура меню, бизнес-процесс или структура веб-страницы

 

Общие черты методов основываются на:

1. Информации о том, как построенное ПО используется для получения тест-кейсов.

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

Преимущества:

– тестирование может производиться на ранних этапах: нет необходимости ждать создания пользовательского интерфейса;

– можно провести более тщательное тестирование, с покрытием большого количества путей выполнения программы.

Недостатки:

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

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

 

 

27. Покрытие тестами

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

Тестовое покрытие можно посчитать с помощью следующей формулы:

 

 

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

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

Существуют следущие подходы к оценке и измерению тестового покрытия:

 

Покрытие требований (Requirements Coverage) - оценка покрытия тестами функциональных и нефункциональных требований к продукту путем построения матриц трассировки

Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей программного обеспечения.

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

Различия:

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

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

Метод оценки покрытия кода не выявит нереализованные требования, так как работает не с конечным продуктом, а с существующим исходным кодом.

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

 

28. Типы покрытия (покрытие выражений, покрытие условий, покрытие веток, покрытие решений, т.п.)

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

· Интеграционный уровень. Мы может измерить покрытие интерфейсов или определенных взаимодействий, которые были протестированы. Покрытие вызова модуля, объективных/процедурных вызовов, покрытие классов или компонент может быть так же изменено.

· В системном или приемном уровне, элементы покрытия могут быть требованиями, пунктами меню, деловыми сделкам, файлами и элементами баз данных (записи, поля и подполя).

Существуют следующие типы покрытия:

1. Statement testing: Исполняемые(без комментариев и пробелов) выражения определены. Элементы покрытия: выражения.

2. Decision testing: Решенияопределены как if/else, switch/case, for и while. Элементы покрытия: результаты решения.

3. Branch testing: Ветки, определены как if/else, switch/case, for и while. Покрытие условий и покрытие веток будут совпадать на 100% покрытии, но будут разными на более низком уровне покрытия, ветки с отдельным покрытием считаются слабыми. Элементы покрытия: ветки.

4. Condition testing: Метки определены как TRUE/FALSE и case (условия которые составляют решения). Элементы покрытия: логические значения операндов.

5. Multiple condition testing: Определены все возможные комбинации TRUE/FALSE для индивидуальных условий внутри всех решений. Элементы покрытия: Комбинации логических значений операндов.

6. Condition determination testing: Определены возможные комбинации результатов для отдельных условий, которые могут влиять на результаты решений. Элементы покрытия: булевы операнд оценивают показания независимо влияющие на решения

7. Path testing: Определены уникальные последовательности операторов (пути). Элементы покрытия: пути.

 

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

 

 

29. Технологии «черного ящика»

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

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

Тестирование черного ящика – это:

– тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы.

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

Почему именно «черный ящик»? Тестируемая программа для тестировщика – как черный непрозрачный ящик, содержания которого он не видит. Целью этой техники является поиск ошибок в таких категориях:

– неправильно реализованные или недостающие функции;

– ошибки интерфейса;

– ошибки в структурах данных или организации доступа к внешним базам данных;

– ошибки поведения или недостаточная производительности системы;

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

Преимущества:

– тестирование производится с позиции конечного пользователя и может помочь обнаружить неточности и противоречия в спецификации;

– тестировщику нет необходимости знать языки программирования и углубляться в особенности реализации программы;

– тестирование может производиться специалистами, независимыми от отдела разработки, что помогает избежать предвзятого отношения;

– можно начинать писать тест-кейсы, как только готова спецификация.

Недостатки:

– тестируется только очень ограниченное количество путей выполнения программы;

– без четкой спецификации (а это скорее реальность на многих проектах) достаточно трудно составить эффективные тест-кейсы;

– некоторые тесты могут оказаться избыточными, если они уже были проведены разработчиком на уровне модульного тестирования;

Противоположностью техники черного ящика является тестирование методом белого ящика.

 

 

30. Классы эквивалентности

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

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

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

Что бы избежать бесполезного тестирования, следует разделить область ввода на классы эквивалентности или группы.

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

Из каждого класса эквивалентности следует выбрать один тест, который будет представлять данный класс

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

 

 

Анализ граничных значений

 

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

 

Основная модель для отыскания граничных значений является математической, которая идентифицирует два граничных значения на границе между одним классом эквивалентности и другим. Граничные значения появляются на стыке классов эквивалентности где система меняет свое поведение. Если граничные значения являются членами действующего класса эквивалентности, они являются are valid boundary values, но если члены есть недействительным класса эквивалентности, они invalid boundary values.

 

Пример:

Есть простой скрипт или программа, которая предлагает нам ввести возраст человека в текстовое поле вместимостью в 2 символа и что ниже находится кнопка для отправки данных. Результат данной программы должна быть стоимость мед страховки в зависимости от той цифры, которую мы введем. В соответствии с функциональной спецификацией все возраста разделили на четыре категории. Первая это Дети (включает от 0 до 12 лет), Вторая категория это Подростки (включает от 13 до 17 лет), Третья категория это Взрослые (включает от 18 до 59 лет), и последняя Четвёртая категория это Пенсионеры (включает от 60 до 99 лет). В зависимости от категории к которой относится человек, будет вычисляться стоимость мед страховки:

 

• Дети — 10 у.е. в месяц
• Подростки — 20 у.е. в месяц
• Взрослые — 30 у.е. в месяц
• Пенсионеры — 40 у.е. в месяц

В данном случае все входные данные мы можем разделить на 4 эквивалентных класса. В нашем примере программа позволяет вводить максимум 2 символа и текстовое поле принимает только числа от 0 до 99. Поэтому граничные значения для этого поля -1,0 и 99,100
Но нам нужно также проверить и граничные значения эквивалентных классов, для большей уверенности в качестве нашей программы.

Какие же Граничные значения у наших эквивалентных классов?
В данном случае это 0, 12, 13, 17, 18, 59, 60, 99.

Следовательно чтобы покрыть эквивалентные классы и граничные значения для нашего примера нужно протестировать программу с такими входными данными:
-1, 0, 5, 12, 13, 15, 17, 18, 36, 59, 60, 78, 99, 100

 

32. Таблицы решений

Таблица принятия решений (decision table) – великолепный инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте. В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определенному действию.

Почему стоит использовать?

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

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

 

 

Анализ рисков

 

Риск – это вероятное событие или условие, которое в случае возникновения имеет позитивный или негативный эффект на одно или более свойств проекта – время, стоимость, объем, качество.

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

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

Алгоритм работы с рисками:

 

39. Управление рисками

Управление рисками можно рассматривать как состоящий из трех основных видов деятельности:

1. Идентификация риска: выяснить, что различные проектные и продуктные риски для проекта

2. Анализ рисков: оценка уровня риска для каждого идентифицированного риска

3. Контроль рисков: по смягчение непредвиденных последствий или принятие мер для различных рисков.

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

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

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

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

 

 

Уточнение (Elaboration)

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

· Документирование требований (включая детальное описание для большинства прецедентов).

· Спроектированную, реализованную и оттестированную исполняемую архитектуру.

· Обновленное экономическое обоснование и более точные оценки сроков и стоимости.

· Сниженные основные риски.

Успешное выполнение фазы разработки означает достижение этапа жизненного цикла архитектуры (англ. Lifecycle Architecture Milestone).

Построение (Construction)

В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

Внедрение (Transition)

В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

 

 

Мониторинг и контроль

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

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

 Какие метрики обычно используются для контроля процесса тестирования

 Как составить матрицу отслеживаемости (Traceability Matrix)

Метрики по тест кейсам

Название	Описание
Passed/Failed Test Cases	Метрика показывает результаты прохождения тест кейсов, а именно отношение количества удачно пройденных к завершившимся с ошибками. В идеале, к концу проекта, количество провальных тестов стремиться к нулю
Not Run Test Cases	Метрика показывает количество тест кейсов, которые еще необходимо выполнить в данной фазе тестирования. Имея данную информацию, мы можем проанализировать и выявить причины, по которым тест не были проведены

 

Метрики по багам

Название	Описание
Open/Closed Bugs	Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)
Reopened/Closed Bugs	Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)
Rejected/Opened Bugs	Метрика показывает отношение количества отклоненных багов к открытым
Bugs by Severity	Количество багов по серьезности
Bugs by Priority	Количество багов по приоритету

 

Хотим отметить, что метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. Имея требования к количеству открытых багов, после каждой итерации тестирования мы сравниваем их с реальными данными, тем самым видя места, где нам нужно прибавить, для скорейшего достижения цели.

Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования.

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

1. Требования к функции можно трактовать по разному

2. Тестировщик не точно описал проблему

3. Некачественное поверхностное решение проблемы (фикс бага)

Второй пример покажет для чего необходима метрика "Rejected/Opened Bugs":
Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:

1. Требования к функции можно трактовать по разному

2. Тестировщик не точно описал проблему

3. Разработчик не желает исправлять допущенную им ошибку или не считает, что это на самом деле ошибка. (Эта проблема является прямым следствием 2-ой, возникшей из-за не точного описания)

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

Метрики по задачам

Название	Описание
Deployment tasks	Метрика показывает количество и результаты установок приложения. Процедура установки приложения была описана в статье Процедура проведения установки новой версии ПО (Deployment WorkFlow). В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему.
Still Opened Tasks	Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Под задачами понимаем следующие виды работ: написание документации (архитектура, требования, планы), имплементация новых модули или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и многое другое

 

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

* * *

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

Отчеты о тестировании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

Шапка.

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

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

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

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

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

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

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

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

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

Окружение.

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

Описание.

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

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

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

Дополнения.

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

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

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

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

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

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

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

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

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

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

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