Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Долговечность дефекта






 

Долговечность дефекта может быть описана следующим образом. Дефект возникает в результате того, что человек допускает ошибку (error), осуществляя некоторый вид деятельности, который имеет отношение к разработке программного обеспечения. К упомянутым видам деятельности относятся, например, формулирование требований, проектирование программы или написание программного кода. Эта ошибка вкрадывает­ ся в рабочий продукт (перечень требований, проектный документ или программный код) в виде неисправности (fault).

 

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

 

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

 

Врезка 1.1

 

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

 

Тестирование программного обеспечения выполняет две базовых функции: ве­ рификацию и аттестацию. В [45] функции верификации и аттестации (verification and validation, V& V) определяются следующим образом:

 

Верификация (verification) обеспечивает соответствие результатов конкретной фазыпроцесса разработки требованиям данной и предшествующей стадий.

 

Аттестация (validation) есть гарантия того, что программный продукт удовлетво­ряет системным требованиям.

 

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


Глава 1. П о н я т и е о технологии быстрого тестирования  

 

 

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

 

 

Остается дать определение еще одного дополнительного понятия — понятия каче­ ства. Подобно такому свойству, как красота, качество — во многом субъективное по­ нятие, поэтому точное определение дать ему достаточно трудно. Определим качество программного обеспечения с использованием трех факторов: отказов на месте экс­ плуатации продукта, надежности и степени удовлетворенности заказчика. Говорят, что программный продукт обладает хорошим качеством {quality), если:

 

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

 

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

 

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

 

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

 

Что такое быстрое тестирование?

 

В данной книге термин " быстрое тестирование" используется как дополнение поня­ тия " быстрая разработка". Как отмечалось в [33], для разных людей быстрая разра­ ботка означает различные вещи. Некоторые понимают это как быстрое создание прототипов. Другие представляют ее как некоторое сочетание инструментальных средств CASE, активного участия пользователя и жестких временных ограничений. В редакции Макконнела [33] при определении быстрой разработки не упоминаются специальные инструментальные средства или методы:

 

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

 

В том же ключе, быстрое тестирование (rapid testing) означает выполнение тестиро­ вания программного обеспечения в более быстром темпе, чем это делается в настоя-







© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.