Мои Конспекты
Главная | Обратная связь

...

Автомобили
Астрономия
Биология
География
Дом и сад
Другие языки
Другое
Информатика
История
Культура
Литература
Логика
Математика
Медицина
Металлургия
Механика
Образование
Охрана труда
Педагогика
Политика
Право
Психология
Религия
Риторика
Социология
Спорт
Строительство
Технология
Туризм
Физика
Философия
Финансы
Химия
Черчение
Экология
Экономика
Электроника

Стадии тестирования





Помощь в ✍️ написании работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

§ Введение

§ Обработка входной документации

§ Разработка рабочей документации

§ Test cycle (непосредственное тестирование)

§ Test outcome (результаты)

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

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

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

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

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

 

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

 

• Тестер должен хорошо изучить тестируемую программу (здесь многое зависит от документооборота между ним и разработчиком).

 

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

 

• Тестер должен уметь пользоваться специальным ПО для тестирования, в том числе автоматизированного.

 

• Тестер должен уметь писать, читать, а иногда и рисовать.

Баг (bug) – это отклонение фактического результата (actual result) от ожидаемого результата (expected result)

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

Тип ошибки (Type)

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

GUI – ошибка, затрагивающая графический интерфейс пользователя, его дизайн.

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

Setup – баги при инсталляции и настройке программы.

Documentation – ошибки в документации.

Серьезность ошибки (Severity)

Cosmetic – ошибка дизайна графического интерфейса (например, не тот цвет линии или шрифт), такая ошибка не мешает программе работать, но портит ее «товарный вид».

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

Major – ошибка, которую не стоит игнорировать, так как она заметно влияет на работу программы.

Critical – серьезная ошибка, способная «повесить» программу или лишить ее важной функциональности.

Causes crash – очень серьезная ошибка, которая может привести к краху системы.

Приоритет ошибки (Priority)

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

Low – приоритет низкий, не требует срочного исправления, возможно «откладывание» исправления на определенный срок.

Medium / Normal – приоритет данной ошибки является нормальным (срочность исправления оценивается самим разработчиком). Исправляется в порядке основной очереди.

High – требует срочного, иногда немедленного исправления.

Стиль названий приоритетов может быть и таким:

ASAP (as soon as possible) – исправление требуется так скоро, как это возможно. Обычно это равнозначно Medium или Normal.

Before next build – ошибку нужно исправить до следующей сборки программы.

Before release 2 – ошибку нужно исправить до выпуска версии 2.

Статус ошибки (Status)

В практике чаще всего используются следующие статусы ошибки:

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

Ошибка переходит в состояние Assigned (назначена) когда исправление поручено конкретному лицу (разработчику). По мере работы, этот разработчик может переадресовать ошибку другому разработчику, который, например, знает данную часть системы лучше. К сожалению, иногда это порождает ситуации, когда ошибка «плутает» от одного разработчика к другому.

Когда разработчик ошибку исправляет, ее статус превращается разработчиком в Resolved / Fixed (исправлена). В этом случае тестировщик обязан перепроверить факт исправления.

В случае, если ошибка изначально не повторяется на стороне разработчика (по его мнению, ошибки нет), он превращает ее статус в Rejected (отклонена)и «переправляет» тестировщику обратно (с комментариями своего решения).

Если тестировщик получает «свою» ошибку со статусом rejected, он обязан перепроверить ее, после чего или закрывает ошибку, или присваивает ей статус Re-Open (открыта заново), когда ошибка все же существует (но ему следует улучшить описание ошибки, чтобы разработчик ее, наконец, обнаружил). Также этот статус получает ошибка, которая была объявлена как fixed, но при перепроверке оказалась не исправленной вследствие тех или иных причин.

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

In Process / Open (в процессе) – ошибка зарегистрирована и принята, сообщение разработчиком прочитано, понято (или обсуждено), работа над ошибкой ведется.

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

Cannot Reproduce (невозможно воспроизвести) – часто аналогично rejected, статус ошибки, которая воспроизводится у тестировщика, но не воспроизводится у разработчика (или наоборот) по ряду причин.

Deferred / Postponed (отложена) – исправление ошибки отложено до выхода новой версии, обновления версии или на определенный/неопределенный срок.

Verified, Closed (проверена и закрыта) – статус тех ошибок, которые были исправлены разработчиком, и этот факт подтвержден тестировщиком.

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

Will not be fixed (не будет исправлена) – ошибка, которая по различным причинам не может быть исправлена ответственным за нее разработчиком. Такой статус требует аргументированного комментария разработчика.

Not a bug (не баг) – ошибка на самом деле ею не является. Как правило, это касается тех особенностей программы, которые не были описаны в документации и были восприняты тестировщиком как ошибки.

Verified (исправление подтверждено) – ошибка исправлена и перепроверена тестировщиком, однако пока не закрыта (например, историю ошибки должен изучить еще кто-то перед тем, как она будет закрыта).

Closed (закрыта) ошибка исправлена, перепроверена, исправленный код помещен на живую систему, или выпущен новый билд (сборка). Запись об ошибке отправляется в архив.

Тест – это исполнение части программы с целью верифицировать (проверить) отдельный ее компонент на предмет содержания ошибок. Большие составные тесты могут дробиться на простые, которые проверяют буквально один так называемый тестовый случай (test case), такой как поведение надписи при наведении указателя мышки или внешний вид кнопки в нажатом состоянии, или, скажем, звук сворачивающегося окна. По мере готовности объекта тестирования большие тесты могут включать в себя уже более сложные действия, которые в будущем будет выполнять конечный пользователь, – так называемые случаи применения (use cases). Это могут быть логически отделяемые задачи: набрать номер на клавиатуре телефона, открыть файл для редактирования, сделать заказ на сайте и т.д.

 

Обычно тесты проектируются и описываются в документации самими тестировщиками.

Тесты можно классифицировать следующим образом:

 

GUI-тесты (тестирование графического интерфейса пользователя). Т.е. тестирование интерфейса – экранов, кнопок и т.д. Большая часть функциональности ПО реализуется, как правило, через пользовательский интерфейс.

Функциональное тестирование. Подразумевает воспроизведение действий пользователя для решения поставленной задачи с проверкой реакции ПО на эти действия.

Тестирование производительности. Т.е. тестирование ПО в имитационной и реальной средах.

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

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

Производственные тесты (профилактические). Цель – убедиться, что за время эксплуатации не произошло никаких ухудшений в работе системы с точки зрения производительности или функциональности («предполетные испытания»).

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

Тест-кейс – это минимальный элемент тестирования. Хороший тест-кейс состоит из трех частей:

1) привести тестируемый продукт в нужное состояние;

2) верифицировать то, что подлежит проверке;

3) привести продукт в исходное состояние.

Существенно то, что акт верификации только один. Именно поэтому тест-кейс нельзя раздробить, разбить на несколько тест-кейсов. Именно поэтому он является минимальным элементом проверки. Если верификаций больше, чем одна, то это не очень правильный тест-кейс.

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

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

Зачастую путают тестирование и обеспечение качества, причем как у нас, так и за рубежом.

QUALITY CONTROL (QC, контроль качества) измеряет качество продукта, а
QUALITY ASSURANCE (QA, гарантия качества) измеряет качество процессов, используемых для создания качественных продуктов. Тестирование (QC) имеет дело только с качеством продукта, а вся система качества включает в себя также и обеспечение качества процессов (QA), применяемых в производстве. Однако на практике тестирование часто вместо QC обозначается тоже QA, это, похоже, стало уже традицией.

Стандарт качества ISO 9000/2000 определяет, что процесс проверки продукта на соответствие входным данным (требованиям, спецификациям) называется верификацией, а валидация – это проверка продукции на соответствие потребностям пользователя. Другими словами, верификация отвечает на вопрос «правильно ли мы делаем работу?», а валидация – «правильную ли работу мы делаем?».

Верификация происходит при помощи статических методов, валидация – динамических. При статических методах программный код не исполняется, тестирование производится при помощи группы методов STR (Software Technical Reviews), то есть, тестируется документация. При динамических программа запускается на выполнение, тестирование происходит по методу, так называемых, «черного ящика» (код программы закрыт и не нужен для тестировщиков) или «белого ящика» (тестировщику необходимо вникать в технологии и код).


 

Software Development Process – структура наложенная на разработку ПО. (Wikipedia)

 

Процессы разработки ПО состоят из множества этапов. Ниже приведены самые основные активности, которые расположены в последовательности «водопадного» процесса (Waterfall process). Последовательность этапов в других процессах может быть изменена.

Доверь свою работу ✍️ кандидату наук!
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой



Поиск по сайту:







©2015-2020 mykonspekts.ru Все права принадлежат авторам размещенных материалов.