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 Управление тестовыми скриптами
Содержание курса
6. Обзор раздела
В этом разделе будет рассмотрено следующее:
– Преимущества
– Кандидаты на автоматизацию
– Процесс автоматизации
7. Основные вопросы
В чем разница между автоматизированными и ручными
тестами?
В чем преимущество автоматизированного тестирования?
Какие типы тестов могут быть автоматизированы?
8. Автоматизированные тесты
Автоматизированные тест представляет собой набор шагов,
которые могут быть запущены программно на компьютере для
тестирования функциональности ПО.
Автоматизированное тестирования дополняет, но не заменяет
ручное тестирование.
Автоматизированные тесты должны быть разработаны
разработчиками, в то время, как ручное тестирование может
быть проведено тем, кто не имеет навыков в
программировании.
9. Преимущество автоматизированных тестов
Автоматизированные тесты помогают поддерживать стабильность и
находить регрессии которые могут происходить из-за изменений в
коде.
Они могут быть запущены без присмотра.
Автоматизированные тесты – это разрабатываемое ПО, которое
состоит из повторно используемого кода. Это делает
автоматизированные тесты гибкими и простыми в поддержке.
Тесты могут быть запущены с различными конфигурациями
используя Microsoft Test Manager.
Метрики покрытия кода могут быть собраны при запуске тестов.
10. Потенциальные недостатки
При изменении кода или рефакторинге кода могут появиться
каскадные эффекты, которые требуют соответствующих
изменений в нерабочих автоматизированных тестах.
Это может привести к “психологическому воздействию” в
вашей команде – если код изменился, то это приводит к
неисправностям в тестах.
Также может быть ложное чувство безопасности когда все
тесты пройдены при неверных входных условиях.
11. Общие автоматизированные тесты
Некоторые типы тестов почти всегда автоматизированы
Модульные тесты: в разработке через тестирование, модульные
тесты создаются первыми; затем разработчики пишут код для
прохождения этих модульных тестов.
Нагрузочные тесты: генерирование тяжелой нагрузки будет
трудным для ручного тестирования, но автоматизированные тесты
могут обеспечить большую нагрузку при наименьших
человеческих усилиях.
Непрерывное интеграционное тестирования: Вы можете
использовать непрерывную интеграцию с Microsoft®Visual
Studio® Application Lifecycle Management (ALM) для гарантии того,
что любой разработанный код проверен и работает корректно.
12. Другие потенциальные кандидаты для
автоматизации
Конфигурационное тестирование: Тестирование в множестве
установленных средах может быть трудной задачей. Microsoft Test
Manager предоставляет возможность запуска наборов тестов с
различными конфигурациями используя виртуальные или физические
машины.
Тесты пользовательского интерфейса: Visual Studio ALM имеет
возможность создавать автоматизированные тесты напрямую для
пользовательского интерфейса.
Установочные тесты: Вы можете использовать лабораторные
возможности Microsoft Test Manager для установки группы
конфигураций которые могут быть использованы для проверки того
выполняется ли установка программы как ожидается.
13. Барьеры на пути к автоматизации
Преимущества автоматизации должны быть соотнесены с
затратами. Несколько соображение при степени
автоматизации:
Создание автоматизированных тестов требует от тестирующей
группы для тестирования изучения кодирования или наем
разработчиков только для участия в команде тестировщиков.
Часто меняющийся код является движущейся мишенью и будет
приводить к каскадному эффекту, поэтому тесты должны также
корректироваться.
Жестко привязанный код к пользовательскому интерфейсу трудно
тестировать потому, что может потребоваться взаимодействие
пользователя с элементами управления.
14. Процесс автоматизации
Вы можете начать цикл тестирования с создания ручного
теста, который, впоследствии, может оказаться хорошим
тестом для автоматизации.
15. Вопросы раздела
В чем разница между автоматизированными и ручными
тестами?
В чем преимущество автоматизированного тестирования?
Какие типы тестов могут быть автоматизированы?
19. Журналирование данных с IntelliTrace
IntelliTrace сохраняет журнал ключевых событий и переменных
во время тестирования и выполнения в отладочном режиме.
Вы можете вернуться назад по истории выполнения перед
неудачей, изучить значения переменных которые записаны в
журнал. Это в частности полезно при работе с багами которые
трудны для воспроизведения.
Для включения IntelliTrace, в Visual Studio Debug меню,
выберите Options and Settings, IntelliTrace. Вы можете также
изменить настройки для записи больше или меньше данных.
20. Определение приоритетов в автоматизации
Создание автоматизированных модульных тестов это первоочередная задача в
командах использующих модель разработки через тестирование —разработчики
обязаны создавать тесты перед сборкой любого метода или класса.
Также, интеграционные тесты становятся главным приоритетом при объединении
модулей в компоненты.
Когда принимают решение о том, что ручные тесты должны быть
автоматизированы, учитывают следующее:
Как часто будет запускаться тест? Отдавайте предпочтение часто
используемым тестам.
Как часто этот код меняется? Часто изменяемый код будет требовать
поддержку и сокращать преимущества от автоматизации.
Как много времени может быть сэкономлено запуском теста без присмотра?
Некоторые ручные тесты требуют огромных временных затрат. Если можно
перейти к автоматизации, это может стоить затраченных на автоматизацию
усилий.
23. Обзор раздела
В этом разделе будет рассмотрено следующее:
– Логика
– Обработка ошибок
– Комментирование
– Виртуальные машины
24. Основные вопросы
Чем виртуальная машина отличается от физической?
Как называется условие теста используемого для проверки
логики в отладочных сборках?
Что произойдет с этими условиями тестов в финальной
сборке?
25. Тестирование логики через утверждения
(Assertions)
Assertion это объект, который позволяет проверить условие во время
выполнения программы. Если утверждение верно (true), без порождения
каких-либо действий; если утверждение ложно (false), утверждение
генерирует сбой.
В отладочной сборке, сбойное утверждение приводит к остановке
программы, что упрощает определение причину проблемы.
В релизе, утверждения игнорируются.
При использовании утверждений необходимо убедиться, что код внутри
блока утверждения не меняет результат программы при его удалении.
Другими словами, он должен быть только
В противном случае, можно случайно породить баг, который только
проявляется в финальной версии программы.
26. Ошибки при тестировании
Автоматизированные тесты представляют собой программный код,
поэтому возможно протестировать этот код на наличие ошибок.
Если тест не запускается, необходимо изучить отказ проверяя тестовую
среду; включая способ проверки и настройки в параметрах теста.
В некоторых случаях, таких как развертывание, отказы не зависят от
типа теста. В других случаях, тип теста определяет как и что необходимо
исследовать.
Ошибки в тестах находятся на двух уровнях:
Ошибки уровня тестирования. Примером может служить ошибка времени
ожидания которая происходит если достигнут предел времени тестирования.
Ошибки уровня выполнения. Примером может служить ошибка времени
ожидания которая происходит если достигнут предел времени выполнения.
27. Комментарии теста
При запуске теста используя Test Runner, вы имеете
возможность добавить комментарии к шагам теста.
Комментарии могут быть использованы для добавления
определенных деталей которые вы хотели бы предоставить
другим членам команды с учетом неожиданного поведения
или предложением на что необходимо обратить внимание
пока тестируется приложение.
Эти комментарии могут быть полезны как дополнительная
информация о багах, для изолирования ошибок кодирования
или для переработки пользовательского интерфейса.
28. Виртуальные машины
В общем случае, на компьютере стоит одна ОС. С учетом того, что разработчикам
может потребоваться протестировать приложение на различных ОС для
совместимости, может потребоваться множество компьютеров с различными
настройками.
Вы можете установить программное обеспечение, которое эмулирует целый
компьютер обрабатывая инструкции таким же образом, как и оригинальный
процессор (или “физическая машина”). Это ПО называется виртуальной машиной
(virtual machine).
Используя виртуальную машину вы можете тестировать различные конфигурации
без приобретения дополнительных компьютеров.
Современный компьютеры даже позволяют запускать множество виртуальных
машин одновременно.
29. Вопросы раздела
Чем виртуальная машина отличается от физической?
Как называется условие теста используемого для проверки
логики в отладочных сборках?
Что произойдет с этими условиями тестов в финальной
сборке?
31. Обзор раздела
В этом разделе будет рассмотрено следующее:
– Дымовое тестирование
– Создание верифицирующих тестов
– Lab Management
32. Основные вопросы
Назовите два типа лабораторных сред?
Что означает тест проверки построения?
Каким типом машин может управлять SCVMM?
33. Дымовое тестирование
Термином дымовое тестирование (или краткое тестирование)
называют проверку изменений кода перед возвратом в
дерево исходного кода проекта.
После анализа кода краткое тестирование является наиболее
экономичным способом выявления и устранения неполадок в
программах.
Краткие тесты должны подтверждать, что изменения в коде
работают должным образом и не приводят к нестабильности
всего построения.
Вкратце, дымовое тестирование сосредоточено на той части
кода, которое было изменено или добавлено.
34. Тесты проверки построения (Build Verification Tests)
Дымовые тесты также известные как тесты проверки
построения
В это случае, он так называется потому, что обычно
выполняется после ежедневной сборки.
35. Лабораторные среды
Совершенная стратегия тестирования включает тесты
выполняемые на множестве систем, возможно, на различном
железе и под разными операционными системами.
Вместо того, что бы вручную настраивать каждую машину для
каждого набора тестов, Visual Studio Lab Management
позволяет настроить, развернуть провести тестирование.
Лабораторная среда это набор компьютеров, которые
управляются как единый блок, и на которой развертывается
система для теста вместе с ПО для тестирования.
36. Преимущество лабораторных сред
Результаты тестов могут быть представлены в виде графиков
которые связаны с системными требованиями.
Lab Manager автоматически устанавливает агента
тестирования на каждую машину, включает сбор тестовых
данных.
Можно просмотреть консоли всех машин одновременно через
одно представление, просто перемещаться от одной машине к
другой.
Лабораторная среда управляет распределением машин для
тестирования с целью предотвращения ошибочного доступа
двух членов команды к одной и той же машине для различных
тестов.
37. Два типа лабораторных сред
Стандартная лабораторная среда, которая может содержать
физические компьютеры и виртуальные машины
одновременно.
SCVMM среда, которая может содержать только виртуальные
машины, которые контролируются через System Center Virtual
Machine Manager (SCVMM).
38. Возможности доступные в SCVMM средах
Слепки (снимки) среды: Слепки среды содержат состояние
лабораторной среды, что позволяет быстро восстановить чистую среду,
или сохранить модифицированную среду.
Сетевая изоляция: Сетевая изоляция позволяет вам одновременно
запускать множество идентичных копий SCVMM сред без конфликта
имен.
Шаблоны виртуальных машин: Шаблон виртуальной машины
позволяет разворачивать множество копий в том же самом окружении
или множество окружений и одновременно запускать виртуальные
машины.
Сохраненная виртуальная машина: это виртуальная машина, которая
хранится в командном проекте и имеет уникальный идентификатор.
39. Поддерживаемые операционные системы в
виртуальных машинах
• Windows® XP SP3 and later versions
• Windows Vista®
• Windows Server® 2003
• Windows Server® 2008
• Windows Server® 2008 R2
• Windows Server® 2012
• Windows 7
• Windows 8 or later version
40. Вопросы раздела
Назовите два типа лабораторных сред?
Что означает тест проверки построения?
Каким типом машин может управлять SCVMM?
41. Дополнительные ресурсы по модулю
MSDN Software Testing Resources
Walkthrough: Creating and Running a Load Test
Containing Web Performance Tests
http://msdn.microsoft.com/en- us/library/dd537628.aspx
Walkthrough: Creating a Simple Web App http://msdn.microsoft.com/en-us/library/ms243156.aspx
Walkthrough: Recording and Running a Web
Performance Test
http://msdn.microsoft.com/en-us/library/ms182551.aspx
Using Code Coverage to Determine How Much Code
is being Tested
http://msdn.microsoft.com/en- us/library/dd537628.aspx
Unit Testing: Testing the Inside http://msdn.microsoft.com/library/jj15934 0.aspx
Отладка приложения путем записи выполнения
кода с помощью IntelliTrace
https://msdn.microsoft.com/ru-ru/en-
%20us/library/vstudio/dd264915.aspx
Walkthrough: Creating and Running a Generic Test http://msdn.microsoft.com/en-us/library/ms182626.aspx
Assertions in Managed Code http://msdn.microsoft.com/en- us/library/ttcc4x86(v=vs.110).aspx
Lab Environments http://msdn.microsoft.com/en- us/library/jj159341.aspx
Troubleshooting Test Execution http://msdn.microsoft.com/en- us/library/ms182478.aspx
Walkthrough: Managing Tests Using Lists and
Properties
(http://msdn.microsoft.com/en-US/library/ms182466(v=vs.100).aspx
Types of Performance Testing http://msdn.microsoft.com/en- us/library/bb924357.aspx
