К дипломному проекту icon

К дипломному проекту



страницы: 1   2   3   4   5   6   7   8   9   10
вернуться в начало
скачать
^

6.2Критерии полноты на основе структуры входных данных


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

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

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

  • Разделение значений по определенным правилам, касающимся их структуры. Например, целые числа обычно представляются в двоично-дополнительном формате, все отрицательные имеют первый (последний) бит, равный 1, в отличие от неотрицательных. Поэтому разбиение на положительные и отрицательные можно обосновать структурой представления числа в машине. Можно делить целые числа на большие и небольшие по абсолютной величине в соответствии с тем, есть ли хотя бы один бит равный 1 среди первых 16. То есть, числа >= 65536 по абсолютной величине объявляются большими, а меньшие — небольшими.

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

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

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

^ Метрика покрытия правил — доля правил грамматики, использованных для построения тестовых данных, среди всех ее правил.

Метрика покрытия альтернатив — для каждого правила определяется, сколько имеется возможных альтернатив его раскрытия, и вместо 1 в определении предыдущей метрики для всех правил учитывается это число, а для покрытых — только количество реализованных альтернатив.

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

Doc ::= A | B ;

A ::= ( “X” | “Y” | “Z” ) (“::”)? “!”

B ::= “O” (A)*

В этом случае один входной документ вида “OX!” покрывает все правила — для его построения используется и корневое правило, и правило для B, и правило для A.

Чтобы покрыть все альтернативы в правиле A, достаточно использовать такие входные данные: “X::!”, “Y!”, “Z!”. Здесь первая альтернатива раскрыта всеми возможными способами. Вторая альтернатива — наличие или присутствие “::” — тоже. Для правила B достаточно “O” и “OX!”, если считать, что опциональный список (A)? достаточно раскрыть на глубину 1. Чтобы список можно было отличить от опционального символа, можно

раскрыть его на глубину 2, использовав, например, “O”, “OX!” и “OX!Z!”. Таким образом, набор данных “X::!”, “Y!”, “Z!”, “O”, “OX!”, “OX!Z!” покрывает все альтернативы во всех правилах.
^

6.3Критерии полноты на основе требований


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

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

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

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

Например, пусть в требованиях к системе есть такая фраза.

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

В ней можно выделить следующие утверждения:

  • «Оператор может прочесть данные записи о клиенте»

  • «Оператор может добавить запись о клиенте»

  • «Оператор может удалить запись о клиенте, если работает с ней один»

  • «Оператор может модифицировать запись о клиенте, если работает с ней один»

  • «Если несколько операторов работает с записью о клиенте, только один может ее удалить»

  • «Если несколько операторов работает с записью о клиенте, только один может ее модифицировать»


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

Часто встречающийся случай — оформление требований в виде набора правил (или бизнес-правил). В этом случае метрикой покрытия правил считают долю проверенных тестами правил среди всех имеющихся.

Это позволяет определить метрики покрытия условий правил примерно так же, как это делается для покрытия условий, используемых в коде. Можно использовать аналоги метрик покрытия элементарных условий, условий и ветвлений, комбинаций условий или MC/DC. Использовать аналог метрики покрытия коротких дизъюнктов нельзя, если только мы не уверены, что в коде эти же условия используются ровно в этом же порядке, что практически никогда не выполнено.

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

6.4Критерии полноты на основе предположений об ошибках


Наиболее удобный на практике способ измерения полноты тестирования на основе явных гипотез о возможных ошибках — это метод определения полноты тестов на основе обнаруженных мутантов.

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

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

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

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

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

Глава 7.Организация тестирования программного продукта


При внедрении автоматизированного тестирования в разработку, во избежание многих частых проблем связанных с этим процессом, рекомендуется использовать методологию жизненного цикла автоматизированного тестирования (The Automated Testing Life-cycle Methodology, ATLM).

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

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

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

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

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

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

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

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

  2. ^ Фаза внедрения автоматизированного тестирования.

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

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

  1. ^ Планирование, проектирование и разработка тестирования

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

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

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

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

^ Разработка тестирования. Чтобы автоматизированное тестирование можно было повторно использовать, повторять и сопровождать, необходимо определить и соблюдать стандарты разработки тестирования.

  1. ^ Выполнение тестов и управление тестами

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

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

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

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

Рисунок 4 Соотношение жизненного цикла разработки системы с ATLM




^

Глава 8.Экономическое обоснование


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

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

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

Цель проекта — оптимизация процесса тестирования графического пользовательского интерфейса (GUI) и повышение степени использования автоматизированного тестирования за счет применения соответствующих инструментальных средств. Для получения сравнительных числовых оценок результатов тестирования исследователи проводили тестирование, используя ручные методы в одном примере и автоматизированные в другом. Требования к тестированию, определенные в спецификации тестирования, были исполнены тестировщиком вручную в основном проекте. Одновременно PIE-команда использовала требования к тестированию для разработки процедур автоматизированного тестирования и дальнейшего выполнения тестов и регрессионного тестирования с помощью автоматизированного средства WinRunner.

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


^ Таблица 6.1 Результаты эксперимента по усовершенствованию процесса разработки

Подготовка V

Выполнение D

N

Затраты E на выполнение n автоматизированных тестов

Тест

Ручной

Автома-тизиро-ванный

Ручной

Автома-тизиро-ванный




1

5

10

20

Тест 1

16

56

24

1

1.74

143%

45%

26%

15%

Тест 2

10

14

2

0.1

2.11

118%

73%

50%

32%

Тест 3

10

16

4.5

0.2

1.40

112%

52%

33%

20%

Тест 4

20

28

1.5

0.2

6.15

131%

105%

86%

64%

Тест 5

10

15

1

0.1

5.56

137%

103%

80%

57%

Тест 6

10

15

1.5

0.1

3.57

131%

89%

64%

43%

Тест 7

10

11.5

0.75

0.1

2.31

108%

87%

71%

54%

Тест 8

10

11.5

0.5

0.1

3.75

110%

96%

83%

68%

Тест 9

10

14

3 .

0.1

1.38

108%

58%

38%

23% «

Тест 10

10

10.6

0.5

0.1

1.50

102%

89%

77%

63% 1

Итого

116

191.6

39.25

2.1

2.03

125%

65%

42%

26%




оставить комментарий
страница9/10
Дата05.11.2011
Размер0,93 Mb.
ТипДиплом, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы: 1   2   3   4   5   6   7   8   9   10
отлично
  1
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Документы

наверх