Преподаватель который помогает студентам и школьникам в учёбе.

Основные понятия качества и тестирования программ

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

Тема данной работы рассматривается в работах как российских, так и зарубежных ученых, таких как Бабенко Л.П., Лавришева Е.М, Борзов Ю. В., Уртанс Г. Б., Шимаров В. А., Канер С., Фолк Д., Нгуен Е.К.,Котляров В.П.,Лаврищева Е.М., Коротун Т.М.,Шимаров В. А., Фаулер М

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

1. Рассмотреть место процесса тестирования в разработке программного обеспечения

2. Обобщить знания по характеристикам качества программного обеспечения

3. Описать основные определения тестирования и отладки.

4. Рассмотреть основные виды тестирования.

5. Изучить организацию процесса тестирования.

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

7. Показать на практике создания скрипта для автоматизированного тестирования.

Структура работы. Работа выполнена на 38листах, содержит 15 рисунков, 1 листинг программ.

1. Основные понятия качества и тестирования программ

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

1.1. Качество программного обеспечения

В курсовой работе для определения качество программного обеспечения будем использовать определение, данное в стандарте ИСО 9126 [6], который трактует его как сумму характеристик, связанных с возможностью удовлетворения явно выраженных или подразумеваемых потребностей всех заинтересованных сторон.

Принято различать понятия внутреннего качества, связанного с характеристиками самого программного обеспечения, без учета его поведения.[16] И понятие внешнее качество, которое характеризует программное обеспечение с точки зрения его поведения; при использовании в различных контекстах - качество, которое ощущается пользователями в конкретных программных сценариев работы. Для всех этих аспектов качества введены метрики, с помощью которых возможно оценить каждый атрибут. Кроме того, для создания программного обеспечения хорошего качества важно соблюдать процессы его построения. Взаимосвязь между аспектами качества принятой в ISO 9126, показано на рисунке 1.

Стандарт ISO 9126 предлагает использовать для описания внутреннего и внешнего качества программного обеспечения многоуровневую модель. На верхнем уровне выделены 6 основных характеристик качества программного обеспечения. Каждая характеристика описывается несколькими из его атрибутов.[7] Каждый атрибут определяется набором показателей, которые позволяют достоверно его оценивать. Набор характеристик и атрибутов качества в соответствии с ISO 9126, показан на рисунке 2.

Рисунок 1 – Качество программного обеспечения по ISO 9126[6]

Ниже приведены определения характеристик и атрибутов ISO 9126: 2001:[16]

Функциональность (functionality) – основная характеристика качества программного обеспечения, которая отвечает за решение в определенных условиях задач, нужных пользователям.
Надежность (reliability)- основная характеристика качества программного обеспечения, которая отвечает за поддержку определенного уровня работоспособности в заданных условиях.
Удобство использования (usability) или практичность. - характеристика качества программного обеспечения, которая отвечает за удобное в обучении и использовании.
Производительность (efficiency) или эффективность. - основная характеристика качества программного обеспечения, которая отвечает за обеспечение необходимого уровня работоспособности по отношению к выделяемым для этого ресурсам. [7]
Удобство сопровождения (maintainability)..
Переносимость (portability). - характеристика качества программного обеспечения, которая отвечает за сохранение работоспособности при переносе из одного окружения в другое, включая организационные, аппаратные и программные аспекты окружения. [7]

Рисунок 2 - Характеристики и атрибуты качества ПО по ISO 9126[6]

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

1.2. Методы контроля качества программного обеспечения

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

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

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

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

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

Рисунок 3 - Тестирование, верификация и валидация[13]

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

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

1.3. Финишные этапы разработки программных систем

Модель жизненного цикла программного продукта – структура, которая определяет последовательность выполнения и взаимосвязи процессов, действий и задач в течении жизненного цикла. [2]

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

Классическая модель процесса разработки разрабатываемого программного обеспечения является водопадная модель (Waterflow), в котором процесс разработки разрабатываемого программного обеспечения представляет чередования фаз (рисунок 4.): [3, с.22]

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

К финишным этапам разработки относят[13]:

Фазу сопровождения;
Фазу развития.

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

Рисунок 4 – Водопадная модель разработки программного обеспечения[12]

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

1.4. Терминология тестирования

Если рассматривать программу как аналог формулы в математике[10, с.45], то ее можно записать как

f = f1* f2* f3*... * fn

f1,f2,... fn – операторы языка программирования.

Существует два метода обоснования истинности формул:

Формальный подход или доказательство осуществляется путем перехода от одних формул к другим по строгим правилам, где процедура перехода от формулы к формуле сводится к последовательности текстовых подстановок: [14]

A**3 = A*A*A

A*A*A = A -> R, A*R -> R, A*R -> R

Преимущество: обращение к конечному множеству символов.

Интерпретационный подход истинность интерпретируемых формул проверяется на конечных множествах возможных значений. Интерпретационный подход используется при экспериментальной проверке соответствия программы своей спецификации. Применение интерпретационного подхода в форме экспериментов над исполняемой программой составляет суть отладки и тестирования. [7]

Отладка (debug) – процесс локализации и поиска, а также исправления ошибок в программе

Тестирование - процесс выявления расхождений фактов с требованиями (ошибок). [13]

Тестирование можно разделить на статическое и динамическое:

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

Выводы по главе 1

1. Рассмотрены основные процессы разработки программного обеспечения.

2. Определенно место тестирования в процессе проверки качества программного обеспечения.

3. Рассмотрены основные характеристики качества программного обеспечения, которые должны быть протестированы:

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

2. Виды тестирования, тестирование надежности, организация процесса тестирования

2.1. Виды тестирования

1. Тестирование “белого ящика”, “черного ящика”, “серого ящика”.

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

доступен ли только интерфейс программы или её исходный код. Это классификация тестов по знанию системы тестировщиком и она бывает трех видов: тестирование черного ящика, тестирование белого ящика и тестирование серого ящика. [11]

Наиболее распространённым является тестирование черного ящика. Два других встречаются крайне редко.

Тестирование Черного Ящика – это тестирование только той части программы, которая доступна через её интерфейс. В этом случае считается проверка кода программы не выполняется. К этим тестам можно отнести проверку граничных значений вводимой и выводимой информации, проверку согласно готовым тест кейсам и use-кейсам, проверку перехода программы из одного состояния в другое. Так же сюда можно отнести не функциональные тесты, такие как проверка удобства использования, производительности, технических требований к компьютеру. [10]

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

Выделяют четыре техники проведения тестирования черного ящика[9]:

- проверка классов эквивалентности;

- проверка граничных значений;

- проверка согласно таблице вариантов использования;

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

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

Рисунок 5 – Виды тестирования

Тестирование Белого Ящика – это тестирование работы программы исходя из знания её программного кода. Здесь важно проверить все условия переходов внутри функций, полноту их покрытия, правильность вычисления формул. При таком тестировании проверка выполняется не запуская программу. Читая программный код тестируется правильность реализации циклов операций, переходов внутри программы. К этой группе тестов от-носится и проверка результатов технических исследований программы, сопоставление реализованных программистами алгоритмов к тем, которые планировались дизайнерами системы.[10]

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

Тестирование Серого Ящика – это тестирование включает в себя оба предыдущих.

2 По степени автоматизации тестов[9]

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

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

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

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

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

3 По виду позитивности[10]

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

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

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

4 По времени проведения[10]

Процесс разработки программы делится на несколько фаз. На каждой фазе требуется проверять разные аспекты работы программы и покрывать тестированием разную функциональность. На одном этапе можно провести, что программа вообще запускается, а на другом может понадобиться полная проверка всех компонентов системы. Поэтому по времени проведения выделяют следующие виды тестов: Альфа, Бета, Дымное (Smoke), Регрессионное, Приемочное (User Acceptance Testing, UAT).

Альфа тестирование[7] – это тестирование продукта штатными сотрудниками компании, которая разрабатывает продукт. Альфа тестирование проводится для того, чтобы выявить и исправить ошибки в полностью собранной финальной версии продукта перед тем как отдавать её заказчику

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

Дымное тестирование – это поверхностный осмотр программы на то что она вообще способна работать и выполнять основные функции. Это тестирование проводится для того, чтобы пропустить какой-то модуль или всю программу на более точные этапы проверки.[10]

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

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

5 По степени изолированности компонентов[11]

Можно проверять какую-то одну компоненту из приложения, либо проверить сразу несколько компонент или же всё приложение в целом. В связи с этим виды тестирования разделяют по степени изолированности компонентов.

Модульным тестированием (Unit testing) – называется проверка минимально функциональной автономной единицы программы. Чаще всего это проверка функций и процедур внутри кода программы. Такое тестирование чаще всего автоматизируют. Отчеты об ошибках при таком тестировании создаются редко, потому что всё исправляется “на лету”. Для проверки функций кода пишется программа, которая подаёт на вход предопределенные параметры и сравнивает полученный результат на выходе функции с ожидаемым[10].

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

Системное тестирование – это тестирование полностью собранной системы в том виде, в котором она будет поставляться заказчику[18].

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

6. Основы тестирования web-приложений.[9]

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

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

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

Чаще всего сервер не имеет графического интерфейса в целях экономии ресурсов, требуемых для его работы. Это будет некоторое консольное приложение, поэтому обязательным будет знание командной строки той операционной системы, на которой оно работает. Одновременно с основной функциональностью web-приложений важную роль играет их безопасность. В последнее время для проверки защищенности системы прибегают к помощи сторонних специалистов, которых называют этическими хакерами (ethic hackers) или пентестерами (penetration tester - тестиров-щик возможности проникновения). По сути – это специалисты, которые пытаются взломать систему, но только не пользуются результатами взлома, а сообщают о них работодателю. Их тоже можно отнести к тестировщикам.[8]

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

2.2. Организация тестирования

Организация тестирования программного обеспечения регулируется следующими стандартами:

IEEE 829-1998. Описывает виды документов, служащих для подготовки тестов.[6]
IEEE 1008-1987. Описывает организацию модульного тестирования.
ISO/IEC 12119:1994. Описывает требования к процедурам тестирования программных систем.

Тестирование – это[2]:

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

Тестирование и его процесс разделяют на три этапа (рис. 6): [13]

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

Рисунок 6 - Схема процесса тестирования[14]

Основная задача тестирования: определить такой набор данных, который был бы достаточно объемен и позволил бы сказать с большой степенью достоверность в правильности ПО вообще и в соответствии с требованиями.[16]

Основные проблемы тестирования[17]:

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

• Требование к тестам - программа на любом тесте должна останавливаться, а не зацикливаться.

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

Выводы по главе 2

1. Приводится классификация видов тестирования. Рассмотрена следующая классификация

Тестирование “белого ящика”, “черного ящика”, “серого ящика”.
По степени автоматизации тестов;
По виду позитивности;
По времени проведения;
По степени изолированности компонентов.

2. Рассмотрено тестирования Web-приложений.

3. Описан процесс организации тестирования.

4. Выделены основные проблемы которые могут возникнуть в процессе тестирования.

3. Практические вопросы отладки и автоматизированного тестирования

3.1. Отладка программы

Для каждого языка программирования есть своя среда разработки. Но все современные среды разработки, такие как Visual Studio, Delphi Embasador и т.д., имеют похожий аппарат отладки программного обеспечения, рассмотрим его.

У Delphi есть мощное средство поиска и устранения ошибок в программе — отладчик. Отладчик позволяет выполнять трассировку программы, наблюдать значения переменных, контролировать выводимые программой данные. [11]

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

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

Delphi обеспечивает два режима трассировки[19] (рисунок 7):

без захода в процедуру (Step over);
с заходом в процедуру (Trace into).

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

Рисунок 7 – Отладка примера

Рисунок 8 – Точка останова

Во время отладки, бывает полезно знать, чему равно значение той или иной переменной. Отладчик позволяет наблюдать значения переменных программы. [19]

Рисунок 9 – Просмотр значения переменных

Рисунок 10 – Watch List с искомыми переменными

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

3.2. Автоматизированное тестирование

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

В курсовой работе рассмотрим процесс создания одного скрипта для автоматизированного тестирования формы регистрации web-сайта. Средой автоматизированного тестирования выберем Selenium IDE[5]

Selenium IDE (Integrated Development Environment, интегрированная среда разработки) — это инструмент, используемый для разработки тестовых сценариев. Он представляет собой простое в использовании дополнение к браузеру Firefox и, в целом, является наиболее эффективным способом разработки тестовых сценариев. Дополнение среди прочего содержит контекстное меню, позволяющее пользователю сначала выбрать любой элемент интерфейса на отображаемой браузером в данный момент странице, а затем выбрать команду из списка команд Selenium с параметрами, предустановленными в соответствии с выбранным элементом. [1]

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

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

Схему взаимодействия моделей системы Selenium можно представить следующим видом (Рисунок 11).

Рисунок 11 - Схема взаимодействия модулей системы Selenium[1]

Для осуществления загрузки компонента в программу Selenium необходимо выполнить ряд действий:[4]

Открыть вкладку “File”;
Нажать клавишу “Open”; (Рисунок 12)
Выбрать необходимый для тестирования компонент или набор компонентов;
Нажать клавишу “Открыть”. (Рисунок 13)

Рисунок 12 - Открытие окна Select a File

Рисунок 13 - . Окно Select a File

В данный момент Selenium используя модуль “Диспетчер загрузки компонентов”[5] осуществляет импортирование выбранных компонентов. По завершению загрузки компонентов имеется возможность простого запуска разработанного компонента или при наличии необходимости произвести его изменение, внеся всю необходимую информацию через интерфейс SeleniumIDE.[4]

При запуске компонента необходимая информация передается в модуль “Диспетчер запуска и работы компонента” являющегося основным модулем контроля выполнения загруженного компонента.(Рисунок 6)

Процесс выполнения компонента сводится к следующим шагам[1]:

SeleniumIDE устанавливает связь с сервером Selenium;
Сервер Selenium запускает браузер с URL, внедряющим Selenium ядра в загружаемую браузером веб-страницу;
SeleniumIDE передает серверу команды запрограммированные в компоненте;
Сервер интерпретирует команды и затем вызывает соответствующий JavaScript, исполняющий команду в браузере.
Selenium ядро дает браузеру команды выполнить первую инструкцию, обычно это открытие страницы тестируемого приложения;
Браузер получает запрос на открытие и запрашивает содержимое веб-сайта у сервера Selenium;
Сервер Selenium связывается с веб-сервером, запрашивая страницу. Получив ее, сервер Selenium отправляет страницу браузеру, маскируя источник таким образом, чтобы он выглядел так, будто страница пришла от того же сервера, что и Selenium Core (благодаря чему Selenium Core соблюдается правило ограничения домена);
Браузер получает веб-страницу и отображает в зарезервированном для нее окне.

При выполнении любой команды сервер и ядро передает информацию о состоянии в модуль “Запуска и работы компонента”, что позволяет отслеживать процесс работы компонента и регистрировать возникающие ошибки. По окончанию работы компонента, вся собранная информация из данного модуля передается в модуль “Формирования отчета по работе компонента” в котором вся информация предоставляется в читабельном виде. (Рисунок 14)[4]

Рассмотрим процесс работы компонента при прохождении одного из тест-кейсов.

Далее приведен пример работы компонента «Регистрация и работа пользователя в Интернет магазине». Разработанный компонент за одно свое выполнение производит проверку всех функциональных областей Интернет-магазина которые были выявлены для тестирования на шаге анализа требований. (Рисунок 9)

Действия выполняемые компонентом за одно выполнение:

- Регистрация нового пользователя в Интернет-магазине;

- Проверка возможности изменения информации в личном кабинете пользователя;

- Добавление и удаление объекта из корзины;

- Полноценный заказ товара;

- Работа консультанта.

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

Рисунок 14 - Форма регистрации пользователя в интернет-магазине

Assert.AreEqual("ПароливполяхПарольиПодтверждениепаролянесовпадают.", driver.FindElement(By.CssSelector("#password2_error_message > p")).Text);

}

catch (AssertionException e)

{

verificationErrors.Append(e.Message);

}

driver.FindElement(By.Id("password1")).Clear();

driver.FindElement(By.Id("password1")).SendKeys("●●●●●●●●●●●●");

driver.FindElement(By.Id("save_profile_but")).Click();

driver.FindElement(By.Id("password1")).Clear();

driver.FindElement(By.Id("password1")).SendKeys("ЙЦУкен123456");

driver.FindElement(By.Id("password2")).Clear();

driver.FindElement(By.Id("password2")).SendKeys("ЙЦУкен123456");

driver.FindElement(By.Id("save_profile_but")).Click();

driver.FindElement(By.CssSelector("img.logo")).Click();

driver.FindElement(By.LinkText("Вседляавтозвука")).Click();

driver.FindElement(By.XPath("//div[@id='category_products_25']/div/div/ul/li/a/img")).Click();

Листинг 1 - Часть скрипта проверки главного меню

Полный код данного компонента приведен в приложении А.

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

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

“По клику левой кнопкой мыши на кнопку Пуск в нижнем левом

углу экрана не выплывает навигационное меню.

1. Наведите курсор мыши точно на кнопку пуск.

2. Выполните одиночный короткий клик на кнопке.”

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

Чтобы было понятно, что это новый отчет об ошибке и программистам стоит заняться проблемой, необходимо указать статус: “Открытый” (Open). В дальнейшем, когда этот отчет руководитель передаст какому-то программисту для исправления, его статус должен измениться на “Назначен” (Assigned). Начав работу над исправлением программист переводит состояние ошибки в “В процессе” (In progress).

Рисунок 15 - Жизненный цикл ошибки[5]

Починив ошибку, он передает вам отчет в статусе “Исправлен” (Fixed). После чего тестировщик, воспроизводит указанную последовательность действий для определения была устранена ошибка или нет. Руководитель разработки или разработчик может вернуть ошибку на любом этапе (кроме “Исправлен”), если считают что это не ошибка. На отчете в этом случае ставится пометка “Не ошибка” (Not a Bug, Will not fix). В этом случае должна указываться причина, почему они так считают. Без уважительных причин не вправе закрыть этот дефект со статусом “Закрыто” (Closed) и необходимо будет переоткрыть его снова поставив статус в “Пере-открыто” (Reopened). Весь этот процесс называется жизненным циклом ошибки. (Рисунок 15)[5]

Выводы по главе 3

1. Показана работа по отладке программ на языке Delphi:

Пошаговая трассировка
Точка останова
Просмотр значений

2. Кратко описана среда разработки автоматизированного тестирования SeleniumIDE

3. Описана последовательность процесса автоматизированного тестирования

4. Приведен пример тестирования формы ввода web-сайта

5. Описана последовательность действий при обнаружении ошибок в коде.

ЗАКЛЮЧЕНИЕ

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

В результате выполнения работы получены следующие выводы:

1. Рассмотрены основные процессы разработки программного обеспечения.

2. Определенно место тестирования в процессе проверки качества программного обеспечения.

Функциональность
Надежность
Удобство использования
Производительность
Удобство сопровождения
Переносимость

5. Приводится классификация видов тестирования. Рассмотрена следующая классификация

Тестирование “белого ящика”, “черного ящика”, “серого ящика”.
По степени автоматизации тестов
По виду позитивности
По времени проведения
По степени изолированности компонентов

6. Рассмотрено тестирования Web-приложений

7. Описан процесс организации тестирования.

8. Выделены основные проблемы которые могут возникнуть в процессе тестирования

9. Кратко описана среда разработки автоматизированного тестирования SeleniumIDE

10. Описана последовательность процесса автоматизированного тестирования

11. Приведен пример тестирования формы ввода web-сайта

12. Описана последовательность действий при обнаружении ошибок в коде.

БИБЛИОГРАФИЯ

Тестирование программного обеспечения//Информационный сайт «Software-Testing.Ru». URL: http HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save":// HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"software HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"- HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"testing HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save". HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"ru HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"/ HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"library HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"/ HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"around HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"- HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"testing HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"/ HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"processes HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"/437- HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"learn HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"- HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"to HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"- HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save" HYPERLINK "http://software-testing.ru/library/around-testing/processes/437-learn-to-save"save . (Дата обращения 18.02.2017).
Виды тестирования //Сайт издательства «открытые системы». URL:http://www.osp.ru/os/2009/03/8161608, (Дата обращения 18.02.2017)..
Портал об автоматизированном тестировании ПО [Электронный ресурс] – URL:: http://automated-testing.info/tools, (Дата обращения 18.02.2017)..
Selenium// Информационный сайт «learnSelenium». URL: http://www.learnSelenium.com/ (Дата обращения 18.02.2017)..
Selenium //Информационный сайт «Selenium.blogspot». URL: http://Selenium.blogspot.ru/2007/05/vbscript-in-Selenium.html (Дата обращения 18.02.2017).
ISO/IEC 9126-1:2001. Software engineering – Software product quality – Part 1: Quality model. – 2001г.
Бабенко Л.П., Лавришева Е.М Основы программной инженерии.- Киев: Знание, 2011. – 269 с
Борзов Ю. В., Уртанс Г. Б., Шимаров В. А. Выбор путей программы для построения тестов. - УСиМ. - 2012. - N. 6 - с.29 – 36
Канер С., Фолк Д., Нгуен Е.К Тестирование программного обеспечения: Пер с англ Киев: DiaSoft. – 2012. – 544 с
Котляров В.П. Основы тестирования программного обеспечения.// Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру » Год выпуска: 2013 - : 360 стр. ISBN: 5-9556-0027-2
Лаврищева Е.М., Коротун Т.М Построение процесса тестирования программных систем Проблемы программирования.–2012.–№1–2.–С.272–281
Липаев В.В Методы обеспечения качества крупномасштабных программных средств . - М.: Синтег, 2013- 3340 С.
Липаев В.В. Тестирование программ. М.: Радио и связь, 2009. - 296с.
Майерс Г. Искусство тестирования программ М.: Финансы и статистика, 2014. -176 с.
Шимаров В. А. Тестирование программ: цели и особенности инструментальной поддержки // Программное обеспечение ЭВМ / АН БССР. Институт математики. Минск, 2012. - Вып. 100 - с. 19 – 43
Вигерс Карл. Разработка требований к программному обеспечению/Пер, с англ. — М.: Издательсш-торговый дом «Русская Редакция», 2014. —576с.: ил.
Калбертсон Р., Браун К., Кобб Г. Быстрое тестирование – ISBN 5-8459-0336-Х. М.: Издательский дом «Вильямс», 2015. -380с.
Фаулер М. Рефакторинг: улучшение существующего кода. – Пер. с англ. – СПб: Символ-Плюс, 2013. -432с., ил. ISBN 5- 93286-045-6
Симдянов И. В., Программирование. Ступени успешной карьеры. / Симдянов И. В., Кузнецов М. В. // - БХВ-Петербург, 2012. – 320 с.
Крат, Ю.Г. Основы информационной безопасности : учеб. пособие / Ю.Г. Крат, И.Г. Шрамкова. – Хабаровск : Изд-во ДВГУПС, 2011. – 112 с.