mva stf module 3 - rus

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

Тестирование ПО

Тестирование ПО01 | Основы тестирования ПО

1.1 Тестирование ПО1.2 Программные и железные компоненты1.3 Основы программирования1.4 Управление жизненным циклом

04 | Управление проектами тестирования 4.1 Основные этапы тестирования

4.2 Agile подход4.3 Работа в распределенной команде

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 Управление тестовыми скриптами

Содержание курса

Click to edit Master subtitle style

03 | Разработка тестов ПО

1. Пользовательское централизованное тестирование

2. Тестируемость ПО3. Разработка плана тестирования компонентов4. Тестирование ключевых изменений5. Appropriately Scoping Test Cases

Обзор

3.1 Пользовательское централизованное тестирование3.2 Тестируемость ПО

03 | Разработка тестов ПО

Обзор раздела

В этом разделе будут рассмотрено следующее:

– Потребности и проблемы бизнеса, требования покупателей, сценарии

– Разработка через тестирование– Testing hooks (Тестовая петля)

Основные вопросы

Пример пользовательских требований?

Какие преимущества разработки через тестирование?

Какой тип тестов является основным для разработки через тестирования?

Пользовательские требованияПользовательские требования или диаграмма определяет что пользователям необходимо от системы или приложения.Они обсуждаются и формулируются на раннем этапе проектирования для гарантии того, что ПО обеспечит требования конечных пользователей. Пользовательские требования не пытаются объяснить внутреннее устройство или как система работает.Существует замечательные приложения для обсуждения с пользователями/заказчиками при agile разработке, которые позволяют сфокусироваться с самого начала на новой итерации.Существует множество способов документирования пользовательских требований включая диаграммы вариантов использования или пользовательские истории.

Диаграммы вариантов использования

Диаграммы вариантов использования описывает кто использует систему и для чего.Диаграмма представляет цели пользователя и процедуры для достижения этих целей

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

Пользовательские историиПользовательская история определяет функциональность продукта или системы которая представляет ценность для конечного пользователя.Каждая пользовательская история должна указывать на одну функциональную фичу, которую пользователь хочет получить от приложения и описать ее с точки зрения пользователя.Пользовательские истории могут вводиться в Microsoft® Visual Studio® и обычно выражаются предложением или коротким параграфом.

Включение пользовательских историй в Visual Studio имеет множество преимуществ, включая возможность добавление ссылок на тесты и задачи присвоенные разработчикам.

Пример пользовательских историй

“Как заказчик, я могу видеть текущее меню.”“Как заказчик, я могу сделать заказ.”“Как заказчик, я могу оплатить заказ.”

“В ресторане, я могу добавлять блюда в текущее меню.”“В ресторане, я могу доставить заказ.”

Разработка через тестирование (TDD)Разработка через тестирование это техника программирования в которой используются модульные тесты как основное руководство для разработки программного обеспечения.Это означает, что вы разрабатывает тестовые случаи перед написанием кода. Затем разрабатывается функционал таким образом, что бы пройти существующие тесты. Этот подход имеет множество преимуществ:

Разработка может начаться при недостаточно определенном наборе требований.

Способствует разработке «слабо-связанного» кода – каждый модуль самодостаточный т.к. разрабатывается независимо от других.

Тесты служат в качестве документации. Интенсивное использование автоматизированных тестов

сокращает время на тестирование и позволяет быстро выполнить регрессионное тестирование.

Процесс разработки через тестирование

Testing Hooks (Тестовая петля)

Testing hook это свойство, которое позволяет протестировать внутреннюю функциональность независимо от остальной части приложения.Например, можно позволить разработчику протестировать функции оплаты заказа без навигации по меню и добавления заказа в корзину.Hooks могут быть удалены или оставлены перед релизом или развертыванием приложения.

Другие примеры тестовой петли

Последовательность нажатий клавиш, которая вызывает диалоговое окно информации о системе.Упрощенный пользовательский интерфейс, который позволяет получить упрощенный доступ к функциям без "удобства" для конечного пользователя.Аргументы командной строки, которые инициализируют данные автоматически, избавляя тестера в необходимости вводить данных вручную.

Вопросы раздела

Пример пользовательских требований?

Какие преимущества разработки через тестирование?

Какой тип тестирования является основным для разработки через тестирования?

3.3 Разработка плана тестирования компонентов

03 | Разработка тестов ПО

Обзор раздела

В этом разделе будет рассмотрено:

– График тестирования– Область тестирования–Методология– Сценарии– Инструменты

Основные вопросыЧто такое управление жизненным циклом приложения (ALM)?

Какое программное обеспечения является основным для управления жизненного цикла приложения в Microsoft® Visual Studio®?

Что такое покрытие кода?

Управление жизненным циклом приложенияУправление жизненным циклом приложений относится к управлению всего объема работ, необходимых для создания приложения от первоначального планирования до развертывания и технического обслуживания.Microsoft Visual Studio включает в себя тестно интегрированный набор ALM инструментов; ядром этого набора является Microsoft Visual Studio Team Foundation Server (TFS).TFS обеспечивает контроль версий, систему сборки, а также инструменты и метрики для управления и организации проектов.

ALM продолжение

ALM инструменты в Visual StudioPowerPoint Раскадровка (Storyboarding): Вы можете быстро визуализировать историю пользователя, требуется опыт работы с PowerPoint раскадровка.Product backlog: страница product backlog представляет информацию о текущей работе которая может быть динамично переопределена или сгруппирована.Sprint backlog и team capacity: страница sprint backlog отражает в режиме реального времени такие входные данные, как рабочие элементы, связанные с итерациями, даты, индивидуальную загруженность и отставание в работе как команды так и отдельных разработчиков.Task board: В повседневной практике, команда может просматривать и обновлять доску задач для визуального отображения состояния рабочих элементов.Request Feedback и Microsoft Feedback Client: инструменты позволяют группам привлекать заинтересованные стороны для получения обратной связи.

Стратегия тестирования и ее областьРазработчикам необходимо как можно раньше обсудить и принять стратегию тестирования проекта.Часто стратегия определяется или на нее оказывает влияние методология разработки, например водопада или agile.Основываясь на этой стратегии, команда разрабатывает один или более планов тестирования.Каждый план тестирования имеет свою область:

Весь проект может иметь план тестирования.В agile подходе каждый спринт или итерация должны иметь

свой план тестирования. Он может быть или не быть похожим на другие планы тестирования спринтов или итераций.

Для других моделей разработки, тесты имеют свои ключевые изменения и отличаться от тестирования спринтов/итераций.

Покрытие кода (Code Coverage)Стратегия тестирования может включать определенную цель в покрытии кода. Покрытие кода это метрика которая описывает какое количество исходного кода тестируется. Оно обычно выражается в процентах.Часто, команда разработчиков стремится к покрытию 80% исходного кода тестами. Эта цель будет принята как часть стратегии тестирования.В Visual Studio, покрытие кода вычисляется для:

Блоков (Block coverage) Строк (Line coverage)

Покрытие кода в Visual Studio

Вопросы раздела

Что такое управление жизненным циклом приложения (ALM)?

Какое программное обеспечения является основным для управления жизненного цикла приложения в Microsoft® Visual Studio®?

Что такое покрытие кода?

3.3 Тестирование фитч

03 | Разработка тестов ПО

Обзор разделаВ этом разделе будет рассмотрено следующее:

– Особенности функциональности в соответствующих новых функциях системы.

Основные вопросыЧто означает тестирование новой функции?

Что должно быть основным при тестировании удобства использования приложения?

Как называют автоматизированное тестирование пользовательского интерфейса?

Новые функции (feature, фитча) ПОФитчи, с точки зрения разработчика – это новая возможность доступная конечному пользователю.Фитчи доступные в проекте определяются главным образом пользовательскими историями создаваемыми в начале на этапе планирования.Часто каждая независимая пользовательская история является описанием фитчи в конечном продукте. Если пользовательская история устанавливает, что покупатель должен иметь возможность расплачиваться кредитной картой, впоследствии обслуживание клиентов по кредитным картам становится ключевой особенностью продукта.Фитчи могут перекрывать сходный функционал. Например, в том же самом проекте также существует возможность оплатить другим способом.Также, некоторые фитчи могут быть доступны различным образом. Подумайте, например, о том, как пользователь может подчеркнуть текст в редакторе Microsoft Word.

Тестирование новой функцииХотя хорошо спроектированные модульные и интеграционные тесты могут предоставить отличное покрытие кода и помочь обеспечить работу модулей в соответствии с внутренней спецификацией разработчиков, весьма важно чтобы функциональность каждой фитчи была протестированаКаждая фитча в приложении должна быть протестирована независимо.Тест, который проверяет функциональность отельной фитчи в приложении, независимой от других фитч, называется тестированием новой функции. В большинстве случаев для тестирования новых функций применяется метод черного ящика.Главная цель тестирования фитч является гарантия того, что реализованные фитчи соответствуют пользовательским требованиям.

Исследовательское тестированиеИногда именуемое специальным (ad hoc) тестированием, при котором тестировщик использует возможности программы различными способами. Часто, эффективные исследовательские тесты используют ПО таким образом, который разработчики не предполагали. Это может выявить неожиданные баги.Качественный исследовательский тест должен иметь план и соответствующие критерии. Если эти критерии не выполняются – тест считается проавленым.

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

Тестирование пользовательского интерфейса (UI) Любой тест взаимодействия с пользовательским интерфейсом или функции UI считается тестом пользовательского интерфейса.Так, как пользовательский интерфейс, как правило, является неотъемлемой частью реализацию фитчи, тестирование UI имеет решающее значение.Автоматизированное тестирование UI называют закодированными тестами пользовательского интерфейса (coded UI tests).Visual Studio позволяет разработчику создать создавать закодированные тести UI через запись действий во время работы программы.

Вопросы раздела

Что означает тестирование новой функции?

Что должно быть основным при тестировании удобства использования приложения?

Как называют автоматизированное тестирование пользовательского интерфейса?

3.5 Область тестирования

03 | Разработка тестов ПО

Обзор разделаВ этом разделе будет рассмотрено следующее:

– Область тестирования– Тема включает:

Граничные условия Уровень детализации Обоснованность

Основные вопросыЧто такое граничный тест?

Что такое тест по «удачному пути»?

В каком типе тестов необходимо указывать детальные шаги?

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

Например, приложение, которое запрашивает у пользователя ввести несколько чисел. Теоретически, возможен ввод бесконечного количества чисел!

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

Тестирование по «удачному пути»В TDD, включая модели agile, тесты пишут перед тем, как модуль написан. Часто первые тесты создаются для стандартных, ожидаемых данных.

Например, разработчик создает интерфейс авторизации для веб-сайта, он может начать с создания тестов используя действительные логин/пароль – тесты которые, как ожидаются, должны быть пройдены.

Некоторые тестировщики и разработчики называют этот случай как тестирование по удачному пути (happy path test).В то время, когда тесты по удачному пути являются отправной точкой, ясно, что дополнительные тесты явно необходимы.

Например, что произойдет при вводе недействительно логина?

Нулевой и Пустой тестовые случаи

В случае числовых данных, модуль должен тестироваться на корректную обработку нулевого значения.Также, нудно учитывать пустой ввод данных.В случае со строкой, может быть рекомендовано проверка на пустую строку (“”).

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

Например, если метод выполняет вычисления на основе вводимого пользователем номера месяца (1 для Января, 2 для Февраля, и т.д.), что произойдет, если введен месяц 13? Другие возможные граничные случаи могут быть 12 (наибольшее возможное значение), нуль, и отрицательное число.

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

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

Visual Studio позволяет вам прикреплять файл с дополнительными деталями или снимком экрана для помощи в тестировании.

Пример ручного тестирования

Рассмотренный пример авторизации может иметь такие шаги ручного тестирования:

“Кликнуть на ссылку «Авторизовать» в верхнем правом углу.”

“Ввести ваше имя в первое текстовое поле.”“Ввести пароль во второе текстовое поле.”“Нажать на конопку «Вход».”

Исследовательское тестирование

Команда разработчиков иногда дополняет детализованные тесты тестами исследовательского подхода, давая татуировщикам больше свободы.В этих тестовых случаях, направления могут быть более общими и направленными на фитчи:

“Выполнить авторизацию на веб-сайте.”

Вопросы раздела

Что такое граничный тест?

Что такое тест по «удачному пути»?

В каком типе тестов необходимо указывать детальные шаги?

Дополнительные ресурсы

MSDN Software Testing Resources

Modeling User Requirements http://msdn.microsoft.com/en- us/library/vstudio/dd409376.aspx

User Story (Agile) http://msdn.microsoft.com/en- us/library/dd380634.aspx

Testing Methodologies http://msdn.microsoft.com/en- us/library/ff649520.aspx

Testing in the Software Lifecycle http://msdn.microsoft.com/en-us/library/jj159342.aspx

Creating, Editing and Maintaining a Coded UI Test http://msdn.microsoft.com/en-us/library/ff977233.aspx

Creating and Running Unit Tests for Managed Code http://msdn.microsoft.com/en- us/library/ms182532.aspx

Manual System Tests http://msdn.microsoft.com/library/jj15933 4.aspx

Test Automation Code Review Guidelines http://msdn.microsoft.com/en- us/library/ff519670.aspx