Файл: Отчет по практике студента Круглова Анастасия Александровна Курс 4.docx
Добавлен: 11.12.2023
Просмотров: 756
Скачиваний: 25
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Разработка тест-кейса
Тест-кейс — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определённой цели или тестового условия, таких как выполнения определённого пути программы или же для проверки соответствия определённому требованию.
Определение тест-кейса языком обывателя:
Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат.
Правила написания тест-кейсов
Заголовок:
-
должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса; -
не может содержать выполняемые шаги и ожидаемый результат.
Предусловие:
-
может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса; -
может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…); -
не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии; -
не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии; -
не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»; -
не может содержать ожидаемый результат.
Шаги проверки:
-
должны быть чёткими, понятными и последовательными; -
следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12». -
Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»; -
должны использоваться безличные глаголы. -
Правильно: нажать, ввести, перейти. -
Неправильно: нажмите, введите, идите; -
не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё; -
не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида.
Ожидаемый результат:
-
должен быть у каждого шага проверки; -
должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага; -
не должно быть избыточного описания.
Общие требования к тест-кейсам:
-
язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц; -
тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще); -
тест-кейсы группируются в функциональные блоки по их назначению; -
в тест-кейсах, проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы, проверяющие отображение страниц и форм.
На самом деле правила простые, однако их не так-то просто соблюдать. Если же придерживаться данных правил, то тест-кейсы будут легко поддерживаемыми, легко читаемыми, не будут вызывать отторжения и могут быть использованы всеми участниками команды в процессе разработки программного обеспечения.
2.4 ОПИСАНИЕ ДЕФЕКТОВ. ЖИЗНЕННЫЙ ЦИКЛ ДЕФЕКТОВ
Программная ошибка – это изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программы и фактических.
Дефект – это ошибка или неточность, которая может быть (может и не быть) следствием сбоя в работе программы.
Дефект – это поведение программы, затрудняющее, или делающее невозможным достижение целей пользователя или удовлетворение интересов участников.
Дефект – это несоответствие требованиям или функциональным спецификациям.
Где можно найти баги:
-
Требования -
Архитектурная документация -
Код -
Дизайн
Кто может обнаружить дефект:
-
Программист -
Тестировщик -
Технический писатель -
Менеджер проекта
После обнаружения дефекта составляется отчет об ошибке. Отчет об ошибке – это технический документ, который составляется с целью:
-
Предоставить информацию о проблеме, ее свойствах и последствиях. -
Классифицировать проблему по важности и скорости устранения. -
Помочь программистам обнаружить и устранить источник проблемы.
Отчет об ошибке (баг-репорт) – это один из основных результатов работы тестировшика.
Формула хорошего баг-репорта:
-
Что мы сделали? -
Что получили? -
Что должны были получить?
Жизненный цикл дефекта:
-
Обнаружен -
Назначен -
Исправлен -
Проверен -
Закрыт/открыт заново
Атрибуты отчета о дефекте:
-
Идентификатор -
Дата -
Краткое описание (что, где и при каких условиях) -
Подробное описание (ожидаемый результат, фактический результат, ссылка на требование) -
Шаги воспроизведения (1. Перейти по ссылке www.omg.org 2. Ввести в поле «логин» значение «admin» 3. Ввести в поле «пароль» значение «abcd» 4. Кликнуть левой кнопкой мыши по кнопке войти. Баг: В левом верхнем углу вместо логотипа пустое место.) -
Воспроизводимость (указывается частота воспроизведения дефекта (всегда или иногда)) (пройти шаги воспроизведения минимум три раза). -
Важность (на сколько серьезна ошибка). Критическая - дефекты вызывают крах системы, либо повреждения данных. Высокая - серьезные ошибки, например, потеря данных пользователя, падение некоторой части функциональности программы, падение браузера. Средняя – ошибки, затрагивающие функции приложения, но их можно обойти. Низкая – ошибки, не мешающие работе с приложением (опечатки). -
Срочность (как быстро необходимо исправить ошибку). Наивысшая присваивается ошибка, наличие которых делает невозможной дальнейшую работу над проектом. Высшая – нужно исправить в самое ближайшее время. Обычная – исправляется в порядке общей очереди. Низкая – если остается время. -
Симптом. Косметический дефект (опечатки, поврежденные картинки, не тот шрифт и т.д.). Повреждения/потеря данных. Проблема в документации. Некорректная операция. Проблема инсталляции. Ошибка локализации. Нереализованная функциональность. Низкая производительность. Крах системы. Неожиданное поведение. Недружественное поведение. Расхождение с требованием, под этот симптом попадает почти любая ошибка, но рекомендуется его писать только тогда, когда другие симптомы не подходят. Предложения по улучшению. Дополнительные атрибуты: возможность обойти баг, дополнительная информация и приложения (скриншот, видео).
Преимущества хорошего отчета об ошибках:
Хороший отчет об ошибках помогает сократить количество ошибок, отклоненных, или открытых заново. Ускорить устранение ошибки. Сократить стоимость исправления ошибки. Повысить репутацию тестировщика.
Баг-трекинговые системы
Система отслеживания ошибок (англ. bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки и неполадки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.
Главный компонент такой системы — база данных, содержащая сведения об обнаруженных дефектах. Эти сведения могут включать в себя:
-
Номер (идентификатор) дефекта; -
Короткое описание дефекта; -
Кто сообщил о дефекте; -
Дата и время, когда был обнаружен дефект; -
Версия продукта, в которой обнаружен дефект; -
Серьёзность (критичность) дефекта и приоритет решения[1]; -
Описание шагов для выявления дефекта (воспроизведения неправильного поведения программы); -
Ожидаемый результат и фактический результат; -
Кто ответственен за устранение дефекта; -
Обсуждение возможных решений и их последствий; -
Текущее состояние (статус) дефекта; -
Версия продукта, в которой дефект исправлен.
Кроме того, развитые системы предоставляют возможность прикреплять файлы, помогающие описать проблему (например, дамп памяти или скриншот).
TRELLO – построена на основе доски, все функции находятся на одном экране. Слишком простая и не предназначена для больших команд. Задачи не имеют номера, что затрудняет контроль.
YouTrack – доска и диаграмма очень удобные, статусы и приоритеты можно выделять для наглядности.
JIRA AGILE – данную систему называют «№1». Она обладает наиболее широкой функциональностью среди других систем. Идеально подходит для крупных проектов с большим штатом тестировщиков, одновременно можно работать под различными операционными системами, создавать и вести схемы безопасности для каждого из проектов.
TARGETPROCESS – система очень дорогая. Доска удобная, размещение задач сделано по принципу trello, приспособлено к большим командам и большому количеству задач. Разработчики ставили цель сделать программу более простой и удобной в использовании, но количество функций урезали.
Процесс баг-трекинга
-
Создаваясь, сообщение, обязательно имеет ответственного -
Каждому дефекту определяется приоритет важности, возможно добавить комментарий -
Сообщениям устанавливаются статусы «в процессе», где указывается время начала и окончания работы.
3 ОРГАНИЗАЦИЯ ТЕСТИРОВАНИЯ ПО
3.1 МОДУЛЬНОЕ ТЕСТИРОВАНИЕ
Задачи и цели модульного тестирования
Каждая сложная программная система состоит из отдельных частей - модулей, выполняющих ту или иную функцию в составе системы. Для того, чтобы удостовериться в корректной работе всей системы, необходимо вначале протестировать каждый модуль системы по отдельности. В случае возникновения проблем при тестировании системы в целом это позволяет проще выявить модули, вызвавшие проблему, и устранить соответствующие дефекты в них. Такое тестирование модулей по отдельности получило называние модульного тестирования (unit testing).
Для каждого модуля, подвергаемого тестированию, разрабатывается тестовое окружение, включающее в себя драйвер и заглушки, готовятся тест-требования и тест-планы, описывающие конкретные тестовые примеры [18].
Основная цель модульного тестирования - удостовериться в соответствии требованиям каждого отдельного модуля системы перед тем, как будет произведена его интеграция в состав системы.
При этом в ходе модульного тестирования решаются следующие основные задачи:
-
Поиск и документирование несоответствий требованиям -
Поддержка разработки и рефакторинга низкоуровневой архитектуры системы и межмодульного взаимодействия -
Поддержка рефакторинга модулей -
Поддержка устранения дефектов и отладки -
Первая задача - классическая задача тестирования, включающая в себя не только разработку тестового окружения и тестовых примеров, но и выполнение тестов, протоколирование результатов выполнения, составление отчетов о проблемах.
Вторая задача больше свойственна "легким" методологиям типа XP, где применяется принцип тестирования перед разработкой (Test-driven development), при котором основным источником требований для программного модуля является тест, написанный до реализации самого модуля. Однако, даже при классической схеме тестирования модульные тесты могут выявить проблемы в дизайне системы и нелогичные или запутанные механизмы работы с модулем.