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

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

294 Глава 6

Вопрос Метрика Код Описание

Q3, Q4 Коэффици-

ент выпол-

нения

Квып Нормализованная величина (нормализация по количе-

ству): отношение количества инспекций, проведенных

на определенной стадии проекта (или всего в проекте),

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

данной стадии (или проекта).

Квып = Ипл / Ипр

Может использоваться для того, чтобы понять, как

лучше планировать инспекции. Если Квып слишком

мал, это может означать, что для выполнения всех за-

планированных инспекций выделено недостаточно

времени.

Q1 Затраты

времени на

инспекцию

Тсум Суммарное количество часов, потраченных на подго-

товку и проведение инспекции

Тсум = Тпо + Тпр

Может использоваться для определения затрат времени

на инспекции по каждой стадии ЖЦ и по проекту в

целом.

Позволяет определить, растет (убывает) ли продолжи-

тельность инспекций по ходу проекта. Имея историче-

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

и максимальные затраты времени.

Q2 Интенсив-

ность под-

готовки к

инспекции

Спо Отношение размера продукта к среднему времени, по-

траченному на подготовку к инспекции одним инспек-

тором (Тпо_ср)

Среднее время на подготовку инспектора к инспекции

продукта

Тпо_ср = Тпо / Ргр

Интенсивность подготовки к инспекции

Спо = Рпрод / Тпо_ср

Эта величина показывает взаимосвязь между количест-

вом часов, потраченных на подготовку к инспекции, и

размером группы инспекторов и продукта. Чем число

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

готовку к инспекции продукта.

Имея исторические данные, можно определить, доста-

точна ли интенсивность подготовки к инспекции про-

дукта данного вида и объема группой определенного

размера.

Q2, Q4,

Интенсив-

ность про-

ведения

инспекции

Спр Отношение размера продукта к среднему времени, по-

траченному на проведение инспекции одним инспек-

тором (Тпр_ср).

Среднее время на проведение инспекции продукта ин-

спектором

Тпр_ср = Тпр / Ргр

Интенсивность проведения инспекции

Спр = Рпрод / Тпр_ср

Эта величина показывает взаимосвязь между количест-

вом часов, потраченных на проведение инспекции, и

размером группы инспекторов и продукта. Чем число

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

ведение инспекции продукта.

Глава 6 295

Вопрос Метрика Код Описание

Имея исторические данные, можно определить, доста-

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

дукта данного вида и объема группой определенного

размера.

Q5, Q6 Число де-

фектов,

обнаружен-

ных ин-

спекцией

Добн Общее количество дефектов, обнаруженных во время

инспекции. Показатель эффективности процесса ин-

спекции. Чем выше это число, тем выше отдача от вы-

деленных ресурсов.

Информация может быть получена по отчетам об ин-

спекциях и описаний (списка) дефектов, а сами дефек-

ты – классифицированы по типам и степени серьезно-

сти.

Q5, Q6 Число де-

фектов, нe

обнаружен-

ных ин-

спекцией

Дне-

обн

Общее количество дефектов в рабочем продукте, под-

вергавшемся инспекции, обнаруженных на последую-

щих стадиях в ЖЦ. Определяется после окончания ин-

спекции продукта на определенной стадии ЖЦ. Чем

меньше дефектов скрылось от инспекции, тем выше ее

эффективность (тем ближе мы к цели 2). Большое ко-

личество скрытых дефектов свидетельствует о пробле-

мах в самом процессе инспекции.

Q5, Q7 Размер

продукта

Рпрод В зависимости от вида рабочего продукта размер опре-

деляется количеством страниц или строк, или числом

функциональных элементов (экранов, отчетов, функ-

ций и др.), числом условных единиц функционально-

сти (FP) или числом KSLOC.

Q7 Продуктив-

ность ин-

спекции

Иэф Нормализованная величина (нормализация по размеру

или времени): количество дефектов, обнаруженных

инспекцией в продукте определенного размера (плот-

ность дефектов), или – за определенный период време-

ни (подготовки или проведения инспекции) (частота

обнаружения). Может вычисляться в любой момент

процесса инспекции.

Q6, Q7 Коэффици-

ент обна-

ружения

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

общему числу дефектов

Кобн = 100 * (Добн / (Добн + Днеобн))

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

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

и использование по назначению.

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

фектов на стадии ЖЦ, если вычисляется как процент

дефектов, обнаруженных на стадии, к общему числу

дефектов, уже обнаруженных в проекте на определен-

ный момент. Чем выше это число – тем лучше раскры-

ваемость.

Q9 Относи-

тельная

эффектив-

ность мето-

да

Мэф Отношение количества дефектов, обнаруженных в

единицу времени инспекции, к количеству дефектов

(Дт), обнаруженных в единицу времени тестирования

Мэм = (Добн / Тсум ) / (Дт / время тестирования)

Дефекты должны быть однотипны.

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

ния дефектов в коде.

296 Глава 6

Сбор и анализ данных Ответственность за сбор объективных данных несет

группа инспекции. Необходимые для этого формы и инструменты (например, таб-

лицы Excel) должны быть подготовлены заранее группой SEPG или SQA. Собран-

ные данные направляются группе SQA для анализа состояния процесса.

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

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

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

спекторов, а также выборочный аудит данных.

Анализ данных проводится с целью определения направлений улучшения

процессов ЖЦ ПС или самой инспекции. Эффективными инструментами анализа

данных являются (см. главу 5):

- диаграммы Парето. Могут использоваться для ранжирования проблем (де-

фектов) по критичности, серьезности, для принятия решения о приоритете устра-

нения дефектов, отслеживания причин возникновения дефектов для предупрежде-

ния их появления в будущем;

- диаграммы выполнения. Отражают поведение определенной переменной во

времени. Могут использоваться для выявления тенденций в процессе инспекции;

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

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

и их способности к обнаружению дефектов (Кобн);

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

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

метрик) и наблюдаемых (базовых) величин - размера, стоимости, времени. Напри-

мер, соотношения данных об эффективности инспекций (Иэф) и размере групп,

выполнявших эти инспекции (Ргр);

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

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

инспекции. Наиболее эффективны, если в их построении участвуют несколько (не

менее трех) экспертов, хорошо понимающих разные аспекты определения процесса

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

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

представлен на рисунке 6.7.

Многие рабочие

продукты

остаются не

проверенными

стандарты не

существуют

процесс инспекции

не определен

инспекторы не обучаются

выполнению инспекции

результаты не наглядны

для принятия решений

успешный опыт не

распространяется

Методы

Персонал

нет ясных целей

процесса

не ясны цели повышения

качества продукта

отсутствуют

стандарты

не известно соотношение

пользы / затрат

не ведутся исторические

данные

Входы

Инструменты

Рис. 6.7. Пример причинно-следственной диаграммы

Глава 6 297

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

снижению эффективности процесса инспекции - должны быть подкорректированы

процедуры инспекции. Анализ может показать необходимость изменения объема

продукта, планируемого на каждую инспекцию, или объема вопросников, или по-

требность в дополнительном обучении инспекторов.

Если данные об инспекциях показывают, что меньше всего дефектов было

найдено на поздних стадиях ЖЦ (например, в коде), это может свидетельствовать о

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

стадиях ЖЦ были очень хороши. В последнем случае, может быть принято реше-

ние об инспекции только критических участков кода.

Данные об инспекциях могут использоваться и для улучшения процесса раз-

работки. Например, если данные инспекции кода свидетельствуют о том, что

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

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

и инспекций его рабочих продуктов. Способность определить, на какой стадии ЖЦ

была допущена ошибка (и внесен дефект, послуживший первопричиной после-

дующих дефектов), зависит от точности сбора данных. Любая попытка изменить

применяемые в организации процессы ЖЦ должна предприниматься с большой

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

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

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

кам процесса, группе качества и группе программной инженерии.

6.4. Требования к рабочим продуктам, предъявляемым для

проверки

Для того чтобы проверки были эффективными, предъявляемые рабочие про-

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

При проведении проверок проверяющие лица оперируют термином прове-

ряемый материал (ПМ) применительно к рабочим продуктам любого вида.

Единицей функциональности ПМ может быть одно предложение, абзац или

раздел, в котором содержится изложение законченной мысли. Например, для доку-

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

нального требования (функции) или нефункционального требования (нефункцио-

нальной характеристики) системы.

Проверяемый материал можно рассматривать как состоящий из компонентов

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

мые операции - модифицировать, добавить или удалить, не причиняя вреда другим

компонентам.

К структуре ПМ предъявляются следующие требования (с которыми могут

быть ассоциированы показатели качества ПМ) [22]:

Корректность. Каждое утверждение ПМ должно быть правильным.

Согласованность. Каждый ПМ должен содержать согласованные между со-

бой утверждения.

Полнота. Каждый ПМ должен содержать информацию, необходимую для

достижения его целей (целей, для которых ПМ разрабатывался). Каждый ПМ дол-

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

му стандартах.

298 Глава 6

Ясность. Смысл и назначение каждого утверждения ПМ должны быть ясны.

Предполагает:

определенность. Каждое утверждение ПМ должно быть четко идентифици-

рованным. Если это пример – должно использоваться ключевое слово «например»

и т.п.;

непротиворечивость. Каждое утверждение ПМ должно иметь только один

смысл (значение).

Требования к определениям и обозначениям в тексте ПМ:

– полнота. ПМ должен включать определения для каждого технического

термина и аббревиатуры;

– первое использование. Определение термина должно либо предварять его

использование, либо следовать непосредственно за первым использованием. Ис-

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

ление;

– идентифицируемость. Первое использование термина, требующего сво-

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

шрифта в тексте);

– простота поиска. Читатель ПМ должен иметь возможность легко найти

определение каждого термина или аббревиатуры в единственном месте (глоссарии

или списке сокращений);

– согласованность. ПМ должен использовать те же определения терминов и

аббревиатур, что были введены в документах более высокого уровня;

– обозначение. Каждый компонент должен иметь уникальное обозначение.

Для текстовых документов это может быть числовое обозначение (номера разде-

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

контекстного поиска).

Модифицируемость. Предполагает соблюдение требований относительно:

– уникальности размещения. Каждое утверждение должно размещаться

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

того требуют цели ПМ (например, повторения в учебных материалах, инструкциях

и др.);

– обозначения ссылок. Ссылки на утверждение в ПМ должны включать обо-

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

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

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

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

Требования к оформлению ссылок на документы. Каждая ссылка на соот-

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

маленьких ПМ, в них необходимо включать раздел библиографии.

Требования к языку. Грамматические правила языка изложения должны со-

блюдаться.

Требования к идентификации. Эти требования касаются:

– версии. ПМ должен иметь уникальный идентификатор версии, отличаю-

щий данный ПМ от его предшественников;

– автора. ПМ должен иметь идентификацию авторов, которые несут ответ-

ственность за его разработку.

Требования к минимизации ПМ. Эти требования касаются:

Глава 6 299

– неизбыточности. ПМ не должен содержать утверждений, которые не яв-

ляются необходимыми для достижения целей его использования;

– простоты. ПМ не должен содержать утверждения, трудные для пони-

мания и осложняющие поиск их смыслового назначения в ПМ.

Литература к главе 6

1. ISO/IEC 12207:1995 / Amd.2:2004 Information technology – Software life cycle processes.

2. Васютович В., Самотохин С., Никифоров Г. Регламентация жизненного цикла про-

граммных средств // Открытые системы, № 7-8. – 2000. – www.osp.ru/cio/2000/07-

08/042.htm.

3. ISO/IEC 15271:1998. Information Technologies - Guide for ISO/IEC 12207 Software Life

Cycle Processes.

4. IEEE Std. 1012:1998. IEEE Standard for Software Verification and Validation.

5. IEEE Std. 1016:1998. IEEE Recommended Practice for Software Design Descriptions.

6. IEEE Std. 1063:1987. IEEE Standard for Software User Documentation.

7. ISO/IEC 9127: 1998. User documentation and cover information for software packages.

8. ISO/IEC 6592:2000. Information Technology. Guidelines for the documentation of computer-

based application systems.

9. IEEE Std. 1044:1993. IEEE Standard Classification for Software Anomalies.

10. IEEE Std. 1044.1:1995. IEEE Guide to Classification for Software Anomalies.

11. Software error analysis (на сайте hissa.nist.gov/SWERROR/).

12. Reference Information for the Software Verification and Validation Process (на сайте

http://hissa.nist.gov/HHRFdata/Artifacts/ITLdoc/234/val-proc.html).

13. IEEE Std. 1028:1997. IEEE Standard for Software Reviews.

14. Using Formal Inspections in Software Quality Assurance http://www.cis.ksu.edu/~hankley/

d841/Fa99/Chap3.html

15. Fagan M. E. Design and Code Inspections to Reduce Errors in Program Development // IBM

Systems Journal.- v.15.- P. 182-211.

16. Ackerman A.F., Buchwald L.S., Lewski F.H. Software inspections: An effective verification

process // IEEE Software.- 1989.- V.6.-May.- P. 31-36.

17. Модель оценки технологической зрелости организаций-разработчиков ПО / Ф.И. Андон,

В.Ю. Суслов, Т.М. Коротун, Г.И. Коваль, О.А. Слабоспицкая // Проблемы программиро-

вания. - 1998. - № 4. - С. 46 – 57.

18. Emam K. El, Laitenberger O. Evaluation capture-recapture models with two inspectors // IEEE

Trans. On Softw. Eng. – 2001. – V.27. – N.9. – P. 851-864.

19. Frankovich J. The Software Inspection Process // Advanced Information Services.-

http://sern.ucalgary.ca/courses/seng/621/W97/johnf/inspections.htm.

20. Lee E. Software Inspections: How to Diagnose Problems and Improve the Odds оf Organiza-

tional Acceptance //CrossTalk. – aug. 1997.

21. Strauss S., Ebenau R. Software Inspection Process // New York: McGraw-Hill, Inc. – 1993. –

363 p.

22. Wheeler D. A., Brykczynski B., Meeson R. N. Software Inspection: An Industry Best Practice

// IEEE Computer Society Press.- Los Alamitos, CA.-1996.- 325 p.

300

Глава 7. ТЕСТИРОВАНИЕ ПРОГРАММНЫХ СИСТЕМ

7.1. Основные понятия в области тестирования

Тестирование – неотъемлемая составляющая процесса программной инжене-

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

ного обеспечения системы посредством выявления оставшихся дефектов, не обна-

руженных ранее всеми другими видами проверок.

Термин testing (тестирование) широко используется в литературе, но опреде-

ляется по-разному.

Стандарт ANSI/IEEE Std. 610.12:1990 определяет термин testing в самом его

широком смысле как любое действие по анализу ПО (включая методы как динами-

ческой, так и статической проверки) [1].

Г. Майерс определяет этот термин в самом узком смысле: «тестирование –

процесс выполнения программы (или ее части) с целью обнаружения ошибок… От-

ладка (debugging) – диагностирование точной природы известных ошибок и их ис-

правление» [2].

Слово testing может быть переведено не только как тестирование, но и как

испытания (как это сделано в стандартах ДСТУ 2844-94 [3], ДСТУ 2853-94 [4]).

Однако, понятие «испытания» нам привычнее связывать с завершающими стадия-

ми ЖЦ, на которых выполняется не поиск ошибок, а подтверждение пригодности

разработанного программного продукта.

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

граммной системы (или элементов ПС) с целью проверки ее соответствия уста-

новленным требованиям и обнаружения дефектов.

По мере развития программной инженерии понимание целей и задач тести-

рования менялось. В работе [5] выделены следующие «исторические» периоды,

отражающие прогресс в понимании целей тестирования и его места в жизненном

цикле ПС:

1) период до 1956 года - ориентация на отладку;

2) период с 1957 по 1978 гг. - ориентация на установление соответствия ПС

исходным требованиям;

3) период с 1979 по 1982 гг. – ориентация на обнаружение дефектов, остав-

шихся после реализации;

4) период с 1983 по 1987 гг. – ориентация на анализ, проверку и тестирование

с целью оценки качества ПС на всех стадиях разработки;

5) период с 1988 по 1995 гг. – интеграция действий по проверке и

тестированию в жизненный цикл ПС с целью предотвращения появления дефектов

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

тестированию).

С появлением в 1995 году стандарта ISO/IEC 12207 [6], в котором все дейст-

вия, связанные с созданием ПС, представлены в виде отдельных процессов ЖЦ,

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

ным процессам. Тестирование отнесено к основным процессам, но представлено не

одним, а группой процессов. Кроме того, ряд задач тестирования решаются в рам-

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

распределены по процессам: «Проектирование архитектуры системы», «Анализ

требований к ПО», «Проектирование ПО». Автономное и интеграционное тестиро-

Глава 7 301

вание ПО выполняются в рамках процессов «Построение ПО» и «Интеграция ПО»,

поскольку неразрывно с ними связаны.

Таким образом, произошла интеграция тестирования с процессами разработ-

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

няемая на протяжении всего процесса разработки. Планирование тестирования

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

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

В SWEBOK 2004 года [7] область знаний «Тестирование ПО» представлена

пятью основными разделами (рисунок 7.1). Весь последующий материал главы

структурирован таким образом, чтобы учесть рекомендации SWEBOK по их смы-

словому наполнению.

Рис. 7.1. Область знаний «Тестирование ПО» в SWEBOK-2004

Терминология тестирования. Тестирование заключается в динамической

проверке поведения программы на конечном множестве тестовых данных, специ-

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

вие установленному ожидаемому поведению.

Выделенные курсивом слова ключевые для тестирования:

динамическое: тестирование всегда предполагает выполнение программы;

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

такое количество тестов, для выполнения которых могут понадобиться годы [2, 8].

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

ное множество тестов можно рассматривать как бесконечное. Количество же тес-

тов, которые могут быть выполнены в ограниченные сроки, конечно. Таким обра-

зом, тестирование всегда предполагает некий «компромисс» между ограниченными

сроками и потенциально неограниченным количеством тестов. Это приводит к из-

вестным проблемам тестирования, таким как принятие решений об адекватности

302 Глава 7

тестирования, и проблемам управления – оценке затрат (стоимости, времени, пер-

сонала) на тестирование;

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

ра ограниченного множества тестов. Методы тестирования, в основном, отличают-

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

ожидаемое поведение: нужно уметь определять, правильны ли полученные

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

ожиданиям пользователя или спецификациям. В литературе по тестированию это

называется проблемой оракула [2] (эталона), для решения которой могут приме-

няться разные подходы (оценка результатов, сравнение с существующим эталоном,

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

Хотя основная цель тестирования – обнаружить дефекты в программной сис-

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

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

чие. Отсюда следует два основных подхода к выполнению тестирования – деструк-

тивный (отрицательное, разрушительное тестирование) и конструктивный (поло-

жительное или демонстрационное).

При деструктивном подходе тесты выбираются с целью обнаружения дефек-

тов, и эффективным считается тест с высокой вероятностью их обнаружения.

При конструктивном подходе тесты выбираются для демонстрации соответ-

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

чества.

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

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

категория объектов тестирования (вся система, программные компоненты, модули)

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

Цели и объекты совместно определяют критерий выбора множества тестов,

как относительно его полноты - «какой объем тестирования достаточен для дости-

жения установленной цели?», так и его состава - «какие тесты должны быть выбра-

ны для достижения установленной цели?». Первый вопрос касается выбора крите-

рия покрытия, а второй – критерия выбора типов тестов.

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

тестирование-исправление-повторное тестирование.

В современной программной инженерии все виды действий, связанные с тес-

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

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

тирования. Документирование процесса тестирования облегчает взаимодействие

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

зволяет сделать процесс видимым, повторяемым и измеряемым.

К ключевым вопросам тестирования в SWEBOK отнесены следующие:

1. Критерии выбора тестов/Критерии адекватности тестов (или правила

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

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

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

ходимо прекратить тестирование.

2. Эффективность тестирования/Цели тестирования. Тестирование – это

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

Глава 7 303

данными параметрами, по заданному сценарию или с другими заданными началь-

ными условиями или целями тестирования. Эффективность теста может быть опре-

делена только в контексте заданных условий [9].

3. Тестирование для выявления дефектов [8]. В тестировании для выявления

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

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

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

предъявляемым к ней требованиями и, соответственно, тест считается успешным,

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

4. Проблема оракула. «Оракул» в тестировании – это любой агент (человек

или программа), оценивающий поведение программы и формирующий заключение

о результате теста (тест пройден или нет). Это заключение существенно зависит от

трактовки понятия «отказ» и «дефект» в конкретном контексте.

5. Теоретические и практические ограничения тестирования. Ограничения

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

нецелесообразности для конкретных ПС. Тестирование должно проводиться с уче-

том риска отказа ПС и основываться на таких стратегиях тестирования, получив-

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

основанное на риске (risk-based testing), и управляемое риском тестирование (risk-

driven testing), которые кратко рассмотрены в этой главе.

6. Проблема неосуществимых путей. Неосуществимые пути – это пути пото-

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

ных параметрах. Это сложнейшая проблема путевого тестирования и особенно его

автоматизации [9]. Основные методы путевого тестирования рассмотрены в разде-

ле 7.3.

7. Тестопригодность [10]. Этот термин имеет два разных значения. Первое –

это степень легкости описания критериев тестового покрытия для ПС, второе – ве-

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

наличии дефекта.

Связь тестирования с другими видами деятельности. Тестирование имеет

много общего с процессами верификации и валидации (V&V), рассмотренными в

главе 6. Общность процесса тестирования с процессами V&V заключается в един-

стве состава и структуры планов, рекомендуемых IEEE Std. 829 [11], а также объек-

тов и применяемых методов. Отличие этих процессов состоит в условиях их при-

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

объектов ПО системы независимо от ее критичности. Процессы V&V, в современ-

ной трактовке стандартов IEEE Std. 1012 [12] и ISO/IEC 12207 [6] – поддерживаю-

щие процессы, которые могут применяться к выбранным объектам тестирования

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

тирование адекватно уровню критичности ПС. По отношению к процессу тестиро-

вания V&V выполняет контрольную функцию и подтверждает соответствие объек-

тов установленным требованиям.

Тестирование ПС тесно связано с отладкой и собственно программировани-

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

стов, тестировщиков, аналитиков и инженеров по качеству.