Тестирование ПО. Перевод презентации курса MVA

1. Шаптала Максим | Компьютерная академия Шаг

2. Тестирование ПО
01 | Основы тестирования ПО
1.1 Тестирование ПО
1.2 Программные и железные компоненты
1.3 Основы программирования
1.4 Управление жизненным циклом
04 | Управление проектами тестирования
4.1 Основные контр. точки тестирования
4.2 Agile подход
4.3 Работа в распределенной команде
4.4 Отчеты о тестировании
02 | Методологии тестирования ПО
2.1 Техники тестирования
2.2 Уровни тестирования
2.3 Типы тестов
05 | Работа с багами
5.1 Выявление программных дефектов
5.2 Регистрация багов
5.3 Управление багами
03 | Разработка тестов ПО
3.1 Пользовательское централизованное
тестирование
3.2 Тестируемость ПО
3.3 Разработка плана тестирования
компонентов
3.4 Тестирование фитч
3.5 Область тестирования
06 | Автоматизация тестирования ПО
6.1 Автоматизация тестирования
6.2 Стратегия автоматизация тестирования
6.3 Написание автоматизированных тестов
6.4 Управление тестовыми скриптами
Содержание курса

3. 05 | Работа с ошибками

4. Как выявить дефекты ПО
Регистрация ошибок
Управления ошибками
Обзор модуля

5. 5.1 Выявление дефектов ПО
05 | Работа с ошибками

6. Обзор раздела
В этом разделе будет рассмотрено следующее:
– Выполнение тестов
– Выполнение сценариев автоматизации

7. Основные вопросы
Что необходимо настроить в Microsoft® Test Foundation Server
(TFS) для запуска тестов и сбора данных удаленно?
Что должно быть установлено на каждую удаленную машину
запускающую тесты?
Какой инструмент в Visual Studio позволяет разработчику
выполнять тесты и анализировать результаты тестового плана?

8. Ручное против автоматизированного тестирования
При ручном тестировании татуировщик играет роль
пользователя и проверяет нет ли каких-либо неожиданного
или нежелательного поведения.
Автоматизированные тесты используют тестовое ПО для
контроля и отслеживания одного или более автоматически
выполняемого теста
Некоторые татуировщики используют скрипты такие как
тестовые скрипты или автоматизированные скрипты.
Автоматизированные скрипты, которые используют для
тестирования пользовательских интерфейсов называются
закодированными тестами пользовательского интерфейса.

9. Автоматизация тестирования с Visual Studio и
MTM
Visual Studio позволяет таксировщиками и разработчикам
запускать тесты локально и удаленно.
Тем не менее, для того, что бы организовать тесты в планы
тестирования и, в свою очередь, выполнить тесты по плану,
провести анализ результатов, можно воспользоваться
Microsoft Test Manager (MTM).
 MTM предоставляет интерфейс с Microsoft Team Foundation Server
для управления тестами для командного проекта.

10. Управление распределенным тестированием
При распределенном тестировании используется множество
компьютеров (настроенных как лабораторное окружение lab
environment) для выполнения тестов и сбора данных.
Лаборатория может состоят из физических или виртуальных машин.
Виртуальная машина это “компьютер в компьютере”
реализованном в виде ПО. Она полностью эмулирует физическую
систему в самостоятельном и изолированном программном
окружении.
Дополнительно, различные машины в лаборатории могут запускать
различное окружение (различные версии ОС Windows, различные
конфигурации, и т.д.)
Для распределенного тестирования необходимо машина с
контроллером тестов и лабораторные машины с тест-агентами

11. ПО для распределенного тестирования
Контроллер тестов: это фоновый процесс, который
управляет набором машин с установленным ПО тест-
агентами.
Тест-агент: фоновый процесс которые получает,
запускает и предоставляет отчет по тестам и собирает
данные на единственном компьютере. Тест-агент
взаимодействует с контроллером теста, обычно
размещенного на другом компьютере.

12. Запуск тестов в Visual Studio
Visual Studio предоставляет различные способы для запуска
тестов. Вы можете выбрать путь, который лучше всего
подходит к вашей потребности:
 Из Test Explorer (Test Explorer позволяет просто запускать и
отслеживать статус всех автоматизированных тестов в Вашем
решении).
 Из редактора нагрузочного теста (нагрузочные тесты и тесты
производительности веб-тестов).
 Из файлов с исходными кодами (запуск тестов во время
редактирования файл, который содержит ваш код).

13. Запуск тестов из Microsoft Test Manager
Запуск автоматизированных тестов в МТМ возможен
различными способами, в зависимости от того как Вы
хотите запустить тесты и увидеть результаты.
Если Вы запустили Ваш автоматизированный тест
используя план тестирования, Вы можете наблюдать
Ваш процесс тестирования и просто перезапускать Ваш
тести при необходимости.

14. Вопросы раздела
 Что необходимо настроить в Microsoft® Test Foundation
Server (TFS) для запуска тестов и сбора данных удаленно?
 Что должно быть установлено на каждую удаленную
машину запускающую тесты?
 Какой инструмент в Visual Studio позволяет разработчику
выполнять тесты и анализировать результаты тестового
плана?

15. 5.2 Регистрация ошибок
05 | Работа с ошибками

16. Обзор раздела
В этом разделе будет рассмотрено следующее:
– Приоритет
– Точность
– Зависимость
– Шаги воспроизведения

17. Основные вопросы
Какой термин используется для описания влияния ошибки ни
проект в целом?
Объясните разницу между приоритетом и рангом стека.
Какая технология позволяет записывать диагностические
данные для помощи в устранении ошибок, которые трудны в
воспроизведении?

18. Отслеживание ошибок
С точки зрения программиста/разработчика баг – это ошибка
кодирования или логическая, которая приводит к краху
программы или к неверным результатам.
При использовании программ управления жизненным циклом
корпорации Microsoft’s®, таких, как Team Foundation Server
(TFS), для обеспечения высокого качества ПО, ошибка должна
быть зарегистрирована, отслежена и решена.
С учетом этого, баг – это такой же рабочий элемент (“work
item”), как и остальные задачи во время разработки. Тогда этот
рабочий элемент записывает потенциальный источник
неудовлетворительной работы продукта.

19. Определения бага
Когда баг или дефект обнаружен, создается рабочий элемент для
информирования команды о потенциальной проблеме и
документирования причины этой проблемы.
Как и другие рабочие элементы, баги управляются через Team
Foundation Server и в общем случае назначаются членам команды.
Если ошибка обнаружена с применением Microsoft Test Manager,
информация о связанных наборах тестов, пользовательских
историях и другая информация автоматически добавляется к багу.
Весьма важным является запись необходимой информации когда
регистрируется новый или ранее не выявленный баг.

20. Приоритет багов
Приоритет это субъективный рейтинг бага который
относится к бизнес процессу.
Можно определить следующие критерии:
1. Продукт не может быть выгружен без успешного решения бага и
баг должен быть решен как можно раньше.
2. Продукт не может быть выгружен без успешного решения бага,
но баг не требует немедленного решения.
3. Решения бага не является обязательным исходя из ресурсов,
времени и рисков.

21. Важность бага
Важность это субъективный рейтинг влияния бага на
проект.
Можно определить следующие критерии:
1. Критичный
2. Высокая
3. Средний
4. Низкий

22. Ранг стека
Ранг стека это субъективный рейтинг бага в сравнении с другими
багами. Элемент, которому присвоено меньшее значение, должен быть
решен раньше элемента с большим значением.
Не существует предопределенной шкалы ранга стека. Вы можете
использовать “сортированный порядок” для всего списка багов. Если
команда собирается определить приоритеты багов над которыми
необходимо работать они могут быть ранжированы по всем
нерешенным багам в ранге стека.
Баг, который будет решен первым должен иметь меньший номер,
например 1 или 2. Багу, который может быть решен позже, присевается
большее значение, возможно 30 или 100.
Ранг стека обычно определяется исходя из приоритета и важности бага.

23. Шаги воспроизведения
Шаги воспроизведения это шаги, которые другие тестеры или
разработчики могут выполнить для воспроизведения бага или
неожиданного поведения.
Подробные шаги воспроизведения имеют решающее значения для
членов команды, которые не видят ошибку с первого раза. Это, в
частности, справедливо если баг обнаруживается через ручное или
исследовательское тестирование
Хорошо описанные шаги являются явными, объясняющими точно какие
действия предпринимались, включая клики мыши и нажатие клавиш на
клавиатуре для обнаружения неисправного поведения.
Вы можете включить снимки экрана, которые могут быть добавлены к
рабочему элементу.

24. Отслеживание диагностических данных
Разработчики могут собирать определенную диагностическую информацию при
запуске тестов для помощи в изолировании багов трудных в воспроизведении.
IntelliTrace: фитча предназначенная для отладки приложения в определенные
моменты времени. Она захватывает и записывает то, что приложение делает во
время работы. При возникновении ошибки, можно увидеть состояние приложения
в любой момент времени с начала до момента возникновения ошибки.
Эта информация позволяет использовать IntelliTrace для отслеживания того, что на
самом деле происходит в приложении при возникновении бага.
When a test step fails and a bug is filed, an IntelliTrace file is automatically linked to the
bug and is available together with the test results.
The IntelliTrace file can then be used by another individual who can replicate the local
test session on their computer without having to reproduce the bug directly.

25. Вопросы раздела
 Какой термин используется для описания влияния ошибки ни
проект в целом?
 Объясните разницу между приоритетом и рангом стека.
 Какая технология позволяет записывать диагностические данные
для помощи в устранении ошибок, которые трудны в
воспроизведении?

26. 5.3 Управление
ошибками
05 | Работа с ошибками

27. Обзор раздела
В этом разделе будет рассмотрено следующее:
– Рассмотрение
– Разрешение
– Закрытие
– Мониторинг
– Финальный отчет ошибок

28. Основные вопросы
Что означает под рассмотрением списка ошибок?
Какие необходимы действия перед закрытием бага?
Какова причина возобновления решенного бага?

29. Что такое рассмотрение?
Рассмотрение это - процесс, при кортом команда
просматривает новые и повторно открытые ошибки,
присваивает им приоритета и итерации, а также назначает
участника команды для их исправления. "Рассмотрение"
обычно ведет владелец продукта или скрам-мастер, учитывая
входные данные от команды. это процесс обзора новых или
возобновленных багов и присвоение каждому рабочего
приоритета или ранга стека.
В некоторых проектах, может быть определена отдельная
команда специально для рассмотрения багов; в других
проектах тестировщики или, возможно, целая команда
выполняет сортировку.

30. Рассмотрение бага
Собрание по рассмотрению багов должно быть назначено с некоторым
интервалом после начала разработки и тестирования проекта.
Перед началом рассмотрения, разрабатывается ряд критериев для определения
того какие баги должны быть исправлены и с каким приоритетом. Критерий
обычно определяют серьёзность ошибок, ошибки которые связаны с фитчями,
имеющие существенное значение или другими рисками в проекте.
В начале проекта, скорее всего, принимается решение фиксировать
большинство багов, которые были рассмотрены. Тем не менее, по мере
развития проекта критерии рассмотрения (bar) могут быть увеличены для
сокращения количества исправленных ошибок.
Увеличение критерия bar и допущение наличия нерешенных багов в проекте –
это компромисс, которые указывает на то, что устранение багов менее важно
чем достижение заданных целей проекта, ограничение бюджета или графика.

32. Проверка устранения бага
После исправления бага, перед закрытием рабочего элемента,
должно быть назначено тестирование для проверки того, что
проблема решена.
Для проверки исправления, тестировщик должен попытаться
воспроизвести баги, рассмотреть дополнительное
неожиданное поведение, и, если необходимо, возобновить
баг.
При проверке бага возможно, что баг не был полностью
устранен или вы не согласны с решением. В этом случае, вы
общаетесь о проблеме с лицом, которое устраняло баг и
приходите к согласию или, возможно, возобновляете ошибку.

33. Состояния ошибки
Команда может отслеживать прогресс ошибок устанавливая их
состояние. Возможные значения для статуса отличаются в
различных методологиях разработки, но большинство из них
используют одинаковый подход.
Активное состояние означает, что ошибка обнаружена. Новому
багу в общем случае присваивают статус Активный.
Решенный означает, что баг исправлен.
Закрытый означает, что кто-то проверил, что разрешенная
ошибка исправлена.
При изменении состояния база, член команды указывает причину

34. Состояния ошибки

35. Причины разрешения бага
Решенная: После исправления проблемы, запуска модульных тестов
для подтверждения того, что проблема решена и проверки в
измененном коде.
Отложенный: В случае, когда баг не будет исправлен на текущей
итерации
Дубликат: Когда другой активный баг описывает ту же самую
проблему.
В соответствии с проектом: Когда баг описывает ожидаемые условия
или поведение системы.
Не может быть воспроизведен: Когда члены команды не могут
воспроизвести поведение описанного в баге.

36. Причины возобновления решенного бага
Устаревший: Когда баг более не принадлежит к продукту.
Например, баг устаревший если он описывает проблему в
фитче, которой больше нет в продукте.
Не исправлен: Когда решение неприемлемо или исправление
неправильно.
Ошибка тестирования: Когда тест показывает, что ошибка
все еще присутствует.

37. Причины возобновления закрытого бага
Регрессия: Когда баг проявляется в поздних сборках.
Возобновленный: Когда баг был закрыт с ошибкой или по
другой причине.

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

39. Финальный отчет об ошибках
С финальный отчет включают:
 Количество ошибок
 Активные ошибка по приоритету или важности
 Активные баги по назначению (с указанием как много
активных багов назначено каждому члену команды)
 Разрешенные баги по назначению (с указанием
количества багов которые каждые член команды решил)

40. Вопросы раздела
 Что означает под рассмотрением списка ошибок?
 Какие необходимы действия перед закрытием бага?
 Какова причина возобновления решенного бага?

41. Дополнительные ресурсы
MSDN Software Testing Resources
Essential Guide for Running Automated Tests from a
Test Plan
http://msdn.microsoft.com/en-us/library/ff472576.aspx
Installing and Configuring Test Agents and Test
Controllers
http://msdn.microsoft.com/en- us/library/vstudio/dd648127.aspx
Running Tests in Microsoft Test Manager http://msdn.microsoft.com/en- us/library/dd286680.aspx
Test Early and Often http://msdn.microsoft.com/en- us/library/vstudio/ee330950.aspx
Bugs (Agile) http://msdn.microsoft.com/en- us/library/dd380645(v=vs.110).aspx
Triage Workbook http://msdn.microsoft.com/en- us/library/dd380707(v=vs.100).aspx
Submitting Bugs http://msdn.microsoft.com/en- us/library/dd286746.aspx
Bug Status Report http://msdn.microsoft.com/en- us/library/dd380736.aspx