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

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


Загрузка...
страницы: 1   ...   5   6   7   8   9   10   11   12   13
вернуться в начало
скачать
^

5.3Связанные с изменениями виды тестирования


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

  • Дымовое тестирование (Smoke Testing)

  • Проверка согласованности/исправности (Sanity Testing)

  • Регрессионное тестирование (Regression Testing)

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

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

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

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

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

Сам по себе термин "Регрессионное тестирование", в зависимости от контекста использования может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа регрессионного тестирования:

  • Регрессия багов (Bug regression) - попытка доказать, что исправленная ошибка на самом деле не исправлена

  • Регрессия старых багов (Old bugs regression) - попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться.

  • Регрессия побочного эффекта (Side effect regression) - попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения
^

Глава 6.Оценка эффективности автоматизации тестирования


Рассмотрим пример из практики использования автоматизированного тестирования, отражающего итоги научно-исследовательской работы, проведенной в Европе, по сбору измерений результатов автоматизированного тестирования с целью изучения преимуществ методов автоматизированного тестирования по сравнению с тестированием вручную. Изучение проводилось компанией 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%



Тест i: тесты, определенные в рамках спецификаций по тестированию в основных проектах.

Vm: затраты на создание спецификации тестирования.

Va: затраты на создание спецификации тестирования и на реализацию.

Dm: затраты на выполнение одного теста вручную.

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

V и D измеряются в часах.

En = Aa/Am = (Va + n*Da)/(Vm + n*Dm)

N = значение показателя экономической эффективности

Подготовка спецификации требований по тестированию загрузки программного обеспечения (загрузка программного обеспечения являлась одной из функций продукта и производилась при нажатии кнопки ЗАГРУЗИТЬ) заняла 10 часов (Ручной V в строке Тест 2 в таблице 6.1). Программирование этих тестов заняло еще 4 часа, что вошло в полное время автоматизированной подготовки к тестированию (Автоматизированный V), равное 14 часам (см. результаты Теста 2). Ручное выполнение этих тестов заняло 2 часа (Ручной D) в противоположность 0.1 часа (Автоматизированный D), поскольку тестировщику нужно было проверить и проанализировать отчеты, сгенерированные средствами тестирования при автоматическом выполнении тестов. На основе измерений, полученных в результате однократного выполнения тестирования, можно вычислить расходы, которые потребовались бы для повторного тестирования 5, 10 или 20 раз. Например, в случае пяти автоматизированных выполнений тестов коэффициент уменьшения расходов на тестирование по сравнению с проведением тестирования вручную составит:

E5=Aam

= (Va + 5*Da)/(Vm + 5*Dm)

= (14 + 5*0.1)/(10 + 5*2)

= 14.5/20 = 0.725 = 73%

В таблице 5.1 показатель экономической эффективности представлен коэффициентом N в соответствии с равенством Е = Ааm = 100%, где Е — это относительные затраты, а А — абсолютные затраты (Аа — абсолютные затраты на автоматизацию,Аm — абсолютные затраты при тестировании вручную), N — значение показателя экономической эффективности, V— подготовка, a D — выполнение.

Измерения, выполненные в ходе эксперимента, показывают, что экономической эффективности можно добиться уже при проведении второго цикла регрессионного тестирования (ntotal = 2.03). Эта рентабельность, однако, требует соблюдения двух условий: (1) тестирование выполняется без вмешательства человека (например, ночью), и (2) не требуется никаких дальнейших модификаций скриптов для того, чтобы повторно выполнить их применительно к окончательным версиям продукта. Как уже упоминалось, эти необходимые условия нелегко соблюсти.

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




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

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

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

опубликовать
Загрузка...
Документы

наверх