mva stf module 3 - rus

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

Upload: maxim-shaptala

Post on 13-Feb-2017

473 views

Category:

Education


2 download

TRANSCRIPT

Page 1: Mva stf module 3 - rus

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

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

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

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

Page 3: Mva stf module 3 - rus

Click to edit Master subtitle style

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

Page 4: Mva stf module 3 - rus

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

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

Обзор

Page 5: Mva stf module 3 - rus

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

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

Page 6: Mva stf module 3 - rus

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

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

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

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

Page 7: Mva stf module 3 - rus

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

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

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

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

Page 8: Mva stf module 3 - rus

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

Page 9: Mva stf module 3 - rus

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

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

Page 10: Mva stf module 3 - rus

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

Page 11: Mva stf module 3 - rus

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

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

Page 12: Mva stf module 3 - rus

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

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

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

Page 13: Mva stf module 3 - rus

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

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

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

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

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

Page 14: Mva stf module 3 - rus

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

Page 15: Mva stf module 3 - rus

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

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

Page 16: Mva stf module 3 - rus

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

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

Page 17: Mva stf module 3 - rus

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

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

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

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

Page 18: Mva stf module 3 - rus

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

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

Page 19: Mva stf module 3 - rus

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

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

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

Page 20: Mva stf module 3 - rus

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

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

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

Page 21: Mva stf module 3 - rus

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

Page 22: Mva stf module 3 - rus

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

Page 23: Mva stf module 3 - rus

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

Page 24: Mva stf module 3 - rus

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

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

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

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

Page 25: Mva stf module 3 - rus

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

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

Page 26: Mva stf module 3 - rus

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

Page 27: Mva stf module 3 - rus

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

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

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

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

Page 28: Mva stf module 3 - rus

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

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

Page 29: Mva stf module 3 - rus

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

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

Page 30: Mva stf module 3 - rus

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

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

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

Page 31: Mva stf module 3 - rus

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

Page 32: Mva stf module 3 - rus

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

Page 33: Mva stf module 3 - rus

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

Page 34: Mva stf module 3 - rus

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

Page 35: Mva stf module 3 - rus

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

Page 36: Mva stf module 3 - rus

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

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

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

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

Page 37: Mva stf module 3 - rus

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

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

Page 38: Mva stf module 3 - rus

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

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

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

Page 39: Mva stf module 3 - rus

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

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

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

Page 40: Mva stf module 3 - rus

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

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

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

Page 41: Mva stf module 3 - rus

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

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

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

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

Page 42: Mva stf module 3 - rus

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

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

Page 43: Mva stf module 3 - rus

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

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

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

Page 44: Mva stf module 3 - rus

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

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

Page 45: Mva stf module 3 - rus

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

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

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

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

Page 46: Mva stf module 3 - rus

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

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

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

Page 47: Mva stf module 3 - rus

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

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

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

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

Page 48: Mva stf module 3 - rus

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

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