Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

324 Глава 7

• процесс перебора альтернатив и «отсеивания» невозможных или нежела-

тельных их сочетаний может быть автоматизирован, что избавит тестировщика от

рутинной работы.

7.3.6. Тестирование переходов между состояниями

По этому методу тесты проектируются для проверки переходов между со-

стояниями программы (например, изменения изображения на экране, смены соста-

ва и активности элементов меню и др.). Поскольку количество возможных состоя-

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

вать, при проектировании тестов следует руководствоваться практическими сооб-

ражениями [8]:

• набор тестов должен охватывать наиболее вероятные последовательности

действий пользователей;

• если есть зависимые состояния и синхронизируемые события, для каждо-

го из них должны разрабатываться отдельные тесты;

• отдельные тесты следует проектировать также для проверки недопусти-

мых переходов между состояниями (для выявления возможных нежелательных по-

бочных эффектов);

• после выполнения минимального набора тестов следует провести набор

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

В качестве инструментов при проектировании тестов используют:

- диаграммы переходов в состояния (State-transition diagram) [36];

- таблицы переходов в состояния (State-transition tables).

Диаграмма перехода в состояния отображает множество состояний в рас-

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

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

Состояние 1

исходное состояние

Состояние 3

Состояние 2

Состояние n

...

переход1

переход 2

переход 3

переход n

...

Рис.7.4. Общий вид диаграммы переходов состояний

Таблицы переходов в состояния предназначены для изображения той же ин-

формации, но в табличном виде (таблица 7.6).

Таблица 7.6. Структура таблицы переходов состояний

Состояние Событие Действие Следующее

состояние

Глава 7 325

Этот метод изначально предназначался для тестирования программ реального

времени, но впоследствии стал применяться при проектировании тестов для инте-

рактивных программ: тестирования состояний меню (активно, не активно, выбра-

но), навигации между окнами, синхронизации элементов интерфейса в диалоговых

окнах.

7.3.7. Тестирование, основанное на моделях программной системы

Как самостоятельное направление тестирование на базе моделей (model-based

testing (MBT)) оформилось к середине 90-х годов прошлого века в связи с автома-

тизацией разработки тестов [43]. Хотя, по сути, все методы тестирования применя-

ют модели, для данного направления характерно следующее:

- модель представлена в формальном виде;

- модель применяется для генерации тестов или эталона.

В энциклопедии wikipedia (www.wikipedia) тестирование на базе моделей оп-

ределяется как «…тестирование ПО, при котором тесты разрабатываются полно-

стью или частично по модели, описывающей некоторые аспекты (как правило,

функциональные) тестируемой системы».

Тесты в целом образуют набор, именуемый абстрактным набором тестов

(abstract test suite), который непосредственно не может применяться для тестирова-

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

(выводимого) по модели. Разработка же самой модели делается параллельно с раз-

работкой ПС или непосредственно для существующей ПС.

Тестирование на базе моделей - это обобщение и расширение известных

«классических» методов, применяемых для автоматического построения тестов,

например:

- теория конечных автоматов;

- переходы между состояниями;

- доказательство теорем и др.

Более подробную информацию о данном подходе можно получить, напри-

мер, на сайте http://www.model-based-testing.org/.

7.3.8. Тестирование Web-приложений

Web-приложения можно рассматривать как клиент/серверные приложения, в

которых функциональность реализуется как на серверной, так и на клиентской сто-

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

которой [44]:

1) для взаимодействия с пользователем используется Web-браузер;

2) взаимодействие с пользователем четко разделяется на этапы, в течение ко-

торых браузер работает с одним описанием интерфейса, а эти этапы, в свою оче-

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

жению;

3) для описания интерфейса применяется стандартное представление;

4) взаимодействие между браузером и приложением осуществляется по стан-

дартному протоколу (HTTP) и четко формализовано;

5) функциональность Web-приложения распределена между удаленным сер-

вером и клиентскими компьютерами пользователей.

Таким образом, тестирование Web-приложений проводится на трех уровнях:

326 Глава 7

- интерфейса пользователя;

- сервера (серверов);

- протоколов их взаимодействия.

В целом, тестирование основано на использовании сценариев, описывающих

последовательность действий виртуальных пользователей.

Функциональное тестирование проводится как на уровне интерфейса при-

ложения, так и на уровне его взаимодействия с сервером.

Тестирование интерфейса обычно сводится к проверке корректности вводи-

мых данных, правильности навигации по сайту и других характеристик интерфейса

и связано с удобством применения Web-приложения.

В таблице 7.7 приведен пример общего контрольного вопросника для про-

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

для планирования тестирования (опубликован компанией IT-Online) [45].

Таблица 7.7. Контрольные вопросы для проверки удобства применения

Web-приложений

Архитектура и навигация сайта

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

Понятна ли схема навигации?

Можно ли определить, в каком месте сайта вы находитесь?

Легко ли найти на сайте нужную информацию?

Разумно ли количество элементов в панелях навигации?

Логично ли отсортированы элементы?

Соответствуют ли названия гиперссылок названиям страницы?

Отчетливо ли выделены гиперссылки ?

Отчетливо ли выделена ссылка на главную страницу?

Существует ли возможность поиска информации на сайте?

Существует ли карта сайта?

Каждая ли страница позволяет понять, на каком сайте вы находитесь?

Можно ли управлять навигацией по сайту?

Планировка и дизайн сайта

Не превышает ли размер страницы размер окна?

Повторяется ли схема планировки на всех страницах?

Существует ли отчетливый фокус на каждой странице?

Видна ли визуально планировка?

Эффективно ли используется выравнивание и группировка?

Достаточно ли хорош контраст?

Не громоздкая ли планировка?

Нравится ли вам сайт эстетически?

Содержание сайта

Понятны и лаконичны ли тексты на сайте?

Организован ли текст в виде небольших блоков?

Встречаются ли в тексте грамматические и орфографические ошибки и опечатки?

Содержат ли страницы вводный текст?

Поддерживают ли мультимедийные компоненты задачи пользователя?

Являются ли единицы измерения, используемые на сайте, понятными?

Представлены ли на сайте время и дата создания страниц?

Представлены ли на сайте номера контактных телефонов?

Представлены ли на сайте адреса с почтовыми индексами?

Глава 7 327

Формы и взаимодействие

Соответствуют ли формы задачам пользователя?

Поддерживают ли диалоги логичную последовательность шагов?

Очевидна ли кнопка или ссылка для перехода к следующему шагу диалога?

Все ли элементы форм используются по назначению?

Сгруппированы ли элементы формы по смысловому назначению?

Понятно ли выглядит кнопка отправки формы?

Графика

Приемлемо ли качество используемой графики ?

Все ли графические элементы имеют альтернативные текстовые надписи?

Содержат ли графические элементы информацию о размере файла?

Оптимизированы ли графические элементы для передачи по Интернету?

Реагируют ли графические элементы на движения мышки?

Используется ли анимация? Приемлем ли объем графических файлов?

Цвета

Подходящий ли выбор цветов для сайта?

Не слишком ли много цветов?

Используются ли цвета логично и последовательно?

Адекватно ли различаются цвета в черно-белом режиме?

Оформление текста

Понятны ли тексты?

Приемлем ли размер шрифта?

Имеет ли шрифт подходящий цвет и достаточно ли он контрастный?

Отформатирован ли текст так, чтобы в строке было от 10 до 12 слов?

Достаточна ли ширины поля вокруг текста?

Устойчивость к ошибкам

Должен ли пользователь что-нибудь запоминать, переходя между страницами?

Возникает ли предупреждение при попытке совершения необратимых действий?

Можно ли отменить рискованные действия?

Перехватываются ли возникающие ошибки локально, без обращения к серверу?

Содержат ли страницы с сообщением о возникших ошибках полезную информацию?

Содержат ли страницы с пустыми результатами поиска советы по расширению усло-

вий поиска?

Существует ли система контекстной помощи (справки)?

Структурирована ли помощь по задачам пользователя? Объясняет ли она пользовате-

лю, как совершить то или иное действие?

Платформа и особенности реализация

Достаточно ли быстро происходит загрузка страниц (от 3 до 15 секунд)?

Все ли гиперссылки работают правильно?

Существуют ли поврежденные графические элементы?

Написан ли текст на страницах так, чтобы его могли найти поисковые системы?

Работает ли сайт с разными браузерами пользователя?

Работает ли сайт на мониторах высокого и низкого разрешения?

Используются ли нестандартные plug-in? Являются ли они необходимыми и полезны-

ми?

Вопросы тестирования серверной части Web-приложений рассмотрены в

разных источниках [44, 46-50], например, в [44] предложена оригинальная техноло-

гия тестирования

UniTesK.

328 Глава 7

Наряду с функциональным тестированием в Web-приложениях возрастает

роль тестирования технических характеристик, прежде всего, надежности и вос-

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

браузерах и платформах).

Вопросы тестирования безопасности охватывают, помимо проверки кор-

ректности ввода, анализ таких распространенных аспектов «уязвимости» Web-

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

намеренное раскрытие информации, а также традиционные ошибки в обычных

приложениях. Так, в работе [49] предложена методология систематического тести-

рования, охватывающая следующие аспекты проверки:

1. Идентификация окружения web-приложения. Включает анализ информа-

ции об используемых языках скриптов, Web-сервере, операционной системе. Для

извлечения такой информации рекомендуется:

– проанализировать отклик на HTTP-запросы HEAD и OPTIONS (из заго-

ловка или любой страницы, содержащей строку SERVER);

– исследовать формат и текст информации о 404-й ошибке сервера (и дру-

гих). Некоторые системы имеют легко узнаваемые сообщения об ошибках, а также

часто позволяют узнать версии используемых языков. Можно преднамеренно за-

просить страницы, приводящие к подобным ошибкам, а также использовать аль-

тернативные методы запроса (POST, PUT и т.п.) для извлечения информации из

сервера;

– проверить распознаваемые типы файлов/расширения/каталоги. Многие

Web-серверы по-разному реагируют на запросы файлов с поддерживаемыми и не-

известными расширениями. Следует попытаться запросить файлы со стандартными

расширениями, такими как “.ASP”, “.HTM”, “.PHP”, “.EXE”, и следить за появле-

нием какого-либо необычного результата или кодов ошибок;

– проверить исходные тексты доступных страниц. Исходный текст страни-

цы, сгенерированной Web-приложением, может указывать на используемое про-

граммное окружение;

– попытаться исказить входные данные для получения ошибок в скриптах.

Это также позволит получить информацию об окружении Web-приложения;

– использовать сканирование TCP/ICMP и сервисов. Для этого рекоменду-

ется использовать анализаторы приложений (в частности, Amap и WebServerFP)

или средства сканирования Nmap и Queso.

2. Тестирование скрытых элементов форм и раскрытие исходных текстов.

Включает проверку всех исходных текстов страниц на наличие любой полезной

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

менты скриптов, расположенных внутри HTML-кода, ссылки на подключаемые или

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

исходным текстом. Должно быть проверено наличие каждой программы и скрипта,

ссылки на которые были найдены. В случае обнаружения они тоже должны быть

протестированы.

3. Определение механизмов аутентификации. Необходимо проверить, как

выбранный механизм применяется к каждому ресурсу, используемому Web-

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

через каждую точку входа. Многие Web-системы предлагают средства поддержки

сессий, основанные на сохранении в cookie или Session-ID псевдоуникальной стро-

Глава 7 329

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

хэшем или строкой, составленной из известных элементов, система может оказать-

ся уязвимой к таким видам атаки, как, например, прямой перебор, повторная от-

правка, или попытка восстановления.

Некоторые особенности тестирования Web-приложений связаны с процессом

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

«ускоренной» разработки, в которых:

– тестирование встроено в ЖЦ и выполняется параллельно с разработкой;

– небольшие проектные группы (или один Web-дизайнер);

– активное участие заказчика (не всегда возможно);

– очень сжатые сроки разработки версий ограничивают время на тщатель-

ное планирование и выполнение тестирования;

– фаза интеграции Web-приложения обычно отсутствует (нет интеграцион-

ного тестирования) поэтому основное внимание уделяется функциональному тес-

тированию приложений в моделируемой среде и системному – в реальной среде;

– стадия сопровождения и развития – неотъемлемая часть ЖЦ, следова-

тельно, требуется постоянное регрессионное тестирование.

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

Особенно это касается тестирования производительности и надежности сервера.

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

фирм-производителей можно найти в приложении 4.

Среди множества публикаций по тестированию можно выделить переводную

монографию [50], посвященную вопросам тестирования Web-приложений, а также

перечень статей, посвященных разным аспектам тестирования в Интернет, напри-

мер, на сайте http://www.rspa.com/reflib/TestingWebApps.html#testingMethods

7.3.9. Особенности выполнения тестирования в моделях ЖЦ

Процесс тестирования ПС и его интеграция с другими процессами разработ-

ки существенным образом зависит от принятой в проекте модели ЖЦ.

В таблице 7.8 представлены основные модели ЖЦ и подходы к тестирова-

нию, применяемые в этих моделях (по материалам сайта http://www.qalabs.com).

Таблица 7.8. Подходы к тестированию, применяемые в моделях ЖЦ

Модель ЖЦ Применяемые подходы к тестированию

Каскадная

Ключевая особенность модели: Каскадная модель с циклами обрат-

ной связи, моделированием или прототипированием. Тестирование на-

чинается после завершения кодирования.

Основные методы/подходы:

1. Передача кода группе тестирования после его готовности.

2. Пользователи привлекаются к тестированию на этапе приемочных

испытаний.

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

(опытная эксплуатация).

Примечание: Улучшение тестирования возможно в конце проекта, что

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

следующих проектах.

330 Глава 7

Модель ЖЦ Применяемые подходы к тестированию

Спиральная

Ключевая особенность модели: использует прототипирование и пере-

планирование с постоянным оцениванием рисков и ограничений в рам-

ках каждого прототипа.

Основные методы/подходы:

1. Тестирование, основанное на оценке риска (risk-driven testing). Тес-

тирование применяется для идентификации рисков. Анализ дефек-

тов служит ключом для идентификации «узких» мест в ПО.

2. Тестирование начинается на ранних стадиях ЖЦ.

3. Критерий завершения тестирования, основанный на риске. Тесто-

вое покрытие – не основная цель. Стратегия тестирования форми-

руется с учетом рисков потенциально оставшихся дефектов и по-

могает принять решение о переходе к следующему витку спирали.

Примечания:

1. В рамках стадии ЖЦ в одном витке спирали тестирование выпол-

няется так же, как и в каскадной модели, но на меньшем объеме ПС

и менее продолжительно.

2. Общее время тестирования в рамках ЖЦ больше, поскольку боль-

ший промежуток времени между его началом и выпуском ПС

Personal

Software

Process

(PSP)

Ключевая особенность модели: Обучение разработчиков методам

идентификации, анализа и улучшения собственных процессов. Цель –

дать возможность каждому улучшить собственную производительность

и достичь установленных целей качества.

Основные методы/подходы:

1. Методы верификации (инспекции, персональные просмотры, кол-

лективные проверки).

2. Раннее устранение дефектов. Разработчики поощряются за раннее

устранение дефектов; фиксацию и управление дефектами, регуляр-

ный анализ дефектов.

3. Стремление к постоянному улучшению процесса.

Примечание: Персональное управление дефектами (фиксация своих

дефектов сразу после их внесения, персональные проверки проекта и

кода по установленным руководствам и контрольным вопросникам).

Модели ус-

коренной

разработки

(Agile Pro-

gramming)

Ключевая особенность модели: Итеративный подход, постоянное

автоматизированное тестирование разработчиками, тесное взаимодей-

ствие, минимум документации (в том числе по тестированию).

Основные методы/подходы:

1. Управляемая тестами разработка (test-driven development). Разра-

ботчики пишут тесты до кодирования и (при необходимости) об-

новляют их для повышения полезности

2. Автоматизация. Когда тесты «стабильны», они автоматизируются,

предпочтительно группами так, чтобы их можно было ассоцииро-

вать с модулем или проектом системы.

3. Принцип «достаточно хорошее качество». Достаточность связыва-

ется со сложностью ПС, критичностью ее функций, терпимости за-

казчика к ошибкам и др.

4. Тестирование рассматривается как стратегия снижения риска отка-

за.

5. Приемочные тесты обычно разрабатываются заказчиком и должны

быть готовы до начала проектирования и кодирования.

Глава 7 331

7.4. Анализ результатов тестирования

7.4.1. Система отслеживания проблем

На эффективность тестирования и устранения дефектов оказывает большое

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

также наличие хорошего инструмента для его поддержки. При отсутствии про-

мышленного инструмента, группа тестирования может создать свою систему от-

слеживания проблем, например, с помощью MS Access.

Цели системы отслеживания проблем:

– отслеживание состояния тестирования и устранения дефектов;

– организация взаимодействия между сотрудниками и решение спорных

вопросов относительно классификации и приоритетов устранения дефектов;

– определение причин дефектов и выявление «узких мест» в процессах раз-

работки и тестирования.

С отчетами о проблемах в процессе тестирования работают тестировщики,

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

решения проблемы важно определить полномочия пользователей системы отсле-

живания проблем (как исполнителей процесса «Решение проблем»).

Процесс решения проблем, обнаруженных при тестировании, может быть

представлен следующей последовательностью шагов.

Шаг 1. Открытие проблемы. При обнаружении проблемы тестировщик со-

ставляет отчет о проблеме («открывает проблему») и передает его программисту

для анализа. При автоматизированном ведении отчетов тестировщик помещает от-

чет в базу данных.

Шаг 2. Изучение. Программист анализирует отчет и принимает решение (со-

гласен или нет). Если проблема вызвана случайным отказом, связанным, например,

со сбоем оборудования, средой тестирования, нарушениями технологии тестирова-

ния или непониманием тестировщика - она отклоняется. Если установлено, что

проблема связана с дефектом в ПО, программист устанавливает приоритет устра-

нения дефекта. В спорных случаях решение о приоритете устранения принимает

руководитель проекта.

Шаг 3. Действие. Программист выполняет устранение дефекта и повторное

автономное тестирование и возвращает отчет с отметкой «Исправлена» тестиров-

щику. При автоматизированном ведении отчетов тестировщик находит отчеты с

этой отметкой в базе данных.

Шаг 4. Закрытие. Тестировщик выполняет проверку исправлений и закрыва-

ет проблему. Закрыть отчет о проблеме может только тестировщик. При автомати-

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

дующего анализа, формирования отчетов, а также для накопления исторических

данных. Отчеты об отклоненных дефектах могут удаляться из базы данных (но

только тестировщиком!).

Шаги 1 - 4 касаются отслеживания каждого отдельного дефекта, но для ана-

лиза результатов и управления процессом тестирования используются обобщенные

и классифицированные данные о дефектах. Этот анализ и обобщение выполняется

менеджером группы тестирования и менеджером проекта. Обобщенные данные

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

332 Глава 7

7.4.2. Классификация дефектов, обнаруженных при тестировании

Существуют разные подходы к классификации дефектов, которые вносятся в

ПС и выявляются на разных стадиях ее разработки. Вопросы классификации де-

фектов, выявляемых при выполнении процессов верификации и валидации, уже

рассматривались в главе 6. Наиболее полная классификация представлена в стан-

дарте IEEE Std. 1044:1993 [51]. В нем вместо термина дефект используется термин

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

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

ПC. В этом разделе рассматриваются вопросы классификации дефектов, которые

обнаруживаются при тестировании.

Наиболее важными аспектами классификации дефекта являются: симптом;

серьезность; приоритет устранения; стадия разработки и источник; тип.

Симптом дефекта касается его видимого проявления, наблюдаемого тести-

ровщиком при выполнении тестов. Описание симптома необходимо для анализа

дефекта разработчиком и определения истинной причины дефекта.

Рекомендуемая IEEE Std.1044:1993 классификация симптомов такова:

•

Аварийное завершение программы

•

Не ожидаемое поведение программы

•

"Зависание" программы

•

Проблема ввода

- Корректные данные не вводятся

- Неправильные данные вводятся

- Описание данных отсутствует или неправильно

- Параметры не полные или отсутствуют

•

Проблема вывода

- Неправильный формат

- Неправильные результаты/данные

- Вывод не полный или отсутствует

- Грамматика/синтаксис

•

Неудовлетворительная производительность

•

Ощущение общего отказа продукта

•

Сообщение об ошибке системы

•

Другое

Для классификации дефектов по серьезности стандарт IEEE Std.1044:1993

рекомендует такую порядковую шкалу:

•

Критический

•

Серьезный

•

Значительный

•

Незначительный

•

Не дефект

В каждом конкретном случае «серьезность» дефекта зависит от типа системы

и должна определяться в контексте последствий дефекта для системы (или для

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

таблице 7.9 (в ней каждому уровню серьезности присвоен код).

Глава 7 333

Таблица 7.9. Описание серьезности дефекта

Код Серьезность Описание

1 Критический Дефект приводит к отказу всей системы, подсистемы, или

компонента. Дальнейшее тестирование и/или использование

системы невозможно.

2 Серьезный Дефект приводит к отказу компонента ПО, потере данных.

3 Значительный Дефект приводит к получению некорректных, неполных или

противоречивых результатов, либо дефект касается удобства

использования системы.

4 Незначитель-

ный

Дефект не приводит к отказу, не ухудшает удобство исполь-

зования системы и может быть легко обойден.

5 Не дефект Ошибки в тестах, сбои аппаратной или программной среды.

С каждым дефектом связывается приоритет устранения. Для классифика-

ции дефектов также может использоваться порядковая шкала (таблица 7.10).

Таблица 7.10. Описание приоритетов устранения дефекта

Код Приоритет Описание

1 В первую

очередь

Дальнейшая разработка и/или тестирование не может выполнять-

ся до устранения дефекта

2 Обратить

особое вни-

мание

Дефект должен быть устранен как можно быстрее, поскольку его

наличие отрицательно влияет на разработку и/или тестирование

3 В порядке

очереди

Дефект должен устраняться в порядке плановых действий по

разработке. Его устранение может быть отложено до выпуска

новой версии

4 Отложить Устранение дефекта может быть отложено на неопределенный

срок. Он может быть устранен в следующей версии или вообще

не устраняться

5 Отклонить Не дефект. Возможно случайный сбой или ошибка тестировщика

Классификация дефектов по стадиям разработки соотносит дефекты со

стадиями разработки (и процессами), на которых они были внесены.

Классификация дефектов по источникам соотносит дефекты с рабочими

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

фектов в коде ПО, например:

•

Спецификация (требований, функций, проекта, интерфейса, данных)

•

Код (дефекты кодирования)

•

Документация на систему

•

Планы и процедуры тестирования

Ниже перечислены основные типы дефектов, рекомендуемые IEEE

Std.1044:1993.

•

Логические

•

Вычислений

•

Интерфейса

•

Обработки данных

•

Ввода данных

•

Обработки ошибок и др.

Собранные и классифицированные данные о дефектах составляют основу для

вычисления метрик тестирования.