Реферат, тестировщик, кто это. Лекция Введение в тестирования
 Скачать 406.08 Kb.
|
|
Лекция 1. Введение в тестирования Тестировщик – опытный специалист, принимающий участие в тестировании компонента или системы. В его обязанность входит поиск вероятных ошибок и сбоев в функционировании объекта тестирования (продукта, программы, и т.д.). Тестировщик моделирует различные ситуации, которые могут возникнуть в процессе использования предмета тестирования, чтобы разработчики смогли исправить обнаруженные ошибки. Тестирование программного обеспечения — процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определенным образом. Цели тестирования: • предоставление информации о качестве ПО конечному заказчику; • повышение качества ПО; • предотвращение появления дефектов. Задача тестирования: • поиск дефектов. Принципы тестирования: 1. Тестирование демонстрирует наличие дефектов. Оно может показать, что дефекты есть, но не может доказать, что их нет. 2. Исчерпывающее тестирование невозможно. Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо. 3. Ранее тестирование. Чтобы как можно раньше найти дефекты, нужно как можно раньше начать активности по тестированию в жизненном цикле разработки ПО или системы. 4. Скопление дефектов. Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже и реальной плотности дефектов по модулям. 5. Парадокс пестицида. Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев перестанет находить новые дефекты. 6. Тестирование зависит от контекста. Тестирование выполняется по-разному, в зависимости от контекста. 7. Отсутствие ошибок не означает, что система готова к использованию. Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям. Критерии начала тестирования: • готовность проекта и модулей по отдельности • законченность разработки требуемого функционала • наличие необходимой документации. Критерии окончания тестирования: • полное тестовое покрытие • результаты тестирования удовлетворяют критериям качества продукта • проверка исправления найденных багов. Лекция 2. Классификация видов тестирования. Классификация по Роману Савину: 1. По знанию внутренностей системы: • черный ящик (black box testing); • серый ящик (grey box testing); • белый ящик (white box testing). 2. По объекту тестирования: • функциональное тестирование (functional testing) – один из видов тестирования, направленного на проверку соответствий функциональных требований ПО к его реальным характеристикам. Функции системы дают ответ на вопрос «что делает система?»; • тестирование интерфейса пользователя (UI testing); • тестирование локализации (localization testing); • тестирование скорости и надежности (load/stress/performance • testing); • тестирование безопасности (security testing); • тестирование опыта пользователя (usability testing); • тестирование совместимости (compatibility testing). 3. По субъекту тестирования: • альфа-тестировщик (alpha tester); • бета-тестировщик (beta tester). 4. По времени проведения тестирования: • до передачи пользователю — альфа-тестирование (alphatesting); • тест приемки (smoke test, sanity test или confidence test) – как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции; • тестирование новых функциональностей (new feature testing); • регрессионное тестирование (regression testing) – это вид тестирования, направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает, как и прежде; • тест сдачи (acceptance or certification test); • после передачи пользователю — бета-тестирование (beta testing). 5. По критерию "позитивности" сценариев: • позитивное тестирование (positive testing) – это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы.; • негативное тестирование (negative testing) – тестирование, в рамках которого применяются сценарии, которые соответствуют внештатному поведению тестируемой системы. 6. По степени изолированности тестируемых компонентов или по уровням тестирования: • компонентное тестирование (component testing) – тестирование каждой атомарной функциональности приложения отдельно, в искусственно созданной среде; • интеграционное тестирование (integration testing) –вид тестирования, при котором на соответствие требований проверяется интеграция модулей, их взаимодействие между собой, а также интеграция подсистем в одну общую систему; • системное (или энд-ту-энд) тестирование (system or end to-end testing) – это тестирование программного обеспечения выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям, как функциональным, так и не функциональным. 7. По степени автоматизированности тестирования: • ручное тестирование (manual testing); • автоматизированное тестирование (automated testing). Лекция 3. Баги и баг-репорты Дефект (он же баг) – это несоответствие фактического результата выполнения программы ожидаемому результату. Дефекты обнаруживаются на этапе тестирования программного обеспечения (ПО), когда тестировщик проводит сравнение полученных результатов работы программы (компонента или дизайна) с ожидаемым результатом, описанным в спецификации требований. Жизненный цикл дефекта представлен на рис.1. Рисунок 1. Жизненный цикл дефекта Баг-репорт – это технический документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата. Атрибуты баг-репорта: • Summary (Тема); • Description1 (Подробное описание); • Steps (Way) To Reproduce (Шаги для воспроизведения); • Actual/Expected Result (Результаты); • Attachments (Вложения); • Priority (Приоритет дефекта); • Severity (Серьезность дефекта); • Status (Статус); • Component (Компонент) или Environment (Среда); • Fix Version (Версия); • Assignee (Назначение); • Build (Номер сборки); • Lable (Лейбл). Принципы составления баг-репорта: • Должен отвечать на вопросы: Где? Что? Когда? • Должен быть написан в настоящем времени. • Должен быть обезличенным. • Должен быть написан грамотно и понятно. • Не должны присутствовать слова: (не)правильно, (не)корректно, (не)верно. Лекция 4. Чек-листы Чек-лист – это список, содержащий ряд необходимых проверок во время тестирования программного продукта. Отмечая пункты списка, команда или один тестировщик могут узнать о текущем состоянии выполненной работы и о качестве продукта. Атрибуты чек-листа: • название проверки; • статус проверки; • ссылка на баг; • название устройства/браузера/версии; • фамилия разработчика. Правила составления чек-листа: • Один пункт – одна операция. • Единообразное оформление. • Составление чек-листа по уровням детализации. Лекция 5. Тест план и тест-кейс Тест-план (Test Plan) – это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Тест-кейс – это тестовый артефакт, суть которого заключается в выполнении некоторого количества действий и/или условий, необходимых для проверки определенной функциональности разрабатываемой программной системы. Атрибуты тест-кейса: • уникальный идентификатор тест-кейса – ID; • название – case; • предусловия – precondition; • шаги – steps; • ожидаемый результат – expected result. Набор тест-кейсов называется тестовым набором (test suite). Что не должно быть в тест-кейсе: • Зависимостей от других тест-кейсов; • Нечеткой формулировки шагов или ожидаемого результата; • Отсутствия необходимой для прохождения тест-кейса информации; • Излишней детализации. |