Курс UT-001. Основы тестирования для не
тестировщиков
1. Что такое тестирование?
1.1. Что такое тестирование?
Тестирование – это проверка, которая позволяет определить: соответствует ли реальное
поведение программы ожидаемому результату, выполнив специально подобранный набор
тестов.
В более широком смысле, тестирование - это одна из техник контроля качества, включающая в
себя активности по планированию работ, проектированию тестов, выполнению тестирования
и анализу полученных результатов.
Тест – это выполнение определенных условий и действий, необходимых для проверки работы
тестируемой функции программы или её части.
Сейчас тренд идет к тому, чтобы ошибки не находить, а предотвращать. Это объясняется тем,
что затраты на исправление найденных ошибок, значительно выше затрат на их
предотвращение.
Почему тестирование необходимо? Вопрос достаточно интересный, потому что часто люди
думают примерно так: «Зачем нам нужны тестировщики, если программисты при
определенном старании могут писать код без ошибок». Более опытные люди понимают, что
люди склонны ошибаться. Если говорить о программах, то это сложные системы и здесь без
ошибок никак. Одни ошибки безобидны, другие же опасны и дорого обходятся. Если есть
люди, которые ошибаются, то должны быть люди, которые будут проверять их работу. И тогда
можно говорить о том, что общее количество ошибок существенно уменьшится на
выпускаемом продукте.
Цели тестирования:
- для предотвращения дефектов;
- для обнаружения дефектов;
- для повышения уверенности в уровне качества;
- предоставление информации для принятия решений.
Тестирование – это информационный сервис предоставления качественной информации о
качестве продукта для обоснованного принятия бизнес решений. Опираясь на информацию о
качестве продукта, руководство может принимать решения о выходе продукта на рынок или
выпуске новой версии продукта.
Тестирование помогает уменьшить общий уровень риска в системе после обнаружения и
устранения дефектов и повышает качество ПО.
1.2. Что такое дефект?
Дефект (баг) – изъян в разработке программного продукта, который вызывает несоответствие
ожидаемых результатов выполнения программного продукта и фактически полученных
результатов. Основной упор в работе тестировщика делается на поиск дефектов или их
документирование.
Как определить дефект перед нами или нет:
1) Программа не делает что-то, что она должна делать согласно требованиям. В требованиях
написано, что должна, но она этого не делает. Очевидно – перед нами дефект.
2) Программа делает что-то, что она не должна делать согласно требованиям. Похожий на
первый пункт.
3) Программа делает что-то, о чем в требованиях не упоминалось. Тут два варианта: это дефект
программы или дефект требований (забыли дописать).
4) Программа не делает что-то, о чем не говорится в требованиях, однако подразумевается,
что она должна делать это. Подразумеваются неявные требования. При написании требований,
может показаться, что данное требование очевидное и поэтому не документируется. А
программист может не знать о таком моменте и упустить при написании кода.
5) Программа трудна для понимания, неудобна в использовании. Если взять две одинаковые
по функциональности программы, то очевидно, что пользователи будут пользоваться той,
которая удобнее.
1.3. Тестирование и качество
Качество программного обеспечения (Software Quality) – это степень, в которой программное
обеспечение обладает требуемой комбинацией свойств.
Отвечает ли тестировщик за качество? Считается, что тестировщик лично за качество не
отвечает. Но он помогает понять проблемные зоны. Тестировщик не может обеспечить
качество работы других участников проекта:
- Тестировщик не вносит изменения в код;
- Тестировщик, как правило, не может организационно повлиять на решение об исправлении
ошибок;
- Тестировщик не управляет ресурсами проекта, бюджетом проекта.
В проекте за качество отвечает менеджер проекта. Можно найти 1 000 дефектов, но от этого
качество продукта не повысится. А вот если эта 1 000 дефектов были исправлены и проверены,
то можно говорить, что качество продукта стало лучше.
Рассмотрим определения обеспечение качества, контроль качества и определим, где
находится тестирование.
В обеспечение качества входит:
- усовершенствование процессов;
- контроль качества;
- управление изменениями.
Контроль качества – часть активности по обеспечению качества.
В контроль качества входит:
- тестирование;
- рецензирование кода;
- статический анализ кода;
- внешняя оценка и аудит.
Тестирование – это одна из техник контроля качества, включающая в себя активности по
планированию работ (Test Management), проектированию тестов (Test Design), выполнению
тестирования (Test Execution) и анализу полученных результатов (Test Analysis).
1.4. Принципы тестирования
Совершенно очевидно, что если Тестирование это наука, то она должна опираться на
некоторые принципы.
Принцип 1 – тестирование демонстрирует наличие дефектов. Тестирование может показать,
что дефекты присутствуют, но не могут доказать, что их нет. Тестирование снижает вероятность
наличия дефектов, находящихся в ПО, но, даже если дефекты не были обнаружены, это не
доказывает его корректности.
Принцип 2 – исчерпывающее тестирование невозможно. Полное тестирование с
использованием всех комбинаций вводов и предусловий физически невыполнимо, за
исключением тривиальных случаев.
Принцип 3 – раннее тестирование. Сделать акцент на предотвращение дефектов вместо их
нахождения.
Принцип 4 – скопление дефектов. Разные модули системы могут содержать разное количество
дефектов – то есть, плотность скопления дефектов в разных элементах программы может
отличаться. Усилия по тестированию должны распределяться пропорционально фактической
плотности дефектов. В основном, большую часть критических дефектов находят в
ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем
содержатся в 20% модулей.
Принцип 5 – парадокс пестицида. Если одни и те же тесты будут прогоняться много раз, в
конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Что
бы преодолеть этот «парадокс», тестовые сценарии должны пересматриваться и
корректироваться. Тесты должны эволюционировать вместе с программой.
Принцип 6 – тестирование зависит от контекста. Например, проведение нагрузочного
тестирования или проверка функциональных требований.
Принцип 7 – заблуждение об отсутствии ошибок. Иногда тестируя и выискивая
функциональные баги, мы забываем посмотреть с другой стороны и спросить, а нужно ли это
пользователю. Если эта фича не соответствует ожиданиям пользователя и его потребностям, то
какой бы качественный наш продукт не был — это уже не так важно.
1.5. Виды тестирования
Все виды тестирования программного обеспечения, в зависимости от преследуемых целей,
можно условно разделить на следующие группы:
- функциональные;
- нефункциональные;
- связанные с изменениями.
Далее, мы постараемся более подробно рассказать о каждом отдельном виде тестирования,
его назначении и использовании при тестировании программного обеспечения.
Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с
другими системами. Функциональные виды тестирования рассматривают внешнее поведение
системы. Далее перечислены одни из самых распространенных видов функциональных тестов:
- Функциональное тестирование рассматривает заранее указанное поведение и основывается
на анализе спецификаций функциональности компонента или системы в целом;
- Тестирование безопасности – это стратегия тестирования, используемая для проверки
безопасности системы, а также для анализа рисков, связанных с обеспечением целостного
подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к
конфиденциальным данным;
- Тестирование взаимодействия – это тестирование, проверяющее способность приложения
взаимодействовать с одним и более компонентами или системами и включающее в себя
тестирование совместимости и интеграционное тестирование.
Нефункциональное тестирование описывает тесты, необходимые для определения
характеристик программного обеспечения, которые могут быть измерены различными
величинами. В целом, это тестирование того, "Как" система работает. Далее перечислены
основные виды нефункциональных тестов:
- Все виды тестирования производительности:
Нагрузочное тестирование - это автоматизированное тестирование, имитирующее работу
определенного количества бизнес пользователей на каком-либо общем (разделяемом ими)
ресурсе;
Стрессовое тестирование позволяет проверить насколько приложение и система в целом
работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к
возвращению к нормальному состоянию после прекращения воздействия стресса;
Тестирование стабильности (надежности) – это проверка работоспособности приложения при
длительном (многочасовом) тестировании со средним уровнем нагрузки;
Объемное тестирование – это получение оценки производительности при увеличении
объемов данных в базе данных приложения;
- Тестирование установки направленно на проверку успешной инсталляции и настройки, а
также обновления или удаления программного обеспечения;
- Тестирование удобства пользования – это метод тестирования, направленный на
установление степени удобства использования, обучаемости, понятности и привлекательности
для пользователей разрабатываемого продукта в контексте заданных условий;
- Тестирование на отказ и восстановление проверяет тестируемый продукт с точки зрения
способности противостоять и успешно восстанавливаться после возможных сбоев, возникших
в связи с ошибками программного обеспечения, отказами оборудования или проблемами
связи (например, отказ сети);
- Конфигурационное тестирование – это специальный вид тестирования, направленный на
проверку работы программного обеспечения при различных конфигурациях системы
(заявленных платформах, поддерживаемых драйверах, при различных конфигурациях
компьютеров и т.д.).
Связанные с изменениями виды тестирования. После проведения необходимых изменений,
таких как исправление бага/дефекта, программное обеспечение должно быть перетестировано
для подтверждения того факта, что проблема была действительно решена. Ниже перечислены
виды тестирования, которые необходимо проводить после установки программного
обеспечения, для подтверждения работоспособности приложения или правильности
осуществленного исправления дефекта:
- Дымовое тестирование (Smoke testing) – это короткий цикл тестов, выполняемый для
подтверждения того, что после сборки кода (нового или исправленного), устанавливаемое
приложение стартует и выполняет основные функции;
- Регрессионное тестирование – это вид тестирования направленный на проверку изменений,
сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на
другую операционную систему, базу данных, веб сервер или сервер приложения), для
подтверждения того факта, что существующая ранее функциональность работает как и прежде;
- Тестирование сборки – это тестирование, направленное на определение соответствия
выпущенной версии, критериям качества для начала тестирования. По своим целям является
аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее
тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от
требований к качеству выпущенной версии.
2. Кто такой тестировщик?
2.1. Кто такой тестировщик?
Портрет идеального тестировщика – это член проектной команды, который:
- Должен уметь разрушать программные продукты, не чувствуя угрызения совести;
- Не должен испытывать дискомфорта, обнаруживая ошибки в работе другого исполнителя
(это очень важно!!!);
- Должен описывать последовательность событий, которые приводят к возникновению
проблемы. Нередко приходится выполнять одни и те же действия. Часто это рутина, часто это
скучно, но это всё же работа тестировщика. Обращаю на это ваше внимание;
- Должен уметь критиковать и воспринимать критику. Нахождение ошибок в чужой работе –
это критика в чистом виде. Тестировщик должен воспринимать критику – иногда то, что он
находит – не является дефектом. Люди не всегда дружелюбно реагируют на то, что к ним
приходит кто-то и говорит: «что всё плохо и виноват в этом ты»;
- Должен уметь деликатно сообщать разработчикам и руководству плохие новости. В общем,
если в 11 часов вечера, в пятницу, не получается добиться нужного качества продукта – тестер
должен сообщить руководству эту плохую новость;
- Быть терпеливым и работать под давлением. Тестирование является завершающей стадией
разработки проекта. Как правило, чем ближе к финалу, тем больше напряжение. Разработчики
позже выкатили новую версию и у тестирования уже не 3 месяца на проверку – а два;
- Должен уметь легко и быстро осваивать новые технологии для повседневных работ. Не
всегда требуется глубокое погружение в технологию;
- Должен обладать гибким мышлением. Иногда требуется работать на нескольких модулях,
быстро переключаться между проектами/задачами.
2.2. Требования к сотруднику УТ
Требования, которые предъявляются к сотруднику управления тестирования:
Тот, кто:
- Способен письменно и устно излагать проблему;
- Способен одновременно выполнять несколько задач;
- Способен работать по расписанию;
- Способен работать в условиях давления;
- Наблюдателен, внимателен к деталям. Есть такая черта – въедливость. Для тестера не должно
существовать мелочей;
- Способен представить себя на месте другого и находить значимые для пользователя
(заказчика) дефекты;
- Командный игрок;
- Склонен к экспериментам в большей степени, чем к рассуждениям;
- Способен предугадать, где находятся ошибки
- Обладает тактом и дипломатичностью.
3. Тестирование - это не карьера (Автор: Джоэл Монтвелиски)
Это путешествие.
Поговорите с успешными тестировщиками, и вы увидите общую тенденцию. Большинство из
них не планировало стать тестировщиком – они стали ими практически случайно и пришли в
тестирование разными дорогами.
Если это так, то какая дорога лучше всего подходит для того, чтобы стать успешным
профессиональным тестировщиком?
Я, честно говоря, не знаю.
Более того, я даже не знаю, есть ли единственно верный путь.
Но я понял нечто куда более интересное, пообщавшись с многими успешными
тестировщиками за последние двадцать лет.
Мне понадобилось время, чтобы это осознать, так как для этого мне пришлось игнорировать и
то, что они делают, и то, что они мне говорят – чтобы сконцентрироваться на том, кто эти люди
и что их отличает от других.
Успешные тестировщики обладают вот такими качествами – я встречал их практически у
любого профессионала:
1. Эмпатия – способность видеть мир чужими глазами и понимать, что важно для людей.
2. Любопытство – способность глубоко копать и добираться до реальных причин
поведения систем, в то время как другие люди просто отбросят их как неинтересные
или не имеющие отношения к делу.
3. Технические навыки – чтобы иметь возможность глубоко покопаться в слоях
продукта, которые обычно не исследуются и не используются другими
тестировщиками.
4. Самообучение – они не ждут, пока их настигнет информация вместе со знаниями, они
ищут способы расширять свои горизонты самостоятельно.
5. Упорство – они не слышат ответа "НЕТ", когда люди говорят им, что они впустую тратят
время.
6. Коммуникация – они убеждаются, что правильно услышаны и поняты, когда им нужно
поделиться своими идеями.
7. Скромность – они понимают, что пошли не по той дороге, и корректируют свои
действия, при этом их эго не страдает.
8. Настойчивость – они понимают, что результаты приходят не от быстрых забегов, а от
длинных марафонов.
Я знаю, что подобных списков и людей, пишущих их, очень много, но я считаю свой
достаточно полезным. Когда меня спрашивают, как стать лучшим тестировщиком, я начинаю с
вопросов по списку и интересуюсь, есть ли у них эти качества.
Если их нет, я предлагаю поискать другую работу.
А если они есть, я прошу их поискать способы применять эти навыки, чтобы стать
профессионалами. Если все сделано верно и с умом, со временем они станут великими
тестировщиками.
Файлы 001. Материал
001Презентация
Курс UT-002. Введение в тестирование
Введение
Основной всплеск интереса к теме тестирования начался в США и пришёлся на 90-е годы.
Бурное развитие систем автоматизированной разработки ПО (CASE-средств) и сетевых
технологий привело к росту рынка производства ПО и к пересмотру вопросов обеспечения
качества и надёжности разрабатываемых программ.
Резко усилившаяся конкуренция между производителями ПО потребовала особого внимания к
качеству создаваемых продуктов, так как теперь у потребителя был выбор: многие фирмы
предлагали свои продукты и услуги по достаточно приемлемым ценам, а потому можно было
обратиться к тем, кто разрабатывает программы не только быстро и дёшево, но и качественно.
Осознавая, что обеспечение высокого качества разрабатываемого ПО, это реальный путь
«обойти» конкурентов, многие компании во всём мире вкладывают всё больше средств в
обеспечение качества своих продуктов. Они создают собственные группы и отделы,
занимающиеся тестированием, или передают тестирование своих продуктов сторонним
организациям.Наиболее крупные компании, заботящиеся о своей репутации и желающие
пройти сертификацию на высокий уровень CMMI (Capability Maturity Model Integration),
создают свои собственные системы управления качеством (Quality Management System),
направленные на постоянное совершенствование производственных процессов и повышение
качества ПО.
Сегодня вопрос о качестве ПО имеет особую важность. От программного обеспечения зависит
не только эффективность производственного процесса, но и жизни людей (медицинская,
военная и космическая сфера). Тестирование стало обязательной частью процесса
производства ПО. Оно направлено на обнаружение и устранение максимального числа
ошибок. Следствием такой деятельности является повышение качества ПО по всем его
характеристикам.
Существующие на сегодняшний день методы тестирования программного обеспечения не
позволяют однозначно и полностью устранить ВСЕ дефекты и ошибки и установить
корректность функционирования программного продукта, поэтому эти методы действуют в
рамках формального процесса проверки/верификации исследуемого или разрабатываемого
программного продукта. Такой процесс может доказать, что дефекты отсутствуют с точки
зрения используемого метода. То есть нет никакой возможности точно установить или
гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора,
присутствующего на всех этапах жизненного цикла программного обеспечения.
Существует множество подходов к решению задачи тестирования и верификации
программного обеспечения, но эффективное тестирование сложных программных продуктов
— это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким
процедурам или созданию таковых. Конечной целью любого процесса тестирования является
обеспечение такого ёмкого (совокупного) понятия как качество, с учётом всех или наиболее
критичных для данного конкретного случая составляющих.
1. Жизненный цикл разработки ПО и место тестирования в нем
На данной схеме представлены обобщенные этапы разработки программного обеспечения и
соответствующие им этапы тестирования. Дополнительно приведен пример действий на
каждом из этапов.
2. Определения тестирования
Тестирование программного обеспечения (Software Testing) - проверка соответствия между
реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов,
выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge,
SWEBOK, 2004].
В более широком смысле, тестирование - это одна из техник контроля качества, включающая
в себя активности по планированию работ (Test Management), проектированию тестов (Test
Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test
Analysis).
Общий взгляд на тестирование программного обеспечения последние годы активно
эволюционировал, становясь все более конструктивным, прагматичным и приближенным к
реалиям современных проектов разработки программных систем. Тестирование более не
рассматривается как деятельность, начинающаяся только после завершения фазы
конструирования. Сегодня тестирование рассматривается как деятельность, которую
необходимо проводить на протяжении всего процесса разработки и сопровождения, и
является важной частью конструирования программных продуктов. Действительно,
планирование тестирования должно начинаться на ранних стадиях работы с требованиями,
необходимо систематически и постоянно развивать и уточнять планы тестов и
соответствующие процедуры тестирования. Даже сами по себе сценарии тестирования
оказываются очень полезными для тех, кто занимается проектированием, позволяя выделять
те аспекты требований, которые могут неоднозначно интерпретироваться или даже быть
противоречивыми.
3. Основные термины тестирования
Автономное тестирование — тестирование подпрограмм, модулей, компонент, другими
словами, тестирование нижнего уровня.
Альфа-тестирование — тестирование программного продукта штатными работниками, либо
потенциальными заказчиками на стороне разработчика. Чаще всего это внутреннее
приёмочное тестирование для готового продукта. Иногда этот вид тестирования выполняется с
использованием окружения, которое помогает быстро выявить ошибки. После чего,
обнаруженные ошибки передаются тестировщикам для дополнительного исследования в
окружении, близком к тому, в котором будет использоваться ПО.
Артефакт — семантически законченная часть информации, которая формируется,
редактируется или используется процессами. Артефакт может выступать в виде модели, или ее
элемента, а так же в виде документа.
Аттестация (Validation) — подтверждение экспертизой соответствия программного продукта
установленным требованиям. Аттестацию чаще всего проводят для готового продукта в
заданных условиях эксплуатации. Не исключено проведение аттестации и на более ранних
стадиях.
Бета-тестирование — распространение среди потенциальных пользователей готовой
версии продукта с ограничениями (по функциональности или времени работы), с целью
выявление и устранения максимального количество ошибок.
Выпуск — версия элемента конфигурации для реализации конкретной цели (к примеру,
тестируемый выпуск).
Инсталляционное тестирование (Installation Testing) — проверить корректную установку
системы при различных условиях с софтом и хардом: недостаток места на диске,
недостаточные системные требования, отсутствие привилегий создания директорий и т.д.
Проверка работы системы при обновлении со старой версии на новую, так же как и установки
с нуля. Установка в различных локализациях.
Интеграционное, или интегральное тестирование (Integration Testing) — полная проверка
программного продукта после его сборки, с целью выявления ошибок, возникающих в
процессе интеграции программных модулей или компонентов.
Квалификационное испытание — тестирование программного продукта разработчиком (при
необходимости санкционированное заказчиком) с целью демонстрации соответствия данного
продукта установленным требованиям, а также оценки его готовности к эксплуатации в
заданных условиях.
Конфигурационное тестирование (Configuration Testing) — работа при различных
конфигурациях системы – заявленных платформах, поддерживаемых драйверах, при
различных конфигурациях компьютеров и т.д.
Модульное (Unit-) тестирование — тестирование отдельных компонентов, изолируя модули
от их реального окружения. Эти тесты служат для проверки правильности работы отдельных
модулей системы, как правило – классов. Использует White Box Testing.
Нагрузочное тестирование, или тестирование производительности (Performance/Load
Testing) — тестирование продукта при заданных известных нагрузках, которые определяются в
терминах числа пользователей, объема данных и скорости их обработки (времени отклика).
Проводится отдельно от функционального тестирования, на специальном оборудовании
(стенде).
Оценка — определение степени соответствия объекта (продукта, системы) заданным
критериям.
Приемосдаточные испытания — контрольные испытания программы перед сдачей в
эксплуатацию.
Проверка реализации протокола (Conformance Testing) — проверка соответствия
реализации протокола установленным требованиям должна выполняться прежде, чем смогут
быть выполнены дальнейшие проверки. Этот тип проверок выполняется автоматически
запуском стандартных, независимых тестов, каждый из которых имеет свою цель. Часто
требуется также представление результата «pass/fail» (соответствие/не соответствие),
указывающего причину любой неисправности. Автоматические тесты предлагают
исчерпывающий набор испытательных сценариев, которые индивидуально применяют
стимулы, чтобы проверить, что протоколы соответствующим образом откликаются/изменяют
состояние.
Прототип — работающая модель программы с неполным функционалом.
Проверка эргономичности или Юзабилити-тестирование (Usability testing) — тестирование,
выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как
веб-страница, пользовательский интерфейс или устройство) для его предполагаемого
применения. Таким образом, проверка эргономичности измеряет эргономичность объекта или
системы. Проверка эргономичности сосредоточена на определённом объекте или небольшом
наборе объектов.
Регрессионное тестирование (Regression Testing) — повторное тестирование программы
после ее функционального усовершенствования или исправления. При регрессионном
тестировании перед тестировщиками ставятся следующие задачи:
1) убедиться, что все ошибки исправлены;
2) гарантировать функциональную преемственность и совместимость новой версии с
предыдущими.
Сборочное тестирование — совместное последовательное тестирование компонент
программы в процессе сборки.
Системное тестирование — тестируется интегрированная система на её соответствие
исходным требованиям.
Стрессовое тестирование (Stress Testing) — тестирование программного продукта в таких
экстремальных условиях, как нехватка памяти, одновременное использование большим
числом пользователей, функционирование в непрерывном режиме и т.д. Цель этой операции
— убедиться, что функциональность не «ломается», когда с системой работает большое число
пользователей, что в принципе может приводить к различным конфликтам.
Тестирование «белого ящика» (White Box Testing) — тестирование на соответствие
программного продукта требованиям со знанием внутренней структуры реализации системы
(есть в наличии исходный код и технические спецификации). Это вид тестирования позволяет
проводить локализацию ошибок, анализ надежности и устойчивости и т.п., существенно
повышая качество системы.
Тестирование «черного ящика» (Black Box Testing) — тестирование на соответствие
программного продукта требованиям без знания внутренней структуры реализации системы.
Тестирование программного обеспечения — процесс, помогающий определить
корректность, полноту и качество разработанного программного обеспечения (ПО). По
статистике, мероприятия по тестированию занимают порядка 40% от всего процесса
разработки продукта.
Тестируемость (Testability) — это степень, до которой могут быть запланированы
реализуемость и объективность тестирования.
Тестовое покрытие — полнота тестирования системы или программного продукта.
Функциональное тестирование (Functional Testing). Чтобы проверить конкретные
функциональные возможности основных протоколов и конкретные функции сетевого
элемента, предлагаемые производителем, нужно провести функциональную проверку
правильности поведения протоколов сетевых элементов при нормальных и аварийных
условиях. Гибкие инструменты имитации протоколов, запускаемые GUI, предоставляют
возможность передавать и принимать сообщения вручную или автоматически, таким образом,
уменьшая количество сообщений, которые пользователю нужно создавать.
GUI-тесты (тестирование пользовательского интерфейса) — это тестирование графического
интерфейса — окон, меню, кнопок, списков и т.д. Как правила, через пользовательский
интерфейс и реализуется большая часть функциональности ПО.
4. Стоимость исправления дефектов
Некоторое время назад ряд компаний провели исследование оценки стоимости ошибок,
возникающих на разных этапах создания программ. Каждая фирма действовала независимо,
тем не менее, результаты получены примерно одинаковые: если стоимость усилий,
необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за
единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет
в 5–10 раз меньше, а стоимость обнаружения и устранения ошибки на стадии сопровождения –
в 20 раз больше.
Оценка стоимости ошибок на разных этапах создания программного обеспечения
Откуда берется такая высокая стоимость ошибки? Ко времени обнаружения ошибки в
требованиях группа разработчиков уже могла потратить время и усилия на создание проекта
по этим ошибочным требованиям. В результате проект, вероятно, придется отбросить или
пересмотреть.
Истинная природа ошибки может быть замаскирована; при проведении тестирования и
проверок на данной стадии все думают, что имеют дело с ошибками проектирования, и
значительное время и усилия могут быть потрачены впустую.
В зависимости от того, где и когда при работе над проектом разработки программного
приложения был обнаружен дефект, цена его может разниться в 50–100 раз.
Причина состоит в том, что для его исправления придется затратить средства на некоторые
(или все) ниже перечисленные действия:
- Повторная спецификация.
-·Повторное проектирование.
-·Повторное кодирование.
-·Повторное тестирование.
-·Замена заказа - сообщить клиентам и операторам о необходимости заменить дефектную
версию исправленной.
-·Внесение исправлений - выявить и устранить все неточности, вызванные неправильным
функционированием ошибочно специфицированной системы, что может потребовать
выплаты определенных сумм возмущенным клиентам, повторного выполнения определенных
вычислительных задач на ЭВМ и т.п.
-·Списание той части работы (кода, части проектов и т.п.), которая выполнялась с наилучшими
побуждениями, но оказалась ненужной, когда обнаружилось, что все это создавалось на
основе неверных требований.
-·Отзыв дефектных версий встроенного программного обеспечения и соответствующих
руководств. Если принять во внимание, что программное обеспечение сегодня встраивается в
различные изделия – от наручных часов и микроволновых печей до автомобилей - такая
замена может коснуться как этих изделий, так и встроенного в них программного обеспечения.
-·Выплаты по гарантийным обязательствам.
-· Ответственность за изделие - если клиент через суд требует возмещение убытка,
причиненного некачественным программным продуктом.
-· Затраты на обслуживание - представитель компании должен посетить клиента, чтобы
установить новую версию программного обеспечения.
-· Создание документации.
5. Модели и методологии разработки
Итеративная модель разработки
Итеративный подход в разработке программного обеспечения — это выполнение работ
параллельно с непрерывным анализом полученных результатов и корректировкой
предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит
повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-docheck-act cycle).
Итеративная модель предполагает разбиение жизненного цикла проекта на
последовательность итераций, каждая из которых напоминает “мини-проект”, включая все
фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по
сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии
программной системы, включающей функциональность, определенную интегрированным
содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит
всю требуемую функциональность продукта.
Преимущества итеративного подхода:









снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к
минимизации затрат на их устранение;
организация эффективной обратной связи проектной команды с потребителем (а также
заказчиками) и создание продукта, реально отвечающего его потребностям;
акцент усилий на наиболее важные и критичные направления проекта;
непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в
целом;
раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;
более равномерная загрузка участников проекта;
эффективное использование накопленного опыта;
реальная оценка текущего состояния проекта и, как следствие, большая уверенность
заказчиков и непосредственных участников в его успешном завершении.
затраты распределяются по всему проекту, а не группируются в его конце.
Каскадная модель разработки
Каскадная модель (водопадная) (англ.waterfall model)—модель процесса разработки
программного обеспечения, в которой процесс разработки выглядит как поток,
последовательно проходящий фазы анализа требований, проектирования, реализации,
тестирования, интеграции и поддержки. В качестве источника названия часто указывают
статью, опубликованную У.У.Ройсом (W.W.Royce) в1970 году; при том, что сам Ройс
использовал итеративную модель разработки.
Содержание модели:
В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть
«каскадная модель», и обсуждал недостатки этой модели. Там же он показал, как эта модель
может быть доработана до итеративной модели.
В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:







Определение требований
Проектирование
Конструирование (также «реализация» либо «кодирование»)
Воплощение
Тестирование и отладка (также «верификация»)
Инсталляция
Поддержка
Переход от одной фазы к другой происходит только после полного и успешного завершения
предыдущей
Следуя каскадной модели, разработчик переходит от одной стадии к другой строго
последовательно. Сначала полностью завершается этап «определение требований», в
результате чего получается список требований к ПО. После того как требования полностью
определены, происходит переход к проектированию, в ходе которого создаются документы,
подробно описывающие для программистов способ и план реализации указанных требований.
После того как проектирование полностью выполнено, программистами выполняется
реализация полученного проекта. На следующей стадии процесса происходит интеграция
отдельных компонентов, разрабатываемых различными командами программистов. После
того как реализация и интеграция завершены, производится тестирование и отладка продукта;
на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки.
После этого программный продукт внедряется и обеспечивается его поддержка— внесение
новой функциональности и устранение ошибок.
Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой
происходит только после полного и успешного завершения предыдущей фазы, и что
переходов назад либо вперёд или перекрытия фаз— не происходит.
Тем не менее, существуют модифицированные каскадные модели (включая модель самого
Ройса), имеющие небольшие или даже значительные вариации описанного процесса.
Спиральная модель разработки
Спиральная модель, предложенная Барри Боэмом в 1986 году, стала существенным прорывом
в понимании природы разработки ПО. Она представляет собой процесс разработки
программного обеспечения, сочетающий в себе как проектирование, так и прототипирование
по стадиям с целью сочетания преимуществ восходящей и нисходящей концепции, делающая
упор на начальные этапы жизненного цикла: анализ и проектирование. Отличительной
особенностью этой модели является специальное внимание рискам, влияющим на
организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по
приоритетам) рисков:










Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
«Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих окружение системы или
вовлечённых в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
«Разрыв» в квалификации специалистов разных областей знаний.
Большая часть этих рисков связана с организационными и процессными аспектами
взаимодействия специалистов в проектной команде.
Каждый виток спирали соответствует созданию фрагмента или версии программного
обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и
планируются работы следующего витка спирали. Таким образом, углубляются и
последовательно конкретизируются детали проекта и в результате выбирается обоснованный
вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:




оценка и разрешение рисков,
определение целей,
разработка и тестирование,
планирование.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В
конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности
модели прототипирования и водопадной модели. Разработка итерациями отражает
объективно существующий спиральный цикл создания системы. Неполное завершение работ
на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения
работы на текущем. При итеративном способе разработки недостающую работу можно будет
выполнить на следующей итерации. Главная задача — как можно быстрее показать
пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения
и дополнения требований. Основная проблема спирального цикла — определение момента
перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на
каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже
если не вся запланированная работа закончена. План составляется на основе статистических
данных, полученных в предыдущих проектах, и личного опыта разработчиков. Одним из
возможных подходов к разработке программного обеспечения в рамках спиральной модели
жизненного цикла является получившая в последнее время широкое распространение
методология быстрой разработки приложений RAD (Rapid Application Development). Под этим
термином обычно понимается процесс разработки программного обеспечения, содержащий 3
элемента:
1. небольшую команду программистов (от 2 до 10 человек);
2. короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);
3. повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает
обретать форму, запрашивают и реализуют в продукте требования, полученные через
взаимодействие с заказчиком.
Жизненный цикл программного обеспечения по методологии RAD состоит из четырёх фаз:
1.
2.
3.
4.
фаза определения требований и анализа;
фаза проектирования;
фаза реализации;
фаза внедрения.
Спиральная модель ориентирована на большие, дорогостоящие и сложные проекты. В
условиях, когда бизнес цели таких проектов могут измениться, но требуется разработка
стабильной архитектуры, удовлетворяющей высоким требованиям по нагрузке и устойчивости,
имеет смысл применение Spiral Architecture Driven Development. Данная методология,
включающая в себя лучшие идеи спиральной модели и некоторых других, позволяет
существенно снизить архитектурные риски, что является немаловажным фактором успеха при
разработке крупных систем.
Критика каскадной модели и гибридные методологические решения:
Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и
объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и
качеству. Тем не менее, при управлении большими проектами формализация часто являлась
очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать
его более прозрачным. Поэтому даже в PMBOK 3-ей версии формально была закреплена
только методика «каскадной модели» и не были предложены альтернативные варианты,
известные как итеративное ведение проектов.
Начиная с PMBOK 4-ой версии удалось достичь компромисса между методологами,
приверженными формальному и поступательному управлению проектом, с методологами,
делающими ставку на гибкие итеративные методы. Таким образом, начиная с 2009 года,
формально Институтом Проектного Менеджмента (PMI) предлагается как стандарт гибридный
вариант методологии управления проектами, сочетающий в себе как плюсы от методики
«Водопада», так и достижения итеративных методологов.
Гибкая методология разработки (англ. Agile software development, agile-методы) — серия
подходов к разработке программного обеспечения, ориентированных на использование
итеративной разработки, динамическое формирование требований и обеспечение их
реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих
групп, состоящих из специалистов различного профиля. Существует несколько методик,
относящихся к классу гибких методологий разработки, в частности экстремальное
программирование, DSDM, Scrum.
Большинство гибких методологий нацелены на минимизацию рисков путём сведения
разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три
недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и
включает все задачи, необходимые для выдачи мини-прироста по
функциональности: планирование, анализ требований, проектирование, программирование,
тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для
выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к
выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет
переоценку приоритетов разработки.
Agile - методы делают упор на непосредственное общение лицом к лицу. Большинство agile
команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает
и «заказчиков» (англ. Product owner— заказчик или его полномочный представитель,
определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнесаналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса,
технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение
непосредственному общению, agile-методы уменьшают объём письменной документации по
сравнению с другими методами. Это привело к критике этих методов как
недисциплинированных.
История:
В феврале 2001 в штате Юта США был выпущен «Манифест гибкой методологии разработки
программного обеспечения». Он являлся альтернативой управляемым документацией,
«тяжеловесным» практикам разработки программного обеспечения, таким как «метод
водопада», являвшимся золотым стандартом разработки в то время. Данный манифест был
одобрен и подписан представителями методологий экстремального программирования, Crystal
Clear, DSDM, Feature driven development, Scrum, Adaptive software development, Pragmatic
Programming. Гибкая методология разработки использовалась многими компаниями и до
принятия манифеста, однако именно после этого события произошло вхождение Agileразработки в массы.
Принципы:


Agile — семейство процессов разработки, а не единственный подход в разработке
программного обеспечения, и определяется Agile Manifesto. Agile не включает практик, а
определяет ценности и принципы, которыми руководствуются успешные команды.
Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge
at Snowbird в горах Юты. Манифест подписали представители следующих методологий
Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature
driven development, Pragmatic Programming. Agile Manifesto содержит 4 основные идеи и 12
принципов. Примечательно, что Agile Manifesto не содержит практических советов.
Основные идеи:




люди и взаимодействие важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий контракта;
готовность к изменениям важнее следования первоначальному плану.
Принципы, которые разъясняет Agile Manifesto:












удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного
обеспечения;
приветствие изменений требований даже в конце разработки (это может повысить
конкурентоспособность полученного продукта);
частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё
чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными
условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее программное обеспечение — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать
постоянный темп на неопределённый срок;
постоянное внимание улучшению технического мастерства и удобному дизайну;
простота — искусство не делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной
команды;
постоянная адаптация к изменяющимся обстоятельствам.
Критика:
Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием
плана («дорожной карты») развития продукта, равно как и управлением, требованиями, в
процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями
не подразумевает далеко идущих планов (по сути, управления требованиями просто не
существует в данной методологии), а подразумевает возможность заказчика вдруг и
неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие
архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к
катастрофическим «авралам» с массовым рефакторингом и переделками практически на
каждой очередной итерации.
Кроме того, считается, что работа в agile мотивирует разработчиков решать все поступившие
задачи простейшим и быстрейшим возможным способом, при этом, зачастую не обращая
внимания на правильность кода с точки зрения требований нижележащей платформы (подход
— «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем
изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у
клиента). Это приводит к снижению качества продукта и накоплению дефектов.
Методологии:
Существуют методологии, которые придерживаются ценностей и принципов заявленных в
Agile Manifesto, некоторые из них:

Agile Modeling — набор понятий, принципов и приёмов (практик), позволяющих быстро и
просто выполнять моделирование и документирование в проектах разработки
программного обеспечения. Не включает в себя детальную инструкцию по
проектированию, не содержит описаний, как строить диаграммы на UML. Основная цель:









эффективное моделирование и документирование; но не охватывает программирование и
тестирование, не включает вопросы управления проектом, развёртывания и
сопровождения системы. Однако включает в себя проверку модели кодом.
Agile Unified Process (AUP) упрощенная версия IBM Rational Unified Process (RUP),
разработанная Скоттом Амблером, которая описывает простое и понятное приближение
(модель) для создания программного обеспечения для бизнес-приложений.
Agile Data Method — группа итеративных методов разработки программного обеспечения,
в которых требования и решения достигаются в рамках сотрудничества разных кроссфункциональных команд.
DSDM основан на концепции быстрой разработки приложений (Rapid Application
Development, RAD). Представляет собой итеративный и инкрементный подход, который
придаёт особое значение продолжительному участию в процессе
пользователя/потребителя.
Essential Unified Process (EssUP).
Экстремальное программирование (Extreme programming, XP).
Feature driven development (FDD) — функционально-ориентированная разработка.
Используемое в FDD понятие функции или свойства (англ. feature) системы достаточно
близко к понятию прецедента использования, используемому в RUP, существенное
отличие — это дополнительное ограничение: «каждая функция должна допускать
реализацию не более, чем за две недели». То есть если сценарий использования достаточно
мал, его можно считать функцией. Если же велик, то его надо разбить на несколько
относительно независимых функций.
Getting Real — итеративный подход без функциональных спецификаций, использующийся
для веб-приложений. В данном методе сперва разрабатывается интерфейс программы, а
потом её функциональная часть.
OpenUP — это итеративно-инкрементальный метод разработки программного
обеспечения. Позиционируется как лёгкий и гибкий вариант RUP. OpenUP делит жизненный
цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и
передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным
лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего
проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать
решения о приемлемости результатов. План проекта определяет жизненный цикл, а
конечным результатом является окончательное приложение.
Scrum устанавливает правила управления процессом разработки и позволяет использовать
уже существующие практики кодирования, корректируя требования или внося тактические
изменения. Использование этой методологии дает возможность выявлять и устранять
отклонения от желаемого результата на более ранних этапах разработки программного
продукта.
Бережливая разработка программного обеспечения (англ. lean software development)
использует подходы из концепции бережливого производства.
6. Виды тестирования
Классификация видов тестирования
Существует несколько признаков, по которым принято производить классификацию видов
тестирования. Обычно выделяют следующие:




В зависимости от исполнения\неисполнения кода
Статическое
Динамическое
По объекту тестирования




























Функциональное тестирование
Нефункциональное тестирование
По знанию системы
Тестирование чёрного ящика
Тестирование белого ящика
Тестирование серого ящика
По степени автоматизации
Ручное тестирование
Автоматическое тестирование
Полу автоматизированное тестирование
По степени изолированности компонентов
Модульное тестирование
Интеграционное тестирование
Системное тестирование
По времени проведения тестирования
Альфа-тестирование
Дымовое тестирование (англ. smoke testing)
Тестирование новой функции (new feature testing)
Подтверждающее тестирование
Регрессионное тестирование
Приёмочное тестирование
Бета-тестирование
По признаку позитивности сценариев
Позитивное тестирование
Негативное тестирование
По степени подготовленности к тестированию
Тестирование по документации (формальное тестирование)
Интуитивное тестирование (англ. ad hoc testing)
Статическое тестирование и динамическое тестирование
Тестирование программного обеспечения делятся на статическое и динамическое. Главной
задачей статического тестирования является найти недостатки уже в фазах проектирования
программы и спецификации. Во время статического тестирования можно также проверить
свойства системы, такие как ремонтопригодность, надежность.
Проведение статического тестирования может значительно снизить затраты на разработку
программного обеспечения и уменьшить время, необходимое для разработки программного
обеспечения. Тем не менее, необходимо помнить, что статическое тестирование не является
заменой динамического тестирования и нельзя гарантировать, что программное обеспечение,
прошедшее только статическое тестирование, будет работать безупречно. Инструменты
статического анализа уведомляют разработчиков программного обеспечения о таких
недостатках как непригодный для использования программный код, неописанные переменные
ит.д.
Динамическое тестирование делится:


функциональное тестирование
структурное тестирование.
Функциональное тестирование рассматривает заранее указанное поведение и основывается на
анализе спецификаций функциональности компонента или системы в целом.
Функциональные тесты основываются на функциях, выполняемых системой, и могут
проводиться на всех уровнях тестирования (компонентном, интеграционном, системном,
приемочном). Как правило, эти функции описываются в требованиях, функциональных
спецификациях или в виде случаев использования системы (use cases).
Преимущества функционального тестирования:

имитирует фактическое использование системы;
Недостатки функционального тестирования:


возможность упущения логических ошибок в программном обеспечении;
вероятность избыточного тестирования.
Функциональные методы тестирования также известны как «Black Box» (черный ящик).
При структурных методах тестирования применяемые тесты исходят из внутренней структуры
программного обеспечения и их называют также методы «White Box» (белый ящик).
Черный, белый, серый ящики
Метод черного ящика
При использовании метода чёрного ящика (black-box testing) тестировщик имеет доступ к ПО
только через те же интерфейсы, что и заказчик или пользователь, либо через внешние
интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к
системе для тестирования. Например, тестирующий модуль может виртуально нажимать
клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия
процессов. Эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок
мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций
или иных документов, описывающих требования к системе.
Тестировщик тестирует программу так, как с ней будет работать конечный пользователь, и он
ничего не знает о внутренних механизмах и алгоритмах, по которым работает программа.
Другими словами, он запускает приложение на выполнение и тестирует его функциональность,
используя пользовательский интерфейс для ввода входных и получения выходных данных. Но
как при этом обрабатываются входные данные, он не знает. Цель данного метода – проверить
работу всех функций приложения на соответствие функциональным требованиям.
Метод белого ящика
Для тестирования программного кода без его непосредственного запуска применяется метод
белого ящика (white-box testing, glass-box testing).При тестировании с использованием метода
белого ящика тестировщик имеет доступ к исходному коду ПС и может писать код, который
связан с библиотеками тестируемого ПС. Это типично для компонентного тестирования (юниттестирования, unit-testing), при котором тестируются только отдельные части системы. Такие
тесты основаны на знании кода приложения и его внутренних механизмов.
Метод белого ящика часто используется на стадии, когда приложение ещё не собрано
воедино, но необходимо проверить каждый из его компонентов, модулей, процедур и
подпрограмм. Также отметим, что компонентным тестированием (unit testing), чаще всего
занимается программист, хорошо понимающий код, или тестировщик, имеющий прекрасные
знания в области программирования.
Метод серого ящика.
Основная разница между тестированиями по методу чёрного и белого ящиков состоит в том,
что метод чёрного ящика может скрыть проблемы, которые метод белого ящика обнаружит.
Так, метод чёрного ящика может не сообщить о некорректном функционировании объекта,
потому что проблемы в работе оказались незаметны. Метод белого ящика может обнаружить
этот некорректный объект или функцию, проведя их по специальному пути исполнения кода.
Этот метод позволяет тестировщику заглянуть внутрь «чёрного ящика» и сосредоточиться на
внутренней информации, которая и определяет поведение системы, позволяет управлять
выбором нужных тестовых данных.
Существует также метод серого ящика (gray box testing), который представляет собой нечто
среднее между методами белого и чёрного ящиков. Этот метод, как правило, используется при
тестировании веб-приложений, когда тестировщик знает принципы функционирования
технологий, на которых построено приложение, но может не видеть кода самого приложения.
7. Понятие дефекта
«Днём рождения» первого компьютерного дефекта считается 9 сентября 1945 года. В
Гарвардском университете в то время работал небольшой компьютер «Mark II Aiken Relay
Calculator». В этот день с машиной возникли проблемы, и исследование показало, что мотылёк
попал между контактами реле №70 в панели F. Операторы извлекли мотылька и сделали
соответствующую запись в журнале: «Обнаружен первый настоящий баг». (Англ. «bug» – жук,
насекомое).
Определения дефекта
Рассмотрим несколько определений дефекта:
1. «Быстрое тестирование» (Роберт Калбертсон, Крис Браун, Гэри Кобб): «Программная ошибка
– ни что иное, как изъян в разработке программного продукта, который вызывает
несоответствие ожидаемых результатов выполнения программного продукта и фактически
полученных результатов.»
2. «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернетстартапах» (Роман Савин): «Итак, баг (bug) – это отклонение фактического результата (actual
result) от ожидаемого результата (expected result). В соответствии с законом исключённого
третьего у нас есть баг при наличии любого фактического результата, отличного от
ожидаемого.»
3. Википедия. «В целом, разработчики различают дефекты программного обеспечения и сбои.
В случае сбоя программа ведёт себя не так, как ожидает пользователь. Дефект – это
ошибка/неточность, которая может быть (а может и не быть) следствием сбоя»
4. Сергей Мартыненко (блог «255 ступеней»). «Дефект – поведение программы, затрудняющее
или делающее невозможным достижение целей пользователя или удовлетворение интересов
участников. Подразумевает возможность исправления. При невозможности исправления
переходит в разряд ограничения технологии»
Мы будем использовать простое определение:
Дефект – это несоответствие требованиям или функциональным спецификациям.
Также следует помнить, что к дефектам относится любое некорректное поведение программы,
не соответствующее оправданным ожиданиям пользователя, даже в том случае, если это
поведение не документировано в требованиях и спецификациях.
Ошибки могут встречаться в любой документации, в архитектуре и дизайне, в коде программы
и т.д. Иногда баг на самом деле является не ошибкой в программе, а результатом неверного
конфигурирования программы и/или окружения.
8. Структура грамотного отчета о дефекте
Отчёт об ошибке – это технический документ, написанный с целью:



Предоставить информацию о проблеме, ее свойствах и последствиях
Выставить приоритет проблемы по важности
Помочь программистам обнаружить и устранить источник проблемы
Отчёт об ошибке («баг-репорт», «bug report») – один из основных результатов работы
тестировщиков. И, к слову, именно этот результат работы видят коллеги (другие тестировщики
и люди, не входящие в команду тестировщиков).
Формула хорошего отчета об ошибке состоит из трёх простых пунктов:



Что мы сделали (steps required to reproduce the problem).
Что мы получили (actual results).
Что мы ожидали получить (expected results).
Кроме того, нужно сообщить, где именно произошла проблема, при каких условиях, а также
дать краткое описание ошибки.
Основные составляющие баг-репорта.
Шапка
Короткое описание
(Summary)
Короткое описание проблемы, явно указывающее на причину и
тип ошибочной ситуации.
Проект (Project)
Наименование тестируемого проекта в котором обнаружен
дефект.
Номер версии (Version)
Версия на которой была найдена ошибка.
Приоритет (Priority)
Блокирующий - Блокирует работы по разработке и/или
тестированию. Блокирует функционирование системы.
Критический - Сбои, потеря данных
Важный - Создание / потеря важной функции
Обычный - Создание / потеря незначительной
функциональности или другая проблема, где есть временное
решение
Незначительный - Косметические проблемы (орфография,
форматирование текста)
Описание или тело дефекта
Шаги воспроизведения
(Steps to Reproduce)
Шаги, по которым можно легко воспроизвести ситуацию,
приведшую к ошибке.
Фактический Результат
(Result)
Результат, полученный после прохождения шагов к
воспроизведению.
Шапка
Ожидаемый результат
(Expected Result)
Результат, в соответствии с техническим заданием или
логическим поведением системы.
Пользователь (User)
Пользователь с определенным набором ролей, при наличии
которых возникает дефект.
База данных (Data base)
База данных или стенд где воспроизводится дефект
Дополнительная информация
Прикрепленный файл
(Attachment)
Файл с логами, скриншот, ссылка на техническое задание
(постановку) или любой другой документ, который может
помочь прояснить причину ошибки или указать на способ
решения проблемы.
9. Общий жизненный цикл дефекта
Рассмотрим рисунок, иллюстрирующий жизненный цикл дефекта, принятый во многих
крупных компаниях
Дефект может находиться в одном из представленных на рисунке состояний.
Обнаружен (submitted). Итак, тестировщик находит дефект и представляет его на
рассмотрение в систему управления дефектами. С этого момента баг начинает свою
официальную жизнь и о его существовании знают необходимые люди.
Назначен (assigned). Далее ведущий разработчик рассматривает дефект и назначает его
исправление кому-то из команды разработчиков.
Исправлен (fixed). Разработчик, которому было назначено исправление дефекта, исправляет
его и сообщает о том, что задание выполнено.
Проверен (verified). Тестировщик, который обнаружил ошибку проверяет на новом билде (в
котором исправление данной ошибки заявлено), исправлен ли дефект на самом деле. И только
в том случае, если ошибка не проявится на новом билде, тестировщик меняет статус бага на
Verified.
Открыт заново (reopened). Если баг проявляется на новом билде, тестировщик снова
открывает этот дефект. Баг приобретает статус Reopened.
Отклонён (declined). Баг может быть отклонён. Во-первых, потому, что для заказчика какие-то
ошибки перестают быть актуальными. Во-вторых, это может случится по вине тестировщика
из-за плохого знания продукта, требований (дефекта на самом деле нет).
Отложен (deferred). Если исправление конкретного бага сейчас не очень важно или заказчик
пока думает, или мы ждём какую-то информацию, от которой зависит исправление бага, тогда
баг приобретает статус Deferred.
Закрытые (closed) ошибки. Закрытым считается дефект в состояниях Проверен (verified) и
Отклонён (declined).
Открытые (open) дефекты. Открытыми являются ошибки в состояниях Обнаружен
(submitted), Назначен (assigned), Открыт заново (reopened). Иногда к открытым относят и
ошибки в состояниях Исправлен (fixed) и Отложен (deferred).
10. Классификация дефектов
Ранее данное определение понятия «дефект» («ошибка») не является универсальным, так как
оно больше подходит для понятия «программная ошибка». В технологии программирования
существуют не только программные ошибки, но и ошибки, связанные с созданием
программного продукта, например, ошибки в документации программы. Но нас пока будут
интересовать программные ошибки.
Итак, по времени появления ошибки можно разделить на три вида:
• структурные ошибки набора;
• ошибки компиляции;
• ошибки периода выполнения.
Структурные ошибки возникают непосредственно при наборе программы. Что это за
ошибки? Если кто-то работал в среде разработки Microsoft Visual Basic, то он знает, что если
набрать оператор If, затем сравнение и нажать на клавишу Enter, не набрав слова Then, то
Visual Basic укажет, что возникла ошибка компиляции. Это не совсем верно, так как
компиляция в Visual Basic происходит только непосредственно при выполнении команды
программы. В данном случае мы имеем дело именно со структурной ошибкой набора.
Данный тип ошибок определяется либо при наборе программы (самой IDE (Integrated
Development Environment) – интегрированной средой разработки) или при ее компиляции,
если среда не разделяет первые два типа ошибок.
К данному типу ошибок относятся такие как: несоответствие числа открывающих скобок
числу закрывающих, отсутствие парного оператора (например, try без catch), неправильное
употребление синтаксических знаков и т. п.
Во многих средах разработки программного обеспечения данный тип ошибок объединяется
со следующим типом, так как раннее определение ошибок вызывает некоторое неудобство
при наборе программ (скажем, я задумал что-то написать, а потом вспомнил, что в начале
пропустил оператор, тогда среда разработки может выдать мне ошибку при попытке перейти в
другую строку).
Еще раз нужно отметить, что данный тип ошибок достаточно уникален и выделяется в
отдельный тип только некоторыми средами разработки программного обеспечения.
Ошибки компиляции возникают из-за ошибок в тексте кода. Они включают ошибки в
синтаксисе, неверное использование конструкций языка (оператор else в операторе for и т. п.),
использование несуществующих объектов или свойств, методов у объектов.
Среда разработки (компилятор) обнаружит эти ошибки при общей компиляции
приложения и сообщит о последствиях этих ошибок. Необходимо подчеркнуть слово
«последствия» – это очень важно. Дело в том, что часто, говоря об ошибках, мы не разделяем
проявление ошибки и саму ошибку, хотя это и не одно и то же. Например, ошибка
«неопределенный класс» не означает, что класс не определен. Он может быть
неподключенным, так как не подключен пакет классов.
Ошибки периода выполнения возникают, когда программа выполняется и компилятор (или
операционная система, виртуальная машина) обнаруживает, что оператор делает попытку
выполнить недопустимое или невозможное действие. Например, деление на ноль.
Предположим, имеется такое выражение:
ratio = firstValue / sum.
Если переменная sum содержит ноль, то деление – недопустимая операция, хотя сам
оператор синтаксически правилен. Прежде, чем программа обнаружит эту ошибку, ее
необходимо запустить на выполнение.
Хотя данный тип ошибок называется «ошибками периода выполнения», это не означает, что
ошибки находятся только после запуска программы. Вы можете выполнять программу в уме и
обнаружить ошибки данного типа, однако, понятно, что это крайне неэффективно.
Если проанализировать все типы ошибок согласно первой классификации, то можно прийти
к заключению, что при тестировании приходится иметь дело с ошибками периода выполнения,
так как первые два типа ошибок определяются на этапе кодирования.
В теоретической информатике программные ошибки классифицируют по степени
нарушения логики на:
• синтаксические;
• семантические;
• прагматические.
Синтаксические ошибки заключаются в нарушении правописания или пунктуации в
записи выражений, операторов и т. п., т. е. в нарушении грамматических правил языка. В
качестве примеров синтаксических ошибок можно назвать:
• пропуск необходимого знака пунктуации;
• несогласованность скобок;
• пропуск нужных скобок;
• неверное написание зарезервированных слов;
• отсутствие описания массива.
Все ошибки данного типа обнаруживаются компилятором.
Семантические ошибки заключаются в нарушении порядка операторов, параметров
функций и употреблении выражений. Например, параметры у функции add (на языке Java) в
следующем выражении указаны в неправильном порядке:
GregorianCalendar.add(1, Calendar.MONTH).
Параметр, указывающий изменяемое поле (в примере – месяц), должен идти первым.
Семантические ошибки также обнаруживаются компилятором.
Надо отметить, что некоторые исследователи относят семантические ошибки к
следующей группе ошибок.
Прагматические ошибки (или логические) заключаются в неправильной логике
алгоритма, нарушении смысла вычислений и т. п. Они являются самыми сложными и крайне
трудно обнаруживаются. Компилятор может выявить только следствие прагматической
ошибки (см. выше пример с делением на ноль, компилятор обнаружит деление на ноль, но
когда и почему переменная sum стала равна нулю – должен найти программист).
Таким образом, после рассмотрения двух классификаций ошибок можно прийти к
выводу, что на этапе тестирования ищутся прагматические ошибки периода выполнения, так
как остальные выявляются в процессе программирования.
На этом можно было бы закончить рассмотрение классификаций, но с течением
времени накапливался опыт обнаружения ошибок и сами ошибки, некоторые из которых
образуют характерные группы, которые могут тоже служить характерной классификацией.
Ошибка адресации – ошибка, состоящая в неправильной адресации данных (например,
выход за пределы участка памяти).
Ошибка ввода-вывода – ошибка, возникающая в процессе обмена данными между
устройствами памяти, внешними устройствами.
Ошибка вычисления – ошибка, возникающая при выполнении арифметических операций
(например, разнотипные данные, деление на нуль и др.).
Ошибка интерфейса – программная ошибка, вызванная несовпадением характеристик
фактических и формальных параметров (как правило, семантическая ошибка периода
компиляции, но может быть и логической ошибкой периода выполнения).
Ошибка обращения к данным – ошибка, возникающая при обращении программы к
данным (например, выход индекса за пределы массива, не инициализированные значения
переменных и др.).
Ошибка описания данных – ошибка, допущенная в ходе описания данных.
Первичное выявление ошибок
В течение многих лет большинство программистов были убеждены в том, что
программы пишутся исключительно для выполнения их на машине и не предназначены для
чтения человеком, а единственным способом тестирования программы является ее
исполнение на ЭВМ. Это мнение стало изменяться в начале 70-х годов в значительной степени
благодаря книге Вейнберга «Психология программирования для ЭВМ». Вейнберг показал, что
программы должны быть удобочитаемыми и что их просмотр должен быть эффективным
процессом обнаружения ошибок.
По этой причине, прежде чем перейти к обсуждению традиционных методов
тестирования, основанных на применении ЭВМ, рассмотрим процесс тестирования без
применения ЭВМ («ручное тестирование»), являющийся по сути первичным обнаружением
ошибок. Эксперименты показали, что методы ручного тестирования достаточно эффективны с
точки зрения нахождения ошибок, так что один или несколько из них должны использоваться
в каждом программном проекте.
Описанные здесь методы предназначены для периода разработки, когда программа
закодирована, но тестирование на ЭВМ еще не началось. Аналогичные методы могут быть
получены и применены на более ранних этапах процесса создания программ (т. е. в конце
каждого этапа проектирования).
Следует заметить, что из-за неформальной природы методов ручного тестирования
(неформальной с точки зрения других, более формальных методов, таких, как математическое
доказательство корректности программ) первой реакцией часто является скептицизм,
ощущение того, что простые и неформальные методы не могут быть полезными. Однако их
использование показало, что они не «уводят в сторону». Скорее эти методы способствуют
существенному увеличению производительности и повышению надежности программы.
Во-первых, они обычно позволяют раньше обнаружить ошибки, уменьшить стоимость
исправления последних и увеличить вероятность того, что корректировка произведена
правильно.
Во-вторых, психология программистов, по-видимому, изменяется, когда начинается
тестирование на ЭВМ. Возрастает внутреннее напряжение и появляется тенденция «исправлять
ошибки так быстро, как только это возможно». В результате программисты допускают больше
промахов при корректировке ошибок, уже найденных во время тестирования на ЭВМ, чем при
корректировке ошибок, найденных на более ранних этапах.
Кроме того, скептицизм связан с тем, что это «первобытный метод». Сейчас стоимость
машинного времени очень низка, а стоимость труда программиста, тестировщика высока и ряд
руководителей пойдут на все, чтобы сократить расходы. Однако, есть другая сторона ручного
тестирования – при тестировании за компьютером причины ошибок выявляются только в
программе, а самая глубокая их причина – мышление программиста, как правило, не
претерпевает изменений, при ручном же тестировании, программист глубоко анализирует
свой код, попутно выявляя возможные пути его оптимизации, и изменяет собственный стиль
мышления, повышая квалификацию. Таким образом, можно прийти к выводу, что ручное
тестирование можно и нужно проводить на первичном этапе, особенно, если нет прессинга
времени и бюджета.
Файлы. Введение в тестирование (презентация)
Курс UT-003. Управление задачами
тестирования
Введение
Тренинг сфокусирован на изучении основ управления дефектами. Рассматриваются вопросы
качества требований. Описываются типы и виды дефектов, в том числе в разрезе различных
приложений и предметных областей. Тренинг содержит практическую часть с использованием
системы управления дефектами Atlassian Jira.
По результатам прохождения тренинга слушатели:



смогут правильно оценить и описать дефекты, а в дальнейшем корректно работать с ними;
смогут проводить тестирование согласно разработанному плану;
получат навык работы с базой дефектов с использованием инструментов JIRA.
1. Общие понятия о JIRA и Issue
JIRA - это продукт, предназначенный для организации процесса контроля запросов и задач,
имеющий часть функциональности обычно присущей большим и дорогим системам
управления проектами.
Ключевыми понятиями в JIRA являются проекты (project) и задачи (issue). Issue создаются в
проектах, для выполнения задач, назначаются исполнители. Задачи могут быть разного типа и
иметь подзадачи, задачи могут быть связанными с другими задачами. Статус задач меняется в
процессе их выполнения.
2. Жизненный цикл дефекта
2.1. Поиск существующего дефекта перед созданием нового
Перед созданием нового дефекта, необходимо убедиться в том, что в системе нет
аналогичного дефекта. Если дефект не исправлен, то создавать новый запрещено, можно
дописать в комментарий существующего дефекта о том, что у вас тоже повторяется такой
дефект и написать свои условия повторения (возможно это ускорит исправление дефекта).
Для поиска дефекта необходимо перейти в меню Поиск -> Поиск запросов:
Заполнить поля "Проект" (Ваш проект) и "Тип запроса" (Дефект). В поле "Содержит текст",
написать часть текста Вашей ошибки, или любую связанную с Вашим дефектом информацию,
если ваш дефект не вызывает форм с ошибками. После этого нажать кнопку "Искать запросы"
(см.скриншот) или Enter на клавиатуре:
Просмотреть отображаемые записи на наличие Вашего дефекта
2.2. Создание дефекта
Для создания дефекта, необходимо нажать кнопку "Создать":
Заполнить обязательные поля "Проект", "Тип запроса", "Тема", "Приоритет", "Бюджет проекта
ПУ", "Сборка с ошибкой". Поле описание, необходимо заполнить по шаблону:
Нажать кнопку "Создать". Справа вверху будет всплывающее сообщение о создании новой
задачи. Для просмотра созданной записи необходимо успеть кликнуть по этому сообщению.
Если не успели, или задачу нужно открыть позже, всегда можно открыть список созданных
Вами задач перейдя в меню Поиск - > Созданные мной
Созданную задачу необходимо открыть и убедиться, что поле "Исполнитель" заполнилось
автоматически (ФИО исполнителя необходимо уточнить у своего непосредственного
руководителя, обычно это тимлид разработки). Задача создаётся на статусе НОВЫЙ
2.3. Принятие в работу разработкой
Все новые дефекты рассматриваются тимлидом разработки. Дефект может быть закрыт как
дубль, если в работе есть аналогичные дефекты. Принятый разработкой дефект переводится на
статус ПРИНЯТ, указывается срок исправления и тестирования дефекта. При этом создаются 2
подзадачи с типом "Разработка (Дефект)" и "Тестирование (Дефект)". Затем на статус В РАБОТЕ. В
подзадаче с типом "Разработка (Дефект)" тимлид разработки устанавливает срок исправления
дефекта и исполнителя.
2.4. Ожидание исправления дефекта
Тимлид тестирования ожидает исправления принятых в работу дефектов. Исправленные
дефекты попадают к нему в бэклог (виджет с фильтром дефектов, в которых подзадача
"Разработка (Дефект)" на статусе ЗАКРЫТ, а подзадача "Тестирование (Дефект)" на НОВЫЙ).
Также, тимлид тестирования может отслеживать важные и\или срочные дефекты, зная их
номера или отслеживая их в отдельном фильтре.
2.5. Тестирование дефекта
В исправленных дефектах, тимлид тестирования планирует её в TimeLine. После этого,
переводит подзадачу "Тестирование (Дефект)" на статус ПРИНЯТ при этом указывает оценку в
часах, срок и запланированного исполнителя.
После перевода подзадачи "Тестирование (Дефект)" на статус ПРИНЯТ, исполнителю приходит
почтовое оповещение. У исполнителя данная задача отображается в фильтре назначенных ему
задач.
Тестировщик, выбирает из списка назначенных ему задач наиболее приоритетную, переводит
подзадачу на статус В РАБОТЕ и только после этого, приступает к её тестированию.
2.6. Переоткрытие разработки, диалог с разработчиком
Если тестировщик выясняет, что дефект не исправлен, то он сообщает об этом разработчику в
комментарии к задаче с типом "Дефект" и переоткрывает подзадачу "Разработка (Дефект)",
переводя её на статус В РАБОТЕ
Также, тестировщик и разработчик могут переписываться в комментариях к задаче с типом
"Дефект" друг на друга символом @:
2.7. Создание связанных дефектов (в т.ч. и блокирующих тестирование)
Если в ходе тестирования текущей задачи были созданы новые дефекты, то их необходимо
связать с первоначальной задачей. Для этого в исходной задаче необходимо нажать
кнопку Другие действия и в выпадающем списке выбрать "Связь"
В открывшейся форме, в поле "Данный запрос", необходимо выбрать тип связи:


если новый дефект не блокирует дальнейшую проверку текущей задачи, то "связан с"
если новый дефект блокирует дальнейшую проверку текущей задачи, то "блокирован"
В поле "Запрос", необходимо вставить или напечатать вручную номер вашего запроса,
например AP-12345:
После этого нажать кнопку "Связь" внизу формы. Записи будут связаны между собой. Новая
связанная задача отобразится в блоке связи запроса:
Для удаления связи, необходимо навести курсор мыши на удаляемый дефект и нажать кнопку в
виде корзины:
2.8. Завершение тестирования, написание результата тестирования
После завершения работ по тестированию дефекта, необходимо закрыть подзадачу
"Тестирование (Дефект)". Для этого нажать кнопку Сделано.
В открывшейся форме необходимо заполнить поля "Резолюция", "Протестировано в сборке", "
Результат тестирования":
После заполнения полей, необходимо нажать кнопку "Сделан", подзадача "Тестирование
(Дефект)" перейдёт на статус ЗАКРЫТ
Далее, необходимо перейти в вышестоящую задачу с типом "Дефект". Назначить себя
исполнителем, нажав "Назначить мне" под исполнителем:
и нажимая на кнопку Сделано перевести дефект на статус СДЕЛАН.
3. Прикрепление файлов к задаче
В созданную задачу можно прикрепить файл (скриншот, видео, файл лога). Для прикрепления
файла к задаче, необходимо просто перетащить его как показано на скриншоте:
4. Жизненный цикл доработки
4.1. Создание доработки
При необходимости реализации нового функционала системы или внесения изменений в
ранее реализованный функционал, сотрудники аналитического отдела создают задачу с типом
"Доработка". После создания, задачи с типом "Доработка", её исполнитель переводит задачу в
работу, создаются подзадачи:





Аналитика (Доработка) - написание постановки на доработку
Разработка - реализация функционала
Тестирование (Доработка) - тестирование сотрудниками ДОК
Документирование (Доработка) - добавление информации в техническую
документацию
Функциональное тестирование - финальное тестирование функционала
сотрудниками аналитического отдела
4.2. Принятие в работу аналитикой
Тимлид аналитического отдела принимает подзадачу Аналитика (Доработка), назначает
исполнителя и указывает срок исполнения.
Аналитик, указанный исполнителем подзадачи Аналитика (Доработка), берёт подзадачу в
работу, пишет постановку в конфлюенсе (новую или вносит изменения в существующую), с
подробным описанием работы всех элементов формы и логикой работы полей,
взаимодействия с другими модулями системы. Аналитик связывает страницу с
постановкой с главной задачей с типом Доработка:
По окончанию работ по написанию постановки, аналитик закрывает подзадачу Аналитика
(Доработка):
4.3. Принятие в работу разработкой
После закрытия подзадачи Аналитика (Доработка) тимлид разработки назначает
исполнителя в подзадаче Разработка и указывает срок исполнения.
Разработчик, указанный исполнителем подзадачи Разработка, берёт подзадачу в работу,
выполняет правки в коде ПО. По окончанию работ по подзадаче Разработка, закрывает её,
заполняя поле "Сборка исправленная"
4.4. Ожидание реализации доработки
До момента закрытия подзадачи Разработка, тимлид ДОК, при необходимости, планирует
подзадачу Тестирование (Доработка) в TimeLine. Открывает подзадачу Тестирование
(Доработка) на редактирование, указывает исполнителя, оценку и срок.
После закрытия подзадачи Разработка, тимлид ДОК принимает подзадачу Тестирование
(Доработка), нажимая на кнопку принять в работу, указывает исполнителя, оценку и срок
(если это не было сделано ранее).
4.5. Изучение постановки на доработку
Тестировщик, принимает в работу подзадачу Тестирование (Доработка) нажимая на
кнопку взять в работу, изучает постановку, открывая её по ссылке в главной задаче с
типом Доработка. При необходимости, обсуждает отдельные моменты с аналитиком и\или
разработчиком.
4.6. Написание ТК на основании постановки, перевод ТК по статусам
Тестировщик, изучив постановку, создаёт новую задачу с типом Test, привязывает её к
подзадаче с типом Тестирование (Доработка). Перечисляет все шаги которые он будет
выполнять при тестировании доработки. После завершения написания ТК, тестировщик
переводит задачу с типом Test на статус ПРОВЕРКА. Тимлид, после проверки ТК, переводит его
на статус ГОТОВ
4.7. Тестирование доработки, выполнение ТК
Для начала тестирования, тестировщик открывает задачу с типом Test, нажимает
кнопку выполнить. В открывшемся окне указывает версию и назначает выполнение себе:
После заполнения полей, нажимает кнопку выполнить
В открывшемся выполнении ТК, тестировщик, выполняет шаги ТК, указывая статус на каждом
шаге





UNEXECUTED - тест ещё не выполнялся
PASS - тест был выполнен и завершился успешно
FAIL - тест был выполнен и завершился дефектом
WIP - тест в работе
BLOKED - выполнение теста этого теста было заблокировано по каким-то причинам
 4.8. Создание связанных с доработкой дефектов (в т.ч. и блокирующих тестирование)
 При нахождении дефектов, тестировщик создаёт задачи с типом Дефект, указывает их
номера в колонке "Дефекты" проваленного шага и ставит статус FAIL:
Созданный дефект тестировщик связывает с задачей с типом Доработка (см. п. 2.7)
4.9. Создание связанных с доработкой поручений (в т.ч. и блокирующих тестирование), с
вопросами к аналитике
При нахождении спорных ситуаций (ошибка бизнес-логики в постановке либо не полное
описание либо не понятное тестировщику описание), тестировщик создаёт задачу с
типом Поручение, в которой заполняет необходимые для его проекта поля, ставит статус WIP:
4.10. Ожидание выполнения поручений, диалог с аналитиком
Задача с типом Поручение попадает в бэклог тимлиду аналитики. Тимлид аналитики назначает
исполнителя и указывает срок.
Аналитик, изучив вопрос, отвечает тестировщику в коментарий поручения и переводит задачу
с типом Поручение на статус СДЕЛАН.
Дальнейшее обсуждение вопроса может проходить как в формате переписки в комментариях,
так и в личной переписке или беседе.
После полного оказания консультации, тестировщик сообщает об этом в комментарий.
Например, "Консультация оказана. Спасибо". Возвращается к пропущенному шагу ТК и
проходит его.
Далее тимлид тестирования переводит Поручение на статус ЗАКРЫТ
4.11. Корректировка ТК после исправления постановки
Если по каким либо причинам, в постановку были внесены изменения, тестировщик обязан
внести изменения в ТК и выполнить изменённые шаги повторно.
4.12. Ожидание исправления дефектов
Если в проверяемой доработке исправление дефектов затянулось, тестировщик сообщает об
этом тимлиду тестирования. Тимлид тестирования делает запрос сроков исправления у
тимлида разработки и, после их получения, корректирует план тестирования.
4.13. Ретест доработки после исправления связанных дефектов
Если, в ходе тестирования доработки, было выявлено большое кол-во дефектов, тимлид
тестирования обсуждает доработку с тестировщиком и при необходимости принимает
решение о ускоренном ретесте доработки, планирует дополнительное время на тестирование
доработки.
4.14. Завершение тестирования, написание результата тестирования
После успешного выполнения всех шагов ТК (все шаги PASS) система предложит проставить
общий статус выполнения ТК на PASS. После этого, тестировщик переводит
подзадачу Тестирование (Доработка) на статус ЗАКРЫТ указывая протестированную версию
и результат тестирования.
5. Работа с фильтрами JIRA
5.1. Создание (фильтр назначенных мне задач в работе)
Фильтры - это поиски запросов, которые были сохранены для повторного использования.
1.Создание фильтров происходит через пункт "Поиск" - "Поиск запросов" в верхнем меню
системы.
Рассмотрим создание фильтра на примере - Назначенных мне задач в определенном проекте
со статусом "В работе".
2. В верхнем меню можно увидеть параметры поиска запросов в "Базовом режиме"
"Продвинутый режим" существует для рукописного ввода формул отбора, для более сложных
формул. Подробнее в справке по синтаксису
- https://confluence.atlassian.com/jirasoftwareserver071/advanced-searching-800707146.html
3. В первом параметре "Проект" выбираем необходимый нам проект из
выпадающего списка.
4. В параметре "Тип запроса" выделяем чек-боксами необходимые нам запросы, например:


"Тестирование (Дефект)"
"Тестирование (Доработка)".
Данные параметры означают что создаваемый фильтр, будет отображать в себе значения
только по подзадачам тестирования дефектов и доработок
5. Далее в параметре "Статус" выбираем статус "В работе".
Данный статус означает, то что в фильтре будут отображаться задачи по которым в данный
момент времени ведется работа.
6. В параметре "Исполнитель", указываем "Текущего исполнителя" или выбираем из списка
необходимого пользователя.
На этом создание фильтра завершено.
5.2. Сохранение фильтра
После того как мы завершили создание нашего фильтра, его необходимо сохранить для
дальнейшего использования.
1. Для это на панели инструментов нажимаем на кнопку "Сохранить как".
2. После, необходимо дать название нашему фильтру (название может быть произвольным).
3. Сохраняем созданный фильтр, нажатием на кнопку "Отправить".
5.3. Корректировка ранее созданного фильтра
1. Для корректировки созданного фильтра, необходимо перейти через пункт меню "Поиск" "Управление фильтрами".
2. В открывшейся форме переходим к созданному фильтру.
Открываем фильтр нажатием на название.
3. Далее открывается уже знакомая нам форма Создания\Редактирования фильтра.
Здесь мы можем изменить\добавить необходимые нам значения в сам фильтр через параметр
"Еще".
Так же для наглядного отображения информации можно добавить столбцы.
Для это нажать на кнопку "Столбцы" и чек-боксами выделить необходимые нам значения.
4. После внесении изменений в фильтр его нужно сохранить, для этого нажимает кнопку
"Сохранить" рядом с названием фильтра.
5.4. Открытие общего доступа
Для предоставления доступа необходимо перейти в пункт "Поиск" - "Управление фильтрами"
нажить на кнопку Шестеренка и выбрать пункт "Редактировать". По умолчанию доступ к
фильтру получает только его автор.
Нам доступны следующие виды предоставления доступа:



Каждый - предоставления доступа всем зарегистрированным пользователям JIRA
Группа - предоставление доступа определенной группе JIRA
Проект - предоставление доступа к фильтру участникам определенного проекта JIRA
Обязательно, после установки параметров нажать "+ Добавить". Сохраняем. Доступ
предоставлен
5.5. Избранные фильтры
При создании фильтра, он по умолчанию помечается как "Избранный".
Для управления избранными фильтрами, необходимой перейти в пункт "Поиск" - "Управление
фильтрами" - "Избранные".
Чтобы добавить фильтр в избранное необходимо найти фильтр и нажать на символ не
закрашенная звезда.
Чтобы удалить фильтр из избранного найти фильтр и нажать на символ закрашенная звезда.
5.6. Добавление фильтров на рабочий стол
Для наглядного отображения информации по фильтрам в JIRA используются "Портлеты
(Гаджеты)".
Портлеты (гаджеты) основываются на проектах, либо фильтрах, созданных в системе. Для
примера, выведем на рабочий стол созданный ранее фильтр "Мой фильтр (Задачи в работе)"
1. В первую очередь необходимо добавить портлет, для этого на рабочем столе в JIRA
нажимаем на кнопку "+ Добавить портлет"
2. В открывшейся форме нажать на "Загрузить все портлеты"
3. Далее в поисковой строке ввести значение "Сохраненный фильтр" и добавить портлет
нажатием на кнопку "Добавить"
4. Портлет (гаджет) появился на рабочем столе.
Теперь необходимо настроить его пункты:




Сохраненный фильтр - Вводится либо название фильтра, либо название проекта. В нашем
случае вводим значение "Мой фильтр (Задачи в работе)"
Количество сток - количество сток, которые будут отображаться в портлете (гаджете)
Столбцы для отображения - поля, которые будут выводиться в столбцы отображаемого
фильтра.
Автообновление - с какой частотой будет обновляться портлет (гаджет)
5. После настройки сохраняем портлет нажатием на кнопку "Сохранить", и настроенный
портлет отображает значения из добавленного фильтра.
5.7. Удаление фильтров
Для удаления фильтра необходимо перейти в пункт "Поиск" - "Управление фильтрами" нажать
на кнопку шестеренка и выбрать пункт "Удаление".
В появившемся диалоговом окне нажать "Удалить".
6. Практические задания. Работа с базой дефектов в тестовом проекте при использовании
инструмента JIRA
Пока нет
Курс UT-004. Тест-дизайн
Введение
Основная проблема, с которой сталкиваются начинающие тестировщики: они не понимают
зачем вообще нужны тест- кейсы, как правильно написать кейс и какие элементы кейса
являются обязательными. Надо ли использовать определенную методологию или нет? Какой
стандарт брать за основу? Как быстро и наглядно убедить заказчика, что действительно все
основные сценарии проверены?
Тестирование, основанное на кейсах, является более объективным, чем исследовательское
тестирование. Вторым достоинством является четкое понимание времени, которое надо на
проведение тестирования. Третьим, неоспоримым, достоинством можно назвать возможность
определить объем проверки Программы в тех или иных цифрах.
По итогам этого курса читатель будет иметь представление зачем нужны тест-кейсы и как их
составлять.
1. Определение Тест-дизайна
Тест Дизайн (Test Design) – это этап процесса тестирования ПО, на котором проектируются и
создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями
качества и целями тестирования.
Соответственно, тест-дизайнер – это сотрудник, в чьи обязанности входит создание набора
тестовых случаев, обеспечивающих оптимальное тестовое покрытие приложения.
Тест-дизайнер должен выстроить процесс тестирования всех важнейших частей программного
продукта, используя минимально возможное количество проверок. В небольших командах
работа тест-дизайнера зачастую ложится на плечи рядового тестировщика, в крупных же
компаниях функции тестирования и тест-дизайна, как правило, четко разделены между
специалистами.
В итоге цепочка тестирования выглядит так:



тест-аналитик выполняет анализ продукта, разбивает его на составные части, расставляет
приоритеты тестирования и составляет логическую карту приложения;
тест-дизайнер на основании информации, полученной от аналитика, приступает к разработке
тестов;
тестировщик проводит непосредственно тестирование по уже готовым тест-кейсам.
Тест-кейс — это такое описание проверки работы системы, которое может
выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже
бизнес-заказчик.
Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.
Набор тест-кейсов называется тестовым набором (test suite), иногда тестовым сценарием.
Иногда этот набор некорректно называют тест-планом. Тест-план — это именно план: когда,
что, зачем, какими ресурсами.
2. План работ над тест-дизайном
В План работы над тест дизайном входят:

анализ имеющихся проектных артефактов: документация (спецификации, требования, планы),
модели, исполняемый код и т.д.


написание спецификации по тест дизайну (Test Design Specification)
проектирование и создание тестовых случаев (Test Cases)
Роли, ответственные за тест дизайн:


Тест аналитик - определяет "ЧТО тестировать?"
Тест дизайнер - определяет "КАК тестировать?"
Попросту говоря, задача тест аналитиков и дизайнеров сводится к тому, чтобы используя
различные стратегии и техники тест дизайна, создать набор тестовых случаев,
обеспечивающий оптимальное тестовое покрытие тестируемого приложения. Однако, на
большинстве проектов эти роли не выделяются, а доверяются обычным тестировщикам.
Давайте рассмотрим каждый из этапов более предметно:
Итак «анализ имеющихся проектных артефактов: документация (спецификации, требования,
планы), модели, исполняемый код и т.д.»
Какие артефакты мы имеем для начала работы над тест-дизайном?
Наиболее распространенными артефактами являются:






План тестирования (Test Plan) - это документ описывающий весь объем работ по
тестированию, начиная с описания объекта тестирования (программы, модуля и т.п.).
Стратегии тестирования – объединение нескольких задач, близких по смыслу, для
совместного тестирования
Критерии начала и окончания тестирования
Специальные знания, а также оценки рисков с вариантами их разрешения.
Набор тест кейсов и тестов (Test Case & Test suite) - это последовательность действий, по
которой можно проверить соответствует ли тестируемая функция установленным
требованиям. Существуют ли уже тест кейсы? Актуальны ли они или требуется внести
изменения?
Дефекты / Баг Репорты (Bug Reports / Defects) - это зафиксированные ситуации или
последовательности действий приведшие к некорректной работе объекта тестирования, с
указанием причин и ожидаемого результата.
Хороший тест план должен, как минимум, описывать следующее:
1. Что надо тестировать?
 описание объекта тестирования: системы, приложения, оборудования
2. Что будете тестировать?
 список функций и описание тестируемой системы и её компонент в отдельности
3. Как будете тестировать?
 стратегия тестирования, а именно: виды тестирования и их применение по отношению к
объекту тестирования
4. Когда будете тестировать?
 последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing),
анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
5. Критерии начала тестирования:
 готовность тестовой платформы (тестового стенда)
 законченность разработки требуемого функционала
 наличие всей необходимой документации
 ...
6. Критерии окончания тестирования:
 результаты тестирования удовлетворяют критериям качества продукта:




требования к количеству открытых багов выполнены
выдержка определенного периода без изменения исходного кода приложения Code
Freeze (CF)
выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)
...
Ответив в своем тест плане на вышеперечисленные вопросы, можно считать, что у вас на
руках уже есть хороший черновик документа по планированию тестирования. Далее, чтобы
документ приобрел более серьезный вид, предлагаем дополнить его следующими пунктами:



Окружение тестируемой системы (описание программно-аппаратных средств)
Необходимое для тестирования оборудование и программные средства (тестовый стенд и его
конфигурация, программы для автоматизированного тестирования и т.д.)
Риски и пути их разрешения
3. Виды тест планов
Чтобы составить тест план нам необходимо понимать какую цель мы преследуем, какой из
видов тест плана нам необходим для данной задачи?
Чаще всего на практике приходится сталкиваться со следующими видами тест планов:
1. Мастер Тест План (Master Plan or Master Test Plan)
2. Тест План (Test Plan), назовем его детальный тест план
3. План Приемочных Испытаний (Product Acceptance Plan) - документ, описывающий набор
действий, связанных с приемочным тестированием (стратегия, дата проведения,
ответственные работники и т.д.)
4. План тестирования производительности.
Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является
более статичным в силу того, что содержит в себе высокоуровневую (High Level)
информацию, которая не подвержена частому изменению в процессе тестирования и
пересмотра требований. Сам же детальный тест план, который содержит более конкретную
информацию по стратегии, видам тестировании, расписанию выполнения работ, является
"живым" документом, который постоянно претерпевает изменения, отражающие реальное
положение дел на проекте.
В повседневной жизни на проекте может быть один Мастер Тест План и несколько
детальных тест планов, описывающих отдельные модули одного приложения.
4. Создание тест-кейса
Все люди разные! Согласны? Чтобы разные люди смогли работать с одним Объектом и
понимать его одинаково, они должны иметь однаковое мышление. А это маловероятно. Но мы
можем искуственно приблизиться к этому состоянию вырабатывая единые методики работы одинаковое оформление позволит быстро ориентироваться в описаниях.
В разных областях и для разных Продуктов методологии создания тест-кейтов могут
отличаться.
При этом, какими бы не были требования к созданию и изменению тест-кейсов, принятые у
вас, есть уже определенные ожидания, которых всегда стоит придерживаться.
Стандартные атрибуты тест-кейса





Номер — уникальный идентификатор тест-кейса. Его удобно использовать для одинакового
понимания, о какой проверке идет речь (например, дать ссылку в баге).
Название — краткое описание сути проверки. Должно помещаться в твиттер и быть
понятным! Кратко, но емко.
Предварительные шаги — описание действий, которые необходимо выполнить, но прямого
отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки
создания элемента). Если предварительных шагов нет, то секция не заполняется.
Шаги — описание действий, необходимых для проверки (например, создание элемента).
Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения
шагов ("Элемент создан").
Требования к хорошему тест-кейсу







Существует обоснованная вероятность выявления тестом дефекта
Определены входные данные
Определен ожидаемый результат, считаемый «хорошим».
Воспроизводимость
Независимость: может исполняться независимо. Оставляет систему в том же состоянии.
Тест должен быть наилучшим в своей категории.
Экономичный. Нет избыточных шагов.
Основные ошибки при составлении тест-кейсов








Слишком длинный сценарий.
Неполное, неправильное или непоследовательное описание условий тестирования или
подготовки тестового окружения.
Пропущенные «очевидные» шаги.
Использование устаревшей информации о тестируемой системе.
Неочевидно, кто должен выполнить действие: пользователь или система.
Неясно, что является успешным результатом.
Отсутствие очистки системы.
Бессистемный выбор входных значений не позволит найти большое количество дефектов.
Необходимо использование методов для выбора набора входных значений.
Основные методы выбора входных значений:






Перебор всех возможных значений,
Случайные входные данные,
Предугадывание ошибки,
Построение графов «причина-следствие»,
Использование классов эквивалентности,
Исследование граничных значений.
5. Методы выбора входных значений
5.1. Метод перебора
Сущность метода перебора заключается в том, что необходимо:
а) рассматривать все возможные случаи;
б) найти те, которые удовлетворяют условию данной задачи;
в) показать, что других решений нет.
В связи с этим должна быть найдена определённая схема перебора, используя которую мы
будем уверены в том, что рассмотрены все возможные случаи.
Используя перебор при решении задач, приходится наблюдать, сопоставлять факты и на
основании частных выводов делать те или иные общие заключения.
5.2. Случайные входные данные
Генерируются случайные входные данные. Либо данные случайным образом выбираются из
большого тестового набора, который не успеваем проверить целиком.
Метод часто используется в нагрузочном тестировании. Для использования метода
необходимо иметь метод определения корректности выхода.
Само понятие «случайное число» пришло из такого раздела математики, как теория
вероятности, и всегда рассматривается в контексте какой-то последовательности, которая
характеризуется тем, что каждое число последовательности не зависит от всех остальных чисел
последовательности, то есть случайное число непредсказуемо, никогда нельзя с полной
уверенностью предугадать, какое будет следующее число в случайной последовательности.
Кроме того, случайные числа должны подчиняться равномерному распределению, то есть
вероятность появления каждого числа равновероятна. Человек очень плох в качестве
генератора случайных чисел.
5.3. Предугадывание ошибки
Это когда сотрудник использует свои знания системы и способность к интерпретации
спецификации на предмет того, чтобы "предугадать" при каких входных условиях система
может выдать ошибку.
Сущность метода:
Составление тестовых сценариев на основании опыта предыдущего тестирования.
Использование знаний об известных проблемных местах продукта.
Использование знаний о распространенных ошибках программирования и составление тестов
для их поиска.












Некорректная работа с памятью: переполнение, чтение за пределами, утечки памяти.
Отсутствие обработки некорректных входных данных.
Ошибки работы с типами данных: переполнение, приведение, приближение.
Ошибки многопоточности: deadlock, data race.
Отсутствие инициализации/сброса переменных.
Недостаток привилегий, недоступность ресурсов.
…
Выделяем причины и следствия в спецификациях.
Строим граф, связывающий причины и следствия.
Выписываем невозможные сочетания причин и следствий.
Разрабатываем «таблицу решений», где в каждом столбце конкретная комбинация входов и
выходов.
Превращаем каждый столбец в тестовый сценарий.
5.4. Графы причина-следствие
Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы
(Следствие). Например, вы проверяете возможность добавлять клиента, используя
определенную экранную форму. Для этого вам необходимо будет ввести несколько полей,
таких как "Имя", "Адрес", "Номер Телефона" а затем, нажать кнопку "Добавить" - это "Причина".
После нажатия кнопки "Добавить", система добавляет клиента в базу данных и показывает его
номер на экране - это "Следствие".
Преимущества и недостатки:



Комбинаторный взрыв числа вариантов
Позволяет систематизировать процесс построения сценариев.
Используются эвристики для уменьшения числа комбинаций
5.5. Классы эквивалентности
Давайте договоримся о том, какие тесты мы будем считать эквивалентными.
Если от двух тестов ожидается одинаковый результат - они эквивалентны.
Группа тестов представляет класс эквивалентности, если:



Все тесты предназначены для выявления одной и той же ошибки.
Если один тест выявит ошибку, то и остальные это сделают.
Если один из тестов не выявит ошибка, то и остальные этого не сделают.
Дополнительные практические критерии:




Тесты включают значения одних и тех же входных данных.
Для проведения теста выполняются одни и те же операции программы.
В результате тестов формируются значения одних и тех же выходных данных.
Ни один из тестов не вызывает выполнения конкретного блока обработки ошибок либо
выполнение этого блока вызывается всеми тестами.
Примерный алгоритм использования техники такой:
1. Определить классы эквивалентности. Это главный шаг техники. От него во многом зависит
эффективность её применения.
2. Затем нужно выбрать одного представителя от каждого класса. На этом шаге из каждого
эквивалентного набора тестов мы выбираем один тест.
3. Нужно выполнить тесты. На этом шаге мы выполняем тесты от каждого класса
эквивалентности.
Пример 1. Программа классификации треугольников.
Классы эквивалентности по корректным входным данным:




Равнобедренные треугольники.
Равносторонние треугольники.
Прямоугольные треугольники.
Просто треугольники.
Классы эквивалентности по некорректным входным данным:

Отрезки не образуют треугольник.


Числа больше sizeof(int).
Строка, содержащая буквы.
Пример 1. Программа, говорящая дату следующего дня.
Классы эквивалентности по корректным входным данным:




День от 1 до 27;
Последний день месяца;
Последний день года;
28 февраля високосного года.
Классы эквивалентности по некорректным входным данным:



Месяц > 12;
День > 31;
Неверная строка.
Поиск классов эквивалентности
Построение классов эквивалентности – субъективный процесс. Общие рекомендации:









Не забывайте о классах некорректных данных.
Формируйте классы в виде таблицы или плана.
Определите диапазоны числовых значений входных данных.
Проанализируйте варианты выбора из списков и меню.
Поищите переменные, значения которых должны быть равными.
Поищите классы значений, зависящих от времени.
Выявите группы переменных, совместно участвующих в конкретных вычислениях.
Посмотрите, на какие действия программа отвечает эквивалентными событиями.
Продумайте варианты среды тестирования.
5.6. Граничное тестирование
Тестирование значений, лежащих на границе классов эквивалентности, т.к. там выше
вероятность возникновения ошибки.
Анализ Граничных значений может быть применен к полям, записям, файлам, или к любого
рода сущностям имеющим ограничения.
Граничное тестирование – применение



Определяем границу класса эквивалентности.
Проверяем значения, лежащие ровно на границе.
Проверяем значения, лежащие максимально близко к границе с обеих сторон.
Пример.
При покупке более 100 единиц товара дается скидка 5%.
Нужно проверить:

100


99
101
6. Эвристики и оракулы
Эвристики и оракулы кажутся новичкам очень сложными концепциями. Они крайне
наукообразно звучат и непохожи на ту реальность, с которой тестировщик ежедневно
сталкивается. Однако на самом деле они крайне полезны в качестве инструментов
критического мышления.
Что же такое эвристики и оракулы? Ответ на этот вопрос хорошо освещен в статье Эвристики и
оракулы.
Как мы узнаем из статьи:
под эвристикой понимают совокупность приемов и методов, облегчающих и упрощающих
решение познавательных, конструктивных, практических задач.
То есть "Эвристики" – это основанные на опыте техники решения проблем и обучения. И не
стоит забывать, что эвристики несовершенны и подвержены ошибкам.
Оракулы – это принципы или механизмы, благодаря которым мы распознаем проблему.
Мы можем определить проблемное место, но не дать ответ, корректно ли поведение
программы.
Оракулы. Примеры
Недостатки


Описание
Преимущества

Нет оракула
(некомпетентный
человек)
Не проверяем результаты. Просто
«исполняем пока не упадет»
Нет оракула
(компетентный человек)
Человек выполняет тест, не зная

правильного
результата. Используется «здравый
смысл» для определения
Возможность
нахождения широкого
круга проблем
Идеальный оракул
Механизм всегда дающий ответ о

прохождении/провал е любого теста
Находит все типы
проблем
Можем
автоматизировать все


Можем использовать
любые объемы данных
Полезно на начальных
стадиях тестирования
Согласованно:








Внутри продукта
Сопоставимыми продуктами
Образом
Заявлениями
Историей
Ожиданиями пользователя
Целью


Проверяет только некоторые аспекты
тестового вывода
Все оракулы – частичны
Оракулы
согласованности
Частичный


Ограничения
Проверка на:


Паттерн знакомой
проблемы


Регрессия


Недопустимые значения ( пример –

почтовый код)
Недопустимые взаимоотношения
(пример – размер страницы печати
должен соответствовать
возможностям принтера)
Программа ведет себя похоже на
другую программу с известной
проблемой
Недостаточно для заведения
дефекта, но мотивирует «копать
глубже»

Сравниваем текущие результаты с 
предыдущими. Считаем предыдущие
результаты правильными

Самопроверяющие
данные (self-verifying
data)


Встроить правильный ответ в
тестовые данных
CRC, digital signature, hashes,
checksums


Большинство оракулов
попадает в эту структуру
Дает идеи для дизайна
тестов и убедительное
обоснование результатов
Более высока
вероятность
существования
Более низкая стоимость
создания и
использования
Находит самые
очевидные ошибки
программы
Полезно, на любых
стадиях разработки
Диагностирует
потенциальные
проблемы (но не
указывает на них)
Простота реализации
Может работать с
большими объемами
данных
Множество инструментов
уже существуют для
помощи в таких
проверках
Дает возможность
анализа результатов
Малая зависимость от
пользовательского
интерфейса


Модель – конечный
автомат
Представляем программу в виде
конечного автомата


Модель взаимодействия
Бизнес-модель

Мы знаем, что если выполнить

действие Х, то другая часть системы
должна сделать Y
Мы понимаем бизнес-процессы
программы. (например, алгоритм
вычисления налога, логику работы
склада и т.д.)


Теоретическая модель 
(например физическая,
математическая)
Мы имеем теоретическую модель, 
описывающую поведение программы
Статистическая модель
Проверка относительно
статистических
предсказаний.Например:



X обычно больше Y
80% покупателей имеют почтовый
код из следующего набора
Данные подготовленные
вручную
Результаты тщательно выбираются
автором тестов
Человек
Источники





Человек решает корректно ли
поведение программы

Можем работать с
большими объемами
данных
Не требует внешних
оракулов
Хороший выбор
вспомогательных
инструментов
Хорошо
автоматизируется
Хорошо поддается
автоматизации
Как правило может быть
выражено уравнениями
или неравенствами
Ошибки такого рода
важны для программы
Хорошо подходит для мат
моделей, функций
Ошибки в этом аспекте,
скорее всего, важны
Позволяет проверять
большие объёмы данных
Позволяет обрабатывать
данные других тестов
Полезно для больших и
сложных систем
Ожидаемый результат
может быть понят
другими
Иногда – это
единственный способ
Помимо всего прочего использовались сайты:
http://software-testing.ru/library/testing/test-analysis/2500-roles-and-responsibilities-of-testdesigner
http://www.protesting.ru/testing/testdesign.html
Курс UT-005. Тестирование Web-приложений
1. Тестирование Веб-приложений
1.1. Введение
Вычислительные и коммуникационные системы используются все чаще и с каждым днем все
глубже входят в нашу повседневную жизнь. Компании и отдельные пользователи все больше
зависят в своей работе от web-приложений. Веб-приложения соединяют различные отделы
внутри компаний, различные компании и простых пользователей. Веб-приложения очень
динамичны, а их функциональные возможности непрерывно растут. Непрерывно возрастает
потоковый трафик средств информации и запросов, формируемых переносными и
встроенными устройствами. Вследствие этого возрастает сложность систем такого рода.
Очевидно, что для понимания, анализа, разработки и управления такими системами нужны
количественные методы и модели, которые помогают оценить
различные сценарии функционирования, исследовать структуру и состояние больших систем.
Наблюдаются тенденции к постоянному росту спроса на Веб-службы. Таким образом,
проблемы, связанные с недостаточной производительностью будут возникать и в будущем, и, в
конце концов, они станут превалирующими при планировании и вводе в эксплуатацию новых
Веб-служб и увеличении пользователей Интернета. Веб-приложения становятся все более
распространенными и все более сложными, играя, таким образом, основную роль в
большинстве онлайновых проектов. Как и во всех системах, основанных на взаимодействии
между клиентом и сервером, уязвимости Веб-приложений обычно возникают из-за
некорректной обработки запросов клиента и/или недостаточной проверки входной
информации со стороны разработчика.
В первой части данной лекции мы рассмотрим вопросы специфичные для тестирования
и отладки Веб-приложений.
Будут рассмотрены принципы следующих подходов к тестированию Веб-приложений:






функциональное тестирование ;
тестирование пользовательского интерфейса ;
тестирование удобства использования ;
нагрузочное и стрессовое тестирование ;
проверка ссылок и HTML-кода;
тестирование безопасности.
Также будет приведен обзор средств автоматизации тестирования Веб-приложений.
Во второй части лекции будут рассмотрены подходы и инструментальные
средства отладки CSS, а также отладки и профилирования JavaScript.
1.2. Подходы к функциональному тестированию Веб-приложений
Функциональное тестирование (functional testing) – процесс верификации соответствия
функционирования продукта его начальным спецификациям. Характерным примером может
быть проверка того, что программа подсчета выплат по банковской ссуде выдает корректные
выкладки на любые введенные сумму ссуды и срок ее возврата. Обычно подобные проверки
проводятся вручную, иногда к этому подключаются конечные пользователи в качестве бетатестеров. Однако программные системы становятся все сложнее, а комбинации различных
входных параметров и поддерживаемых операционных систем нередко исчисляются
десятками и сотнями.
Перечислим некоторые из методов функционального тестирования веб-приложений:
1. Record & Play – основан на возможности средств автоматизации
тестирования автоматически генерировать код.
2. Functional Decomposition – в основе лежит разбиение всех компонент фреймворка по
функциональному признаку на бизнес-функции (реализуют/проверяют бизнесфункциональность приложения), user-defined функции (вспомогательные функции,
которые еще имеют привязку к тестируемому приложению или к конкретному проекту),
утилиты (функции общего назначения, не привязанные к конкретному приложению,
технологии, проекту).
3. Data-driven – основан на том, что к некоторому тесту или группе тестов привязывается
источник данных, и этот тест или набор тестов циклически выполняется для каждой
записи из этого источника данных. Вполне может применяться в комбинации с другими
подходами.
4. Keyword-driven – представляет собой фактически движок для обработки посылаемых ему
команд, а сами инструкции выносятся во внешний источник данных.
5. Object-driven – основан на том, что основные ходовые части фреймворка реализованы в
виде объектов, что позволяет собирать тесты по кирпичикам.
6. Model-based – основан на том, что тестируемое приложение (или его части) описывается
в виде некоторой поведенческой модели.
Самым распространенным является подход, называемый Capture & Playback (другие названия –
Record & Playback, Capture & Replay). Суть этого подхода заключается в том,
что сценарии тестирования создаются на основе работы пользователя с тестируемым
приложением. Инструмент перехватывает и записывает действия пользователя, результат
каждого действия также запоминается и служит эталоном для последующих проверок. При
этом в большинстве инструментов, реализующих этот подход, воздействия (например, нажатие
кнопки мыши) связываются не с координатами текущего положения мыши, а с объектами
HTML-интерфейса (кнопки, поля ввода и т.д.), на которые происходит воздействие, и их
атрибутами. При тестировании инструмент автоматически воспроизводит ранее записанные
действия и сравнивает их результаты с эталонными, точность сравнения может настраиваться.
Можно также добавлять дополнительные проверки – задавать условия на свойства объектов
(цвет, расположение, размер и т.д.) или на функциональность приложения (содержимое
сообщения и т.д.).
Основное достоинство этого подхода – простота освоения. Создавать тесты с помощью
инструментов, реализующих данный подход, могут даже пользователи, не имеющие навыков
программирования.
Вместе с тем, у подхода имеется ряд существенных недостатков. Для разработки тестов не
предоставляется никакой автоматизации; фактически, инструмент записывает процесс ручного
тестирования. Если в процессе записи теста обнаружена ошибка, то в большинстве случаев
создать тест для последующего использования невозможно, пока ошибка не будет исправлена
(инструмент должен запомнить правильный результат для проверки). При изменении
тестируемого приложения набор тестов трудно поддерживать в актуальном состоянии, так как
тесты для изменившихся частей приложения приходится записывать заново.
1.3. Тестирование пользовательского интерфейса
Часть программной системы, обеспечивающая работу интерфейса с пользователем – один из
наиболее нетривиальных объектов для верификации. Нетривиальность заключается в двояком
восприятия термина "пользовательский интерфейс".
С одной стороны пользовательский интерфейс – часть программной системы. Соответственно,
на пользовательский интерфейс пишутся функциональные и низкоуровневые требования, по
которым затем составляются тест-требования и тест-планы. При этом, как правило, требования
определяют реакцию системы на каждый ввод пользователя (при помощи клавиатуры, мыши
или иного устройства ввода) и вид информационных сообщений системы, выводимых на
экран, печатающее устройство или иное устройство вывода. При верификации таких
требований речь идет о проверке функциональной полноты пользовательского интерфейса –
насколько реализованные функции соответствует требованиям, корректно ли выводится
информация на экран.
С другой стороны пользовательский интерфейс – "лицо" системы, и от его продуманности
зависит эффективность работы пользователя с системой. Факторы, влияющие на
эффективность работы, в меньшей степени поддаются формализации в виде конкретных
требований к отдельным элементам, однако должны быть учтены в виде общих рекомендаций
и принципов построения пользовательского интерфейса программной системы. Проверка
интерфейса на эффективность человеко-машинного взаимодействия получила название
проверки удобства использования (usability verification, в русскоязычной литературе в качестве
перевода термина usability часто используют слово "практичность").
Функциональное тестирование пользовательского интерфейса состоит из пяти фаз:





анализ требований к пользовательскому интерфейсу;
разработка тест-требований и тест-планов для проверки пользовательского интерфейса;
выполнение тестовых примеров и сбор информации о выполнении тестов;
определение полноты покрытия пользовательского интерфейса требованиями.
составление отчетов о проблемах в случае несовпадения поведения системы и
требований, либо в случае отсутствия требований на отдельные интерфейсные
элементы.
Все эти фазы точно такие же, как и в случае тестирования любого другого компонента
программной системы. Отличия заключаются в трактовке некоторых терминов в применении к
пользовательскому интерфейсу и в особенностях автоматизированного сбора информации на
каждой фазе.
Так, тест-планы для проверки пользовательского интерфейса, как правило, представляют
собой сценарии, описывающие действия пользователя при работе с системой. Сценарии могут
быть записаны либо на естественном языке, либо на формальном языке какой-либо системы
автоматизации пользовательского интерфейса. Выполнение тестов при этом производится
либо оператором в ручном режиме, либо системой, которая эмулирует поведение оператора.
При сборе информации о выполнении тестовых примеров, как правило, применяются
технологии анализа выводимых на экран форм и их элементов (в случае графического
интерфейса) или выводимого на экран текста (в случае текстового), а не проверка значений тех
или иных переменных, устанавливаемых программной системой.
Под полнотой покрытия пользовательского интерфейса понимается то, что в результате
выполнения всех тестовых примеров каждый интерфейсный элемент был использован хотя бы
один раз во всех доступных режимах.
Отчеты о проблемах в пользовательском интерфейсе могут включать в себя как описания
несоответствий требований и реального поведения системы, так и описания проблем в
требованиях к пользовательскому интерфейсу. Основной источник проблем в этих
требованиях – их тестонепригодность, вызванная расплывчатостью формулировок и
неконкретностью.
Тестирование пользовательского интерфейса может проводиться различными методами –
как вручную при непосредственном участии оператора, так и при помощи различного
инструментария, автоматизирующего выполнение тестовых примеров. Рассмотрим эти методы
более подробно.
1.3.1. Ручное тестирование
Ручное тестирование пользовательского интерфейса проводится тестировщикомоператором, который руководствуется в своей работе описанием тестовых примеров в виде
набора сценариев. Каждый сценарий включает в себя перечисление последовательности
действий, которые должен выполнить оператор и описание важных для анализа результатов
тестирования ответных реакций системы, отражаемых в пользовательском интерфейсе.
Типичная форма записи сценария для проведения ручного тестирования – таблица, в которой
в одной колонке описаны действия (шаги сценария ), в другой – ожидаемая реакция системы, а
третья предназначена для записи того, совпала ли ожидаемая реакция системы с реальной и
перечисления несовпадений.
В табл. 1 приведен пример сценария для ручного тестирования пользовательского
интерфейса.
Таблица 1. Пример сценария для ручного тестирования пользовательского
интерфейса
№
п/п
Действие
Реакция системы
Результат
1
Щелкните на значке
"Система" и выберите
пункт меню
"Администрирование
системы".
Появится окно ввода логина
и пароля
Верно
2
Введите в появившееся
окно ввода имя
пользователя "admin" и
пароль "admin". Затем
нажмите кнопку "OK".
Появится окно
"Администрирование
системы". В верхнем правом
углу должно быть выведено
имя вошедшего пользователя
admin.
Неверно Окно
имеет название
"Управление
системой"
Ручное тестирование пользовательского интерфейса удобно тем, что контроль корректности
интерфейса проводится человеком, т.е. основным "потребителем" данной части программной
системы. К тому же при чисто косметических изменениях в интерфейсах системы, не
отраженных в требованиях (например, при перемещении кнопок управления на 10 пикселей
влево) анализ успешности прохождения теста будет выполняться не по формальным
признакам, а согласно человеческому восприятию.
При этом ручное тестирование имеет и существенный недостаток – для его проведения
требуются значительные человеческие и временные ресурсы. Особенно сильно этот
недостаток проявляется при проведении регрессионного тестирования и вообще любого
повторного тестирования – на каждой итерации повторного тестирования
пользовательского интерфейса требуется участие тестировщика-оператора. В связи с этим в
последнее десятилетие получили распространение средства автоматизации тестирования
пользовательского интерфейса, снижающие нагрузку на тестировщика-оператора.
1.3.2. Сценарии на формальных языках
Естественный способ автоматизации тестирования пользовательского интерфейса –
использование программных инструментов, эмулирующих поведение тестировщикаоператора при ручном тестировании пользовательского интерфейса.
Такие инструменты используют в качестве входной информации сценарии тестовых
примеров, записанные на некотором формальном языке, операторы которого соответствуют
действиям пользователя – вводу команд, перемещению курсора, активизации пунктов меню и
других интерфейсных элементов.
При выполнении автоматизированного теста инструмент тестирования имитирует действия
пользователя, описанные в сценарии, и анализирует интерфейсную реакцию системы. При
этом для определения ожидаемого состояния пользовательского интерфейса могут
использоваться различные методы – либо анализ снимков экрана и сравнение их с
эталонными, либо доступ к данным интерфейсных элементов средствами операционной
системы (например, доступ ко всем кнопкам окна по их дескрипторам и получение значений
текста).
И при передаче информации в тестируемый интерфейс и при получении информации для
анализа могут использоваться два способа доступа к элементам интерфейса:
 позиционный, при котором доступ к элементу осуществляется при помощи задания его
абсолютных (относительно экрана) или относительных (относительно окна) координат
и размеров;
 по идентификатору, при котором доступ к элементу осуществляется при помощи
получения интерфейсного элемента при помощи его уникального идентификатора в
пределах окна.
При внесении изменений в пользовательский интерфейс при использовании первого метода в
результате проведения регрессионного тестирования будет выявлено большое количество не
прошедших тестов – достаточно изменения местоположения одного ключевого
интерфейсного элемента, как все сценарии начнут работать неверно. Соответственно при
таком методе автоматизации тестирования необходимо менять значительную
часть сценариев в системе тестов при каждом изменении интерфейса системы. Такой
метод автоматизации тестирования подходит для систем с устоявшимся и редко
изменяемым интерфейсом.
Второй метод автоматизации тестирования более устойчив к изменению расположения
интерфейсных элементов, но изменения тестовых примеров могут потребоваться и здесь в
случае изменения логики работы интерфейсных элементов. Например, пусть в первой версии
системы при нажатии на кнопку "Передать данные" передача данных начиналась сразу, и
выводилось окно с индикатором прогресса. Сценарий тестового примера в этом случае
включает в себя имитацию нажатия на кнопку и обращение к индикатору прогресса для
получения значения прогресса в процентах.
1.4. Тестирование удобства пользования
Тестирование удобства пользования – тест, который можно назвать практически главным
для всех интерактивных сервисов, взаимодействующих с пользователем – это тест на "usability"
или на удобство использования. Такое тестирование одно из самых дорогих, потому что
наиболее ценную информацию можно получить только от реальных пользователей, наблюдая
за их работой с вашим сайтом – а такие исследования требуют дорогостоящей инфраструктуры
и времени, их сложно автоматизировать. Это метод тестирования, направленный на
установление степени удобства использования, обучаемости, понятности и привлекательности
для пользователей разрабатываемого продукта в контексте заданных условий.
Выделяют следующие этапы тестирования удобства использования пользовательского
интерфейса:




Исследовательское – проводится после формулирования требований к системе и
разработки прототипа интерфейса. Основная цель на этом этапе – провести
высокоуровневое обследование интерфейса и выяснить, позволяет ли он с достаточной
степенью эффективности решать задачи пользователя.
Оценочное – проводится после разработки низкоуровневых требований и
детализированного прототипа пользовательского интерфейса. Оценочное тестирование
углубляет исследовательское и имеет ту же цель. На данном этапе уже проводятся
количественные измерения характеристик пользовательского интерфейса: измеряются
количество обращений к системе помощи по отношению к количеству совершенных
операций, количество ошибочных операций, время устранения последствий ошибочных
операций и т.п.
Валидационное – проводится ближе к этапу завершения разработки. На этом этапе
проводится анализ соответствия интерфейса программной системы стандартам,
регламентирующим вопросы удобства интерфейса, проводится общее тестирование
всех компонент пользовательского интерфейса с точки зрения конечного пользователя.
Под компонентами интерфейса здесь понимается как его программная реализация, так и
система помощи и руководство пользователя. Также на данном этапе проверяется
отсутствие дефектов удобства использования интерфейса, выявленных на предыдущих
этапах.
Сравнительное – данный вид тестирования может проводиться на любом этапе
разработки интерфейса. В ходе сравнительного тестирования сравниваются два или
более вариантов реализации пользовательского интерфейса.
Тестирование удобства пользования дает оценку уровня удобства использования приложения
по следующим пунктам:




производительность, эффективность (efficiency) – сколько времени и шагов понадобится
пользователю для завершения основных задач приложения, например, размещение
новости, регистрации, покупка и т.д.
правильность (accuracy) – сколько ошибок сделал пользователь во время работы с
приложением
активизация в памяти (recall) – как много пользователь помнит о работе приложения
после приостановки работы с ним на длительный период времени? (повторное
выполнение операций после перерыва должно проходить быстрее, чем у нового
пользователя)
эмоциональная реакция (emotional response) – как пользователь себя чувствует после
завершения задачи – растерян, испытал стресс. Порекомендует ли пользователь систему
своим друзьям.
Исследование и оценка сайтов может проводится разными методами, разработанными
экспертами по юзабилити. Общим для всех методов является постановка реальных задач перед
пользователями, а также фиксирование результатов тестирования для дальнейшего анализа.
Для участия в юзабилити-тестировании отбираются пользователи, соответствующие целевой
аудитории, они также не должны быть слишком знакомы с разработкой. Для того чтобы
выявить и оценить наибольшее количество присутствующих на сайте проблем, необходимо
привлекать реальных пользователей.
На удобство использования пользовательского интерфейса влияют следующие факторы:





легкость обучения – быстро ли человек учится использовать систему;
эффективность обучения – быстро ли человек работает после обучения;
запоминаемость обучения – легко ли запоминается все, чему человек научился;
ошибки – часто ли человек допускает ошибки в работе;
общая удовлетворенность – является ли общее впечатление от работы с системой
положительным.
Все эти факторы, несмотря на свою неформальность, могут быть измерены. Для таких
измерений выбирается группа типичных пользователей системы, в процессе их работы с
системой измеряются показатели их работы с системой (например, количество допущенных
ошибок), а также им предлагается высказать собственные впечатления от работы с системой
при помощи заполнения опросных листов.
Как правило, при тестировании удобства использования пользовательского интерфейса
используются некоторые эвристические критерии и характеристики, которые заменяют точные
оценки в классическом тестировании программных систем.
Например, Якоб Нильсен в своей работе выделил 10 эвристических характеристик удобного
пользовательского интерфейса, которые с его точки зрения должны проверяться
при тестировании удобства использования интерфейса:
1. Наблюдаемость состояния системы – система всегда должна оповещать пользователя о
том, что она в данный момент делает, причем через разумные промежутки времени;
2. Соотнесение с реальным миром – терминология, использованная в интерфейсе системы
должна соотноситься с пользовательским миром, т.е. это должна быть терминология
проблемной области пользователя, а не техническая терминология.
3. Пользовательское управление и свобода действий – пользователи часто выбирают
отдельные интерфейсные элементы и используют функции системы по ошибке. В этом
случае необходимо предоставлять четко определенный "аварийный выход", при помощи
которого можно вернуться к предыдущему нормальному состоянию. К таким
"аварийным выходам" относятся, например, функции отката и обратного отката.
4. Целостность и стандарты – для обозначения одних и тех же объектов, ситуаций и
действий должны использоваться одинаковые слова во всех частях интерфейса. Более
того, терминология сообщений в пользовательском интерфейсе должна учитывать
соглашения конкретной платформы.
5. Помощь пользователям в распознавании, диагностике и устранении ошибок –
Сообщения об ошибках должны быть написаны на естественном языке, а не заменяться
кодами ошибок. Сообщения об ошибках должны четко определять суть возникшей
проблемы и предлагать ее конструктивное решение.
6. Предотвращение ошибок – продуманный дизайн пользовательского интерфейса,
предотвращающий появление ошибок пользователя всегда лучше хорошо продуманных
сообщений об ошибках. При проектировании интерфейса необходимо либо полностью
устранить элементы, в которых могут возникать ошибки пользователя, либо проверять
ввод пользователя в этих элементах и сообщать ему о потенциально возможном
возникновении проблемы.
7. Распознавание, а не вспоминание – при создании интерфейса необходимо
минимизировать нагрузку на память пользователя, делая объекты, действия и опции
ясными, доступными и явно видимыми. Пользователь не должен запоминать
информацию при переходе от одного диалогового окна к другому. Во всех необходимых
местах должны быть доступны контекстные инструкции по использованию интерфейса.
8. Гибкость и эффективность использования – в интерфейсе должны быть предусмотрены
горячие клавиши (не обязательные к использованию начинающим пользователем) – они
часто значительно ускоряют работу опытного пользователя. Иными словами, система
должна предоставлять два способа работы – для новичков и для опытных пользователей.
Желательно при этом давать возможность пользователю автоматизировать часто
повторяющиеся действия.
9. Эстетичный и минимально необходимый дизайн – Окна не должны содержать не
относящуюся к делу или редко используемую информацию. Каждый интерфейсный
элемент, содержащий бесполезную информацию, играет роль информационного шума и
отвлекает пользователя от действительно полезных интерфейсных элементов.
10. Помощь и документация – Несмотря на то, что в идеальном случае лучше, когда
системой можно пользоваться без документации, она все равно необходима – как в виде
системы помощи, так и, возможно, в виде печатного руководства. Информация в
документации должна быть структурирована таким образом, чтобы пользователь мог
легко найти нужный раздел, посвященный решаемой им задаче. Каждый такой
ориентированный на конкретную задачу раздел должен помимо общей информации
содержать пошаговые руководства по выполнению задачи и не должен быть слишком
длинным.
Все эти эвристики могут использоваться при тестировании удобства
использования пользовательского интерфейса. Достаточно очевидно, что при тестировании
удобства слабо применимы способы автоматизации тестирования при помощи сценариев и
подобные методы. Один из наиболее эффективных методов проверки интерфейса на удобство
– использование формальной инспекции. Вопросы в бланке инспекции могут быть как общего
характера (так, например, можно использовать в качестве вопросов перечисленные выше 10
эвристик), так и вполне конкретными. Например, в работе приводится список контрольных
вопросов, которые желательно проверять при тестировании удобства использования Вебсайтов. С некоторыми изменениями эти вопросы применимы и для обычных оконных
интерфейсов.
1.5. Проверка ссылок
Еще один вид тестирования – проверка ссылок. В больших тестовых комплексах он
интегрирован в проверку юзабилити, или же в проверку правильности HTML-кода, но
существует и множество простеньких утилит для такого рода проверок. Такое тестирование
актуально и для внутренних ссылок (в случае больших и разветвленных порталов), и для
внешних – если это, к примеру, каталог сайтов, или просто обычная страница "Ссылки".
Пожалуй, такой тест – это один из немногих тестов, специфический для веб-приложений и
сайтов. Кроме того, такой тест можно и необходимо периодически проводить на работающем
сайте – ведь со временем структура меняется, и некоторые ссылки могут стать неверными.
1.6. Тестирование безопасности
Отдельно следует отметить тест на безопасность. Это очень важный тип тестов, так как от
безопасности сервера зависит практически все – и сам бизнес, и доверие пользователей, и
сохранность информации. Правда, в отличие от других тестов, тестирование
безопасности следует проводить регулярно. Кроме того, тестированию подвергается не только
сам конкретный сайт или веб-приложение, а весь сервер полностью – и веб-сервер, и
операционная система, и все сетевые сервисы. Как и в случае других тестов, программа
"прикидывается" реальным пользователем-взломщиком и пытается применить к серверу все
известные ей методы атаки и проверяет все уязвимости. Результатом работы будет отчет о
найденных уязвимостях и рекомендации по их устранению.
Ошибки, связанные с проверкой корректности ввода, часто довольно сложно обнаружить в
большом объеме кода, взаимодействующего с пользователем. Это является основной
причиной того, что разработчики используют методологию тестирования приложений на
проникновение для их обнаружения. Веб-приложения, однако, не имеют иммунитета и к более
традиционным способам атаки. Весьма распространены плохие механизмы
аутентификации, логические ошибки, непреднамеренное раскрытие информации, а также
такие традиционные ошибки для обычных приложений как переполнение буфера. Приступая к
тестированию Веб -приложений, необходимо учитывать все перечисленное, и должен
применяться методический процесс тестирования ввода/вывода по схеме "черного ящика" в
сочетании (если возможно) с аудитом исходного кода.
Существуют различные инструменты позволяющие производить
автоматическое тестирование безопасности, выполняя такие задачи как cross site
scripting, SQL injection, включая переполнение буфера, подделка параметра,
несанкционированный доступ, манипуляции с HTTP запросами и т.д.
1.7. Нагрузочное тестирование
Следующим видом тестирования является тест на устойчивость к большим нагрузкам –
Load-testing, stress-test или performance test. Такой тест имитирует одновременную работу
нескольких сотен или тысяч посетителей (каждый из которых может "ходить" по сайту в
соответствии со своим сценарием ), проверяя, будет ли устойчивой работа сайта под большой
нагрузкой. Кроме этого, можно имитировать кратковременные пики нагрузки, когда
количество посетителей скачкообразно увеличивается – это очень актуально для новостных
ресурсов и других сайтов с неравномерной аудиторией. В таком тесте проверяется не только и
не столько сам сайт, сколько совместная слаженная работа всего комплекса – аппаратной
части сервера, веб-сервера, программного ядра (engine) и других компонентов сайта.
Основными целями нагрузочного тестирования являются:




оценка производительности и работоспособности приложения на этапе разработки и
передачи в эксплуатацию;
оценка производительности и работоспособности приложения на этапе выпуска новых
релизов, патч-сетов;
оптимизация производительности приложения, включая настройки серверов и
оптимизацию кода;
подбор соответствующей для данного приложения аппаратной (программной
платформы) и конфигурации сервера.
В нагрузочное тестирование входят следующие тесты:
1.7.1. Тестирование производительности (Performance testing)
Задачей тестирования производительности является определение масштабируемости
приложения под нагрузкой, при этом происходит:
 измерение времени выполнения выбранных операций при определенных
интенсивностях выполнения этих операций;
 определение количества пользователей, одновременно работающих с приложением;
 определение границ приемлемой производительности при увеличении нагрузки (при
увеличении интенсивности выполнения этих операций);
 исследование производительности на высоких, предельных, стрессовых нагрузках.
1.7.2. Стрессовое тестирование (Stress Testing)
Стрессовое тестирование позволяет проверить насколько приложение и система в целом
работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к
возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в
данном контексте может быть повышение интенсивности выполнения операций до очень
высоких значений или аварийное изменение конфигурации сервера. Также одной из задач
при стрессовом тестировании может быть оценка деградации производительности, таким
образом, цели стрессового тестирования могут пересекаться с целями тестирования
производительности.
1.7.3. Объемное тестирование (Volume Testing)
Задачей объемного тестирования является получение оценки производительности при
увеличении объемов данных в базе данных приложения, при этом происходит:
 измерение времени выполнения выбранных операций при определенных
интенсивности выполнения этих операций;
 может производиться определение количества пользователей, одновременно
работающих с приложением.
1.7.4. Тестирование стабильности или надежности (Stability / Reliability Testing)
Задачей тестирования стабильности (надежности) является проверка работоспособности
приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Время выполнения операций могут играть в данном виде тестирования второстепенную роль.
При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под
нагрузкой и другие аспекты, влияющие именно на стабильность работы.
1.7.5. Моделирование Транзакций (Transaction Simulation, TS)
Этот метод используется в большом числе различных продуктов, в частности, в пакетах
AppManager и Vivinet Manager компании NetlQ.
Метод TS основан на использовании программных GUI-роботов (GUI -Graphical User Interface).
GUI-робот – это специальная программа, которая "заставляет" реальное пользовательское
приложение работать в автоматическом режиме, без участия самого пользователя (человека).
Примерами средств, предназначенных для создания GUI-роботов, являются пакеты
Rational Visual Test и Rational Robot компании Rational Software, а также пакет WinRunner
компании Mercury Interactive.
Программный GUI-робот, как и реальный пользователь приложения, анализирует содержимое
экрана и вводит данные с клавиатуры. Другими словами, он взаимодействует с
пользовательским приложением через тот же интерфейс, что и человек. При этом GUI-робот
работает по программе (скрипту), к коду которой всегда есть доступ (в отличие от кода самого
пользовательского приложения). Поэтому, если в скрипт GUI-робота встроить специальные
вызовы, например, перед началом и после окончания транзакции, то можно измерить время
выполнения этой транзакции.
Основное достоинство метода TS заключается в том, что он позволяет измерять
производительность работы приложения "с точки зрения пользователя" и, при этом, не
требует доступа к коду пользовательского приложения. Недостаток же метода в том, что он
позволяет измерять время выполнения только рабочих транзакций и не может использоваться
для измерения времени выполнения системных транзакций.
1.7.6. Метод "Анализ данных на стороне клиента" (Client Capture, CC)
Данный метод реализован, например, в программном пакете Vital Suite компании Lucent.
Метод основан на извлечении данных о работе приложения из операционной системы
компьютера, где установлено пользовательское приложение. Для этого на компьютере
пользователя устанавливается специальный Агент, который отслеживает взаимодействие
приложения и ОС и, таким образом, получает информацию о доступности и времени реакции
пользовательского приложения. Достоинство данного метода в том, что при его
использовании нет необходимости модернизировать код приложения. Недостаток –
дополнительные накладные расходы на компьютере пользователя (клиента) и ограниченный
набор поддерживаемых приложений.
1.7.7. Метод "Анализ Сетевого Трафика" (Network Sniffing, NS)
Примером такого устройства является NetScout WAN Probes, компании NetScout.Он основан на
извлечении информации о производительности приложений из сетевого трафика. Для этого в
сети устанавливаются специальные Зонды (как правило, аппаратные), которые в режиме
реального времени захватывают сетевой трафик, анализируют его и "извлекают" данные о
времени реакции приложений, доступности приложения и т.п. АРМ-средства на базе метода
"Network Sniffing" выпускаются, в основном, производителями аппаратных анализаторов
сетевых протоколов.
Он имеет следующие недостатки. Во-первых, для того, чтобы в режиме реального времени из
сетевого трафика извлекать информацию о времени реакции приложений, компьютеры, где
установлены Зонды, должны иметь очень высокую производительность. Второй недостаток
метода NS заключается в том, что Зонд может "понимать" только заранее заданный набор
пользовательских приложений, что также ограничивает использование данного метода.
Поскольку применение для целей тестирования большого числа клиентских машин с
практической точки зрения нецелесообразно, встает задача обеспечения независимости
пользовательских запросов, генерируемых одной или несколькими клиентскими машинами.
В настоящее время применяются два способа обеспечения независимости запросов:
использование многопоточности и создание распределенных систем. Многопоточность в той
или иной форме применяется во всех рассмотренных средствах тестирования. Данный метод
не позволяет воспроизводить и в явной форме задавать характер потока запросов
(равномерный, пульсирующий и т.д.) и его статистические характеристики (средняя величина
интервала времени между последовательными запросами, дисперсия и др.). Величина
выделяемого нити кванта времени (а, следовательно, и величина интервала между запросами)
зависит от производительности вычислительной системы и ее загруженности, а также от
алгоритмов разделения времени, применяемых операционной системой. Непредсказуемые
колебания интенсивности генерируемого потока запросов не позволяют достоверно оценить
стабильность работы сервера. Увеличение числа нитей повышает уровень независимости
запросов, однако конкуренция между нитями снижает ур овень нагрузки, что делает данный
подход неприменимым для тестирования высокопроизводительных серверов.
Применение распределенных вычислений позволяет добиться большей реалистичности
тестирования, так как статистические характеристики генерируемого потока запросов
приближаются к характеристикам, наблюдаемым в условиях эксплуатации сервера. Кроме того,
становится возможным увеличение интенсивности нагрузки. Однако применение данного
подхода предъявляет значительно более высокие требования к архитектуре системы и
планированию тестов.
1.8. Проверка HTML-кода
Еще одним типом тестирования является проверка верности HTML-кода страниц сайта. Для
такого рода тестирования написано множество утилит – от простых скриптов на Perl до
мощных валидаторов, проверяющих весь сайт на соответствие стандартам (а некоторые
валидаторы могут в автоматическом режиме исправлять найденные недочеты, например,
пропущенные закрывающие теги и т.д.). Часто такие средства встраивают в Веб-редакторы,
существуют браузеры с встроенными валидаторами.
Например, FireBug интегрируется с браузером Firefox, чтобы обогатить инструментарий
разработчика. Вы сможете редактировать, отлаживать и исследовать CSS, HTML и JavaScript
вживую, на любой веб-странице. Firebug предоставляет возможность делать
экспериментальные изменения в HTML и смотреть, как они тут же отображаются на странице,
производить мониторинг сетевых запросов.
В комплекте с IE8 поставляется инструмент "средства разработчика", который, по сути, является
аналогом FireBug.
1.9. Обзор автоматизации тестирования
В процессе создания информационных систем нередки ошибки и дефекты – это вполне
ожидаемое и нормальное явление, а в условиях ограниченных временных ресурсов и высоких
требований к качеству программных продуктов неизбежно возникает необходимость в
организации эффективного контроля и управления всем процессом тестирования. Контроль
качества ПО невозможен сегодня без автоматизации всех задач тестирования.
Ручное тестирование является затратным по времени, трудоемким и часто монотонным
процессом. Оно приводит к возникновению проблем, особенно при ограниченных ресурсах и
жестких сроках. Если вам нужно улучшить тестирование приложений для проверки
корректности их работы, важно двигаться в сторону автоматизации всех ручных задач
тестирования.
В современных условиях, когда циклы разработки сокращаются, автоматизированное
тестирование позволяет как профессионалам, так и новичкам быстро достичь
высококачественных результатов тестирования приложений. Инструментальные средства
автоматизации записывают взаимодействие пользователей с приложением, а
сформированные на этой основе сценарии используются для последующих тестов. В двух
словах, автоматизация тестирования позволяет оптимизировать качество сложных
приложений эффективным по стоимости способом за приемлемое время. Это помогает
быстрее выпустить программное обеспечение более высокого качества.
Процесс автоматизации тестирования делится на три этапа:



Запись. Сценарий тестирования записывается "на лету" по мере работы пользователя с
приложением. Можно также вставить точки верификации (verification points) для
проверки ответа системы и сделать сценарии тестирования зависящими от данных,
чтобы выполнять один и тот же сценарий с различными наборами входных данных.
Улучшение. Добавление кода, выполняющего разнообразные функции. Типичные
изменения сценариев тестирования – условное ветвление, рефакторинг и обработка
исключительных ситуаций.
Воспроизведение. Выполнение сценариев, эмулирующих действия, которые выполнял
пользователь приложения при записи теста. Расхождения регистрируются, и
тестировщик может сделать вывод о том, хорошо ли функционирует приложение
или регрессионное тестирование выявило проблемы.
Для автоматизации тестирования существует большое количество приложений.
Наиболее популярные из них:




HP LoadRunner, HP QuickTest Professional, HP Quality Center;
Segue SilkPerformer;
IBM Rational FunctionalTester, IBM Rational PerformanceTester, IBM Rational TestStudio;
AutomatedQA TestComplete.
HP LoadRunner – программный продукт для автоматизации нагрузочного
тестирования широкого набора программных сред и протоколов. Поддерживает SOA, работу
с Web-сервисами, Ajax, RDP, SQL, продуктами Citrix, платформы Java, .Net, а также все основные
ERP- и CRM-приложения от PeopleSoft, Oracle, SAP и Siebel. Пакет HP LoadRunner включает в
себя более 60 мониторов сбора данных о тестируемой инфраструктуре и предоставляет
детальную диагностику по работе приложений.
HP LoadRunner состоит из следующих приложений:




Virtual User Generator (VuGen) – служит для разработки нагрузочных скриптов;
Load Generator – служит для генерации нагрузки (генерации виртуальных пользователей);
Controller – служит для разработки и запуска сценариев нагрузки;
Analysis – служит для анализа результатов нагрузочного тестирования.
Средства от IBM Rational:





IBM Rational Robot – универсальное средство автоматизации тестирования общего
назначения для команд разработчиков, выполняющих функциональное
тестирование клиент-серверных приложений. Дает возможность обнаруживать
неполадки в ПО благодаря расширению сценариев тестирования средствами условной
логики, позволяющей целиком охватить тестируемое приложение. Robot позволяет
создавать сценарии тестирования с вызовом внешних библиотек DLL или исполняемых
модулей.
IBM Rational Performance Tester – инструмент нагрузочного и стрессового тестирования,
с помощью которого можно выявлять проблемы системной производительности и их
причины. Позволяет создавать тесты без написания кода и, не требуя навыков
программирования. Обеспечивает гибкие возможности моделирования и эмуляции
различных пользовательских нагрузок. Выполняет сбор и интеграцию данных о
серверных ресурсах с данными о производительности приложений, получаемыми в
режиме реального времени.
IBM Rational Functional Tester – набор средств автоматизированного тестирования,
позволяющих выполнять функциональное и регрессионное
тестирование, тестирование пользовательского интерфейса и тестирование,
управляемое данными. Инструмент применяет технологию ScriptAssure (бесшовная
проверка достоверности динамических данных) и функции поиска соответствия по
шаблону, позволяющие повысить устойчивость сценариев тестирования в условиях
частых изменений пользовательских интерфейсов приложений. Тестировщики могут
выбрать язык сценариев для разработки и настройки тестов: Java в среде Eclipse или
Microsoft Visual Basic .Net в среде Visual Studio .Net.
IBM Rational Quality Manager – решение для реализации процессов управления
тестированием и качеством, поддерживает сотрудничество участников групп по
разработке программных продуктов, предоставляя им возможность обмениваться
информацией, применять средства автоматизации для сокращения графиков
выполнения проектов, а также составлять отчеты по проектным показателям для
принятия обоснованных решений. Rational Quality Manager может быть дополнен
средством управления ресурсами тестирования Rational Test Lab, обеспечивающим учет
ресурсов тестирования (серверов), их бронирование, автоматизацию развертывания
тестовой среды на сервере и запуск скриптов тестирования, а также отчетность по
использованию ресурсов тестирования.
Rational Quality Manager и Rational Test Lab созданы на базе открытой платформы Jazz,
которая предоставляет стандартные интерфейсы и удобные возможности для
интеграции с решениями партнеров и других производителей.
1.10. Ключевые термины
Функциональное тестирование, Тестирование пользовательского интерфейса, Ручное
тестирование, Сценарии, Тестирования удобства использования, Проверка
ссылок, Тестирование безопасности, Нагрузочное тестирование, Тестирование
производительности, Стрессовое тестирование, Объемное тестирование, Тестирование
стабильности, Моделирование Транзакций, Метод "Анализ данных на стороне
клиента", Метод "Анализ Сетевого Трафика", Автоматизации тестирования, Проверка
HTML-кода.
2. Отладка Веб-приложений
2.1. Введение
Отладка – этап разработки компьютерной программы, на котором обнаруживают, локализуют
и устраняют ошибки. Чтобы понять, где возникла ошибка, приходится:


узнавать текущие значения переменных;
и выяснять, по какому пути выполнялась программа.
Существуют две взаимодополняющие технологии отладки.


Использование отладчиков – программ, которые включают в себя пользовательский
интерфейс для пошагового выполнения программы: оператор за оператором, функция
за функцией, с остановками на некоторых строках исходного кода или при достижении
определённого условия.
Вывод текущего состояния программы с помощью расположенных в критических точках
программы операторов вывода – на экран, принтер, громкоговоритель или в файл.
Вывод отладочных сведений в файл называется журналированием.
Современный процесс веб-разработки включает не только работу с HTML, но
и отладку сценариев, и проверку оформления страниц. По этой причине все основные
браузеры, под которые производится верстка и оптимизация большинства страниц, включает в
себя специальные средства для веб-мастеров.
В JavaScript доступ к отладчикам становится особенно полезным при разработке крупных
нетривиальных программ из-за различий в реализациях разных браузеров (в частности, в
отношении объектной модели документа). Полезно иметь доступ к отладчику для каждого из
браузеров, в которых будет работать веб-приложение.
По состоянию на начало 2010 года, Internet Explorer, Firefox, Safari, Google Chrome, а также
Opera имеют отладчики сценариев.
Internet Explorer имеет три отладчика: Microsoft Visual Studio – самый полный из них, следом за
ним следует Microsoft Script Editor (компонент Microsoft Office), и, наконец, свободный
Microsoft Script Debugger, который гораздо более простой, чем два других. Бесплатный
Microsoft Visual Web Developer Express предоставляет ограниченную версию с отладочной
функцией JavaScript в Microsoft Visual Studio. В восьмой версии в IE вместе с инструментами для
разработчиков появился встроенный отладчик.
В Opera также имеется собственный отладчик – Opera Dragonfly.
Разрабатываемые веб-приложения в Firefox можно отлаживать при помощи
расширений Firebug и Venkman.
В Safari входит отладчик JavaScript WebKit Web Inspector. Этот же отладчик доступен и в других
браузерах, использующих WebKit: Google Chrome, Arora, Rekonq, Midori и др.
Профилирование – сбор характеристик работы программы, таких как время выполнения
отдельных фрагментов (обычно подпрограмм), число верно предсказанных условных
переходов, число кэш промахов и т. д. Инструмент, используемый для анализа работы,
называют профилировщиком. Обычно выполняется совместно с оптимизацией программы.
Характеристики могут быть аппаратными (время) или вызванные программным обеспечением
(функциональный запрос). Инструментальные средства анализа программы чрезвычайно
важны для того, чтобы понять поведение программы. Проектировщики ПО нуждаются в таких
инструментальных средствах, чтобы оценить, как хорошо выполнена работа. Программисты
нуждаются в инструментальных средствах, чтобы проанализировать их программы и
идентифицировать критические участки программы.
Это часто используется, чтобы определить, как долго выполняются определенные части
программы, как часто они выполняются, или генерировать граф вызовов (Call Graph). Обычно
эта информация используется, чтобы идентифицировать те участки программы, которые
работают больше всего. Эти трудоёмкие участки могут быть оптимизированы, чтобы
выполняться быстрее. Это – также общая методика для отладки.
Также выделяют анализ покрытия (Code Coverage) – процесс выявления неиспользуемых
участков кода при помощи, например, многократного запуска программы.
В таблице 2 приведено сравнение средств отладки кода страниц разными браузерами.
Таблица 2. Сравнение средств отладки кода страниц разными браузерами
Браузер/функция
IE8
Firefox ( Firebug )
Opera
Safari
Chrome
Подсветка
синтаксиса HTML
есть
есть
есть
есть
есть
Свертывание кода
есть
есть
есть
есть
есть
Правка HTML
есть
есть
нет
нет
нет
Валидатор HTML-кода
есть
(*)
нет
нет
нет
нет
Очистка кэша
есть
нет
нет
нет
нет
Выделение/подсветка всех
вхождений кода
есть
есть
есть
есть
есть
Вьювер/редактор CSS
есть
есть
есть
есть
есть
Подсветка синтаксиса CSS
есть
есть
нет
нет
нет
Отключение стилей CSS
есть
есть
нет
нет
нет
Создание новых стилей CSS
есть
есть
нет
нет
нет
Валидатор CSS
есть
(*)
нет
нет
нет
нет
Подсветка JavaScript
есть
нет
есть
есть
нет
Отладчик JavaScript
есть
есть
есть
есть
нет
Точки остановки
выполнения скрипта
есть
есть
есть
есть
нет
Ручное
пошаговое выполнение
скрипта
есть
есть
есть
есть
нет
Профили JavaScript
есть
есть
нет
есть
нет
Выполнение JavaScript
есть
есть
есть
есть
есть
Стек вызовов
есть
есть
есть
есть
нет
Местные переменные
есть
есть
нет
есть
нет
Отслеживание переменных
есть
есть
есть
нет
нет
Вьювер для веб-сервиса
нет
есть
нет
нет
нет
Переключение режимов
совместимости браузера
есть
нет
нет
нет
нет
Парковка к границам окна
есть
есть
есть
есть
есть
Палитра цветов
есть
есть(*)
нет
нет
нет
Вкладки
нет
есть
нет
нет
нет
Скорость загрузки страницы
(Yslow)
нет
есть
нет
нет
нет
* – поддерживается на стороннем веб-сервисе
Рассмотрим подробнее средства отладки и профилирования Internet Explorer 8 и Mozilla
Firefox.
2.2. Отладка и профилирование в Internet Explorer 8
Рассмотрим, какие же возможности предоставляет IE8, и сравним их с реализацией в других
популярных веб-браузерах.
Инструменты для разработчика – Developer Tools – требуются для быстрой проверки кода
страницы на его валидность (соответствие веб-стандартам, отсутствие ошибок в синтаксисе), а
также для отладки различных сценариев (в основном, из-за распространения AJAX в
современном сайтостроительстве это отладка JavaScript) и отображения стилей (CSS,
отдельные цвета, шрифты и графика). При этом важно, чтобы данные инструменты были
встроены в сам браузер, а не представляли собой отдельное приложение. В IE длительное
время не было подобного инструмента, пока в 2007 году не появился отдельный тулбар для
разработчиков (IE Developer Toolbar). С его помощью можно было разбирать код страницы
(DOM), "на лету" проверять корректность HTML, CSS, RSS, включать отображение линеек
масштаба для последующей верстки страниц и многое другое. Кроме этого тулбара, под IE
были выпущены еще ряд инструментов – инспектор кода IEWatch, отладчики DebugBar и
Fiddler, средства для работы со скриптовыми технологиями Ajaxview и Visual Web Developer
Express. Однако в большинстве своем это были решения от сторонних разработчиков
браузера, а фирменная панель IE Developer Toolbar иногда замедляла быстродействие
браузера.
2.2.1. Состав Developer Tools
Запуск встроенного в IE8 инструмента веб-разработки осуществляется или через меню (Сервис
– Средства разработчика), или с помощью горячей клавиши F12. В отдельном окне откроется
двухпанельный редактор. В левой части будет отображаться DOM-структура сайта (секции
head, body), а справа – расширенное содержание выбранного фрагмента кода. Developer
Tools поддерживает работу по инспекции и отладке HTML, CSS, JavaScript, а также просмотр
cookies и кэша браузера.
Рис. 1 Developer Tools в Internet Explorer 8.0
Пользователь может вносить изменения в код или атрибуты элементов в режиме реального
времени (WYSWYG), одновременно наблюдая результат на странице. Также можно открывать
элементы только для чтения. Полученные в ходе редактирования веб-документы можно
сохранять на локальном диске компьютера.
Developer Tools открываются под каждую открытую в IE8 страницу, поэтому, чтобы не
загромождать экран окнами средств разработчика, их можно закреплять (команда Ctrl+P или
нажатие на пиктограмму под кнопкой закрытия окна). В этом случае окно будет располагаться
во вкладке редактируемой страницы в виде панели (рис 2).
Рис. 2. Панель Developer Tools в Internet Explorer 8.0
Работа с инструментом строится по классической схеме – пользователю нужно выделить
фрагмент страницы или участок ее кода, который автоматически будет подсвечен согласно
правилам синтаксиса HTML/CSS. Внесение изменений осуществляется простой правкой кода
или установкой других значений атрибутов, после чего требуется нажать клавишу Enter.
Отмена всех изменений производится или обновлением страницы, или нажатием на кнопку
ESC, если требуется отменять правки по частям.
2.2.2. Отладка HTML и CSS
С помощью средств разработки можно проверять код HTML и каскадные таблицы стилей сайта
в том виде, в котором они обрабатываются браузером Internet Explorer, а не в исходном виде.
Это особенно удобно в случае с динамическими сайтами, сложными сайтами и сайтами, где
применяются платформы ASP или PHP.
В основной области содержимого используется дерево документо-объектной модели (DOM)
сайта, соответствующее структуре, содержащейся в памяти браузера Internet Explorer для
отображения сайта. Для перемещения по дереву можно использовать мышь или клавиатуру.
Самый быстрый способ найти узел, соответствующий определенному элементу страницы, –
использовать функцию "Выбрать элемент щелчком". Используйте эту функцию, чтобы выбрать
элемент на странице, и в средствах разработки будет автоматически выбран нужный узел
дерева. Также можно использовать поле поиска.
После выбора элемента в дереве DOM в области свойств справа появятся более подробные
сведения о выбранном элементе:

Стиль. Команда "Стиль" повышает эффективность отладки CSS, предоставляя список всех
правил, применяющихся к выбранному элементу. Правила отображаются в порядке
следования. Правила, применяющиеся в последнюю очередь, отображаются в нижней
части списка; свойства, которые далее заменяются другими, перечеркиваются; благодаря
этому можно лучше понять, каким образом правила CSS влияют на текущий элемент, без
сопоставления селекторов вручную. Можно быстро включать и отключать правила CSS,



устанавливая или снимая флажок рядом с правилом. Изменения будут сразу же
отображаться на странице.
Отслеживать стили. Эта команда содержит такие же сведения, что и команда "Стиль", но в
данном случае стили группируются по свойствам. Если нужно найти сведения о каком-либо
свойстве, используйте команду "Трассировка стиля". Нужно всего лишь найти нужное
свойство, щелкнуть значок плюса (+), и на экране появится список всех правил,
устанавливающих данное свойство. Правила перечисляются в порядке следования.
Раскладка. Команда "Раскладка" предоставляет сведения о макете модели, такие
как смещение элементов, их высота и заполнение. Эту команду следует применять
при отладке расположения элементов.
Атрибуты. Команда "Атрибуты" дает возможность исследовать все определенные атрибуты
выбранного элемента. С помощью этой команды также можно изменять, добавлять и
удалять атрибуты выбранного элемента.
После загрузки DOM-структуры сайта пользователь увидит древовидный список структуры
тегов на левой панели. Справа же отображаются связанные с ними, соответственно, стили и
атрибуты CSS. Например, при выборе в странице тега <div> можно увидеть связанные с
таблицей классы CSS и отследить вызываемые параметры цветов, шрифтов, полей, отступов и
так далее. Здесь же в разделе "Раскладка" (Layout) будет показано расположение этого
элемента на площади страницы с указанием размеров в пикселях и пропорций. Естественно,
его можно изменять непосредственно на этой вкладке. В атрибутах отображается список всех
зависимостей HTML-кода на странице; к ним можно добавлять собственные из выпадающего
списка (рис. 3).
Рис. 3. Атрибуты в Developer Tools
Помимо отображения в рамках Developer Tools, расположение HTML-элементов можно увидеть
и на самой оригинальной странице. Для этого следует указать в меню "Как векторные" (Outline)
показ соответствующих фрагментов – ячеек таблицы, таблиц, элементов DIV-верстки, границ
рисунков в относительных, абсолютных, постоянных и перемещенных границах. В результате
на странице они будут размечены тонкими зелеными линиями.
Многие средства разработчика HTML и CSS работают с отдельными элементами веб-страницы.
Чтобы выбрать элемент, необходимо выделить на вкладке HTML или при нажатии на кнопку
"Выбрать элемент щелчком" в меню "Найти" средств разработчика. После нажатия этой кнопки
можно будет с помощью мыши выбрать элемент на веб-странице. На рис. 4 показаны
результаты выбора элемента.
Рис. 4. Результаты выбора элемента в Developer Tools
Developer Tools позволяет настраивать каскадные стили в режиме реального времени
Пользователь в одноименной вкладке выбирает нужный шаблон, описывающий оформление
страницы, после чего в левой части окна появляется иерархический список всех атрибутов.
Отключение/включение производится простой установкой или снятием галочки на
соответствующем пункте. Заметим, что, если на странице вызываются несколько шаблонов
CSS, то в списке на первом месте по умолчанию появится тот, который подгружается самым
первым.
С помощью вкладки CSS можно понять взаимодействие между таблицами стилей. Она в
большей степени полезна для сайтов, на которых используется несколько таблиц стилей. Для
переключения между таблицами стилей используйте кнопку выбора таблиц стилей. При
выборе таблицы стилей правила и связанные с ними свойства стилей появляются в основной
области содержимого. Эта информация сгруппирована по правилам стилей. По умолчанию на
этой кнопке отображается первая таблица стилей, на которую ссылается веб-страница. Как
показано на рис. 5, правила таблиц стилей отображаются под кнопкой выбора таблиц стилей.
Рис. 5. Вкладка CSS в Developer Tools
С помощью средства Layout можно вывести следующие значения:



Значения смещений, то есть расстояния между выбранным элементом и его родительскими
элементами. Смещения представлены свойствами offsetLeft и offsetTop.
Значения величин Margin, Border и Padding, которые соответствуют значениям, установленным
на веб-странице. Если в исходном коде веб-страницы значения для этих величин не указаны,
используются значения по умолчанию Windows Internet Explorer.
Глубже других внутри находятся высота и ширина элемента, которые определяются
свойствами offsetHeight и offsetWidth.
Для каждого атрибута рамочной модели указаны его величина и единица измерения. По
умолчанию значения атрибутов рамочной модели указываются в точках; если единица
измерения средством "Layout" не показана, значит, величина задана в точках. На рис.
6 изображено средство "Layout" вместе с выбранным на панели HTML (слева) элементом.
Рис. 6. Раскладка в Developer Tools
Все изменения, внесенные с помощью средств разработчика, применяются только к
внутреннему представлению сайта в браузере Internet Explorer. При обновлении страницы или
при переходе на другую страницу вновь откроется исходный сайт. Однако в некоторых случаях
может потребоваться сохранить изменения. На вкладках "HTML" и "CSS" нажмите кнопку
"Сохранить" для сохранения текущего HTML- или, соответственно, CSS-кода в файл. Помните,
что отличия от исходного кода могут быть не только в измененных вами фрагментах, но и в
других частях, поскольку в средствах разработчика сайт отображается в соответствии с кодом в
Internet Explorer, а не с кодом исходного сайта. Чтобы избежать случайной перезаписи кода,
выходные данные сохраняются в виде текста, а в начало файла добавляется комментарий.
2.2.3. Отладка JScript
Отладка JScript – это важнейший этап в разработке веб-приложений. Благодаря интуитивно
понятному упрощенному отладчику JScript средства разработчика позволяют существенно
упростить весь процесс отладки JScript. Установив Internet Explorer 8, разработчики могут
отлаживать JScript на любом сайте, загруженном в Internet Explorer (рис. 7).
Developer Tools может использоваться также и как отладчик JavaScript. Для его запуска нужно
перейти во вкладку "Сценарий" (Script) и нажать на кнопку Start Debugging. В результате
произойдет перезагрузка текущей страницы в открытой вкладке (если в настройках браузера
запрещена отладка скриптов), а Developer Tools "открепятся" от нижней части экрана.
Остановка процесса отладки производится по нажатию на клавиатурное сочетание Shift+F5
или нажав на кнопку Stop Debugging.
Рис. 7. Отладка в Developer Tools
Консоль JavaScript-кода может отслеживать вызов тех или иных переменных, выражений и
стеков вызовов.
В ходе процесса возможна установка контрольных точек автоматической остановки
выполнения – для этого нужно выделить нужное место в коде скрипта, после чего нажать на
кнопку F9. Есть также и запуск отладчика с пропуском ошибок исполнения (во избежание
остановок) – для этого можно или щелкнуть по кнопке "Остановка при ошибке" или же
продублировать это действие командой Ctrl+Shift+E. Кроме того, в случае, если установленная
контрольная точка становится неактуальной (код на странице поменялся, указан неправильный
путь до сценария и так далее), то в отладчике можно задать условия, при которых будет
выполняться остановка (устанавливается в свойствах точки остановки). Наконец, в случае,
когда выполнение сценарияприостановлено, пользователь может вручную продолжить работу
отладчика (кнопка F5), остановить процесс (Ctrl+Shift+B), перейти на следующий этап (F11) или
предыдущий шаг (F10), повторить последний цикл скрипта до текущего состояния (Shift+F11).
Любая ошибка во время выполнения приводит к тому, что отладчик автоматически
останавливается в месте возникновения ошибки. Windows Internet Explorer остановится и
выделит строку, вызвавшую ошибку, в окне просмотра исходного кода.
Примечание. Пока Windows Internet Explorer ожидает ввода от отладчика сценариев, он не
отвечает ни на какие воздействия пользователя.
Выбрать место прерывания выполнения можно при помощи установки точки останова. При
наличии точки останова исполнение сценария приостанавливается на строчке, находящейся
непосредственно перед точкой останова. В окне просмотра исходного кода подсвечивается
следующая исполняемая строчка. Точки останова можно устанавливать и после того, как
запущен отладчик. Для этого нужно или щелкнуть рядом с номером строчки кода, или вызвать
контекстное меню, или нажать клавишу F9.
На вкладке Breakpoints изображен список всех доступных точек останова. На рис. 8 показана
вкладка Breakpoints, выбранная в правой части панели отладчика.
Рис. 8. Вкладка "Точки останова" в Developer Tools
Все точки останова вместе с именами файлов и номерами строк представлены здесь. Дважды
щелкнув точку останова в этом списке, можно перейти к исходному коду, в котором она
установлена. Сняв флажок рядом с точкой останова, ее можно временно деактивировать, не
удаляя из исходного кода. Чтобы удалить точку останова, щелкните ее правой кнопкой мыши и
выберите Delete (Удалить).
Примечание. Даже если перейти со страницы текущего веб-узла, Windows Internet Explorer
сохранит информацию о точках останова до тех пор, пока не будут закрыты средства
разработчика.
Консоль JavaScript-кода может отслеживать вызов тех или иных переменных, выражений и
стеков вызовов. Все полученные результаты могут протоколироваться. Еще одна полезная для
веб-разработчика функция в Developer Tools связана с измерением производительности
JavaScript на страницах. Под страницу могут создаваться специальные профили, которые
показывают, какое количество времени было затрачено на исполнение того или
иного сценария, а также число вызовов его при открытии страницы. Соответственно, под
каждый сеанс будут создавать соответствующие отчеты, которые можно экспортировать в CSVфайл. Помимо этого, профили можно сохранять для сравнения между разными версиями кода.
В любой момент, когда исполнение сценария приостановлено точкой останова, можно
просмотреть значения переменных. С помощью средства Locals отладчика можно вывести
имена, значения и типы всех переменных, существующих в текущей области
видимости сценария. Значения переменных вне области видимости не определены. Область
видимости – это интервал, в котором можно обращаться к некоторой переменной. На рис.
9 показан вид средства Locals во время отладки.
Рис. 9. Средства "Локальные" в Developer Tools
С помощью средства Watch можно просматривать переменные из разных областей видимости.
Чтобы включить просмотр переменной, нужно найти ее в исходном тексте сценария, щелкнуть
правой кнопкой мыши и выбрать Add Watch. Таким образом, будет добавлена точка
наблюдения для идентификатора, на котором находился курсор. На рис. 10 изображено
средство Watch с наблюдаемой переменной.
Рис. 10. Средства "Смотреть" в Developer Tools
Еще один способ добавить точку наблюдения переменной – щелкнуть текст "Click to add…" в
окне Watch и ввести имя переменной.
Заметим, что функция профилирования JavaScript добавляет к функциональности отладчика
возможность оптимизации кода. Иными словами, Developer Tools содержат инструмент,
позволяющий выявить "узкие места" в веб-приложениях – обычно это наиболее часто
используемые скрипты. Для этого вебмастеру необходимо инициировать
процесс профилирования, чтобы увидеть скорость обработки сценариев. Результат будет
представлен в виде списка последовательных вызовов скрипта или отдельных его функций.
Чтобы увидеть URL, который относится к данному фрагменту и строку на странице, в IE8
должен быть включен отладчик сценариев.
2.2.4. Профилирование JavaScript
Благодаря профилированию сценариев можно улучшить работу веб-сайта посредством
идентификации и исправления связанных с производительностью проблем в коде JavaScript
(JScript).
Режим Profiler позволяет собрать информацию о временных характеристиках работы веб-узла,
которая собирается по мере визуализации страниц веб-узла обозревателем Windows Internet
Explorer. Данная информация помогает оптимизировать участки кода, на исполнение которых
уходит слишком много времени, то есть узкие места.
На вкладке "Профили" начните сеанс профилирования сценария нажатием кнопки "Запуск
создания профилей". При этом обработчик сценариев переключается в
режим профилирования, и на кнопке появляется текст "Остановка создания профилей".
Выполните сценарий, который хотите профилировать на веб-странице. Щелкните "Остановка
создания профилей" для завершения сеанса. Автоматически отображается отчет о только что
созданном профиле.
На рис. 11 показан основной пользовательский интерфейс вкладки "Профили".
Рис. 11. Вкладка "Профили" в Developer Tools
Отчеты о профилях можно просматривать в представлении "Функции" или "Дерево вызовов",
которое можно выбрать из раскрывающегося списка "Текущее представление".


В представлении "Функции" перечисляются все используемые функции.
В представлении "Дерево вызовов" показана иерархия вызовов.
В отчете показаны функции, использовавшиеся обозревателем Windows Internet Explorer для
визуализации URL-адреса. Выводится название функции, число ее вызовов, включительное и
исключительное время. Включительное время – это время, затраченное на исполнение самой
функции и всех функций, из нее вызванных. Исключительное время – это время, затраченное
на исполнение самой функции без учета функций, из нее вызванных.
С помощью собранной профилировщиком информации легко найти узкие места в коде вашего
веб-узла. Если обнаружить и изменить структуру неэффективного кода или медленных
алгоритмов, то можно сократить время, которое обозреватель Windows Internet Explorer тратит
на визуализацию веб-страниц.
Данные профиля можно экспортировать из текущего отчета в CSV-файл.
2.2.5. Другие возможности Developer Tools
При создании средств разработчика в IE8 Microsoft учла современные требования к подобным
инструментам. В частности, особое внимание было уделено к юзабилити решения. Так,
в Developer Tools поддерживается полнотекстовый поиск фрагментов HTML (окно поиска
расположено в верхнем правом углу окна), а также быстрый поиск всех вхождений тега на
основе совместимых с W3C-стандартами селекторов (например, "@table"). Просмотр с
помощью Developer Tools включен в контекстное меню IE8. В Developer Tools модули
подгружаются по мере необходимости и под конкретную страницу, не затрагивая
производительность IE8 на других открытых вкладках.
Среди прочих возможностей Developer Tools есть расширенные инструменты работы с
рисунками (показ путей, размеров, отчетов об изображениях, блокировка их на странице),
ссылками на странице (генерация отчета обо всех внешних и внутренних гиперссылках с их
атрибутами), кэшем браузера (просмотр и удаление cookies сайта или страницы, политика
обновления кэша обозревателя для страницы или всего домена), а также полезные для
верстальщика линейка масштаба, палитра цветов и подгонка страницы по определенное
разрешение (есть предустановки под стандартные 800*600 и 1024*768 пикселей и возможность
задать свой произвольный размер). Кроме того, рядом расположен переключатель
отображения веб-документа под разные версии IE – режим совместимости с IE7/IE8, а также
более старшими билдами браузера.
Developer Tools являются удобным и эффективным инструментом для решения повседневных
задач веб-мастера. В отличие от плагинов, которые загружают дополнительно не без того
ресурсоемкий процесс любого браузера (этим особенно отличаются браузеры на движке
Gecko, работающие под Windows), решение от Microsoft выглядит достойной и современной
альтернативой.
2.3. Отладка и профилирование в Firebug
Firebug – расширение для браузера Firefox, являющееся консолью, отладчиком, и DOMинспектором JavaScript, DHTML, CSS, XMLHttpRequest. Firebug показывает в консоли вызвавшую
ошибку функцию, стек вызовов функций, вызвавших эту ошибку. Он предупреждает, что CSSправило или JavaScript-метод/свойство, которое вы пытаетесь использовать, не существует.
Основные возможности Firebug:





Удобный просмотр HTML-кода страницы. Функция Inspect позволяет точно определить
местонахождение тега того или иного элемента, просмотреть все "привязанные" к нему
свойства и стили.
Редактирование HTML и CSS прямо в браузере. Можно изменять атрибуты тегов и значения
свойств для того, чтобы пронаблюдать изменения. Удобно для тех случаев, когда нужно
путём экспериментов найти наиболее приемлемый вариант оформления создаваемой
страницы.
Отладка JavaScript.
Отслеживание процесса загрузки страницы.
Просмотр HTTP-заголовков обычных и AJAX-запросов.
Firebug вызывается также при нажатии на клавишу F12 или при нажатии на изображение
"жука" в статус баре браузера (рис. 12).
Рис. 12. "Жук" в статус баре браузера
При нажатии на Control+F12 (или Command+F12 для Mac) Firebug откроется в отдельном окне
(рис. 13).
Рис. 13. FireBug в отдельном окне
Firebug, как и Developer Tools, можно "прикреплять" к инспектируемой странице (рис. 14).
Рис. 14. FireBug в виде панели браузера
2.3.1. Отладка HTML и CSS
В Firefox есть окно "View Source", но оно не покажет, как HTML выглядит на самом деле, после
трансформаций JavaScript. Вкладка HTML в Firebug показывает, как HTML выглядит в данный
момент времени.
В дополнение, вкладки справа позволят выяснить свойства индивидуальных элементов,
включая правила CSS, которые их стилизуют, размер и позицию в пикселях, и свойства DOM, к
которым есть доступ из JavaScript.
В любом сайте, основанном на JavaScript, HTML-элементы все время создаются, удаляются и
изменяются. Firebug подсвечивает изменения HTML желтым цветом, как только они
происходят.
Firebug дает возможность делать изменения в HTML и смотреть, как они тут же отражаются на
странице. Можно создавать, удалять или редактировать HTML-атрибуты и текст, просто кликая
на них и табом перемещаясь от одного к другому (рис. 15). Изменения применяются
мгновенно, в момент печати.
Рис. 15. Изменение HTML-атрибутов в FireBug
Помимо этого Firebug позволяет редактировать HTML-исходник любого элемента, нажав
правой кнопкой на элементе и выбрав "Edit HTML..." в меню.
При помощи функции "Inspect" в панели Firebug можно, выделив мышью по странице элемент,
увидеть его HTML и CSS (рис. 16).
Рис. 16. Выделение элемента на странице с помощью FireBug
Firebug предоставляет инструменты для отладки CSS. Firebug показывает правила, которые
работают в CSS, стилизуя каждый элемент (рис. 17). Правила отсортированы в восходящем
порядке, и overridden-свойства вычеркнуты. У каждого правила есть ссылка на файл, из
которого оно пришло.
Рис. 17. Выделение элемента на странице с помощью FireBug
Редактирование CSS происходит также как и HTML (рис. 18). Во время печати, изменения тут же
применяются к странице.
Рис. 18. Редактирование CSS с помощью FireBug
При желании можно добавить новое CSS свойство (рис. 19).
Рис. 19. Добавление CSS-свойства с помощью FireBug
Можно также отключать некоторые CSS свойства (рис. 20).
Рис. 20. Отключение CSS-свойства с помощью FireBug
Вкладка "Макет" (Layout) визуально разбивает каждый контейнер в контейнерной модели и
дает ширину каждого ребра (рис. 21). Дополнительно, она показывает ширину и высоту
внутреннего контейнера, и сдвиги по x и y относительно родителя.
Рис. 21. Вкладка "Макет" в FireBug
Двигая мышью по контейнерам во вкладке Layout, на странице появляются линейки и
направляющие (рис. 22).
Рис. 22. Линейки и направляющие на HTML-странице
Линейки окружают родителя текущего элемента, относительно которого заданы CSS-свойства
left, top, bottom и right. Направляющие касаются каждого края элемента и являются отличным
способом показать с точностью до пикселя, насколько точно сведены края нескольких
контейнеров.
Как и всякую другую вкладку Firebug, вкладку Layout можно редактировать.
2.3.2. Отладка JavaScript
Firebug содержит мощный JavaScript-отладчик, который дает Вам возможность приостановить
выполнение в любой момент и просмотреть каждую переменную на этот момент.
Многие веб-приложения состоят из большого числа файлов, и найти тот, который нужно
отлаживать может быть рутинной и скучной задачей. Меню для выбора скриптов
в Firebug сортирует и организует файлы в четкий и понятный список, который поможет найти
любой файл одним щелчком пальца (рис. 23).
Рис. 23. Выбор скриптового файла в FireBug
Firebug позволяет устанавливать брейкпойнты, которые говорят отладчику приостановить
выполнение скрипта, когда он дойдет до определенной строки. Пока выполнение
приостановлено, можно смотреть значения любых переменных и инспектировать объекты.
Чтобы установить брейкпойнт, необходимо кликнуть на номере любой строки, и там появится
красная точка, обозначающая, что брейкпойнт установлен.
Firebug позволяет Вам устанавливать "условные" брейпкойнты (рис. 24). Они проверяют
выражение, которое должно быть истинным, чтобы брейкпойнт сработал.
Рис. 24. Точки останова в FireBug
Когда отладчик приостановил выполнение, можно продолжать скрипт по одному шагу. Это
позволяет четко видеть, как выполнение конкретной строчки влияет на переменные и
объекты.
Также Firebug дает возможность заходить в отладчик автоматически, когда происходит ошибка
(рис. 25).
Рис. 25. Отладчик в FireBug
Когда отладчик приостанавливает выполнение, Firebug показывает стек вызова, т.е. набор
вложенных вызовов функций, которые сейчас запущены и ждут возврата. Стек вызовов
представлен компактной полоской кнопок в панели, каждая – с именем функции в стеке.
2.3.3. Профилирование
Чтобы использовать профилировщик, необходимо зайти во вкладку Console и кликнуть кнопку
"Profile". После этого можно увидеть детальный отчет, который показывает, какие функции
были вызваны и сколько времени заняла каждая (рис. 26).
Рис. 26. Профилирование в FireBug
Помимо этого у каждого файла во вкладке "Сеть" (Net) есть полоска, которая показывает, когда
началась и закончилась загрузка, относительно других файлов. Полоски могут показать,
например, что JavaScript файлы загружаются по очереди, и никогда – параллельно. Это
поможет оптимизировать порядок файлов на странице, чтобы пользователь проводил меньше
времени, ожидая показа страницы. Также в панели Net можно фильтровать список по типам
файлов (JavaScript, картинки и др.).
Рис. 27. Вкладка "Сеть" в FireBug
Firebug обозначает запросы, которые загружаются из кэша браузера вместо сети, светлосерым, так что можно легко заметить, насколько эффективно сайт использует кэш для
оптимизации времени загрузки страницы.
Плюс ко всему Firebug показывает каждый XMLHttpRequest (например, используемые AJAX), и
во вкладке Net, и в Console, вместе с текстом, который был отправлен и получен (рис. 28).
Рис. 28. XMLHttpRequest в FireBug
3. Краткие итоги
Функциональное тестирование – процесс верификации соответствия функционирования
продукта его начальным спецификациям.
Методы функционального тестирования веб-приложений:
1.
2.
3.
4.
5.
6.
Record & Play;
Functional Decomposition;
Data-driven;
Keyword-driven;
Object-driven;
Model-based.
Функциональное тестирование пользовательского интерфейса состоит из пяти фаз:





анализ требований к пользовательскому интерфейсу;
разработка тест-требований и тест-планов для проверки пользовательского интерфейса;
выполнение тестовых примеров и сбор информации о выполнении тестов;
определение полноты покрытия пользовательского интерфейса требованиями.
составление отчетов о проблемах в случае несовпадения поведения системы и требований,
либо в случае отсутствия требований на отдельные интерфейсные элементы.
Тестирование удобства пользования дает оценку уровня удобства использования приложения
по следующим пунктам:




производительность, эффективность;
правильность;
активизация в памяти;
эмоциональная реакция;
В нагрузочное тестирование входят следующие тесты:







Тестирование производительности ;
Стрессовое тестирование ;
Объемное тестирование ;
Тестирование стабильности или надежности;
Моделирование Транзакций ;
Метод "Анализ данных на стороне клиента" ;
Метод "Анализ Сетевого Трафика" ;
Другие виды тестирования Веб-приложений: проверка ссылок, тестирование безопасности,
проверка верности HTML-кода.
Процесс автоматизации тестирования делится на три этапа [20]:



Запись;
Улучшение;
Воспроизведение;
Для автоматизации тестирования существует большое количество приложений.
Отладка – этап разработки компьютерной программы, на котором обнаруживают, локализуют
и устраняют ошибки.
Профилирование – сбор характеристик работы программы, таких как время
выполнения отдельных фрагментов (обычно подпрограмм), число верно предсказанных
условных переходов, число кэш промахов и т. д.
Internet Explorer Developer Tools, входящий в комплект IE8 – инструмент для разработчика,
требующийся для быстрой проверки кода страницы на его валидность, а также
для отладки различных сценариев и отображения стилей.
Firebug – расширение для браузера Firefox, являющееся консолью, отладчиком, и DOMинспектором JavaScript, DHTML, CSS, XMLHttpRequest.
Файлы. Документ Курс. Презентация Тестирование W-П
Курс UT-006. Основы управления
тестированием
1. Основы теории качества
1.1. Основы модели качества
Качество системы - это степень удовлетворения системой заявленных и
подразумеваемых потребностей различных заинтересованных сторон, которая позволяет,
таким образом, оценить достоинства. Эти заявленные и подразумеваемые потребности
представлены в международных стандартах серии SQuaRE посредством моделей качества,
которые представляют качество продукта в виде разбивки на классы характеристик,
которые в отдельных случаях далее разделяются на подхарактеристики. Измеримые,
связанные с качеством свойства системы называют свойствами качества, связанными с
соответствующими показателями качества.
К настоящему времени в серии SQuaRE имеются три модели качества: модель качества
при использовании и модель качества продукта, определенные в ИСО/МЭК 25010, и
модель качества данных, определенная в ИСО/МЭК 25012. Совместное использование
моделей качества дает основание считать, что учтены все характеристики качества. Но не
все характеристики качества из полного множества, обеспечиваемого этими моделями,
значимы для конкретной заинтересованной стороны.
Рассмотрим модель качества при использовании и модель качества продукта.
Модель качества при использовании
Качество при использовании - это степень, в которой продукт или система могут
использоваться конкретными пользователями для достижения определенных целей с
эффективностью, производительностью, свободой от риска и удовлетворенностью в
конкретных условиях использования для удовлетворения их потребностей.
Свойства качества при использовании представляют собой пять характеристик, которыми
являются: эффективность, производительность, удовлетворенность, свобода от риска и
покрытие контекста.
Эффективность. Точность и полнота, с которой пользователи достигают определенных целей.
Производительность. Связь точности и полноты достижения пользователями целей с
израсходованными ресурсами.
Удовлетворенность. Способность продукта или системы удовлетворить требованиям
пользователя в заданном контексте использования.
Свобода от риска. Способность продукта или системы смягчать потенциальный риск для
экономического положения, жизни, здоровья или окружающей среды.
Полнота контекста. Степень, в которой продукт или система могут быть использованы с
эффективностью, результативностью, свободой от риска и в соответствии с требованиями при
всех указанных условиях использования.
Качество при использовании системы характеризует воздействие продукции (система или
программный продукт) на заинтересованную сторону. Оно определяется качествами
программного обеспечения, аппаратных средств, операционной среды, а также
характеристиками пользователей, задач и социальной среды. Все эти факторы вносят свой
вклад в качество системы при использовании.
Модель качества продукта
Модель качества продукта разделяет свойства качества продукта на восемь характеристик,
которыми являются: функциональная пригодность, надежность, уровень производительности,
удобство использования, защищенность, совместимость, сопровождаемость и переносимость.
Функциональная пригодность. Степень, в которой продукт или система обеспечивают
выполнение функции в соответствии с заявленными и подразумеваемыми потребностями при
использовании в указанных условиях.
Уровень производительности. Производительность относительно суммы использованных
при определенных условиях ресурсов.
Совместимость. Способность продукта, системы или компонента обмениваться информацией
с другими продуктами, системами или компонентами, и/или выполнять требуемые функции
при совместном использовании одних и тех же аппаратных средств или программной среды.
Удобство использования. Степень, в которой продукт или система могут быть использованы
определенными пользователями для достижения конкретных целей с эффективностью,
результативностью и удовлетворенностью в заданном контексте использования.
Надежность. Степень выполнения системой, продуктом или компонентом определенных
функций при указанных условиях в течение установленного периода времени.
Защищенность. Степень защищенности информации и данных, обеспечиваемая продуктом
или системой путем ограничения доступа людей, других продуктов или систем к данным в
соответствии с типами и уровнями авторизации.
Сопровождаемость. Результативность и эффективность, с которыми продукт или система
могут быть модифицированы предполагаемыми специалистами по обслуживанию.
Переносимость. Степень простоты эффективного и рационального переноса системы,
продукта или компонента из одной среды (аппаратных средств, программного обеспечения,
операционных условий или условий использования) в другую.
Применение модели качества
Модели качества продукции и качества при использовании могут быть использованы для
определения требований, выработки показателей и выполнения оценки качества.
Определенные характеристики качества могут использоваться в качестве контрольного списка
для обеспечения детального исследования требований к качеству, обеспечивая таким образом
основу для оценки необходимых в процессе разработки систем последующих трудозатрат и
действий. Характеристики в модели качества при использовании и модели качества продукта
предназначены для использования в качестве набора при спецификации или оценке качества
программного продукта.
Практически невозможно определить или измерить все подхарактеристики для программного
продукта. Аналогично в большинстве случаев практически не применимо определение или
измерение качества при использовании для всех возможных сценариев задач пользователя.
Относительная важность характеристик качества зависит от целей высокого уровня и целей
проекта. В связи с этим перед использованием для выделения из требований тех характеристик
и подхарактеристик, которые наиболее важны, модель должна быть соответствующим
образом адаптирована, а ресурсы распределены между различными типами показателей в
зависимости от целей заинтересованных лиц и целей продукта.
1.2. Качество программного обеспечения
Качество программного обеспечения (Software Quality) – это степень, в которой
программное обеспечение обладает требуемой комбинацией свойств.
Верификация (verification) — это процесс оценки системы или её компонентов с целью
определения удовлетворяют ли результаты текущего этапа разработки условиям,
сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по
разработке проекта, определенные в начале текущей фазы.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и
потребностям пользователя, требованиям к системе.
Этапы обеспечения качества:
- внутренний (формирует природу качества создаваемого продукта);
- внешний (контролирует природу качества созданного продукта).
К внутренним этапам относятся:
1) тестирование документации. Включает в себя проверки документации на:
- логику;
- полноту;
- функциональность;
- однозначность.
2) unit-тесты. Позволяет провести проверки на уровне самого кода, проверяя отдельные
функции и методы;
3) code-review. Позволяет определить степень соответствия кода реализации
регламентированным нормам и обеспечить его прозрачную поддерживаемость в будущем;
4) менеджерская приемка. Позволяет определить общее соответствие фактической
реализации, ожидаемому результату заказчика.
К внешним этапам относятся:
1) тестирование;
2) обработка пользовательской обратной связи.
Тестирование – это одна из техник контроля качества, включающая в себя активности по
планированию работ (Test Management), проектированию тестов (Test Design), выполнению
тестирования (Test Execution) и анализу полученных результатов (Test Analysis).
Роль тестирования в проекте.
Выделяют три основные роли тестирования в проекте:
1) Объективная оценка качества системы;
2) Валидация требований к системе;
3) Снижение риска неприемлемости системы для заказчика.
2. Цели тестирования
Целью тестирования является:
1. выявление проблем, связанных с несоответствием разрабатываемого программного
продукта и требованиям к нему;
2. учет статуса проблем;
3. предотвращение дефектов;
4. снижение рисков проекта, связанных с качеством разрабатываемого продукта.
Если посмотреть с другой стороны, тестирование проводится в соответствии с определенными
целями (могут быть заданы явно или неявно) и различным уровнем точности. Определение
цели точным образом, выражаемым количественно, позволяет обеспечить контроль
результатов тестирования.
Тестовые сценарии могут разрабатываться как для проверки функциональных требований
(известны как функциональные тесты), так и для оценки нефункциональных требований. При
этом, существуют такие тесты, когда количественные параметры и результаты тестов могут
лишь опосредованно говорить об удовлетворении целям тестирования (например, “usability” –
легкость, простота использования, в большинстве случаев, не может быть явно описана
количественными характеристиками).
Можно выделить следующие, наиболее распространенные и обоснованные цели (а,
соответственно, виды) тестирования:
1) Приёмочное тестирование (Acceptance/qualification testing)
Проверяет поведение системы на предмет удовлетворения требований заказчика. Это
возможно в том случае, если заказчик берет на себя ответственность, связанную с
проведением таких работ, как сторона “принимающая” программную систему, или
специфицированы типовые задачи, успешная проверка (тестирование) которых позволяет
говорить об удовлетворении требований заказчика.
Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них.
2) Установочное тестирование (Installation testing)
Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции
системы в целевом окружении.
3) Альфа и бета-тестирование (Alpha and beta testing)
Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить
стадии альфа (внутреннее пробное использование) и бета (пробное использование с
привлечением отобранных внешних пользователей) версий.
4) Функциональные тесты/тесты соответствия (Conformance testing/Functional
testing/Correctness testing)
Эти тесты могут называться по-разному, однако, их суть проста – проверка соответствия
системы, предъявляемым к ней требованиям, описанным на уровне спецификации
поведенческих характеристик.
5) Достижение и оценка надежности (Reliability achievement and evaluation)
Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение
надежности программных систем. Случайно генерируемые сценарии тестирования могут
применяться для статистической оценки надежности. Обе цели – повышение и оценка
надежности – могут достигаться при использовании моделей повышения надежности.
6) Регрессионное тестирование (Regression testing)
Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software
Engineering Terminology”) гласит: “повторное выборочное тестирование системы или
компонентов для проверки сделанных модификаций не должно приводить к
непредусмотренным эффектам”. На практике это означает, что если система успешно
проходила тесты до внесения модификаций, она должна их проходит и после внесения
таковых. Основная проблема регрессионного тестирования заключается в поиске
компромисса между имеющимися ресурсами и необходимостью проведения таких тестов по
мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы
определить критерии “масштабов” изменений, с достижением которых необходимо проводить
регрессионные тесты.
7) Тестирование производительности (Performance testing)
Специализированные тесты проверки удовлетворения специфических требований,
предъявляемых к параметрам производительности. Существует особый подвид таких тестов,
когда делается попытка достижения количественных пределов, обусловленных
характеристиками самой системы и ее операционного окружения.
8) Нагрузочное тестирование (Stress testing)
Необходимо понимать отличия между рассмотренным выше тестированием
производительности с целью достижения ее реальных (достижимых) возможностей
производительности и выполнением программной системы c повышением нагрузки, вплоть до
достижения запланированных характеристик и далее, с отслеживанием поведения на всем
протяжении повышения загрузки системы.
9) Сравнительное тестирование (Back-to-back testing)
Единичный набор тестов, позволяющих сравнить две версии системы.
10) Восстановительные тесты (Recovery testing)
Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы
(disaster), влияющей на функционирование операционной среды, в которой выполняется
система.
11) Конфигурационное тестирование (Configuration testing)
В случаях, если программное обеспечение создается для использования различными
пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку
поведения и работоспособности системы в различных конфигурациях.
12) Тестирование удобства и простоты использования (Usability testing)
Цель – проверить, насколько легко конечный пользователь системы может ее освоить,
включая не только функциональную составляющую – саму систему, но и ее документацию;
насколько эффективно пользователь может выполнять задачи, автоматизация которых
осуществляется с использованием данной системы; наконец, насколько хорошо система
застрахована (с точки зрения потенциальных сбоев) от ошибок пользователя.
3. Жизненный цикл тестирования
Роль тестирования в жизненном цикле разработки ПО
В первую очередь стоит отметить, что процесс тестирования ПО тесно связан непосредственно
с процессом разработки. Жизненный цикл разработки состоит из следующих этапов:
1.
Анализ требований
2.
Дизайн
3.
Разработка
4.
Тестирование
5.
Эксплуатация и поддержка
Как показано в списке выше, мы должны провести тестирование на четвертом шаге
жизненного цикла. Но обычно в случае, если нашей главной целью является получить
высококачественное ПО и минимизировать затраты на исправление багов, мы можем
проводить тестирование уже на стадии анализа требований. Чем раньше вы приступите к
тестам, тем лучших результатов добьетесь.
Преимущества проведения тестов на каждом этапе жизненного цикла ПО
Давайте детально рассмотрим, какие преимущества может принести проведение тестирования
на каждом этапе процесса разработки, начиная с самого первого.
Первый этап. Анализ требований
Давайте начнем с первого этапа жизненного цикла разработки: анализ требований.
Требования к конечному продукту обычно формулируются заказчиком или менеджером
проекта. Эти требования могут быть как функциональными, так и нефункциональными. Они
формируются в процессе общения с заказчиком или анализа стандартов и нормативной
документации. Зачем же необходимо проводить тесты ПО на этом этапе жизненного цикла и
какие преимущества это может нам принести?
Представим ситуацию, при которой имеющиеся требования не были протестированы, но были
использованы на этапе дизайна и разработки. Только после того, как разработка закончена,
требования и сам продукт направляются в отдел тестирования. Как было сказано ранее, в
процессе тестирования мы проверяем, соответствует ли текущее поведение продукта
заявленным требованиям. А это значит, что отдел тестирования может обнаружить ошибки не
только в самом продукте, но также и в документации. Как вы можете представить, в этом
случае исправление ошибок обойдется гораздо дороже в сравнении с подходом, который
предусматривает включение тестов в самые ранние этапы жизненного цикла ПО, такие как
фаза анализа требований. Тщательным образом, проанализировав требования, вы можете
собрать информацию, которая поможет вам оптимизировать процесс работы над проектом с
самых первых дней. Как правило, тестирование требований происходит на этапе анализа
требований. Эта задача подразумевает ряд тестов, основанных на таких характеристиках как
завершенность, согласованность, недвусмысленность и т.д. Главная задача такого подхода —
убедиться в том, что требования заказчика были правильно интерпретированы и остаются
корректными, понятными и последовательными. Важно отметить, что ясная и точная
документация помогает выбрать правильные цели для процесса тестирования.
Второй этап. Процесс дизайна
Следующим этапом жизненного цикла разработки ПО является процесс дизайна. Как и
тестирование требований на стадии анализа требований, этот этап подразумевает проверку
уже созданных прототипов на предмет их корректности и соответствия ожиданиям заказчика.
Более того, проверка удобства в использовании также должна быть проведена на этом этапе.
Также следует начать создание тестовой документации для данного проекта. Эта задача
включает в себя подготовку плана тестирования, тест-кейсов, юзкейсов, чек-листов. Процесс
тестирования ПО на этом этапе обеспечивает способность проникновения в суть продукта и
понимание ее соответствия требованиям.
Третий этап. Разработка
В процессе этапа разработки важно провести модульное, интеграционное и системное
тестирование. В самом начале этого шага разработки проводится модульное тестирование.
Этот процесс представляет собой проверку отдельного модуля системы или функционала.
Интеграционное тестирование проводится после того, как несколько модулей объединены
вместе как отдельная часть приложения. В дальнейшем в процессе разработки все больше и
больше модулей объединяются воедино. После того, как разработка закончена, наступает
время подготовки к системному тестированию. Эта стадия жизненного цикла разработки ПО
подразумевает общий тест системы на предмет интеграции ее компонентов. Это значит, что в
случае, если система состоит из различных модулей, мы должны проверить, насколько хорошо
или насколько плохо каждый из них работает внутри системы. Более того, на этом этапе важно
произвести тестирование пользовательского интерфейса.
Четвертый этап. Процесс тестирования и дебаггинга
На этом шагу вы должны провести тесты независимо от того, проводились ли они на
предыдущих этапах. Должны быть проведены полное функциональное тестирование и
тестирование пользовательских интерфейсов, а все обнаруженные дефекты должны быть
задокументированы в системе баг-трекинга. Помимо этого, применяется регрессионное
тестирование. После завершения дебаггинга предоставляется оценка общего качества
продукта. После завершения последнего теста процесс тестирования ПО считается
законченным.
Пятый этап. Эксплуатация и поддержка
Даже после достижения стадии релиза продукта, остается необходимость в тестировании,
проводимом на этапе эксплуатации и поддержки. Разные пользователи могут работать в
абсолютно разных окружениях. Поэтому всегда возможно, что новые ошибки, которые не
были выявлены ранее, дадут о себе знать. Более того, пользователи могут использовать ПО
изначально непредвиденным способом. Это, в свою очередь, может вызвать некоторые
непредвиденные проблемы. В таком случае потребуется вмешательство отдела тестирования.
Очевидно, что процесс управления тестированием ПО затрагивает все этапы жизненного
цикла разработки. Он подразумевает сравнение действительного состояния продукта и того
состояния, которое было запланировано и задокументировано в плане тестирования продукта.
Процесс тестирования, анализа и мониторинга помогает спланировать и изменить
последующие задачи наилучшим путем.
Жизненный цикл тестирования
Следуя общей логике итеративности, превалирующей во всех современных моделях
разработки ПО, жизненный цикл тестирования также выражается замкнутой
последовательностью действий.
Стадия 1 (общее планирование и анализ требований) объективно необходима как минимум
для того, чтобы иметь ответ на такие вопросы, как: что нам предстоит тестировать; как много
будет работы; какие есть сложности; всё ли необходимое у нас есть и т.п. Как правило,
получить ответы на эти вопросы невозможно без анализа требований, т.к. именно требования
являются первичным источником ответов.
Стадия 2 (уточнение критериев приёмки) позволяет сформулировать или уточнить метрики и
признаки возможности или необходимости начала тестирования, приостановки и
возобновления тестирования, завершения или прекращения тестирования.
Стадия 3 (уточнение стратегии тестирования) представляет собой ещё одно обращение к
планированию, но уже на локальном уровне: рассматриваются и уточняются те части стратегии
тестирования, которые актуальны для текущей итерации.
Стадия 4 (разработка тест-кейсов) посвящена разработке, пересмотру, уточнению, доработке,
переработке и прочим действиям с тест-кейсами, наборами тест-кейсов, тестовыми
сценариями и иными артефактами, которые будут использоваться при непосредственном
выполнении тестирования.
Стадия 5 (выполнение тест-кейсов) и стадия 6 (фиксация найденных дефектов) тесно связаны
между собой и фактически выполняются параллельно: дефекты фиксируются сразу по факту их
обнаружения в процессе выполнения тест-кейсов.
Стадия 7 (анализ результатов тестирования) и стадия 8 (отчётность) также тесно связаны
между собой и выполняются практически параллельно. Формулируемые на стадии анализа
результатов выводы напрямую зависят от плана тестирования, критериев приёмки и
уточнённой стратегии, полученных на стадиях 1, 2 и 3. Полученные выводы оформляются на
стадии 8 и служат основной для стадий 1, 2 и 3 следующей итерации тестирования. Таким
образом, цикл замыкается.
Жизненный цикл тестирования ПО является процессом, которого нельзя избежать. Он
непрерывен, продолжителен и требует наличия команды тестирования, достаточно опытной
для того, чтобы произвести полный цикл тестирования. Эта неотъемлемая часть современного
процесса разработки ПО помогает заказчику, команде разработчиков, а также конечному
пользователю получить продукт высокого качества.
4. Риски в тестировании
Риск — это существующий или развивающийся фактор процесса, который обладает
потенциально негативным воздействием на процесс.
Разграничим риск и проблему: риск это то, что может случиться и привести к негативным
последствиям, а проблема, это то, что уже случилось и мешает работать. И риск и проблема
мешают или могут мешать работать, но способы работы с рисками и проблемами несколько
разные: первые надо пытаться понять, найти и по возможности минимизировать их
последствия до того как они «выстрелят», а с проблемами надо работать по факту — чинить
или «тушить». Если отделить риски и проблемы, область управления рисками становится
намного проще и понятнее.
4.1. Как работать с рисками
Алгоритм работы с рисками можно неплохо представить в виде часто используемой в
тренингах и литературе картинки:
Активности работы с рисками цикличные, как и любые другие проектные активности, если вы
работаете в итерациях. При этом, если итерации у вас достаточно длинные, циклов работ
связанных с управлением рисками может быть несколько, такие внутренние циклы можно для
простоты называть «петлями».
Что, обычно, вызывает сложности на начальных этапах работы с рисками: собственно начать
(внести эти активности в рабочие планы); понять, что эти активности как и любые другие
должны быть спланированы, обеспечены ресурсами (исполнителями), выполнены, а
результаты должны быть проанализированы (что «выстрелило», что — нет, с чем мы
справились успешно и т.д.).
Иногда мы ничего не можем сделать с риском или наших воздействий недостаточно, чтобы
исключить риск из списка, да так бывает. Системные риски на то и системные, что
полностью исключены быть не могут, так как зачастую являются особенностью процесса, в
котором мы работаем. Разминирование мин, процесс рискованный, но работать надо. В
этом случае мы пытаемся себя подстраховать на случай пожара от его последствий и
расписываем инструкции на случай военных действий.
Не буду останавливаться подробнее, но этап анализа полученных результатов и извлечения
уроков часто игнорируется, что приводит к повторению неудачного результата на следующих
итерациях — что, собственно, характерно для любого процесса: если вы не анализируете «куда
попали», в следующий выстрел попадаете снова «куда-то туда…», вместо того, чтобы попасть
«туда, куда нужно».
Что хотелось бы зафиксировать, прежде чем мы приступим к рассмотрению типичных рисков
связанных с тестированием ПО. Для того, чтобы правильно работать с рисками и эта работа
приносила результаты, нужно чётко понимать к какому уровню относится тот или иной риск —
к уровню вашей ответственности как менеджера по тестированию или к уровню проектных
рисков, работать на котором нужно вместе с менеджером проекта и ведущим разработчиком.
Системные риски или риски уровня бизнеса компании, в которой вы трудитесь, обычно
находятся вне зоны влияния проектной команды, но проектная команда может принимать
участие в подготовке каких-то решений и анализе текущей ситуации, чтобы предоставить
принимающим решение лицам актуальную и понятную информацию.
4.2. Типичные риски в тестировании ПО
Неполная оценка трудозатрат по проекту
В целом, данный риск, конечно, относится к уровню проектных рисков, а точнее к рискам
управления проектами. Но, так как оценка трудозатрат по проекту включает оценку
трудозатрат по тестированию, а работы по тестированию стоят на критическом пути плана
итерации, то риск зачастую связан с неправильной оценкой трудозатрат по тестированию,
который мы рассмотрим следующим отдельным риском.
Риск характеризуется тем, что тестировщики не привлекаются ни к ревью трудозатрат по
проекту, ни к получению самих оценок. Ситуация в которой оценки на тестирование просто
спускаются менеджером проекта, заказчиком или кем-то ещё зачастую клиническая и
противоречит основным принципам управления проектами: оценку задачи даёт исполнитель,
иначе исполнитель может не браться за выполнение задачи или не отвечает за её результат.
Повторюсь — риск проектного уровня, если речь идёт об оценке трудозатрат по проекту, но
частично может управляться и минимизироваться группой тестирования или её менеджером,
путём включения тестировщиков в процесс получения оценок по трудозатратам и ревью
полученных оценок и планов проекта.
Неполная оценка трудозатрат по тестированию
Аналогичный предыдущему риск, базирующийся в основном на нарушении принципа «оценку
трудозатрат даёт исполнитель», но уже на уровне задач проекта по тестированию.
Кроме базовой причины «выстрела» данного риска, также существенно рискованными
факторами могут быть пропуск неявных требований, неверное определение типов тестов и
конфигураций в которых будет проводиться тестирование — эти задачи являются наиболее
влияющими на объём работ по тестированию и как следствие ошибки, допущенные при
выполнении этих задач, приводят к изменению объёмов работ по тестированию и
существенно влияют на план тестирования.
Как бороться: ревью и аудиты, формальные и «на бегу». В этом месте одна голова хорошо, а
две — лучше.
Ситуация может порождаться или усугубляться совмещением ролей тест-менеджера и тестдизайнера. При разделении этих проектных ролей на разных участников команды
тестирования, тест-дизайнер должен обосновать и защитить предлагаемую им стратегию
тестирования и свою оценку трудозатрат. Подобная защита, зачастую работает лучше чем
формальный ревью.
Тест-план не привязан к плану проекта
Строго говоря, это именно проблема процесса тестирования, которая, между тем, настолько
распространена, что необходимо акцентировать на ней внимание как на серьёзном риске.
Тестирование и разработка сидят на одном проектном ресурсе — на времени. Если планы двух
направлений не связаны жестко (лучше всего на уровне одного общего плана работ по
проекту, буквально линками между задачами в MS Project или любой другой подобной
системе) или не синхронизированы на постоянной основе, существует вероятность или
риск, что сдвиг планов разработки (который влияет на дату поставки версии в тестирование) не
будет учтён в плане работ по тестированию, что приведёт к недостатку времени на
тестирование и, как следствие, к незавершению этапа тестирования.
Почему планы тестирования и разработки ещё должны быть связаны жестко на уровне
единого плана проекта: в зону ответственности менеджера проекта, при фиксированной
длительности итерации кроме всего прочего относится управление объёмом итерации, для
чего ему необходимо видеть работы по тестированию. Грубо говоря, в ограниченной по
времени итерации задача ПМ-а выбрать такой объём функционала, который команда успеет и
сделать и протестировать.
Если менеджеру проекта оценки трудозатрат по тестированию не нужны, задача менеджера по
тестированию внести свои работы в план проекта и связать их с соотв. задачами по
разработке. В такой схеме сдвинуть сроки тестирования крайне сложно — какая-то часть работ
по тестированию просто будет наглядно вылазить за deadline в плане или на диаграммах.
Стратегия тестирования отсутствует или непринята группой разработки или заказчиком
Формально не риск, а проблема, которая порождает риск, что стратегия тестирования не будет
выполнена в той части задач, где пересекается с задачами разработки или не будет обеспечена
ресурсами (зачастую именно проектным временем) и как результат всё равно не выполнена.
Как бороться: формальный ревью стратегии или плана тестирования здесь обычно не
помогает. Формальный апрув в этом месте, зачастую означает «я видел, что у тебя есть
документ с названием Стратегия или План и ты его обновил в этой итерации». По факту это
слова «молодец, главное чтобы ты хорошо учился», которые не дают вам, как тест-менеджеру,
возможности получать необходимое понимание в команде разработки и соответствующие
ресурсы на выполнение этой стратегии и ваших планов.
Увольнение сотрудников
Риск увольнения ключевого или не очень ключевого сотрудника есть всегда.
Проблема не в том, что люди уходят, а в том, что уходят тогда, когда нужно им, а не проекту, а
на ввод нового сотрудника, его обучение и вывод на «проектную мощность» требуется время
— соответственно планы проседают, скорость падает, все нервничают.
Что делать. Держать «скамейку запасных» не всегда возможно по экономическим причинам.
«Кормить лучше» помогает далеко не всегда, а иногда (в случае как раз с не ключевыми
товарищами) это ещё и попросту невыгодно. Что тут можно сделать? Самое очевидное, это
«договориться с соседями» — просто побеседовать с соседними отделами или проектами (у
которых этот риск тоже есть) и договориться, что в случае такого события, они смогут хоть както (если это позволит специфика продукта и текущая загруженность) помочь вам людьми.
Аналогично, будьте готовы помочь сами. Да-да, спасение утопающих — дело рук самих
утопающих.
Остальные проблемы
Изменение даже зафиксированных требований или их приоритетов, зачастую относят к
рискам, как к фактору, который повлияет на объём итерации и соответственно приведёт к
пересмотру планов и возможно срыву сроков поставки версии. Не стоит называть эту часть
проектной работы риском — это реальность, с которой надо работать как с проектным
ограничением и стараться не дотягивать даже до состояния проблемы. Действенным путём
является как раз ограничение объёмов итерации по срокам, когда любое изменение в
требованиях приводит к выталкиванию какого-то другого кусочка работ (и девелопмент и
тестирование) в следующую итерацию. Принудительно или административно «заставить»
требования не меняться ещё ни у кого не получалось – бизнес меняется, требования меняются
и если Заказчик готов платить не только за естественные изменения в требованиях, но и за
свои «фантазии» или «неорганизованность» — это надо принять и уметь с этим жить. Способы
есть и они работают.
Риск игнорирования рисков
Один из рисков, который распространяется на все уровни управления рисками.
Нежелание принимать во внимание тот факт, что риски есть, что процесс (даже самый
налаженный, выверенный, формализованный и контролируемый) может давать сбои, обычно
приводит к чересчур оптимистичным планам, к конфликтам при их невыполнении, к
необходимости перепланировать в «пожарном режиме» (что обычно приводит к просчётам и
ещё больше нарушает нормальный ритм работ) и как результат к провалам.
Что делать: начать работать с рисками (как бы избито и банально не звучал этот вывод, но
другой рекомендации тут нет). В тестировании специфичных рисков немного. Большинство
рисков проектного уровня, могут решаться совместными усилиями групп тестирования,
разработки и управления проектом.
5. Рекомендации по управлению тестированием
Ниже приведены общие рекомендации, которые могут улучшить процесс управления
тестированием программного обеспечения.
1) Начинайте работу по управлению тестированием как можно раньше.
Хотя это может показаться самым очевидным предложением, немногие программные проекты
действительно применяют эту концепцию. Необходимо подключать ресурсы тестирования к
ранним стадиям разработки ПО – проводить анализ требований, формировать тест-кейсы.
Более ранняя разработка тест-кейсов смягчает неизбежно наступающие временные
ограничения.
2) Тестируйте в итеративном режиме.
Тестирование программного обеспечения должно быть итеративным процессом,
генерирующим ценные тестовые артефакты и результаты на ранних стадиях всего цикла жизни
проекта. Это следует из первой рекомендации о раннем начале процесса тестирования итеративный процесс тестирования вынуждает рано обращать внимание на управление
тестированием. Управление тестированием обеспечивает это путем организации различных
артефактов и ресурсов в итерации. Этот основанный на оценке рисков подход может
гарантировать, что с изменениями, задержками и другими непредвиденными препятствиями,
которые возможны в цикле жизни проекта, можно будет справиться очень эффективно.
3) Повторное использование тестовых артефактов.
Повторное использование тестовых артефактов в проекте (или в разных проектах) может
заметно улучшить эффективность группы тестирования. Оно может значительно снизить
давление ограничений времени и ресурсов. К повторно используемым артефактам относятся
не только объекты автоматизации тестирования, но также тестовые процедуры и другая
информация планирования. Для эффективного использования таких артефактов, управление
тестированием должно выполнить значительную работу по организации и определению
различной информации о тестировании, используемой для данного проекта. Повторное
использование всегда требует некоторой предусмотрительности при создании артефактов, и
этот принцип может повсюду применяться в управлении тестированием.
4) Используйте тестирование, основанное на требованиях.
Тестирование может быть разделено на два общих подхода:
- проверка того, выполняет ли что-нибудь то, что от него ожидается;
- попытка определить, что может нарушить работу чего-нибудь.
Хотя последнее исследовательское тестирование важно для обнаружения трудно
предсказуемых сценариев и ситуаций, приводящих к ошибке, проверка основных требований,
вероятно, является наиболее критичной оценкой, выполняемой группой тестировщиков.
Основанное на требованиях тестирование является основным способом проверки
приложения или системы. Основанное на требованиях тестирование имеет тенденцию быть
менее субъективным, чем исследовательское тестирование, а также может обеспечить и
другие преимущества. Некоторые участники группы тестировщиков могут усомниться или
даже признать негодными результаты исследовательского тестирования, но они не могут
поставить под сомнение тщательно разработанные тесты, которые напрямую проверяют
требования. Еще одним преимуществом является то, что требуемые действия по тестированию
могут быть более просто вычислены (отличие от исследовательского тестирования, которое,
зачастую, ограничивается только доступным временем).
Можно также предоставить различные статистические данные, которые могут быть полезными
показателями качества, например, объем тестирования.
5) Определение и выполнение гибкого процесса тестирования.
Хороший, повторяемый процесс может помочь вам понять текущее состояние проекта и,
поскольку проект становится более предсказуемым, куда он направляется. Однако различные
проекты будут иметь различные специализированные требования для тестирования, поэтому
процесс управления тестированием, автоматизирующий потоки задач, должен быть гибким и
настраиваемым. Процесс должен быть повторяемым (для обеспечения предсказуемости), но
что более важно, - он должен быть пригоден для улучшений. Должна быть обеспечена
возможность достаточно легко выполнять редактирование процесса, включая настройку во
время итераций, так чтобы его можно было оптимизировать, исходя из изменившихся
требований.
Файлы. Презентация основы управления тестированием
Курс UT-007. Тестирование безопасности Webприложений
Введение
Веб-технологии используются практически повсеместно – интернет-магазины, банки, да и
просто веб-страницы какой-либо фирмы. Они могут иметь как сложные интерфейсы, так и
простенькие с одним двумя полями ввода, для быстрого доступа к информации, хранящейся в
базе данных. Специалистов веб-технологии привлекают доступностью с любой точки планеты,
быстрой разработкой и независимостью от клиентской платформы. Для управления
достаточно веб-браузера который давно уже стал стандартным компонентом любой ОС,
включая используемых в карманных компьютерах и смартфонах.
К сожалению, доступность веб-приложения отовсюду, имеет и свой минус – приходится
уделять дополнительное внимание безопасности решения. А это не простой вопрос. Ведь в
формировании результирующего контента участвует несколько элементов – веб-сервер или
сервер-приложений, обработчик (HTML, PHP, Python, Perl, Ruby, JavaScript, + AJAX и т.п.), база
данных. И это только небольшой список технологий, которые должны работать как единое
целое, выдавая результат. Причем конечных решений может быть много. Ведь список тех же
веб-серверов насчитывает уже десяток вариантов. Естественно разработчик предусмотреть все
возможные проблемы для разных ситуаций просто не в состоянии. В результате получаем
целый букет специфический атак направленных на веб-приложения – XSS (Cross-Site Scripting),
SQL injection, подмена сессии, подмена прототипа и др. Все в различных вариантах исполнения.
Причем это не болезнь маленьких проектов, уязвимостям подвержены и крупные проекты,
развивающиеся уже не один год.
Тестирование безопасности веб-приложений направлено на поиск возможных путей взлома
системы, оценку защищенности веб-приложений или сайта и доступа к конфиденциальным
данным. Базируясь на принципах конфиденциальности, доступности и целостности,
тестирование безопасности способствует обеспечению сохранности данных, учетных записей,
доступов и подключений пользователей.
Для обеспечения безопасности веб-приложений создано международное некоммерческое
сообщество OWASP (Open Web Application Security Project). Сообщество OWASP включает в
себя корпорации, образовательные организации и частных лиц со всего мира. Сообщество
работает над созданием статей, учебных пособий, документации, инструментов и технологий,
находящихся в свободном доступе. Также сообществом OWASP создан список из 10-и самых
опасных векторов атак на Web-приложения
(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).
1. Методы тестирования
Существуют 3 метода тестирования безопасности веб-приложений: BlackBox, WhiteBox и
GreyBox:
BlackBox — «черный ящик». Специалист располагает только общедоступной информацией о
цели исследования, её сети и параметрах. Данный вариант максимально приближен к
реальной ситуации. В качестве исходных данных для тестирования исполнителю сообщается
только адрес сайта, а всю остальную информацию, такую как используемые компанией IPадреса, сайты и др., специалисту придётся выяснять самому;
WhiteBox – полная противоположность BlackBox. В данном случае, специалисту
предоставляется максимум необходимой для него информации, вплоть до административного
доступа на любые сервера. Данный способ позволяет провести наиболее полное тестирование
безопасности веб-приложений. При WhiteBox специалисту не придётся тратить время на сбор
информации, составления карты сети, и другие действия перед началом тестирования, а так же
сократит время самого тестирования, т.к. часть проверок просто не придется делать. Плюс
данного метода в более полном и комплексном подходе к тестированию. Минус в том, что это
менее приближено к ситуации реальной атаки злоумышленника;
GrayBox – это средний вариант между WhiteBox и BlackBox, когда специалист действует по
варианту BlackBox и периодически запрашивает информацию о тестируемом веб-приложении,
для того чтобы сократить время исследования или более эффективно приложить свои усилия.
Такой вариант самый популярный, так как позволяет провести тестирование без траты
лишнего времени на сбор информации, и больше времени уделить поиску уязвимостей, при
этом данный вариант остается достаточно близким к реальной ситуации действия
злоумышленника.
Учитывая, что специалисты по тестированию безопасности веб-приложений должны смотреть
на веб-приложения глазами потенциального взломщика, понимать суть атак и видеть
проблемные места, рассмотрим метод тестирования BlackBox.
2. Методика тестирования
Во время тестирования безопасности веб-приложения и поиска уязвимостей в нём очень
важно придерживаться определенной методологии. Чем крупнее веб-приложение, тем важнее
систематизированный подход.
Как правило, тестированию подлежит следующее:
Контроль доступа – определяет проблемы, связанные с несанкционированным доступом
пользователей к информации и функциям в зависимости от предоставленной роли.
Тестирование конфигурации ролевой модели.
Аутентификация – позволяет удостовериться в отсутствии возможности обойти процедуру
регистрации и авторизации; убедиться в корректности управления пользовательскими
данными, исключить возможность получения информации о зарегистрированных
пользователях и их учетных данных.
Валидация входных значений – используется для проверки алгоритмов обработки данных,
включая некорректные значения, прежде, чем на них будет ссылаться приложение.
Криптография – обнаруживает проблемы, связанные с шифрованием, дешифрованием,
подписью, верификацией подлинности, в том числе включает уровень сетевых протоколов,
работу с временными файлами и cookies.
Механизмы обработки ошибок – включает проверку системных ошибок приложения на
отсутствие факта раскрытия информации о внутренних механизмах безопасности (например,
посредством демонстрации исключений, программного кода).
Конфигурация сервера – ищет в многопоточных процессах ошибки, связанные с
доступностью значений переменных для совместного использования другими приложениями
и запросами.
Интеграция со сторонними сервисами – позволяет убедиться в невозможности манипуляции
данными, передаваемыми между приложением и сторонними компонентами, например,
платежными системами или соцсетями.
Проверка устойчивости к Dos/DDos атакам – проверяет способность приложения
обрабатывать незапланированно высокие нагрузки и большие объемы данных, которые могут
быть направлены на выведение приложения из строя.
В нижеприведенной методике весь процесс тестирования разбит на несколько блоков, а
именно:
1. сбор информации о веб-приложении;
2. тестирование безопасности веб-приложения в «ручном» режиме;
3. Автоматизированное тестирование безопасности веб-приложения;
Рассмотрим подробнее каждый из блоков.
2.1. Сбор информации о веб-приложении
Для начала тестирования необходимо собрать как можно больше информации о вебприложении, в том числе найти включенные службы, скрытые папки, возможные логины,
выявить уязвимости установленного программного обеспечения.
Сбор информации включает в себя:
- сканирование портов;
- анализ видимого контента;
- поиск скрытого контента;
- поиск параметров отладки и разработки;
- определение точек ввода данных;
- определение используемых технологий;
- поиск возможных векторов атаки.
Сбор информации делится на активный и пассивный.
Активный сбор информации подразумевает прямое взаимодействие с веб-приложением (вебсервером).
В результате сканирования портов можно определить открытые порты, а также тип и версии
установленных программных продуктов. Для сканирования портов можно воспользоваться
специализированным программным обеспечением Nmap. В практических занятиях будет
рассмотрен процесс работы с указанным ПО.
Анализ видимого контента позволит определить места ввода данных, а указанная в вебприложении информация (почтовые ящики, имена сотрудников) – возможные данные для
аутентификации.
При изучении исходного кода веб-приложения можно встретить забытые комментарии,
обнаружить ссылки и скрипты.
Поиск режима отладки, параметров разработчика, определения версий включенных сервисов
на ресурсе могут указать на имеющиеся уязвимости.
Пассивный сбор информации подразумевает поиск информации о веб-приложении с
помощью всевозможных сторонних сервисов/ресурсов. В указанных вакансиях компании,
аккаунтах сотрудников можно узнать используемые технологии, тип и версии ПО и СУБД и т.д.
2.2. Тестирование безопасности веб-приложения в «ручном» режиме
Тестирование веб-приложения в ручном режиме включается проверку аутентификации,
управления сессиями и разграничения прав пользователей.
Необходимо проверить, что все страницы веб-приложения открываются через HTTPS (SSL).
В случае если какая-либо функциональность веб-приложения не работает, в сообщении об
ошибке не должна быть отображена информация о сервере или базе данных – должно
отображаться соответствующее сообщение об ошибке.
Необходимо проверить, что важная информация (пароль, номер кредитной карты и т.п.)
отображается в зашифрованном виде.
Проверка аутентификации включает в себя:
- Определение правил стойкости пароля
- Тестирование подбора логина
- Тестирование подбора пароля
- Тестирование восстановления аккаунта
- Тестирование функции «Запомнить меня»
- Тестирование функции идентификации пользователя
- Проверка распределения полномочий
- Проверка уникальности логина
При проверке правила создания пароля (длина, разрешённые символы) можно определить
стойкость пароля для аутентификации на ресурсе (стойкость пароля – это мера оценки
времени, которое необходимо затратить на угадывание пароля или его подбор каким-либо
методом). В открытых ресурсах
(например https://2ip.ru/passcheck/, https://password.kaspersky.com/ru/) можно определить
стойкость пароля.
Также необходимо проверить, что правила создания паролей внедрены на всех страницах
аутентификации (регистрация, страница "забыли пароль", смена пароля).
Проверка правила создания логина поможет выявить уязвимость XSS (в случае реализации
правил на стороне клиента, их можно легко обойти, отредактировав код ресурса в браузере).
При тестировании подбора логина и пароля необходимо обратить внимание на отсутствие
секретной информации в сообщениях об ошибках. Необходимо проверить защиту ресурса от
брутфорс-атак (брутфорс-атака – (с англ. brute force) метод подбора пароля, путем
поочередного перебора возможных комбинаций) – должно быть ограничено количество
возможных попыток ввода пароля.
При тестировании функции “Запомнить меня” необходимо обратить внимание на ее срок
действия.
При тестировании функции идентификации пользователя и распределения полномочий
обратите внимание на возможность подмены учетных данных (начало действия под одним
логином, а окончание – с его подменой).
Проверка управления сессиями включает в себя:
- Проверка безопасности передачи токенов
- Проверка отображения токенов в логах
- Проверка многократного использования токенов
- Проверка завершения сеанса
- Проверка фиксации сессии
- Тестирование уязвимости CSRF
Для идентификации сессии клиента используется токен – идентификатор записи о данных
пользователя и его правах, передаваемый на компьютер пользователя (часто просто целым
числом или строкой). Токен может храниться в cookie файле, полученным с ресурса.
При проверке токенов сеcсии необходимо обратить внимание на безопасность их передачи,
отображения в логах, возможность их перехвата и многократность использования.
При проверке завершения сеанса необходимо убедиться, что если пользователь вышел из
системы или сессия завершена, он не может пользоваться ресурсом.
При проверке фиксации сессии необходимо убедится в отсутствии доступа к закрытым и
открытым страницам сайта напрямую без аутентификации.
Проверка контроля доступа включает в себя проверку разграничения уровня доступа для
различных пользователей. К примеру, пользователь не должен получить доступ к ресурсу с
правами администратора.
Также необходимо проверить, что если пароль изменен, пользователь не может зайти под
старым.
2.3. Автоматизированное тестирование безопасности веб-приложения
Автоматизированное тестирование безопасности веб-приложений предназначено для
обнаружения различных видов уязвимости с использованием специализированного
программного обеспечения.
В настоящее время наиболее распространенными видами уязвимости в безопасности
программного обеспечения являются:
- XSS (Cross-Site Scripting) – это вид уязвимости программного обеспечения (Web
приложений), при которой, на генерированной сервером странице, выполняются вредоносные
скрипты, с целью атаки клиента. Более подробно с данным видом уязвимости можно
ознакомится на странице сообщества
OWASP https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#XSS_Locator
- XSRF / CSRF (Request Forgery) – это вид уязвимости, позволяющий использовать недостатки
HTTP протокола. При этом злоумышленники работают по следующей схеме: ссылка на
вредоносный сайт устанавливается на странице, пользующейся доверием у пользователя, и
при переходе по вредоносной ссылке выполняется скрипт, сохраняющий личные данные
пользователя (пароли, платежные данные и т.д.), либо отправляющий СПАМ сообщения от
лица пользователя, либо изменяет доступ к учетной записи пользователя, для получения
полного контроля над ней. Более подробно с данным видом уязвимости можно ознакомится
на странице сообщества OWASP https://www.owasp.org/index.php/CrossSite_Request_Forgery_(CSRF).
- Code injections (SQL, PHP, ASP и т.д.) – это вид уязвимости, при котором становится
возможно осуществить запуск исполняемого кода, с целью получения доступа к системным
ресурсам, несанкционированного доступа к данным либо выведения системы из строя. Более
подробно с данным видом уязвимости можно ознакомится на странице сообщества
OWASP https://www.owasp.org/index.php/Top_10_2017-A1-Injection.
- ServerSide Includes (SSI) Injection – это вид уязвимости, использующий вставку серверных
команд в HTML код или запуск их напрямую с сервера. Более подробно с данным видом
уязвимости можно ознакомится на странице сообщества
OWASP https://www.owasp.org/index.php/Category:Injection.
- Authorization Bypass – это вид уязвимости, при котором возможно получить
несанкционированный доступ к учетной записи или документам другого пользователя
Разработано множество инструментов для автоматизированного тестирования безопасности
веб-приложений. В лекции будет рассмотрен OWASP Zed Attack Proxy и описан механизм
работы с ним.
OWASP Zed Attack Proxy – это простой в использовании интегрированный инструмент для
тестирования на проникновение, а также для поиска уязвимостей в веб-приложениях. Этот
инструмент разработан сообществом OWASP
(https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project);
3. Сценарий тестирования
Тестирование безопасности нацелено на поиск недостатков и пробелов с точки зрения
безопасности веб-приложения.
Ниже приведен сценарий проведения тестирования безопасности веб-приложения:
1. Необходимо проверить, что все страницы веб-приложения открываются через HTTPS (SSL).
2. Необходимо проверить, что важная информация (пароль, номер кредитной карты и т.п.)
отображается в зашифрованном виде.
3. Необходимо проверить, что правила создания паролей внедрены на всех страницах
авторизации (регистрация, страница "забыли пароль", смена пароля).
4. Необходимо проверить, что если пароль изменен, пользователь не может зайти под старым.
5. Необходимо проверить, что сообщения об ошибках не содержат никакой секретной
информации.
6. Необходимо проверить, что если пользователь вышел из системы или сессия завершена, он
не может пользоваться веб-приложением.
7. Необходимо проверить, что отсутствует доступ к закрытым и открытым страницам сайта
напрямую без авторизации.
8. Необходимо проверить, что опция "Просмотр исходного кода" отключена и не видна
пользователю.
9. Необходимо проверить, что учетная запись пользователя блокируется, если он несколько
раз ввел пароль неверно.
10. Необходимо проверить, что пароль не хранится в открытом виде в cookie файле.
11. Необходимо проверить, что если какая-либо функциональность не работает, система не
отображает информацию о приложении, сервере или базе данных. Вместо этого отображается
соответствующее сообщение об ошибке.
12. Необходимо проверить права пользователей и их роли. К примеру, пользователь не имеет
доступа к странице администратора веб-приложения.
13. Необходимо проверить, что важные операции пишутся в логи, и информацию можно
отследить.
14. Необходимо проверить, что значения сессий отображаются в адресной строке в
зашифрованном виде.
15. Необходимо проверить, что cookie файлы хранятся в зашифрованном виде.
16. Необходимо проверить, что веб-приложение устойчиво к брутфорс-атакам.
17. Необходимо провести автоматизированное тестирование веб-приложения.
4. Инструменты тестирования
4.1. Программное обеспечение Nmap
Nmap («Network Mapper») – это утилита с открытым исходным кодом для исследования сети и
проверки безопасности веб-приложений.
Инсталляционный пакет доступен на сайте https://nmap.org/download.html или здесь.
Рассмотрим процесс установки ПО Nmap.
1. Для установки ПО Nmap необходимо запустить инсталляционный пакет:
2. В открывшемся окне нажать «I Agree»
3. Нажимаем в открывшемся окне «Next»
4. В открывшемся окне нажимаем «Install»
5. В открывшемся окне нажимаем «I Agree»
6. В открывшемся окне нажимаем «Install»
7. В следующем окне нажимаем «Next»
8. Далее нажимаем «Finish»
9. Далее нажимаем «Next»
10. Далее нажимаем «Next»
11. Далее нажимаем «Finish»
Рассмотрим процесс работы ПО Nmap.
1. Запускаем ПО Nmap. Запуск программы осуществляется в оболочке "Zenmap".
2. В открывшемся окне заполняем поля «Цель» и «Профиль» и нажимаем кнопку сканирование
3. После окончания сканирования во вкладках «Вывод Nmap», «Порты / Узлы», «Топология»,
«Детали узла» и «Сканирование» ПО Nmap появляются отчёты по проведенному
сканированию
4. Для сохранения отчета о сканировании выбираем форму сохранения отчета в меню
«Отчет»
5. В открывшемся окне вводим имя и указываем месторасположение файла отчета. Далее
нажимаем кнопку «Save»
Следует отметить, что для получения полного списка открытых портов при сканировании
портов ПО Nmap нужно изучить все 65535 портов, а не ограничиваться стандартными портами
доступа.
4.2. Программное обеспечение OWASP Zed Attack Proxy (ZAP)
OWASP Zed Attack Proxy (ZAP) - это простой в использовании интегрированный инструмент для
тестирования на проникновение, а также для поиска уязвимостей в веб-приложениях.
Инсталляционный пакет доступен на сайте OWASP Zed Attack Proxy
(ZAP) https://github.com/zaproxy/zaproxy/wiki/Downloads или здесь.
Рассмотрим процесс установки ПО OWASP Zed Attack Proxy (ZAP).
1. Для установки ПО OWASP Zed Attack Proxy (ZAP). необходимо запустить
инсталляционный пакет
2. Нажимаем «ОК»
3. Нажимаем «Next»
4. Отмечаем «I accept the agreement» и нажимаем «Next»
5. Нажимаем «Next»
6. Нажимаем «Install»
7. Нажимаем «Finish»
Рассмотрим процесс работы ПО OWASP Zed Attack Proxy (ZAP).
1.
2.
a.
b.
c.
Запускаем ПО OWASP Zed Attack Proxy (ZAP)
В открывшемся окне выбираем один из вариантов сохранения сессии работы
С именем, основанным на текущем времени
С выбором специального имени и расположением
Без сохранения
И нажимаем кнопку «Запуск»
3. В открывшемся окне вводим имя сохраняемой сессии и нажимаем кнопку «Save»
4. В поле «URL-адрес для атаки» вводим адрес веб-приложения и нажимаем кнопку
«Атака»
5. После окончания сканирования во вкладке «Оповещения» будут указаны выявленные
уязвимости и краткое описание каждой из них
6. Для сохранения отчета о сканировании выбираем форму сохранения отчета в меню «Отчет»
7. В открывшемся окне вводим имя отчета, выбираем месторасположение и нажимаем
кнопку "Save"
8. В открывшемся окне браузера отображается сохраненный отчет
5. Тесты
Список использованной литературы и ресурсов
1.
2.
3.
4.
5.
6.
7.
https://www.tux.in.ua
http://qawebmart.ru
http://www.protesting.ru
https://defcon.ru
https://nmap.org
https://www.owasp.org
https://github.com/zaproxy/zaproxy/wiki/Downloads
Курс UT-008. Автоматизация тестирования с
использованием AutomatedQA TestComplete 10
1. Что такое TestComplete
TestComplete - это автоматизированное средство тестирования, позволяющее создавать тесты
для Windows приложений, web серверов и web страниц.
Автоматизированное тестирование - это автоматическое выполнение тестирования ПО
специальной программой при малой доле вмешательства человека или вовсе без него.
Автоматическое выполнение тестирования гарантирует выполнение всех тестовых действий
без исключения. Оно освобождает тестировщика от необходимости повторять одни и те же
монотонные действия снова и снова. Одним из таких инструментов является TestComplete.
TestComplete используется для автоматизации различных типов тестирования программного
обеспечения для .NET, Java, Visual C++, Visual Basic, Delphi, C++Builder, web страниц и других
приложений. Инструмент предназначен для разработчиков программного обеспечения и
отделов тестирования софта для того, чтобы уменьшить временные затраты, необходимые на
ручное тестирование.
В TestComplete существует специальный механизм, облегчающий создание скриптов для
тестирования приложений. Суть механизма заключается в следующем: тестировщик выполняет
необходимые действия, которые автоматически записываются в файл. Данный файл, который
доступен для просмотра и редактирования, и при запуске, повторит все те операции, которые
были предварительно выполнены. Важным обстоятельством является тот факт, что записанные
тесты могут быть изменены позднее.
2. Структура автотестов
Папка autotests содержит следующие подкаталоги:
ActionBuilder – содержит приложение, с помощью которого составляются xml с тестами.
apps – содержит приложения, используемые во время выполнения автотестов.
git-tester – содержит ключи для работы с git для пользователя tester на виртуальных машинах,
на которых прогоняются автотесты.
LoadTests – содержит нагрузочные тесты.
TC_Runner – содержит приложение для запуска автотестов (сейчас неактуально, его роль
выполняет jenkins)
test-selenium – проект для поддержки автотестов веб-клиента с использованием библиотеки
selenium.
test-selenium-gz – проект автотестов Госзаказ.
TestFramework – содержит папки с автотестами по направлениям и папку Script с модулями
для поддержки работы автотестов.
Для разработки модулей используется язык JScript.
На примере проекта Финансы разберем структуру хранения автотестов (папка
d:\autotests\TestFramework\TestAzkFinance )
Тесты хранятся в папке с указанием промежутка версий проекта, для которых используются
тесты (например, 2.51.0.0 - 2.51.0.999). Далее по подкаталогам:
Actions содержит xml-файлы с тестовыми сценариями, которые разделены по следующим
типам (подкаталогам) :




dictionary - тесты справочников;
documents - тесты документов;
reports - тесты отчетов;
setup - тесты предзаполнения.
Тесты справочников и документов находятся каждый в своей отдельной папке, которая
называется по имени объекта приложения.
Templates содержит шаблоны - описатели форм справочников и документов. Шаблоны
называются по имени объекта приложения.
reports_etalons содержит эталонные файлы для тестов отчетов.
files содержит файлы с данными для тестов. Данные вынесены в отдельные файлы, а в самих
тестах используются ссылки на эти данные. Такой способ хранения выбран по причине
неоднократного использования данных, чтобы в случае изменения данных можно было
исправлять только в одном месте. Данные хранятся в виде:
<Ссылка>=<Значение>
Пример ввода данных без использования ссылок::
Код источника=102345
Дата={ return getDate("%d.%m.%Y"); }
Также в папке files хранятся xml, копируемые в сборку при установке проекта, сертификаты
для подписи.
Важные файлы
files\links.txt содержит ссылки на данные, вида:
<Ссылка>=<Путь до файла с данными>
пример строки с ссылкой на данные:
<param id="0"><![CDATA[{ return getData("Справочники.Настройка проводок", "Класс
проводки"); }]]></param>
В этой строке мы получаем значения "Класс проводки" из "Справочники.Настройка проводок".
Адрес нахождения файла определяется путем парсинга файла "TestAzkFinance\tests\2.51.0.0 2.51.0.999\files\links.txt" и поиска в нем записи "Справочники.Настройка
проводок=tests\dictionary\AccountEngineForm\data.txt". Далее парсится файл
tests\dictionary\AccountEngineForm\data.txt и в нем ищется запись "Класс проводки".
files\common\misc.txt содержит данные, используемые во многих тестах, например,
Наименование бюджета.
files\common\path.txt содержит пути до справочников и документов.
Пример:
Справочники.Статусы документов=Администрирование системы|Документы|Статусы
документов
Если пути для delphi и web-клиентов отличаются, то перед названием добавляем префиксы
desktop или web:
desktop.Справочники.Статусы документов=Справочники|Документооборот|Статусы
документов
files\options.xml содержит в xml-формате данные для установки проекта – пути до папок со
сборкой, отчетами, томкатом, файла лицензии, предзаполненной базы, проливаемые при
установке xml и т.д. Есть возможность настройки под различные локации, т.е. для каждого
филиала задать свои пути.
tests\config.xml нужен для того, чтобы указать настройки, отличающиеся от стандартных, для
выполнения тестов на виртуальных машинах, например, браузер, на котором будут
выполняться тесты, версии отчетов и сборки, тип базы данных и т.д.
TestFramework\Common\controls.xml описывает типы контролов (поле, таблица, тулбар и т.д.)
и действия (ввод текста, клик, проверка текста и т.д.), которые можно над ними выполнять, а
так же необходимые параметры.
Templates\applications.xml содержит записи в xml-формате обо всех справочниках и
документах, для которых есть шаблоны. В файл записывается id объекта, которое соответствует
названию шаблона и названию справочника:
<object id="bft.budget.estimate" desc="Бланки расходов"/>
3. Структура папки data
Во время выполнения установки проекта создается папка data, в которую копируются данные
для установки проекта, и происходит его установка. Папка data содержит следующие
подкаталоги:
build – папка, в которую при установке копируются данные из сборки – архивы клиента, вебклиента, сервера, отчетов, томката и т.д.
db – папка, в которую при установке копируется бэкап базы или заархивированная база, в эту
папку распаковывается и в ней хранится база firebird.
deploy – папка, в которую устанавливается сервер, клиент и web-клиент.
reports – папка, в которую во время тестов отчетов сохраняются файлы отчетов.
4. Тестовые сценарии
Тестовые сценарии, которые хранятся в папке Actions записаны в xml-формате и состоят из
действий, записанных в стандартном виде:
<action appId="dicts" actionId="keys" controlId="CAPTION" objectId="bft.budget.kvr">
<param id="0"><![CDATA[{ return getData("Справочники.Классификатор вида расходов",
"Краткое наименование"); }]]></param>
</action>
appId – id типа объекта (dicts, docs, client и т.д.)
actionId – действие, которое выполняется над объектом – контролом (полем, тулбаром,
таблицей и т.д.)
controlId – id контрола, над которым выполняется действие.
objectId – id объекта (справочника, документа), на котором расположен контрол.
У действия action могут быть параметры param. Параметр, который передается как ссылка на
данные из файла, имеет следующий вид:
{ return getData("<Ссылка на данные>", "<Ссылка на значение>"); }
где <Ссылка на данные> - это ссылка на файл с данными из файла links.txt, а <Ссылка на
значение> - это ссылка на данные из файла с данными.
5. Работа с ActionBuilder
Xml с тестами составляются с помощью ActionBuilder.
1.
2.
3.
4.
5.
Запускаем ActionBuilder\bin\ActionBuilder.exe.
Переходим в меню настроек Settings|Options.
В поле Current version указываем папку с версией тестов.
В поле Data path указываем путь до тестов.
Сохраняем настройки.
6. На форме ActionBuilder в поле Test description пишем название теста.
7. В выпадающем меню выбираем тип объекта, который нам нужен (Клиент,
Справочники, Документы, Настройки клиента)
8. В списке ниже выбираем нужный объект, разворачиваем его дерево и видим список
контролов объекта. Разворачивая каждый контрол, можно увидеть список действий для
него. Два поля внизу формы группы Data используются для заполнения параметров
действий. После выбора действия над полями для параметров появляются подсказки,
какими данными их нужно заполнить.
9. После выбора контрола, действия для него и заполнения параметров нужно нажать
кнопку Add. В правой части формы отобразится сформированное действие. С
помощью кнопки Del действие можно удалить.
10. Таким способом и добавляем новые действия. После того как создадим все нужные
действия, сохраняем сформированный xml-файл.
6. Шаблоны
Шаблоны справочников и документов, расположенные в папке Templates, являются
описателями форм, используемых в автотестах, они в xml-формате содержат контролы форм,
например:
<control id="refGrantInvestmentType" type="referenceField" desc="Референс &quot;Тип&quot;">
<web><![CDATA[AppObject("bft.fin.aubuClassifiersRules",
"edit").Field("refGrantInvestmentType")]]></web>
<path><![CDATA[VCLObject("frmAuBuClassifiersRulesDocument").VCLObject("cmbGrantInvest
mentType")]]></path>
<params>
<param id="0">
<value><![CDATA[{ return getData("Документ.Тест", "Тип"); }]]></value>
<value><![CDATA[{ return "Тип=" + getData("Документ.Тест", "Тип"); }]]></value>
</param>
<param id="1">
<value><![CDATA[]]></value>
</param>
</params>
</control>
id – id контрола.
type – тип контрола, например, текстовое поле (textField), комбобокс, таблица и т.д.
desc – описание контрола.
В тэгах <web> хранится путь до контрола для web-клиента. В тэгах <path> хранится путь до
контрола для delphi-клиента. Для контрола могут быть указаны параметры <params>, это не
обязательно, они нужны для удобства, чтобы указанные строки подтягивались в поля с
параметрами ActionBuilder и их можно было выбрать, а не набирать вручную.
Шаблоны составляются путем запуска функций из скриптовых файлов TestComplete. Для
составления шаблона для delphi-клиента используется модуль core_base_fr4k. В функции,
которую нужно запустить, указываем путь для генерации файла и адрес формы для описания,
который получаем при помощи Object Spy TestComplete.
Для составления шаблонов для web-клиента используется модуль core_base_fr. В функции,
которую запускаем нужно указать путь до папки, где лежат описатели форм в веб-клиенте,
названия файлов с описаниями объекта .data и .form, наименование объекта приложения.
7. Структура проекта в TC
В Project Explorer отображается структура проекта автотестов. В Scripts видим, подключенные к
проекту модули. В папке common находятся общие для разных проектов файлы. В
паке core находятся ядерные модули, они так же общие для различных проектов. В
подпапке base расположены базовые модули, такие как модули для работы со строками,
логами, почтой, загрузкой данных из xml-файлов, инсталляторы и т.д.
Стоит обратить внимание на следующие модули:
core_base_defines – в нем описаны переменные для автотестов, общие для разных проектов:
пути до сервера, клиента и т.д., настройки для разных БД и т.д.
core_base_fr – модули для формирования шаблонов форм Web.
core_base_fr4k – модули для формирования шаблонов форм Delphi.
В подкаталоге controls расположены модули для работы с контролами delphi-клиента.
В подкаталоге player расположены модули для поиска контролов (core_player_finder) и
воспроизведения тестов (core_player) delphi-клиента.
В подкаталоге processes расположены модули для работы с различными процессами,
например, сервером приложения, томкатом, delphi-клиентом, cmd-файлами, WinRar и т.д.
В папке project находятся проектные модули (для каждого проекта свои). В
модуле fin_defines описаны проектные переменные, например, различные пути, используемые
для конкретного проекта. Модуль fin_installer переопределяет некоторые методы основного
инсталлера, таким образом, позволяя установить данные для проекта, которые используются
только в нем, к примеру, различные xml, проливаемые при установке.
В папке tests расположены модули с функциями, запускающие выполнение автотестов.
TestsReference – модуль с тестами справочников.
tests_setup – модуль с тестами наполнения базы.
В TestedApps видим приложения, которые используются во время выполнения автотестов:
client, web_server, app_server и т.д.
На вкладке Test Items проекта видим дерево тестов, которое включает в себя установку
проекта, проверку дерева навигации, тесты справочников и документов и т.д.
Для запуска тест-айтема Проверка билда АЦК-Финансы нужно указать следующие
параметры:
browserId –браузер, который будет использоваться при выполнении автотестов, можно
выбрать Mozilla FireFox, Internet Explorer, Chrome.
platformId – платформа, на которой будут выполняться автотесты. Можно указать windows или
redhat.
clientId – тип клиента, для которого будут выполняться автотесты. Указываем Sencha-клиента.
BudgetPeriod – тип бюджета, для которого будут выполняться автотесты – однолетний или
трехлетний.
TestMode – режим выполнения тестов – полный или сокращенный прогон.
Данные параметры заполняются проектными переменными, которые можно посмотреть на
закладке Variables проекта:
Перед запуском установки проекта необходимо указать следующие параметры:
versionMax – версия сборки, не позднее которой будет установлена.
versionReportsMax – версия отчетов, не позднее которой будет установлена.
db – база данных, для которой будет происходить установка, можно выбрать FireBird, Oracle,
Postgresql.
mode – режим установки автотестов, можно выбрать create – с созданием базы с нуля, preset –
с использованием предзаполненной базы и другие режимы.
isReports – параметр показывает, нужно ли устанавливать отчеты.
На закладке Variables сьюты можно посмотреть глобальные переменные, которые
используются во время выполнения автотестов:
8. Функция для запуска автотестов
Функция для запуска автотестов справочника имеет стандартный вид:
//Проверка справочника Корректирующие коэффициенты (выравнивающие)
function test_plIndCoeffLeveling(CheckList) {
try {
if ((ProjectSuite.Variables.TestMode == CheckList)||(CheckList == "MinCheck")) {
if (!ProjectSuite.Variables.isTestsAllowed) throw new Error(sError.tests_are_not_allowed);
var path = dataReader.pathTestData + folderActions + "dicts\\bft.plan.plIndCoeffLeveling\\";
clientType = clientTypes.delphi;
client.run("root", "toor");
player.play(path + "create_delphi.xml");
player.play(path + "edit_delphi.xml");
player.play(path + "view_delphi.xml");
clientType = clientTypes.sencha;
client.run("root", "toor");
player.play(path + "create_web.xml");
player.play(path + "view_web.xml");
player.play(path + "delete_web.xml");
client.close();
clientType = clientTypes.delphi;
player.play(path + "delete_delphi.xml");
client.close();
}
else
ProjectSuite.Variables.tests.current.canStart = false;
} catch (exception) {
Log.Error(exception.message, exception.description);
}
}
Параметр функции CheckList указывается в параметрах тест-айтема, для которого будет
выбрана данная функция, может принимать значения FullCheck (полный прогон)
и MinCheck (сокращенный прогон)
Перед запуском тестов всегда проверяем, возможен ли запуск с помощью глобальной
переменной ProjectSuite.Variables.isTestsAllowed. Данная проверка нужна, чтобы не тратить
время на выполнение тестов в случае неудачной установки проекта.
В переменной path указан путь до папки с автотестами справочника.
С помощью переменной clientType указываем тип клиента (web, delphi), для которого будут
выполняться тесты.
client.run("root", "toor"); - запуск клиента с указанием логина и пароля.
client.close(); - закрытие клиента.
player.play(path + "create_delphi.xml"); - запуск теста create_delphi.xml, который расположен
в папке path.
9. Правила написания CRUD-тестов произвольного справочника
Что делать, если стоит задача написать с нуля, или актуализировать CRUD-тест справочника?
1. Найти документ в системе. Если не получается или существуют вопросы по функционалу запрашиваем консультацию у соответствующего направления Управления Тестирования.
2. Проверить наличие справочника в обоих клиентах - Web/Delphi.
3. Планирование тестов. CRUD-тесты справочников должны включать в себя следующие вещи:
a. Создание (С)
i.
переход на списочную форму справочника
ii.
создание записи справочника (сохранение записи при заполнении всех полей)
iii.
проверка наличия в списке и корректности заполненных данных в этом списке(в
гриде/дереве)
iv.
закрытие списочной формы справочника
b. Проверка введенных данных (R)
i.
переход на списочную форму справочника
ii.
открытие созданной в пункте a.ii записи
iii.
проверка всех полей (поля при создании копированием ведут себя по-разному - некоторые
должны остаться нетронутыми, некоторые должны очиститься, некоторые - изменить
значение на дефолтное)
iv.
закрытие формы справочника
v.
закрытие списочной формы справочника
c. Редактирование (U)
i.
переход на списочную форму справочника
ii.
открытие созданное в пункте a.ii записи
iii.
не просматривая имеющиеся значения полей, изменить запись справочника и
сохранить(т.е. проверять, чем заполнены поля документа здесь уже не надо).
iv.
проверка наличия в списке и корректность данных в этом списке(в гриде/дереве)
v.
закрытие списочной формы справочника
d. Удаление (D)
i.
переход на списочную форму справочника
ii.
удаление созданной в пункте a.ii записи
iii.
проверка отсутствия записи в списке.
iv.
закрытие списочной формы справочника
4. Из плана, указанного в п.3 нужно убрать те действия, которые не поддерживаются данным
справочником. По остальным пунктам пройтись вручную. Если при проверке находим
ошибку - заводим репорт в JIRA. Если ошибка критична и не позволяет проводить
дальнейшие работы, то на этом этапе работы по задаче приостанавливаются.
5. Как только блокирующие баги из п.4 будут исправлены - можно приступать к реализации.
6. Структурирование тестов(со стороны TestComplete):
a. Тесты справочников располагаются в unit TestsReference
b. Все тесты одного справочника(логическая CRUD-цепочка) должны располагаться в одной
функции, в т.ч. если написаны тесты для двух клиентов(Web + Delphi)
c. Если тесты пишутся для двух клиентов, структура функции должна быть вида:
i.
Логин в Delphi-клиент
ii.
Создание в Delphi-клиенте
iii.
Проверка в Delphi-клиенте
iv.
Редактирование в Delphi-клиенте
v.
vi.
vii.
viii.
ix.
x.
xi.
xii.
7.
a.
i.
ii.
iii.
b.
c.
d.
8.
9.
Логин в Web-клиент
Создание в Web-клиенте
Проверка в Web-клиенте. Важно! Проверять не только созданный в п.vi, но и так же
документ из п.iv
Редактирование в Web-клиенте
Удаление в Web-клиенте
Закрытие Web-клиента
Удаление в Delphi-клиенте
Закрытие Delphi-клиента
Структурирование тестов(со стороны файловой системы)
XML-описание каждого справочника должно:
Находиться в директории <tests>\templates\dicts
Содержать описание как для Web, так и для Delphi клиентов
Иметь соответствующее AppObject имя. В случае если справочник есть в двух клиентах, за
основу берется имя в Web
Примеры:
для справочника "Бюджеты" - bft.budget.budget.xml
для справочника "Виды лицензий" - dictLicType
Все тесты должны находиться в директории
<tests>\actions\dictionary\<AppObject>\. AppObject указывается по-аналогии с пунктом "а".
Примеры:
тесты для справочника "Бюджеты" находятся по пути:
<tests>\Actions\dictionary\bft.budget.budget.
тесты для справочника "Виды лицензий" находятся по пути:
<tests>\Actions\dictionary\dictLicType
Наименование тестов должно отражать их задачу.
Пример: create_delphi.xml - тест создания в Delphi-клиенте.
Если для теста необходимо наличие каких-либо данных в базе, то необходимо написать
тесты создания этих данных и в функции отметить с помощью "//TODO требуется вынести в
предзаполнение". Тогда при очередном процессе пересоздания базы, эти данные будут
перенесены в предзаполнение.
Данные для тестов необходимо обязательно заполнить в data-файлы. Местоположение поаналогии с остальными пунктами:
Примеры:
data-файлы для справочника "Бюджеты" находятся по пути:
<tests>\files\tests\bft.budget.budget\data.txt
data-файлы для справочника "Виды лицензий" находятся по пути:
<tests>\files\tests\dictLicType\data.txt
По окончании разработки тестов, необходимо сформировать информационную страницу в
confluence.
10. Разбор логов
После выполнения теста TestComplete формирует лог, он понятен и хорошо читаем. Каждое
действие из теста описано отдельной строкой, которая имеет вид:
<Название справочника>-><Контрол> “<Название контрола>”.<Действие>(<Параметры>)
Действия, во время выполнения которых произошли ошибки, выделяются красным цветом, по
логу можно увидеть, в чем заключается ошибка. При анализе ошибок полезную информацию
можно найти на закладках лога Picture, Additional Info.
11. Тесты web-клиента
Если запуск и воспроизведение тестов delphi-клиента происходит с помощью TestComplete, то
тесты web-клиента проигрываются с помощью Selenium. Для запуска тестов web-клиента
TestComplete запускает SeRunner, заполняет его поля, нажимает на кнопки и таким образом
передает параметры и запускает тесты Selenium.
12. Поиск объектов приложений, объектов данных
12.1. Объекты данных/объекты приложений
Все объекты, представленные в Web-клиенте (справочники, документы) имеют в системе
формальные описания - описания объектов данных или объектов приложений. Фактически со
стороны автотестирования они отличаются только тем, что объекты данных описаны в файлах
*.data, а объекты приложений в файлах *.form. В описании объекта данных присутствуют только
ссылки на некие поля с данными. Форма для объектов данных строится "на лету" и
представляет собой простой список полей, перечисленных в объектах данных. В описании
объекта приложения есть отсылки к разным объектам данных, однако общая форма построена
заранее. Так же объект приложения содержит секцию со скриптом, который исполняется во
время показа формы - используется для придания формам динамики.
12.2. Подгрузка ресурсов с сервера и по внутреннему URL
При показе, данные для форм запрашиваются либо с сервера, либо по внутреннему URL. Со
стороны автотестирования важно знать, что описание пути к формам, построенным на основе
готового описания и полученных по внутреннему URL будут отличаться.
12.3. Формирование описания для объектов
Как определить, при помощи чего выведена данная форма и как отличаются пути? Для ответа воспользуемся нижеприведённой схемой:
1. Поиск и формирование описания для объекта приложения:
В консоли JS в этом случае подставляем:
core.util.TestUtils.getLastOpenedDocument("bft.fin.budgObligation", "edit")
Так же возможен запрос другого вида (для вложенных форм):
https://localhost:8443/azk/controller?actionId=res&appObj=bft.fin.budgObligati
В этом случае для проверки в строку консоли подставляем:
core.util.TestUtils.getLastOpenedDocument("bft.fin.budgObligation", "edit", {o
В описателе форм для TestComplete такая строка будет выглядеть:
AppObject("bft.fin.budgObligation", "edit",
"CONSTAGE")
2. Поиск и формирование описания для объекта, полученного по внутреннему URL:
А в этом случае для проверки в строку консоли подставляем:
core.util.TestUtils.getLastOpenedDocumentByUrl("app:doc/expenseRequestLinesEdi
3. Еще один вариант визуализации
4. Полезные функции
а. Возвращает строку из которой можно выделить параметры
для core.util.TestUtils.getLastOpenedDocument...(...)
>>> Ext.WindowMgr.getActive().items.items[0].context.ns
<<< "bft_plan_moscow_mskExpenseKadmKcsrKvrYears_0_form"
б. Возвращает тоже что и core.util.TestUtils.getLastOpenedDocument...(...)
>>> Ext.WindowMgr.getActive().items.items[0].context.lastOpenedDocument
<<< Object
13. Обучающие видео к курсу
Создание автотеста создание справочника delphi
Создание автотеста просмотр, редокатирование, удаление справочника delphi
Создание data файла
web.mp4
Приложение. Необходимое ПО
Требуется установить следующте ПО:
1. Oracle (Админский)
2. PostgreSQL установливать в корень диска С:, путь должен быть без пробелов!
3. jdk-8u45
4. Git-1.7.7
5. Firefox Setup 60.9.0esr (32-bit)
6. TortoiseGit-1.7.5.0-64bit
7. TestComplete1430
8. Totalcomander
9. tightvnc-2.8.5 необходим для проведения тестов на удаленной машине. Testcomplete не
отрабатывает при не активной сессии на рабочем столе.
Перечисленное ПО можно найти по адресу "\\srv-fs-azkbuild\build\autotests\ПО для
Автотестов"
Лицензия testcomplete
В браузере открыть страничку - http://localhost:1947/_int_/config_to.html
Перейти на вкладку "Access to Remote License Managers"
В поле "Specify Search Parameters" прописать IP машины epishin-ap.
На данный момент, это - 172.21.20.248. Проставить три верхние галочки.
172.21.20.194 и 172.21.21.228 172.21.20.60 для ТС 10
Для Функционирование автотеста на машине должны быть прописаны следующие переменые
среды:
DIRECTORY = BACKUP
JAVA_HOME = C:\Java\jdk1.8.0_45\ без разницы, главное условия чтобы в пути не было
пробелов. Рекомендуемая версия 1.8.0_45
ORACLE_HOME = d:\app\a.lesovoy\product\11.2.0\client_1\ (ну или каталок куда установлен
клиент оракл)
ORACLE_URL = @172.26.5.22:1522/orcl.bft.local (адресс ора сервера, куда будут ресторится базы
для прогона)
PASSWD = oracle (Пароль для ора)
USERNAME = SYSTEM (пользователь ора)
PGLOCALEDIR = C:\Program Files\PostgreSQL\9.5\share\locale (pg локальная директори)
PGPORT = 5432
PGUSER = postgres
POSTGRE_HOME = C:\Program Files\PostgreSQL\9.5
Путь до папки .ssh должен быть на латинице
cmd переходите на диск D: и выполните команду git clone git@git:autotests
При настройки из виртулки Testcomplete должен запускатся от администратора. Свойства совместимость - Изменить параметры для всех пользователей - Выполнять эту программу от
имени администратора
Доступ до ресурсов не из домена можно организовать путем внесения этих ресурсов в Панель
управления - Учетные записи пользователей - Диспетчер учетных данных. Учетные данные
Windows добавить. Адресс без подпапок.