В преддверии тренинга Тест-дизайн и все все все, который пройдет этой осенью в четырех городах (24-25 сентября в Харькове; 15-16 октября в Нижнем Новгороде; 29-30 октября в Москве; 18-19 ноября в Самаре) Александр Федоров решил лучше познакомиться со своей аудиторией и провести бесплатный вебинар Тест-дизайн «в цикле».
Любые процессы цикличны по своей природе, и разработка тестов не исключение. Тест-кейсы придумываются, создаются и используются на продукте и иногда в его последующих версиях. На разных этапах разработки к тестированию и тест-дизайну выдвигаются разные требования, которые мы рассмотрим в рамках вебинара.
Особенности тест-дизайн при итерационной разработке
Польза и спорная эффективность автоматизации тестирования
Наследование тест-кейсов новыми и «родственными» версиями продукта
Поддержание тест-кейсов в актуальном состоянии на разных этапах жизненного цикла продукта
В преддверии тренинга Тест-дизайн и все все все, который пройдет этой осенью в четырех городах (24-25 сентября в Харькове; 15-16 октября в Нижнем Новгороде; 29-30 октября в Москве; 18-19 ноября в Самаре) Александр Федоров решил лучше познакомиться со своей аудиторией и провести бесплатный вебинар Тест-дизайн «в цикле».
Любые процессы цикличны по своей природе, и разработка тестов не исключение. Тест-кейсы придумываются, создаются и используются на продукте и иногда в его последующих версиях. На разных этапах разработки к тестированию и тест-дизайну выдвигаются разные требования, которые мы рассмотрим в рамках вебинара.
Особенности тест-дизайн при итерационной разработке
Польза и спорная эффективность автоматизации тестирования
Наследование тест-кейсов новыми и «родственными» версиями продукта
Поддержание тест-кейсов в актуальном состоянии на разных этапах жизненного цикла продукта
This document outlines the test approach, scope, objectives, assumptions, and methodology for testing applications. It describes unit, integration, system, regression, and user acceptance testing. The primary objective is to ensure all requirements are met and the system functions as intended. The secondary objective is to identify and address all issues before release. Test deliverables include documents like the test approach, plan, and specifications as well as test cases, bug reports, and status reports.
This document outlines the test approach, scope, objectives, assumptions, and methodology for testing applications. It describes unit, integration, system, regression, and user acceptance testing. The primary objective is to ensure all requirements are met and the system functions as intended. The secondary objective is to identify and address all issues before release. Test deliverables include documents like the test approach, plan, and specifications as well as test cases, bug reports, and status reports.
"Опыт создания системы управления сборкой и тестированием" (полная)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
Тестирование параллельного программного обеспечения представляет собой более сложную задачу по сравнению с тестированием последовательной программы. Программист должен знать о подводных камнях при тестировании параллельного кода, имеющихся методологиях и инструментарии.
Поиск уязвимостей в программах с помощью анализаторов кодаTatyanazaxarova
В настоящее время разработано большое количество инструментальных средств, предназначенных для автоматизации поиска уязвимостей программ. В данной статье будут рассмотрены некоторые из них.
Ошибки, которые сложно заметить на code review, но которые находятся статичес...Andrey Karpov
Есть ошибки, которые легко прячутся от программистов на обзорах кода. Чаще всего они связаны с опечатками или недостаточным знанием тонких нюансах языка/библиотеки. Давайте посмотрим интересные примеры таких ошибок и как их можно выявить с помощью статического анализа. При этом анализаторы не конкурируют с обзорами кода или, например, юнит-тестами. Они отлично дополняют другие методологии борьбы с ошибками.
В статье описаны технологии тестирования, используемые при разработке статического анализатора кода PVS-Studio. Разработчики инструмента для программистов делятся принциами тестирования собственного программного продукта, которые могут быть интересны разработчикам аналогичных пакетов обработки текстовых данных или исходных кодов.
2. Что такое Баг ?
По одной из версий, в 1946
году учёные Гарвардского
университета,
тестировавшие
вычислительную машину
Mark IIAiken Relay Calculator,
нашли мотылька,
застрявшего между
контактами
электромеханического реле,
и Грейс Хопперпроизнесла
этот термин. Извлечённое
насекомое было вклеено
скотчем в технический
дневник с сопроводительной
надписью: «First actual case
of bug being found» («первый
реальный случай, когда был
найден жук»)[1]
Source: https://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%B3
3. Bug:
"Если программа не делает того, чего
пользователь от нее вполне обосновано
ожидает, значит налицо программная ошибка
(Майерс (Myers, 1976, c.6))
Bug=defect= A flaw in a component or system
that can cause the component or system to fail to
perform its required function, e.g. an incorrect
statement or data definition. A defect,
ifencountered during execution, may cause a
failure of the component or system. (ISTQB)
определение ошибок как расхождения между
программой и ее спецификацией - не совсем
верно
4. Bug Report (Баг репорт)
это документ, описывающий ситуацию или последовательность
действий приведшую к некорректной работе объекта
тестирования, с указанием причин и ожидаемого результата.
Должна использоваться правильная терминология :
элементы пользовательского интерфейса (editbox, listbox,
combobox, link, text area, button, menu, popup menu, title bar,
system tray и т.д.),
действий пользователя (click link, press the button, select menu
item и т.д.)
полученных результатах (window is opened, error message is
displayed, system crashed и т.д.).
5. Шапка
– Идентификатор (id) Уникальный
- Короткое описание (Bug Summary), Принцип Что? Где? Когда?
http://qanest.blogspot.com/2008/09/blog-post.html
Короткое описание проблемы, явно указывающее на
причину и тип ошибочной операции
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Серьезность (Severity), S1 Блокирующий (Blocker)
S2 Критический (Critical)
S3 Значительный (Major)
S4 Незначительный (Minor)
S5 Тривиальный (Trivial)
http://www.protesting.ru/testing/bugpriority.html#severity
Приоритет (Priority) P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
http://www.protesting.ru/testing/bugpriority.html#priority
Статус (Status) Статус бага. Зависит от используемой процедуры
и жизненного цикла бага (bug workflow and life cycle)
Автор (Author) Создатель баг репорта, обычно не редактируется
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
6. Окружение:
ОС / Сервис Пак и т.д. / Браузера + версия / .. Информация об окружении, на котором был найден баг:
операционная система, сервис пак, для WEB тестирования -
имя и версия браузера и т.д.
Описание
Описание (Description)
Шаги к воспроизведению (Steps to reproduce), Шаги, по которым можно легко воспроизвести ситуацию,
приведшую к ошибке.
Результат (Actual Result), Результат, полученный после прохождения шагов к
воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Приложение (Attachment) Файл с логами, скриншот или любой другой документ,
который может помочь прояснить причину ошибки или
указать на способ решения проблемы
7. Основные ошибки при написании
багов репортов:
Недостаточность предоставленных данных
Определение серьезности
Язык описания
Отсутствие ожидаемого результата
9. Методы тестирования
Белый ящик
Полностью покрыты все :
… строки кода программы
… ветви в коде программы
… пути в коде программы
Черный ящик
Полностью покрыты все:
… входные данные
… комбинации входных данных
… последовательности комбинаций
входных данных
10. Black Box
= specification-based testing: Testing, either functional or
non-functional, without reference to the
internal structure of the component or system.
11. White Box
=clear-box testing= structural testing: Testing based on
an analysis of the internal structure of the component or
system
12. Test Types (Виды тестирования)
Functional testing
Non- Functional testing
Structural testing
Testing related to changes
13. Functional testing
Функциональное тестирование (Functional
testing)
Тестирование безопасности (Security and
Access Control Testing)
Тестирование взаимодействия (Interoperability
Testing)
14. Non - Functional testing
Нагрузочное тестирование (Performance and Load
Testing)
Стрессовое тестирование (Stress Testing)
Тестирование стабильности или надежности
(Stability / Reliability Testing)
Объемное тестирование (Volume Testing)
Тестирование установки (Installation testing)
Тестирование удобства пользования (Usability
Testing)
Тестирование на отказ и восстановление (Failover
and Recovery Testing)
Конфигурационное тестирование (Configuration
Testing)