Краткий путеводитель начинающего тестировщика бесплатное чтение
![](/img/b/82503.jpg)
© Дмитрий Самойлов, 2023
ISBN 978-5-0059-8529-3
Создано в интеллектуальной издательской системе Ridero
Введение
Тестирование является важной частью процесса разработки программного обеспечения, которая позволяет выявлять ошибки и дефекты в работе ПО. Каждый тестировщик должен иметь хорошие знания и навыки в области тестирования, чтобы обеспечить высокое качество продукта.
Данная книга является кратким путеводителем для тестировщиков, который поможет им ознакомиться с основами тестирования, методами и инструментами тестирования, а также с процессом тест-планирования и тест-дизайна. Кроме того, в книге описаны особенности тестирования в Agile, приведен краткий обзор автоматизации тестирования и инструментов, обзор тестирования безопасности, производительности и особенностей тестирования мобильных и web приложений.
Книга написана на понятном языке, и ее структура позволяет быстро находить необходимую информацию. Надеюсь, что данный путеводитель будет полезен тем, кто начинает свой путь в тестировании программного обеспечения.
Основные термины и определения
– Тестирование (Testing): процесс проверки соответствия продукта его требованиям и ожиданиям пользователей.
– Тестировщик (Tester): специалист, занимающийся тестированием продукта, отвечающий за обнаружение дефектов и обеспечение качества продукта.
– Качество (Quality): свойство продукта, которое определяет его способность удовлетворять потребности и ожидания пользователей в соответствии с заданными требованиями и стандартами. Качество в тестировании связано с тем, насколько хорошо продукт соответствует его целям и требованиям, а также насколько эффективно он выполняет свои функции и задачи.
– Тест-план (Test Plan): документ, описывающий общий подход к тестированию продукта, содержащий информацию о целях, методах, ресурсах и расписании тестирования.
– Тестовый набор (Test Suite): группа связанных тест-кейсов, которые выполняются последовательно, чтобы проверить определенную функциональность продукта.
– Тестовый сценарий (Test Scenario): последовательность шагов, необходимых для проверки определенной функциональности продукта.
– Тест-кейс (Test Case): набор инструкций для проведения конкретного тестирования и проверки корректной работы определенного функционала продукта.
– Покрытие тестами (Test Coverage): процентное соотношение между количеством выполненных тестовых сценариев или тест-кейсов и общим количеством функциональности продукта, проверяемой в этих тестах.
– Дефект (Defect): отклонение от требований или ожиданий пользователей, обнаруженное в процессе тестирования.
– Баг (Bug): термин, используемый для обозначения дефекта или ошибки в работе программного обеспечения.
– Тестовое окружение (Test Environment): среда, в которой проводится тестирование продукта, включающая в себя программное и аппаратное обеспечение, настройки и конфигурации.
– Регрессионное тестирование (Regression Testing): процесс повторного тестирования уже протестированных функций или участков кода после внесения изменений, чтобы проверить, что изменения не привели к появлению новых дефектов.
– Автоматизированное тестирование (Automated Testing): процесс проведения тестирования с использованием специальных программных инструментов для автоматизации выполнения тестовых сценариев и тест-кейсов.
– Интеграционное тестирование (Integration Testing): процесс проверки работоспособности компонентов системы в совокупности, в том числе взаимодействия между ними.
– Юнит-тестирование (Unit Testing): процесс тестирования отдельных компонентов программного обеспечения (например, функций, классов), чтобы проверить их корректность и работоспособность.
– Тестирование производительности (Performance Testing): процесс тестирования, направленный на оценку работоспособности и производительности продукта, включая проверку его способности обрабатывать большое количество запросов и обеспечивать быстрый отклик.
– Тестирование безопасности (Security Testing): процесс тестирования, направленный на оценку уровня защищенности продукта от внешних угроз, таких как хакерские атаки, вирусы и т. д.
– Тестирование совместимости (Compatibility Testing): процесс тестирования, направленный на проверку работоспособности продукта в различных окружениях и на разных платформах.
– Тестирование пользовательского интерфейса (User Interface Testing): процесс тестирования, направленный на проверку корректности работы пользовательского интерфейса продукта, включая взаимодействие с пользователем и удобство использования.
Основы тестирования
Жизненный цикл разработки ПО
Жизненный цикл разработки ПО (Software Development Life Cycle, SDLC) – это процесс разработки ПО, который включает в себя различные фазы, начиная от анализа требований и заканчивая сопровождением и поддержкой ПО после его внедрения. Жизненный цикл разработки ПО обычно включает следующие основные фазы:
– Анализ требований: определение требований к ПО на основе потребностей заказчика и пользователей, описание функциональных и нефункциональных требований, создание спецификаций требований.
– Проектирование: разработка архитектуры ПО, создание диаграмм и схем, определение функциональности и интерфейсов.
– Разработка: создание кода ПО на основе заданных требований и дизайна, тестирование кода на соответствие требованиям.
– Тестирование: проверка работоспособности ПО на соответствие требованиям, выявление дефектов и ошибок в работе ПО, исправление и повторное тестирование.
– Внедрение: установка ПО на рабочие станции пользователей, настройка и интеграция с другими системами.
– Сопровождение и поддержка: обеспечение работоспособности ПО, исправление ошибок и дефектов, обновление ПО для улучшения его функциональности и совместимости с другими системами.
Важно отметить, что жизненный цикл разработки ПО может варьироваться в зависимости от методологии разработки (например, водопадной, Agile и т.д.) и конкретного проекта. Тестирование является важной частью жизненного цикла разработки ПО, и тестировщики должны уметь эффективно взаимодействовать с разработчиками и другими членами команды в каждой фазе процесса.
Основные постулаты тестирования
Постулаты тестирования – это основные принципы и подходы, которые лежат в основе тестирования программного обеспечения. Вот некоторые из главных постулатов тестирования:
– Полное тестирование невозможно: невозможно провести тестирование, которое охватит все возможные сценарии использования продукта. Поэтому тестировщики должны использовать свой опыт и знания, чтобы выбрать тестовые сценарии, которые наиболее вероятно приведут к проблемам.
– Дефекты накапливаются: в ходе тестирования всегда будут находиться новые дефекты, и количество дефектов может накапливаться со временем. Поэтому тестировщики должны непрерывно тестировать продукт и исправлять найденные проблемы.
– Тестирование не может доказать отсутствие ошибок: тестирование может показать наличие ошибок, но не может гарантировать, что их нет. Тестирование может улучшить качество продукта и уменьшить риск ошибок, но не может исключить их полностью.
– Тестирование зависит от контекста: каждый проект уникален, и контекст тестирования может сильно варьироваться. Тестирование должно учитывать требования и цели проекта, а также особенности окружения, в котором будет использоваться продукт.
– Безусловная вера в тестирование опасна: тестирование не является абсолютным инструментом для обнаружения всех дефектов. Поэтому необходимо использовать и другие методы контроля качества, например, код-ревью и анализ требований.
– Тестирование должно начинаться как можно раньше: тестирование должно начинаться с самого начала разработки продукта и должно включать тестирование на каждом этапе разработки. Это поможет обнаружить проблемы и ошибки раньше, когда они легче исправляются.
– Тестирование должно быть систематическим и документированным: тестирование должно проводиться систематически и документироваться, чтобы обеспечить повторяемость и воспроизводимость результатов тестирования. Это также помогает обеспечить качество продукта и улучшить процесс разработки.
Эти постулаты помогают тестировщикам ориентироваться в работе и сделать процесс тестирования более эффективным.
Классификация видов тестирования
Когда разработчики создают программное обеспечение (ПО), необходимо проводить тестирование, чтобы убедиться в правильной работе приложения и соответствии его функциональным и нефункциональным требованиям. Соответственно, существует два основных вида тестирования ПО: функциональное и нефункциональное.
Функциональное тестирование – это тестирование, которое направлено на то, чтобы убедиться в том, что ПО способно выполнять свои функции и соответствовать функциональным требованиям, установленным для него.
Нефункциональное тестирование включает в себя проверку соответствия нефункциональным требованиям, таким как удобство использования для конечных пользователей, масштабируемость, производительность, безопасность, надежность и др. Виды нефункционального тестирования:
– Тестирование пользовательского интерфейса (UI Testing) – это процесс проверки интерфейса на соответствие заданным требованиям, таким как размер, шрифт, цвет и последовательность действий.
– Тестирование удобства использования (Usability Testing) – это метод проверки, который оценивает удобство использования, обучаемость, понятность и привлекательность продукта для пользователей в соответствии с контекстом использования. Он состоит из UX (User Experience), который описывает взаимодействие пользователя с продуктом, и UI (User Interface), который представляет собой инструмент для взаимодействия между пользователем и веб-ресурсом.
– Тестирование безопасности (Security Testing) – это стратегия, которая используется для проверки безопасности системы и анализа рисков, связанных с защитой приложения от атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным и другими видами угроз.
– Инсталляционное тестирование (Installation Testing) – это проверка успешной установки и настройки, обновления или удаления приложения на различных платформах.
– Конфигурационное тестирование (Configuration Testing) – это специальный вид тестирования, который проверяет работу программного обеспечения в разных конфигурациях системы, включая заявленные платформы, поддерживаемые драйверы и различные конфигурации компьютеров.
– Тестирование на отказ и восстановление (Failover and Recovery Testing) – это проверка, которая оценивает способность продукта успешно восстанавливаться после возникновения сбоев, связанных с ошибками программного обеспечения, отказами оборудования или проблемами связи.
– Тестирование локализации (Localization Testing) – это проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями, включая язык, формат даты и времени, валюту и т. д.
Однако виды тестирования можно классифицировать по различным параметрам. Например:
Классификация тестирования по позитивности сценария:
– Позитивное тестирование – использует только корректные данные для проверки правильности функций приложения.
– Негативное тестирование – использует как корректные, так и некорректные данные для проверки исключительных ситуаций и часто включает некорректные операции.
Классификация тестирования по знанию системы:
– Тестирование белого ящика (White Box) – тестирование ПО с полным доступом к коду проекта, при котором тестировщик знает внутреннюю структуру, устройство и реализацию системы.
– Тестирование серого ящика – метод тестирования ПО, который предполагает частичный доступ к коду проекта, объединяя в себе White Box и Black Box методы.
– Тестирование чёрного ящика (Black Box) – метод тестирования ПО, при котором тестировщик не имеет доступа к внутренней структуре и реализации системы, а основывается на работе с внешним интерфейсом тестируемой системы.
Классификация тестирования по исполнителям тестирования:
– Альфа-тестирование – ранняя версия программного продукта, которая тестируется внутри организации-разработчика, а также может привлекать конечных пользователей для частичного тестирования.
– Бета-тестирование – готовое или практически готовое ПО, которое выпускается для ограниченного числа пользователей для получения отзывов и реакции клиентов на продукт и внесения соответствующих изменений в ПО.
Классификация тестирования по уровню тестирования:
– Модульное (компонентное) тестирование – проводится разработчиками, чтобы проверить отдельные компоненты системы, такие как объекты, классы, функции и т. д. и выявить дефекты в коде.
– Интеграционное тестирование – направлено на проверку корректности взаимодействия между несколькими модулями системы, объединенными в единое целое.
– Системное тестирование – это проверка функциональных и не функциональных требований всей системы в целом, с целью выявления дефектов и оценки качества системы.
– Операционное тестирование – финальный шаг валидации, который проводится в среде эксплуатации для проверки соответствия системы потребностям пользователей и выявления нефункциональных проблем.
Классификация тестирования по исполнению кода:
– Статическое тестирование – это процесс проверки артефактов разработки (кода, документации) путем анализа без его фактического выполнения. Цель этого тестирования – выявить проблемы и ошибки на ранних стадиях разработки, чтобы избежать их в будущем.
– Динамическое тестирование – это проверка работы системы во время ее выполнения, т.е. с запуском программного кода и проверкой его результатов. Этот вид тестирования направлен на проверку функциональности и нахождение проблем, которые могут возникнуть в процессе выполнения.
Классификация тестирования по хронологии выполнения:
– Повторное/подтверждающее тестирование (re-testing/confirmation testing) – это тестирование, при котором запускаются тестовые сценарии, которые выявили ошибки в предыдущем тестовом цикле, с целью подтверждения того, что ошибки были успешно исправлены.
– Регрессионное тестирование (regression testing) – это тестирование, которое проводится после внесения изменений в код приложения, чтобы убедиться, что изменения не вызвали ошибок в неизмененных областях кода. Также проверяется, что исправление ошибок и любые изменения в коде приложения не повлияли на работу других модулей ПО и не вызвали новых ошибок.
– Приемочное тестирование – это проверка соответствия системы требованиям пользователя, бизнес-процессам и потребностям.
Этапы тестирования
Этапы тестирования являются важной частью жизненного цикла разработки ПО. Они позволяют эффективно проверять функциональность ПО, выявлять и исправлять ошибки, а также обеспечивать высокое качество конечного продукта. Ниже перечислены основные этапы тестирования:
– Планирование тестирования: на этом этапе определяются цели тестирования, составляется план тестирования, определяется состав тестовых случаев, определяются критерии окончания тестирования.
– Проектирование тестов: на этом этапе составляются тестовые сценарии, определяются входные данные и ожидаемые результаты для каждого тестового случая.
– Подготовка тестовых данных: на этом этапе создаются тестовые данные, которые будут использоваться при проведении тестирования.
– Выполнение тестов: на этом этапе проводятся тесты в соответствии с планом тестирования. Результаты тестирования записываются и анализируются.
– Анализ результатов тестирования: на этом этапе анализируются результаты тестирования, выявляются ошибки и проблемы, их описывают, классифицируют по уровню серьезности и приоритету.
– Исправление ошибок: на этом этапе исправляются выявленные ошибки и проблемы.
– Повторное тестирование: после исправления ошибок проводится повторное тестирование, чтобы убедиться, что ошибки действительно были исправлены и не появились новые.
– Приемочное тестирование: на этом этапе проводится финальное тестирование, которое выполняется с целью убедиться, что ПО полностью соответствует требованиям заказчика и готово к выходу в эксплуатацию.
Каждый этап тестирования имеет свои специфические особенности и выполняется в определенной последовательности, что позволяет обеспечить высокое качество продукта.
Тест-планирование
Цели и задачи тест-планирования
Цель тест-планирования – определить процесс и стратегию тестирования, которые позволят достичь заданных целей и обеспечить высокое качество конечного продукта.
Основные задачи тест-планирования:
– Определение общей стратегии тестирования: на этом этапе происходит определение подхода к тестированию и выбор методов и техник, которые будут использоваться при тестировании.
– Определение объема тестирования: на этом этапе определяется, какие части системы будут тестироваться, а также какие функциональные и нефункциональные требования должны быть протестированы.
– Определение рисков и приоритетов: на этом этапе происходит анализ возможных рисков и их влияния на систему, а также определение приоритетов для тестирования тех частей системы, которые являются наиболее критическими.
– Определение тестовых сценариев и тест-кейсов: на этом этапе создаются тест-кейсы и определяются тестовые сценарии, которые будут использоваться для проверки системы на соответствие требованиям.
– Определение тестовых данных: на этом этапе производится подготовка тестовых данных, которые будут использоваться при тестировании.
– Определение критериев приемки: на этом этапе происходит определение критериев приемки системы, которые должны быть выполнены, чтобы система была готова к релизу.
– Определение расписания и ресурсов: на этом этапе определяется расписание тестирования и ресурсы, необходимые для его выполнения.
– Определение процесса управления ошибками: на этом этапе происходит определение процесса управления ошибками и дефектами, включая их отслеживание, отчетность и управление жизненным циклом дефектов.
В результате тест-планирования создается план тестирования, который содержит информацию о целях, методах и процессах тестирования, а также о расписании, ресурсах и критериях приемки. Этот план является основным руководством для тестировщиков в процессе выполнения тестирования и позволяет обеспечить высокое качество конечного продукта.
Разработка тест-плана
Разработка тест-плана – это процесс создания документа, который описывает общий план тестирования для проекта. Тест-план является основным документом, который определяет, как будет проводиться тестирование системы, и содержит детальные инструкции для всех этапов тестирования. Он включает в себя следующие этапы:
– Определение целей и задач тестирования: на этом этапе определяются цели тестирования, например, проверка функциональности системы, производительности или безопасности. Также определяются задачи, необходимые для достижения этих целей, такие как создание тест-кейсов, проведение функционального тестирования, нагрузочного тестирования и т. д.
– Определение области тестирования: на этом этапе определяется область тестирования, которую необходимо покрыть в процессе тестирования. Это может быть конкретный функциональный модуль, компонент системы или вся система в целом.
– Определение методов тестирования: на этом этапе выбираются методы тестирования, которые будут использоваться для проведения тестов. Это может быть ручное или автоматизированное тестирование, функциональное или нефункциональное тестирование, нагрузочное тестирование и т. д.
– Определение тестовых сценариев и тест-кейсов: на этом этапе разрабатываются тестовые сценарии и тест-кейсы для проверки функциональности и нефункциональных требований системы. Тест-кейсы должны содержать подробные инструкции для проведения тестов, описывать ожидаемый результат и определять тестовые данные.
– Определение критериев окончания тестирования: на этом этапе определяются критерии, которые будут использоваться для оценки результатов тестирования и определения того, когда тестирование может быть завершено. Критерии могут включать в себя достижение определенного покрытия тестами, отсутствие критических ошибок или удовлетворение определенных требований к качеству.
– Определение графика тестирования: на этом этапе разрабатывается график тестирования, который определяет, когда будут проводиться тесты и какие ресурсы необходимы для проведения тестирования. График должен быть раз работан с учетом сроков проекта и уровня рисков, связанных с проведением тестирования.
– Определение ответственностей: на этом этапе определяются роли и ответственности членов команды тестирования. Например, кто будет разрабатывать тест-кейсы, кто будет проводить тесты и кто будет отчитываться о результатах тестирования.
– Определение ресурсов: на этом этапе определяются ресурсы, необходимые для проведения тестирования, такие как персонал, оборудование и программное обеспечение.
– Оценка рисков: на этом этапе определяются риски, связанные с проведением тестирования, и разрабатываются планы по их управлению.
– Утверждение тест-плана: после того, как тест-план разработан, он должен быть утвержден соответствующими заинтересованными сторонами, такими как руководство проекта, заказчик или команда разработчиков.
Разработка тест-плана – это важный процесс в жизненном цикле разработки ПО, который помогает гарантировать, что тестирование будет проведено в соответствии с требованиями проекта и наилучшими практиками тестирования.
Оценка рисков
Оценка рисков является важной частью процесса тестирования и позволяет определить потенциальные проблемы, которые могут возникнуть во время тестирования, и разработать стратегии по их управлению. Оценка рисков позволяет уменьшить вероятность возникновения проблем и минимизировать их воздействие на проект.
Процесс оценки рисков включает в себя следующие шаги:
– Идентификация рисков: определение потенциальных проблем, которые могут возникнуть во время тестирования. Для этого можно использовать опыт предыдущих проектов, анализ требований, общение с командой разработки и другие источники информации.
– Оценка вероятности возникновения рисков: оценка вероятности того, что каждый потенциальный риск возникнет во время тестирования. Это может быть сделано на основе данных из прошлых проектов, опыта команды и других факторов.
– Оценка влияния рисков: оценка влияния каждого риска на проект, если он произойдет. Например, некоторые риски могут привести к задержке сроков, повышению затрат или к критическим ошибкам в приложении.
– Разработка стратегий управления рисками: разработка плана действий для управления каждым риском. Это может включать в себя разработку запасных планов, увеличение тестового покрытия для конкретных функций, использование инструментов тестирования и т. д.
– Мониторинг и управление рисками: мониторинг и управление рисками во время тестирования. Это может включать в себя регулярный анализ статуса рисков, обновление стратегий управления рисками и другие меры.
Цель оценки рисков – определить и управлять рисками, связанными с тестированием, чтобы минимизировать негативное влияние на проект и улучшить качество продукта. Важно помнить, что оценка рисков – это непрерывный процесс, который должен проводиться на протяжении всего процесса тестирования.
Тест-дизайн
Цели и задачи тест-дизайна
Цель тест-дизайна – разработка тестовых случаев, которые позволят эффективно проверить функциональность программного продукта и обнаружить ошибки. Тест-дизайн является важной частью процесса тестирования и может существенно повлиять на качество продукта.
Основные задачи тест-дизайна включают:
– Разработка тестовых случаев: определение входных данных и ожидаемых результатов для каждого функционала продукта. Это позволяет создать тестовые случаи, которые будут эффективно проверять функциональность продукта и помогать обнаруживать ошибки.
– Определение приоритетов: определение приоритетов для каждого функционала продукта, чтобы определить, какие тесты должны быть выполнены первыми и какие могут быть выполнены позже.
– Определение покрытия: определение покрытия тестами для каждого функционала продукта. Это позволяет определить, как много тестов необходимо выполнить для каждого функционала, чтобы быть уверенным, что она работает правильно.
– Создание тестовых данных: создание набора тестовых данных, которые будут использоваться для выполнения тестовых случаев. Тестовые данные должны быть достаточно разнообразными, чтобы проверить различные варианты использования продукта.
– Определение ожидаемых результатов: определение ожидаемых результатов для каждого тестового случая. Это позволяет определить, работает ли продукт правильно и соответствует ли он требованиям.
– Проверка тестовых случаев: проверка тестовых случаев, чтобы убедиться, что они покрывают все функции продукта и соответствуют требованиям.
– Обновление тестовых случаев: обновление тестовых случаев при изменении требований или функций продукта.
Цели и задачи тест-дизайна направлены на создание тестовых случаев, которые эффективно проверяют функциональность продукта и помогают обнаруживать ошибки. Хороший тест-дизайн может значительно повысить качество продукта и сэкономить время и деньги на более поздних стадиях тестирования и разработки.
Тест-кейсы и их структура
Составление тест-кейсов – это важный процесс, который помогает эффективно тестировать программное обеспечение и обнаруживать ошибки. Следующие шаги могут помочь правильно составлять тест-кейсы:
– Определение целей тестирования: определение целей тестирования позволяет определить, какие тесты необходимо провести. Необходимо определить, что именно должен делать продукт, какие функции он должен выполнять и какие проблемы могут возникнуть. Важно также уделить уделить внимание негативному тестированию.
– Определение входных данных: определение входных данных для каждого тестового случая позволяет проверить, работает ли продукт правильно. Необходимо определить, какие данные будут использоваться для каждого теста, какие значения будут использоваться и как они будут вводиться.
– Определение ожидаемых результатов: определение ожидаемых результатов для каждого тестового случая позволяет определить, работает ли продукт правильно и соответствует ли он требованиям. Необходимо определить, какие результаты должны быть получены, как они должны быть отображены и какие сообщения об ошибках должны появиться, если они есть.
– Создание шагов тестирования: создание шагов тестирования для каждого тестового случая позволяет определить, какие шаги необходимо выполнить для тестирования каждой функции продукта. Шаги должны быть конкретными и четкими, чтобы тестирование было эффективным.
– Определение предусловий и постусловий: определение предусловий и постусловий для каждого тестового случая позволяет определить, какие условия должны быть выполнены перед запуском теста и что должно произойти после его завершения.
– Проверка тест-кейсов: проверка тест-кейсов позволяет убедиться, что они покрывают все функции продукта и соответствуют требованиям. Необходимо также проверить, что тест-кейсы легко читаются и понятны для других членов команды.
– Обновление тест-кейсов: обновление тест-кейсов при изменении требований или функций продукта позволяет сохранить их актуальность.
Важно помнить, что тест-кейсы должны быть написаны так, чтобы их можно было легко понять и выполнить другими членами команды. Каждый тест-кейс должен покрывать только одну функцию продукта. При составлении тест-кейсов не забывайте составлять негативные кейсы. Негативное тестирование является важной частью процесса тестирования, поскольку направлено на проверку того, как система обрабатывает неправильные или неверные данные и действия пользователей. Негативные тесты помогают обнаружить потенциальные уязвимости, ошибки и неожиданное поведение системы.
Структура тест-кейсов
Хороший тест-кейс должен иметь структуру, которая обеспечивает понятность, четкость и легкость его использования. Ниже представлена стандартная структура хорошего тест-кейса:
– Идентификатор: уникальный номер тест-кейса для идентификации и связывания с требованиями или другими документами.
– Название: краткое описание функциональности, которую тестирует данный тест-кейс.
– Окружение: на каком окружении (устройство/браузер/ОС) должно проводиться тестирование.
– Описание: подробное описание того, что тестируется в данном тест-кейсе.
– Предусловия: любые условия, которые должны быть выполнены перед запуском тест-кейса, например, наличие определенных данных или доступ к определенной системе.
– Шаги: последовательность действий, которые тестировщик должен выполнить, чтобы протестировать определенную функциональность.
– Ожидаемый результат: четкое описание того, что ожидается в результате выполнения каждого шага тест-кейса или тест-кейса в целом.
– Фактический результат: фактический результат выполнения каждого шага тест-кейса или тест-кейса в целом.
– Статус: текущее состояние тест-кейса, например, пройден, провален или в процессе выполнения.
– Постусловия: любые условия, которые должны быть выполнены после завершения тест-кейса, например, восстановление данных или перезагрузка системы.
– Заключение: краткий комментарий о результатах тестирования, включая проблемы, которые были обнаружены в процессе выполнения тест-кейса, и рекомендации для дальнейших шагов.
Важно отметить, что структура тест-кейса может различаться в зависимости от проекта, инструментов тестирования и методологии разработки. Однако, необходимо следовать общим принципам, чтобы тест-кейсы были эффективными и максимально информативными для тестировщиков и других членов команды разработки.
Ниже приведен пример тест-кейса для тестирования функции отправки электронной почты в веб-приложении:
TК001. Отправка электронной почты
Окружение: Android 12, Chromev.111
Описание: Тестирование функции отправки электронной почты в веб-приложении.
Предусловия: Авторизоваться в веб-приложении.
Шаги:
1. Нажать на кнопку «Написать письмо».
2. Ввести адрес электронной почты получателя в поле «Кому».
3. Ввести тему письма в поле «Тема».
4. Ввести текст письма в поле «Текст письма».
5. Нажать на кнопку «Отправить».
Ожидаемый результат:
Письмо успешно отправлено.
Получатель успешно получает письмо.
На странице отображается сообщение об успешной отправке письма.
Фактический результат:
Письмо не отправлено.
При отправке письма возникает ошибка.
Получатель не получает письмо.
Чек-листы