Mva stf module 3 - rus
- 1. Шаптала Максим | Компьютерная академия Шаг
- 2. Тестирование ПО 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 Управление тестовыми скриптами Содержание курса
- 3. 03 | Разработка тестов ПО
- 4. 1. Пользовательское централизованное тестирование 2. Тестируемость ПО 3. Разработка плана тестирования компонентов 4. Тестирование ключевых изменений 5. Appropriately Scoping Test Cases Обзор
- 5. 3.1 Пользовательское централизованное тестирование 3.2 Тестируемость ПО 03 | Разработка тестов ПО
- 6. Обзор раздела В этом разделе будут рассмотрено следующее: – Потребности и проблемы бизнеса, требования покупателей, сценарии – Разработка через тестирование – Testing hooks (Тестовая петля)
- 7. Основные вопросы Пример пользовательских требований? Какие преимущества разработки через тестирование? Какой тип тестов является основным для разработки через тестирования?
- 8. Пользовательские требования Пользовательские требования или диаграмма определяет что пользователям необходимо от системы или приложения. Они обсуждаются и формулируются на раннем этапе проектирования для гарантии того, что ПО обеспечит требования конечных пользователей. Пользовательские требования не пытаются объяснить внутреннее устройство или как система работает. Существует замечательные приложения для обсуждения с пользователями/заказчиками при agile разработке, которые позволяют сфокусироваться с самого начала на новой итерации. Существует множество способов документирования пользовательских требований включая диаграммы вариантов использования или пользовательские истории.
- 9. Диаграммы вариантов использования Диаграммы вариантов использования описывает кто использует систему и для чего. Диаграмма представляет цели пользователя и процедуры для достижения этих целей
- 10. Пример диаграммы вариантов использования Представим ПО для продажи еды онлайн. Оно должно позволять клиентам покупать еду, позволять ресторанам обновлять меню и доставлять еду. Диаграмма может выглядеть так:
- 11. Пользовательские истории Пользовательская история определяет функциональность продукта или системы которая представляет ценность для конечного пользователя. Каждая пользовательская история должна указывать на одну функциональную фичу, которую пользователь хочет получить от приложения и описать ее с точки зрения пользователя. Пользовательские истории могут вводиться в Microsoft® Visual Studio® и обычно выражаются предложением или коротким параграфом. Включение пользовательских историй в Visual Studio имеет множество преимуществ, включая возможность добавление ссылок на тесты и задачи присвоенные разработчикам.
- 12. Пример пользовательских историй “Как заказчик, я могу видеть текущее меню.” “Как заказчик, я могу сделать заказ.” “Как заказчик, я могу оплатить заказ.” “В ресторане, я могу добавлять блюда в текущее меню.” “В ресторане, я могу доставить заказ.”
- 13. Разработка через тестирование (TDD) Разработка через тестирование это техника программирования в которой используются модульные тесты как основное руководство для разработки программного обеспечения. Это означает, что вы разрабатывает тестовые случаи перед написанием кода. Затем разрабатывается функционал таким образом, что бы пройти существующие тесты. Этот подход имеет множество преимуществ: Разработка может начаться при недостаточно определенном наборе требований. Способствует разработке «слабо-связанного» кода – каждый модуль самодостаточный т.к. разрабатывается независимо от других. Тесты служат в качестве документации. Интенсивное использование автоматизированных тестов сокращает время на тестирование и позволяет быстро выполнить регрессионное тестирование.
- 14. Процесс разработки через тестирование
- 15. Testing Hooks (Тестовая петля) Testing hook это свойство, которое позволяет протестировать внутреннюю функциональность независимо от остальной части приложения. Например, можно позволить разработчику протестировать функции оплаты заказа без навигации по меню и добавления заказа в корзину. Hooks могут быть удалены или оставлены перед релизом или развертыванием приложения.
- 16. Другие примеры тестовой петли Последовательность нажатий клавиш, которая вызывает диалоговое окно информации о системе. Упрощенный пользовательский интерфейс, который позволяет получить упрощенный доступ к функциям без "удобства" для конечного пользователя. Аргументы командной строки, которые инициализируют данные автоматически, избавляя тестера в необходимости вводить данных вручную.
- 17. Вопросы раздела Пример пользовательских требований? Какие преимущества разработки через тестирование? Какой тип тестирования является основным для разработки через тестирования?
- 18. 3.3 Разработка плана тестирования компонентов 03 | Разработка тестов ПО
- 19. Обзор раздела В этом разделе будет рассмотрено: – График тестирования – Область тестирования – Методология – Сценарии – Инструменты
- 20. Основные вопросы Что такое управление жизненным циклом приложения (ALM)? Какое программное обеспечения является основным для управления жизненного цикла приложения в Microsoft® Visual Studio®? Что такое покрытие кода?
- 21. Управление жизненным циклом приложения Управление жизненным циклом приложений относится к управлению всего объема работ, необходимых для создания приложения от первоначального планирования до развертывания и технического обслуживания. Microsoft Visual Studio включает в себя тестно интегрированный набор ALM инструментов; ядром этого набора является Microsoft Visual Studio Team Foundation Server (TFS). TFS обеспечивает контроль версий, систему сборки, а также инструменты и метрики для управления и организации проектов.
- 22. ALM продолжение
- 23. ALM инструменты в Visual Studio PowerPoint Раскадровка (Storyboarding): Вы можете быстро визуализировать историю пользователя, требуется опыт работы с PowerPoint раскадровка. Product backlog: страница product backlog представляет информацию о текущей работе которая может быть динамично переопределена или сгруппирована. Sprint backlog и team capacity: страница sprint backlog отражает в режиме реального времени такие входные данные, как рабочие элементы, связанные с итерациями, даты, индивидуальную загруженность и отставание в работе как команды так и отдельных разработчиков. Task board: В повседневной практике, команда может просматривать и обновлять доску задач для визуального отображения состояния рабочих элементов. Request Feedback и Microsoft Feedback Client: инструменты позволяют группам привлекать заинтересованные стороны для получения обратной связи.
- 24. Стратегия тестирования и ее область Разработчикам необходимо как можно раньше обсудить и принять стратегию тестирования проекта. Часто стратегия определяется или на нее оказывает влияние методология разработки, например водопада или agile. Основываясь на этой стратегии, команда разрабатывает один или более планов тестирования. Каждый план тестирования имеет свою область: Весь проект может иметь план тестирования. В agile подходе каждый спринт или итерация должны иметь свой план тестирования. Он может быть или не быть похожим на другие планы тестирования спринтов или итераций. Для других моделей разработки, тесты имеют свои ключевые изменения и отличаться от тестирования спринтов/итераций.
- 25. Покрытие кода (Code Coverage) Стратегия тестирования может включать определенную цель в покрытии кода. Покрытие кода это метрика которая описывает какое количество исходного кода тестируется. Оно обычно выражается в процентах. Часто, команда разработчиков стремится к покрытию 80% исходного кода тестами. Эта цель будет принята как часть стратегии тестирования. В Visual Studio, покрытие кода вычисляется для: Блоков (Block coverage) Строк (Line coverage)
- 26. Покрытие кода в Visual Studio
- 27. Вопросы раздела Что такое управление жизненным циклом приложения (ALM)? Какое программное обеспечения является основным для управления жизненного цикла приложения в Microsoft® Visual Studio®? Что такое покрытие кода?
- 28. 3.3 Тестирование фитч 03 | Разработка тестов ПО
- 29. Обзор раздела В этом разделе будет рассмотрено следующее: – Особенности функциональности в соответствующих новых функциях системы.
- 30. Основные вопросы Что означает тестирование новой функции? Что должно быть основным при тестировании удобства использования приложения? Как называют автоматизированное тестирование пользовательского интерфейса?
- 31. Новые функции (feature, фитча) ПО Фитчи, с точки зрения разработчика – это новая возможность доступная конечному пользователю. Фитчи доступные в проекте определяются главным образом пользовательскими историями создаваемыми в начале на этапе планирования. Часто каждая независимая пользовательская история является описанием фитчи в конечном продукте. Если пользовательская история устанавливает, что покупатель должен иметь возможность расплачиваться кредитной картой, впоследствии обслуживание клиентов по кредитным картам становится ключевой особенностью продукта. Фитчи могут перекрывать сходный функционал. Например, в том же самом проекте также существует возможность оплатить другим способом. Также, некоторые фитчи могут быть доступны различным образом. Подумайте, например, о том, как пользователь может подчеркнуть текст в редакторе Microsoft Word.
- 32. Тестирование новой функции Хотя хорошо спроектированные модульные и интеграционные тесты могут предоставить отличное покрытие кода и помочь обеспечить работу модулей в соответствии с внутренней спецификацией разработчиков, весьма важно чтобы функциональность каждой фитчи была протестирована Каждая фитча в приложении должна быть протестирована независимо. Тест, который проверяет функциональность отельной фитчи в приложении, независимой от других фитч, называется тестированием новой функции. В большинстве случаев для тестирования новых функций применяется метод черного ящика. Главная цель тестирования фитч является гарантия того, что реализованные фитчи соответствуют пользовательским требованиям.
- 33. Исследовательское тестирование Иногда именуемое специальным (ad hoc) тестированием, при котором тестировщик использует возможности программы различными способами. Часто, эффективные исследовательские тесты используют ПО таким образом, который разработчики не предполагали. Это может выявить неожиданные баги. Качественный исследовательский тест должен иметь план и соответствующие критерии. Если эти критерии не выполняются – тест считается проавленым.
- 34. Тестирование удобства использования Это тестирование включает изучение того как конечный пользователь взаимодействует с ПО. Он предоставляет ценную обратную реакцию связанную с простотой использования и удовлетворенностью клиента. Несмотря на то, что тестирование удобства использования необязательная часть тестирования новой функции, изучение того, как пользователи используют определенные фитчи может дать представления о потенциальных недостатках. По умолчанию, эти тесты используют модель черного ящика.
- 35. Тестирование пользовательского интерфейса (UI) Любой тест взаимодействия с пользовательским интерфейсом или функции UI считается тестом пользовательского интерфейса. Так, как пользовательский интерфейс, как правило, является неотъемлемой частью реализацию фитчи, тестирование UI имеет решающее значение. Автоматизированное тестирование UI называют закодированными тестами пользовательского интерфейса (coded UI tests). Visual Studio позволяет разработчику создать создавать закодированные тести UI через запись действий во время работы программы.
- 36. Вопросы раздела Что означает тестирование новой функции? Что должно быть основным при тестировании удобства использования приложения? Как называют автоматизированное тестирование пользовательского интерфейса?
- 37. 3.5 Область тестирования 03 | Разработка тестов ПО
- 38. Обзор раздела В этом разделе будет рассмотрено следующее: – Область тестирования – Тема включает: Граничные условия Уровень детализации Обоснованность
- 39. Основные вопросы Что такое граничный тест? Что такое тест по «удачному пути»? В каком типе тестов необходимо указывать детальные шаги?
- 40. Рекомендации при выборе тестовых случаев В большинстве случаев, возможны разнообразные исходные данные для приложения, поэтому и возможные пути выполнения кода также весьма разнообразны. Например, приложение, которое запрашивает у пользователя ввести несколько чисел. Теоретически, возможен ввод бесконечного количества чисел! Следовательно, разработчики и тестеры должные допускать, что полное тестирование может быть невозможным. Разработка тестовый случаев позволяет выбрать такие варианты, которые имеют наиболее высокую вероятность выявления большинства дефектов ПО.
- 41. Тестирование по «удачному пути» В TDD, включая модели agile, тесты пишут перед тем, как модуль написан. Часто первые тесты создаются для стандартных, ожидаемых данных. Например, разработчик создает интерфейс авторизации для веб- сайта, он может начать с создания тестов используя действительные логин/пароль – тесты которые, как ожидаются, должны быть пройдены. Некоторые тестировщики и разработчики называют этот случай как тестирование по удачному пути (happy path test). В то время, когда тесты по удачному пути являются отправной точкой, ясно, что дополнительные тесты явно необходимы. Например, что произойдет при вводе недействительно логина?
- 42. Нулевой и Пустой тестовые случаи В случае числовых данных, модуль должен тестироваться на корректную обработку нулевого значения. Также, нудно учитывать пустой ввод данных. В случае со строкой, может быть рекомендовано проверка на пустую строку (“”).
- 43. Граничные тесты Граничные тесты фокусируются на поведении ПО при исходных данных близких к их минимальному или максимальному уровню. Эти граничные условия также называют крайние случаи. Например, если метод выполняет вычисления на основе вводимого пользователем номера месяца (1 для Января, 2 для Февраля, и т.д.), что произойдет, если введен месяц 13? Другие возможные граничные случаи могут быть 12 (наибольшее возможное значение), нуль, и отрицательное число. В общем случае, если значения около границ обрабатываются корректно, то это означает также корректное поведение в большинстве других случаях.
- 44. Варианты ручного тестирования В связи с тем, что ручное тестирование может выполнятся различными тестировщиками в различное время, весьма важно включить детальную информацию для обеспечения последовательности действий. Ручное тестирования разбивают на отдельные шаги, каждый из которых снабжается комментариями о действии и ожидаемом результате. Visual Studio позволяет вам прикреплять файл с дополнительными деталями или снимком экрана для помощи в тестировании.
- 45. Пример ручного тестирования Рассмотренный пример авторизации может иметь такие шаги ручного тестирования: “Кликнуть на ссылку «Авторизовать» в верхнем правом углу.” “Ввести ваше имя в первое текстовое поле.” “Ввести пароль во второе текстовое поле.” “Нажать на конопку «Вход».”
- 46. Исследовательское тестирование Команда разработчиков иногда дополняет детализованные тесты тестами исследовательского подхода, давая татуировщикам больше свободы. В этих тестовых случаях, направления могут быть более общими и направленными на фитчи: “Выполнить авторизацию на веб-сайте.”
- 47. Вопросы раздела Что такое граничный тест? Что такое тест по «удачному пути»? В каком типе тестов необходимо указывать детальные шаги?
- 48. Дополнительные ресурсы 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
Editor's Notes
- #2: 1
- #4: 3
- #30: Перевод Featurе Tests https://wiki.documentfoundation.org/QA/Testing/Feature_Tests/ru
- #33: While well-designed unit and integration tests may provide excellent code coverage and help ensure the units work meet the internal specifications of the developers, it is important that the functionality of each feature is tested. Each feature in an application should be tested independently. A test that focuses on the functionality of an individual feature in the software, independent of other features, is called a feature test. In many cases, black box testing is used to testing functionality The big-picture goal of feature testing is to ensure the features implemented in the software meet or fit the user requirements.